Cisco Unified Communications Manager Release 9.0(1) の IM and Presence サービスに対するドメイン間フェデレーション
この統合の概要
この統合の概要
発行日;2013/01/06   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

目次

この統合の概要

基本的なフェデレーテッド ネットワーク

この統合により、企業ドメイン内の IM and Presence ユーザと外部ドメインのユーザとの間で、プレゼンス情報やインスタント メッセージ(IM)を交換できるようになります。 IM and Presence では、さまざまな外部ドメインとのフェデレーションが行えるよう、多様なプロトコルが使用されます。

IM and Presence では、以下とのフェデレーションに対しては、標準的な Session Initiation Protocol(SIP RFC 3261)が使用されます。

  • Microsoft Office Communications Server Release 2(OCS R2)、OCS 2007、Microsoft Lync 2010

    (注)  


    IM and Presence Release 9.0 以降では、Microsoft Lync とのドメイン間フェデレーションがサポートされています。 また IM and Presence Release 9.0 以降の場合、OCS とのドメイン間フェデレーションへの参照には、別途明示的な指定がない限り、Microsoft Lync が指定されます。


  • AOL SIP Access Gateway(SAG)

    (注)  


    IM and Presence Release 9.0 以降では、AOL とのドメイン間フェデレーションがサポートされています。

    AOL との SIP フェデレーションにより、IM and Presence ユーザは次のユーザとフェデレーションを行うことが可能です。

    • AOL パブリック コミュニティ(aim.com、aol.com など)のユーザ。
    • ドメインが AOL によってホストされている企業のユーザ。
    • AOL とフェデレーションを行っている外部企業のユーザ。 IM and Presence では、こうした外部企業とフェデレーションを行う際、AOL をクリアリング ハウスとして使用することもできます。

IM and Presence では、以下とのフェデレーションに対しては、Extensible Messaging and Presence Protocol(XMPP)が使用されます。

  • IBM Sametime Server 8.2 および 8.5
  • Cisco Webex Connect Release 6
  • GoogleTalk
  • Cisco Unified CallManager Release 8.x
  • XMPP 標準に準拠したその他のサーバ
  • IM and Presence では、IM and Presence Release 9.0 の企業配置と Cisco Unified Presence Release 7.0(x) の企業配置の間のフェデレーションはサポートされていません。
  • IM and Presence では、TCP を介した GoogleTalk とのフェデレーションはサポートされていますが、 TLS を介した GoogleTalk とのフェデレーションはサポートされていません。

次の図は、IM and Presence の企業配置と Microsoft OCS の企業配置との間の SIP フェデレーテッド ネットワークの具体例を示したものです。

図 1. IM and Presence と Microsoft OCS の間の基本的な SIP フェデレーテッド ネットワーク



この図では、各内部企業ドメインがそれぞれの DMZ エッジ サーバとセキュアな TLS 接続を使用して、パブリック インターネット経由で相互接続しています。 内部の IM and Presence の企業配置では、Cisco Adaptive Security Appliance(ASA)によってファイアウォール、ポート アドレス変換(PAT)、および TLS プロキシ機能が実現されています。 Cisco Adaptive Security Appliance(ASA)では、外部ドメインからの着信トラフィックが、指定された IM and Presence サーバへルーティングされます。

次の図は、IM and Presence の企業配置と IBM Sametime の企業配置との間の XMPP フェデレーテッド ネットワークの具体例を示したものです。 XMPP フェデレーションでは、TLS はオプションです。 XMPP フェデレーションの場合、Cisco Adaptive Security Appliance(ASA)はファイアウォールとしてのみ機能し、TLS プロキシ機能や PAT を実行する役割は果たしません。

図 2. IM and Presence と IBM Sametime の間の基本的な XMPP フェデレーテッド ネットワーク



IM and Presence の内部企業配置には DNS サーバが 2 つ存在します。 一方の DNS サーバは、IM and Presence のプライベート アドレスをホストします。 もう一方の DNS サーバは、SIP フェデレーションに使用する IM and Presence のパブリック アドレスと DNS SRV レコード(_sipfederationtls)、および IM and Presence との XMPP フェデレーションに使用する DNS SRV レコード(_xmpp-server)をホストします。 IM and Presence のパブリック アドレスをホストする DNS サーバは、ローカルの DMZ に配置します。

AOL との SIP フェデレーション

AOL フェデレーションを使用する場合の制限事項

AOL コミュニティ(aol.com、aim.com)のユーザは、既存の電子メール アドレスを AOL の画面名として使用することができます。 既存の電子メール アドレスとは、gmail.com、yahoo.com、msn.com などの一般的な電子メール プロバイダで現在使用している電子メール アドレスのことです。 このシナリオの場合、AOL では、これらのユーザに対して user(gmail.com)@aol.com などのアドレスを割り当てる際、マッピングされた JID が必要となります。また AOL からは修正された JID が送信されます。

