JP5337698B2 - 分散型スケーラブル・プラグ可能な会議アーキテクチャ - Google Patents

Description

本発明は、分散可能かつスケーラブルでプラグ可能な会議アーキテクチャに関する。

コンピューティング・デバイスおよびネットワーク化における技術の進歩は、多様な情報およびサービスへのより広大なアクセスを提供し続けており、実質的に世界中のどこからでもアクセスが可能となっている。行う必要がある仕事を、ほとんどの場所から実行することができるので、仮想オフィスは、一層当たり前のことになりつつある。

ネットワーク事業者および提供者（携帯電話および非携帯電話の両方の）は、現在存在しているか、または将来市場に出される、多種のポータブルデバイスおよび媒体をサポートするインフラストラクチャに、膨大な量のお金と資源を費やしている。例えば、携帯電話の事業者達は、先を争うように、携帯電話の顧客がＩＰネットワーク（例えば、インターネット）および関連するＩＰサービスにセルラーネットワークを介してアクセスできるようにするインフラストラクチャを提供している。したがって、携帯電話の顧客は、現在、ＩＰベースのネットワーク上で利用可能な情報にアクセスすることが可能である。同様に、コンピューティング・デバイスでは、ＩＰネットワーク上で会話することや、携帯電話ユーザーに接続することさえできる。

企業はさらに、例えば、今後効果的により多くの製品を開発するために、ミーティングの重要性を認識している。しかし、ユーザーに、ユーザーがいる様々な遠隔地からビジネスに同時に従事させること、および、多数の利用可能な通信デバイスおよび媒体タイプをサポートすることは、困難である可能性がある。

電子会議の開催（ｃｏｎｆｅｒｅｎｃｉｎｇ）は、例えば、法人企業の従業員がミーティングを実施することを可能にする、効果的な手段であり得る。しかし、任意の時点における場所および接続機能を考慮すると、参加者が、異なるメディアタイプを介して参加することを望むことがある。ポータブルの無線コンピューティング・デバイスの記憶能力および計算能力の進歩とともに、ユーザーは今では、例えば、イメージ、ビデオクリップ、オーディオデータ、およびテキストデータなどの多数のタイプの異種のデータタイプでやりとりすることができる。さらに、ユーザーは、典型的に、セッションに接続するための複数のタイプのデバイスを有することができる。例えば、あるユーザーは会議室からオーディオ／ビデオによって、別のユーザーはデスクトップ・コンピューターを介して音声によって、さらに別のユーザーは携帯電話を使用してテキスト入力によって、参加することができる。

そのような異種の媒体の能力は、従来的に、媒体処理能力をローカルに統合することによってサーバーレベルで対処されていた。しかし、これには、このようなシステムを管理するにはより多くのリソースが必要とされること、および、これらのシステムは、電子会議の開催の需要に合致するように拡大することがより難しい、という点において問題がある。

以下は、開示される本発明の一部の態様についての基本的な理解を提供するための、簡略化された要約を提示する。この「課題を解決するための手段」は、広範囲な概説ではなく、主要な／本質的な要素を特定すること、またはその範囲を線引きすることは意図されていない。その唯一の目的は、幾つかの概念を簡略化された形式で、後に提示される詳細な説明に対する前置きとして提示することである。

本明細書には、マルチパーティ・マルチメディア会議のための、スケーラブルでプラグ可能（ｐｌｕｇｇａｂｌｅ）なアーキテクチャを説明するアーキテクチャが開示されている。マルチポイント・コントロール・ユニット（ＭＣＵ）などの異なる分散媒体コンポーネントのシームレスなプラグインを可能にする、集中ポリシーおよびコントロールコンポーネントのためのフレームワークを提供する。会議アーキテクチャは、セッションへのクライアント参加のための、異種の媒体タイプ（例えば、データ、オーディオ／ビデオ、インスタント・メッセージ）に対する多様なプラグ可能な分散媒体コンポーネントをサポートする。

例えば、電子会議の必要性に応えるため、クライアントは、（例えば、インターネット接続を介して）集中型のコントロールコンポーネント（フォーカスとも呼ばれる）にアクセスし、会議セッションを作成してスケジュールすること、または現在のセッションへの参加を要求する。コントロールコンポーネントは、適切な媒体インターフェース（例えば、オーディオ、ビデオ、データ）に接続して該インターフェースをクライアントに割り当て、要求されたクライアントの媒体タイプに合うように媒体インターフェースを構成し、会議セッションのセッション管理を提供し、関連するクライアントおよびシステム全てのセッションの完了とクリーンアップを管理する能力を有する。

集中型の会議コントロールコンポーネントは、スケジューリング・サービスおよびセッション・インスタンスの作成も（フォーカス・ファクトリーを介して）提供する。会議コントローラーはまた、会議セッションのための、１つまたは複数の最も利用可能な分散メディアコンポーネントを（媒体ファクトリーを介して）割り当てる機能を含む。会議コントロールコンポーネントは、会議ポリシーおよび名簿コントロールサービスとしても機能する。会議ポリシーサーバーは、会議ポリシーおよび名簿を記憶し操作することができる論理的な機能（ｌｏｇｉｃａｌ ｆｕｎｃｔｉｏｎ）である。会議ポリシーは、会議のオペレーションを定めているルール全てのセットであり、メンバーシップ・ポリシーおよび媒体ポリシーに分けることもできる。

会議コントロールコンポーネントは、フォーカスを通知（ｎｏｔｉｆｉｅｒ）として動作させ、会議状態（ｃｏｎｆｅｒｅｎｃｅ ｓｔａｔｅ）への申込み（ｓｕｂｓｃｒｉｐｔｉｏｎ）を受け取り、申込者にその状態の変更ついて通知することができる、論理機能である会議通知サービスを含む。状態は例えば、フォーカス自身、会議ポリシー、および媒体ポリシーによって保持される状態を含む。会議コントロールコンポーネントは、識別情報および／またはＰＩＮに基づいて、ユーザー承認および／または認証サービスを介して、セッション・セキュリティを提供するようにも機能する。集中型の会議コントローラーはまた、会議ポリシーおよび名簿の管理サービスの分散媒体コンポーネント（例えば、ＭＣＵ）とインターフェース接続する。会議アーキテクチャは、単一の統合された名簿を使用して、フォーカスから会議参加者に単一の会議画像を提供し、これはこのフォーカスを通して会議をコントロールすることによって可能である。

これらのサポートにおいて、本明細書に開示され特許請求されるアーキテクチャは、会議セッションの集中型コントロールのための会議コントロールコンポーネント、および、媒体タイプを使用してクライアントが会議セッションにインターフェース接続するための分散媒体コンポーネントを含む、コンピューターで実施される会議システムを備える。媒体コンポーネントは、任意の場所にあり得るため（例えば、インターネット）、例えば、ＨＴＴＰを介してアクセスが可能である。集中型コントローラーは、分散媒体コンポーネントについて全て知っている必要はない。

前述および関連する目的の達成のために、開示される本発明に関する特定の例示的態様を、以下の説明および添付の図面と関連して本明細書において説明する。しかし、これらの態様は、本明細書に開示される原理を利用することができる様々な方法の一部を示すものであり、そのような態様およびその等価物を全て含むことが意図されている。他の利点および新規な特徴は、図面とともに以下の詳細な説明を考察することにより明らかになるであろう。

分散媒体アクセスのためのコンピューター実装会議システムを図示する図である。 開示される会議アーキテクチャに従った分散媒体コンポーネントを使用して、会議セッションを管理する方法論を図示する図である。 セッション管理のより詳細な方法論を図示する図である。 ウェブベースの会議コントロールコンポーネントおよび分散媒体コンポーネントを使用して、会議セッションの作成を容易にするシステムの、より詳細なブロック図である。 イントラネットのクライアントが、会議を作成し参加するために参加者と交信する、参加者間のデータフローを図示する図である。 会議システム実装のためのコンポーネントアーキテクチャの、例示の詳細な図である。 電子会議および分散ＭＣＵのための、例示のサーバーキテクチャおよびプロトコルを図示する図である。 ウェブインターフェース／サービスを介して会議の作成を起動するための、例示のコール・フロー図である。 ＳＩＰ招待機構を介して会議の作成を起動するための、例示のコール・フロー図である。 ＳＩＰサービス機構を介して会議の作成を起動するための、例示のコール・フロー図である。 クライアントが会議にダイアルインするための、例示のコール・フロー図である。 アドユーザーのダイアルインによりデータコラボレーションＭＣＵを介してクライアントが参加するための、例示のコール・フロー図である。 アドユーザーのダイアルアウトによりオーディオ／ビデオＭＣＵを介してクライアントが参加するための、例示のコール・フロー図である。 ＭＣＵへの直接招待を介して、クライアントが参加するための、例示のコール・フロー図である。 ダイアルインを生じる別のクライアント参加者に対するアドホック招待のための、例示のコール・フロー図である。 別のクライアントに対するアドホック・ダイアルアウトＩＮＶＩＴＥのための、例示のコール・フロー図である。 リダイレクションを使用する、例示のコール・フロー図である。 クライアントの会議への参加とは別に会議の作成を扱う、例示のコール・フロー図である。 プール内の異なるフロンドエンドマシン上で作動するフォーカス・アプリケーションの多数のインスタンス間で、状態を共有するサーバー・プールシステムを図示する図である。 フォーカス・インスタンスを伴う２つの別個のクライアント−フォーカスのダイアログの例示のコール・フロー図である。 クライアントが会議状態を修正するためのＣ３Ｐコマンドを発行する、例示のコール・フロー図である。 分散ＭＣＵ会議アーキテクチャに従って利用されることが可能なＣ３Ｐコマンドを図示する図である。 フロントエンド・サーバーが同等の機能を有する、マルチ・サーバープールを図示する図である。 障害回復および高可用性特性のためのマルチ・サーバープール構成を図示する図である。 分散媒体コンポーネントアーキテクチャのエンティティ間の、種々のタイプのデータフローのトポロジ図である。 プラグ可能および分散媒体コンポーネントを使用する、会議アーキテクチャ全体を図示する図である。 開示されるアーキテクチャに従った、中央集中かつ分散された電子会議を実行するよう作動することができるコンピューターのブロック図である。 分散媒体電子会議を容易にする、例示のコンピューティング環境の概略ブロック図である。

図面を参照して本発明を説明するが、全体を通じて同様の参照番号を使用して同様の要素を示す。以下の記載において、説明の目的で、多くの具体的な詳細が、その十分な理解を提供するために説明される。しかし、本発明を、これらの具体的な詳細を必要とせずに実施することができることは明白であろう。他の例では、周知の構造および装置が、その説明を容易にするためにブロック図の形式で示される。

開示されるアーキテクチャは、マルチパーティ・マルチメディア会議セッションのためのスケーラブルでプラグ可能なアーキテクチャである。集中型ポリシーおよび会議コントロールコンポーネントは、異なる分散媒体コンポーネント（例えば、データ、オーディオ／ビデオ、メッセージ）のシームレスなプラグインを可能にし、会議セッションへのクライアントの参加を受け入れる。集中型会議コントロールコンポーネントには、以下のものが含まれる。すなわち、会議状態への申込みを受け取り、申込者にその状態の変更について通知する、会議通知サービス；会議ポリシーおよび名簿を記憶し操作する、会議ポリシーおよび名簿のコントロールサービス；ユーザー識別情報に基づいてユーザーを承認／認証する、セキュリティサービス；会議をスケジューリングする、スケジューリング・サービス；会議セッションに対して最も可用性のある媒体コンポーネントを割り当てる、割り当てサービス；ならびに、分散媒体コンポーネントの会議ポリシーおよび名簿を管理する、ＭＣＵ管理サービス、が含まれる。

初めに図面を参照すると、図１は、分散媒体アクセスのためのコンピューター実装される会議システム１００を図示している。システム１００は、様々な異なる装置を介したセッション参加者によるアクセスのために、多様なプラグ可能な分散媒体システムをサポートする、プラグ可能な会議アーキテクチャである。そのサポートにおいて、システム１００は、会議セッションの集中作成およびコントロールのためのネットワークベースの会議コントロールコンポーネント１０２を含む。システム１００のコントロールコンポーネント１０２は、クライアント１０６（クライアント、およびクライアント₁、．．．、クライアント_Mで示される。Ｍは正の整数）による同様および／または異種の媒体モード（例えば、オーディオ、ビデオ）を介した会議セッションへのクライアントのアクセスをさらに提供する、マルチポイント・コントロール・ユニット（ＭＣＵ）などの１つまたは複数の分散媒体コンポーネント１０４（媒体コンポーネント₁、．．．、媒体コンポーネント_Nで示される。Ｎは正の整数）と、インターフェース接続してこれらを管理する。

ＭＣＵは、１つまたは複数のクライアントの媒体タイプに対して接続および管理を容易にするシステムである。媒体は、クライアントとＭＣＵとの間で直接交換される。従来のシステムは、開示される新規のアーキテクチャによって提供される、少なくともＭＣＵの分散型の機能を備えるＭＣＵを利用していない。

言い換えると、電子会議の必要性を満たすため、クライアント１０８は（例えば、インターネット接続を介して）、会議セッションの作成を要求しているコントロールコンポーネント１０２にアクセスする。コントロールコンポーネント１０２は、セッション参加者（例えば、クライアント１０８、クライアント₁、クライアント₂、およびクライアント₃）、およびそれらの所望の接続タイプ（例えば、オーディオ、ビデオなど）に対する適切な媒体コンポーネント１０４（例えば、媒体コンポーネント１１０および１１２）の割り当て、媒体コンポーネント１０４のインターフェース管理、要求された電子会議の必要性に適合させるための１つまたは複数の媒体コンポーネント１０４の構成、セッション中のセッション管理、ならびに、関連する全てのシステムに対するセッションの完了およびクリーンアップを容易にする。

図２は、開示される会議アーキテクチャにかかる、分散媒体コンポーネントを使用して会議セッションを管理する方法を図示している。説明を簡略化する目的のために、例えば、フローチャートまたはフロー図の形式で本明細書に示される１つまたは複数の方法は、一連のアクトとして示され説明されるが、本発明は、アクトの順番によって限定されるものではなく、一部のアクトが、本明細書で示され説明される順番と異なる順番でおよび／または他のアクトと同時に起こり得ることは、理解され認識されよう。例えば、当業者には理解され認識されるであろうが、方法は代替的に、状態図など、一連の相関的な状態またはイベントとして表されること可能性がある。さらに、図示されたアクト全てが、本発明にかかる方法を実行するのに必要とされるわけではない。

２００において、中央会議コントロールコンポーネントが会議セッション管理のために提供される。２０２において、１つまたは複数の媒体コンポーネント（例えば、ＭＣＵ）が、同一または異種の媒体タイプ（例えば、インスタント・メッセージ、オーディオ）を介してセッション参加者を接続させるために、コントロールコンポーネントによって、分散型かつアドレス可能な手法で提供される。２０４において、会議セッションの作成の要求を、クライアントから受信する。２０６において、コントロールコンポーネントが、会議インスタンスを作成する。２０８において、セッションにアクセスするためのアクセス情報が、クライアントに返される。２１０において、コントロールコンポーネントは、参加者、および要求された参加者の媒体タイプをサポートするために、媒体コンポーネントの可用性を判断する。２１２において、コントロールコンポーネントは、予想されたセッション媒体タイプに対して、１つまたは複数の媒体コンポーネントを割り当てる。２１４において、参加者は、セッションを通知される。２１６において、コントロールコンポーネントは、セッションへの参加者のアクセスを認証することによってセキュリティ処理を容易にする。

