Cisco Unified Communications Manager Release 10.5(1)の IM and Presence サービスに対するドメイン間フェデレーション
この統合の概要
この統合の概要

目次

この統合の概要

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

この統合により、IM and Presence Service が外部ドメイン ユーザとアベイラビリティ情報やインスタント メッセージング(IM)を交換したどのドメイン内からの IM and Presence Service ユーザもイネーブルにします。 異なる外部ドメインと連携するために、IM and Presence Service が異なるプロトコルを使用します。

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

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


    (注)  


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


  • AOL SIP Access Gateway(SAG)


    (注)  


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

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

    • AOL パブリック コミュニティ(aim.com、aol.com など)のユーザ。

    • ドメインが AOL によってホストされている企業のユーザ。

    • AOL とフェデレーションを行っている外部企業のユーザ。 IM and Presence Service では、こうした外部企業とフェデレーションを行う際、AOL をクリアリング ハウスとして使用することもできます。


IM and Presence Service では、以下とのフェデレーションに対しては、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 ServiceIM and Presence Service Release 9.0 Enterprise と Cisco Unified Presence Release 7.0(.x)Enterprise 間のフェデレーションをサポートしていません。
  • IM and Presence Service では、TCP を介した GoogleTalk とのフェデレーションがサポートされます。 TLS を介した GoogleTalk との XMPP フェデレーションはサポートされていません。

  • TCP での Google と連携する場合、Google が Google アプリケーション サブスクリプションがあるドメインを持つフェデレーションを許可しません。


(注)  


外部ドメインを使用して、XMPP フェデレーションをイネーブルにする場合、外部ドメインが Cisco Unified Presence の SIP フェデレーション ドメインとして設定されていないことを確認します。

例: example.com の Cisco Unified Presence 配置は、SIP ベースのフェデレーションとして過去に設定されています。 ただし、example.com には XMPP サポートが追加されたため、ローカル管理者は代わりに XMPP ベースのフェデレーションを有効化することを希望しています。 この機能を使用するには、ローカル管理者は Cisco Unified Presence で SIP フェデレーション ドメインとして example.com を最初に削除する必要があります。


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

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



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

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

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



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

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

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

AOL コミュニティ(aol.com、aim.com)のユーザは、既存の電子メール アドレスを AOL の画面名として使用することができます。 既存の電子メール アドレスとは、gmail.comyahoo.commsn.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 Service の導入では、外部ドメインが新しいセッションを開始すると、Cisco Adaptive Security Appliance がすべてのメッセージをルーティング用に指定された IM and Presence Service ノードにルーティングします。 IM and Presence Service ルーティング ノードが受信ユーザをホストしていない場合は、クラスタ間通信を介してクラスタ内の適切な IM and Presence Service ノードにメッセージをルーティングします。 システムは、ルーティング IM and Presence Service ノードを介して、この要求に関連付けられたすべての応答をルーティングします。

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

XMPP フェデレーション配置

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

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

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

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

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

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


(注)  


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


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

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

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

図 3. ハイ アベイラビリティのある IM and Presence Service と 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 レコードと他のノードの 1 個に再接続できます。
  • 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@externaldomain.com から user@local.com への新たなプレゼンス サブスクリプションはすべて、Cisco Adaptive Security Appliance により送信されます(以下の図を参照)。 Cisco Adaptive Security Appliance では、許可されている外部ドメインのリストと着信 SIP サブスクリプションとの照合確認が行われます。 許可されていないドメインのプレゼンス サブスクリプションは Cisco Adaptive Security Appliance により拒否されます。


(注)  


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


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

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

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

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

ユーザは、サブスクリプションをユーザ単位およびドメイン単位でブロックすることもできます。 これは、Cisco Jabber クライアントで設定できます。

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



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

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


(注)  


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


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




(注)  


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


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

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

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

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

Microsoft Office Communicator

設定

IM and Presence Service に接続された)サードパーティの 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 Service に接続されたサードパーティの XMPP クライアントから Microsoft Office Communicator への在席ステータスのマッピング状況を示したものです。

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

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

Microsoft Office Communicator

設定

連絡可能(Available)

連絡可能(Available)

退席中(Away)

退席中(Away)

退席中(延長)(Extended Away)

退席中(Away)

応答不可(Do Not Disturb)

ビジー(Busy)

オフライン(Offline)

オフライン(Offline)

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

次の表は、Microsoft Office Communicator から 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 Service 上のサードパーティの XMPP クライアント、および Cisco Jabber への在席ステータスのマッピング状況を示したものです。

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

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

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