たとえば、AOL では次のようにして、画面名「user@gmail.com」を基にしたアドレスがユーザに割り当てられます。

SUBSCRIBE sip:user(gmail.com)@aol.com SIP/2.0From: sip:user@cisco.com;tag=
To: sip:user(gmail.com)@aol.com

AOL からは、このユーザの修正済み JID が送信されます。

SUBSCRIBE sip:user@cisco.com SIP/2.0From: sip:user(gmail.com)@aol.com ;tag=
To: sip:user@cisco.com

AOL との SIP フェデレーションを導入する場合、IM and Presence では、画面名としてユーザ ID ではなく電子メール アドレスを使用するこのような AOL ユーザはサポートされません。

なお AOL のルーティングは OCS のルーティングとは異なり、SIP レコード ルートには従いません。AOL からのすべての要求は、それらが元々その他の IM and Presence ノードから送信されたものであっても、ルーティング用の IM and Presence サーバに送信されます。 そのため、AOL フェデレーションを設定すると、OCS とのフェデレーションの場合に比べて、フェデレーションのルーティングを行う IM and Presence サーバの負荷が大きくなる場合があります。

クラスタ間配置とマルチノード配置


(注)  


このマニュアルに記載されている IM and Presence のクラスタ間配置に関連した設定手順はすべて、IM and Presence のマルチノード配置にも適用することができます。


SIP フェデレーション配置

IM and Presence のクラスタ間配置およびマルチノード クラスタ配置では、外部ドメインで新しいセッションが開始されると、Cisco Adaptive Security Appliance(ASA)により、ルーティング用として指定された IM and Presence サーバにすべてのメッセージがルーティングされます。 ルーティング用の IM and Presence サーバが受信ユーザをホストしていなければ、そのメッセージはクラスタ間通信を介してクラスタ内の適切な IM and Presence サーバへルーティングされます。 またこの要求に対する応答はすべて、ルーティング用の IM and Presence サーバを経由してルーティングされます。

いずれの IM and Presence サーバも、Cisco Adaptive Security Appliance(ASA)を介して外部ドメインにメッセージを送信することが可能です。 OCS では、これらのメッセージに対して外部ドメインから応答があると、Cisco Adaptive Security Appliance(ASA)を介してメッセージを送信した IM and Presence サーバにその応答が直接返送されます。 この動作は、Cisco Adaptive Security Appliance(ASA)上でポート アドレス変換(PAT)を設定すると有効になります。 ただし AOL フェデレーションの場合、応答はすべてルーティング用の IM and Presence サーバを経由してルーティングされます。 200 OK 応答メッセージに対しては PAT が必要となるため、Cisco Adaptive Security Appliance(ASA)上で PAT を設定することをお勧めします。

XMPP フェデレーション配置

単一のクラスタの場合、クラスタ内の 1 ノードでのみ XMPP フェデレーションをイネーブルにする必要があります。 パブリック DNS では、その企業に対してただ 1 つの DNS SRV レコードがパブリッシュされます。 この DNS SRV レコードは、XMPP フェデレーションが有効な IM and Presence ノードにマッピングされます。 外部ドメインからの着信要求はすべて、パブリッシュされた SRV レコードに基づいて、XMPP フェデレーションが実行されているノードにルーティングされます。 これらの要求は、内部的には IM and Presence により、各ユーザにとって適切なノードにルーティングされます。 また IM and Presence では、発信要求はすべて、XMPP フェデレーションが実行されているノードを経由してルーティングされます。

規模を拡大する場合や、複数の IM and Presence クラスタをパブリッシュしたのに伴って XMPP フェデレーションを各クラスタにつき少なくとも 1 つずつ有効にする必要がある場合などには、複数の DNS SRV レコードをパブリッシュすることもできます。 XMPP フェデレーションでは、SIP フェデレーションとは異なり、IM and Presence が配置された企業ドメインに対してエントリ ポイントがただ 1 つである必要はありません。 そのため IM and Presence では、パブリッシュされているノードのうち XMPP フェデレーションが有効であるいずれのノードに対しても、着信要求をルーティングすることができます。

IM and Presence のクラスタ間配置およびマルチノード クラスタ配置では、外部の XMPP フェデレーテッド ドメインで新しいセッションが開始されると、その要求のルーティング先を決定するため DNS SRV ルックアップが実行されます。 複数の DNS SRV レコードをパブリッシュした場合、DNS ルックアップでは複数の結果が返されます。IM and Presence では、DNS でパブリッシュされたいずれのサーバへも、要求をルーティングすることができます。 これらの要求は、内部的には IM and Presence により、各ユーザにとって適切なノードにルーティングされます。 IM and Presence では、発信される要求は、XMPP フェデレーションが実行されているクラスタ内のいずれかのノードを経由してルーティングされます。