図３は、セッション管理のより詳細な方法を図示する。３００において、クライアントは、ウェブアドレスを使用してウェブベースの会議コントロールコンポーネントに接続する。３０２において、クライアントは、会議情報をコントロールコンポーネントに送信する。この情報は、例えば、参加者情報、セッションの日時、および参加者のアクセスをサポートする媒体タイプなどの、セッションに関する設定および構成情報を含む。３０４において、コントロールコンポーネントは、セッション・インスタンスを作成し、セッションのＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）を返し、１つまたは複数のＵＲＩを、セッションに割り当てられた媒体コンポーネントに返す。３０６において、クライアントは、ＵＲＩ情報を参加者に渡す。セッションが開始し、３０８において、参加者は、セッション状態の変更を通知される。３１０において、コントロールコンポーネントは、セッション中に補足的な（ｓｉｄｅｂａｒ）会議を作成および終了することを容易にする。３１２において、セッション参加者はセッションの中座者（立ち去る参加者）を通知され、セッションは終了し、システムはクリーンアップを実行する（例えば、ＭＣＵ、セッション・インスタンスなどを終了する）。

ここで図４を参照すると、図４には、ウェブベースの会議コントロールコンポーネント４０２および分散媒体コンポーネント４０４を使用して会議セッションの作成を容易にする、システム４００のより詳細なブロック図が図示されている。システム４００は、集中型会議コントローラーである会議コントロールコンポーネント４０２（本明細書では、フォーカスコンポーネントとも呼ばれる）を含む。フォーカスコンポーネント４０２は、会議通知サービスを提供する通知コンポーネント４０６を含む。会議通知サービスは、フォーカスコンポーネント４０２によって提供される論理機能である。フォーカスコンポーネント４０２は、会議状態への申込みを受諾すること、および申込者（または参加者）にその状態の変更について通知することによって、通知として動作することができる。

フォーカスコンポーネント４０２は、ポリシーおよび名簿のコントロールサービスを提供するための会議ポリシー／名簿コンポーネント４０８も含む。コンポーネント４０８の一部としての会議ポリシーサーバーは、会議ポリシー／名簿を記憶して操作することができる論理機能である。会議ポリシーは、会議のオペレーションを定めるルール全てのセットであり、メンバーシップ・ポリシーおよび媒体ポリシーに分けられる。通知コンポーネント４０６によりモニタリングされる状態は、フォーカスコンポーネント４０２自身、会議ポリシー、および媒体ポリシーによって保持される状態を含む。

フォーカスコンポーネント４０２は、会議のスケジューリングを可能にするスケジューリング・コンポーネント／フォーカス・ファクトリーコンポーネント４１０も含む。認証コンポーネント４１２は、識別（ｉｄｅｎｔｉｔｙ）（例えば、アクティブ・ディレクトリ）に基づいて、またはＰＩＮを使用して、ユーザーの承認および認証の処理を提供する。ＭＣＵインターフェースコンポーネント４１４は、会議名簿／ポリシー管理のための複数の分散媒体コンポーネント４０４（例えば、ＭＣＵ４０４）（ＭＣＵ₁、ＭＣＵ₂、．．．、ＭＣＵ_Tで示され、Ｔは正の整数）とのインターフェース接続を容易にする。フォーカス４０２は、ＭＣＵ割り当てコンポーネント（ＭＣＵファクトリーとも呼ばれる）４１６を含み、その機能は、会議セッションに対して、ネットワーク４１８（例えば、インターネット）の最も可用性のあるネットワークベースのＭＣＵ４０４を割り当てることである。システム４００は、メインフォーカスから単一の会議画像を単一の統合された名簿と共に取得し、このフォーカスを通して会議をコントロールすることできる、プラグ可能な会議参加者（クライアント４２０として示される）を含む。

図５は、イントラネットのクライアントが、参加者とやりとりをして、会議を作成し参加する、参加者間のデータフローを図示する。開示される集中型会議アーキテクチャには、全ての会議参加者に対して可視である単一の（または主要な）フォーカスがある。このフォーカスは、同一会議の複数の参加者に対する単一の中央シグナリングポイントである。各会議は、一意のＳＩＰ（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）ルーティング可能会議ＵＲＩによって識別される。典型的には、このＵＲＩは、ＭＣＵにより実行されており、会議をホストしているフォーカスにルーティングする。

改善されたユーザー体験を提供するために、システムは、全ての会議ＵＲＩがメインフォーカスにルーティングする、メインフォーカスの概念を導入する。クライアントユーザーは、フォーカスによって会議に参加することを承認され、会議の状態における変更に関する情報をフォーカスから取得し、会議コントロールの全てのオペレーションが、クライアントによってメインフォーカスに発行される。

アーキテクチャのコンポーネントは、クライアント５００、フォーカス・ファクトリー５０２、フォーカス５０４、ＭＣＵファクトリー５０６、およびＭＣＵ５０８である。開示される会議アーキテクチャの主な特徴の一つは、従来のモノリシックなサーバーキテクチャではなく、分散型の方式で動作する、多様なコンポーネントを使用することである。

会議クライアント５００は、会議に追加および参加することができるエンドポイントである。クライアント５００は、最初にフォーカス・ファクトリー５０２とやりとりをして会議を作成する。

フォーカス・ファクトリー５０２は、会議のためのフォーカス５０４を作成するエンティティである。フォーカス・ファクトリー５０２は、クライアント５００に、会議が開かれる適切なフォーカスの位置を示す。フォーカス・ファクトリー５０２は、ＳＩＰフロントエンドマシンにおいてＳＩＰエンドポイントとして動作するアプリケーションであり、ＳＩＰ ＵＲＩでアドレス可能である。

フォーカス・ファクトリー５０２は、ＳＩＰでアドレス可能であり、さらに、ＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）およびＳＯＡＰ（ｓｉｍｐｌｅ ｏｊｂｅｃｔ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ）ＵＲＩを使用してもアドレス可能である。あるアーキテクチャ実装において、フォーカス・ファクトリー５０２は、フォーカス５０４と一緒に用いられ、別のアーキテクチャ実装においては、一緒には用いられない。各会議プールを、フォーカス・ファクトリーと見なすことができる。

フォーカス５０４は、会議セッションのための集中型ポリシーおよび状態マネージャである。フォーカス５０４は、会議を表し、かつ会議の全ての態様に対して中央コーディネータとして動作する、ＳＩＰエンドポイントである。フォーカス５０４は、会議コントロールポリシーを実施すること、会議の全体のセキュリティを管理すること、会議状態の更新をクライアントに通知すること、および、クライアント５００とＭＣＵ５０８との間のフローへのコンジット（ｃｏｎｄｕｉｔ）をコントロールコマンドに提供することを担う。

フォーカス５０４はまた、全てのクライアントの代わりに、会議の一部である各媒体タイプのＭＣＵとやりとりをする。フォーカス５０４は、会議に関する照会（ｑｕｅｒｙ）への応答に必要な状態の全て、または、フロントエンド・サーバーが使えない場合にミーティングを復活させるのに必要な状態の全てを記憶する。会議情報は、将来的な使用のために、セッションのクリーンアップまでＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ）サーバー・データベースに保持されることが可能である。フォーカス・インスタンスは、会議プール上で作動する。これにより、クライアントがプール内の任意のフロントエンド・サーバーに接続することが可能になり、それによって、より良い可用性、負荷の分散、およびより良いスケーリングを可能になる。フォーカス５０４は、例えば、ＭＣＵをブートストラップすること、およびＨＴＴＰインターフェース上でＭＣＵへの接続を維持することも担う。フォーカス５０４はまた、プロキシからプロキシへのＣ３Ｐ（すなわち、ＣＣＣＰ：ｃｏｎｆｅｒｅｎｃｅ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ ｐｒｏｔｏｃｏｌ：会議コントロール・チャネル・プロトコル））コマンドおよび通知として動作することもできる。これについては、以下に述べる。

フォーカスの概念は、ＳＩＰＰＩＮＧに準拠した会議の中核を成す。ＳＩＰＰＩＮＧは、ＳＩＰへの会議拡張を定義することで設立されたＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のワーキングループである。ＳＩＰＰＩＮＧの設立目的は、会議状態イベントのパッケージスキーマを定義することである。

ＭＣＵファクトリー５０６は、ＳＩＰＰＩＮＧの概念であり、ＭＣＵ５０８を特定の媒体タイプの会議セッションに割り当てる。ＭＣＵファクトリー５０６は、会議を作成するためのローカルポリシーを使用して、特定の媒体タイプの会議をＭＣＵ５０８において設定することを担う。ＭＣＵファクトリー５０６は、ＭＣＵを会議に割り当てる前に、ＭＣＵに対する現在の負荷を考慮することもできる。一実装においては、媒体タイプごとに１つのＭＣＵファクトリー５０６とすることができる。

ＭＣＵ５０８は、１つまたは複数の媒体タイプを管理することを担う。開示されるアーキテクチャの１つのシナリオにおいては、全ての会議コントロールコマンドが、クライアント５００によってフォーカス５０４に送信され、次いで、該フォーカス５０４が、これらのコマンドを、要求を送信したクライアント５００がそのオペレーションを実行する権限を有することを検証した後に適切なＭＣＵ５０８へ中継する。その後、媒体はクライアント５００とＭＣＵ５０８との間で直接交換される。

ＭＣＵのタイプは、データコラボレーションＭＣＵ、オーディオ／ビデオＭＣＵ、ＩＭ（インスタント・メッセージ）ＭＣＵ、およびＡＣＰ（ａｕｄｉｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｐｒｏｖｉｄｅｒ：オーディオ会議プロバイダ）ＭＣＵを含むことができる。適切に設計されたサードパーティのＭＣＵは、アーキテクチャにプラグインし、例えば、オーディオ／ビデオの向上のために参加者の体験を向上させることができる。アーキテクチャは、他のＭＣＵを、望み通りに今後容易に追加することを可能にする。例えば、適切に設計されたＭＣＵを、アプリケーションの共有またはチャットに提供することができる。

以下は、より詳細なデータフローの概要であり、データフローには通信チャネル、セマンティックス、およびコンポーネント間で交換されるデータのタイプが含まれる。

図５のクライアント／フォーカス・ファクトリーの通信（図中、１で示される）は、最初にクライアント５００がフォーカス・ファクトリー５０２の位置を特定することにより始まる。クライアント・アプリケーションは、フォーカス・ファクトリー５０２と通信し、新しい会議を開始する。上述したように、ユーザーがサインオンすると、クライアント・アプリケーションがフォーカス・ファクトリーＵＲＩを取得するので、クライアント５００は、フォーカス・ファクトリー５０２と任意の時間に通信して新しいアドホック会議を開始する手段を有する。クライアント５００は、例えば、サーバープールのどのサーバー上にフォーカス・ファクトリー５０２が位置しているかに注意を払わない。すなわち、クライアント５００は、接続すべきフォーカス・ファクトリーＳＩＰ ＵＲＩが必要なだけである。

開示されるフレームワークにおいて、会議を作成することは、フォーカス・インスタンスを作成し、構成することを意味する。フォーカス・ファクトリー５０２のジョブは、フォーカス５０４のＵＲＩをクライアント５００に返すことである。このことは、クライアント５００とフォーカス・ファクトリー５０２との間の会話はそれほど長く続けられる必要はないが、フォーカスＵＲＩがクライアント５００へ戻されるまでは持続するように十分長ければよい、ということを意味する。フォーカス・ファクトリー５０３は、フォーカスＵＲＩをクライアント５００へ戻す前に、フォーカス５０４を作成し、（必要であれば）構成する。

クライアント５００は、会議の役割の定義、媒体タイプ、権限、参加者に関して必要な全ての情報を、フォーカス・ファクトリー５０２に前もって渡すことができ、したがって、フォーカス・ファクトリー５０２は、成功のレスポンスを最後のデータとともに返すことができる。

図５のフォーカス・ファクトリー／フォーカスの通信（図中、２で示される）に関して、要求をクライアント５００から受け取ると、フォーカス・ファクトリー５０２は、フォーカス５０４を作成し、フォーカスＵＲＩをクライアント５００に返す（図中、３で示される）。フォーカス５０４は、フォーカス・ファクトリー５０２と同様、アプリケーションによって表されるＳＩＰエンドポイントである。フォーカス・ファクトリー５０２は、クライアント５００から受け取る要求をフォーカス５０４にリダイレクトするため、フォーカス５０４は、クライアント５００とともにメディアネゴシエーションを実行するエンドポイントになることできる。フォーカスＵＲＩをクライアント５００に渡した後、フォーカス・ファクトリー５０２は、いかなる状態も保持する必要がなく、あるいは、いかなる動作も行う必要がない。

ＭＣＵファクトリー５０６は、アクセス情報をＭＣＵ５０８に提供する論理エンティティである。ＭＣＵファクトリー５０６は、ＭＣＵ装置またはソフトウェアのベンダのベンダ固有の実装とすることができる。フォーカス５０４は、設定を通じて、どのＭＣＵファクトリーがシステムに存在し、それがどの媒体タイプをサポートするかについてわかる。従って、フォーカス５０４は、ＭＣＵファクトリー５０６に、どのようにＭＣＵ５０８とコンタクトをとるのかに関する情報を求め（図中、４で示される）、ＭＣＵファクトリー５０６は、動作中の全ての内部論理に基づいてその情報を返す（図中、４で示される）。

ＭＣＵファクトリー５０６は、ＭＣＵ５０８をフォーカス５０４に提供するように要求されると（図中、４で示される）、この要求に応答するためにどのＭＣＵ５０８が最も適切かを見つけ出し、そのＭＣＵ５０８のＵＲＬ（ｕｎｉｖｅｒｓａｌ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）を返す。各ＭＣＵを（例えば、アクティブ・ディレクトリにおいて）公開することができるため、トポロジ内の全てのＭＣＵファクトリー５０６が、利用可能な同種のＭＣＵを見つけ出すことができるようになる。

各ＭＣＵ５０８は、同様にアクティブ・ディレクトリにおけるコントロールのためにそのＨＴＴＰアドレスを公開する。このアドレスは、ＭＣＵファクトリー５０６がＭＣＵリソース５０８を割り当てるときにフォーカス５０４に渡されるものである。しかし、ＵＲＬがフォーカス５０４へ渡される前に、ＭＣＵファクトリー５０６は、ＭＣＵ５０８上に会議を設定しようとする（図中、５で示される）。ＭＣＵのレスポンスが肯定的な（ｐｏｓｉｔｉｖｅ）場合、ＵＲＬがフォーカス５０４に返される。

フォーカス５０４は、次いで、ＨＴＴＰをトランスポートとして使用して、ＭＣＵ５０８と通信することができる（図中、６で示される）。要求および応答のペイロードは、ＸＭＬドキュメントとすることができる。クライアント５００は、ＭＣＵ５０８と、シグナリング・プロトコルおよびメディア・プロトコルを介して通信する（図中、７で示される）。オーディオ／ビデオＭＣＵでは、シグナリング・プロトコルはＳＩＰメディアであり、ＲＴＰ／ＲＴＣＰ上で搬送されることが可能である。ミーティングＭＣＵでは、シグナリングおよびメディアの両方が、ＰＳＯＭプロトコルを使用してトランスポートとしてのＨＴＴＰ上で搬送されることが可能である。

