Cisco Collaboration システム 12.x ソリューション リファレンス ネットワーク デザイン（SRND）
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2018年6月11日
章のタイトル： コラボレーションのインスタント メッセー ジングとプレゼンス
- 永続的なチャットの配置に関する考慮事項
- IM and Presence Service のチャット ルームの制限
- マネージド ファイル転送
- オンプレミスの Cisco IM and Presence サービスのメッセージ アーカイブおよびコンプライアンス
- オンプレミスの Cisco IM and Presence サービスのカレンダー統合
- Exchange Web サービス カレンダー統合
- オンプレミスの Cisco IM and Presence サービス モビリティ統合
- オンプレミスの Cisco IM and Presence サービス サードパーティ製 Open API
- オンプレミスの Cisco IM and Presence サービスの設計に関する考慮事項
- モバイル & リモート アクセス
コラボレーションのインスタント メッセージングとプレゼンス
Cisco Unified Communications Manager IM and Presence サービスは、ネイティブな標準ベースのデュアルプロトコル企業インスタント メッセージング（IM）、および Cisco Unified Communications の一部としてのネットワークベースのプレゼンスを提供します。Cisco Unified Communications Manager のこのセキュアかつスケーラブルで管理の容易なサービスでは、ユーザに企業内外への機能豊富な通信機能が提供されます。
Cisco Unified Communications Manager IM and Presence サービスは IM and Presence のオプションの 1 つであり、Cisco Unified Communications および Collaboration システムの価値を高めます。このソリューションの主要なプレゼンス コンポーネントは、すべてのオンプレミス配置で必要な Cisco IM and Presence サービスです。このサービスは Extensible Communications Platform（XCP）を備え、ユーザの在籍ステータスと通信機能に関する情報を収集する SIP/SIMPLE および Extensible Messaging and Presence Protocol（XMPP）をサポートしています。ユーザの在籍ステータスは、ユーザが電話機などの通信デバイスをアクティブに使用しているかどうかを示します。ユーザの通信能力は、ビデオ会議、Web コラボレーション、インスタント メッセージング、基本オーディオなど、ユーザが使用できる通信の種類を示します。
IM and Presence サービスは、シスコやサードパーティの互換性のあるデスクトップとモバイル プレゼンス、およびインスタント メッセージング クライアントと緊密に統合されており、Cisco Jabber SDK も含まれています。これにより、クライアントはインスタント メッセージング、プレゼンス、クリックツーコール、電話制御、音声、ビデオ、ビジュアル ボイスメール、Web コラボレーションなど多数の機能を実行できます。IM and Presence サービスが提供するリッチなオープン インターフェイスによる柔軟性が、IM およびシスコのネットワークベース プレゼンスの実装に加え、さまざまなビジネス アプリケーションの IM and Presence フェデレーションを可能にします。
Cisco IM and Presence サービスによって取得された集約ユーザ情報により、Cisco Jabber、Cisco Unified Communications Manager アプリケーション、およびサードパーティ製のアプリケーションはユーザの生産性を高めることができます。これらのアプリケーションは、最も効果的な通信形態を判断することにより、ユーザ間のコミュニケーションの効率性を高めます。
（注
） Cisco IM and Presence サービスは、Cisco Unified Computing System（UCS）上の仮想サーバでシスコが提供する VM 設定オプション ユーザ設定テンプレートを使用して、Cisco Unified Communications Manager（Unified CM）の同等のバージョンとともに配置する必要があります。シスコは仮想サーバ間での VM リソースのオーバーサブスクリプションをサポートしていないため、配置される仮想サーバごとに専用のシステム リソースを使用する必要があります。
この章では、オンプレミス、クラウド、およびハイブリッド オプション用の Cisco Unified Communications システムにおけるプレゼンスとインスタント メッセージングの基本概念を説明し、プレゼンスおよびインスタント メッセージング ソリューションのさまざまなコンポーネントを最適に配置するためのガイドラインを示します。
この章の変更点
表 20-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
|
|---|---|---|
プレゼンス
プレゼンス とは、ユーザが特定のデバイス セットで通信する能力とその意志を意味します。プレゼンスでは、次の段階またはアクティビティが実行されます。
ユーザ ステータスの変更は、ユーザによるキーボード操作、電話機の使用、WebEx Meeting ステータス、ネットワークへのデバイス接続、Microsoft Exchange のカレンダー ステータスを認識することにより、自動的にパブリッシュできます。
パブリッシュされた情報は、すべての利用可能なソースから収集され、プライバシー ポリシーが適用され、現在のステータスが集約および同期されてから、保存されたうえで消費されます。
デスクトップ アプリケーション、カレンダー アプリケーション、およびデバイスが、ユーザ ステータス情報を使用して、エンド ユーザにリアルタイムの更新情報を提供します。これにより、エンド ユーザは、適切な通信方法を判断できるようになります。
ステータス情報は、デバイスやユーザが実行可能な機能（音声、ビデオ、インスタント メッセージング、Web コラボレーションなど）と、デバイスやユーザの状態（連絡可能、ビジー、通信中など）の両方を示します。プレゼンス ステータスは、クライアントへのログインや電話機のオフフックなどの自動イベントによって決定されるか、またはユーザがステータス変更ピックリストから [Do Not Disturb] を選択したなどのユーザによるステータス変更の明示的な通知イベントによって決定されます。
プレゼンスに関する用語として、ウォッチャ、プレゼンス エンティティ（ presentity ）、およびプレゼンス サーバがあります。プレゼンス エンティティは、SIP/SIMPLE クライアントの場合は PUBLISH または REGISTER メッセージを、XMPP クライアントの場合は XML プレゼンス スタンザを使用して、自身の現在のステータスをプレゼンス サーバにパブリッシュします。プレゼンス エンティティは、通信クラスタ内外のディレクトリ番号（DN）または SIP のユニフォーム リソース識別子（URI）です。 ウォッチャ （デバイスまたはユーザ）は、プレゼンス サーバにメッセージを送信することにより、プレゼンス エンティティに関するプレゼンス ステータスを要求します。これに対しプレゼンス サーバは、要求されたプレゼンス エンティティの現在のステータスが含まれたメッセージをウォッチャに返します。
オンプレミスの Cisco IM and Presence サービスのコンポーネント
Cisco IM and Presence サービスでは、図 20-1 に示すコンポーネントが対象になります。
図 20-1 Cisco IM and Presence サービスのインターフェイス
オンプレミスの Cisco IM and Presence サービス ユーザ
ユーザのプレゼンスは通常、ユーザのプレゼンス ステータス、システム上のユーザ数、またはユーザのプレゼンス機能で示されます。
Unified CM で エンド ユーザ として指定されたユーザには、ライン アピアランスを関連付ける必要があります。Unified CM で IMP PUBLISH Trunk サービス パラメータを使用する場合は、ユーザをライン アピアランスと関連付ける必要があります。ライン アピアランスに関連付けることによって、ユーザは実質的にライン アピアランス（特定のデバイスのディレクトリ番号または URI）に結合されるので、より詳細できめ細かいプレゼンス情報を集約できます。ユーザを複数のライン アピアランスにマップすることも、各ライン アピアランスに複数のユーザ（最大 5 人）を割り当てることも可能です。
（注） 音声専用、ビデオ専用、または IM 専用の導入の場合、シスコ コラボレーション システム リリース（CSR）12.x の IM and Presence サービスの、フル UC モードでのクラスタ容量の制限は 75,000 ユーザです。
この章では、 プレゼンス ユーザ という概念が随所で使用されます。Cisco IM and Presence で定義されるユーザの意味を常に念頭に置いてください。デフォルトで、Unified Communications 配置では IM and Presence サービス ユーザは user@default_domain （Jabber ID（JID）の基本）として定義されます。ここで、 user は手動または Unified CM LDAP 同期アグリーメント（sAMAccountName、電子メール、employeenumber、telephonenumber、または UserPrincipalName）で設定されている値、 default_domain は IM and Presence サービス管理で設定されているドメインです。
拡張 IM アドレッシングおよび IM アドレス スキーム
拡張 IM アドレッシング機能では、Unified CM IM and Presence で追加の IM アドレス（JID）設定オプションを使用でき、マルチドメイン サポートが提供されます。
- UserID @ Default_Domain は、IM and Presence サービスをインストールした場合の、デフォルトの IM アドレッシング方式です。
- DirectoryURI IM アドレッシング方式は、複数のドメイン、ユーザのメール アドレスの調整、および Microsoft SIP URI の調整をサポートしています。
user@default_domain のデフォルト設定では 1 つのドメインだけが許可されますが、DirectoryURI では複数のドメインや電子メール アドレスを連絡先識別子としてより柔軟に処理することができます。ユーザは各自の sAMAccountName 属性を使用して Jabber にログインでき、Jabber ID が DirectoryURI フィールドにマッピングされます。Fleixble JID 構造により認証用の UID とは独立しています。
（注） DirectoryURI は Unified CM のグローバル管理設定です。IM and Presence サービス アドレッシングに DirectoryURI を選択する場合、配置内のすべてのクライアントは DirectoryURI オプションを処理およびサポートできる必要があります。
ユーザ ID は電子メール アドレスにマッピングできますが、それが IM URI が電子メール アドレスに等しいという意味ではありません。代わりに、 <email-address> @ Default_Domain となります。たとえば、amckenzie@example.com @sales-example.com です。選択した設定をマッピングする Active Directory（AD）は、IM and Presence サービス クラスタ内のすべてのユーザに対してグローバルに適用されます。個々のユーザに対して異なるマッピングを設定することはできません。
単一 IM ドメインに限定される UserID@Default_Domain IM アドレッシング方式とは異なり、DirectoryURI IM アドレッシング方式は複数の IM ドメインをサポートします。DirectoryURI に指定されたドメインは IM and Presence サービスによってホストされているものとして処理されます。ユーザの IM アドレスを使用して、Cisco Unified Communications Manager で設定されているとおりにそれらのユーザの DirectoryURI に合わせます。
シングル サインオン（SSO）ソリューション
シスコではシングル サインオン ソリューション（SSO）として SAML SSO（リリース 10.0(1) 以降）の使用を推奨しています。
SAML は、すべてのオペレーティング システムでフェデレーテッド認証を有効にするオープン スタンダードです。SAML 標準により、クライアントは自身のプラットフォームのオペレーティング システム（OS）に関係なく、SAML 対応の Collaboration サービスに対して認証を行うことができます。SAML とは、ユーザおよびユーザの属性に関する情報を共有するために定義された標準セットであり、認証の要求方法、およびアクセスを許可または拒否する方法を提供します。たとえば SAML を使用すると、2 つの組織がパスワードを交換せずに信頼関係を確立することができます。
SAML は次のエンドユーザ アプリケーションをサポートします。
- Cisco Unified CM
- Cisco IM and Presence サービス
- Cisco Unity Connection
- Cisco WebEx Connect および Messenger Cloud
SAML SSO は次のエンドユーザ クライアントもサポートします。
- WebEx iOS
- WebEx Android
- WebEx Connect
- WebEx Messenger
- Jabber for Windows
- Jabber iOS
- Jabber for Android
- Jabber for Mac
SAML SSO の詳細については、オンプレミスの Cisco IM and Presence サービスの Jabber 用 SAML SSOの項、または次の Web サイトで入手可能な『 SAML SSO Deployment Guide for Cisco Unified Communications Applications 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
IM and Presence のコラボレーション クライアント
Jabber クライアントの Cisco Collaboration ソフトウェア ファミリを使用すると、ユーザは音声およびビデオ コールに簡単にアクセスでき、同僚のプレゼンス情報を含む連絡先ディレクトリや、インスタント メッセージング（IM）、ボイス メッセージング、デスクトップ共有、および会議のツールを利用できます。
Cisco Jabber クライアントではさまざまなオプションから選択でき、サードパーティ製 XMPP クライアントとアプリケーションも使用できます。Cisco Jabber クライアントは、インターフェイスの共通セットにより、基礎となる Cisco Unified Communication サービスと統合されます。一般に、各クライアントでは特定のオペレーティング システム、およびデスクトップとモバイルの両方のアプリケーションがサポートされます。
この章のクライアント固有の項では、Cisco Unified Communications システムへの統合に関して、関連する配置上の考慮事項、プランニング、および設計ガイドラインも提供しています。
次のコラボレーション クライアントが、Cisco Unified Communications システムでサポートされます。
– Virtualization Experience Media Engine（VXME）for Windows
Macintosh と Windows の両方で使用できる Cisco Jabber デスクトップ クライアントは、基本的な IM and Presence、音声とビデオ、ビジュアル ボイスメール、デスクトップ共有、デスクフォン制御、Microsoft Office との統合、およびコンタクト管理など、堅牢で機能豊富なコラボレーション機能を提供します。
Cisco Jabber デスクトップ クライアントを配置して、Cisco IM and Presence および Cisco Unified Communications Manager がクライアント設定、インスタント メッセージングとプレゼンス、およびユーザとデバイスの管理を提供するオンプレミス サービスを利用できます。Cisco Jabber for Windows と Cisco Jabber for Mac は、Cisco WebEx Messenger サービスと統合することで、クラウドベースの環境でも使用できます。
マルチ デバイス メッセージング（MDM）とログイン
ユーザが Jabber デスクトップまたはモバイル クライアントにログインすると、すべての Cisco Jabber クライアントが IM and Presence サービス ノードに関連付けられます。ユーザが関連付けられた IM and Presence ノードは、在席状況、連絡先リスト、および機能ベースのタスクなど、そのユーザに対するすべての変更をモニタします。
IM and Presence サービス ノードは、それぞれのプレゼンス対応ユーザの登録済みクライアントをすべて追跡します。これは、ユーザが Cisco Jabber for iOS、Android、Windows、または Mac など、各種 Jabber クライアントの 1 つでログインしていても、すべてでログインしていても変わりません。
複数のクライアントにログインしているユーザ間で新しい IM セッションが開始されると、最初の着信メッセージが受信ユーザのすべての登録済みクライアントにブロードキャストされます。その後で、IM and Presence サービス ノードが登録済みクライアントのいずれかからの最初の応答を待機します。最初に応答したクライアントは、ユーザが別の登録済みクライアントから応答を開始するまで、引き続き着信メッセージを受け取ります。その後で、ノードが以降のメッセージをこの新しいクライアントに再ルーティングします。
Johnny は Betty と IM カンバセーションを始めようと思っています。Johnny は、Cisco Jabber for Windows と Cisco Jabber for Android にすでにログインしています。また、Betty は、2 つのクライアントを中央の IM and Presence サービス ノードに登録しています。Johnny は次のようなメッセージを送信して会話を開始します。「こんにちは、Betty。今時間がありますか?」
IM and Presence サービス ノードは、Betty に 2 つの登録済みクライアントがあることを識別し、両方に Johnny のメッセージをブロードキャストします。Betty は自分のデスクで、ノートパソコンと電話の両方に表示される Johnny のメッセージを見ます。Anita はノートパソコンを使用して応答することを選択し、次のようなメッセージを返信します。「数分後に会議がありますが、短時間ならチャットできます。」
IM and Presence サービス ノードは、Betty が Cisco Jabber for Windows を使用して応答したことを特定して、これを会話で以降のすべてのメッセージをルーティングするクライアントとしてマーキングします。Johnny が「すぐに済みます」と返信すると、この返信は Cisco Jabber for Windows に直接ルーティングされます。会話のある時点から Betty が電話を使用して Johnny に応答し始めると、IM and Presence サービス ノードは以降のメッセージを Cisco Jabber for Windows ではなく、電話にルーティングします。
（注） ユーザがログインするすべてのクライアントが、IM and Presence および Unified CM クラスタ上のユーザとデバイスの合計キャパシティの制限に影響します。たとえば 15,000 ユーザ VM 設定のクラスタでは、すべてのユーザが各自の iPhone およびデスクトップ Jabber クライアントにログインする場合、最大キャパシティは 15,000 ではなく 7,500 プレゼンス ユーザになります。
Jabber デスクトップ クライアント モード
Cisco Jabber デスクトップ クライアントは、次の 2 つのモードのいずれかで、呼制御に対して動作できます。
ソフトフォン モードの Jabber デスクトップ クライアントは、音声およびビデオ コール制御機能の SIP エンドポイントとして Unified CM に直接登録され、デバイス タイプ Client Services Framework として Unified CM で設定されます。
デスクフォン制御モードの Jabber デスクトップ クライアントは、SIP を使用して Unified CM に登録されることはありませんが、代わりに Cisco IP Phone を制御しながら、CTI/JTAPI を使用してコールの開始、モニタ、終了、回線状態のモニタを実行し、コール履歴を提供します。
シスコは、Android、BlackBerry、Apple iOS デバイス（iPhone や iPad）向けにコラボレーション クライアントを提供しています。モバイル デバイス用 Cisco Jabber の詳細については、モバイル コラボレーションの章を参照してください。
Cisco UC Integration TM for Microsoft Lync
Cisco UC Integration TM for Microsoft Lync は、一貫したユーザ エクスペリエンスを保ちつつ、Cisco Unified Communications サービスと Microsoft Lync および Microsoft Office Communications Server（OCS）R2 との統合を可能にします。このソリューションは、標準ベースの音声とビデオ、ユニファイド メッセージング、Web 会議、デスクフォン制御、テレフォニー プレゼンスなどの幅広い一連の Cisco Unified Communications サービスへのアクセスを提供することにより、Microsoft Lync のプレゼンスとインスタント メッセージングの機能を拡張します。
Cisco IM and Presence では SIP/SIMPLE および Extensible Messaging and Presence Protocol（XMPP）がサポートされているため、サードパーティ製のクライアントおよびアプリケーションで、プレゼンスおよびインスタント メッセージングの更新を複数のクライアント間で通信することがサポートされています。サードパーティ製 XMPP クライアントで、さまざまなデスクトップ オペレーティング システム間での拡張された相互運用性が実現します。また、Web ベースのアプリケーションは、SOAP、REST、または BOSH（Cisco AJAX XMPP Library API に基づく）を使用する HTTP インターフェイスを使用して、プレゼンスの更新、インスタント メッセージング、および参加者リストの更新を取得できます。サードパーティ製のオープン インターフェイスの詳細については、サードパーティ製プレゼンス サーバ統合の項を参照してください。
SAML のシングル サインオン
シングル サインオンを利用すると、Cisco Jabber ユーザはすべての Jabber サービスに安全にアクセスできます。それぞれに個別にログインするよう要求されることはありません。Cisco Jabber アプリケーションでは、企業のアイデンティティ プロバイダーが実行する認証を使用します。アイデンティティ プロバイダーは、Cisco Jabber ユーザの認証エクスペリエンスを制御できます。たとえば、Cisco Jabber アプリケーションの初回実行時にユーザに社内ユーザ名とパスワードを一度要求し、ユーザに Cisco Jabber サービスの使用を許可する時間を指定することで制御します。
Cisco Jabber アプリケーションは Security Assertion Markup Language（SAML）を使用します。SAML は XML ベースのオープン スタンダードのデータ形式で、アイデンティティ プロバイダーによるクレデンシャルの確認後に定義済みの一連のシスコ サービスに対する透過的なアクセスを可能にします。SAML シングル サインオンは、Cisco WebEx Messenger サービス、Cisco Unified Communications Manager、および Cisco Unity Connection に対して有効にすることができます。SSO は、サービス ディスカバリを使用する Cisco Jabber クライアントで使用するために導入します。
– IM and Presence および Unified CM
– IM and Presence、Unified CM、および Unity Connection（SSO）
– IM and Presence、Unified CM、Unity Connection（SSO）、および Cisco Mobile ワークスペース ソリューション（SSO、または SSO なし）
– WebEx Messenger（SSO）および Unified CM
– WebEx Messenger（SSO）、Unified CM、および Unity Connection
– WebEx Messenger（SSO）、Unified CM、Unity Connection、および WebEx Meeting Center
Cisco Unified CM ユーザ データ サービス（UDS）
UDS は、Unified CM によって提供される包括的なサービス API です。UDS は、連絡先ソースに対する Cisco Expressway モバイルおよびリモート アクセスを介して Jabber が使用できる連絡先ソース API を提供します。UDS 連絡先ソースは、Unified CM のエンド ユーザ テーブルの情報を使用して連絡先検索サービスを提供します。
Cisco Unified CM 11.5 以降は、連絡先の検索に UDS-to-LDAP プロキシ機能を使用することもできます。この機能を有効にしても、連絡先の検索は引き続き UDS によって処理されますが、UDS が Jabber クライアントに結果をリレーすることで社内 LDAP ディレクトリにプロキシ処理されます。これにより Jabber クライアントは、Unified CM 内でサポートされる最大ユーザ数を超える社内ディレクトリを検索することができます。
UDS コンタクト サービスは、Expressway モバイルおよびリモート アクセスを介して接続されたリモート Jabber クライアントに対して常に使用され、社内ネットワーク上のクライアントに対してはオプションのコンタクト サービスとして使用されます。UDS 連絡先ソース データを入力するには、Unified CM の Web インターフェイス（エンドユーザが作成）、Active Directory またはサポートされている他の LDAP ソースに対する LDAP 同期機能、または UDS-to-LDAP プロキシ機能を使用します。
UDS では LDAP 連絡先ソースと同じ属性リストはサポートされません。代わりに、UDS は次の属性をサポートしています。
[username、firstname、lastname、middlename、nickname、phone number、homenumber、mobilenumber、email、directory URI、msURI、title、department、manager]
UDS では、LDAP 連絡先ソースと同レベルの予測検索または Ambiguous Name Resolution（ANR）は提供されません。UDS は firstname、lastname、および email address に対して検索を行います。
（注） Ambiguous Name Resolution（ANR）は Lightweight Directory Access Protocol（LDAP）クライアントに関連付けられた検索アルゴリズムであり、複雑な検索フィルタなしでオブジェクトをバインドすることができます。ANR は、クライアントが認識していない可能性があるオブジェクトおよび属性を見つけるときに役立ちます。
オンプレミス配置での UDS の使用に関する考慮事項は次のとおりです。
- Jabber オンプレミス（オンネット）では連絡先ソースとして LDAP または UDS を使用できます。
- UDS は Unified CM が提供する一連の HTTP ベースのサービスです。UDS 連絡先ソースは、連絡先と番号の解決を提供する UDS サービスです。
- Expressway モバイルおよびリモート アクセスを介してリモート接続された Jabber は、連絡先ソースとして常に UDS を使用します。上記のとおり、設計がクラスタ サイジングに関する推奨事項に準拠している必要があります。
UDS はクラスタ内のすべての Unified CM サーバ上で実行される統合ネットワーク サービスであり、サーバ検出に不可欠です。IM 専用の配置の場合、音声とビデオは配置に含まれませんが、UDS サービスの負荷を処理および分散するために、Unified CM の呼処理サブスクライバ ペアが必要です。必要な Unified CM サブスクライバ ペアの数は IM 専用ユーザ数によって決まります。たとえば標準の Unified CM クラスタでユーザ数またはエンドポイント数が 40,000 である場合、40,000 人の IM 専用ユーザをサポートするには 4 つのサブスクライバ ペアが必要です。
LDAP ディレクトリ
次のような多くの異なる要件を満たすように、社内 LDAP ディレクトリを設定できます。
- ユーザ プロビジョニング：ディレクトリ統合を使用して、Cisco Unified Communications Manager データベースに LDAP ディレクトリからユーザを自動的にプロビジョニングできます。Cisco Unified CM は LDAP ディレクトリの内容と同期されるため、LDAP ディレクトリに変更が発生するたびに手動でユーザ情報の追加、削除、変更を行う必要はありません。
- ユーザ認証：LDAP ディレクトリのクレデンシャルを使用してユーザを認証できます。Cisco IM and Presence は、Cisco Unified Communications Manager からすべてのユーザ情報を同期してクライアント ユーザを認証します。
- ユーザ ルックアップ：LDAP ディレクトリの参照を有効にして、シスコのクライアントまたはサードパーティ製 XMPP クライアントが LDAP ディレクトリで連絡先を検索できるようにします。
AD グループおよびエンタープライズ グループ
Cisco Jabber ユーザは Microsoft Active Directory のグループを検索して、自分の連絡先リストに追加できます。
Cisco Unified CM は、指定された間隔（LDAP ディレクトリ設定の [LDAP ディレクトリ同期スケジュール（LDAP Directory Synchronization Schedule）] パラメータで指定）でデータベースを Microsoft Active Directory グループと同期し、同期時に Jabber エンドユーザの連絡先リストも更新します。
AD グループ同期機能が有効な状態で、Cisco Jabber ユーザがグループを連絡先リストに追加する場合、Cisco Jabber クライアントは IM and Presence サービス ノードにグループ要求を送信します。IM and Presence サービス ノードは各グループ メンバーに関する次の情報を提供します。
グループおよびユーザ フィルタに関する AD グループの考慮事項
WebEx ディレクトリ統合
WebEx ディレクトリの統合は WebEx 管理ツールの使用により実現します。WebEx は WebEx Messenger サービスに企業ディレクトリ情報のカンマ区切り形式（CSV）ファイルをインポートします。詳細については、次の Web サイトにあるマニュアルを参照してください。
https://www.webex.com/webexconnect/orgadmin/help/index.htm?toc.htm?17444.htm
ローカル Jabber デスクトップ クライアント キャッシュまたは連絡先リストで連絡先が見つからない場合、連絡先の検索を実行できます。WebEx Messenger ユーザは、連絡先名が入力されるとキャッシュ、連絡先リスト、およびローカル Outlook の連絡先リストを照会する予測検索を使用できます。一致が見つからない場合、検索は社内ディレクトリ（WebEx Messenger データベース）への照会を続けます。
Jabber クライアントの一般的な配置モデル
Cisco Jabber デスクトップ クライアントは、次の配置モデルをサポートします。
配置モデルの選択は、主に IM and Presence の製品選択、および音声やビデオ、ボイスメール、デスクフォン制御といった追加サービスの要件に依存します。
オンプレミス配置モデル
オンプレミス配置モデルでは、運用や保守管理を自社で行う企業ネットワーク上ですべてのサービスがセットアップおよび設定されます（図 20-2 を参照）。
Cisco Jabber for Windows のオンプレミス配置モデルには、次のコンポーネントが必要です。
- Cisco Unified Communications Manager は、すべてのユーザおよびデバイスの設定機能を提供します。
- Cisco Unified Communications Manager およびシスコの会議デバイスは、音声およびビデオ会議機能を提供します。
- Cisco Unity Connection はボイスメール機能を提供します。
- Cisco IM and Presence はインスタント メッセージングおよびプレゼンス サービスを提供します。
- Microsoft Active Directory またはサポートされている他の LDAP ディレクトリは連絡先ソースを提供します。
これらのコンポーネントは、Cisco Jabber クライアントの基本配置を実現する重要な要件です。基本配置をセットアップおよび設定した後は、次のような追加の配置オプションを設定できます。
- 音声：音声コール機能を提供します。
- ビデオ：ビデオ コールの送受信を可能にする機能を提供します。
- ボイスメール：ユーザが Cisco Jabber クライアントのユーザ インターフェイスで直接利用するか、ボイスメール番号のダイヤル時に取得できるボイスメール機能を提供します。
- デスクトップ共有：Binary Flow Control Protocol（BFCP）によりデスクトップを共有できるようにします。
- Microsoft Office 統合：Microsoft Outlook などの Microsoft Office アプリケーションのユーザ インターフェイスで、ユーザの在籍ステータスおよびメッセージング機能を直接提供します。
クラウドベース配置モデル
クラウドベース配置モデルでは、すべて（またはほとんど）のサービスが Cisco WebEx を使用してクラウドでホストされます。Cisco WebEx を使用してクラウドベース配置モデルを実装する場合は、Cisco WebEx 管理ツールでクラウドベース配置を管理およびモニタします（図 20-3 を参照）。
図 20-3 Jabber クラウドベース配置モデル（WebEx）
Cisco Jabber for Windows のクラウドベース配置モデルでは、次のサービスに Cisco WebEx Messenger サービスを使用します。
これらのサービスは、Cisco Jabber for Windows の基本配置を実現するために必要な基本コンポーネントです。基本配置をセットアップおよび設定した後は、次のような追加の配置オプションを設定できます。
- Cisco WebEx Meeting Center：オンライン会議やイベントなどのホステッド コラボレーション機能を提供します。
- Microsoft Office 統合：Microsoft Outlook などの Microsoft Office アプリケーションのユーザ インターフェイスで、ユーザの在籍ステータスおよびメッセージング機能を直接提供します。この統合はデフォルトで設定されます。
- カレンダー統合：WebEx Meeting Center、Outlook、および IBM Lotus Notes とのカレンダー統合もサポートされます。
WebEx Messenger サービスの Jabber クライアント向け設定については、次の Web サイトで入手可能な『 Cisco WebEx Messenger Administrator’s Guide 』を参照してください。
クラウドベース/オンプレミス ハイブリッド配置モデル
ハイブリッド配置では、Cisco WebEx Messenger サービスでホストされるクラウドベース サービスが、オンプレミス配置の次のコンポーネントと組み合わされます（図 20-4 を参照）。
- Cisco Unified Communications Manager は、ユーザおよびデバイス サービスを提供します。
- Cisco Unity Connection はボイスメール サービスを提供します。
図 20-4 Jabber クラウドベース/オンプレミス ハイブリッド配置モデル
クライアント固有の設計の考慮事項
ここでは、Mac および Windows 用の Cisco Collaboration デスクトップ クライアントに固有の設計に関する考慮事項について説明します。これらのクライアント タイプの一般的な設計の考慮事項については、Cisco Jabber デスクトップ クライアントのアーキテクチャの項にある設計ガイドラインを参照してください。
電話機固有のプレゼンスおよびビジー ランプ フィールド
Unified CM に接続するエンドポイントは、他の 1 つ以上のエンドポイントの回線ステータスをアイドル、ビジー、不明として受信できます。ステータスは、コール履歴、ディレクトリ、およびビジー ランプ フィールド（BLF）機能を使用して表示されます。ユーザが参照を実行した後でのみコール履歴とディレクトリのプレゼンスが受信されている間は、BLF は継続的に電話機またはビデオ電話の回線ステータスをモニタし、そのステータスをモニタリング デバイスに設定されている特定のプレゼンス対応のスピード ダイヤルに表示します。
ユーザのテレフォニー プレゼンス要求は、クラスタ内かクラスタ外かに関係なく、すべて Cisco Unified CM で処理されます。
ウォッチャとプレゼンス エンティティが同じ Unified CM クラスタ内にある場合、プレゼンス要求を送信した Unified CM ウォッチャは、プレゼンス ステータスなどの応答を直接受信します。
プレゼンス エンティティがクラスタ外にある場合、Unified CM は、SIP トランク経由で外部のプレゼンス エンティティに照会します。ウォッチャが、SUBSCRIBE コーリング サーチ スペースとプレゼンス グループ（いずれもUnified CM のプレゼンス ポリシーの章を参照）に基づいて外部プレゼンスをモニタする権限を持つ場合、SIP トランクはプレゼンス要求を外部プレゼンス エンティティに転送し、外部プレゼンス エンティティからの応答を待って、現在のプレゼンス ステータスをウォッチャに返します。
Unified CM クラスタ外のウォッチャは、プレゼンス要求を SIP トランクに送信します。Unified CM がそのプレゼンス エンティティをサポートしている場合、現在のプレゼンス ステータスを応答として返します。Unified CM がそのプレゼンス エンティティをサポートしていない場合、SIP エラー応答によってプレゼンス要求を拒否します。
SIP を使用した Unified CM のプレゼンス
Unified CM で、 SIP 回線 という用語は、Unified CM に直接接続され、登録されている SIP 対応のエンドポイントを表し、 SIP トランク という用語は、SIP をサポートするトランクを表します。プレゼンス ウォッチャとして動作する SIP 回線側エンドポイントは、指定されたプレゼンス エンティティのプレゼンス ステータスを要求する SIP SUBSCRIBE メッセージを Unified CM に送信します。
そのプレゼンス エンティティが Unified CM クラスタ内にある場合、Unified CM は、SIP 回線側プレゼンス要求に対し、プレゼンス エンティティの現在のステータスを示す SIP NOTIFY メッセージをプレゼンス ウォッチャに応答として送信します（図 20-5 を参照）。
図 20-5 SIP 回線の SUBSCRIBE/NOTIFY の交換
そのプレゼンス エンティティが Unified CM クラスタ外にある場合、Unified CM は、SUBSCRIBE コーリング サーチ スペース、プレゼンス グループ、および SIP ルート パターンに基づいて、SUBSCRIBE 要求を外部の適切な SIP トランクにルーティングします。Unified CM は、プレゼンス エンティティのステータスを示す SIP NOTIFY 応答をトランクで受信すると、SIP 回線側プレゼンス要求に対し、プレゼンス エンティティの現在のステータスを示す SIP NOTIFY メッセージをプレゼンス ウォッチャに送信して応答します（図 20-6 を参照）。
図 20-6 SIP トランクの SUBSCRIBE/NOTIFY の交換
Unified CM クラスタの外側にあるディレクトリ番号または SIP URI に対する SUBSCRIBE メッセージは、Unified CM 内の SIP トランク上で送受信されます。SIP トランクは、別の Unified CM とのインターフェイスとして動作するか、Cisco IM and Presence サービスとのインターフェイスとして動作できます。
Unified CM のスピード ダイヤルのプレゼンス
Unified CM は、ビジー ランプ フィールド（BLF）スピード ダイヤルを使用しスピード ダイヤルのプレゼンス機能をサポートしています。BLF スピード ダイヤルは、スピード ダイヤルとプレゼンス インジケータの両方の機能を備えています。ただし、BLF スピード ダイヤルを設定できるのは管理者のみで、システム ユーザは BLF スピード ダイヤルを設定できません。
管理者は、対象のディレクトリ番号または URI に対し、宛先の Unified CM クラスタまたは SIP トランク内のディレクトリ番号または URI に解決可能な BLF スピード ダイヤルを設定する必要があります。SIP URI に対して、BLF スピード ダイヤル用に、BLF SIP 回線側エンドポイントを設定することもできますが、SCCP 回線側エンドポイントの設定はできません。BLF スピード ダイヤルのインジケータは、回線レベルのインジケータであり、デバイス レベルのインジケータではありません。
（注） クラスタあたり最大 30,000 BLF スピード ダイヤルを設定できます。
BLF スピード ダイヤルをサポートしている電話機モデルのリストについては、 https://www.cisco.com/ で入手可能な Cisco Unified IP Phone のアドミニストレーション ガイドを参照してください。
図 20-7 では、電話機のさまざまなタイプの BLF スピード ダイヤルのインジケータを示しています。
図 20-7 Cisco Unified IP Phone 7900 シリーズのスピード ダイヤルのプレゼンスのインジケータ
Unified CM のコール履歴のプレゼンス
Unified CM は、コール履歴リストに関するプレゼンス機能をサポートしています（電話機の Directories ボタン）。コール履歴リストのプレゼンス機能は、Unified CM Administration 内の BLF for Call Lists エンタープライズ パラメータによって制御されます。 BLF for Call Lists エンタープライズ パラメータは、電話機の Directories ボタンを使用するすべてのページ（不在着信、着信履歴、発信履歴、個人ディレクトリ、社内ディレクトリ）に影響を及ぼし、グローバルに設定されます。
通話履歴リストのプレゼンス機能をサポートしている電話機モデルのリストについては、 https://www.cisco.com/ で入手可能な Cisco Unified IP Phone のアドミニストレーション ガイドを参照してください。
コール履歴リストのプレゼンス インジケータには、図 20-7 のアイコン列と同じインジケータが使用されます。LED インジケータはありません。
Unified CM のプレゼンス ポリシー
Unified CM には、プレゼンス ステータスを要求するユーザに対して、ポリシーを設定する機能があります。このポリシーを設定するには、まずプレゼンス ステータスに関する SIP SUBSCRIBE メッセージを特にルーティングするコーリング サーチ スペースを設定します。次に、ユーザを関連付けることのできるプレゼンス グループを設定し、そのグループに対し、他のグループのユーザのプレゼンス ステータスを表示するためのルールを指定します。
Unified CM の SUBSCRIBE コーリング サーチ スペース
Unified CM のプレゼンス ポリシーの第 1 の側面は、SUBSCRIBE コーリング サーチ スペースです。Unified CM は、SUBSCRIBE コーリング サーチ スペースを使用して、ウォッチャ（電話機またはトランク）から送信されるプレゼンス要求（Event フィールドが Presence に設定された SUBSCRIBE メッセージ）のルーティング方法を決定します。SUBSCRIBE コーリング サーチ スペースは、ウォッチャに関連付けられ、ウォッチャが「確認」できるパーティションをリストします。このメカニズムによって、プレゼンス SUBSCRIBE 要求を通常の呼処理コーリング サーチ スペースから独立してルーティングするという詳細な制御が可能になります。
SUBSCRIBE コーリング サーチ スペースは、デバイス別またはユーザ別に割り当てることができます。ユーザがエクステンション モビリティを使用してデバイスにログインするか、管理によってデバイスに割り当てられると、開始されるサブスクリプションにユーザ設定が適用されます。
SUBSCRIBE コーリング サーチ スペースを [<なし>（<None>）] に設定すると、BLF スピード ダイヤルとコール履歴リストのプレゼンス ステータスが機能しなくなり、サブスクリプション メッセージが「ユーザ不明（user unknown）」として拒否されます。有効な SUBSCRIBE コーリング サーチ スペースを指定すると、インジケータが動作し、SUBSCRIBE メッセージが受け入れられて、適切にルーティングされます。
（注） <None> と定義されたままのコーリング サーチ スペースを残さないでください。コーリング サーチ スペースを<None> に設定したままにすると、プレゼンス ステータスやダイヤル プランの動作が予測困難になる可能性があります。
Unified CM のプレゼンス グループ
Unified CM のプレゼンス ポリシーの第 2 の側面は、プレゼンス グループです。プレゼンス グループには、デバイス、ディレクトリ番号、およびユーザを割り当てることができます。すべてのユーザは、デフォルトで Standard Presence Group に割り当てられています。プレゼンス グループは、定義済みのプレゼンス グループとのユーザのアソシエーションに基づいて、ウォッチャがモニタできる対象を制御します（たとえば、Contractors（派遣社員）から Executives（エグゼクティブ）のモニタは禁止するが、逆は許可するなど）。ユーザがエクステンション モビリティ経由でデバイスにログインするか、管理によってデバイスに割り当てられると、開始されるサブスクリプションにプレゼンス グループのユーザ設定が適用されます。
複数のプレゼンス グループが定義されている場合は、Inter-Presence Group Subscribe Policy サービス パラメータが使用されます。1 つのグループと別のグループとの関係が、許可や禁止ではなく Use System Default 設定による場合、このサービス パラメータの値が有効になります。Inter-Presence Group Subscribe Policy サービス パラメータが Disallowed に設定されている場合、SUBSCRIBE コーリング サーチ スペースが許可していても、Unified CM は要求をブロックします。Inter-Presence Group Subscribe Policy サービス パラメータは、コール履歴リストがあるプレゼンス ステータスにのみ適用され、BLF スピード ダイヤルには使用されません。
依存関係レコードを有効にすると、プレゼンス グループは、関連付けられたすべてのディレクトリ番号、ユーザ、およびデバイスをリストできます。依存関係レコードを使用することで、管理者はグループレベルの設定に関する特定の情報を検索できます。ただし、Dependency Record Enterprise パラメータを有効にすると、CPU の使用量が大きくなるので注意してください。
Unified CM のプレゼンス ガイドライン
システム管理者は、Unified CM で Unified CM Administration の中から、ユーザの電話機の状態のプレゼンス機能の設定と制御が可能です。Unified CM 内でプレゼンスを設定する場合は、次のガイドラインに従ってください。
– SUBSCRIBE コーリング サーチ スペースを使用して、ウォッチャ プレゼンスベースの SIP SUBSCRIBE メッセージが正しい宛先にルーティングされるように制御します。
– プレゼンス グループを使用して同類のユーザのセットを定義し、他のユーザ グループのプレゼンス ステータスの更新を許可するか禁止するかを定義します。
- コール履歴リストのプレゼンス機能はグローバルに有効になりますが、プレゼンス ポリシーを使用してユーザ ステータスをセキュリティ保護できます。
- BLF スピード ダイヤルは管理制御され、プレゼンス ポリシー設定の影響を受けません。
（注） Cisco Business Edition は、Unified CM によってユーザ プレゼンス機能を設定および制御する場合とほぼ同じ方法で使用できます。詳細については、呼処理の章を参照してください。
ユーザ プレゼンス：Cisco IM and Presence アーキテクチャ
Cisco IM and Presence サービスは、インスタント メッセージングとプレゼンスに標準ベースの XMPP を使用します。Cisco IM and Presence サービスは、SIP IM プロバイダーとの相互運用のために SIP もサポートしています。また、Cisco IM and Presence は、Simple Object Access Protocol（SOAP）経由の設定インターフェイス、Representational State Transfer（REST）経由のプレゼンス インターフェイス、および Cisco AJAX XMPP Library（CAXL）経由のプレゼンス、インスタント メッセージング、および Bidirectional-streams Over Synchronous HTTP（BOSH）インターフェイスを備えた HTTP インターフェイスを提供します。Cisco AJAX XMPP Library Web ツール キットは、Cisco IM and Presence 内の Extensible Communications Platform 上の BOSH インターフェイスと通信します。Cisco IM and Presence サービスは、これらの標準ベースの SIP、SIMPLE、XMPP、および HTTP インターフェイスを使用して、ユーザ機能および属性を収集、集約、および配布します。
シスコ製またはサードパーティ製のアプリケーションは、プレゼンスとの統合によって、エンドユーザ エクスペリエンスおよび効率性を向上させるサービスを提供できます。Cisco IM and Presence サービスの中心となるコンポーネントは、プレゼンス、インスタント メッセージング、参加者、ルーティング、ポリシー、およびフェデレーション管理を処理する Extensible Communications Platform（XCP）、プレゼンス ステータス収集、ネットワークベースの高度なプレゼンス構成、およびプレゼンス対応ルーティング機能を処理する高度なプレゼンス サービス、および永続的なチャットとメッセージ アーカイブが外部データベースに対して処理されるアドホック グループ チャット ストレージのサポートです。永続的なチャットが有効になっていると、アドホック チャットの期間中、アドホック ルームが外部の PostgreSQL、Microsoft SQL、または Oracle データベースに保存されます。永続的なチャットが無効の場合、アドホック チャットは、チャットの期間中揮発性メモリに保管されます。
アプリケーション（シスコ製またはサードパーティ製）にプレゼンスを統合することによって、エンド ユーザ エクスペリエンスと効率性を向上させるサービスを提供できます。さらに、Cisco Jabber はインスタント メッセージングとプレゼンス ステータスも統合した Cisco IM and Presence サービスの対応クライアントです。
Cisco IM and Presence サービスは、Microsoft Lync Server 2010 および 2013、および Unified CM に接続された Cisco Unified IP Phone 用の Microsoft Lync クライアントとの相互運用性もサポートしています。Microsoft Lync クライアントの相互運用性には、クリックツーダイヤル機能、リモート呼制御（RCC）経由の電話制御機能、および Cisco Unified IP Phone のプレゼンス ステータスが含まれます。
オンプレミスの Cisco IM and Presence サービス クラスタ
Cisco IM and Presence サービスで使用される基礎となるアプライアンス モデルおよびハードウェアは、Unified CM や Cisco Unified Computing System（UCS）プラットフォーム上の Unified CM で使用されるものと同じです（同様の管理インターフェイスなど）。サポートされるプラットフォームの詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Compatibility Matrix 』の最新バージョンを参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps556/products_device_support_tables_list.html
Cisco IM and Presence サービス クラスタは、最大 6 台のサーバで構成され、そのうち 1 つはパブリッシャに指定されています。これは、Unified CM のパブリッシャおよびサブスクライバと同じアーキテクチャ概念を採用しています。Cisco IM and Presence サービス クラスタ内の各サーバをグループ化して、サブクラスタを構成できます。サブクラスタには、最大で 2 台のサーバを関連付けることができます。図 20-8 は Cisco IM and Presence サービス クラスタの基本的なトポロジを示し、図 20-9 は可用性の高いトポロジを示しています。また、Cisco IM and Presence サービス クラスタには、2 台のサーバが設定されたサブクラスタと、1 台のサーバが設定されたサブクラスタを混合して配置することもできます（図 20-10 を参照）。
図 20-8 オンプレミスの Cisco IM and Presence サービスの基本的な配置
図 20-9 オンプレミスの Cisco IM and Presence サービスのハイ アベイラビリティ配置
図 20-10 オンプレミスの Cisco IM and Presence サービスの混合配置
オンプレミスの Cisco IM and Presence サービスは、ユーザ情報とデバイス情報を共有することによって、Unified CM パブリッシャが使用するデータベースを利用し、それを拡張します。
Cisco Unified CM とのアベイラビリティ統合をサポートするには、CUCM ドメインの SIP Proxy サービス パラメータが Unified CM クラスタの DNS ドメインと一致する必要があります。デフォルトでは、CUCM ドメインの SIP Proxy サービス パラメータは IM and Presence データベース パブリッシャ ノードの DNS ドメインに設定されます。したがって、IM and Presence データベース パブリッシャ ノードの DNS ドメインが Unified CM クラスタの DNS ドメインと異なる場合、IM and Presence データベース パブリッシャ ノードで Cisco Unified CM IM and Presence の管理ユーザ インターフェイスを使用してこのサービス パラメータを更新する必要があります。Cisco Unified Communications Manager クラスタに関連付けられた DNS ドメインの指定の詳細については、次の Web サイトで入手可能な『 Configuration and Administration of IM and Presence Service on Cisco Unified Communications Manager 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
IM and Presence はすべての Unified CM ノードのアクセス コントロール リスト（ACL）エントリを維持することに注意してください。これらのエントリは FQDN ベースで、Unified CM のホスト名を IM and Presence パブリッシャの DNS ドメインに付加することによって生成されます。そのため、IM and Presence パブリッシャ（データベース）の DNS ドメインが Unified CM クラスタの DNS ドメインと異なる場合、無効な ACL エントリが生成されることで問題が発生する可能性があります。
（注） 単一の Unified CM クラスタがサポートするのは、1 つの IM and Presence サービス クラスタのみであるため、Unified CM クラスタごとに、別々の IM and Presence サービス クラスタが必要です。
クラスタ内トラフィックは、Cisco IM and Presence サービスと Unified CM の間、および Cisco IM and Presence サービス パブリッシャとサブスクライバ サーバの間に非常に低いレベルで加わります。両方のクラスタは、共通のホスト ファイルを共有し、IPTables を使用した強力な信頼関係を備えています。データベースとサービスのレベルでは別個の異なるクラスタですが、設定と管理は主に Unified CM クラスタで行われ、制限付きの設定と管理は IM and Presence サービス クラスタで行われます。現在、クラスタ内トラフィックには、トランスポート層セキュリティ（TLS）や IPSec は使用されていません。
Cisco IM and Presence サービス パブリッシャは、Simple Object Access Protocol（SOAP）インターフェイスを使用して、AVVID XML Layer Application Program Interface（AXL API）経由で Unified CM パブリッシャと直接通信します。最初の設定時に、Cisco IM and Presence サービス パブリッシャは、Unified CM ユーザおよびデバイス データベース全体の初期同期を実行します。すべての Cisco IM and Presence サービス ユーザは、Unified CM エンド ユーザ設定で設定されます。同期の際、Cisco IM and Presence サービスは、Unified CM データベースからこれらのユーザをそれ自体のデータベースに入力しますが、その管理インターフェイスからエンドユーザ設定を提供することはありません。同期後、Cisco IM and Presence サービスでユーザを管理するには、Cisco Unified Communications Manager の管理者インターフェイスを介して IM and Presence サービスに対してユーザを有効にする必要があります。
（注） Cisco IM and Presence サービスは、最大 160,000 ユーザの同期をサポートします（Unified CM と同等）。ただし、Cisco IM and Presence サービス クラスタに対してライセンスされたプレゼンス ユーザの最大数は、メガクラスタ配置で 3 つのサブクラスタ ペアに 25,000 ユーザ IM and Presence VM テンプレートを使用した場合は 75,000 です。
Unified CM から最初に Cisco IM and Presence サービス データベースを同期する場合、少し時間がかかることがあります。所要時間は、データベース内の情報量と現在システムにかかっている負荷によって異なります。それ以降は、新しいユーザ情報やデバイス情報が Unified CM に追加されたときに、Unified CM から Cisco IM and Presence サービスへのデータベースの同期がリアルタイムで実行されます。
（注） Cisco IM and Presence サービスによる Unified CM からの初期データベース同期の際、同期エージェントがアクティブな間は、管理作業を一切行わないでください。
オンプレミスの Cisco IM and Presence サービスのハイ アベイラビリティ
Cisco IM and Presence サービス クラスタは、最大 6 台のサーバで構成されていますが、これを複数のサブクラスタ（最大 3 つのサブクラスタ）に構成してハイ アベイラビリティを実現できます。サブクラスタには最大 2 台のサーバが含まれ、フェールオーバー イベントの発生時には、サブクラスタの片方のサーバに関連付けられたユーザが、自動的にサブクラスタの他方のサーバを使用できるようになります。Cisco IM and Presence サービスはサブクラスタ間のフェールオーバー機能を提供しません。
Cisco IM and Presence サービス クラスタをハイ アベイラビリティを確保して配置する場合、フェールオーバーの発生時にサブクラスタ内の 1 台のサーバに対してオーバーサブスクリプションにならないよう、サーバあたりの最大ユーザ数を考慮する必要があります。
アクティブ/アクティブとアクティブ/スタンバイの 2 種類の異なる設定を使用することで、ハイ アベイラビリティを実現できます。平衡型モードでは、連動するようにプレゼンス冗長グループ内のノードを設定できます。コンポーネントの障害や停電により、いずれかのノードが停止すると、ユーザのロード バランシングとユーザのフェールオーバーが自動的に有効になり、冗長ハイ アベイラビリティが提供されます。アクティブ/スタンバイの設定では、アクティブ ノードが停止すると、スタンバイ ノードはアクティブ ノードを自動的に引き継ぎます。
IM and Presence サービス クラスタは、25,000 ユーザ VM 設定テンプレートで 3 つの IM and Presence ノードを配置した場合、フル UC モードで最大 75,000 ユーザをサポートします。ただしハイ アベイラビリティは確保されません。
75,000 ユーザのハイ アベイラビリティ配置では、3 つの IM and Presence サブクラスタ ペアを 25,000 ユーザ VM 設定テンプレート オプションで配置する必要があります。
（注） 25,000 ユーザ VM 設定は、事前にシスコによって確認および承認されたメガクラスタ配置に使用する必要があります。メガクラスタ配置以外の場合は、15,000 ユーザまたは 5,000 ユーザ VM 設定テンプレートなど、キャパシティの少ない VM 設定テンプレートを使用してください。ただし、メガクラスタ以外の配置でも 25,000 ユーザ IM and Presence VM 設定の使用が望ましい場合は、25,000 ユーザ VM 設定を配置する前に、シスコに設計トポロジを伝えて承認を要求してください。25,000 ユーザ VM テンプレートを使用した IM and Presence 設定の設計を確認した上で、例外が提供される場合があります。
オンプレミスの Cisco IM and Presence サービス配置モデル
Cisco IM and Presence サービスは、すべての Unified CM 配置モデルでサポートされます。ただし、初期ユーザ データベース同期のために、Cisco IM and Presence サービス パブリッシャを Unified CM パブリッシャと同じ物理データセンターに共存させることを推奨します。すべてのオンプレミスの Cisco IM and Presence サーバは、地理的なデータセンターの冗長性および WAN を介したクラスタリングを除き、物理的に Cisco IM and Presence サービス クラスタ内の同じデータセンターに配置する必要があります（詳細については、WAN を介したクラスタリングを参照してください）。
Unified CM の配置モデルの詳細については、コラボレーションの配置モデルの章を参照してください。
Cisco IM and Presence サービスの配置は、ハイ アベイラビリティの要件、合計ユーザ数、および使用するサーバに依存します。詳細な設定および配置の手順については、次の Web サイトで入手可能な『 Deployment Guide for Cisco IM and Presence 』を参照してください。
https://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html
可用性が高い Cisco IM and Presence サービス クラスタには、サブクラスタごとに 2 台のサーバが必要です。これにより、ユーザはサブクラスタ内のサーバ間でフェールオーバーを実行できますが、サポートされる合計ユーザ数とフェールオーバー時間は、有効にする機能、連絡先リストの平均サイズ、サーバ上のトラフィック レート、およびサーバの配置（WAN を介した配置の場合）によって異なります。Cisco IM and Presence サービスのサブクラスタに 2 台のサーバを設定すると、Unified CM 管理の [システム（System）] > [プレゼンス冗長グループ（Presence Redundancy Group）] で [ハイアベイラビリティ（High Availability）] が設定されている場合、常にハイ アベイラビリティとして動作します。ハイ アベイラビリティは、アクティブ/スタンバイ モデルまたはアクティブ/アクティブ モデルを使用して配置できます。これらのモードは、エンタープライズ パラメータの [プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] によって制御されます。デフォルトで、すべてのユーザはクラスタ内のすべてのサーバに均等に割り当てられます。このパラメータはデフォルト値のままにすることを推奨します。
Cisco IM and Presence アクティブ/スタンバイ モード （[プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を [なし（None）] に設定）は、手動でユーザをサブクラスタの最初のサーバに割り当て、2 番目のサーバにユーザを 1 人も割り当てずにすべての処理を同期させ、サブクラスタの最初のサーバに障害が発生した場合のフェールオーバーに備えることで実現されます。たとえば、図 20-9 では、最初のユーザをサーバ 1A、2 番めのユーザをサーバ 2A、3 番めのユーザをサーバ 3A、4 番めのユーザをサーバ 1A、5 番めのユーザをサーバ 2A、6 番めのユーザをサーバ 3A、というように割り当てています。これにより、ユーザは、クラスタのすべての「A」サーバに均等に割り当てられます。
Cisco IM and Presence アクティブ/アクティブ モード （[プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を [平衡化（balanced）] に設定）は、デフォルト設定であり、負荷分散の目的で推奨されます。このモードでは自動的にユーザがサブクラスタ内のすべてのサーバに均等に割り当てられます。各サーバは同期され、サブクラスタ内の他のサーバの障害時には、フェールオーバーが可能です。たとえば、図 20-9 では、最初のユーザをサーバ 1A、2 番目のユーザをサーバ 2A、3 番目のユーザをサーバ 3A、4 番目のユーザをサーバ 1B、5 番目のユーザをサーバ 2B、6 番目のユーザをサーバ 3B、というように割り当てます。ユーザは、クラスタ内のすべてのサーバに均等に割り当てられます。
[プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を [平衡化（balanced）] に設定した Cisco IM and Presence アクティブ/アクティブ 配置では、使用する機能、ユーザの連絡先リストのサイズ、および生成されるトラフィック（ユーザ データ プロファイル）に応じた柔軟な冗長構成が可能です。完全な冗長性モードの Cisco IM and Presence アクティブ/アクティブ配置では、機能に関係なく、サポートされる合計ユーザ数を半分にする必要があります（たとえば、15,000 ユーザ OVA をバランス型のハイ アベイラビリティ冗長構成で配置する場合、1 つのサブクラスタでサポートされるユーザ数は、最大 15,000 人になります）。非冗長モードの Cisco IM and Presence アクティブ/アクティブ配置では、使用する Cisco IM and Presence サービスの機能、ユーザの連絡先リストの平均サイズ、および生成されるトラフィックをさらに詳細に検討する必要があります。たとえば、プレゼンスとインスタント メッセージングを有効にし、カレンダーとモビリティ統合を無効にした配置で、連絡先リストが平均 30 ユーザ、ユーザ データ プロファイルが少数のプレゼンスとインスタント メッセージングの更新の場合、サブクラスタあたり 15,000 人を超えるユーザをサポートできます。
ハイ アベイラビリティ構成でない Cisco IM and Presence サービス クラスタ配置の場合、サブクラスタの各サーバは、そのサーバの最大ユーザ数までサポートできます。また、クラスタ内のすべてのサーバに対してサポートされる合計ユーザ数は、IM and Presence サービス クラスタの最大ユーザ数まで許容されます。サブクラスタに 2 台目のサーバを追加した後でも、サブクラスタはハイ アベイラビリティ配置と同様に動作しますが、オンライン サーバがキャパシティの上限（有効な Cisco IM and Presence サービス機能、ユーザの連絡先リストの平均サイズ、およびユーザによって生成されるトラフィック量に基づく）に達すると、サーバに障害が発生した場合にフェールオーバーが成功しないことがあります。
オンプレミスの Cisco IM and Presence サービスの配置例
例 20-1 単一の Unified CM クラスタで Cisco IM and Presence サービスを配置
- 4,000 ユーザを最大 13,000 ユーザまで拡張可能
- 単一の Cisco Unified Communications Manager クラスタ
- インスタント メッセージのロギングおよびコンプライアンスへの準拠が不要
- ハイ アベイラビリティが不要
- 1 つのシングルサーバのサブクラスタ（[平衡化（balanced）] に設定した [プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を使用）
例 20-2 2 つの Unified CM クラスタで Cisco IM and Presence サービスを配置
- 11,000 ユーザを最大 24,000 ユーザまで拡張可能
- 2 つの Cisco Unified Communications Manager クラスタ
- インスタント メッセージのロギングおよびコンプライアンスへの準拠が不要
- ハイ アベイラビリティが不要
- 2 つの Cisco IM and Presence サービス クラスタ（Cisco Unified Communications Manager クラスタごとに 1 つ）で各クラスタに 1 つのサーバ（[平衡化（balanced）] に設定した [プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を使用）
例 20-3 単一の Unified CM クラスタで Cisco IM and Presence サービスを配置
- 500 ユーザを最大 2500 ユーザまで拡張可能
- 単一の Cisco Unified Communications Manager クラスタ
- インスタント メッセージのアーカイブが必要
- ハイ アベイラビリティが必要
- 2 台のサーバから構成される 1 つのサブクラスタ（[平衡化（balanced）] に設定した [プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を使用）、およびクラスタ用の PostgreSQL、Microsoft SQL、または Oracle データベース インスタンス
例 20-4 単一の Cisco Business Edition クラスタで Cisco IM and Presence サービスを配置
- 2 台のサーバから構成される 1 つのサブクラスタ（[平衡化（balanced）] に設定した [プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] を使用）、およびクラスタ内のサーバごとに固有の PostgreSQL、Microsoft SQL、または Oracle データベース インスタンス（永続的なチャット機能用）
例 20-5 メガクラスタで Cisco IM and Presence サービスを配置
これは、40,000 を超えるユーザやデバイスの配置が必要な場合のメガクラスタ配置の構成例です。
（注） Unified CM サブスクライバ ペアが 5 つ以上必要なすべての配置は、配置前にシスコのメガクラスタ チームによって確認および承認される必要があります。メガクラスタの承認および確認プロセスの詳細については、https://wiki.cisco.com/display/CCM/Megacluster にある情報を参照してください。
- 25,000 ユーザ IM and Presence VM 設定テンプレートを使用する 6 個のノード
- ハイ アベイラビリティ モードで 3 つのサブクラスタ サブスクライバ ペアとして分散されるノード
- 10,000 ユーザ Unified CM VM 設定テンプレートを使用する 19 個のノード
- 専用パブリッシャで配置される Unified CM
- 専用 TFTP1 サーバおよびバックアップ TFTP2 サーバ
- 8 個のサブスクライバ ペア仮想ノード
- インスタント メッセージのコンプライアンス準拠が必要
- ハイ アベイラビリティが必要
例 20-6 単一の UCS B シリーズ サーバ上で複数の Unified CM クラスタに Cisco IM and Presence サービスを配置
オンプレミスの Cisco IM and Presence サービスのパフォーマンス
Cisco IM and Presence サービス クラスタは、シングルサーバとマルチサーバの両方の構成をサポートします。Cisco IM and Presence サービス クラスタによってサポートされる最大ユーザ数は、配置で使用されるプラットフォームによって異なります。たとえば、それぞれが独自のサブクラスタを構成する 3 つの 2,000 ユーザ VM 設定テンプレートで Cisco IM and Presence サービス クラスタを配置すると、合計 6,000 ユーザがサポートされます。Cisco IM and Presence サービス クラスタでサポートされるフル UC ユーザの最大数は 75,000 であり、クラスタ配置でサポートされるデバイスの最大数を超えることはありません。サポートされる IM 専用ユーザの最大数は 75,000 です。Cisco IM and Presence サービスのプラットフォーム要件、およびプラットフォームごとにサポートされる最大ユーザ数の詳細リストについては、次の Web サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-ucm-im-presence.html
Cisco IM and Presence サービスは仮想サーバ上で VM 設定テンプレートのみを使用した配置をサポートします。Cisco IM and Presence サービスでは物理サーバはサポートされません。
クラスタ内のすべての IM and Presence ノードに同一の VM 設定を使用することを推奨します。ただし、IM and Presence パブリッシャ ノードに使用される VM 設定が、同じクラスタ内のいずれかのサブスクライバ ノードに使用される VM 設定のキャパシティ以上であれば、キャパシティが異なる VM 設定をクラスタ内に混在させることができます。
同様のガイドラインが冗長性およびハイ アベイラビリティ モデルにも適用されます。クラスタ内の IM and Presence のスタンバイ/バックアップ仮想サブスクライバ ノードで使用する VM 設定は、IM and Presence パブリッシャまたはそれぞれのアクティブ/プライマリ サブスクライバの VM 設定以下である必要があります。
同じ IM and Presence クラスタ内に VM 設定を混在させる場合は、使用される各種 VM 設定によってパフォーマンスとキャパシティに影響が出る可能性があることを考慮してください。クラスタ全体のキャパシティは、最終的にクラスタ内の最小 VM 設定のキャパシティによって決まる場合があります。
（注） IM and Presence と Unified CM を統合してもこれらが同じクラスタに属することはなく、2 つの別のクラスタに属します。
オンプレミスの Cisco IM and Presence サービス配置
シングルクラスタ配置
図 20-11 に、Cisco IM and Presence サービス、LDAP サーバ、および Cisco Unified Communications Manager 間で基本的な機能に使用される通信プロトコルを示します。Cisco IM and Presence サービスの管理と設定の詳細については、次の Web サイトで入手可能な Cisco IM and Presence のインストール、管理、および設定に関するマニュアルを参照してください。
https://www.cisco.com/en/US/products/ps6837/tsd_products_support_series_home.html
図 20-11 Cisco IM and Presence サービス コンポーネント間の相互作用
図 20-11 に、Cisco IM and Presence サービス コンポーネント間の次の相互作用を示します。
1. Cisco IM and Presence サービスと Unified CM 間の SIP 接続は、すべての電話機の状態のプレゼンス情報交換を処理します。
Unified CM の設定では、Cisco IM and Presence サービスをアプリケーション サーバとして Unified CM に追加する必要があります。また Cisco IM and Presence サービスを指す SIP トランクが必要です。SIP トランクに設定するアドレスは、Cisco IM and Presence サービスに対して解決されるドメイン ネーム システム（DNS）サーバ（SRV）の完全修飾ドメイン名（FQDN）、または個別の Cisco IM and Presence サービスの IP アドレスです。Cisco IM and Presence サービスは、管理者が Cisco IM and Presence サービスの管理によってシステム トポロジ ページでノードを追加すると、Cisco Unified Communications Manager アプリケーション サーバ エントリの設定を AXL/SOAP で自動的に処理します。
ネットワーク内の DNS の可用性が非常に高く、DNS SRV の利用が可能な場合、Cisco IM and Presence サービス パブリッシャとサブスクライバの DNS SRV FQDN を使用して、Unified CM 上に SIP トランクを設定します。また、Unified CM サブスクライバの DNS SRV FQDN を同等の重み付けで使用し、Cisco IM and Presence サービス上にプレゼンス ゲートウェイを設定します。この設定により、プレゼンス情報の交換に使用するすべてのサーバ間でプレゼンス メッセージングが均等に振り分けられます。
DNS がハイ アベイラビリティでない場合、またはネットワーク内で信頼できるオプションでない場合は、IP アドレスを使用する。IP アドレスを使用すると、単一のサブスクライバが指されるので、プレゼンス メッセージング トラフィックを複数の Unified CM サブスクライバ間で均等に振り分けることはできません。
Unified CM では、PUBLISH メソッド（SUBSCRIBE/NOTIFY ではなく）を設定し、Cisco IM and Presence サービスへの SIP トランク インターフェイス上で使用できるようにする IMP PUBLISH Trunk というサービス パラメータによって、通信をさらに簡素化し、使用帯域幅を削減します。IMP PUBLISH Trunk サービス パラメータを有効にした場合、ユーザをプライマリ内線だけでなく、ライン アピアランスと関連付ける必要があります。
2. Cisco IM and Presence サービスと Unified CM との間のコンピュータ テレフォニー インテグレーション Quick Buffer Encoding（CTI-QBE）接続は、Cisco IM and Presence サービスのプレゼンス対応ユーザが、Unified CM に登録済みの各自に関連付けられた電話機を制御するために使用するプロトコルです。この CTI 通信は、Cisco Jabber が Desk Phone モードで Click to Call を行う場合、または Microsoft Office Communicator が Microsoft Office Communications Server 2007 または Microsoft Lync によって Click to Call を行う場合に実行されます。
a. Unified CM の設定では、ユーザを CTI Enabled グループに関連付け、そのユーザに割り当てられたプライマリ内線で CTI 制御を有効にする必要があります（[Directory Number] ページのチェックボックス）。また CTI Manager サービスも、Cisco IM and Presence サービス パブリッシャおよびサブスクライバとの通信に使用される各 Unified CM サブスクライバ上でアクティブにする必要があります。Microsoft Office Communications Server 2007 または Microsoft Lync との統合では、Unified CM で、CTI Enabled グループと役割を使用して、アプリケーション ユーザを設定する必要があります。
b. Cisco Jabber と連携して使用するための Cisco IM and Presence サービスの CTI 設定（CTI サーバおよびプロファイル）は、Unified CM とのデータベースの同期時に自動的に作成されます。すべての Cisco Jabber CTI 通信は、Cisco IM and Presence サービスを介さずに、直接 Unified CM と実行されます。
Microsoft Office Communications Server 2007 または Microsoft Lync と連携して使用するための Cisco IM and Presence サービスの CTI 設定（Desktop Control Gateway）では、Desktop Control Gateway のアドレス（Cisco Unified Communications Manager のアドレス）とプロバイダー（Unified CM で以前に設定されたアプリケーション ユーザ）を設定する必要があります。スケーラビリティを拡大させるため、最大 8 個の Cisco Unified Communications Manager アドレスをプロビジョンできます。Cisco IM and Presence サービスの Desktop Control Gateway の設定で使用できるのは、IP アドレスのみです。管理者は、Cisco Unified Communications Manager アドレスの設定および割り当てが、ロード バランシングのために均等に分散されるようにする必要があります。
3. AXL/SOAP インターフェイスは、Unified CM からのデータベースの同期を処理して、Cisco IM and Presence サービス データベースにデータを入力します。
a. Unified CM では、その他の設定は必要ありません。
b. Cisco IM and Presence サービスのセキュリティ設定では、AXL 設定内の Unified CM AXL アカウントのユーザとパスワードを設定する必要があります。
Sync Agent サービス パラメータである [ユーザ割り当て（User Assignment）] は、デフォルトで [平衡化（balanced）] に設定され、すべてのユーザが Cisco IM and Presence サービス クラスタ内のすべてのサーバに均等にロードバランスされます。管理者は、[ユーザ割り当て（User Assignment）] サービス パラメータを [なし（None）] に変更して、Cisco IM and Presence サービス クラスタ内の特定のサーバに手動でユーザを割り当てることができます。
4. LDAP インターフェイスは、ユーザの LDAP 認証に使用されます。LDAP 同期と認証の詳細については、ディレクトリ統合とアイデンティティ管理の章を参照してください。
Unified CM は、手動設定または LDAP からの直接同期によるすべてのユーザ エントリを処理し、Cisco IM and Presence サービスは Unified CM からすべてのユーザ情報を同期します。ユーザが Cisco IM and Presence サービスにログインし、LDAP 認証が Unified CM で有効になっている場合、Cisco IM and Presence サービスは LDAP に直接アクセスし、Bind 操作を使用してユーザを認証します。
Microsoft Active Directory を使用する場合は、パラメータの選択を慎重に考慮してください。大規模な Active Directory 実装が存在し、設定でドメイン コントローラが使用されている場合、Cisco IM and Presence サービスで十分なパフォーマンスが得られないことがあります。Active Directory の応答時間を改善するために、場合によっては、ドメイン コントローラをグローバル カタログに追加し、LDAP ポートを 3268 に設定する必要があります。
クラスタ間展開
前の項までは、単一の Cisco IM and Presence サービス クラスタが、単一の Unified CM クラスタと通信する配置トポロジについて説明しました。しかし単一のクラスタ内だけの通信では、プレゼンスやインスタント メッセージングの機能には限りがあります。そこで、プレゼンスとインスタント メッセージングの能力と機能を拡張できるよう、これらのスタンドアロンのクラスタにピア関係を設定することで、同じドメイン内の複数のクラスタ間で通信できるようになります。この機能により、1 つのクラスタ内のユーザが、同じドメイン内の異なるクラスタにいるユーザと通信したり、プレゼンスをサブスクライブしたりできます。
フルメッシュのプレゼンス トポロジを作成するには、それぞれの Cisco IM and Presence サービス クラスタと、同じドメイン内の他のそれぞれの Cisco IM and Presence サービス クラスタとの間に、個別のピア関係が設定されている必要があります。このクラスタ間ピアに設定されているアドレスは、リモートの Cisco IM and Presence サービス クラスタ サーバに対して解決される DNS FQDN、または単純に Cisco IM and Presence サービス クラスタ サーバの IP アドレスです。
各 Cisco IM and Presence サービス クラスタ間のインターフェイスには、AXL/SOAP インターフェイスとシグナリング プロトコル インターフェイス（SIP または XMPP）の 2 つが使用されます。IM and Presence サービス クラスタのパブリッシャ専用サーバ間の AXL/SOAP インターフェイスはホーム クラスタ アソシエーション用にユーザ情報の同期を処理しますが、これは完全なユーザ同期ではありません。シグナリング プロトコル インターフェイス（SIP または XMPP）は、配置内のすべてのサーバ間でフルメッシュです。これは、サブスクリプション トラフィックと通知トラフィックを処理し、同じドメイン内のリモートの Cisco IM and Presence サービス クラスタでユーザが検出されると、URI のホスト部分を書き換えてから転送します。
WAN を介したクラスタリング
Cisco IM and Presence サービス クラスタは、ワイド エリア ネットワーク（WAN）を介して配置されたサブクラスタのノードの 1 つを使用して配置できます。これにより、サイトをまたがるノード間でサブクラスタの地理的冗長性とユーザのハイ アベイラビリティが実現します。次のガイドラインは、Cisco IM and Presence サービスの配置と WAN を介したクラスタリングの計画時に使用する必要があります。
Cisco IM and Presence サービス クラスタは、単一サブクラスタ トポロジで 2 つのサイト間に配置できます。このトポロジでは、サブクラスタの一方のサーバが 1 つの地理的サイトに置かれ、サブクラスタの他方のサーバが別のサイトに置かれます。この配置では、5 Mbps 以上の帯域幅を確保し、遅延を 80 ms ラウンド トリップ時間（RTT）以下に抑え、TCP によるメソッド イベント ルーティングを行う必要があります（図 20-12 を参照）。
Cisco IM and Presence サービスのハイ アベイラビリティにより、サブクラスタ内の 1 つのノードのユーザは、サブクラスタ内の別のノードに自動的にフェールオーバーされます。最大 2 つのノードで構成される Cisco IM and Presence サービス サブクラスタでは、リモート フェールオーバーは基本的に 2 つのサイト間（各ノードに 1 つのサイト）で行われます。スケーラブルなハイ アベイラビリティの Cisco IM and Presence サービス クラスタでは、最大 3 つのサブクラスタを構成できます。したがって、スケーラブルなハイ アベイラビリティのリモート フェールオーバー トポロジは、次のような 2 つのサイトで構成されます。
- サイト A：サブクラスタ 1 ノード A、サブクラスタ 2 ノード A、およびサブクラスタ 3 ノード A
- サイト B：サブクラスタ 1 ノード B、サブクラスタ 2 ノード B、およびサブクラスタ 3 ノード B
この配置では、1 つのサブクラスタごとに 5 Mbps 以上の帯域幅を確保し、遅延を 80 ms ラウンド トリップ時間（RTT）以下に抑え、TCP によるメソッド イベント ルーティングを行う必要があります。この配置に追加される新しい各サブクラスタには、データベースと状態の複製を処理するために、さらに 5 Mbps の専用帯域幅が必要です。
スプリット サブクラスタ モデルでは、サブクラスタ ペアが WAN を介して分割され、2 つの別々の場所に配置されます。スプリット サブクラスタ モデルは、6 箇所に別々に配置された最大 6 つのノードをサポートします。これは、帯域幅と遅延の要件が満たされ、最大ラウンドトリップ時間（RTT）が 80 ms で 6 つの各ノードの帯域幅が 5 Mbps であると想定した場合です。
- Unified CM パブリッシャおよび IM and Presence パブリッシャは、同じ WAN 側に存在する必要があります。この要件が満たされないと、アップグレード（特に更新（デュアル）アップグレード）で問題が発生する可能性があります。
- すべての IM and Presence ノードには 5 Mbps 以上の帯域幅が必要であり、データベースの同期用にクラスタにはさらに 5 Mbps が必要です。
- 各 IM and Presence ノードの RTT 遅延は 80 ms 以下である必要があります。
- すべてのユーザをすべてのスプリット クラスタ ノードに均等に分散する必要があります（図 20-13 を参照）。たとえば、サブクラスタが 15,000 ユーザをサポートすると想定した場合、スプリット サブクラスタの各ノードは 15,000 ユーザ VM 設定テンプレートで 7,500 をサポートします。
図 20-13 WAN を介して分割された IM and Presence サブクラスタ
2 つのサイト間の Cisco IM and Presence サービス クラスタ配置では、1 つのサイトごとに 1 つのサブクラスタ トポロジ（単一ノードまたはハイ アベイラビリティ構成のデュアル ノード）を構成することもできます。この場合、一方のサブクラスタを 1 つの地理的サイトに置き、他方のサブクラスタを別の地理的サイトに置きます。このトポロジにより、ユーザは、異なるサイトまたは場所にフェールオーバーせずに、（ハイ アベイラビリティまたはハイ アベイラビリティでない）ローカル サイトに残ることができます。この配置では、それぞれのサイトの各サブクラスタ間に 5 Mbps 以上の専用帯域幅を確保し、遅延を 80 ms ラウンドトリップ時間（RTT）以下に抑え、TCP によるメソッド イベント ルーティングを行う必要があります。
WAN を介してノードが分割されたトポロジを持つ Cisco IM and Presence サービス クラスタでは、ユーザのクライアント内の連絡先数が、帯域幅の要件や配置の基準に影響を及ぼす可能性があります。Cisco IM and Presence サービスのクラスタ内およびクラスタ間で生成されるトラフィックは、プレゼンス ユーザ プロファイルの特性や配置に必要な帯域幅に直接関係します。帯域幅が小さい（10 Mbps 以下）環境のクライアントでは、リモート連絡先を 25 % 以下にすることを推奨します。最大ラウンドトリップ遅延は、常に 80 ms 以下にする必要があります。
永続的なチャットとコンプライアンス ロギングに関する考慮事項
Cisco IM and Presence サービスが永続的なチャット、メッセージ アーカイブ、またはコンプライアンス ロギングに対して有効になっており、サブクラスタが WAN を介して分割されている場合は、外部データベース サーバをそれが関連付けられた Cisco IM and Presence サービス サブスクライバ ノードと同じ WAN 側に配置することをお勧めします。
単一サーバで複数のデータベース インスタンスをサポートできる能力と外部データベース サーバを関連する IM and Presence ノードと同じ WAN 側に配置するという推奨事項を考慮して、Cisco IM and Presence サービス クラスタが WAN を介して分割されている場合は、ベスト プラクティスとして 2 つの外部データベース サーバの展開をお勧めします。
（注） これは、同じデータセンター内に配置する外部データベース サーバと関連する IM and Presence ノードに対する要件ではありません。ただし、外部データベース サーバと IM and Presence サブスクライバ ノード間の最大サポート遅延は 60 ms ラウンド トリップ時間（各方向に 30 ms）を超えないようにする必要があり、最小帯域幅割り当ては Cisco IM and Presence サービスに関する WAN 経由のクラスタリング要件を満たしている必要があります。また、常設チャット ルームあたりのインスタント メッセージの平均数は 1 時間あたり 25 件を超えないようにする必要があります。（図 20-14 を参照）。
図 20-14 WAN 経由の外部データベースを使用した永続的なチャット
（注） WAN 経由で外部データベースを展開する場合や高可用性が必要な場合は Oracle Database 12c を使用することをお勧めします。
集中型 IM and Presence は、複数のリモート Cisco Unified CM の音声クラスタとビデオ クラスタにプレゼンス サービスを提供できます。集中型導入では、IM and Presence サービスがリモート Unified CM クラスタ上のすべてのユーザに対するすべてのプレゼンス関連サービスを管理し、各リモート Unified CM クラスタが個別のユーザの音声とビデオのニーズを処理します。
集中型 IM and Presence モデルは、複数の場所に Unified CM クラスタを分散させるため、すべての場所に IM and Presence クラスタを展開する必要のない大企業向けのオプションを提供します。つまり、1 つの集中型 IM and Presence クラスタがあれば、複数のリモート Unified CM クラスタに対するプレゼンス サービスを賄うことができます。
場所の数は多いものの、それぞれの場所のユーザ数は非常に少ない導入では、このモデルから多くの恩恵を受けることができます。たとえば、ある病院が 50 か所にいる 100 人ずつのユーザに音声、ビデオ、プレゼンス サービスを提供しているとします。この場合は、Unified CM の 50 クラスタと IM and Presence の 50 クラスタを展開するのは現実的ではありません。それよりも、1 つの集中型 IM and Presence クラスタで 50 台のリモート Unified CM クラスタを制御する方が効率的で簡単ですし、仮想サーバを減らすことでコストを大幅に削減できます。
集中型 IM and Presence クラスタは、15k/25k ユーザ IM and Presence VM テンプレートを使用して展開する必要があります。集中型クラスタ用の Unified CM パブリッシャは、10k ユーザ Unified CM VM テンプレートを使用して展開する必要があります。（図 20-15 を参照）。
（注） 40,000 台を超えるクライアントまたはデバイスを展開する場合の集中型導入設計は、シスコのメガクラスタ レビュー プロセスを通して審査および承認される必要があります。
集中型 IM and Presence 導入の詳細については、次の場所にある『 Configuration and Administration of IM and Presence Service on Cisco Unified Communications Manager 』に関するガイドの最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
図 20-15 集中型 IM and Presence の導入
図 20-16 に、シングル サインオン（SSO）を使用しない場合の集中型 IM and Presence の次のログイン フロー ステップを示します。
- ステップ 1 ～ 2：DNS に問い合わせて、SRV レコードを取得します。
- ステップ 3 ～ 4：UDS に問い合わせて、ホーム Unified CM クラスタを取得します。
- ステップ 5 ～ 8：LDAP 認証を介して Unified CM クラスタからアクセス トークンとリフレッシュ トークンを取得します。
- ステップ 9：[UC サービス プロファイル（UC Service Profile）] -> [IM and Presence プロファイル（IM & Presence Profile）] を読んで、IM and Presence ノード情報を入手します。
- ステップ 10：Jabber クライアントが SOAP インターフェイスと XMPP インターフェイスを介して同じアクセス トークンを使用して IM and Presence クラスタに登録します。
- ステップ 11：IP Multimedia Subsystem（IMS）API が AuthZ サービスを呼び出してトークンを検証し、その応答が Jabber クライアントに送り返されます。
（注） リモート Cisco Unified CM クラスタ上のサービス パラメータ [Unified CM IM and Presence でのユーザの有効化（Enable User for Unified CM IM and Presence）] は無効（オフ）にする必要があります。
図 20-16 シングル サインオン（SSO）を使用しない集中型 IM and Presence ログイン フロー
図 20-17 に、シングル サインオン（SSO）を使用する場合の集中型 IM and Presence の次のログイン フロー ステップを示します。
- ステップ 1 ～ 2：DNS に問い合わせて、SRV レコードを取得します。
- ステップ 3 ～ 4：UDS に問い合わせて、ホーム Unified CM クラスタを取得します。
- ステップ 5 ～ 8：ID プロバイダー（IDP）認証を介して Unified CM クラスタからアクセス トークンとリフレッシュ トークンを取得します。
- ステップ 9：[UC サービス プロファイル（UC Service Profile）] -> [IM and Presence プロファイル（IM & Presence Profile）] を読んで、IM and Presence ノード情報を入手します。
- ステップ 10：Jabber クライアントが SOAP インターフェイスと XMPP インターフェイスを介して同じアクセス トークンを使用して IM and Presence クラスタに登録します。
- ステップ 11：IP Multimedia Subsystem（IMS）API が AuthZ サービスを呼び出してトークンを検証し、その応答が Jabber クライアントに送り返されます。
（注） リモート Cisco Unified CM クラスタ上のサービス パラメータ [Unified CM IM and Presence でのユーザの有効化（Enable User for Unified CM IM and Presence）] は無効（オフ）にする必要があります。
図 20-17 シングル サインオン（SSO）を使用した集中型 IM and Presence ログイン フロー
図 20-18 集中型 IM and Presence のサポート ユーザの最大数
フェデレーション配置
Cisco IM and Presence サービスは企業間通信に対応するため、異なるドメイン間でプレゼンス情報やインスタント メッセージング通信を共有できるドメイン間フェデレーションを搭載しています。ドメイン間フェデレーションの構築には、明示的な DNS ドメインを設定し、さらに DMZ にセキュリティ アプライアンス（Cisco Adaptive Security Appliance）を置いて、フェデレーション接続を企業で終端させる必要があります。
マルチドメイン サポート
IM and Presence サービスでは、フェデレーションに複数のドメインを設定することができます。DirectoryURI を使用している場合、ドメインはシステムによって自動的に検出されます。または、管理者が手動でドメインを追加することもできます。フェデレーション配置に複数のドメインが含まれる場合、DNS SRV レコードを各電子メール ドメインに対してパブリッシュする必要があります。各 DNS SRV レコードは、XMPP フェデレーションがすべての XMPP フェデレーション ノードのリストで、SIP フェデレーションがルーティング IM and Presence ノードの Public FQDN である一連の結果と同一に解決される必要があります。
また、複数の電子メール ドメインを設定したフェデレーションでは、セキュリティ証明書 cup-xmpp（XMPP クライアントに提示される証明書）および cup-xmpp-s2s（フェデレーション システムに提示される証明書）の再生成が必要です。両方の証明書で、すべてのドメインを Subject Alt Name（SAN）のエントリとして含める必要があります。手動管理設定で、管理者はドメインを事前入力するオプションを使用できるため、新しいドメインが自動的に検出されるたびに証明書を再生成する必要はありません。
フェデレーション ドメインがすべて同じ信頼性境界内に存在する場合（配置では単一データセンター内にすべてのコンポーネントが含まれます）は、Adaptive Security Appliance を使用する必要がありません。ドメイン間フェデレーションの詳細については、次の Web サイトで入手可能な『 Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
図 20-19 に、ドメイン A とドメイン B という 2 つの異なるドメイン間の基本的なドメイン間フェデレーション配置を示します。DMZ の Adaptive Security Appliance（ASA）は社内への境界として使用されます。XMPP トラフィックはそのまま通過しますが、SIP トラフィックは検査されます。フェデレーションのすべての着信トラフィックは、フェデレーション ノードとして有効化された Cisco IM and Presence サービス経由でルーティングされ、内部ではユーザがいるクラスタの適切なサーバにルーティングされます。クラスタ間配置では、クラスタ間ピアはトラフィックをドメイン内の適切なホーム クラスタに伝達します。フェデレーションのすべての発信トラフィックは、XMPP フェデレーションが有効化された IM and Presence サービス クラスタ内の任意のノードを経由して外部に誘導されます。大企業での配置においては、複数のノードをフェデレーション ノードとして有効化できます。その場合、各要求は、DNS SRV ルックアップから返されるデータのラウンドロビン実装に基づいてルーティングされます。
図 20-19 IM and Presence サービス XMPP フェデレーション（ドメイン間）
（注） Cisco IM and Presence サービスでは、AOL ネットワーク（ホストされたネットワークとパブリック コミュニティの両方から構成されます）の各ドメインに対して SIP フェデレーション（ドメイン間と AOL）を設定する必要があります。ホストされた一意のドメインをそれぞれ設定する必要がありますが、AOL ネットワークではユーザを user@aol.com または user@aim.com と指定できるため、単一の aol.com パブリック コミュニティだけを指定する必要があります。
図 20-20 IM and Presence サービス SIP フェデレーション（ドメイン間）
表 20-2 に、Cisco IM and Presence サービスと Microsoft Lync Server との間のステータスのマッピングを示します。
|
|
|
|
|
|---|---|---|---|
（注） Cisco IM and Presence サービスは、他のドメインが、DNS SRV によって Cisco IM and Presence サービスを検出できるように、ドメインに関する DNS SRV レコードをパブリッシュする必要があります（SIP、XMPP、および各テキスト会議ノード）。Microsoft Lync Server 配置では、Cisco IM and Presence サービスが Access Edge サーバ上の Public IM Provider として設定されているので、このようなパブリッシュが必要です。Cisco IM and Presence サービスが DNS SRV を使用している Microsoft ドメインを検出できない場合、Cisco IM and Presence サービスで外部ドメインのスタティック ルートを設定する必要があります。
Cisco IM and Presence サービスの SIP フェデレーション配置は、Adaptive Security Appliance と Cisco IM and Presence サービス間にロード バランサを使用することで、冗長性のある構成にできます。または、冗長構成の Adaptive Security Appliance によって冗長性を実現することもできます。XMPP フェデレーションの場合は、DNS SRV レコードを使用して冗長性を実現できます。
フェデレーション配置に関するその他の設定および配置上の考慮事項については、次の Web サイトで入手可能な『 Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
図 20-21 に示すパーティション化されたドメイン内フェデレーション配置はセカンダリ オプションであり、これにより、Cisco IM and Presence サービスと Microsoft Lync Server は、同じプレゼンス ドメイン内でプレゼンスおよびインスタント メッセージングをフェデレーションできます。ユーザは、単一プレゼンス ドメイン内の両方の配置にわたってパーティション化され、Cisco IM and Presence サービスまたは Microsoft Lync Server のいずれかでライセンス供与されます。
（注） シスコ プラットフォームと Microsoft プラットフォームの両方で同時に特定のユーザへのライセンス供与を行うことはできません。
図 20-21 Cisco IM and Presence サービス ドメイン内フェデレーション
シスコ プラットフォームと Microsoft プラットフォーム間のパーティション化されたドメイン内フェデレーションは、SIP/SIMPLE プロトコルに基づいており、Microsoft の Cisco IM and Presence サービス ドメイン間フェデレーション サポートでサポートされているため、基本プレゼンスおよびインスタント メッセージング交換が可能になります。高度なプレゼンスおよびグループ チャット機能は、パーティション化されたドメイン内プレゼンス フェデレーションではサポートされていません。
ドメイン間フェデレーションおよびパーティション化されたドメイン内フェデレーションは、次の条件で同時にサポートされます。
- XMPP フェデレーションは Cisco IM and Presence サービス配置で有効化できますが、Cisco IM and Presence サービスのライセンスされたユーザのみが使用できます。
- SIP フェデレーションは Cisco IM and Presence サービス、Microsoft Office Communications Server 2007 R2、または Lync Server のいずれかで有効化することができます。ただし、シスコと Microsoft の両方のユーザが使用できる SIP フェデレーションの場合は、Microsoft Office Communications Server 2007 R2 または Lync Server で有効にする必要があります。
- Microsoft Lync または Office Communications Server との SIP/SIMPLE のドメイン間フェデレーションが、パーティション化されたドメイン内フェデレーションと並行して必要な場合は、外部フェデレーションを管理するように Microsoft Office Communications Server または Lync Server を設定することができます。Cisco IM and Presence サービス管理は、外部ドメインの Microsoft 環境へのスタティック ルートを使用して設定する必要があります。また、Cisco IM and Presence サービスは SIP フェデレーションを管理することができ、Microsoft Lync または Office Communications Server は XMPP フェデレーションを管理することができます。
オンプレミスの Cisco IM and Presence サービスの Jabber 用 SAML SSO
（注） SAML SSO 配置でサポートされるエンドポイントは Cisco Jabber です。
Security Assertion Markup Language シングル サインオン（SAML SSO）機能は、コラボレーション ソリューション内の複数のアプリケーションに何度もログインする必要をなくすことで、エンド ユーザ エクスペリエンスを向上させます。
SAML SSO は、Unified CM、Cisco Unity Connection、IM and Presence、Jabber クライアントなどの複数の Unified Communications アプリケーション間でエンド ユーザのクレデンシャルと関連情報を使用するセキュアなメカニズムを提供します。
SAML SSO 機能が正常に動作するよう、認証および各ユーザに関連する 2 台以上のデバイスを必要とする 5 つ以上のサービスを各ユーザが所有すると仮定して、各クラスタのユーザ数に合わせてネットワーク アーキテクチャが拡張されていることを確認します。複数の Unified Communications アプリケーション間の配置で、Cisco Jabber クライアントが正常にログインするには、すべての SAML 要求が IdP によって認証される必要があります。
（注） SSO は、SAML および OAuth のみを使用する Unified Communications サービスでサポートされます。
SAML SSO を使用する Cisco Jabber は、ログイン時にパフォーマンスに影響を及ぼします。5,000 ユーザの現在の最大ログイン レートは 30 分以内です。これは、デバイスとユーザがすべてのノードに均等に分散されていて、Cisco Jabber がソフトフォン モードである場合です。
Cisco Jabber は、SAML SSO をサポートする IM and Presence 配置で唯一サポートされているクライアント/エンドポイントです。
サイジング情報と例については、コラボレーション ソリューション サイジング ガイダンスの章の SAML SSO Cisco Jabber クライアントの項を参照してください。
オンプレミスの Cisco IM and Presence サービスの企業インスタント メッセージング
Cisco IM and Presence サービスには、Extensible Communications Platform（XCP）でサポートされている企業インスタント メッセージング機能が組み込まれています。また、マルチデバイス ユーザ エクスペリエンスのサポートを向上させるためにいくつかの変更を行うことができます。Cisco IM and Presence サービスでは、XCP インスタント メッセージング ルーティング アーキテクチャが変更され、最初のインスタント メッセージが、既存の XCP インストールで行われるように最も優先順位の高いデバイスにルーティングされるのではなく、ユーザの負ではない優先順位のすべてのログイン済みデバイスにルーティングされます。Cisco IM and Presence サービス SIP クライアントおよび XMPP クライアント間のポイントツーポイントのインスタント メッセージングの下位互換性サポートは、IM 内部ゲートウェイ機能によって提供されます。
IM and Presence サービスは、アドホック チャット ルームと永続的なチャット ルームの両方の IM 交換をサポートします。デフォルトで、IM and Presence サービスの Text Conference（TC）コンポーネントは、アドホック チャット ルームの IM 交換を処理するように設定されています。
アドホック チャット ルームは、1 人のユーザがチャット ルームに接続されている限り存続する IM セッションで、最後のユーザがルームを離れるとシステムから削除されます。IM 会話のレコードは永続的に維持されません。
永続的なチャット ルームは、すべてのユーザがルームを離れても存続するグループ チャット セッションで、アドホック グループ チャット セッションのように終了することはありません。その目的は、ユーザが後で永続的なチャット ルームに戻って、協力し特定のトピックに関する知識を共有したり、そのトピックに関する発言のアーカイブを検索したり、そのトピックのディスカッションに参加したりできるようにすることです。
永続的なチャットの場合、クラスタの各ノードに対する外部データベース インスタンスの 1：1 のマッピングが必要です。データベースのサイズを考慮する必要があります。メッセージのアーカイブはオプションであり、実行すると外部データベース インスタンスが接続されているノード上のトラフィックが増加します。大規模な配置では、ディスク領域がすぐにいっぱいになる可能性があるため、記録される情報量の処理に対してデータベースの大きさが十分であることを確認する必要があります。
Cisco IM and Presence サービスでは、外部データベースの基本的なインターフェイスが使用され、データベースの管理、インターフェイス フック、または設定は提供されません。Cisco IM and Presence サービスを永続的なグループ チャットとともに配置する場合は、クラスタ内の各サーバに個別のデータベース インスタンスが必要です（図 20-22 を参照）。データベース インスタンス間で同じハードウェアを共有することはできますが、必ずしも共有する必要はありません。
図 20-22 Cisco IM and Presence サービスの永続的なチャット
永続的なチャットが有効な場合は、外部データベースを Cisco XCP Text Conference Manager サービスに関連付ける必要があり、また、データベースがアクティブで到達可能である必要があります。そうでない場合は、Text Conference Manager は起動しません。Text Conference Manager サービスが起動した後で外部データベースとの接続が失敗した場合、Text Conference Manager サービスはアクティブなままで動作を継続します。ただし、メッセージはデータベースに書き込まれなくなり、接続が回復するまで新しい永続的なチャット ルームを作成できません。
永続的なチャットの配置に関する考慮事項
- 永続的なチャットはクラスタ内の 1 つ以上のノードに配置できます（図 20-23 を参照）。
- 永続的なチャットをサポートする各ノードは、専用のデータベース インスタンスに割り当てる必要があります。
- 外部データベース サーバは複数のインスタンスをサポートできます。
- 永続的なチャットはクラスタ全体の設定です。
- クラスタ内の少なくとも 1 つのノードを外部データベースに割り当てる必要があります。
- Cisco XCP Text Conference Manager サービスは、外部データベースに割り当てられていないノードでは動作しません。
- 純粋なインスタント（アドホック）会議には、外部データベースは必要ありません。
IM and Presence Service のチャット ルームの制限
IM and Presence サービスは、XMPP クライアント間のポイントツーポイント ファイル転送をサポートします。 表 20-3 に、IM and Presence サービスのチャット ルームの制限を示します。
|
|
|
|---|---|
デフォルトで表示されるチャット履歴のメッセージこれは、ユーザがチャット ルームに入室したときに表示されるメッセージの数です。 |
マルチユーザ チャットとも呼ばれるテキスト会議は、アドホック グループ チャットおよび永続的なグループ チャットとして定義され、XCP フィーチャ セットの一部としてサポートされます。また、オフライン インスタント メッセージング（現在オフラインであるユーザのためにインスタント メッセージを保存する機能）も XCP フィーチャ セットの一部としてサポートされます。Cisco IM and Presence サービスでは、これらの各インスタント メッセージング機能における保存は、異なる場所で処理されます。オフライン インスタント メッセージングは、Cisco IM and Presence サービス IDS データベースにローカルに保存されます。
アドホック グループ チャットは、Cisco IM and Presence サービスでメモリ内にローカルに保存されます。永続的なグループ チャットには、チャット ルームおよび会話を保存するための外部データベースが必要です。サポートされている外部データベースは、PostgreSQL（ https://www.postgresql.org/ を参照）、Microsoft SQL、および Oracle（ https://www.oracle.com を参照）です。
（注） シスコでは、データベースのベスト プラクティスおよびデータ抽出ツールを提供していません。これらのタスクとツールはデータベース管理者によって提供されることが予想されます。
（注） Oracle を外部データベースとして使用する場合は、テーブルスペースの情報を設定する必要があります。
マネージド ファイル転送
マネージド ファイル転送（MFT）を使用すると、Cisco Jabber などの IM and Presence サービス クライアントは他のユーザ、アドホック グループ チャット ルーム、および永続的なチャット ルームにファイルを転送できます。ファイルは外部ファイル サーバのリポジトリに保存され、トランザクションが外部データベースのログに記録されます。
この設定はファイル転送に固有な設定であり、法規制コンプライアンスのためのメッセージ アーカイバ機能には影響しません。
（注） IM and Presence ノードから外部の各サードパーティ データベースへの接続は 1 つしか存在しないため、MFT または永続的なチャットのハイ アベイラビリティ ソリューションはありません。
- Cisco IM and Presence サービス リリース 10.5(2) 以降
- PostgreSQL または Microsoft SQL
- Oracle バージョン 9i、10g、または 11g
- ファイル サーバ バージョン CentOS 6.5 以降
（注） Oracle Data Guard は、外部データベースとして使用できますが、シスコではテストされていません。
（注） 外部データベースとの暗号化接続が必要な場合は、Oracle 11g を使用してください。サポートされている他のデータベース バージョンでは、暗号化接続を確立できません。
Linux または Windows オペレーティング システムにデータベースをインストールできます。サポートされているオペレーティング システムとプラットフォーム要件の詳細については、PostgreSQL、Microsoft SQL、および Oracle のマニュアルを参照してください。
IPv4 と IPv6 はデュアルスタック モードのままでサポートされます。
1 人の受信者にファイルを転送するためのフローには、次の手順が含まれます。
1. 送信者のクライアントは HTTP 経由でファイルをアップロードし、サーバはファイルの URI を応答として返します。
2. ファイルは、ファイル サーバのリポジトリに格納されます。
3. 外部データベース ログ テーブルに、アップロードを記録する項目が書き込まれます。
4. 送信者のクライアントが受信者に IM を送信します。IM にはファイルの URI が含まれます。
5. 受信者のクライアントが HTTP 経由でファイルを要求します。
6. ファイルがリポジトリから読み取られます（取得されます）。
グループ チャットや永続的なチャット ルームにファイルを転送するためのフローもこれと類似していますが、異なる点として送信者はチャット ルームに IM を送信し、チャット ルームの各参加者は個別にファイル ダウンロード要求を送信します。
IM and Presence サービスでのマネージド ファイル転送
IM and Presence サービス ノードでマネージド ファイル転送を有効にする場合は、次の情報を考慮してください。
- IM and Presence サービス ノードに、永続的なグループ チャット機能、メッセージ アーカイバ機能、またはマネージド ファイル転送機能を組み合わせて配置する場合は、これらの機能すべてに、同一の物理外部データベース インストールとファイル サーバを割り当てることができます。ただし、サーバの容量を判断する際には、見込まれる IM トラフィックおよびファイル転送（サイズと数）を考慮する必要があります。
- ノードの公開キーはノードの割り当てが解除されると無効になります。後日ノードが再割り当てされると、新しいノード公開キーが自動的に再生成されます。外部ファイル サーバも再設定する必要があります。
- マネージド ファイル転送が必要な各ノードで、Cisco XCP File Transfer Manager サービスがアクティブである必要があります。
マネージド ファイル転送のキャパシティ
すべての Jabber ユーザが自由にファイル転送を使用できるため、ファイル転送の使用状況によってはシステムに影響する可能性があります。必要なキャパシティを効果的に計算するには、 表 20-4 を参照してください。
表 20-4 の値は、500 キロバイト（KB）の転送ファイル サイズに厳密に基づいています。これらの値を調整して異なるキャパシティを計算することができます。たとえば、次のシナリオはどれも 1 時間あたり 1,500 の転送に相当します。
- 1 時間に 1,500 人の各ユーザが 500 KB のファイル 1 個をダウンロードまたはアップロードする。
- 3,000 人の各ユーザが 1 時間に 250 KB のファイル 1 個を転送する。
- 750 人の Jabber ユーザが他の 750 人の Jabber ユーザに 500 KB のファイル 1 個を送信する。
サポートされる最大転送数は 500 KB のファイルで 12,000 です。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
[ファイル転送（File Transfer）] ウィンドウの [ファイル転送タイプ（File Transfer Type）] には次のコントロールがあります。
- [無効（Disabled）]：ファイル転送はクラスタに対して無効です。
- [ピアツーピア（Peer-to-Peer）]：1 対 1 のファイル転送は許可されますが、サーバではファイルのアーカイブや保存が行われません。グループ チャットのファイル転送はサポートされません。
マネージド ファイル転送と永続的なグループ チャットの両方で、IM and Presence クラスタ内の IM and Presence ノードごとに外部データベース インスタンスが必要です。
（注） マネージド ファイル転送が有効になっているノードを、ピアツーピアが有効になっているノードを含むクラスタに配置しないでください。推奨される移行パスは、ピアツーピア ノードをマネージドおよびピアツーピア ファイル転送ノードとして設定した後、それらのノードをマネージド ファイル転送ノードに変更することです。
オンプレミスの Cisco IM and Presence サービスのメッセージ アーカイブおよびコンプライアンス
アーキテクチャの一部として、Cisco IM and Presence サービスにはメッセージ アーカイバ コンポーネントが含まれています。このコンポーネントによって、非ブロッキング コンプライアンスの一部として、ポイントツーポイント メッセージ、テキスト会議メッセージ、フェデレーション メッセージ、およびクラスタ間メッセージを外部データベースにロギングできます。Cisco IM and Presence サービスのメッセージ アーカイブには、クラスタごとに外部データベース（PostgreSQL、Microsoft SQL、または Oracle）インスタンスが必要です。同じデータベースを複数のクラスタで共有できますが、クラスタ間ピア導入のユーザ数が多い場合は、容量の需要と大量のデータ挿入のためにさらに多くのデータベース インスタンスが必要になります。IM and Presence クラスタあたり 1 つの外部データベース インスタンスがサポートされますが、最低でもサブクラスタ ペアごとに 1 つの外部データベース インスタンスを配置することが推奨されます。
図 20-24 に示すように、メッセージのロギングだけでなく、メッセージ配信とメッセージ内容に対するポリシー適用も可能にする、ブロッキング サードパーティ コンプライアンス ソリューションは、サードパーティ コンプライアンス サーバ ソリューションを通して提供されます。Cisco IM and Presence サービスのサードパーティ製コンプライアンスは、クラスタ内の各サーバに複数のコンプライアンス サーバ、各コンプライアンス サーバに複数のサーバ、またはその他の組み合わせで展開できます。サードパーティ コンプライアンス ソリューションの使用は、メッセージ アーカイバ機能の使用と相互排他的です。
図 20-24 オンプレミス Cisco IM and Presence サービス：サードパーティ コンプライアンス
クラスタ内のすべての Cisco IM and Presence サービス サーバが、コンプライアンスの対象となります。図 20-25 は IM and Presence サービス クラスタ内の各サーバに対するコンプライアンス サーバの配置を示し、図 20-26 は、複数の IM and Presence サービス サーバへの単一のコンプライアンス サーバのマッピング、または単一の IM and Presence サービス サーバへの複数のコンプライアンス サーバのマッピングを示しています。さまざまな配置オプションによって、コンプライアンス ポリシー ルーティングとクラスタ配置の柔軟性が向上します。
図 20-25 Cisco IM and Presence サービスのサードパーティ コンプライアンス
図 20-26 完全なハイ アベイラビリティ クラスタ全体のコンプライアンス
クラスタ全体のコンプライアンスによって、特定のイベントに基づいてコンプライアンス プロファイルを設定でき、コンプライアンス プロファイルでイベントが重複した場合、これらのイベントを順位付けして適切なコンプライアンス サーバにルーティングできます。すべてのコンプライアンス サーバにコンプライアンス プロファイルを割り当てる必要があり、複数のコンプライアンス サーバで同じコンプライアンス プロファイルを共有できます。
IM and Presence サービスの外部データベース要件は、使用する機能によって異なります。たとえば、永続的なグループ チャット機能を有効にするには、IM and Presence サブクラスタ ペアごとに外部データベースが必要です。この場合、クラスタ内のすべての IM and Presence サブクラスタ ペアが固有のデータベース インスタンスを指しますが、同じ物理データベース インストールを共有することができます。
メッセージ アーカイバ（コンプライアンス）機能では、IM and Presence クラスタごとに 1 つ以上の外部データベース インスタンスが必要です。ただし、各サブクラスタ ペアを 2 つの外部データベース インスタンスと 1：1 でマッピングし、それぞれのコンプライアンス サーバに割り当てられたコンプライアンス プロファイルで IM and Presence ノードをそれぞれ定義することが推奨されます。
マネージド ファイル転送機能には、Cisco XCP File Transfer Manager サービスがアクティブになっている IM and Presence サービス クラスタ内の IM and Presence サービス ノードごとに固有の論理外部データベース インスタンスが 1 つ必要です。
（注） IM and Presence サービス ノード上に永続的なグループ チャット、メッセージ アーカイバ（コンプライアンス）、およびマネージド ファイル転送機能を組み合わせて配置する場合は、各機能に同じ外部データベースを割り当てることができます。
コラボレーション クライアントのメッセージ ロギング ストレージ要件
メッセージ アーカイブと永続的なチャット機能は、外部データベースを使用してメッセージをオフラインで保存します。配置のストレージ要件には、カスタマー トポロジ、データベースの調整方法、組織内でのメッセージングの使用方法などの複数の考慮事項が存在します。次の計算は、外部データベース ストレージ配置のロー データベース ストレージ要件を見積もるために使用する入力値のガイドラインを提供します。
Cisco IM and Presence サービスは SIP クライアントと XMPP クライアントの両方をサポートし、メッセージあたりのオーバーヘッドのサイズはプロトコルによって若干異なります。メッセージ アーカイブの 1 つのメッセージあたりのオーバーヘッドは、実際には配置、Jabber ID/UserID サイズ、クライアント タイプ、およびスレッド ID に応じて大きくなったり、小さくなったりすることがあります。したがって、平均のオーバーヘッド サイズが使用されます。SIP ベースのメッセージの場合、平均オーバーヘッドは 800 バイトになり、XMPP メッセージの場合、平均オーバーヘッドは 600 バイトになります。
Cisco Jabber ユーザに対する 1 ヵ月あたりのメッセージ アーカイブの最低ストレージ要件（バイト単位）は、次のように計算できます。
（ユーザ数）∗（1 時間あたりのメッセージ数）∗（1 ヵ月あたりのビジー時間数）∗（600 +（3 ∗ メッセージあたりの文字数））
Cisco IM and Presence サービスのコンプライアンス設定で [発信メッセージのロギングの有効化（Enable Outbound Message Logging）] が有効になっている場合は、上記のメッセージ アーカイブ要件を 2 倍にする必要があります。
Cisco Jabber ユーザに対する 1 ヵ月あたりの永続的なチャットの最低ストレージ要件（バイト単位）は、次のように計算できます。
（ユーザ数）∗（1 時間あたりの永続的なチャット メッセージ数）∗（1 ヵ月あたりのビジー時間数）∗（700 +（3 ∗ メッセージあたりの文字数））
（注） 永続的なチャットは XMPP クライアントでのみサポートされ、700 バイトの平均オーバーヘッドを使用します。
表 20-5 に、データベース容量に関する要件の特定を支援するスプレッドシートの例を示します。これらの計算は、非常に簡略化された形で示されています。この例では、データベース タイプ間の違いやストレージの使用方法は提供されません。
|
|
|
|
|
|
|
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|||||
これらのメッセージ アーカイブ数と永続的なチャット数は、長期の平均値に基づいた最小ストレージ要件です。したがって、非常に大きい UserID、予想よりも大きいインスタント メッセージ長、およびストレージ要件を増加させる可能性がある他の要因に対応するために、1.5（150 %）のバッファ係数を使用する必要があります。 表 20-6 に、Cisco Collaboration クライアントのストレージ要件の例を示します。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
オンプレミスの Cisco IM and Presence サービスのカレンダー統合
Cisco IM and Presence サービスは、Microsoft Exchange 2010 または 2013 サーバ側の統合でカレンダー モジュール インターフェイスを使用してカレンダー ステータスを取得し、それをプレゼンス ステータスに集約できます。シスコは、Microsoft Exchange の設定、配置、またはベスト プラクティス手順は提供していませんが、Cisco IM and Presence サービスと Microsoft Exchange 2010 または 2013 のカレンダー モジュール インターフェイスとの統合に関するガイドラインをこの項で提供しています。
Microsoft Exchange の統合は、Microsoft Active Directory 2008 および Active Directory 2012 と Windows Server 2008 および Windows Server 2012 でサポートされます。Microsoft Exchange 2010 または 2013 では、Microsoft Exchange からの要求の送信や通知の受信を可能にする Exchange Web サービス（EWS）経由で、サーバからカレンダー データを取得できます。Microsoft Exchange との統合は、カレンダー アプリケーション用の別のプレゼンス ゲートウェイによって実現されます。管理者が Outlook 対応のプレゼンス ゲートウェイを設定すると、ユーザは自分のプレゼンス ステータスにカレンダー情報を集約するかどうかを切り替えられるようになります。
カレンダー情報の取得に使用される交換 ID は、そのユーザの LDAP 構造の電子メール ID から取得されます。電子メール ID が存在しない場合、または LDAP が使用されていない場合は、Cisco IM and Presence サービスのユーザ ID が交換 ID としてマッピングされます。
Cisco IM and Presence サービスから Microsoft Exchange Server へのカレンダー ステータスに関するサブスクリプションによって、情報が収集されます。図 20-27 は、このやり取りを示します。
図 20-27 Cisco IM and Presence サービスと Microsoft Exchange 間の Outlook Web Access 通信
Microsoft Outlook カレンダー統合
IM and Presence サービスでは、ユーザの応答可能性をパブリッシュするときに、Microsoft Outlook カレンダーの空きおよびビジーのデータを組み込むことができます。この機能により、ユーザの応答可能性とステータスが自動的に維持されます。これはサーバ間の統合に基づいているため、発信元ユーザのログイン状況が別のユーザに表示されます。Microsoft Outlook カレンダー機能では、Microsoft Exchange Server へのゲートウェイ接続を確立する必要があり、Microsoft Exchange Server 2003、2007、および 2010 と互換性があります。
（注） Cisco IM and Presence サービスは、単一または複数の Microsoft Exchange Server とともに単一のフォレスト内にのみ配置できます。Microsoft Exchange 配置では、複数の Exchange Server で構成されるクラスタを使用できるので、Cisco IM and Presence サービスは、Cisco IM and Presence サービスがステータスを要求する対象ユーザをホストしている Exchange Server への REDIRECT メッセージを受け入れます。
多言語カレンダーのサポート
カレンダー統合配置の要件で複数の言語を指定する場合は、次の設計ガイドラインに従ってください。
- Cisco IM and Presence サービスには、Cisco Unified Communications Manager と同様に、ユーザが必要なロケールを選択できるように適切なロケールがインストールされている必要があります。
- Cisco IM and Presence サービスは、カレンダー統合用に Unified Communications の標準ロケールをすべてサポートしています。
- エンド ユーザ用ページ、または管理用の Bulk Administration Tool によって、ユーザに目的のロケールが設定される必要があります。
- Cisco IM and Presence サービスは、最初の照会とともに適切なロケール フォルダを送信します。照会は必要に応じて、フロントエンドまたはクライアント アクセス用 Microsoft Exchange Server の最初の応答によってリダイレクトされます。
Exchange Web サービス カレンダー統合
Cisco IM and Presence サービスでは、ユーザの全体のプレゼンス ビューに集約されるカレンダー ステータス情報を Microsoft Exchange Web サービスが収集することを許可するよう設定できます。ユーザ メールボックスが設定された Exchange Server に存在する場合、Cisco IM and Presence サービスは Exchange Server と直接通信します。その一方で、ユーザ メールボックスが設定された Exchange Server 以外のサーバに存在する場合、Cisco IM and Presence サービスは Exchange Server のリダイレクションに従ってユーザ メールボックスが存在するサーバを見つけます。サーバ ファームの Exchange Server だけが、設定された Exchange Server として機能できます。サーバ ファームのサーバを 1 つのみ指定する必要があります。
Microsoft Exchange Web サービスは、エンドユーザが使用する言語に関係なく、Exchange クライアント アクセス サーバと連携するために使用されるプロトコルを指定します。したがって、エンドユーザの言語を決定するためにロケールを使用する必要はありません。Cisco IM and Presence サービス カレンダー統合は、単一の Microsoft Exchange フォレストでのみサポートされます。
Cisco IM and Presence Exchange Web サービス カレンダー統合は、カレンダー情報のポーリング（図 20-28 を参照）とカレンダー情報のサブスクリプション/通知（図 20-29 を参照）の両方をサポートします。さまざま設定パラメータを使用して、ポーリング間隔のレート、サブスクリプション頻度、およびタイマーの耐障害性を制御します。その他の設定の詳細については、次の Web サイトで入手可能な『 Integration Note for Configuring Cisco IM and Presence with Microsoft Exchange 』を参照してください。
https://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html
図 20-28 Cisco IM and Presence サービス カレンダーを使用した Exchange Web サービスのポーリング
図 20-29 Cisco IM and Presence サービス カレンダーを使用した Exchange Web サービスのサブスクリプション/通知
クライアント アクセス サーバ（CAS）ロールがインストールされた各サーバに対して Service Connection Point（SCP）Active Directory オブジェクトが作成されている場合は、Cisco IM and Presence サービスで Exchange Web サービスの Auto Discover もサポートされます。Auto Discover では、ドメインと、ホストおよびポートの代わりにサイト（任意）を使用してカレンダー ゲートウェイが設定されます。Cisco IM and Presence サービスは、自動検出アルゴリズムを使用して適切なクライアント アクセス サーバである Exchange Server との接続に使用する Exchange Web サービスの URL を特定します。
オンプレミスの Cisco IM and Presence サービス モビリティ統合
Cisco IM and Presence サービスでは、連絡先リストとプレゼンス ステータスを Cisco Jabber Mobile IM と統合できます。Jabber Mobile IM は引き続き Cisco Unified CM と直接通信しますが、Cisco Unified CM は、AXL/SOAP および SIP 経由で Cisco IM and Presence サービスと通信します。
Cisco Unified CM が Cisco IM and Presence サービスとの間で管理セッションを確立するには、その前に Cisco IM and Presence サービスと Cisco Unified CM 上でアプリケーション ユーザを設定する必要があります。Cisco Jabber Mobile IM のエンドユーザ ログインにより、Cisco IM and Presence サービスに対してシステム設定、ユーザ設定、連絡先リスト、プレゼンス ルール、およびアプリケーション ダイヤル ルールを求める Cisco Unified CM SOAP 要求が生成されます。その後、Unified Communicator Change Notifier（UCCN）設定と Presence SIP サブスクリプションが実行されます。
オンプレミスの Cisco IM and Presence サービス サードパーティ製 Open API
Cisco IM and Presence サービスでは、SIP/SIMPLE と XMPP に加え、HTTP を介してサードパーティ製アプリケーションと統合できます。HTTP インターフェイスは、設定インターフェイスのほか、Representational State Transfer（REST）経由のプレゼンス インターフェイスを備えています。サードパーティ製の Open API は、プレゼンスへのアクセス メカニズムとして、リアルタイム イベンティング モデルとポーリング モデルの 2 つのメカニズムを持っています。
サードパーティ製 Open API の詳細については、次の Web サイトの Cisco Developer Community を参照してください。
https://developer.cisco.com/web/cdc
リアルタイム イベンティング モデルでは、Cisco IM and Presence サービス上でアプリケーション ユーザを使用して管理セッションを確立することにより、エンド ユーザがそのセッション キーを使用してログインできるようになります。ユーザはログインすると、Representational State Transfer（REST）を使用してプレゼンスの更新について登録とサブスクリプションを行います。図 20-30 に、サードパーティ製 Open API リアルタイム イベンティング モデルでの Cisco IM and Presence サービスとの対話を示します。
図 20-30 サードパーティ製 Open API リアルタイム イベンティング モデル
図 20-30 のコールフローは、次の一連のイベントを示しています。
1. アプリケーションが、スーパーユーザ アプリケーション ユーザ（APIUser）経由で Cisco IM and Presence サービスに対して SOAP ログイン要求を開始し、Cisco IM and Presence サービスがセッション キーを返します。これにより、アプリケーションはセッションキーを使用してエンド ユーザをログインさせられるようになります（実質的には、エンド ユーザがアプリケーション経由でログインします）。
2. エンド ユーザが、アプリケーションユーザ セッション キーを使用してエンドポイントを登録します。
3. アプリケーションが、ユーザの代わりに（セッション キーを使用して）サブスクライブ要求を開始し、ユーザ情報、連絡先リスト、およびプレゼンス ルールを取得します。
4. Cisco IM and Presence サービスが、非保護の通知を送信します。
5. アプリケーションが、ユーザのプレゼンス ステータスを要求します。
ポーリング モデルでは、Cisco IM and Presence サービス上でアプリケーション ユーザを使用して管理セッションを確立することにより、エンド ユーザがそのセッション キーを使用してログインできるようになります。ユーザがログインすると、アプリケーションは、ここでも Representational State Transfer（REST）を使用して、定期的にプレゼンスの更新を要求します。図 20-31 に、サードパーティ製 Open API ポーリング モデルでの Cisco IM and Presence サービスとの対話を示します。
図 20-31 サードパーティ製オープン API ポーリング モデル
図 20-31 のコールフローは、次の一連のイベントを示しています。
1. アプリケーションが、スーパーユーザ アプリケーション ユーザ（APIUser）経由で Cisco IM and Presence サービスに対して SOAP ログイン要求を開始し、Cisco IM and Presence サービスがセッション キーを返します。これにより、アプリケーションはセッションキーを使用してエンド ユーザをログインさせられるようになります（実質的には、エンド ユーザがアプリケーション経由でログインします）。
2. アプリケーションがプレゼンス ステータスを要求します。イベンティング モデルは省略されます。
3. アプリケーションがプレゼンス ステータスを要求します。イベンティング モデルは省略されます。
（注） ポーリング モデルでは、基本プレゼンスと高度なプレゼンスの両方が取得できますが、Presence サーバの負荷が大きくなります。
Extensible Messaging and Presence Protocol インターフェイス
XCP アーキテクチャでは、プレゼンス、インスタント メッセージング、および参加者管理に、クライアント XMPP インターフェイスおよび Cisco AJAX XMPP Library インターフェイスという 2 つのオープンなインターフェイスを追加で使用できます。クライアント XMPP の機能によって、サードパーティ製 XMPP クライアントにプレゼンス、インスタント メッセージング、および参加者管理を統合できます。これは、Cisco IM and Presence サービスにおける SIP/SIMPLE インターフェイスを補完するインターフェイスです。クライアント XMPP インターフェイスは、Cisco IM and Presence サービス内では通常の XMPP クライアントとして処理されます。そのため、インターフェイスのサイジングは、通常の XMPP クライアントとして処理する必要があります。
Cisco AJAX XMPP Library API は、XCP 機能を Web アプリケーションおよびウィジェットに統合するための Web 2.0 スタイルのインターフェイスを提供し、Cisco IM and Presence サービスから直接利用できます。Cisco AJAX XMPP Library API は Bidirectional-streams Over Synchronous HTTP（BOSH）インターフェイスと通信するクライアント側専用の JavaScript ライブラリです。BOSH は、基本的にロングポーリング手法を使用してサーバから Web ブラウザにデータをプッシュできる XMPP over HTTP インターフェイスです。
いずれかのモデルのサードパーティ製 Open API を Cisco IM and Presence サービスと統合する場合は、次の要件に従ってください。
- プレゼンス インターフェイスに対する証明書（sipproxy.der）と設定インターフェイスに対する証明書（tomcat_cert.der）が必要です。
- 1 つの Cisco IM and Presence サービス配置で、1000 人を超えるサードパーティ製 Open API ユーザの統合はできません。
- パフォーマンスの向上を図るには、サードパーティ製 Open API ユーザを Cisco IM and Presence サービス クラスタにあるすべてのサーバに均等に振り分けてください。
Cisco IM and Presence サービスのサードパーティ製 Open API の使用に関する詳細とサポートについては、次の Web サイトの Cisco Developer Services を参照してください。
https://developer.cisco.com/web/cupapi
開発者向けの情報は、Cisco Developer Community にも用意されています。次の Web サイトからログインしてアクセスしてください。
オンプレミスの Cisco IM and Presence サービスの設計に関する考慮事項
- LDAP 統合が可能な場合、すべてのユーザ情報（番号、ID など）は、単一のソースから Unified CM との LDAP 同期を使用してプルする必要があります。ただし、LDAP server および LDAP 同期が有効でない Unified CM の両方を含む配置の場合、管理者は、ユーザのディレクトリ番号のアソシエーションの設定にあたって、Unified CM と LDAP の両方に一貫した設定を行う必要があります。
- Cisco IM and Presence サービスは、Diffserv コード ポイント（DSCP）により、レイヤ 3 IP パケットをマーキングします。Cisco IM and Presence サービスは、SIP プロキシの下の Differential Service Value サービス パラメータ（デフォルトは DSCP 24（PHB CS3））に基づいて、すべての IM and Presence トラフィックをマーキングします。
- Cisco IM and Presence サービスのプレゼンス ポリシーは、ユーザが作成した定義済みのルール セットによって、厳格に制御されます。
- サービス パラメータ IMP PUBLISH Trunk を使用して、Cisco IM and Presence サービスとの SIP 通信トラフィックを簡素化します。
- Unified CM のプレゼンス ユーザは、プライマリ内線だけでなく、ライン アピアランスと関連付けます。これにより、デバイスとユーザのプレゼンス ステータスの詳細度が向上します。サービス パラメータ IMP PUBLISH Trunk を使用している場合は、Unified CM 内のプレゼンス ユーザをライン アピアランスと関連付けてください。
- サーバ ハードウェアとクラスタ トポロジの特性を決定する際は、プレゼンス ユーザ プロファイル（ユーザ アクティビティおよび連絡先リストの連絡先とサイズ）を考慮する必要があります。Cisco IM and Presence のシステム アーキテクチャは、フル装備のシステムでユーザ 1 人あたり 75 件という連絡先リストの平均サイズに基づいています。システム全体ではユーザごとの連絡先リストのサイズが異なりますが、システムのユーザの多くが 75 件の連絡先という平均リスト サイズを超える場合はシステム パフォーマンスに影響します。デフォルトでは、連絡先リストの最大サイズは 200 です。一部のユーザの連絡先が 200 件を超えている場合は、IM and Presence クラスタの [プレゼンスの設定（Presence Settings）] を修正することで、この最大連絡先リスト サイズを変更できます。サイジングの追加情報については、Cisco IM and Presenceと名簿管理のセクションを参照してください。
- クラスタ全体として最高のパフォーマンスを得るには、[プレゼンスサーバのユーザ割り当てモード（User Assignment Mode for Presence Server）] エンタープライズ パラメータに、デフォルトの [平衡化（balanced）] を使用します。
- Cisco IM and Presence サービスでは、永続的なチャットを行う場合、クラスタ内の各サーバに外部データベース インスタンスが必要です。また、メッセージ アーカイブについては、クラスタごとに 1 つのデータベース インスタンスが必要です。サードパーティ製コンプライアンスは、1 つの外部コンプライアンス データベースに対する IM and Presence サービス クラスタ内のすべてのサーバまたはサーバのサブセットのマッピングをサポートします。IM and Presence サーバごとに複数のコンプライアンス サーバ、コンプライアンス サーバごとに複数の IM and Presence サーバ、またはその組み合わせといった、3 つの外部データベース オプションが柔軟な配置を実現します。
- コンプライアンス サーバは専用にすることも、同じクラスタ内の IM and Presence ノードと共有することもできます。コンプライアンス プロファイルで定義されている両方の IM and Presence ノードで、サブクラスタ ペアごとに 2 台のコンプライアンス サーバを配置することを推奨します。クラスタ全体で 1 台のコンプライアンス サーバであってもサポートされますが、お勧めしません。
- Linux または Windows オペレーティング システムにデータベースをインストールできます。サポートされるオペレーティング システムとプラットフォームの要件の詳細については、次の該当するデータベースのマニュアルを参照してください。
– https://www.postgresql.org/docs/manuals/ で入手可能な PostgreSQL のマニュアル
– https://docs.oracle.com/en/database/database.html で入手可能な Oracle のマニュアル
- Cisco IM and Presence サービスは、フル Unified Communications モードでクラスタあたり合計 75,000 ユーザをサポートします。ユーザのサイジングにおいては、SIP/SIMPLE ユーザの数および XMPP ユーザの数を考慮する必要があります。SIP/SIMPLE ユーザは XCP アーキテクチャへの IM ゲートウェイ機能を利用するため、XMPP ユーザの方が若干パフォーマンスがよくなります。
- すべての eXtensible Communications Platform（XCP）通信およびロギングは GMT で実行および保管され、インストールされたロケーションに合せてローカライズされません。
- ユーザおよび連絡先リストを簡単に移行できるように、Cisco IM and Presence Bulk Administration Tool では、一括インポートの入力としてカンマ区切り値（csv）ファイルを使用した一括連絡先リスト インポートをサポートしています。
Cisco IM and Presence サービスによって使用されるポートの完全なリストについては、次の Web サイトで入手可能な『 Port Usage Information for Cisco IM and Presence 』を参照してください。
https://www.cisco.com/en/US/products/ps6837/products_device_support_tables_list.html
連絡先リストとウォッチャ リストの推奨事項
（注） このセクションで提示するガイドラインは、特定のテスト条件下で Cisco によって検証された事実に厳密に基づいています。この推奨事項の目的は、クラスタ内の連絡先リストとウォッチャ リストの管理に関して、IM and Presence 導入におけるプレゼンス ユーザの導入と分散を支援することです。
IM and Presence クラスタ
IM and Presence の標準導入は、3 つの IM and Presence サブクラスタ ペア（6 ノード）の 1 つのフル稼働しているクラスタで 45,000 人のプレゼンス対応ユーザをサポートするように設計されており、15k ユーザ IM and Presence VM テンプレートを使用して展開されます。
連絡先リストとウォッチャ リストに関する推奨事項は、クラスタ平均が、クラスタ内のユーザあたり 75 人のプレゼンス対応連絡先を超えないことです。この値は、ユーザあたり平均 100 人の総連絡先（それぞれのバディ リストで 75 人のプレゼンス対応ユーザと 25 人の非プレゼンス対応ユーザに分けられている）の検証テストから抽出されたものです。このセクションの後半では、75 人のプレゼンス対応ユーザを中心に説明します。これは、システムのパフォーマンスと拡張性に最も影響する要素だからです。
IM and Presence システムのパフォーマンスと安定性の管理を支援するには、IM and Presence 名簿テーブルを適切に維持、管理、監視することが重要です。このテーブルは、基本的にすべてのプレゼンス ユーザのエンドユーザ連絡先リストとウォッチャ リストで構成されています。
（注） ユーザあたり 75 人のプレゼンス対応連絡先というクラスタ平均は、[連絡先リストの最大サイズ（ユーザごと）（Maximum Contact List Size (per user)）] と [ウォッチャの最大数（ユーザごと）（Maximum Watchers (per user)）] のサービス パラメータと同じではありません。これらのデフォルト値は、Cisco IM and Presence のリリース バージョンに応じて、それぞれ、150 と 200 です。
プレゼンス状態変更の影響
状態変更がシステムに与える影響を理解するために、標準的な作業日の 1 人のユーザの視点からイベントを検討してみます。Bob という名前のユーザがバディ リスト内に 75 人の連絡先を登録しており、その 75 人の連絡先もバディ リスト内に Bob を 1 人の連絡先として登録しているとします（ただし、ほとんどの導入で必ずしもあてはまるとは限りません）。
Bob が初めてデスクトップ Jabber クライアントにログインすると、75 件の通知が生成され、彼のバディ リスト内のすべての連絡先に送信されます。その後で、Bob が卓上電話機を使用して電話を掛けると、彼の状態を「電話中」に更新する、別の 75 件の通知が彼の連絡先に送信されます。Bob の状態変更ごとに、彼のバディ リスト内の連絡先あたり 1 件の通知が発行されます。ただし、Bob もその連絡先のバディ リストに登録されている場合です。
すべてのプレゼンス対応ユーザが、バディ リスト内のすべてのプレゼンス対応連絡先にステータス変更更新を発行します。ステータス変更には、電話機のハンドセットの持ち上げ、コールの発信、電話の切断、会議への参加などのアクションが含まれます。そのため、75 人のプレゼンス対応連絡先を持つすべてのユーザのすべてのアクションによって、最低 75 件の通知が生成されます。
たとえば、それぞれのバディ リストに 75 人の連絡先が登録されている、3,000 人のプレゼンス対応ユーザの導入を考えてみます。3,000 人すべてのユーザが同時に会議またはオールハンズ ミーティングに参加すると、225,000 件のプレゼンス更新通知が生成されます。同様に、9,000 人のプレゼンス ユーザの導入では、すべてのユーザが同時にプレゼンス ステータスの変化を引き起こすアクションを実行すると、675,000 件のプレゼンス更新通知が生成されます。これらの通知によって、システム リソースが使用され、特に、ピーク使用時間中のシステム パフォーマンスに影響が出ます。これが、ユーザをクラスタ全体に均等に分散させ、ユーザあたり 75 人の連絡先という推奨平均値を超えないようにすることが不可欠な理由です。
プレゼンス ユーザの分散
IM and Presence データベースの予算、つまり、最大許容連絡先エントリ数は、設定済みのプレゼンス ユーザの総数に、各ユーザがバディ リストに登録可能なプレゼンス連絡先の推奨平均数（75）を掛けて求めることができます。たとえば、45,000 人のユーザがフル稼働しているクラスタの推奨予算（IM and Presence 連絡先の最大数）は、次のようになります。
（45,000 人のユーザ） ∗ （ユーザあたり 75 人の連絡先） = クラスタの 3,375,000 人の IM and Presence 連絡先
それぞれのサブクラスタ内に 15,000 人のユーザが配置された 3 つのサブクラスタ ペア（6 ノード）が導入に存在する場合は、平均で次のようになります。
15,000 人のユーザ ∗ ユーザあたり 75 人の連絡先 = サブクラスタ ペアあたり 1,125,000 人の連絡先
すべての IM and Presence ユーザがバディ リストに 75 人以下の連絡先を登録している場合は、上記の計算で示したように、ユーザをサブクラスタ間で均等に分散することができます。ただし、一部のユーザがバディ リストに 75 人を超える連絡先を登録する必要がある場合は、次のセクションで説明する、カスタム分散が必要です。
ヒント 大量の連絡先（75 人を超える）を持つユーザは、そのすべてが同じ IM and Presence ノードに存在するのではなく、ノード全体に均等に分散されるようにしてください。
ここでも、3 つのサブクラスタに 45,000 人のユーザが分散された、フル稼働の IM and Presence クラスタを考えてみます。たとえば、クラスタ内の 1,000 人のユーザがバディ リストに 500 人のプレゼンス対応連絡先を登録する必要があるとします。このケースでは、これらの 1,000 人のユーザで以下のことが必要です。
（1,000 人のユーザ） ∗ （ユーザあたり 500 人の連絡先） = 500,000 個の IM and Presence データベース エントリ
クラスタ全体で許容される IM and Presence データベース エントリの最大数は 3,375,000 です。それぞれが 500 人の連絡先を持つ 1,000 人のユーザの場合を見積ったら、残りの使用可能な連絡先エントリは次のようになります。
3,375,000 - 500,000 = 2,875,000 の連絡先エントリがクラスタ内の残りの 44,000 人のプレゼンス ユーザで使用可能。
使用可能な連絡先エントリがクラスタ内の残りの 44,000 人のユーザの間で均等に分散されている場合は、次のようになります。
2,875,000/44,000 = ユーザあたり 65 人の連絡先の最大値
（注） 上の例では、500 人の連絡先を持つユーザを 3 つのサブクラスタ ペア間で均等に分散する必要があります。使用状況やリソース要件の変化に合わせて、IM and Presence ユーザの分散を頻繁に監視および調整することによってシステムの安定性を確保することも重要です。加えて、クラスタ内のいずれかのユーザに必要な連絡先の数がサービス パラメータ [連絡先リストの最大サイズ（ユーザごと）（Maximum Contact List Size (per user)）] のデフォルト値より高い場合は、そのパラメータの設定と [ウォッチャの最大数（ユーザごと）（Maximum Watchers (per user)）] の設定の両方をより高い値に変更する必要があります。
上の例では、ユーザあたり 500 人の連絡先があるカスタム分散では、均等に分散されたオプションのステータス変更あたり 75 件の通知と比較して、ステータス変更あたり 500 件の通知が生成されることになります。以降の例では、75 人の連絡先を持つ 1,000 人のユーザと 500 人の連絡先を持つ 1,000 人のユーザの影響の比較を示します。
モバイル & リモート アクセス
ユーザは VPN クライアントを使用せずに、企業のファイアウォールの外からコラボレーション ツールにアクセスできます。シスコのコラボレーション ゲートウェイを使用して、クライアントは公衆 Wi-Fi ネットワークやモバイル データ ネットワークなどのリモート ロケーションから社内ネットワークに安全に接続できます。
Cisco Unified Communications のモバイルおよびリモート アクセスは Cisco Collaboration Edge アーキテクチャの中核を成します。Cisco Jabber などのエンドポイントが企業ネットワーク外にある場合に、Cisco Unified Communications Manager（Unified CM）への登録、呼制御、プロビジョニング、メッセージング、およびプレゼンスの機能を使用することができるようになります。Cisco Expressway は、Unified CM 登録にセキュアなファイアウォール トラバーサルと回線側サポートを提供します。
サードパーティ製 SIP または H.323 デバイスは、ネイバー ゾーンで Cisco Expressway に接続されている Cisco VCS に登録でき、必要に応じて SIP トランクを介して Unified CM に登録されたデバイスと相互運用できます。
Cisco Expressway サーバのセットアップ方法については、次の Web サイトで入手可能な『 Cisco Expressway Basic Configuration Deployment Guide 』および『 Mobile and Remote Access via Cisco Expressway Deployment Guide 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html
サードパーティ製プレゼンス サーバ統合
Cisco IM and Presence サービスでは、SIP アプリケーションと SIMPLE アプリケーションを Cisco Unified Communications ソリューションに統合できるよう、SIP と SIP for Instant Messaging and Presence Leveraging Extensions（SIMPLE）に基づくインターフェイスを提供しています。これにより、サードパーティ製のプレゼンス サーバやアプリケーションをこの SIP/SIMPLE と連携して設定し、統合して、プレゼンス集約やフェデレーションを提供できます。
リモート呼制御（RCC）用 Microsoft Communications Server
Microsoft 製品のセットアップ、設定、および配置に関するすべての情報は、次の Web サイトにあるマニュアルを参照してください。
シスコは、Microsoft Communications 製品の設定、配置、またはベスト プラクティス手順は提供していませんが、Cisco IM and Presence サービスと Microsoft Lync との統合に関する次のガイドラインを提供しています。
シスコは、機能の相互運用性と、Cisco IM and Presence サービスを Microsoft Lync と統合するための設定手順を示すマニュアルを作成しました。このマニュアルには次の URL でアクセスできます。
https://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html
Cisco IM and Presence サービスと Microsoft Lync の統合に関するガイドライン
次のガイドラインは、Cisco IM and Presence サービスと Microsoft Lync を統合するときに適用されます。
- Cisco IM and Presence サービスと Microsoft Lync との通信には、SIP/SIMPLE インターフェイスが使用されます。ただし、Microsoft Lync は SIP 経由の Computer-Supported Telecommunications Applications（CSTA）トラフィックをトンネルします。したがって、Cisco IM and Presence サービス上の CTI ゲートウェイは、Click to Call の電話制御のために CSTA-CTI 変換を処理するように設定する必要があります。
- リモート呼制御用の Microsoft Lync とともに Cisco IM and Presence サービスを配置する場合は、Cisco IM and Presence サービス クラスタを形成するサーバの単一サブクラスタ ペアで構成する必要があります。
- 次の表では、プラットフォームごとのサポートされるユーザ数を示します。ユーザ数は、IM and Presence サービス プラットフォームに関係なく、Unified CM プラットフォームの相当数にのみ基づきます。
|
|
|
|
|---|---|---|
- LDAP、Unified CM、および Microsoft Lync で、同じエンドユーザ ID を設定する必要があります。これにより、Active Directory（AD）による Microsoft Lync 認証と Unified CM のエンドユーザ設定との競合、さらには Unified CM 上でのユーザの電話制御との競合を防止できます。
Active Directory については、General、Account、および Communications のユーザのプロパティですべて同一の ID を使用することを推奨します。Cisco IM and Presence サービス ユーザの一貫性を維持するために、Unified CM で LDAP 同期と LDAP 認証を有効にする必要があります。
- Microsoft Lync のホスト認証に Cisco IM and Presence サービス パブリッシャとサブスクライバを含めるように設定する必要があります。
- Microsoft Lync プロパティのスタティック ルートによって SIP メッセージが Cisco IM and Presence サービスにルーティングされるように設定する必要があります。
- Cisco IM and Presence サービスで発着信のアクセス コントロール リスト（ACL）を設定して、Microsoft Lync との通信を許可する必要があります。
- Unified CM で各ユーザのプレゼンスを有効にするだけでなく、Cisco IM and Presence サービス設定で、各ユーザに Microsoft Lync の使用を許可する必要があります。
- Microsoft Lync のログイン時に、Microsoft Lync と Microsoft Communications Server 間での設定情報の交換や、Cisco IM and Presence サービス CTI ゲートウェイとの初期通信のために必要となる帯域幅を考慮に入れる必要があります。
- ディレクトリ番号からそれに対応するユーザを検索するリバース ルックアップの問題に対処するには、次の Web サイトで入手可能な『 Release Notes for Cisco IM and Presence 』に記載されているガイドラインを使用してください。
https://www.cisco.com/en/US/products/ps6837/prod_release_notes_list.html
クラウド内サービスとアーキテクチャ
ここでは、Cisco IM and Presence サービスのクラウド内サービスとアーキテクチャについて説明します。このホステッド サービスは、オンプレミス ソリューションと同じユーザ エクスペリエンスを提供します。
Cisco WebEx Messenger
Cisco WebEx Messenger は、同期および非同期コラボレーションに対応したマルチテナント型 Software-as-a-Service（SaaS）プラットフォームです。WebEx Messenger プラットフォームは、Cisco WebEx Collaboration Cloud 内でホストされ、コラボレーション アプリケーションと統合を可能にします。これにより、会社およびエンド ユーザが自分の作業環境をカスタマイズすることが可能になります。Cisco WebEx Messenger サービスの詳細については、次の Web サイトで入手可能なマニュアルを参照してください。
https://developer.cisco.com/web/webex-developer
Cisco Collaboration Cloud の詳細については、次の Web サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/en/US/solutions/ns1007/collaboration_cloud.html
Cisco WebEx Messenger サービスの配置
Cisco WebEx Messenger ソリューションの配置は、図 20-32 に示すように、次のコンポーネントで構成されています。
- プレゼンス、インスタント メッセージング、VoIP、PC 間ビデオ、メディア転送（スクリーン キャプチャとファイル転送）、およびデスクトップ共有のための、Cisco WebEx Messenger XMPP クラウド プラットフォームへのセキュア接続（SSL と AES）
- Cisco WebEx Meetings
- 他の WebEx Messenger 組織との XMPP フェデレーション、サードパーティ製 XMPP クライアント、および XMPP インスタント メッセージング（IM）ネットワーク
- 呼制御、ボイス メッセージング、およびコール履歴のための、Cisco Unified Communications 統合
- Microsoft Outlook および IBM Lotus Notes カレンダー統合
- プレゼンス、Click-to-Communicate 機能のための、Microsoft Outlook への統合
図 20-32 Cisco WebEx Messenger サービスの配置
中央集中型の管理
Cisco WebEx Messenger サービスでは、組織全体にわたるソリューションを管理するための Web ベースの管理ツールを提供しています。Cisco WebEx Messenger サービス ユーザは、Cisco WebEx 管理ツールを介して設定および管理されます。これにより、管理者は機能およびサービスに対してセキュリティとポリシーの基本制御を設定できます。これらのポリシーは、企業全体、グループごと、または個別に適用できます。ユーザ データベースをプロビジョニングにするためのさまざまな方法があります。これらの方法については、次の Web サイトで入手可能な『Cisco WebEx Administrator's Guide』を参照してください。
シングル サインオン
シングル サインオン（SSO）を使用すると、会社は Security Assertion Markup Language（SAML）サポートなどのオンプレミス SSO システムを使用でき、ユーザが会社のログイン クレデンシャルを使用してソリューション内の Unified Communications アプリケーションに安全にログインできるようにすることで、Cisco WebEx Messenger または IM and Presence サービスの管理を簡素化できます。ユーザのログイン クレデンシャルはシスコに送信されないため、ユーザの会社のログイン情報は保護されます。図 20-33 に、Cisco WebEx Messenger および Unified CM へのユーザ ログイン時に発生するクレデンシャル ハンドシェイクを示します。
（注） Cisco Jabber を Cisco WebEx Meeting Server とともに配置する場合、Cisco Unified CM と WebEx Meeting Server が同じドメインに存在する必要があります。
図 20-33 Cisco WebEx Messenger サービスでのユーザ ログイン認証プロセス
ユーザ アカウントは、ユーザが初めて Cisco IM クライアントにログインしたときに自動的に作成されるように設定できます。ユーザの会社のログイン アカウントが非アクティブになると、そのユーザは Cisco WebEx Messenger サービスにアクセスできなくなります。
WebEx Messenger サービスを使用したシングル サイン オンの詳細については、次の Web サイトで入手可能なマニュアルを参照してください。
https://developer.cisco.com/web/webex-developer/sso-reference
セキュリティ
Cisco WebEx セキュリティ モデルは、セキュリティの機能レイヤで構成されています。図 20-34 に、各レイヤを構成する、独立しているが相互に関連する要素を示します。
最下位層は、Cisco WebEx データセンターの物理セキュリティを示しています。すべての従業員は、広範なバックグラウンド チェックを通過し、データセンターに入るためのデュアルファクタ認証を実行する必要があります。
次のレベルのポリシー管理では、WebEx Messenger 組織管理者が、個々のユーザ、グループ、または Cisco WebEx Messenger 組織全体に異なるポリシーを設定することによってアクセス コントロール レベルを設定し、管理できます。外部ユーザまたはドメインに固有のホワイトリスト ポリシーを作成して、インスタント メッセージング交換を許可できます。Cisco WebEx Messenger 組織モデルでは、ユーザ ベース全体に固有の役割やグループを作成することもでき、管理者は特定の権限を役割やグループに割り当てたり、組織全体に対してアクセス コントロールなどのポリシーを設定したりできます。
Cisco WebEx Messenger サービスへのアクセスは、認証レイヤで制御されます。いずれのユーザも一意のログインとパスワードを所有します。パスワードが保存されたり、クリア テキストの E メールで送信されたりすることはありません。パスワードを変更できるのは、エンド ユーザ自身だけです。管理者は、次のログイン時にエンド ユーザがパスワードを変更するように、パスワードのリセットを選択できます。また、管理者は、Cisco WebEx Messenger サービスと企業のディレクトリとの間のシングル サイン オン（SSO）統合を使用して、エンドユーザのアクセス管理を簡略化することもできます。シングル サイン オン統合は、Identity Management System（IDMS）を使用して実現されます。
暗号化レイヤでは、Cisco WebEx Messenger ユーザ間のすべてのインスタント メッセージング通信が暗号化されます。Cisco WebEx Messenger ユーザと Messenger Collaboration クラウドのサーバとの間のすべてのインスタント メッセージング通信は、SSL 暗号化を使用してデフォルトで暗号化されます。256 ビットの AES レベル暗号化を使用して IM 通信をエンドツーエンドで暗号化できる追加のセキュリティ レベルを使用できます。
Cisco WebEx Messenger プラットフォームでは、SSAE 16 Type II 監査などのサードパーティによる監査を使用して、カスタマーに半年ごとに別個のセキュリティ レポートを提供します。カスタマーは、シスコのセキュリティ組織に要求すればいつでもこのレポートを確認できます。その他の Cisco WebEx Messenger サービスのセキュリティについては、次の Web サイトで入手可能な『 Cisco WebEx Connect Security White Paper 』を参照してください。
https://www.cisco.com/en/US/products/ps10528/prod_white_papers_list.html
ファイアウォール ドメインのホワイト リスト
アクセス コントロール リストは、webex.com ドメインおよび webexconnect.com ドメインと、この両ドメインのすべてのサブドメインからのすべての通信を許可するように明確に設定する必要があります。WebEx Messenger プラットフォームからエンドユーザにユーザ名とパスワードを通知する電子メールが送信されます。これらの電子メール メッセージは mda.webex.com ドメインから発信されます。
インスタント メッセージのロギング
Cisco WebEx Messenger サービスのインスタント メッセージング通信は、ユーザがログインしているパーソナル コンピュータのローカル ハード ドライブに記録されます。インスタント メッセージのロギングは Cisco WebEx Messenger サービスの機能です。この機能は Org Admin ツールでポリシーを使用して有効にすることができます。
エンド ユーザは、ロギングの詳細、ロギングの有効化または無効化、およびログの保存期間を設定できます。これらのメッセージ履歴設定は、IM クライアント プリファレンスの [全般（General）] にあります。
詳細な監査機能や e-Discovery（電子情報の開示）機能を必要とする場合は、サードパーティ製のソリューションを利用することも検討してください。現在シスコでは、インスタント メッセージング通信の詳細な監査をサポートしていません。ただし、Cisco WebEx Messenger サービスでは、ユーザ間で交換されるインスタント メッセージのロギングとアーカイブを実行できます。ログのアーカイブは、サードパーティの SaaS アーカイブ サービスを使用して実行できます。または、ログをオンプレミス SMTP サーバにセキュアに配信できます。
インスタント メッセージのアーカイブの詳細については、次の Web サイトで入手可能な『Cisco WebEx Administrator's Guide』を参照してください。
Cisco WebEx Messenger サービスのキャパシティ プランニング
エンドユーザが WebEx Messenger サービスにログインして、プレゼンス、インスタント メッセージング、および Voice over IP（VoIP）コーリングなどの基本機能を利用するために必要なものは、56 kbps ダイヤルアップ インターネット接続だけです。ただし小規模のオフィスや支店で、ファイル転送、スクリーン キャプチャ、および PC 間ビデオ コールなどの高度な機能を利用するには、512 kbps 以上のブロードバンド接続が必要です。高品位 720p などの高い品質のビデオの場合、推奨される最小の帯域幅接続は 2 Mbps です。
ネットワークおよびデスクトップの要件の詳細については、次の Web サイトで入手可能な『Cisco WebEx Administrator's Guide』を参照してください。
https://www.webex.com/webexconnect/orgadmin/help/index.htm
Cisco WebEx Messenger サービスのハイ アベイラビリティ
WebEx Messenger は、Software as a Service（SaaS）アプリケーションです。エンドユーザが IM クライアントにログインするには、エンドユーザ デバイスをインターネットに接続する必要があります。標準のインターネット接続があれば、利用できます。エンド ユーザがリモートの場合は、WebEx Messenger サービスにログインするために、そのユーザが会社の VPN を介して接続する必要はありません。Cisco WebEx Messenger サービスの IM クライアントは、可用性の高い冗長なトポロジに配置できます。Cisco WebEx Messenger Software-as-a-Service アーキテクチャの配置は、この項で説明する各種のネットワークおよびデスクトップ要件で構成されます。
高可用性
マルチテナント型 Software-as-a-Service アーキテクチャを使用していて、グループ内のいずれかの個別サーバが何らかの理由で停止した場合、要求を Cisco WebEx Messenger プラットフォーム内の利用可能な他のサーバにルーティングできます。
Cisco WebEx Network Operations Team は、Cisco WebEx Network Operations Center（NOC）から Cisco WebEx Collaboration Cloud を毎日 24 時間アクティブにモニタします。Cisco WebEx テクノロジーの概要については、次の Web サイトを参照してください。
https://www.cisco.com/en/US/solutions/ns1007/collaboration_cloud.html
冗長性、フェールオーバー、およびディザスタ リカバリ
Cisco WebEx のグローバル サイト バックアップ アーキテクチャは、電源異常、自然災害による停電、放電過多、ネットワーク容量過多、その他のタイプのサービス中断を処理します。グローバル サイト バックアップでは、手動と自動の両方のフェールオーバーをサポートします。手動フェールオーバー モードは通常、メンテナンス時間枠で使用されます。自動フェールオーバー モードは、サービス中断によるリアルタイム フェールオーバーの場合に使用されます。
グローバル サイト バックアップは、エンド ユーザに対して自動的かつ透過的であり、すべてのユーザが利用できます。フェールオーバー可能なユーザ数に制限はありません。
Cisco WebEx Messenger サービスの設計に関する考慮事項
Cisco WebEx Messenger は、Software as a Service モデルとして配置されるため、設計と配置の考慮事項は最小限で済みます。Cisco WebEx Messenger ソリューションには、Windows と Mac デスクトップ、および一般的なモバイル デバイスで使用可能なクライアント オプションがあります。
サードパーティ製 XMPP クライアントから Cisco WebEx Messenger サービスへの接続
シスコでは、他の XMPP クライアントによる Cisco WebEx Messenger サービスへの接続を公式にサポートしていませんが、XMPP プロトコルの性質上、エンド ユーザはさまざまな XMPP クライアントで WebEx Messenger サービスのクレデンシャルを使用してプレゼンス クラウドに接続できます。XMPP ソフトウェア クライアントのリストは、次の Web サイトで入手できます。
https://xmpp.org/software/clients.shtml
組織のポリシーは、サードパーティ製の XMPP クライアントに適用できません。また、エンドツーエンド暗号化、デスクトップ共有、ビデオ コール、PC 間コール、および電話会議などの機能は、サードパーティ製のクライアントではサポートされていません。WebEx Messenger サービス以外の XMPP IM クライアントが WebEx Messenger サービス ドメインに対して認証できるようにするには、DNS SRV レコードを更新する必要があります。特定の DNS SRV エントリは、Cisco WebEx 管理の [設定と IM フェデレーション（Configuration and IM Federation）] で見つけることができます。
Cisco WebEx 管理の [設定と XMPP IM クライアント（Configuration and XMPP IM Clients）] で、Messenger サービス以外の XMPP クライアントの使用を明示的に許可する必要があります。
サードパーティ製 XMPP クライアントが WebEx Messenger プラットフォームに接続できるようにする方法の詳細については、次の Web サイトで入手可能な『Cisco WebEx Administrator's Guide』を参照してください。
サードパーティ製 XMPP クライアントを使用したインスタント メッセージングおよびプレゼンス フェデレーション
Cisco WebEx Messenger サービス ネットワークは、GoogleTalk および Jabber.org などの XMPP ベースのインスタント メッセージング ネットワークとフェデレーションできます（図 20-35 を参照）。XMPP に基づいた公衆インスタント メッセージング ネットワークのリストは、次の Web サイトで入手できます。
現在、WebEx Messenger サービスには Yahoo! Messenger および Windows Live Messenger との相互運用性はありませんが、フェデレーション ゲートウェイ経由で AIM とフェデレーションすることはできます。
フィードバック