XMPP フェデレーションを実行しているノードが複数ある場合は、パブリック DNS 内でパブリッシュするノードを 1 つだけ選択することもできます。 この設定の場合、IM and Presence では、XMPP フェデレーションが実行されているすべてのノードを対象に、着信要求のロードバランシングが行われることはなく、着信要求はすべて、選択されたそのノードを経由してルーティングされます。 発信要求については、IM and Presence によってロードバランシングが行われ、XMPP フェデレーションが実行されているクラスタ内のあらゆるノードを経由して送信されます。

ハイ アベイラビリティとフェデレーション

SIP フェデレーションのハイ アベイラビリティ


(注)  


ハイ アベイラビリティは、IM and Presence Release 8.5 以降でのみサポートされています。


Microsoft OCS の企業とフェデレーションを行う場合、Microsoft のアクセス エッジ サーバでは、ホスト名とサーバ アドレスをそれぞれ 1 つだけ返す DNS SRV ルックアップしか実行できません。 また Microsoft のアクセス エッジ サーバでは、手動でプロビジョニングできる IP アドレスはただ 1 つです。

そのため、Microsoft OCS とのフェデレーションにおいてハイ アベイラビリティを実現するためには、以下の図のように IM and Presence サーバと Cisco Adaptive Security Appliance(ASA)との間にロード バランサを配置する必要があります。 ロード バランサは、Cisco Adaptive Security Appliance(ASA)からの着信 TLS 接続を終端したうえで、TLS 接続を新たに開始して適切なバックエンド IM and Presence サーバへデータをルーティングします。 現在 TLS をサポートしているのは Cisco CSS11506 Content Services Switch のみです。

同様に、AOL とのフェデレーションにおいてハイ アベイラビリティを実現する場合も、以下の図のように IM and Presence サーバと Cisco Adaptive Security Appliance(ASA)との間にロード バランサを配置する必要があります。

図 3. IM and Presence と Microsoft OCS との間のフェデレーテッド ネットワークに対するハイ アベイラビリティの実現



関連情報

XMPP フェデレーションのハイ アベイラビリティ

XMPP フェデレーションのハイ アベイラビリティには、IM and Presence のその他の機能に対するハイ アベイラビリティとは異なる点があります。それは 2 ノード サブクラスタ モデルには限定されないという点です。

XMPP フェデレーションに対してハイ アベイラビリティを実現するためには、クラスタ内の 2 つ以上の IM and Presence ノードに対して XMPP フェデレーションを有効にする必要があります。複数のノードに対して XMPP フェデレーションを有効にすることで、規模が拡大されるだけでなく、いずれかのノードに障害が発生したときのための冗長性が確保されます。

発信要求のルーティングに対するハイ アベイラビリティ

IM and Presence では、クラスタ内部のユーザからの発信要求について、XMPP フェデレーションが有効になっているクラスタ内のすべてのノードに対して均等にロードバランシングが行われます。 いずれかのノードで障害が発生すると、発信トラフィックは IM and Presence によって、クラスタ内に存在する残りのノード全体に動的に分散されます。

着信要求のルーティングに対するハイ アベイラビリティ

着信要求のルーティングに対してハイ アベイラビリティを実現するためには、さらなる対処が必要です。 IM and Presence のローカル配置を外部ドメインから検出できるようにするためには、パブリック DNS サーバ上で DNS SRV レコードをパブリッシュする必要があります。 このレコードから、XMPP フェデレーションの有効なノードが解決されます。 外部ドメインは、解決されたそのアドレスに接続します。

このモデルでハイ アベイラビリティを実現するためには、IM and Presence のローカル配置に対して複数の DNS SRV レコードをパブリッシュする必要があります。 これらの各レコードは、IM and Presence のローカル配置内のノードのうち XMPP フェデレーションの有効なノードに解決されます。

ローカル配置に対する DNS SRV レコードは、これらのレコードの中から選択されます。 XMPP フェデレーションが有効になっているノードに障害が発生した場合、外部システムは別のノードを選択し、そのノードから IM and Presence のローカル配置に接続することになります。