図６は、会議システム６００を実装するためのコンポーネントアーキテクチャに関する例示の詳細な図を図示する。システム６００は、フロントエンド・コンピューター６０２、ストレージ・システム６０４、および分散媒体コンポーネント６０６を含む。フロントエンド・コンピューター６０２は、ＳＩＰプロキシ６１０として機能するサーバープロセス６０８を含む。ＳＩＰプロキシおよびルータとして動作することに加えて、サーバープロセス６０８は、プレゼンス（およびレジストラ）サーバー（またはモジュール）６１４、アーカイブ・エージェント・モジュール６１６、およびＳＩＰ ＡＰＩモジュール６１８によって使用される、内部ＡＰＩ（拡張モジュールＡＰＩと呼ばれる）６１２も提供する。図示されるように、これら拡張モジュール６１２の全ては、同一のプロセス内で実行することができる。サードパーティのコードは、ＳＩＰプロキシプロセス６１０内で実行される必要がない。

プレゼンス／レジストラモジュール６１４は、レジストラおよびプレゼンスの機能を提供する。プレゼンスおよびレジストラモジュール６１４は、ＳＱＬサーバー・データベース（またはＭＳＤＥ）内の全てのレジストレーション情報およびプレゼンス情報を管理する。

ＳＩＰプロキシおよび関連する拡張モジュールの組み合わせは、総称してサーバーフロントエンドと呼ばれる。示されるように、フロントエンドの機能は、会議モジュール６１８（会議マネージャとも呼ばれる）を介して会議の特性（ｆｅａｔｕｒｅｓ）を含むように強化されている。会議マネージャ６１８は、シグナリングおよび会議管理の機能を提供するサーバーコンポーネントである。会議マネージャ６１８の主な構成要素は、フォーカス、およびフォーカス・ファクトリーである。

上記に示されるように、フォーカスは、会議を表すＳＩＰエンドポイントである。フォーカスは、会議の状態を管理すること、セキュリティを強化すること、役割と権限を管理すること、および会議状態の更新をクライアント（図示せず）に提供することを担う。フォーカスはまた、全てのクライアントの代わりに、会議の一部である各媒体タイプのＭＣＵとやりとりをする。

会議データベース６２０は、サーバー６０２上に設定された各会議に関する情報を含む。これは、会議ＩＤ、会議に関連するパスワードおよび／またはＰＩＮ、開始時間および終了時間（ある場合）、役割および権限などに関する情報を含む。データベース６２０は、フォーカス障害から回復させるための実行中の会議に関する情報も含む。プレゼンス／レジストラ情報、および会議情報は、同一の物理的なデータベース（例えば、会議データベース）の異なるテーブルとすることができる。

各ＭＣＵは、１つまたは複数の媒体タイプを管理することを担う。一実装おいて、全ての会議コントロールコマンドは、クライアントによってフォーカスに送信され、次いで、フォーカスは、これらのコマンドを、要求を送信したクライアントがそのオペレーションを実行する権限を有するか検証したあとに適切なＭＣＵに中継する。その後、媒体はクライアントとＭＣＵとの間で直接交換される。

ＭＣＵは、２つの論理要素から成る。すなわち、メディアコントローラー（ＭＣ）とメディアプロセッサー（ＭＰ）である。メディアコントローラーは、フォーカスとＭＣＵとの間でコントロールコマンドを管理することを担う。メディアプロセッサーは、例えば、ミキシング、中継、トランスコーディングなどの媒体管理を担う。ＭＣＵが、データコラボレーションＭＣＵである場合、メディアプロセッサーは、全体的なデータコラボレーション体験を管理することを担う、高度なソフトウェアコンポーネントである。各ＭＣＵは、そのコンテンツおよび状態情報を、故障および／または障害が発生した場合の回復のために、関連するストレージユニットに格納することができる。

ＭＣＵがオーディオ／ビデオＭＣＵである場合、メディアプロセッサーは、遅いリンクにいるクライアントのために、オーディオストリームとビデオストリームのミキシング、ビデオストリームをつなぎ合わせること、メディアのダウンコンバートなどに関する非常に専門的な知識を有する。全ての会議コンポーネントのうち、メディアプロセッサーは、最もＣＰＵとネットワークが集約的なコンポーネントであり得る。従って、ＭＣＵは、会議マネージャとは異なる物理コンピューター上で作動可能であり、これによりスケーリングをも提供する。一実装おいて、メディアコントローラーおよびメディアプロセッサーは、展開を簡略化するために同一のマシンに配置される。代替的実装においては、メディアコントローラーおよびメディアプロセッサーは、異なるマシン６０４上に配置される。

フロントエンド・コンピューター６０２は、ウェブサービスおよびウェブ・スケジューリング・アプリケーション６２４と、ＭＣＵファクトリー６２６とを含むウェブサーバー６２２を作動させることもできる。先に示したように、ＭＣＵファクトリー６２６は、会議を作成するためのローカルなポリシーを使用して、特定の媒体タイプの会議をＭＣＵに設定することを担う。ＭＣＵファクトリー６２６は、ＭＣＵを会議に割り当てる前に、ＭＣＵに対する現在の負荷を考慮することもできる。ロードバランシングデータを、ロードバランシングデータベース６２８上に格納することができる。この特定の実装において、媒体タイプごとに１つのＭＣＵファクトリーとすることができる。しかし、代替的実装においては、１つのＭＣＵファクトリーは、適切に強固であり多数の異なる媒体タイプを扱う。

ウェブコラボレーションの特性を、データコラボレーションＭＣＵによって提供することができる。データコラボレーションＭＣＵは、「ＰＳＯＭ」技術で設計される。データコラボレーションＭＣＵがサポートする特性は、例えば、プレゼンテーション・ソフトウェア・ドキュメント、ワードプロセシングおよびスプレッドシートドキュメント、チャット、投票、ホワイトボード、およびアプリケーションの共有などである。

オーディオ／ビデオＭＣＵは、マルチパーティのオーディオとビデオのミキシング能力および中継能力を提供し、業界標準のＲＴＰ（ｒｅａｌｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ：リアルタイム転送プロトコル）およびＲＴＣＰ（ＲＴＰ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ：リアルタイム転送制御プロトコル）で構築される。他のＭＣＵでは、例えば、インスタント・メッセージ（ＩＭ）ＭＣＵおよびＡＣＰＭＣＵなどを設計し、提供することができる。

ウェブサーバー６２４は、オンライン会議をスケジュールするためのスケジューリングアプリケーション（例えば、ＡＳＰ．ＮＥＴ）を提供する。このアプリケーションは、会議を設定して会議のポリシーを管理するために、ウェブサービスＡＰＩを使用する。ウェブスケジューラのカレンダリングに使用されるデータベースは、フォーカス／会議データベース６２０とすることができる。ＭＣＵのコンテンツおよび状態を、ローカルなデータストア６３０に格納することができる。

サービスには、議題、アクション・アイテム、 追加事項、共有ワークスペースに関連するドキュメントなどのミーティングメタデータを使用して、進行中のミーティングを管理するための、豊富なストアおよびビューを提供することもできる。

認証を、会議アーキテクチャの統合部分とすることが可能である。一実装おいては、ユーザーのログイン証明書を、ユーザーを自動的に認証すること（例えば、シングルサインオン）に使用することができる。フォーム認証には、ユーザーが自分のユーザー名およびパスワードを明示的に入力するウェブ形式のフォームを提供することもできる（例えば、ユーザー名およびパスワード）。承認は、初期認証ハンドシェークの後に、クライアントによってサーバーにセキュアに伝送される不透明なもの（ｏｐａｑｕｅ）に基づいて強化され得る。クライアントからサーバーへの転送チャネルの強い暗号化（例えば、１２８ビット暗号）を行うことも可能である。

ウェブ会議は、サービスまたは企業内にアカウントを持たないユーザーとのオンラインミーティングの開催を含むことが可能である。これらの一度限りのミーティングは、公平に共通のものである。一度限りの会議の参加者の認証は、電子メール等の帯域外の手段を通じて潜在的な参加者と通信状態に入る各セッションのための一意のパスワードを指定することによって、サポートされることが可能である。

一部の状況では、会議アプリケーションにおいて承認を要求することが可能である。会議は、リソースをサーバー／サービス上に取り上げる。従って、ユーザーが会議の作成を許可される前に、強制的な承認を課すことができる。別の例では、所与の会議において、全てのユーザーが全ての権限を持つ必要はない。例えば、ユーザーの特定サブセットは、セッション内に存在することおよび話すこと許可され、ユーザーの別のサブセットは、聴くことだけを許可される。別の例では、会議の全てのユーザーが、他のユーザーを招待して参加させることを許可されるわけではない。会議コントロールアクションには、会議のミュート／ミュート解除、特定のユーザーのミュート／ミュート解除、または会議からのユーザーの削除などがある。これらの各アクションは、最初に権限または許可を要求するようにすることが可能である。

これらの権限を有するユーザーのセットは、会議ごとに異なるものとすることができる。各会議は潜在的に、異なるメンバーシップを持ち、あるユーザーが多数の会議への参加を承認されていても、このユーザーはこれらの会議の各々において異なる権限を持っていても良い。このため、より簡単に、「役割」のセットを定義し、「権限」のセットをこれらの役割と関連付け、そして会議の作成者に、ユーザーをこれらの役割のそれぞれに割り当てさせる。例えば、「主催者」役、「プレゼンタ」役、および「聴衆」役があり得る。会議を作成するユーザーは、これらの役割の各々が何の権限を持っているのかを指定する必要はないであろう。役割に対する権限を、会議サーバー管理者が予め構成することができる。役割の名前は、それらが持ち得るような権限の種類を連想するように（または直観的であるように）選択されることが可能である。

図７は、会議および分散ＭＣＵのための、例示的なサーバーキテクチャおよびプロトコルの図を図示する。多数のプロトコルを、クライアント７００とサーバー７０２との間で使用することが可能であり、それぞれが異なる目的のためのものである。ユーザーインターフェース７０４を有するクライアント７００が示されており、ユーザーインターフェース７０４は、下層の会議コントロール・管理コンポーネント７０６、および会議媒体コンポーネント７０８にアクセス可能である。管理コンポーネント７０６は、セッション招待名簿および／またはサードパーティ会議名簿を提供する名簿コンポーネント７１０にアクセス可能である。会議媒体コンポーネント７０８は、データコラボレーション・アプリケーションの共有コンポーネント７１２、およびオーディオ／ビデオコンポーネント７１４へのアクセスを容易にする。

サーバー７０２は、フォーカスコンポーネント７１６、データコラボレーション・アプリケーションの共有ＭＣＵコンポーネント７１８、およびオーディオ／ビデオ（ＡＶ）ＭＣＵコンポーネント７２０を含む。クライアント７００およびサーバー７０２は、様々なプロトコルを使用するためのプロトコルインターフェースコンポーネント（例えば、ＳＩＰ、ＰＳＯＭ、ＲＴＰ／ＲＴＣＰ）を含む。クライアント／サーバーＳＩＰコンポーネントは、セッションの設定および会議の管理のためのシグナリング・コントロールプロトコルを利用する。この特定の実装において、（例えば、ＲＦＣ３２６１に規定されるような）ＳＩＰは、コールの設定および終了に利用される。加えて、同一の会議セッションが、ＳＩＰ−ＣＸ拡張機能を使用する会議ポリシーコントロールおよびサードパーティコントロールに使用されることが可能である。一実装おいては、ＳＩＰ−ＣＸコマンドは、ＳＩＰ−ＩＮＦＯ上をトンネルされる。別の実装においては、Ｃ３Ｐコントロールプロトコルコマンドを利用することができる。さらに別の実装においては、ＸＣＯＮ（中央集中された会議のためのＩＥＴＦワーキンググループ）から、会議ポリシーコントロールのための標準的な転送およびプロトコルを使用することができる。ＳＩＰは、下層の転送レイヤとして、ＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）、またはＴＬＳ（ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ）を使用することが可能である。

別個のＳＵＢ−ＮＯＴダイアログを、会議パッケージへの参加申込み、および状態が変わるときに通知を取得するために使用することができる。会議の名簿は、このＳＵＢ−ＮＯＴダイアログに基づいて駆動される。ＰＳＯＭは、データコラボレーションのためのメディア・プロトコルとすることができ、下層のトランスポートとしてＴＣＰまたはＨＴＴＰを使用することが可能である。

会議の各媒体に対して、媒体トランスポートが使用される。ＲＴＰおよびＲＴＣＰを使用して、オーディオ／ビデオの機能を提供することができる。ＲＴＰ／ＲＴＣＰを、ＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）上で作動させることができ、ＵＤＰ接続がクライアント７００とサーバー７０２との間で利用可能である。ＵＤＰ接続がない場合、ＲＴＰ／ＲＴＣＰを、ＴＣＰまたはＨＴＴＰ上をトンネルさせることができる。他のメディア・プロトコルを、他の媒体タイプに使用することができる。例えば、チャットは、ＭＳＲＰ（ｍｅｓｓａｇｅ ｓｅｓｓｉｏｎｓ ｒｅｌａｙ ｐｒｏｔｏｃｏｌ）においてサポートされ、アプリケーションの共有は、ＲＤＰ（ｒｅｍｏｔｅ ｄｅｓｋｔｏｐ ｐｒｏｔｏｃｏｌ）においてサポートされることができる。これら各々は、別個の媒体タイプとして作動させることができる。別の実装においては、これらのプロトコル両方をＰＳＯＭのトップに実装することが可能である。

図８から１８は、会議を作成し、会議にダイアルインし、ダイアルインおよびダイアルアウトによってＡＶ ＭＣＵでメディアセッションに参加し、参加者に対するアドホック招待を実行し、データＭＣＵを介してコラボレーション・セッションに参加するためのコール・フロー図を図示する。

クライアント・アプリケーションは、フォーカス・ファクトリーと通信し、新しい会議を開始する。会議を作成することは、フォーカス・インスタンスの作成および構成を意味する。フォーカス・ファクトリーのジョブは、フォーカスへのＵＲＩをクライアントに返すことである。クライアントとフォーカス・ファクトリーとの間のこの通信は、長く続ける必要はない。フォーカスＵＲＩがクライアントへ戻されるまで継続する必要があるだけである。フォーカス／会議ＵＲＩは、一意の会議識別子、一意のサーバー識別子、および、会議をホストするドメインを、例えば、ｏｒｇａｎｉｚｅｒ＠ｄｏｍａｉｎ．ｃｏｍ；ｍｓ−ａｐｐ＝ｃｏｎｆ；ｍｓ−ｃｏｎｆ−ｉｄ＝ｌｌ、のようにユーザー情報の部分に含むように構成される。

クライアントが会議を作成することできる３つの方法がある。すなわち、ウェブサービス、ＳＩＰ招待機構、およびＳＩＰサービス機構を介するものである。図８は、ウェブインターフェース／サービスを介して会議の作成を開始する例示的なコール・フロー図を図示する。クライアントは、既知のフォーカス・ファクトリー・ウェブＵＲＩに接続し、公開されたウェブインターフェースを使用して、フォーカスを作成する。フォーカスの作成に成功した後、ウェブページは、クライアントに、会議にダイアルインするために、会議クライアントを起動するのに必要な情報を示す。

図９は、ＳＩＰ招待機構を介して会議の作成を開始する例示手なコール・フロー図を図示する。クライアントは、会議、媒体タイプ、権限、参加者に関して必要な全ての情報を、ＩＮＶＩＴＥ（招待）要求の一部としてフォーカス・ファクトリーに渡す。フォーカス・ファクトリーは、フォーカス・インスタンスを作成し、生成されたフォーカスＵＲＩを使用してクライアントをフォーカスにリダイレクトする。