Cisco Jabber

Release 8.x での設定

連絡可能(Available)

連絡可能(Available)

応答可能(ステータスメッセージも表示)(Available with status message)

応答不可(Do Not Disturb)

応答不可(Do Not Disturb)

応答不可(ステータスメッセージも表示)(Do Not Disturb with status message)

連絡可能(「会議中」ステータスも表示)(Available with status "In a meeting"

連絡可能(「会議中」ステータスも表示)(Available with status "In a meeting"

応答可能(ステータスメッセージも表示)(Available with status message)

退席中(Away)

退席中(Away)

退席中(ステータスメッセージも表示)(Away with status message)

オフライン(Offline)

オフライン(Offline)

オフライン(Offline)

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

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

Webex Connect での設定

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

Cisco Jabber

Release 8.x での設定

連絡可能(Available)

連絡可能(Available)

応答可能(Available)

応答不可(Do Not Disturb)

応答不可(Do Not Disturb)

応答不可(Do Not Disturb)

連絡可能(「会議中」ステータスも表示)(Available with status "In a meeting"

連絡可能(「会議中」ステータスも表示)(Available with status "In a meeting"

応答可能(「会議中」ステータスも表示)(Available with status "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 Service に接続されている)サードパーティの 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 Service 上のサードパーティの XMPP クライアントからフェデレーションが有効な他のクライアントへの在席ステータスのマッピング状況を示したものです。

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

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

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

フェデレーションが有効な(IM and Presence Service に接続されている)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 with status "Idle"

アイドル(Idle)

退席中(「アイドル」ステータスも表示)(Away with status "Idle"

退席中(「アイドル」ステータスも表示)(Away with status "Idle"

退席中(「アイドル」ステータスも表示)(Away with status "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 サービス ノードへ送信されます。 これらの 2 つのユーザ間にまだ既存の IM セッションが確立されていない場合は、新しいセッションを確立するために IM and Presence サービスから外部ドメインに INVITE メッセージが送信されます。 以下の図は、このフローを図示したものです。 IM and Presence サービスでは、これ以降両ユーザから送信されるメッセージ トラフィックはいずれも、このセッションを使用して処理されます。 ただし、Cisco Jabber およびサードパーティの XMPP クライアントについては、利用可能でない場合でもユーザは IM を開始することができます。

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




(注)  


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


関連資料

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

XMPP フェデレーションの着信/発信のアベイラビリティと IM 要求のフローは、IM and Presence サービスのマルチノード配置で違いがあります。

マルチノード配置では、クラスタ内の各ノードで 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 サービス展開で完全にサポートされます。

ローカル クラスタ内のすべてのユーザのフェデレーションを有効にするには、すべてのローカル ドメインの DNS レコードを作成する必要があります。

XMPP フェデレーションの場合は、cup-xmpp セキュリティ証明書でサブジェクト代替名としてすべてのローカル ドメインが含まれている必要があります。

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

IM and Presence Service は次のサブドメインのシナリオをサポートします。

  • IM and Presence Service は、外部ドメインのサブドメインに属します。 たとえば、IM and Presence Service はサブドメイン「imp.cisco.com」に属します。 IM and Presence Service では、ドメイン「cisco.com」に属する外部企業とフェデレーションできます。 この場合、IM and Presence Service ユーザには「impuser@imp.cisco.com」という URI に割り当てられ、外部ユーザには「foreignuser@cisco.com」という URI が割り当てられます。

  • IM and Presence Service は親ドメインに属し、外部企業はその親ドメインのサブドメインに属しています。 たとえば、IM and Presence Service はドメイン「cisco.com」に属します。 IM and Presence Service では、サブドメイン「foreign.cisco.com」に属する外部企業とフェデレーションできます。 この場合、IM and Presence Service ユーザには「impuser@cisco.com」という URI に割り当てられ、外部ユーザには「foreignuser@foreign.cisco.com」という URI が割り当てられます。

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

サブドメインとフェデレーションを行う場合は、DNS ドメインを別途設定するだけで十分です。Active Directory を分割する必要はありません。 企業内部でフェデレーションを設定する場合、IM and Presence Service ユーザまたは外部ユーザを同じ Active Directory ドメインに所属させることができます。 たとえば上記 3 番目のシナリオの場合、Active Directory が親ドメイン「cisco.com」に属すことができます。 各ユーザは「imp.cisco.com」と「foreign.cisco.com」のどちらかのサブドメインに所属し、かつ「impuser@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 Service では、ローカル ドメインではなく正しいドメインが適用されます。


(注)  


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