(注)  


  • パブリッシュされた DNS SRV レコードの優先度および重み付けはすべて同じであることが必要です。 これにより、パブリッシュされたすべてのレコードに対して負荷を分散することができるうえ、外部システムでは障害発生時に DNS SRV レコードに対応する他のいずれかのノードに正しく再接続することができます。
  • DNS SRV レコードは、XMPP フェデレーションが有効になっているすべてのノードに対してパブリッシュできるほか、その一部に対してのみパブリッシュすることもできます。 パブリッシュされたレコードの数が多いほど、着信要求の処理に関するシステムの冗長性は高くなります。
  • XMPP フェデレーション配置の IM and Presence サーバ上でチャット機能を設定した場合は、チャット ノード エイリアスに対して複数の DNS SRV レコードをパブリッシュできます。 それにより外部システムでは、XMPP フェデレーションが有効ないずれかのノードで障害が発生した場合に、XMPP フェデレーションが有効な他のノードを経由してその特定のチャット ノードに達する別の着信ルートを検索することができます。 ただし、これはチャット機能そのものに対するハイ アベイラビリティではなく、チャット ノード エイリアス宛ての着信要求に対する XMPP フェデレーションのハイ アベイラビリティ機能を拡張したものです。

IBM Sametime フェデレーション

IM and Presence Release 9.0 では、IM and Presence の企業と IBM Sametime の企業とのドメイン間フェデレーションに対するハイ アベイラビリティはサポートされていません。 これは、IBM Sametime が DNS SRV ルックアップにより返された別のレコードに対して再試行を行わないためです。 試行の対象となるのは最初に検出された DNS SRV レコードのみで、接続試行に失敗しても、重み付けの低いノードに対する再試行は行われません。


(注)  


IBM Sametime フェデレーション配置の IM and Presence でも、状況によっては XMMP フェデレーションのハイ アベイラビリティが実現されているように見えることがあります。 それは、重大なサービス障害に伴ってユーザがバックアップ ノードにフェールオーバーしても、プライマリ ノードでは引き続き Cisco XCP XMPP Federation Connection Manager が実行されているという状況です。 この場合、着信トラフィックはこれまでどおりプライマリ ノードに転送され、その後ルータ間接続を使用してバックアップ ノードにリダイレクトされます。 そしてこのシナリオでは、XMPP フェデレーションは停止することなく、通常どおりの動作が続行されます。


GoogleTalk フェデレーション

IM and Presence サービスでは、IM and Presence が配置された企業と GoogleTalk との間のドメイン間フェデレーションに対するハイ アベイラビリティはサポートされていません。

Cisco Adaptive Security Appliance(ASA)の配置オプション

IM and Presence の内部企業配置では、Cisco Adaptive Security Appliance(ASA)によってファイアウォール、ポート アドレス変換(PAT)、および TLS プロキシ機能が DMZ 内に実現されています。これにより、ハブリック インターネットからの着信接続を終端するとともに、特定のフェデレーテッド ドメインからのトラフィックを許可することができます。


(注)  


XMPP フェデレーション配置の場合、Cisco Adaptive Security Appliance(ASA)によって実現されるのはファイアウォール機能だけです。 すでにファイアウォールが配置されている場合は、XMPP フェデレーション用として Cisco Adaptive Security Appliance(ASA)を追加する必要ありません。


Cisco Adaptive Security Appliance(ASA)には、既存のネットワーク、および導入する必要があるファイアウォール機能の種類に応じて、さまざまな配置方法があります。 ここでは、推奨される配置モデルの概要についてのみ説明します。 詳細については、Cisco Adaptive Security Appliance(ASA)のマニュアルに記載されている展開に関するガイドラインを参照してください。 ここで説明する Cisco Adaptive Security Appliance(ASA)の配置オプションは、SIP フェデレーションに適用されるものです。

Cisco Adaptive Security Appliance(ASA)は以下の 2 つの図のように、インスタント メッセージ(IM)のトラフィックやプレゼンスのトラフィックなどさまざまなトラフィックを保護する企業ファイアウォールとして配置することができます。 これはコスト効率が最も高く、新しいネットワークにも既存のネットワークにも推奨される配置方法です。 また、Cisco Adaptive Security Appliance(ASA)を既存のファイアウォールと並行して配置することもできます(次の図を参照)。 このように配置した場合、Cisco Adaptive Security Appliance(ASA)では、IM and Presence とパブリック インターネットの間の IM and Presence トラフィックが処理され、既存のトラフィックにはそのまま既存のファイアウォールが使用されます。 次の図では、配置された Cisco Adaptive Security Appliance(ASA)IM and Presence サーバに対するゲートウェイとしても機能しています。そのため、Cisco Adaptive Security Appliance(ASA)にトラフィックを転送するためのルートを別途用意する必要はありません。

図 4. 既存の NAT/ファイアウォールと並行して Cisco ASA 5500 を配置する方法