さらに具体的には、クライアントは、ＩＮＶＩＴＥ要求を、会議を作成するための情報とともにフォーカス・ファクトリーに送信する。フォーカス・ファクトリーは、フォーカス・ファクトリーがフォーカスをインスタンス化する間にクライアント・トランザクションがタイムアウトしないように、仮（ｐｒｏｖｉｓｉｏｎａｌ）のｌｘｘレスポンスをクライアントに送信する。フォーカスの作成に要した時間がＳＩＰトランザクション・タイムアウトより短い場合、このレスポンスの送信は無視される可能性がある。フォーカス・ファクトリーは、次いで、ＩＮＶＩＴＥから要求された情報を全て解析し、フォーカス・インスタンスを作成する。フォーカス・ファクトリーとフォーカスが一緒に用いられることが可能なときは、フォーカスを作成するこのコールは、単にローカルなファンクションコールであり得る。フォーカス・ファクトリーは、次に、３０２レスポンスを、新しい招待セッションを開始するクライアントをフォーカスにリダイレクトするコンタクトヘッダとともに送信する。クライアントは、フォーカス・ファクトリーにＡＣＫを返信する。

図１０は、ＳＩＰサービス機構を介して会議の作成を開始する例示的なコール・フロー図を図示する。クライアントは、会議、媒体タイプ、権限、参加者に関して必要な全ての情報を、ＳＥＲＶＩＣＥ（サービス）要求の一部としてフォーカス・ファクトリーへ渡す。フォーカス・ファクトリーは、フォーカス・インスタンスを作成し、接続情報を２００ ＯＫレスポンスでクライアントに返信する。

さらに具体的には、クライアントは、ＳＥＲＶＩＣＥ要求を、会議を作成するための情報とともにフォーカス・ファクトリーに送信する。フォーカス・ファクトリーは、要求された情報をＳＥＲＶＩＣＥから全て解析し、フォーカス・インスタンスを作成する。フォーカス・ファクトリーとフォーカスが一緒に用いられることが可能なときは、フォーカスを作成するこのコールは、単にローカルなファンクションコールであり得る。フォーカス・ファクトリーは、２００ ＯＫレスポンスを会議情報とともに送信する。

図１１は、クライアントが会議にダイアルインする例示的なコール・フロー図を図示する。クライアントは、会議にダイアルインするためのフォーカスを用いてＩＮＶＩＴＥダイアログおよびＳＵＢＳＣＲＩＢＥダイアログを構築する。クライアントは、ＩＮＶＩＴＥダイアログを使用して会議に参加し、またそれをクライアントからフォーカスへのコマンドトラフィックのさらなるサードパーティコントロールのために使用する。クライアントからのコントロールコマンドは、ＩＮＦＯメッセージ内で搬送される。ＩＮＦＯメッセージの本文（ｂｏｄｙ）は、Ｃ３Ｐコントロール要求を含み、フォーカスによって処理される。

クライアントは、会議状態を観察するためにＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹダイアログを使用する。フォーカスは、申込みを受け入れ、申込者に任意の会議状態の変更を通知する。状態は、フォーカス自身、会議ポリシー、および媒体情報によって保持される状態を含む。例えば、ＩＮＶＩＴＥダイアログ内のクライアントによってＩＮＦＯメッセージを使用して送信されたコマンドが、会議状態を変更するコマンドである場合、フォーカスはまた、変更された会議状態のＮＯＴＩＦＹを送信することによってクライアントに通知する。

さらに具体的には、クライアントは、ＩＮＶＩＴＥ要求をフォーカスＵＲＩに送信して会議に参加する。このＩＮＶＩＴＥダイアログは、２つの目的を有する。すなわち、会議に参加しているクライアントを暗示すること、このダイアログ内のＩＮＦＯ要求を使用して会議のサードパーティコントロールに使用されることである。ＩＮＶＩＴＥのボディ内のＣ３Ｐアドユーザー（ａｄｄＵｓｅｒ）要求を使用して、特定のクライアント属性（例えば、表示名、役割、隠れた参加者）を特定することができる。クライアントは、ＳＵＢＳＣＲＩＢＥを会議イベント・パッケージに送信し、会議状態通知を観察する。初期の会議状態ドキュメントは、この拡張のサポートを示しているクライアントに従ってＳＵＢＳＣＲＩＢＥの２００ ＯＫ内に、ピギーバックされることが可能である。

図１２は、クライアントが、アドユーザーのダイアルインによってデータコラボレーションＭＣＵを介して参加する例示的なコール・フロー図を図示する。会議内の各ＭＣＵに対して、フォーカスは、フォーカス自身にルーティング可能な仮想ＳＩＰ ＵＲＩを割り当てる。フォーカスからクライアントへの初期通知は、会議内の全てのＭＣＵに対するＵＲＩを含む。クライアントが、ＭＣＵを用いてメディアセッションを構築することができる３つの方法がある。すなわち、ＭＣＵ ＵＲＩへのアドユーザーのダイアルイン、ＭＣＵ ＵＲＩを使用するアドユーザーのダイアルアウト、およびＭＣＵ ＵＲＩへの直接の媒体ＩＮＶＩＴＥである。

アドユーザーのダイアルインに関して、クライアントは、アドユーザーのダイアルインＣ３Ｐコマンドを発行し、フォーカスがそのコマンドをＭＣＵに転送する。ＭＣＵは、コマンドを承認し、適切な接続情報を返す。クライアントは、次いで、ＭＣＵを用いてディレクションメディアセッションを構築する。これは、ＳＩＰベースではない、ＭＣＵへのダイアルインの第１のモードである。

さらに具体的には、クライアントは、通知ドキュメントで受け取ったＭＣＵ ＵＲＩでＩＮＦＯアドユーザーのダイアルインコマンドを送信する。フォーカスは、ＭＣＵがこの会議の特定の様式（媒体）に対して割り当てられたかどうかをチェックする。ＭＣＵが割り当てられていない場合、フォーカスは、この会議に対してＭＣＵを割り当てるようにフォーカスに求めているＭＣＵファクトリーに、ＨＴＴＰ要求を送信する。ＭＣＵが会議に割り当てられたと仮定すると、フォーカスは、次いで、新しい参加者（アドユーザー）を推測するようフォーカスに求めている割り当てられたＭＣＵに、ＨＴＴＰ要求を送信する。フォーカスがこのＭＣＵと初めて通信する場合、ＭＣＵ上の会議を初期化するように他のブートストラップ要求が送信されるべきである。ＭＣＵは、推測された参加者（アドユーザー）のコールに対して成功メッセージのレスポンスを返す。レスポンスはまた、参加者にＭＣＵと接続させたい実際のＵＲＬを有することもある。データコラボレーションＭＣＵの場合、ＵＲＬは、ＰＳＯＭ ＵＲＬである可能性がある。もしある場合は承認情報も、同様に返すことができる。

フォーカスは、ＰＳＯＭ接続情報をクライアントに送信する。クライアントは、次いで、ＭＣＵを用いてＰＳＯＭチャネルを直接構築する。クライアントは、ＭＣＵへの参加が成功すると、参加者追加イベントをフォーカスに送信する。フォーカスは、その後、参加者追加のＭＣＵ状態変更通知を（ＳＩＰＰＩＮＧ ＢＥＮＯＴＩＦＹ（または、Ｂｅｓｔ ＥｆｆｏｒｔＮＯＴＩＦＹ）を介して）会議の全てのウォッチャに送信する。

図１３は、クライアントが、アドユーザーのダイアルアウトによってオーディオ／ビデオＭＣＵを介して参加する例示的なコール・フロー図を図示する。クライアントは、アドユーザーのダイアルアウトＣ３Ｐコマンドを発行し、フォーカスは、そのコマンドをＭＣＵに転送する。ＭＣＵは、コマンドを承認し、アドユーザーコマンド内に挙げられたクライアントにダイアルアウトする。クライアントは、次いで、ＭＣＵを用いてダイレクトメディアセッションを構築する。これは、ＳＩＰベースのＭＣＵ（例えば、Ａ／Ｖ ＭＣＵおよびＩＭ ＭＣＵ）とのクライアント接続において使用される。この機構はまた、クライアントがＭＣＵを介して別のクライアントにダイアルアウトする際にも使用されることが可能である。

さらに具体的には、クライアントは、通知ドキュメントで受け取ったＭＣＵ ＵＲＩを用いてＩＮＦＯアドユーザーのダイアルアウトコマンドを送信する。フォーカスは、次いで、ＭＣＵがこの会議の特定の様式に対して割り当てられたかどうかをチェックする。ＭＣＵが割り当てられていない場合、フォーカスは、ＨＴＴＰ要求を、この会議に対してＭＣＵを割り当てるようにフォーカスに求めているＭＣＵファクトリーに送信する。ＭＣＵが会議に割り当てられたと仮定すると、フォーカスは次に、ＨＴＴＰ要求を、ユーザーへダイアルアウトすることをフォーカスに求めている割り当てられたＭＣＵに送信する。ＭＣＵは、通常はフォーカスサーバー自身であるアウトバウンドＳＩＰプロキシを使用して、ＩＮＶＩＴＥをクライアントにダイアルアウトする。クライアントは、ＭＣＵを用いてＲＴＰ媒体チャネルを直接構築する。クライアントは、ＭＣＵへの参加が成功すると、参加者追加イベントをフォーカスに送信する。フォーカスは、その後、参加者追加のＭＣＵ状態変更通知を会議の全てのウォッチャに送信する。

図１４は、クライアントがＭＣＵへの直接招待を介して参加する例示的なコール・フロー図を図示する。ＭＣＵへの直接媒体ＩＮＶＩＴＥは、ＳＩＰを使用してセッション（例えば、Ａ／Ｖ ＭＣＵ、ＩＭ ＭＣＵ）を構築するＭＣＵとともに機能する。クライアントは、事前のアドユーザーコールを全く必要とせずに、メディアセッション招待をＭＣＵ ＵＲＩに直接送信することが可能である。ＩＮＶＩＴＥは、フォーカスにルーティングされた状態になり、フォーカスは、クライアントの代わりに、ＭＣＵに対してアドユーザーを開始する。ＭＣＵは承認し、接続情報で応答する。フォーカスは、接続情報がルーティング可能なＳＩＰアドレスであるかどうかをチェックし、ＩＮＶＩＴＥを直接ＭＣＵに転送する。これは、主として、非Ｃ３Ｐの純粋なＳＩＰクライアント（ｎｏｎ−Ｃ３Ｐ ｐｕｒｅ ＳＩＰ）をサポートして会議にダイアルインする、ということである。Ｃ３Ｐクライアントは、ＭＣＵ ＵＲＩを会議通知からフェッチし、ＲＥＦＥＲメッセージを、ＭＣＵに直接ダイアルインを試すことができる純粋なＳＩＰクライアントに送信することができる。

さらに具体的には、クライアントは、ＩＮＶＩＴＥを通知ドキュメントで受け取ったＭＣＵ ＵＲＩに送信する。このＩＮＶＩＴＥは、フォーカスにルーティングされた状態になる。クライアントは、メディアネゴシエーションのためのセッション記述を追加することが可能である。ＩＮＶＩＴＥが特定のＭＣＵへアドレス指定されていることをフォーカスが知っている場合、フォーカスは、ＩＮＶＩＴＥの本文内の任意のセッション記述を無視してもよい。フォーカスは次に、ＨＴＴＰ要求を、新しい参加者（アドユーザーのダイアルイン）を推測するようフォーカスに求めている割り当てられたＭＣＵに送信する。フォーカスが、このときこのＭＣＵと初めて通信する場合、ＭＣＵ上の会議を初期化するように他のブートストラップ要求を送信することができる。ＭＣＵは、推測される参加者のコールに対して成功メッセージのレスポンスを返す。レスポンスはまた、参加者にＭＣＵと通信させたい実際のＵＲＬを有することがある。

Ａ／Ｖ ＭＣＵの場合、ＵＲＬは、参加者がＳＩＰを介してＭＣＵと通信することが可能であることを示す。Ａ／Ｖ ＭＣＵの場合、フォーカスは、ＩＮＶＩＴＥをＭＣＵに転送する。クライアントは、ＡＣＫを返信し、ＩＮＶＩＴＥダイアログを終了して、そのＩＮＶＩＴＥダイアログがＭＣＵとのメディアネゴシエーションのためにも使用されるようにする。ここで、クライアントは、ＭＣＵを用いてＩＮＶＩＴＥダイアログを直接構築するが、ＳＩＰは、それ自身にフォーカスを通してトラバースするよう要求することに留意されたい。クライアントは、ＭＣＵへの参加が成功すると、参加者追加イベントをフォーカスに送信する。フォーカスは、参加者追加のＭＣＵ状態変更通知を会議の全てのウォッチャに送信する。クライアントとＭＣＵとの間の直接のメディアネゴシエーションが得られる。オーディオ／ビデオの場合は、これがＲＴＰ／ＲＴＣＰストリームであり得る。

図１５は、ダイアルインすることになる別のクライアント参加者へのアドホック招待の例示的なコール・フロー図を図示する。クライアントは次いで、アプリケーションＩＮＶＩＴＥ（ａｐｐ ＩＮＶＩＴＥ）を参加者に送信する。承認ＰＩＮが君困れた会議ＵＲＬを有するアプリケーション招待は、ユーザーのクライアントにメッセージ・プロンプトとして表れる。参加者は、メッセージ・プロンプトを受け取る／クリックすると、会議の参加者にダイアルインする会議クライアントを起動する。

さらに具体的には、クライアントは、（もしあれば）承認情報を含め、会議にダイアルインする参加者に対して必要な全ての情報を含むアプリケーション招待を、参加者に送信する。アプリケーション招待は、コンソールにプロンプトとして表れる。参加者が、プロンプトを受け取ると、会議クライアントが起動して、クライアントが会議にダイアルインできるようになる。クライアントが、会議へのダイアルインを成功した後、フォーカスは、名簿更新の通知を会議の全てのウォッチャに送信する。

図１６は、別のクライアントへのアドホック・ダイアルアウトＩＮＶＩＴＥに関する例示的なコール・フロー図を図示する。クライアント参加シーケンスは、クライアント１とフォーカスとの間で開始され、クライアント１からフォーカスへのＩＮＦＯアドユーザーのダイアルアウトメッセージが後に続く。２００ ＡＣＣＥＰＴメッセージがフォーカスから返される。フォーカスは、アドユーザーのダイアルアウトメッセージをＭＣＵに送信し、ＭＣＵは２００ ＯＫで応答する。ＭＣＵは、第２のクライアント２に、フォーカスを介してルーティングされるＩＮＶＩＴＥメッセージを送信する。クライアント２は、２００ ＯＫメッセージで応答し、ＭＣＵからのＡＣＫが後に続く。次いで、媒体ストリーム（例えば、ＲＴＰを使用して）が、ＭＣＵとクライアント２との間に開始される。ＭＣＵは、参加者追加イベントをフォーカスに送信する。その後、フォーカスは、クライアント２が会議セッションに加わったことを示す更新名簿メッセージを、クライアント１に送信する。

上記で言及されたアプリケーション招待機構は、アプリケーション招待およびＣ３Ｐプロトコル機構を理解する新しいクライアントで機能する。しかし、Ｃ３Ｐを理解しないレガシークライアントを招待することができる。この機構を使用して、純粋なＳＩＰクライアントを会議に入れることもできる。クライアントは、ＢＹＥを初期ＩＮＶＩＴＥダイアログに送信して、会議を退出することができる。故障したクライアントを検出するために、セッション・キープアライブ・メッセージを使用することが可能である。

会議状態通知は、ＭＣＵからフォーカスへ、そしてフォーカスからクライアントへ、行われることが可能である。状態通知データモデルは、次の要素を含む。すなわち、会議記述（例えば、タイトル、主題、主催者の記述）；能力、現在の状態、設定およびポリシーに関する情報を含む会議ビュー（例えば、ＡＶ ＭＣＵ、ＩＭ ＭＣＵなどの各エンティティフォーカスについての会議レベル情報）；ユーザー（例えば、会議の名簿、ユーザー、対応するエンドポイントおよびそれらが接続するメディアセッション）；および、サブ会議を表示するサイドバーである。

以下のコードは、会議状態の階層の一例を表す。
Conference-info [1..1]
Conference-description [0..1]
Conference-view [0..1]
Entity-view [0..N] (keyed by entity URI)
Entity-capabilities [0..1]
Entity-policy [0..1]
Entity-settings [0..1]
Entity-state [0..1]
Conference-media [0..N] (keyed by media label)
Users [0..1]
User [0..N] (keyed by user URI)
Endpoint [0..N] (keyed by endpoint URI)
Media [0..N] (keyed by media id. Label is a
reference to conference-media
element, see below.)
Sidebars-by-val [0..1]
Entry [0..N] (recursively defines a sub-conference object).

以下のコードは、２つのＭＣＵ（例えば、Ａ／Ｖ、データ）がありユーザーがログインしていない、初期会議状態の一例を表す。
<conference-info >
<conference-description>
<display-text>brownbag </display-text>
<conf-uris>
<entry>
<uri>sip:organizor@msft.com;ms-app=conf/meeting;ms-conf-id=cd</uri>
<display-text>Data MCU</display-text>
<purpose>meeting</purpose>
</entry>
<entry>
<uri>sip:organizor@msft.com;ms-app=conf/audio-video;ms-conf-id=cd/uri>
<display-text>AV MCU</display-text>
<purpose>audio-video</purpose>
</entry>
</conf-uris>
</conference-description>
<conference-info >

以下は、参加とＡ／Ｖ ＭＣＵのブートストラップをユーザーが試みる、コードの一例を表す。
<conference-info >
<conference-description>
…
</conference-description>
<conference-view>
<entity-view entity="focus " / >
<entity-view entity="AV" >
<entity-state />
<entity-view />

<entity-view>
<conference-view>
</conference-info >

以下は、フォーカスに加わるユーザーのボブ（Ｂｏｂ）に関するコードの一例を表す。
<conference-info >
<conference-description>
…
</conference-description>
<conference-view>
....
</conference-view>
<users >
<user entity="sip:bob state="full" >
<display-text>bob<display-text>
<roles><entry>presenter</entry></roles>
<endpoint entity="sip:bob;focus" >
<status>connected</status>
</endpoint>
</user>
</users
<conference-info >

以下は、ＡＶ ＭＣＵに加わるユーザーのボブ（Ｂｏｂ）に関するコードの一例を表す。
<conference-info >
<conference-description>
…
</conference-description>
<conference-view>
....
</conference-view>
<users >
<user entity="sip:bob state="full" >
<display-text>bob<display-text>
<roles><entry>presenter</entry></roles>
<endpoint entity="sip:bob;focus" >
<status>connected</status>
</endpoint>
<endpoint entity="sip:bob;AV" >
<status>connected</status>
</endpoint>

</user>
</users
<conference-info >

フォーカス・ファクトリーＵＲＩを見つけることは、いくつかの方法で行うことができる。すなわち、グループポリシーの利用による方法、サーバーのＤＮＳ（ｄｏｍａｉｎ ｎａｍｅ ｓｅｒｖｅｒ）、固定ＵＲＩ、およびユーザープロファイルデータによる方法である。

管理者によって共通に使用され、クライアントに設定を分散する方法は、グループポリシー・オブジェクト（ＧＰＯ：Ｇｒｏｕｐ Ｐｏｌｉｃｙ Ｏｂｊｅｃｔｓ）を使用することである。ある特定のアプリケーションの設定と特性は、ＧＰＯ設定を通してオンまたはオフされることが可能である。例えば、管理者は、ＧＰＯを通して、ある特定メニューオプションを削除し、あるいは他のものを幾つか追加するという選択をすることができる。ＧＰＯの使用を通して、ドメイン管理者は、ユーザーの特定のセットに特定のフォーカス・ファクトリーを示すことができる。これにより、手動構成の要求が排除される。

別のオプションは、ＤＮＳレコードを使用して、クライアントにフォーカス・ファクトリーＵＲＩを示す。ＤＮＳ ＳＲＶは、標準ＤＮＳサーバーの拡張であり、このＤＮＳ ＳＲＶを使用して、サーバーの１つまたは複数のＩＰアドレスを取得することができる。このＩＰアドレスはそれぞれ各自の優先度を持つ。下記は、ＳＲＶレコードの一例である。
_http._tcp.example.com. SRV 10 5 80. www.example.com
ＳＲＶレコードの命名規則は、レコードが以下のものを順番に含むことを要求する。順番に、サービス名が後に続くアンダーライン、ピリオド、プロトコルが後に続くアンダーライン、ピリオド、そして、ドメイン名である。

別のオプションでは、以下のようなフォーカス・ファクトリーに固定のＵＲＩを使用する。
sip:FocusFactory@microsoft.com
このアプローチは、推測・発見要求を完全に排除する。プールのフロントエンドマシン上で作動するアプリケーションは、これを特別なＵＲＩであると解釈し、そのように扱う。これは、同一のＵＲＩが、多数のプール内で作動するアプリケーションによって表されることを意味する。

別のアプローチは、ユーザープロファイルデータによるものである。ユーザーはサインオンして、ローミング接続およびセキュリティ情報を取得する。クライアントは、ローミング接続、ローミングＡＣＬ（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔｓ：アクセス制御リスト）、ユーザーのプレゼンスデータに対する未処理の申込み要求などを含む、様々のタイプのデータを申し込むことが可能である。この情報は、プレゼンスストアに格納される。データは、クライアントがイントラネットの内部であるか外部であるかに関わらず、クライアントに搬送される。クライアントは、そのプレゼンス情報で登録するときは、これらのデータタイプを申し込み、サーバーがＳＩＰプロトコルを使用して（ＮＯＴＩＦＹメッセージを使用して）、それらを送信する。

別のデータタイプ、ＦｏｃｕｓＦａｃｔｏｒｙＵＲＩを導入することにより、クライアントは次に、そのデータを申し込むこともでき、それを元のハンドシェークの一部として受け取る。追加の利点は、クライアントがＦｏｃｕｓＦａｃｔｏｒｙＵＲＩデータタイプを申し込んだため、この情報が変わると、クライアントはＳＩＰセマンティックを使用して通知されることである。

このデータをどのように格納することができるかに関しては、２つのオプションがある。第１に、各ユーザーは、別個のＦｏｃｕｓＦａｃｔｏｒｙＵＲＩを持つことができる。このアプローチにおいて、プレゼンスストアは拡張可能であり、電子会議に対してイネーブルにされた各ユーザーおよび全てのユーザーのＵＲＩを格納する。第２のアプローチにおいては、フォーカス・ファクトリーＵＲＩは、そのプール内にある全てのユーザーが共有する、プールレベルの設定である。このアプローチの利点は、各ユーザーに対して管理されるべきファクトリーＵＲＩを必要とせず、プール全体に対して単一のＵＲＩを格納することである。プール設定がプール内の全てのフロントエンド・サーバー間で共有されるため、各フロントエンド上で作動するユーザーサービスモジュールは、この設定へのアクセスを有する。設定は、システム内の他のプールに対して可視である。

フォーカス・ファクトリーおよびフォーカス・インスタンスは、ユーザーがホームとしないプール上でホストされることが可能である。これにより、クライアントからフォーカス・ファクトリーとフォーカス・インスタンスとをホストしているプールへの要求に対して、ルーティング要件が作成される。最初の要件がない場合でも、要求は、異なるプールに接続されるクライアントからフォーカス・インスタンスをホストするプールにルーティングされる。

ユーザーサービスは、クライアントにより求められる様々なタイプのデータをデータベースに照会し、それをＸＭＬフォーマットにフォーマットし、ＮＯＴＩＦＹメッセージで応答することができる。この特定のデータタイプに対して、データベースに行ってデータを取り出す代わりに、要求を受け取るフロントエンドマシンは、プールレベルの設定を参照し、ＸＭＬドキュメントを作成してＮＯＴＩＦＹとともに送信することができる。設定が更新されると、ユーザーサービスは、その変更を時間ウィンドウ（ｔｉｍｅ ｗｉｎｄｏｗ）で通知されるため（例えば、５分）、設定のためにそのローカルな値を更新することが可能になる。

多数のドメインからのユーザーがホームとするプールに対しては、設定は、ホームとされるドメインのそれぞれについて構成可能であるので、ホームとされる異なるドメインの異なるファクトリーＵＲＩを許可することができる。これの一例がホスティング・ソリューションであり、ユーザーが多くの可能なドメインに渡って広がっている。多数のドメイン名をプールごとに格納し、フォーカス・ファクトリーＵＲＩをそれらに割り当てる能力が提供される。設定は全てのプールに対して可視である。

クライアント・アプリケーションは、フォーカス・ファクトリーと通信し、新しい会議を開始する。上で述べたように、ユーザーがサインオンするときに、クライアント・アプリケーションがフォーカス・ファクトリーＵＲＩを取得するので、クライアント・アプリケーションは、フォーカス・ファクトリーと任意の時間に通信して、新しいアドホック会議を開始する手段を有する。ＳＩＰクライアントが別のクライアントと通信したいとき、クライアント間のＳＩＰダイアログは、あるパーティによって別のパーティに送信されたＩＮＶＩＴＥで開始する。ＳＤＰ（セッション記述プロトコル）パッケージは、ＩＮＶＩＴＥ内のペイロードおよびその同一のＩＮＶＩＴＥに対する２００ ＯＫレスポンスとして、メディアネゴシエーションのために搬送される。

開示されるフレームワークにおいて、会議を作成することは、フォーカス・インスタンスを作成し、構成することを意味する。フォーカス・ファクトリーのジョブは、フォーカスへのＵＲＩをクライアントに返すことである。これは、クライアントとフォーカス・ファクトリーとの間の会話はそれほど長く続けられる必要はないということを意味する。フォーカスＵＲＩがクライアントへ戻されるまで持続する必要があるだけである。

フォーカス・ファクトリーは、フォーカスを作成して構成した後に、そのＵＲＩをクライアントに戻す。構成は、この会議で使用される媒体のタイプ、予想される参加者の数、既知の参加者の役割と権限、役割の定義などを設定する。

フォーカス・ファクトリーは、ミーティングの事前のスケジューリングを可能にするウェブサービスインターフェースを有する。そのシナリオにおいては、会議クライアントは、フォーカスと直接通信し、フォーカス・ファクトリーとのダイアログを構築することはない。しかし、アドホック会議では、会議クライアントは、フォーカス・ファクトリーと通信して、フォーカス・ファクトリーにフォーカスＵＲＩを提供させる。

図１７は、リダイレクションを使用する、例示的なコール・フロー図を図示する。最初に、クライアントは、ＩＮＶＩＴＥをフォーカス・ファクトリーＵＲＩに送信する。
・Ｔｏ＝Ｆｏｃｕｓ Ｆａｃｔｏｒｙ ＵＲＩ
・Ｆｒｏｍ＝Ｕｓｅｒ ＵＲＩ
・Ｃｏｎｔｅｎｔ−Ｔｙｐｅ＝Ｍｕｌｔｉ−ｐａｒｔ ＭＩＭＥ
・Ｃｏｎｔｅｎｔ＝ＸＭＬコンテンツ（初期参加者リスト、役割マッピング、およびテンプレート識別トークンを含む）

プール上で作動するフォーカス・ファクトリー・アプリケーションは、メッセージを受信し、１００（進行中（Ｉｎ Ｐｒｏｇｒｅｓｓ）、または１８０）リンギング仮レスポンスを返す。これにより、任意のデータの準備およびルックアップがフォーカス・ファクトリーによって実行される間は、クライアントを待機させることができる。フォーカス・ファクトリーは、フォーカスを作成し、３０２のリダイレクト・レスポンスのコンタクトヘッダ内のフォーカスＵＲＩを返す。これにより、クライアントは、コンタクトヘッダ値を会議ＵＲＩとしてキャッシュすることができる。クライアントは、同一のＩＮＶＩＴＥを、受信したフォーカスＵＲＩに送信する。Ｔｏ：ヘッダが、この時の会議ＩＤであるＧＲＵＩＤパラメータを有する、ということだけが異なる。

図１８は、クライアントの会議への参加とは別に会議の作成を扱う、例示的なコール・フロー図を図示する。これは、発生するオペレーションの段階をより良く反映する。従って、会議の作成には、クライアントからフォーカス・ファクトリーにＩＮＶＩＴＥを渡すこと、返される１８０の進行中レスポンスを受信すること、ＣｒｅａｔＦｏｃｕｓをフォーカス・ファクトリーからフォーカスに送信してフォーカス・インスタンスを作成すること、フォーカスデータをフォーカス・ファクトリーに返すこと、接続フォーカスＵＲＩをクライアントに送信すること、および、受信したことの確認応答することが含まれる。会議への参加に関連するメッセージには、ＩＮＶＩＴＥをクライアントへのフォーカスＵＲＩとともにフォーカスに送信すること、クライアントへ返される２００ ＯＫを受信すること、および、受信したことの確認応答することが含まれる。

ＩＮＶＩＴＥメッセージをクライアントから受信すると、フォーカス・ファクトリーは、フォーカスを作成して、フォーカス情報をクライアントに返す。フォーカスは、フォーカス・ファクトリーと同様に、アプリケーションによって表されるＳＩＰエンドポイントである。フォーカス・ファクトリーは、受信するＩＮＶＩＴＥ要求をフォーカスにリダイレクトするため、フォーカスが、クライアントとともにメディアネゴシエーションするエンドポイントになることが可能になる。

上記で示したように、フォーカスは、会議の「登録された」ハンドラである。フォーカスＵＲＩは、会議を表し、また会議ＵＲＩとして参照される。１つの決定論的方法では、ＵＲＩのユーザーセクションに固定のパターンを使用し、それに会議ＩＤ情報で注釈をつける。このことは、ルーティング・ロジックが、ＵＲＩに基づいてより簡単な方法で書き込まれることを可能にし、フォーカスＵＲＩが、企業内の単一のアプリケーションにマッピングされることを可能にし、したがってシステムの管理が容易になる。この使用は、ＳＩＰへの「ＧＲＵＵ／ＧＲＩＤ拡張」によって概説され、これは、ＧＲＵＵパラメータを周知のフォーカスＵＲＩに付加することを可能にする。下記は例である：
Sip:conf-mgr@confserver.company.com;grid=Schumacher1980
Sip:FocusFactoryMS@conferencing.microsoft.com;grid=conf34242834

フォーカス・ファクトリーの動作は、フォーカス・ファクトリーが作動しているプールと同じプール上でフォーカスが存続するというものである。これは、会議フォーカス・インスタンスを、ＳＩＰレジストラ・サーバーとは完全に別個にスケーリングするための構成可能な設定であり得る。

フォーカス・インスタンスは、プールの全てのフロントエンドマシン上で同時に作動する。これにより、クライアントは、負荷の分散とより良いスケーリングが可能なプール内の任意のフロントエンドに接続することができる。会議のフォーカス・インスタンス間で共有されるフォーカス状態は、データベース内に保持される。このデータは、名簿、役割と権限、媒体タイプ、およびＭＣＵ識別子などを含む。各フォーカス・インスタンスは、フォーカス・インスタンスが作動している特定のフロントエンドに接続されるクライアントに関する接続状態を処理する。各フォーカス・インスタンスはＳＩＰエンドポイントであるので、これらの接続はＳＩＰダイアログである。