既存のファイアウォールの背後に Cisco Adaptive Security Appliance(ASA)を配置することもできます。 この場合は、IM and Presence 宛てのトラフィックが Cisco Adaptive Security Appliance(ASA)へ転送されるように既存のファイアウォールを設定します(次の図を参照)。 このように配置した場合、Cisco Adaptive Security Appliance(ASA)IM and Presence サーバに対するゲートウェアとして機能します。

図 5. 既存の NAT/ファイアウォールの背後に Cisco ASA 5500 を配置する方法



プレゼンス サブスクリプションとブロッキング レベル

「x@foreigndomain.com」から「user@local.com」への新たなプレゼンス サブスクリプションはすべて、Cisco Adaptive Security Appliance(ASA)を経由して送信されます(以下の図を参照)。 Cisco Adaptive Security Appliance(ASA)では、許可されている外部ドメインのリストと着信 SIP サブスクリプションとの照合確認が行われます。 許可されていないドメインのプレゼンス サブスクリプションは Cisco Adaptive Security Appliance(ASA)により拒否されます。


(注)  


XMPP フェデレーション配置の場合、Cisco Adaptive Security Appliance(ASA)ではドメインの確認は行われません。


IM and Presence では、着信サブスクリプションを受信すると、その外部ドメインが許可フェデレーテッド ドメインに該当するかどうか検証が行われます。許可フェデレーテッド ドメインは IM and Presence サーバにおいて管理レベルで定義します。 SIP フェデレーションの場合は、フェデレーテッド ドメインを設定します。 XMPP フェデレーションの場合は、XMPP フェデレーションに関する管理者ポリシーを定義します。 許可ドメイン以外から受信したサブスクリプションは、IM and Presence により(ローカル ユーザに通知されることなく)拒否されます。

許可ドメインからサブスクリプションを受信した場合、IM and Presence ではローカル ユーザの承認ポリシーが確認された後、そのローカル ユーザが過去にフェデレーテッド ドメイン、またはプレゼンス サブスクリプションの送信ユーザをブロックまたは許可したことがあるかどうか検証が行われます。 その上で IM and Presence では、その着信サブスクリプションがいったん受け取られ、保留状態に置かれます。

ここで、「x@foreigndomain.com」からプレゼンスの閲覧要求があることをローカル ユーザに通知するため、IM and Presence からクライアント アプリケーションに対してサブスクリプションに関する通知メッセージが送信されます。 これを受けてクライアント アプリケーションには、ローカル ユーザがサブスクリプションを許可または拒否することができるダイアログ ボックスが表示されます。 ユーザが承認または拒否の決定を下すと、クライアント アプリケーションから IM and Presence に対してその決定内容が通知されます。 承認または拒否の決定は、IM and Presence に保存されているユーザのポリシー リストに追加されます。


(注)  


サードパーティの XMPP クライアントでは、サブスクリプションが受け取られるだけで、ユーザのポリシー リストが更新されることはありません。 ユーザは、IM and Presence のユーザ オプション インターフェイスで、各自のプライバシー リストを手動で更新できます。


拒否の決定が下されると、ポライト ブロッキングの措置が取られます。この場合、その外部クライアントに対してユーザのプレゼンス ステータスが「オフライン」と表示されます。 ローカル ユーザがサブスクリプションを許可した場合は、IM and Presence から外部ウォッチャに最新のプレゼンス情報が送信されます。

ユーザは、サブスクリプションをユーザ単位およびドメイン単位でブロックすることもできます。 その設定は、IM and Presence のユーザ オプション インターフェイスおよび Cisco Jabber クライアントから行えます。

図 6. 着信 SIP プレゼンス メッセージのフロー



IM and Presence からは、すべての発信サブスクリプションが Cisco Adaptive Security Appliance(ASA) を経由して送信されます。Cisco Adaptive Security Appliance(ASA) では、これらのサブスクリプションが外部ドメインへ転送されます。 その外部ドメインの同じ外部ユーザと、別のローカル ユーザとの間にアクティブなサブスクリプションがすでに存在する場合でも、IM and Presence からは発信サブスクリプションが送信されます。 次の図は、発信プレゼンス サブスクリプションのフローを図示したものです。

クライアント アプリケーションの連絡先リストおよび IM and Presence のユーザ オプション インターフェイスには、外部ユーザが「user@foreigndomain.com」として追加されます。


(注)  


XMPP フェデレーションの場合、Cisco Adaptive Security Appliance(ASA)でのドメイン レベル認証チェックは行われません。


図 7. 発信プレゼンス要求のフロー




(注)  


  • Microsoft OCS では、サブスクライブ更新が 1 時間 45 分間隔で実行されます。 そのため、IM and Presence サーバが再起動すると、Microsoft Office Communicator クライアントでは、IM and Presence コンタクトのプレゼンス ステータスのない状態が最長で 2 時間前後続きます。
  • また Microsoft OCS が再起動した場合は、IM and Presence クライアントで、Microsoft Office Communicator コンタクトのプレゼンス ステータスがない状態が最長で 2 時間前後続きます。