フォーカスＵＲＩがクライアントに渡されるとき、そのＵＲＩの一部は、会議ＩＤ、すなわち、データベース内の会議レコードを参照するデータベースエンジンにより生成される数字である。データベースレコードは、レコードをどのくらいの期間データベースに保持すべきかを示すデータ、および会議に関する他の情報を含む。

フォーカスＵＲＩをクライアントに渡した後、フォーカス・ファクトリーは、状態を持続する必要が全くなく、または仕事をする必要が全くない。クライアントが、ＩＮＶＩＴＥを、該クライアントが接続するホームサーバーを介してフォーカスＵＲＩに送信すると、そのＩＮＶＩＴＥは、会議をホストするプールにルーティングされる。ＩＮＶＩＴＥを受信すると、プール内のフロントエンドマシンの１つがフォーカスを作成して、クライアントに応答する。

上記で示したように、フォーカス・インスタンスは、プールの全てのフロントエンドマシン上で作動する。考慮すべき問題には、ルーティング、パフォーマンス、安定性、および信頼性がある。上記に述べたように、会議に関連する状態は、プールの全てのフロントエンドマシンによってアクセス可能なデータベースに格納される。これにより、会議に関する状態を、プール内の異なるフロントエンドマシン上で作動するフォーカス・アプリケーションの多数のインスタンス間で共有することが可能になる。その結果、各クライアントは、そのプールおよび／またはホームサーバーに接続し、クライアントが到達しようとしているフォーカスは、そのボックス上で作動して、クライアントが送信する会議関連の全ての要求に応えるために準備をする。

図１９は、プール内の異なるフロントエンドマシン上で作動するフォーカス・アプリケーションの多数のインスタンス間で状態を共有するサーバー・プールシステム１９００を図示する。システム１９００は、全てのフロントエンドマシン（またはフロントエンド）にわたって負荷を分散し、ルーティング要求を排除し、可用性の高い特性を使用することによって、ルーティング、パフォーマンス、安定性、および信頼性の問題に対処する。接続管理負荷は、プールの全てのフロントエンドマシン間でランダムに分散される。追加のフロントエンドマシンを、容易に追加し、削除することができるが、これは、該フロントエンドマシンが、プールに関連していることの他には識別を有していないからである。安定性に関しては、フロントエンドが故障した場合、そのフロントエンドに接続された全てのユーザーは、会議への接続試して再接続することができる。全てのこれらのユーザーは、再度ロードバランシングされ、同じプール内の他のフロントエンドに接続される。ルーティングの問題は、何も必要とされないため排除される。会議の共有状態は、データベースに格納され、全てのフロントエンドが、これにアクセスすることができる。１つのマシンも情報ブローカである必要はない。

図２０は、フォーカス・インスタンス有する２つの別個のクライアント−フォーカスのダイアログの例示的なコール・フロー図を図示する。ＩＮＶＩＴＥダイアログは、クライアントが会議に加わることを可能にするダイアログであり、クライアントからフォーカスへのさらなるコマンドトラフィックに使用される。クライアントからのコマンドは、ＩＮＦＯメッセージ内部で搬送される。ＩＮＦＯメッセージの本文は、ＳＯＡＰと同様のＸＭＬの本文を含み、フォーカスにより処理される。ここで、図２０の単一ＩＮＦＯメッセージは、会議の存続時間中の全てのＩＮＦＯメッセージを表すことに留意されたい。クライアントに割り当てられた役割に基づいて、クライアントは、会議コントロール、会議ポリシーコントロール、媒体コントロールまたは媒体ポリシーコントロールのためのコマンドを発行することができる。

クライアントが会議に加えられると、クライアントは、参加者の追加および削除、媒体の追加および削除など、会議内で発生しているイベントを通知される。会議状態に対するこれらの変更、ならびに会議および媒体のポリシーに対する変更は、このダイアログ内のクライアントに送信されるＮＯＴＩＦＹメッセージを通して搬送される。ＩＮＶＩＴＥダイアログ内のクライアントによってＩＮＦＯメッセージを使用して送信されたコマンドが、会議状態を変更するコマンドである場合、フォーカスは、クライアントに、会議状態の変更されたセクションを含むＮＯＴＩＦＹを送信することによって通知する。ここで、図２０の単一のＮＯＴＩＦＹメッセージは、会議の存続時間中の全てのＮＯＴＩＦＹメッセージを表すことに留意されたい。

会議内で、あるタイプの媒体を開始するためのオプションは、作成されたフォーカス、およびフォーカスが作成されるときに会議が通知された全てのＭＣＵを有することである。これにより、後に媒体のイネーブルが素早くできる。加えて、媒体が前もってイネーブルされるので、ＭＣＵは、該ＭＣＵに接続可能な名簿の一部について前もって知っており、したがって、媒体に対するユーザー追加オペレーションを、遅延なく実行することが可能になる。このモデルにおいては、フォーカスは、作成されるとすぐに、ミーティング状態を割り当てているＭＣＵにコマンドを送信し、予想される参加者の会議名簿上に渡す。フォーカスは次いで、使用される媒体タイプに対して会議状態をＭＣＵ情報で更新する。このように、参加者が媒体に入り参加するときはいつでも、フォーカスが、ＭＣＵに行って接続情報を取得する必要はない。経験は、ミーティングに参加する最初および最後の参加者に対して、一つであり同じであろう。

上記で示したように、ＭＣＵファクトリーは、アクセス情報をＭＣＵに提供する論理エンティティである。ＭＣＵファクトリーは、ＭＣＵ装置またはソフトウェアのベンダのためのベンダ固有の実装とすることができる。フォーカスは、設定を通じて、どのＭＣＵファクトリーがシステムに存在し、該ＭＣＵファクトリーがサポートするのはどの媒体タイプであるかについて知る。フォーカスは、ＭＣＵファクトリーに、どのようにＭＣＵにコンタクトをとるのかに関する情報を求め、ＭＣＵファクトリーは、作動している全ての内部論理に基づいてその情報を返す。

例えば、ファーストパーティＭＣＵおよびサードパーティＭＣＵが、Ａ／Ｖアクティビティに対して存在する展開を考える。これは、ＭＣＵファクトリーリストが、２つのエントリ、すなわち、この媒体タイプに対してこれらのベンダ各々につき１つを含むことを意味する。設定の表示の例には以下のものが含まれる。

Ａ／Ｖアクティビティを有する会議が作成されると、その会議を表すフォーカスは、その会議に使用されようとしているＭＣＵのタイプのＭＣＵファクトリーとコンタクトをとる。多数のＭＣＵファクトリーが存在する、このようなシナリオにおいて、フォーカスは、ＭＣＵファクトリーの１つを選択する。テンプレートの使用により、これは解決される。

Ｃ３Ｐは、会議状態を修正するのに使用される会議コントロール／操作コントロールプロトコルである。開示されるアーキテクチャにおいて、Ｃ３Ｐコマンドは、クライアントからフォーカスへ、およびフォーカスからＭＣＵへ流れ、逆方向は会議通知のために適用される。Ｃ３Ｐは、ＳＩＰと同様に、要求／未処理レスポンス／最終レスポンスのセマンティックを有する。

図２１は、クライアントが会議状態を修正するためのＣ３Ｐコマンドを発行する、例示的なコール・フロー図を図示する。クライアントは、フォーカスへの参加シーケンスを開始する。ＩＮＦＯ Ｃ３Ｐコマンドが、クライアントからフォーカスに送信される。フォーカスは、２０２ ＡＣＣＥＰＴで応答する。フォーカスは、Ｃ３Ｐ要求をデータコラボレーションＭＣＵに送信し、続いて同一のタイプの要求をオーディオ／ビデオＭＣＵに送信する。フォーカスはまた、クライアントにＩＮＦＯ Ｃ３Ｐレスポンスを送信し、続いて２００ ＯＫメッセージを送信する。フォーカスは次に、状態変更通知を（ＢＥＮＯＴＩＦＹを介して）クライアントに送信する。ＭＣＵ（データコラボレーションおよびＡＶ）は、Ｃ３Ｐレスポンスをフォーカスに送信する。データコラボレーションＭＣＵおよびＡＶ ＭＣＵはそれぞれ、状態変更通知をＣ３Ｐコマンドによってフォーカスに送信する。フォーカスは次に、対応する状態変更通知を（ＢＥＮＯＴＩＦＹを介して）クライアントに送信する。

図２２は、分散ＭＣＵ電子会議アーキテクチャに従って利用することができるＣ３Ｐコマンドを図示する。コマンドは、会議レベル、ユーザーレベル、サイドバーレベル、エンドポイントレベル、エンドポイント媒体レベル、レコーディング、ロードバランシング、およびスケジューリング仕様に関する。会議レベルにおいては、会議の追加、削除、変更、ロック変更、媒体フィルタ変更、記録された名前の再生、および会議の取得が可能である。ユーザーレベルにおいては、ユーザーの追加、削除、および修正、ユーザーの役割変更、ならびにユーザーのアクセス設定が可能である。エンドポイントレベルにおいては、エンドポイントの役割が変更可能である。エンドポイント媒体レベルにおいては、媒体のエンドポイントの追加、削除、および変更が可能である。サイドバーレベルにおいては、サイドバーの追加、削除、および変更が可能である。ユーザーをサイドバーに移動させることもできる。レコーディングに関しては、レコーディングを、開始、停止、一時停止、およびレジュームすることが可能である。スケジューリングに関しては、利用可能なＭＣＵタイプ、暗号化キー、および会議を（ｇｅｔを付けて）得ることが可能である。ロードバランシングに関しては、ＭＣＵをｐｉｎｇ値とともに得ることが可能である。

開示される会議アーキテクチャは、幾つかの構成でインストールされ、中小企業向けの簡単な単一のサーバーのインストールで開始し、マルチサーバーインストールおよび異なるスケーリングの特徴を有する会議機能のそれぞれに対して異なる数のサーバーを用いた、ホストされるメガ・サービスへの部門別インストールで開始することが可能である。構成要求は、今度はサーバーキテクチャ、および機能の一部分を別々にする方法を行う。

単一のサーバー構成においては、プレゼンス、インスタント・メッセージ、マルチパーティウェブ会議、オーディオ／ビデオ会議、およびレコーディングを提供するために必要な全てのサーバーコンポーネントを、単一のマシン上にインストールすることができる。このモードにおいて、例えば、レジストレーションおよびプレゼンス、会議マネージャ、会議フォーカス、Ａ／Ｖ ＭＣＵ、ならびにデータＭＣＵコンポーネントのための「ホームサーバー」は、全て同一のサーバー上で作動する。この構成は、少数のユーザーおよび並行するミーティングをサポートする。例えば、１００人程度のユーザーが任意の所与の瞬間にＩＭを行い、５０程度の並行するマルチメディア会議の参加者（データ／オーディオ／ビデオ）があると仮定すると、単一のサーバーのインストールは、最大でも５００人までの並行するユーザーのプレゼンスをサポートすることができる。レジストレーションならびに会議データベースもまた、単一サーバー上で作動する可能性がある。ＴＣＰポートおよびＵＲＬ名前空間は、共有リソースである。

図２３は、複数のフロントエンド・サーバー２３００が同等の機能を有する、マルチ・サーバープールを図示する。このモデルにおいて、多数のサーバーが、ＩＰロードバランサ２３０２の後方に実装される。多数のサーバーは、可用性の高い解決方法を提供し、これは、サーバーフロントエンドシステムの１つが故障すると、クライアントが、フロントエンドの故障を検出し、自動的に他の利用可能なフロントエンド・サーバーの１つに再接続する。

これらのフロントエンド２３００のぞれぞれは、レジストレーション、プレゼンス、およびルーティング機能を含むだけでなく、会議機能も含む。各フロントエンドは、フォーカス・ファクトリー、ＭＣＵファクトリー、ゼロまたはそれ以上のフォーカスホスト処理、および媒体ＭＣＵ処理のインスタンスを実行する。会議セッションを含むように、故障の検出およびテイクオーバのロジックを拡張することができる。会議の途中で障害が発生した場合、クライアントが、フォーカスに戻って接続可能であり、フォーカスは、サーバープール２３００上で故障が発見されると別のフロントエンド・サーバー上で再インスタンス化される。新しいフォーカスは、前のフォーカスが有していた状態をできるだけ有し、クライアントが会議を中断したところから続けることを可能にする。

全てのサーバー２３００が、機能的に同等である。フォーカス・ファクトリー、フォーカス、ＭＣＵファクトリー、ＭＣＵ、ウェブスケジューリング・インターフェースなどのソフトウェアコンポーネントは、全てのフロントエンド・サーバー上にインストールされる。フォーカスおよびＭＣＵは、異なるスケーリングの特徴を有するが、この構成は、設定および管理の簡素さを提供しつつ、高い可用性および障害回復を提供する。アーキテクチャはまた、ＭＣＵを別個のボックスに分けることも可能にする。

図２４は、障害回復および高い可用性を有する特徴のためのマルチ・サーバープール２４００構成を図示する。加えて、該構成は、異なるスケーリングの特徴を有する機能を、異なるサーバーに分ける能力を提供する。さらに、複数のＭＣＵ２４０２を、会議のスケーリングのために、ならびに、企業間または企業とホストされるサービスとの間の連合を可能にするためにチェイニングすることができる。ＭＣＵは、媒体を中継、混合、および処理する。媒体の転送および処理は、フォーカスを通して渡すシグナリング・会議コントロールデータと比較すると、よりＣＰＵおよびネットワークに集約的である。従って、ＭＣＵを、プレゼンス、シグナリングおよび会議コントロール要素から独立してスケールリングすることが可能である。

図２５は、分散媒体コンポーネントアーキテクチャのエンティティ間の、様々なタイプのデータフローのトポロジ図を図示する。ＭＣＵ（例えば、ＩＭ ＭＣＵ、Ａ／Ｖ ＭＣＵ）を有するようなクライアント・サーバー（Ｃ／Ｓ）通信、およびロードバランサへのクライアント・サーバー（Ｃ／Ｓ）通信は、ＳＩＰを介するものである。ロードバランサは、ＳＩＰを使用して、フロントエンド・サーバーともインターフェース接続することができる。オーディオ／ビデオストリームに対しては、クライアントは、ＲＴＰ／ＲＴＣＰを使用して、インターフェース接続することができる。データコラボレーションＭＣＵとの対話では、クライアントはＰＳＯＭを使用することができる。各ＭＣＵは、ＨＴＴＰを使用してフロントエンド・サーバーとインターフェース接続することができ、ＨＴＴＰはＭＣＵファクトリーにも使用される。会議ウェブサーバーは、ブラウザアプリケーショによりアクセス可能である。該ウェブサーバーは、例えば、ＯＤＢ（ｏｂｊｅｃｔ ｄａｔａｂａｓｅ）／ＡＤＯ（ＡｃｔｉｖｅＸ ｄａｔａ ｏｂｊｅｃｔｓ）を使用して、フォーカスバックエンドサーバー（例えば、ＳＱＬサーバー）にアクセス可能である。フロントエンド・サーバー（例えば、フロントエンド１）は、ＯＤＢ／ＡＤＯを使用して、バックエンドサーバーにアクセスすることもできる。サーバー間（Ｓ／Ｓ）通信（例えば、ＩＭ ＭＣＵとサーバープール、Ａ／Ｖ ＭＣＵとサーバープール）は、ＳＩＰを使用すると可能である。ロードバランサは、サーバー間ＳＩＰを使用して、１つまたは複数のフロントエンド・サーバーとインターフェース接続することができる。