在席ステータスのマッピング

Microsoft OCS の在席ステータスのマッピング

次の表は、Microsoft Office Communicator から IM and Presence、サードパーティの XMPP クライアント、および Cisco Jabber への在席ステータスのマッピング状況をまとめたものです。

表 1 Microsoft Office Communicator の在席ステータスのマッピング

Microsoft Office Communicator

設定

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

Cisco Jabber Release 8.x での設定

Available

Available

Available

Busy

Away

Busy

Do Not Disturb

Away

Busy

Be Right Back

Away

Away

Away

Away

Away

Offline

Offline

Offline

この表の中で、Microsoft Office Communicator の「ビジー(Busy)」および「サイレント」の各ステータスはいずれも「退席中」にマッピングされており、サードパーティの XMPP クライアントでは「ビジー(Busy)」というステータスとして表されています。 XMPP クライアントでは、この「退席中」ステータスの表示方法がそれぞれで異なります。たとえば、テキストのない「退席中」アイコンとして表示される XMPP クライアントもあれば、 「ビジー(Busy)」というテキストが付記された「退席中」アイコンとして表示される XMPP クライアントもあります。

次の表は、Cisco Jabber Release 8.x から Microsoft Office Communicator に対する在席ステータスのマッピング状況を示したものです。

表 2 Cisco Jabber Release 8.x の在席ステータスのマッピング

Cisco Jabber

Release 8.x での設定

Microsoft Office Communicator

設定

Available

Available

Busy

Busy

Do Not Disturb

Busy

Offline

Offline

次の表は、IM and Presence に接続されたサードパーティの XMPP クライアントから Microsoft Office Communicator への在席ステータスのマッピング状況を示したものです。

表 3 サードパーティの XMPP クライアントの在席ステータスのマッピング

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

Microsoft Office Communicator

設定

Available

Available

Away

Away

Extended Away

Away

Do Not Disturb

Busy

Offline

Offline

Microsoft Lync の在席ステータスのマッピング

次の表は、Microsoft Lync から IM and Presence、サードパーティの XMPP クライアント、および Cisco Jabber への在席ステータスのマッピング状況をまとめたものです。

表 4 Microsoft Lync の在席ステータスのマッピング

Microsoft Lync

設定

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

 Cisco Jabber

Release 8.x での設定

Available

Available

Available

Busy

Away

Busy

Do Not Disturb

Away

Busy

Be Right Back

Away

Away

Away

Away

Away

Offline

Offline

Offline

この表の中で、Lync クライアントの「ビジー(Busy)」および「サイレント」の各ステータスはいずれも「退席中」にマッピングされており、サードパーティの XMPP クライアントでは「ビジー(Busy)」というステータスとして表されています。 XMPP クライアントでは、この「退席中」ステータスの表示方法がそれぞれで異なります。たとえば、テキストのない「退席中」アイコンとして表示される XMPP クライアントもあれば、 「ビジー(Busy)」というテキストが付記された「退席中」アイコンとして表示される XMPP クライアントもあります。

次の表は、Cisco Jabber Release 8.x から Lync クライアントへの在席ステータスのマッピング状況を示したものです。

表 5 Cisco Jabber Release 8.x の在席ステータスのマッピング

Cisco Jabber 

Release 8.x での設定

Microsoft Lync

設定

Available

Available

Busy

Busy

Do Not Disturb

Busy

Offline

Offline

次の表は、IM and Presence に接続されたサードパーティの XMPP クライアントから Lync クライアントへの在席ステータスのマッピング状況を示したものです。

表 6 サードパーティの XMPP クライアントの在席ステータスのマッピング

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

Microsoft Lync

設定

Available

Available

Away

Away

Extended Away

Away

Do Not Disturb

Busy

Offline

Offline

AOL Instant Messenger の在席ステータスのマッピング

次の表は、AOL Instant Messenger から Cisco Jabber への在席ステータスのマッピング状況を示したものです。

表 7 AOL Instant Messenger から Cisco Jabber への在席ステータスのマッピング

AOL Instant Messenger

設定

Cisco Jabber

Release 8.x での設定

Available

Available

Away

Away

Invisible

Offline

Offline

Offline

次の表は、Cisco Jabber から AOL Instant Messenger への在席ステータスのマッピング状況を示したものです。

表 8 Cisco Jabber から AOL Instant Messenger への在席ステータスのマッピング

Cisco Jabber Release 8.x での設定

AOL Instant Messenger

Available

Available

Do Not Disturb

Away

Busy

Away

Idle

Away

Offline

Offline

XMPP フェデレーションの在席ステータスのマッピング

次の表は、IBM Sametime 8.2 から IM and Presence 上のサードパーティの XMPP クライアント、および Cisco Jabber への在席ステータスのマッピング状況を示したものです。

表 9 IBM Sametime 8.2 クライアントの在席ステータスのマッピング

IBM Sametime クライアントでの設定

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

Cisco Jabber

Release 8.x での設定

Available

Available

Available(ステータス メッセージも表示)

Do Not Disturb

Do Not Disturb

Do Not Disturb(ステータス メッセージも表示)

Available(「In a meeting」ステータスも表示)

Available(「In a meeting」ステータスも表示)

Available(ステータス メッセージも表示)

Away

Away

Away(ステータス メッセージも表示)

Offline

Offline

Offline

次の表は、webex Connect から IM and Presence 上のサードパーティの XMPP クライアント、および Cisco Jabber への在席ステータスのマッピング状況を示したものです。

表 10 Webex Connect の在席ステータスのマッピング

Webex Connect での設定

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

Cisco Jabber

Release 8.x での設定

Available

Available

Available

Do Not Disturb

Do Not Disturb

Do Not Disturb

Away(「In a meeting」ステータスも表示)

Available(「In a meeting」ステータスも表示)

Away(「In a meeting」ステータスも表示)

Away

Away

Away

Offline

Offline

Offline

次の表は、Cisco Jabber Release 8.x からフェデレーションが有効な他のクライアントへの在席ステータスのマッピング状況を示したものです。

表 11 Cisco Jabber Release 8.x の在席ステータスのマッピング

Cisco Jabber Release 8.x での設定

フェデレーションが有効な Cisco Jabber Release 8.x での設定

フェデレーションが有効な(IM and Presence に接続されている)サードパーティの XMPP クライアントでの設定

Webex Connect クライアントでの設定

IBM Sametime クライアント サーバ

Available

Available

Available

Available

Available

Do Not Disturb

Do Not Disturb

Do Not Disturb

Do Not Disturb

Do Not Disturb

Busy

Busy

Away

Idle

Away

Idle

Idle

Idle

Idle

Idle

Offline

Offline

Offline

Offline

Offline

次の表は、IM and Presence 上のサードパーティの XMPP クライアントからフェデレーションが有効な他のクライアントへの在席ステータスのマッピング状況を示したものです。

表 12 IM and Presence に接続されている XMPP クライアントの在席ステータスのマッピング

IM and Presence に接続された)サードパーティの XMPP クライアントでの設定

フェデレーションが有効な Cisco Jabber Release 8.x での設定

フェデレーションが有効な(IM and Presence に接続されている)XMPP クライアントでの設定

Webex Connect クライアントでの設定

IBM Sametime クライアント サーバ

Available

Available

Available

Available

Available

Do Not Disturb

Do Not Disturb

Do Not Disturb

Do Not Disturb

Do Not Disturb

Away

Away

Away

Away

Away

Extended Away

Away

Extended Away

Extended Away

Away

Away(「Idle」ステータスも表示)

Idle

Away(「Idle」ステータスも表示)

Away(「Idle」ステータスも表示)

Away(「Idle」ステータスも表示)

Offline

Offline

Offline

Offline

Offline

インスタント メッセージ

SIP フェデレーションに関するインスタント メッセージのフロー

2 つの企業配置間でインスタント メッセージ(IM)を送信する場合には、セッション モードが使用されます。 外部ドメインのユーザが IM and Presence ドメインへ IM を送信する場合は、次の図のように、外部サーバから INVITE メッセージが送信されます。 この INVITE メッセージは、Cisco Adaptive Security Appliance(ASA) によって IM and Presence に転送されます。 IM and Presence では外部サーバに対し 200 OK メッセージが返送され、外部サーバからはテキスト データを含む SIP メッセージが送信されます。 IM and Presence では、適切なプロトコルを使用して、ローカル ユーザのクライアント アプリケーションにそのテキスト データが転送されます。

図 8. 着信インスタント メッセージのフロー



IM and Presence ドメインのローカル ユーザが外部ドメインのユーザに IM を送信する場合、その IM は IM and Presence サーバへ送信されます。 これらの両ユーザ間にまだ IM セッションが確立されていない場合は、新しいセッションを確立するために IM and Presence から外部ドメインに INVITE メッセージが送信されます。 以下の図は、このフローを図示したものです。 IM and Presence では、これ以降両ユーザから送信されるメッセージ トラフィックはいずれも、このセッションを使用して処理されます。 ただし、Cisco Jabber およびサードパーティの XMPP クライアントについては、ステータスが「利用可能」でない場合でもそれらのユーザは IM を開始することができます。