図２６は、プラグ可能な分散媒体コンポーネントを使用する、会議アーキテクチャ２６００の全体を図示する。アーキテクチャ２６００はまた、同一の媒体タイプ（例えば、ＩＰとＰＳＴＮの参加者を同一の会議に橋渡しするための、音声ＩＰ ＭＣＵとＰＳＴＮ ＭＣＵの間のカスケードを実装している）に使用されている、多数のＭＣＵの保護を可能にする。会議およびその会議ＵＲＩが（インターフェースＡを使用して）割り当てられ、クライアントが、（インターフェースＢを使用して）会議にアクセスするためのフォーカス許可を受信すると、クライアントは、会議イベント状態情報に（インターフェースＣ上で）申し込み、（インターフェースＣ上で）フォーカスから第１のイベント内で受信したドキュメントから、媒体ＭＣＵごとに実際の会議ＵＲＩを取り出す。クライアントは、取り出された会議ＭＣＵ ＵＲＩ使用して会議にダイアルイン（または参加）し、ファーストパーティの基本のＳＩＰコールシグナリングのオペレーションを（インターフェースＤ上で）ＭＣＵを直接用いて実行する。

ＳＩＰシグナリングは（インターフェースＤ上で）、ＳＩＰルーティング手段によってフォーカスを通して自動的にプロキシされる。ＰＳＯＭシグナリング・データプロトコルは（インターフェースＬ上で）、クライアントとデータＭＣＵの間で直接ルーティングされる。フォーカスを通してプロキシされているＳＩＰ接続は、検査される機会を有しており、認証、承認、会員などに関してローカルなポリシーが強化されている。ここで、ＰＳＴＮ ＭＣＵおよびデータＭＣＵの場合、ファーストパーティのコールシグナリングは、フォーカスを通ってプロキシされていないことに留意されたい。これらのＭＣＵのポリシーは、フォーカスからＭＣＵへ明確にアップロードされることが可能である。クライアントは、（インターフェースＢ上で）元の会議ＵＲＩで構築されたＳＩＰダイアログを使用して、ＣＣＣＰ（本明細書では、Ｃ３Ｐとも呼ばれる）を用いて任意の他のタイプの会議コントロールを実行する。

フォーカスの観点からは、ＡＣＰ ＭＣＵは、転送がＨＴＴＰの代わりにＳＩＰであることを除いて、任意の他のＩＰ ＭＣＵとして扱われている。このインターフェースは、Ｂ^**およびＣ^**として図面に示され、説明されるが、Ｂ^**は、ＳＩＰ上でＣＣＣＰトンネルであり、Ｃ^**は、ＳＩＰ上でトンネルされるＸＭＬイベントの会議パッケージである。一実装おいては、ＡＣＰ ＧＷ（ゲートウェイ）論理モジュールを実装して、ＳＩＰ−ＣＸプロトコルをすでにサポートしているＡＣＰをインフラストラクチャにシームレスに統合することを可能にする。

ファーストパーティのシグナリング（例えば、この場合はＰＳＴＮシグナリング）は、フォーカスに対して可視ではないため、（承認を扱う）さらなるセキュリティハンドシェークが、フォーカスとＡＣＰ ＭＣＵ（およびＡＣＰ ＧＷ）の間で実装される。

データＭＣＵは、ＳＩＰを実装することを必要としない。従って、会議にダイアルインしようと試みるクライアントは、データＭＣＵを示すＨＴＴＰ ＵＲＩへリダイレクトすることになる。ここで、全てのセキュリティの問題（認証および承認を含む）に、データクライアントとデータＭＣＵとの間でＰＳＯＭを使用して直接対処することが可能であることに留意されたい。

会議状態および通知については、システム内の各ＭＣＵは、各ＭＣＵがホストする各会議の状態情報を保持する。この情報は、会議に関するＭＣＵの媒体特有のビューを表す。ＭＣＵは、ＨＴＴＰ上のインターフェースＣ^*のＸＭＬイベントの会議パッケージ上で、会議の状態における変更をメインフォーカスにプッシュする。メインフォーカスは、個々の状態情報を（インターフェースＣ^*上で）各ＭＣＵから動的に受信し、その情報を集約し、各クライアントの申込みおよび権限に従って、クライアントに（インターフェースＣ上で）完全な会議ビューを分散する。関心のある各クライアントおよび潜在的な参加者は、（インターフェースＣ上で）メインフォーカス用いて、その関心のある会議に（会議ＵＲＩを使用して）ＳＵＢＳＣＲＩＢＥ（申込み）をすることができる。

各参加申込者への第１の会議状態通知では、フォーカスは会議に関する全ての情報を含む。会議の混合が多数の媒体ＭＣＵによって実行される場合、各ＭＣＵにルーティングする媒体会議ＵＲＩは、その会議の会議ＵＲＩとしてリストアップされる。クライアントは、ＸＭＬ会議状態ドキュメントを構文解析し、適切なファーストパーティシグナリング（例えば、インターフェースＤ上のＩＮＶＩＴＥ、またはインターフェースＬ上のデータＭＣＵ）をＭＣＵに対して開始する。

ＳＩＰを使用することは、参加者が会議に参加すること、および会議から退出することができることを意味する。ＳＩＰを使用することは、参加者が自身の媒体ストリームを、再ＩＮＶＩＴＥ（ｒｅ−ＩＮＶＩＴＥ）をＭＣＵに送信することによって変更することができることも意味する。この種のオペレーションは、「ファーストパーティシグナリング」と呼ばれ、インターフェースＤとして示される。これらのオペレーションは、会議内の他の参加者の状態には影響しない。

フォーカスを介してＳＩＰを使用して他の会議参加者をコントロールするための、限られたオペレーション（「サードパーティコントロール」と呼ばれる）を得ることもできる。より豊かな会議コントロールを実行するために、ユーザークライアントはＣＣＣＰクライアントを実装することができる。インターフェースＢ上でＣＣＣＰを使用すると、クライアントは、それ自身の状態と、他の参加者の状態と、会議参加者の状態に間接的に影響し得るフォーカス／ＭＣＵの状態とに影響を与えることができる。ＣＣＣＰを使用する会議コントロールは、論理的に会議状態に対して実行される。ＣＣＣＰ要求を使用して、クライアントは、なるべき会議状態をどの程度見たいのかを表現する。ＣＣＣＰサーバーは、オペレーションを実行し、その「マスター」会議状態を更新してその変更を反映する。

「特定の参加者の特定の媒体を保留する」要求の例を見てみよう。クライアントがこのオペレーションを要求するために、最初に必要なのは、アクティブなストリームを有する特定の参加者について学習し、次にこの参加者および特定のストリームを、ＣＣＣＰを使用して明確に示すことである。クライアントが会議システムの明白なコントロールコマンドを発行できるように、フォーカスは、十分に豊富な情報をその通知で提供する。フォーカスの最終レスポンスは、オペレーションのステータスを含み、会議状態の影響された部分を含み得る。ここで、説明されたＣＣＣＰトランザクションとは別に、会議状態変更を、会議状態パッケージに参加申し込みされたユーザーに対して、該ユーザーの権限に従って報告することができる。

フォーカスは、ＭＣＵファクトリーを使用して新しい会議を作成する。フォーカスは、システムまたはプール内の利用可能なＭＣＵファクトリーのリストを、各ＭＣＵファクトリーについて、対応するＵＲＩ、サポートされる媒体タイプ、およびコントロールＵＲＩとともに含む。各ＭＣＵファクトリーは、新しい会議を割り当てることが可能な、サポートされる媒体タイプを有するＭＣＵの論理的なセットを表す。新しい会議を割り当てるために、フォーカスは、１つの互換性のあるＭＣＵファクトリーをテーブルから選択し、「ｇｅｔＭｃｕ」ＣＣＣＰ初期要求を、そのコントロールＵＲＩに（インターフェースＦ上で）発行する。ＭＣＵを選択するよう求めるＣＣＣＰ要求は、所望の会議記述および能力を記載している会議オブジェクトを含むことができる。成功のレスポンスは、ＣＣＣＰ要求がアドレスされるＭＣＵコントロールＵＲＩを含む。故障した場合は、フォーカスは、別の互換性のあるＭＣＵファクトリーを試す。ここで、ＭＣＵファクトリーコントロールＵＲＩおよびＭＣＵコントロールＵＲＩは、ＭＣＵファクトリー実装に従って、ＵＲＩと同じでも異なっていても良いことに留意されたい。記載される分解により、アーキテクチャに影響を与えることなく、各ＭＣＵベンダが、そのＭＣＵファームのためのロードバランシング（または他の種類の論理）実装することが可能になる。

メインフォーカスと各ＭＣＵ（インターフェースＢ^*）との間のコントロールインターフェースは、フォーカスから要求を発行するためのものであり、該コントロールインターフェースを、ＣＣＣＰを使用して実装することができる。このインターフェース上で、フォーカスはＣＣＣＰクライアントとして動作し、ＭＣＵはＣＣＣＰサーバーとして動作する。

インターフェースについての簡単な概要をここで提供する。インターフェースＡは、アドホック会議作成のためのＳＩＰインターフェースである。インターフェースＢは、ｃｃ会議（ファーストパーティおよび限られたサードパーティ）およびＳＩＰ上のＣＣＣＰのためのものである。インターフェースＢ^*は、ＨＴＴＰ上のＣＣＣＰのためのものである。インターフェースＢ^**は、ＳＩＰ上のＣＣＣＰトンネルのためのものである。インターフェースＢ^***は、ＳＩＰ上のＳＩＰ−ＣＸのためのものである。インターフェースＣは、ＳＩＰ上の会議パッケージのＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹのためのものである。インターフェースＣ^*は、ＨＴＴＰ上の会議パッケージＸＭＬイベントのためのものである。インターフェースＣ^**は、ＳＩＰ上をトンネルされる会議パッケージＸＭＬイベントのためのものである。インターフェースＣ^***は、ＳＩＰ−ＣＸ内と同様の会議パッケージＸＭＬイベントのためのものである。インターフェースＤは、ＳＩＰ−ファーストパーティのみのためのものである。インターフェースＦは、会議作成／割り当てのみの用途のＨＴＴＰ上のＣＣＣＰのためのものである。インターフェースＬは、データプロトコル（データおよびファーストパーティシグナリング）のためのものである。インターフェースＭは、媒体（例えば、音声およびビデオ用のＲＴＰ／ＲＴＰＣ）のためのものである。インターフェースＰは、フォーカス・ファクトリーとフォーカスとの間の通信のためのものである。

本出願において使用されるとき、用語「コンポーネント」および「システム」は、コンピューター関連のエンティティ、すなわちハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または、実行中のソフトウェアのいずれかを指すことが意図されている。例えば、コンポーネントは、プロセッサー上で実行されるプロセス、プロセッサー、ハードディスクドライブ、（光および／または磁気記憶媒体の）多数のストレージ・ドライブ、オブジェクト、実行ファイル、実行ファイルのスレッド、プログラム、および／またはコンピューターとすることができるが、これらには限定されない。例としては、サーバー上で実行されるアプリケーションおよびサーバー両方がコンポーネントであり得る。１つまたは複数のコンポーネントは、プロセス内および／または実行ファイルのスレッド内に存在することが可能であり、コンポーネントは、１つのコンピューター上でローカライズされること、および／または２つまたはそれ以上のコンピューター間で分散されることが可能である。

ここで、図２７を参照すると、開示されるアーキテクチャに従って、集中型会議、および分散会議を実行するように作動可能なコンピューターのブロック図が図示されている。その様々な態様の追加のコンテキストを提供するために、図２７および以下の説明は、本発明の様々な態様を実装することができる適切なコンピューティング環境２７００に関する簡単かつ一般的な説明を提供するように意図されている。上記は、１つまたは複数のコンピューター上で実行することができるコンピューター実行可能命令の一般的コンテキストで記載されているが、当業者には、本発明が、他のプログラムモジュールとの組み合わせで、および／またはハードウェアおよびソフトウェアの組み合わせとして実装することができることを認識されよう。

一般的に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者には、本発明の方法を、それぞれが１つまたは複数の関連する装置に動作可能に接続される、シングルプロセッサーまたはマルチプロセッサー・コンピューターシステム、ミニコンピューター、メインフレーム・コンピューター、およびパーソナル・コンピューター、ハンドヘルドコンピューター・デバイス、マイクロプロセッまたはプログラム可能な家庭用電子マシンなどを含む、他のコンピューターシステム構成で実施することができることが認識されよう。

本発明の説明された態様を、ある所定のタスクが通信ネットワークを介してリンクされるリモート処理装置により実行される、分散コンピューティング環境において実施することもできる。分散コンピューティング環境において、プログラムモジュールを、ローカルおよびリモート両方のメモリ記憶装置に配置することができる。

コンピューターは、典型的に、様々なコンピューター読取可能媒体を含む。コンピューター読取可能媒体は、コンピューターによりアクセス可能な任意の媒体とすることができ、揮発性媒体および不揮発性媒体、取り外し可能媒体および取り外し不可能媒体を含む。限定ではなく例として、コンピューター読取可能媒体は、コンピューター記憶媒体および通信媒体を備えることができる。コンピューター記憶媒体は、コンピューター読取可能命令、データ構造、プログラムモジュールまたは他のデータなど、情報の記憶のための任意の方法および技術において実装される、揮発性媒体および不揮発性媒体、取り外し可能媒体および取り外し不可能媒体を含む。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置デバイス、または、所望の情報の記憶に使用され、コンピューターによりアクセス可能な任意の他の媒体を含むが、これらには限定されない。

図２７を再度参照すると、様々な態様を実装するための例示の環境２７００はコンピューター２７０２を含み、コンピューター２７０２は、処理ユニット２７０４、システムメモリ２７０６およびシステムバス２７０８を含む。システムバス２７０８は、システムメモリ２７０６を含むがこれに限定されないシステムコンポーネントを、処理ユニット２７０４に接続する。処理ユニット２７０４は、任意の様々な市販のプロセッサーとすることができる。デュアルマイクロプロセッサーおよび他のマルチプロセッサーキテクチャも、処理ユニット２７０４として利用することができる。

システムバス２７０８は、メモリバス（メモリコントローラーを有しても、有さなくてもよい）、周辺バス、および任意の様々な市販のバスアーキテクチャを使用するローカルバスに相互接続することができる、いくつかのタイプのバス構造のいずれかとすることができる。システムメモリ２７０６は、読み出し専用メモリ（ＲＯＭ）２７１０およびランダムアクセスメモリ（ＲＡＭ）２７１２を含む。基本入出力システム（ＢＩＯＳ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ２７１０内に格納され、このＢＩＯＳは、スタートアップ中などにコンピューター２７０２内の要素間の情報の転送を助ける基本ルーチンを含む。ＲＡＭ２７１２は、データをキャッシュするためのスタティックＲＡＭなどの高速ＲＡＭも含む。

コンピューター２７０２は、外部使用のために適切な筺体（図示せず）内に構成することもできる内部ハードディスクドライブ（ＨＤＤ）２７１４（例えば、ＥＩＤＥ、ＳＡＴＡ）、磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）２７１６（例えば、取り外し可能なディスケット２７１８との間で読み書きするための）、および光ディスクドライブ２７２０（例えば、ＣＤ−ＲＯＭディスク２７２２を読み込む、または、ＤＶＤなどの他の大容量光媒体との間で読み書きするための）をさらに含む。ハードディスクドライブ２７１４、磁気ディスクドライブ２７１６、および光ディスクドライブ２７２０は、それぞれハードディスクドライブインターフェース２７２４、磁気ディスクドライブインターフェース２７２６、および光ドライブインターフェース２７２８によって、システムバス２７０８に接続されることができる。外部ドライブを実装するためのインターフェース２７２４は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）技術およびＩＥＥＥ１３９４インターフェース技術の少なくとも１つまたは両方を含む。他の外部ドライブ接続技術は、対象の本発明の意図の範囲内である。

ドライブおよびその関連するコンピューター読取可能媒体は、データの不揮発性記憶装置、データ構造、コンピューター実行可能命令などを提供する。コンピューター２７０２に対して、ドライブおよび媒体は、適切なデジタルフォーマットで任意のデータの記憶を提供する。上記のコンピューター読取可能媒体の記載は、ＨＤＤ、取り外し可能磁気ディスケット、ならびに、ＣＤまたはＤＶＤなどの取り外し可能な光媒体を指しているが、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジなど、コンピューターにより読取可能な他のタイプの媒体も、例示的なオペレーティング環境において使用することができ、さらに任意のそのような媒体は、開示される本発明の方法を実行するためのコンピューター実行可能命令を含むことを当業者は認識されたい。

多くのプログラムモジュールを、ドライブおよびＲＡＭ２７１２に格納することができ、ＲＡＭ２７１２には、オペレーティング・システム２７３０、１つまたは複数のアプリケーションプログラム２７３２、他のプログラムモジュール２７３４、およびプログラムデータ２７３６が含まれる。全てのまたは一部のオペレーティング・システム、アプリケーション、モジュール、および／またはデータも、ＲＡＭ２７１２にキャッシュすることができる。本発明を、様々な市販のオペレーティング・システムまたはオペレーティング・システムの組み合わせで実装することができることは、理解されよう。

ユーザーは、コマンドおよび情報をコンピューター２７０２に、１つまたは複数の有線／無線の入力装置、例えば、キーボード２７３８、およびマウス２７４０などのポインティングデバイスを介して入力することができる。他の入力装置（図示せず）には、マイク、赤外線リモートコントロール、ジョイスティック、ゲームパッド、スタイラス・ペン、タッチスクリーンなどが含まれる。これら入力装置のおよび他の入力装置を、システムバス２７０８に接続される入力装置インターフェース２７４２を介して、処理ユニット２７０４に接続することが多いが、他のインターフェース、例えばパラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、赤外線インターフェースなどに接続することもできる。

モニタ２７４４または他のタイプの表示装置も、ビデオアダプタ２７４６などのインターフェースを介して、システムバス２７０８に接続される。モニタ２７４４に加えて、コンピューターは、典型的にはスピーカ、プリンタなどの他の周辺出力装置（図示せず）を含む。

コンピューター２７０２は、有線通信および／または無線通信を介して、リモート・コンピューター２７４８などの１つまたは複数のリモート・コンピューターへの論理接続を使用してネットワーク化された環境で動作する。リモート・コンピューター２７４８は、ワークステーション、サーバーコンピューター、ルータ、パーソナル・コンピューター、ハンドヘルドコンピューター、マイクロプロセッサーベースの娯楽電化製品、ピアデバイスまたは他の共通ネットワークノードとすることができ、典型的には、コンピューター２７０２に関連して記載した多くのまたは全ての要素を含むが、簡潔にするためにメモリ／記憶装置２７５０のみを図示している。示された論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）２７５２および／またはより大きなネットワーク、例えば、広域ネットワーク（ＷＡＮ）２７５４への有線／無線の接続を含む。そのようなＬＡＮネットワーク環境およびＷＡＮネットワーク環境は、オフィスおよび企業内では一般的であり、イントラネットなどの企業規模のコンピューターネットワークを容易にし、その全てを、例えば、インターネットなどのグローバルな通信ネットワークに接続することができる。

ＬＡＮネットワーク環境で使用されるとき、コンピューター２７０２は、有線および／または無線通信ネットワークインターフェースまたはアダプタ２７５６を介して、ローカルネットワーク２７５２に接続される。アダプタ２７５６は、ＬＡＮ２７５２への有線通信または無線通信を簡素化することができ、ＬＡＮ２７５２は、無線アダプタ２７５６との通信のために配置された無線アクセス・ポイントも含む。

ＷＡＮネットワーク環境で使用されるとき、コンピューター２７０２は、モデム２７５８を含むことができるか、またはＷＡＮ２７５４上の通信サーバーに接続され、あるいは、インターネットを介するなどしてＷＡＮ２７５４上で通信を構築する他の手段を有する。モデム２７５８は、内蔵または外付けの、有線または無線の装置とすることができ、システムバス２７０８にシリアルポートインターフェース２７４２を介して接続される。ネットワーク化された環境では、コンピューター２７０２に関連して示されるプログラムモジュール、またはその一部分を、リモートメモリ／記憶装置２７５０に格納することができる。示されたネットワーク通信が例示的であり、コンピューター間の通信リンクを構築する他の手段も使用することができることは理解されよう。

コンピューター２７０２は、任意の無線装置、または無線通信において動作可能に配置されるエンティティ、例えば、プリンタ、スキャナ、デスクトップ・コンピューターおよび／またはポータブルコンピューター、ＰＤＡ、通信衛星、無線検出可能タグに関連する任意の設備または場所（例えば、キオスク、新聞販売店、トイレ）、および電話、と通信するよう動作可能である。これは、少なくともＷｉ−Ｆｉおよびブルートゥース（登録商標）の無線技術を含む。従って、通信は、従来のネットワークを用いた所定の構造とすることができ、または単純に少なくとも２つのマシン間のアドホック通信とすることができる。

ここで、図２８を参照すると、分散媒体会議を容易にする例示的なコンピューター環境２８００の概略ブロック図が図示されている。システム２８００は、１つまたは複数のクライアント２８０２を含む。クライアント２８０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング・デバイス）とすることができる。クライアント２８０２は、例えば、対象の本発明を利用することにより、クッキーおよび／または関連するコンテキスト情報を格納することができる。

システム２８００は、１つまたは複数のサーバー２８０４も含む。サーバー２８０４も、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング・デバイス）とすることができる。サーバー２８０４は、スレッドを格納して、例えば、アーキテクチャを利用することによって変換を実行することができる。クライアント２８０２とサーバー２８０４との間の１つの可能な通信は、２つまたはそれ以上のコンピュータープロセス間で伝送されるように適合されたデータパケットの形式とすることができる。データパケットは、例えば、クッキーおよび／または関連するコンテキスト情報を含む。システム２８００は、クライアント２８０２とサーバー２８０４との間の通信を容易にするのに使用することができる、通信フレームワーク２８０６（例えば、インターネットなどのグローバルな通信ネットワーク）を含む。

通信は、有線（光ファイバを含む）および／または無線技術を介して促進することができる。クライアント２８０２は、クライアント２８０２にローカルな情報（例えば、クッキーおよび／または関連するコンテキスト情報）を格納するのに使用することができる、１つまたは複数のクライアントデータストア２８０８に動作可能に接続される。同様に、サーバー２８０４は、サーバー２８０４にローカルな情報を格納するのに使用することができる、１つまたは複数のサーバーデータストア２８１０に動作可能に接続される。

上述したことには、開示された本発明の例を含む。当然、コンポーネントおよび／または方法の考えられる全ての組み合わせを記載することは不可能であるが、さらに多くの組み合わせおよび順列ができることを当業者は認識されよう。従って、本発明は、添付の請求項の範囲の精神および範囲内にある全てのそのような変更、修正、および変形を含むことが意図されている。さらに、用語「含む（ｉｎｃｌｕｄｅ）」は、詳細な説明または特許請求の範囲のいずれかにおいて使用される限りにおいては、用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」が特許請求の範囲において遷移語として利用されるときに解釈されるように、「備える」と同様に包括的なものであることが意図されている。

Claims (20)

1. コンピューターにより実現される会議システムにおいて、
   プログラムを記憶する記憶デバイスと、
   前記プログラムにアクセスして実行する処理ユニットと、
   を備え、前記処理ユニットが前記プログラムを実行すると、前記会議システムは、クライアントによって提示された会議セッションの設定要求に応答して会議コントロールコンポーネントを提供するように構成され、前記会議コントロールコンポーネントは、
   前記クライアントから前記会議セッションの設定要求を受信して、前記会議セッションを作成し、
   前記要求を受信して前記会議セッションを作成した後に、前記クライアントに前記会議セッションの媒体を提供する分散媒体コンポーネントを、前記会議セッションに割り当て、
   前記分散媒体コンポーネントを前記会議セッションに割り当てた後、前記分散媒体コンポーネントのユニフォームリソース識別子を前記クライアントに返し、
   複数のクライアントによる前記会議セッションへの参加を受け入れ、
   前記参加したクライアントに、前記会議セッションに関連付けられた状態の変更を通知することを特徴とするシステム。
2. 前記分散媒体コンポーネントは、データ、オーディオ信号、ビデオ信号、およびインスタント・メッセージ信号のうちの少なくとも１つを提供するマルチポイント・コントロール・ユニットであることを特徴とする請求項１に記載のシステム。
3. 前記会議コントロールコンポーネントは、前記会議セッションのオペレーションを定め、前記会議セッションへの参加者を許可するルールを維持する、ポリシーおよび名簿コンポーネントを提供することを特徴とする請求項１に記載のシステム。
4. 前記会議コントロールコンポーネントは、参加者の識別情報に基づいて前記会議セッションへのアクセスを制限することにより前記会議セッションに対してセキュリティを課す、認証コンポーネントを提供することを特徴とする請求項１に記載のシステム。
5. 前記会議コントロールコンポーネントは、前記分散媒体コンポーネントを前記会議セッションに割り当てる、割り当てコンポーネントを提供することを特徴とする請求項１に記載のシステム。
6. 前記会議コントロールコンポーネントは、前記会議セッションをスケジュールするスケジューリング・コンポーネントを提供することを特徴とする請求項１に記載のシステム。
7. 各サーバーが前記会議セッションのインスタンスを実行する、フロントエンド・サーバーの会議プールをさらに備え、前記フロントエンド・サーバーの会議プールは前記処理ユニットを含み、前記クライアントは、前記フロントエンド・サーバーの１つにアクセスして前記会議セッションにアクセスすることを特徴とする請求項１に記載のシステム。
8. 前記フロントエンド・サーバーの会議プールは、前記フロントエンド・サーバー間のセッション負荷のバランスを取るロードバランサを含むことを特徴とする請求項７に記載のシステム。
9. マルチパーティ会議を管理するために、会議コントロールコンポーネントを有するコンピューターによって実行される方法であって、
   会議セッションを作成する要求をセッション参加者から受信するステップと、
   前記要求に応答して前記会議コントロールコンポーネントによって、
   前記要求に応答して、前記会議セッションを作成して構成するステップと、
   前記要求を受信した後に、前記セッション参加者による媒体アクセスのための分散マルチポイント・コントロール・ユニット（ＭＣＵ）の可用性を判断するステップと、
   前記分散ＭＣＵの可用性を判断した後に、前記セッション参加者によるセッションアクセスのために、前記分散ＭＣＵのうち利用可能なＭＣＵを前記会議セッションに割り当てるステップと、
   前記利用可能なＭＣＵを前記会議セッションに割り当てた後に、前記利用可能なＭＣＵのユニフォームリソース識別子（ＵＲＩ）を前記セッション参加者に返すステップと、
   複数のクライアントによる前記会議セッションへの参加を受け入れるステップと、
   前記参加したクライアントに前記会議セッションに関連する状態の変更を通知するステップと、
   前記会議セッションへの参加者のアクセスを認証するステップと、
   を含むことを特徴とする方法。
10. 前記会議セッションの状態情報をデータベース内に動的に保持するステップをさらに含むことを特徴とする請求項９に記載の方法。
11. 前記分散ＭＣＵのうち前記会議セッションに割り当てられた各ＭＣＵについて個々の状態情報を受信するステップと、
    前記個々の状態情報を集約することによって、集約された状態情報を生成するステップと、
    前記集約された状態情報を前記会議セッションの前記参加したクライアントの各々に分散するステップと
    をさらに含み、前記通知するステップは、前記個々の状態情報のいずれかにおける変更を前記会議セッションに関連する状態の変更として通知することを含むことを特徴とする請求項１０に記載の方法。
12. セッション参加者の変更に基づいてセッション名簿を更新するステップをさらに含むことを特徴とする請求項９に記載の方法。
13. ＵＲＩアドレスを前記分散ＭＣＵのそれぞれに関連付けるステップであって、前記セッション参加者が、前記分散ＭＣＵの１つを介して前記会議セッションにアクセスするステップをさらに含むことを特徴とする請求項９に記載の方法。
14. 前記要求は、セッション開始プロトコル（ＳＩＰ）要求であることを特徴とする請求項９に記載の方法。
15. 前記会議セッション内に前記利用可能なＭＣＵをブートストラップするステップをさらに含むことを特徴とする請求項９に記載の方法。
16. 前記利用可能なＭＣＵを識別するＭＣＵ ＵＲＩへのダイアルイン、前記ＭＣＵ ＵＲＩを使用するダイアルアウト、または前記利用可能なＭＣＵから前記ＭＣＵ ＵＲＩへの直接招待を使用して、前記利用可能なＭＣＵに加わるステップをさらに含むことを特徴とする請求項９に記載の方法。
17. 別の参加者へのアドホック招待を開始するステップをさらに含むことを特徴とする請求項９に記載の方法。
18. 会議コントロールコンポーネントを介して前記会議セッションの単一の会議ビューを表示するステップをさらに含むことを特徴とする請求項９に記載の方法。
19. クライアントによって提示された会議セッションの設定要求に応答して、会議コントロールコンポーネントを提供する会議システムであって、
    クライアントからの会議セッションを開始する前記要求を受信することを実施させる手段と、
    前記要求を受信したことに応答して、前記会議セッションの会議インスタンスを作成することを実施させる手段と、
    前記会議セッションのアドレスを作成してクライアントに送信することを実施させる手段と、
    前記要求を受信した後に、分散ＭＣＵによって提供される媒体タイプの可用性に基づいて分散ＭＣＵを前記会議セッションに割り当てることを実施させる手段と、
    前記会議セッションの間の会議状態を管理することを実施させる手段と、
    複数のクライアントによる前記会議セッションへの参加を受け入れるステップと、
    前記参加したクライアントに前記会議セッションの状態における変更を通知することを実施させる手段と
    を備えることを特徴とするシステム。
20. コンピューターによって実行されると、クライアントによって提示された会議セッションの設定要求に応答して、前記コンピューターに会議コントロールコンポーネントを提供させるプログラムであって、前記会議コントロールコンポーネントは、
    前記クライアントから前記会議セッションを開始するための前記要求を受信することと、
    前記要求を受信したことに応答して、前記会議セッションの会議インスタンスを作成することと、
    前記要求への応答として、前記会議セッションのアドレスを作成して前記クライアントに送信することと、
    前記要求を受信した後に、分散ＭＣＵによって提供される媒体タイプの可用性に基づいて、分散ＭＣＵを前記会議セッションに割り当てることと、
    前記分散ＭＣＵを前記会議セッションに割り当てた後に、前記分散ＭＣＵのユニフォームリソース識別子（ＵＲＩ）を前記クライアントに返すことと、
    前記会議セッションの間の会議状態を管理することと、
    複数のクライアントによる前記会議セッションへの参加を受け入れるステップと、
    前記参加したクライアントに前記会議セッションの状態における変更を通知することと
    を実行するように構成されることを特徴とするプログラム。

Images