図 9. 発信インスタント メッセージのフロー




(注)  


IM and Presence では、Microsoft OCS コンタクトを使用した 3 者間 IM セッション(グループ チャット)はサポートされていません。


関連資料

XMPP フェデレーションに関する在席情報およびインスタント メッセージのフロー

IM and Presence のマルチノード配置の場合、XMPP フェデレーションに関する在席情報およびインスタント メッセージは、設定方法に応じて着信/発信フローに違いがあります。

マルチノード配置では、クラスタ内の各ノードで XMPP フェデレーションを有効にできるほか、クラスタ内のいずれか 1 つのノードでのみ XMPP フェデレーションを有効にすることも可能です。 さらに DNS SRV レコードについても、いずれか 1 つだけをパブリッシュすることも、複数のレコード(ただし XMPP フェデレーションを有効にしたノードごとに 1 つずつ)をパブリッシュすることもできます。

DNS SRV レコードを 1 つだけパブリッシュした場合は、そのレコードに対応するただ 1 つのノードにすべての着信要求がルーティングされ、内部的には IM and Presence によりクラスタ間ルーティングを使用して正しいノードにトラフィックがルーティングされます(次の図を参照)。 複数の DNS SRV レコードをパブリッシュした場合は、SRV レコードの設定方法に応じて、各ノードに対して着信要求のロードバランシングが行われます。

図 10. XMPP 着信要求のフロー



発信要求については、IM and Presence から、XMPP フェデレーションが有効なクラスタ内のいずれのノードにもルーティングされます。そのノードは、要求を送信したユーザのホーム ノードである必要はありません。

図 11. XMPP 発信要求のフロー



関連資料

フェデレーションとサブドメイン

IM and Presence では、次のようなサブドメインのシナリオがサポートされています。

  • IM and Presence は外部ドメインのサブドメインに属しています。 たとえば、IM and Presence は「cup.cisco.com」というサブドメインに属しているとします。 IM and Presence は、「cisco.com」というドメインに属する外部企業とフェデレーションを行っています。 この場合、IM and Presence ユーザには「cupuser@cup.cisco.com」という URI に割り当てられ、外部ユーザには「foreignuser@cisco.com」という URI が割り当てられます。
  • IM and Presence は親ドメインに属し、外部企業はその親ドメインのサブドメインに属しています。 たとえば、IM and Presence は「cisco.com」というドメインに属しているとします。 IM and Presence は、「foreign.cisco.com」というサブドメインに属する外部企業とフェデレーションを行っています。 この場合、IM and Presence ユーザには「cupuser@cisco.com」という URI に割り当てられ、外部ユーザには「foreignuser@foreign.cisco.com」という URI が割り当てられます。
  • IM and Presence と外部企業は、それぞれ別々のサブドメインに属していますが、どちらのサブドメインも親ドメインは同じです。 たとえば、IM and Presence は「cup.cisco.com」というサブドメイン、外部企業は「foreign.cisco.com」というサブドメインに属しているとします。 また、どちらのサブドメインも「cisco.com」という親ドメインに属しているとします。 この場合、IM and Presence 遊佐には「cupuser@cup.cisco.com」という URI が割り当てられ、外部ユーザには「foreignuser@foreign.cisco.com」という URI が割り当てられます。

サブドメインとフェデレーションを行う場合は、DNS ドメインを別途設定するだけで十分です。Active Directory を分割する必要はありません。 企業内部でフェデレーションを設定する場合、IM and Presence ユーザまたは外部ユーザを同じ Active Directory ドメインに所属させることができます。 たとえば上記 3 番目のシナリオの場合、Active Directory が親ドメイン「cisco.com」に属しているとします。 各ユーザは「cup.cisco.com」と「foreign.cisco.com」のどちらかのサブドメインに所属し、かつ「cupuser@cup.cisco.com」と「foreignuser@foreign.cisco.com」のどちらかの URI が割り当てられていますが、このような場合でもすべてのユーザを「cisco.com」ドメイン配下の Active Directory に設定することが可能です。

ただし、Cisco Jabber から LDAP 検索を実行すると、他のドメインまたはサブドメインのユーザが返される場合がありますが、Cisco Jabber ユーザが Cisco Jabber での LDAP ルックアップからこれらのフェデレーション ユーザを追加することはできません。 Cisco Jabber ユーザは、これらのユーザを外部(フェデレーション)コンタクトとして追加する必要があります。これにより IM and Presence では、ローカル ドメインではなく正しいドメインが使用されます。


(注)  


IM and Presence では、IM and Presence の 2 つの企業配置の間にフェデレーションを設定する場合にも、上記のシナリオがサポートされています。