JP2005513870A - テレビ会議コール設定 - Google Patents

Abstract

クライアント間にマルチキャストセッションを設置する方法が提供される。該方法は、クライアントがテレビ会議セッションに参加できるように共通マルチキャストＩＰアドレスを割り当てるステップと、少なくとも一つのクライアントに共通マルチキャストＩＰアドレスを送信するステップを含む。

Description

関連出願への相互参照

これは、ここに参照援用される２００１年１２月１５日に出願された、タイトル「ＶＩＤＥＯ ＣＯＮＦＥＲＥＮＣＩＮＧ ＣＡＬＬ ＳＥＴ ＵＰ ＭＥＴＨＯＤ」の仮出願Ｎｏ．６０／３４１，７９７、代理人Ｄｏｃｋｅｔ Ｎｏ．ＰＵ０１０３０７の米国特許法１１９条の利益を主張する非仮出願である。本出願は、参照援用される２００２年３月２０日に出願された、タイトル「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ ＳＹＳＴＥＭ ＡＲＣＨＩＴＥＣＴＵＲＥ」の共通に割り当てられた仮出願Ｎｏ．６０／３６６，３３１にも関連する。本出願は、ここに参照援用される以下の共通に割り当てられた仮出願にも関連する：
２００１年１２月１５日に出願された、タイトル「ＶＩＤＥＯ ＣＯＮＦＥＲＥＮＣＩＮＧ ＢＡＮＤＷＩＴＨ ＳＥＬＥＣＴＩＯＮ ＭＥＣＨＡＮＩＳＭ」、出願番号Ｎｏ．６０／３４１，７２０、２００１年１２月１５日に出願された、タイトル「ＱＵＡＬＩＴＹ ＯＦ ＳＥＲＶＩＣＥ ＳＥＴＵＰ ＯＮ Ａ ＴＩＭＥ ＲＥＳＥＲＶＡＴＩＯＮ ＢＡＳＩＳ」、出願番号Ｎｏ．６０／３４１，６７１、２００１年１２月１５日に出願された、タイトル「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ ＳＥＳＳＩＯＮ ＳＷＩＴＣＨＩＮＧ ＦＲＯＭ ＵＮＩＣＡＳＴ ＴＯ ＭＵＬＴＩＣＡＳＴ」、出願番号Ｎｏ．６０／３４１，８００、２００１年１２月１５日に出願された、タイトル「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＶＩＤＩＮＧ Ａ ＰＲＩＶＡＴＥ ＣＯＮＶＥＲＳＡＴＩＯＮ ＣＨＡＮＮＥＬ ＩＮ Ａ ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＩＮＧ ＳＹＳＴＥＭ」、出願番号Ｎｏ．６０／３４１，７９９、２００１年１２月１５日に出願された、タイトル「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ ＡＰＰＬＩＣＡＴＩＯＮ ＵＳＥＲ ＩＮＴＥＲＦＡＣＥ」、出願番号Ｎｏ．６０／３４１，８０１、および２００１年１２月１５日に出願された、タイトル「ＳＥＲＶＥＲ ＩＮＶＯＫＥＤ ＴＩＭＥ ＳＣＨＥＤＵＬＥＤ ＶＩＤＥＯ ＣＯＮＦＥＲＥＮＣＥ」、出願番号Ｎｏ．６０／３４１，８１９。

本発明はテレビ会議に関し、特に、テレビ会議コールを設定する方法と装置に関する。

従来のテレビ会議システムは、各テレビ会議参加者からメディアストリームを受信し、ストリームを結合し、テレビ会議セッションのデスティネーションクライアントに送るマルチ会議ユニット（ＭＣＵ）を使用する。ＭＣＵは高価であり、その使用は従来のテレビ会議システムにおいてスケーラビリティの制限に帰結する。

したがって、ＭＣＵを必要とせず、それに対応するスケーラビリティ問題を生じさせないテレビ会議を設定する方法と装置を有することは望ましく、非常に有利である。

上記問題は、従来技術の関連する他の問題と同様に、テレビ会議を設定する方法と装置である本発明により解決される。

本発明はテレビ会議コールをサーバを用いて設定する。テレビ会議コールが開始クライアント（テレビ会議を最初に要求するクライアント）と複数のデスティネーションクライアント（開始クライアントがテレビ会議に参加して欲しいと望むクライアント）の間である場合、本発明は開始クライアントと複数のデスティネーションクライアントとの間でＩＰマルチキャストセッションを開始する。テレビ会議コールが開始クライアントと単一のデスティネーションクライアントとの間の場合、ＩＰユニキャストセッションが開始される。

本発明の一態様によると、クライアント間にマルチキャストセッションを設定する方法が提供される。この方法は、クライアントがテレビ会議セッションに参加できるように共通のマルチキャストＩＰアドレスを割り当てるステップと、少なくとも一つのクライアントに共通マルチキャストＩＰアドレスを送信するステップとを含む。

本発明の他の態様によると、クライアント間にマルチキャストセッションを設定するシステムが提供される。このシステムは、クライアントがセッションに参加できるように共通のマルチキャストＩＰアドレスを割り当てる手段と、割り当てる手段とデータ通信をして、少なくとも一つのクライアントに共通のＩＰアドレスを送信する手段を含む。

本発明のさらに別の態様によると、クライアント間にマルチキャストセッションを設定する方法が提供される。この方法は、テレビ会議セッションのための共通マルチキャストＩＰアドレスを受信する能力を提供するステップと、共通マルチキャストＩＰアドレスを用いてテレビ会議コンテントを受信する能力を供給するステップを含む。

本発明のこれらとその他の態様、特徴、利点は、添付した図面を参照して好ましい実施形態の詳細な説明を読めば明らかとなるであろう。

発明の詳細な説明

本発明はテレビ電話コールを設定する装置および方法である。本発明により、開始クライアント（開始クライアントはテレビ会議を最初に要求するクライアントである）から単一のデスティネーションクライアントまたは複数のデスティネーションクライアント（デスティネーションクライアントは開始クライアントがテレビ会議への参加を望むクライアントである）へのテレビ会議セッションを柔軟に設定することができる。コール設定は中心となるテレビ会議サーバにより制御され、ピアツーピアでなされるものではない。

テレビ会議セッション中に複数のデスティネーションクライアントにビデオを送らねばならないとき、デスティネーションクライアントにビデオコンテントを送るために、中心となるテレビ会議サーバが開始クライアントにマルチキャストグループＩＰアドレスを割り当てる。デスティネーションクライアントは、中心となるテレビ会議サーバにより送られた要求により、マルチキャストグループに加入するように要求される。

ここで、「クライアント」、「クライアントコンピュータ」、「テレビ会議クライアントアプリケーション」という用語は相互に置き換えてもよいことを理解すべきである。

本発明は、ハードウェア、ソフトウェア、ファームウェア、特定目的プロセッサ、またはこれらの組み合わせの様々な形式で実施してもよいことを理解すべきである。好ましくは、本発明はハードウェアとソフトウェアの組み合わせで実施される。また、ソフトウェアはプログラム記憶装置上に有形的に具現化されたアプリケーションプログラムとして好ましくは実施される。アプリケーションプログラムは好適なアーキテクチャを有するマシンによりアップロードされ、実行されてもよい。好ましくは、このマシンは、一以上の中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、入出力（Ｉ／Ｏ）インターフェイスなどのハードウェアを有するコンピュータプラットフォーム上で実施される。コンピュータプラットフォームはオペレーティングシステムとマイクロインストラクションコードも含む。ここに説明する様々なプロセスと機能は、オペレーティングシステムを通して実行されるマイクロインストラクションコードやアプリケーションプログラム（またはこれらの組み合わせ）の一部であってもよい。また、付加的なデータ記憶装置や印刷装置等の他の様々な周辺装置がコンピュータプラットフォームに接続されてもよい。

添付した図に示されたシステム構成要素および方法ステップは好ましくはソフトウェアにおいて実施されるので、システム構成要素（またはプロセスステップ）間の実際の接続は、本発明のプログラムの仕方により異なってもよいことは理解すべきである。この教示を与えられれば、関連技術分野の通常の知識を有する者は、本発明のここに説明するまたはこれに類似する実施形態および構成を企図することができるであろう。

図１Ａは本発明の一実施形態による、本発明が適用可能なコンピュータシステム１００を示すブロック図である。コンピュータ処理システム１００は、システムバス１０４を経由して他の構成要素と動作可能に結合された少なくとも一つのプロセッサ（ＣＰＵ）１０２を含む。リードオンリーメモリ（ＲＯＭ）１０６、ランダムアクセスメモリ（ＲＡＭ）１０８、表示アダプタ１１０、入出力アダプタ１１２、ユーザインターフェイスアダプタ１１４、サウンドアダプタ１９９、ネットワークアダプタ１９８はシステムバス１０４に動作可能に結合されている。表示装置１１６は、表示アダプタ１１０によりシステムバス１０４に動作可能に結合されている。ディスク記憶装置（例えば、磁気または光ディスク記憶装置）１１８は入出力アダプタ１１２によりシステムバス１０４に動作可能に結合されている。

マウス１２０とキーボード１２２は、ユーザインターフェイスアダプタ１１４によりシステムバス１０４に動作可能に結合されている。マウス１２０とキーボード１２２は、システム１００との情報の入出力に使用される。

少なくとも一つのスピーカ（これ以後「スピーカ」）１９７がサウンドアダプタ１９９によりシステムバス１０４に動作可能に結合されている。

（デジタルおよび／またはアナログの）モデム１９６が、ネットワークアダプタ１９８によりシステムバスに動作可能に結合されている。

本発明の一実施形態による、ポリシーベースネットワークマネージメント（ＰＢＮＭ）について説明する。ＰＢＮＭは、ネットワーク（本発明を適用することができるネットワークの一例が図２を参照して以下に説明されている）を管理するポリシーを定義し分配する能力を提供する技術である。このポリシーにより、バンド幅やセキュリティなどのクリティカルなネットワーク資源を統合的に制御することができる。ＰＢＮＭにより、ネットワーク上で差別化された取り扱いを要する、ＩＰベースのテレビ会議などのアプリケーションが可能となる。ＰＢＭＮにより、異なるタイプのアプリケーションが単一のネットワーク上で共存し、各アプリケーションに必要な資源を提供することができる。

さらに詳細に、ＰＢＮＭはネットワーク資源を消費するアプリケーションやユーザのためのポリシーを定義する。例えば、ビジネスのクリティカルなアプリケーションには最も高い優先順位と、ネットワーク上のバンド幅のパーセンテージが与えられ、テレビ会議とボイスオーバーＩＰには２番目に高い優先順位が与えられ、バンド幅や時間の厳しいクリティカルな制限がないウェブトラッフィックとファイルトランスファーにはネットワークの残りの資源が与えられることができる。このようなユーザとアプリケーションの差別化はＰＢＮＭを用いることにより達成することができる。

テレビ会議システムは、テレビ会議アプリケーションに対応するポリシーをネットワークポリシーサーバに問い合わせることによりＰＢＮＭシステムに接続する。テレビ会議サーバはネットワークポリシーサーバからポリシーを取得し、受信したパラメータに基づきテレビ会議に利用可能なネットワーク資源を決定する。ポリシーは典型的には、例えば、その日のある時間内のこのアプリケーションまたはあるユーザに利用可能なバンド幅に対応する。例えばポリシーおよび／またはその一部を加え、削除し、代替し、変更することにより、構成を容易に変更することができる。その結果、テレビ会議サーバは、ネットワーク上のテレビ会議セッションを管理するため、ポリシーに供給されている情報を使用する。

図２は本発明の一実施形態による、本発明が適用されるネットワーク２００を示すブロック図である。ネットワーク２００は、テレビ会議サーバ２０５、ポリシーおよびＱｏＳマネージャ２１０、ＭＡＤＣＡＰサーバ２１５、第１の複数のコンピュータ２２０ａ−ｆ、第１のローカルエリアネットワーク２２５、第１のルータ２４０、第２の複数のコンピュータ２３０ａ−ｅ、第２のローカルエリアネットワーク２３５、第２のルータ２４５、ワイドエリアネットワーク２５０を含む。

本発明の一実施形態によるサーバのアーキテクチャを説明する。図３は、本発明の一実施形態による、図２のテレビ会議サーバ２０５を示すブロック図である。テレビ会議サーバ２０５は、データベースエンティティ３０２、ネットワーク通信エンティティ３０４、およびセッション管理エンティティ３０６である三つの基本的エンティティを含むと考えることができる。

セッション管理エンティティ３０６はテレビ会議セッション設定および終了を管理する役割を有する。セッションマネージメントエンティティ３０６は、テレビ会議サーバ２０５の主な制御のほとんども提供する。セッションマネージメントエンティティ３０６は、セッションマネージメントエンティティ３０６の機能を実施するためのセッションマネージャ３２０を含む。

ネットワークコミュニケーションエンティティ３０４は、テレビ会議システムに使用される異なる多くのプロトコルを一つにまとめる役割を有する。プロトコルには、遠隔アドミニストレーションと管理のためのＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）、ポリシーマネージメントのためのＣｏｍｍｏｎ Ｏｐｅｎ Ｐｏｌｉｔｙ Ｓｅｒｖｉｃｅｓ（ＣＯＰＳ）またはＬｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）等のその他のプロトコル、マルチキャストアドレス割当てのためのＭｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ Ｄｙｎａｍｉｃ Ｃｌｉｅｎｔ Ａｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＭＡＤＣＡＰ）、テレビ会議セッション管理のためのＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）、分散したテレビ会議サーバ管理のためのＳｅｒｖｅｒ ｔｏ Ｓｅｒｖｅｒ ｍｅｓｓａｇｉｎｇを含む。従って、ネットワーク通信エンティティ３０４は、ＳＮＭＰモジュール３０４ａ、ＬＤＡＰクライアントモジュール３０４ｂ、ＭＡＤＣＡＰクライアントモジュール３０４ｃ、ＳＩＰモジュール３０４ｄ、サーバツーサーバ管理モジュール３０４ｅを含む。また、前記の要素３０４ａ−ｅは、リモートアドミニストレーションターミナル３８２、ネットワークポリ氏サーバ（バンド幅ブローカ）３８４、ＭＡＤＣＡＰサーバ２１５、デスクトップ会議クライアント３８８、および他のテレビ会議サーバ３９０とそれぞれ通信する。その通信は、プロトコルモジュール３３０により集合的に表されるＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）を使用して実施することもできる。前記のプロトコルのリストとそれに対応する要素は単なる例示であり、本発明の精神と範囲内において、他のプロトコルやそれに対応する要素を容易に使用することができることは理解されるべきである。

テレビ会議サーバ２０５のアーキテクチャは、テレビ会議セッションからコンテントを送受信するためにＶｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ（ＶＰＮ）を経由して会社のインフラストラクチャに接続する携帯デバイスのユーザにも好適である。

データベースエンティティ３０２は、スケジューリングデータベース３１０、アクティブセッションデータベース３１２、メンバーデータベース３１４、ネットワークアーキテクチャデータベース３１６である四つのデータベースを含む。

テレビ会議システムサーバ２０５は、カンパニーＬＤＡＰサーバ（ユーザ情報）３４０とオプションの外部データベース３４２をさらに含むか、または少なくともインターフェイスする。

本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれるメンバーデータベース３１４について説明する。メンバーデータベース３１４は、テレビ会議システムにログインした各ユーザの情報を含む。例として、メンバーデータベース３１４には各ユーザについて次の情報が保管される：ユーザ名、パスワード（該当する場合）、サポートされるビデオコーデックおよびキャプチャソリューション、サポートされるオーディオコーデック、カレントＩＰアドレス、カレントコールナンバー（現在、アクティブコールのメンバーであるとき）、アベイラビリティ（アベイラブルであるかないか）、ビデオカメラのタイプおよびモデル、ネットワーク上の位置（各位置はバンド幅が制限されたワイドエリアネットワークリンクにより接続される）、ＣＰＵタイプおよび処理パワー。前記の項目は単なる例であり、前記項目の一部または全部に加えてまたは替わりに、他の項目を各ユーザについてメンバーデータベース３１４に保管することもできることは理解すべきである。

図４は、本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれたメンバーデータベース３１４のためのメンバーデータベースエンティティ４００を示す図である。図４の実施形態において、メンバーデータベース３１４はシンプルリンクリストを用いて実施されている。しかし、本発明の他の実施形態においては、本発明の精神と範囲を保ったまま、メンバーデータベース３１４の異なる実施をしてもよいことは理解すべきである。一つの例として、ＬＤＡＰタイプのデータベースをメンバー情報を記憶するために使用してもよい。

本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれるアクティブセッションデータベース３１２について説明する。アクティブセッションデータベース３１２は現在発生している各テレビ会議セッションの情報を含む。例として、アクティブセッションデータベース３１２には各コールについて次の情報が保管される：コールＩＤ；ディスクリプション；マルチキャスト（イエス／ノー）；マルチキャストの場合、マルチキャストＩＰアドレス；各参加者についてのネットワークロケーション、カレント送信解像度、カレント送信ビットレート、ビデオおよびオーディオコーデック；パブリック／プライベートコール（他人は参加できるか？）；セッションのスケジュールタイム；セッションの開始時間；その他のオプション。前記のアイテムは単なる例示であり、本発明の精神と範囲を維持したまま、前記のアイテムの一部または全部に加えてまたは替わりに、他のアイテムがアクティブセッションデータベース３１２に保管されてもよい。

図５は、本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれるアクティブセッションデータベース３１２のアクティブセッションエントリー５００を示すブロック図である。図５の実施形態において、アクティブセッションデータベース３１２はシンプルリンクリストを用いて実施されている。しかし、本発明の他の実施形態においては、本発明の精神と範囲を維持したままアクティブセッションデータベース３１２の他の実施も採用することができることは理解すべきである。

再び図３を参照して、本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれるネットワークアーキテクチャデータベース３１６について説明する。ネットワークアークテクチャデータベース３１６は、ネットワーク全体の全マッピングを含む。ネットワークアーキテクチャデータベース３１６は、各アクティブネットワークエレメント（すなわち、ＩＰルータ、イーサネット（登録商標）スイッチ）に関する情報と、ルータとスイッチをつなぐリンクに関する情報とを含む。ネットワーク内のバンド幅とサービス品質を効果的に管理するため、テレビ会議サーバ２０５はこの情報を知る必要がある。

同時に発生させることのできるテレビ会議セッションの数に関するポリシー情報、テレビ会議セッションのビットレート、およびバンド幅制限は、ネットワークアーキテクチャデータベース３１６において定義される。ネットワークアーキテクチャは、ネットワークアーキテクチャデータベース３１６内の重みつきグラフとして表現される。ネットワークアーキテクチャデータベース３１６はテレビ会議サーバ２０５のオプションのデータベースであることは理解すべきである。ネットワークアーキテクチャデータベース３１６は、ポリシーサーバ２１０から要求されたポリシーをキャッシュするのに使ってもよい。

本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれるスケジューリングデータベース３１０について説明する。スケジューリングデータベース３１０は、テレビ会議システムを使用する時間をユーザが予約するスケジュールを含む。これは、例えば情報システム部がしかるべき所に有する、ワイドエリアネットワーク２５０のあるリンク上で同時に発生してもよいテレビ会議セッションの数に関するポリシーに依存する。

図３のネットワーク通信エンティティ３０４について説明する。ネットワーク通信エンティティ３０４は、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）モジュール３０４ａ、Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）クライアントモジュール３０４ｂ、Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ Ｄｙｎａｍｉｃ Ｃｌｉｅｎｔ Ａｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＭＡＤＣＡＰ）クライアントモジュール３０４ｃ、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）モジュール３０４ｄ、およびサーバツーサーバマネージメントモジュール３０４ｅを含む。

本発明の一実施形態による、図３のネットワーク通信エンティティ３０４に含まれるＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）モジュール３０４ａについて説明する。図６は、本発明の一実施形態による、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）クライアントサーバアーキテクチャ６００を示すブロック図である。アーキテクチャ６００は、ＳＮＭＰモジュールの一実施形態を表すが、しかし本発明は図６に示したアーキテクチャに限定されず、本発明の精神と範囲を維持したまま他のＳＮＭＰアーキテクチャを採用してもよいことは理解すべきである。ＳＮＭＰはテレビ会議サーバを遠隔管理し監視するのに使用される。

Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）クライアントサーバアーキテクチャ６００はＳＮＭＰ管理ステーション６１０とＳＮＭＰ被管理エンティティ６２０を含む。ＳＮＭＰ管理ステーション６１０は管理アプリケーション６１０ａとＳＮＭＰマネージャ６１０ｂを含む。ＳＮＭＰ被管理エンティティ６２０は被管理リソース６２０ａ、ＳＮＭＰ被管理オブジェクト６２０ｂ、ＳＮＭＰエージェント６２０ｃを含む。さらに、ＳＮＭＰ管理ステーション６１０とＳＮＭＰ被管理エンティティ６２０の各々は、ＵＤＰレイヤー６３０、ＩＰレイヤー６４０、メディアアクセスコントロール（ＭＡＣ）レイヤー６５０および物理レイヤー６６０をさらに含む。

ＳＮＭＰエージェント６２０ｃにより、ＳＮＭＰ管理ステーション６１０からの監視と管理ができる。ＳＮＭＰエージェント６２０ｃはＳＮＭＰアーキテクチャ６００のクライアントである。ＳＮＭＰエージェント６２０ｃは、基本的に、ＳＮＭＰ管理ステーション６１０からの情報および動作を求める要求に応答する役割を果たす。ＳＮＭＰ管理ステーション６１０は、ＳＮＭＰアーキテクチャ６００のサーバである。ＳＮＭＰ管理ステーション６１０は、ネットワーク内のエージェントを管理する中心となるエンティティである。ＳＮＭＰ管理ステーション６１０の機能により、管理者はＳＮＭＰエージェント６２０ｃから統計を集め、ＳＮＭＰエージェント６２０ｃの構成パラメータを変更することができる。

ＳＮＭＰモデルを用いて、テレビ会議サーバ２０５のリソースをオブジェクトとして表現することにより管理することができる。各オブジェクトは被管理エージェントの一態様を表すデータ変数である。オブジェクトのこの集合は、通例、Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ（ＭＩＢ）と呼ばれる。ＭＩＢは、ＳＮＭＰ管理ステーション６１０のＳＮＭＰエージェント６２０ｃにあるアクセスポイントの集合として機能する。ＳＮＭＰ管理ステーション６１０は、ＳＮＭＰエージェント６２０ｃのＭＩＢオブジェクトの値を読むことにより監視することができる。ＳＮＭＰ管理ステーション６１０は、ＳＮＭＰエージェント６２０ｃに動作させることもでき、ＳＮＭＰエージェント６２０ｃの構成設定を変更することもできる。

ＳＮＭＰはＩＰレイヤー６４０上で動作し、トランスポートプロトコルとしてＵＤＰレイヤー６３０を使用する。

ＳＮＭＰ管理プロトコルで使用される基本的なメッセージは、ＧＥＴ、ＳＥＴ、及びＴＲＡＰである。ＳＮＭＰ管理ステーション６１０は、ＧＥＴメッセージを使用してＳＮＭＰエージェント６２０ｃのオブジェクトの値を読むことができる。ＳＮＭＰ管理ステーション６１０は、ＳＥＴメッセージを使用してＳＮＭＰエージェント６２０ｃのオブジェクトの値をセットすることができる。ＳＮＭＰエージェント６２０ｃは、ＴＲＡＰメッセージを使用してＳＮＭＰ管理ステーション６１０に重要なイベントを知らせることができる。

本発明の一実施形態による、ＳＮＭＰ被管理エンティティ６２０に含まれるＳＮＭＰ被管理リソース６２０ａについて説明する。遠隔管理により、テレビ会議サーバ２０５内の、アクティブセッションと関連する統計、セッションログ、テレビ会議のネットワークポリシー、セッション開始プロトコル（ＳＩＰ）パラメータと統計、ＭＡＤＣＡＰパラメータと統計を監視及び制御することができる。

ＳＮＭＰ管理ステーション６１０は、管理アプリケーションの代わりに３タイプのＳＮＭＰメッセージ、ＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ、およびＳｅｔＲｅｑｕｅｓｔを発行する。最初の二つはＧＥＴ関数のバリエーションである。ＳＮＭＰエージェント６２０ｃはＧｅｔＲｅｓｐｏｎｓｅメッセージの形で全てのメッセージに答える。ＧｅｔＲｅｓｐｏｎｓｅメッセージは管理アプリケーション６１０ａまで送られる。ＳＮＭＰエージェント６２０ｃは、被管理リソースで発生したイベントに応じてＴＲＡＰメッセージを発行してもよい。

図３を再び参照して、本発明の一実施形態による、図３のネットワーク通信エンティティ３０４に含まれるＬｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）クライアントモジュール３０４ｂについて説明する。ＬＤＡＰモジュール３０４ｂは、共通のディレクトリー情報にアクセスするための標準のＩＰベースプロトコルであるＬＤＡＰを使用する。ＬＤＡＰは、ユーザの特定の基準を満たすエントリーの検索、エントリーの追加、エントリーの削除、エントリーの変更、エントリーの比較等のディレクトリーエントリーにアクセスし変更する動作を決めている。

本発明の一実施形態による、図３のネットワーク通信エンティティに含まれるＭｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ Ｄｙｎａｍｉｃ Ｃｌｉｅｎｔ Ａｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＭＡＤＣＡＰ）クライアントモジュール３０４ｃについて説明する。ＭＡＤＣＡＰモジュール３０４Ｃにより、ホストはマルチキャストアドレスアロケーションサーバにマルチキャストアドレスアロケーションサービスを要求することができる。テレビ会議セッションがマルチキャスティングサービスを用いるように設定されているとき、テレビ会議サーバ２０５はセッションのクライアントに割り当てるマルチキャストアドレスを取得する必要がある。テレビ会議サーバ２０５は、ＭＡＤＣＡＰを用いてマルチキャストアドレスアロケーションサーバからマルチキャストアドレスを取得することができる。

本発明の一実施形態による、図３のネットワーク通信エンティティ３０４に含まれるＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）モジュール３０４ｄについて説明する。ＳＩＰモジュール３０４ｄは、ＩＰベースのネットワーク上で一以上の参加者とのマルチメディアセッションを生成、変更、終了するためのアプリケーションレイヤー制御プロトコルであるＳＩＰを使用する。ＳＩＰはテキストメッセージベースのプロトコルである。

ＳＩＰベースのテレビ会議システムにおいては、各クライアントとサーバはＳＩＰ ＵＲＬで特定される。ＳＩＰ ＵＲＬは、電子メールアドレスと同じフォーマットである、ｕｓｅｒ＠ｈｏｓｔの形をとり、ほとんどの場合、ＳＩＰ ＵＲＬはユーザの電子メールアドレスである。

本発明の一実施形態による、図３のネットワーク通信エンティティ３０４に含まれるサーバツーサーバ管理モジュール３０４ｅについて説明する。サーバツーサーバ管理モジュール３０４ｅは、テレビ会議サーバ間で情報を交換するためのメッセージを使用する。サーバツーサーバ管理モジュール３０４ｅは、好ましくは、唯一のテレビ会議サーバ（例えば、テレビ会議サーバ２０５）がサポートしているネットワーク（例えば、ＬＡＮ２２５）に局所的に設定されている典型的な配置において使用され、それゆえ、いくつかのテレビ会議サーバが会社規模のネットワーク（例えば、ネットワーク２００）内に存在するかも知れない。情報交換のためのメッセージのいくつかの基本的な目的は、データベースを同期し、ネットワークリソースの利用可能性をチェックすることを含む。

次のメッセージが定義されている：ＱＵＥＲＹ−遠隔サーバにエントリーを問い合わせる；ＡＤＤ−遠隔サーバにエントリーを追加する；ＤＥＬＥＴＥ−遠隔サーバからエントリーを削除する；ＵＰＤＡＴＥ−遠隔サーバ上のエントリーを更新する。

サーバツーサーバメッセージングは各サーバ間のＴＣＰベースの接続を使用することができる。一つのサーバの状態が変化したとき、残りのサーバは同じ情報で更新される。

本発明の一実施形態による、テレビ会議サーバ２０５の動作シナリオについて説明する。最初に、テレビ会議セッションの設定に対応する動作シナリオについて説明し、続いて、テレビ会議セッション中の解像度とフレームレートの調整に対応する動作シナリオを説明する。セッション動作シナリオはＳＩＰサーバディスカバリー、メンバー登録、セッション設定、セッションキャンセル、セッション終了を含む。

本発明の一実施形態による、ＳＩＰサーバディスカバリに対応するセッション動作シナリオについて説明する。ユーザ（テレビ会議アプリケーション）は、事前構成されたテレビ会議サーバ（手動準備された）で、またはスタートアップ時に、よく知られた「全ＳＩＰサーバ」マルチキャストアドレス「ｓｉｐ．ｍｃａｓｔ．ｎｅｔ」（２２４．０．１．７５）にＲＥＧＩＳＴＥＲ要求を送ることによって、登録することができる。各ユーザがテレビ会議クライアントアプリケーションのローカルＳＩＰサーバのアドレスを手動構成しなくてよいので、第２のメカニズム（ＲＥＧＩＳＴＥＲ要求）の方が好ましい。この場合、ユーザがテレビ会議のための正しいＳＩＰサーバに登録することを確からしめるため、マルチキャストアドレスはネットワーク内で正しくスコープする必要がある。前記の方法に加え、準備プロセスを簡単にするための他の方法において、ＳＩＰ仕様によると、ｓｉｐ．ｄｏｍａｉｎｎａｍｅ協定を用いて管理者がＳＩＰサーバに名前をつけることが推奨されている（例えば、ｓｉｐ．ｐｒｉｎｃｅｔｏｎ．ｔｃｅ．ｃｏｍ）。

本発明の一実施形態による、メンバー登録に対応するセッション動作シナリオについて説明する。図７は、本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いてテレビ会議セッションに登録する方法を示す図である。図７の例は、テレビ会議クライアントアプリケーション（クライアント）７０２とテレビ会議サーバ（サーバ）２０５を含む。ここでは「クライアントアプリケーション」と「クライアント」という用語は交換可能に使用されていることは理解すべきである。

メンバー登録関数において、クライアント７０２はサーバ２０５にＳＩＰ ＲＥＧＩＳＴＥＲ要求を送る（ステップ７１０）。サーバ２０５はこのメッセージを受信し、メンバーデータベース３１４にクライアント７０２のＩＰアドレスとＳＩＰ ＵＲＬを記憶する。

基準では仕様が定義されていないが、ＲＥＧＩＳＴＥＲ要求はメッセージ本体を含んでもよい。メッセージ本体は、サーバ２０５に登録するクライアント７０２の構成オプションに関する追加情報を含むことができる。

サーバ２０５は、クライアント７０２に２００ＯＫメッセージを送ることにより登録されたことを知らせる（ステップ７２０）。

本発明の一実施形態による、ユニキャストおよびマルチキャストテレビ会議セッションについて説明する。図１Ｂと１Ｃは、本発明の二つの実施形態による、ユニキャストテレビ会議セッションとマルチキャストテレビ会議セッションをそれぞれ示すブロック図である。図１Ｂと１Ｃの例は、クライアント１（１３０）、クライアント２（１３２）、クライアント３（１３４）、イーサネット（登録商標）スイッチ１３６、ＩＰルータ１３８、ＩＰルータ１４０、およびＷＡＮ１４２を含む。

ユニキャストの例において、ユニークなストリームが各クライアントからその他クライアントに送られる。このようなアプローチにより、より多くの参加者がネットワークに参加するにつれ、大量のバンド幅が消費される。対照的に、マルチキャストアプローチにおいては、各クライアントから一つだけのストリームが送られる。それゆえ、マルチキャストアプローチは、ユニキャストアプローチと比較して、より少ないバンド幅等のネットワークリソースしか消費しない。

本発明の一実施形態によるユニキャストテレビ会議セッション設定に対応するセッション動作シナリオについて説明する。図８Ａは、本発明の一実施形態によるＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたユニキャストテレビ会議セッションを設定する方法を示す図である。図８Ａの例は、テレビ会議クライアントアプリケーション＃１（クライアント＃１）８０２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアントアプリケーション＃２（クライアント＃２）８０６を含む。

ＩＮＶＩＴＥ要求がクライアント＃１（８０２）からサーバ２０５に送られる（ステップ８１０）。このＩＮＶＩＴＥ要求はサーバ２０５からクライアント＃２（８０６）に転送される（ステップ８１５）。

１８０リンギングメッセージがクライアント＃２（７０６）からサーバ２０５に送られる（ステップ８２０）。この１８０リンギングメッセージはサーバ２０５からクライアント＃１（７０２）に転送される（ステップ８２５）。

２００ＯＫメッセージがクライアント＃２（７０６）からサーバ２０５に送られる（ステップ８３０）。この２００ＯＫメッセージはサーバ２０５からクライアント＃１（７０２）に転送される（ステップ８３５）。

アクノレッジメッセージＡＣＫはクライアント＃１（７０２）からクライアント＃２（７０６）に送られる（ステップ８４０）。テレビ会議セッション（メディアセッション）は二つのノード（クライアント＃１（８０２）と＃２（８０６））との間で発生する（ステップ８４５）。

図８Ｂは、本発明の一実施形態による、テレビ会議クライアントアプリケーション＃１（８０２）からＩＮＶＩＴＥ要求を受信したとき、テレビ会議サーバ２０５により実行されるステップを示す図である（図８Ａのステップ８１０）。

サーバ２０５は、要求しているユーザ（クライアント＃１（８０２））がサーバ２０５に登録されているかチェックし、コールされているユーザ（クライアント＃２（８０６））がサーバ２０５に登録されているかチェックする（ステップ８５０）。

サーバ２０５は各ユーザのネットワーク上のロケーションを判断し（ステップ８５５）、その二つのロケーション（異なる場合）を結ぶ低バンド幅のＷＡＮリンク（例えば、ＷＡＮ２５０）があるか判断する（ステップ８６０）。

二つのロケーションを結ぶ低バンド幅リンクＷＡＮがないとき、サーバ２０５はコールする（ステップ８６５）。しかし、二つのユーザ間に低バンド幅リンクがあるとき、ステップ８７０に進む。

ステップ８７０において、サーバ２０５はＷＡＮ２５０上のテレビ会議セッションのポリシーをチェックする。これは、基本的に「Ｘ個のセッションが最大ビットレートＹで発生する」ことに帰結する。サーバ２０５はこのポリシーに基づき利用可能性をチェックする（ステップ８７５）。利用可能性がないとき、サーバ２０５は次のメッセージ、「６００−Ｂｕｓｙ Ｅｖｅｒｙｗｈｅｒｅ」、「４８６−Ｂｕｓｙ Ｈｅｒｅ」、「５０３−Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ」、「６０３−Ｄｅｃｌｉｎｅ」のいずれかを送ることによりＩＮＶＩＴＥ要求を拒絶し（ステップ８８０）、この方法は終了する（図８Ａの方法のステップ８１５には続かない）。しかし、利用可能性があるとき、サーバ２０５はコールする（ステップ８６５）。ステップ８６５は図８Ａの方法のステップ８１５に続くことは理解すべきである。

図９は本発明の一実施形態による図８Ａの方法をさらに示す図である。図９の例には、クライアントアプリケーション１（９９８）、クライアントアプリケーション２（９９７）、テレビ会議サーバ２０５、および他のテレビ会議サーバ９８６が含まれる。図９に示されたテレビ会議サーバ２０５の要素は、メンバーデータベース３１４、アクティブセッションデータベース３１２、ネットワークアーキテクチャデータベース３１６に含まれるポリシーデータベース９９９、セッションマネージャ３２０、ＳＩＰモジュール３０４ｄ、およびサーバツーサーバ管理モジュール３０４ｅを含む。

図９は、テレビ会議サーバ２０５内の内部相互作用を図示するために設けられたもので、それゆえ、テレビ会議サーバ２０５のエンティティの間の信号フローの例を提供するために、基本レベルだけで示されている。

ＩＮＶＩＴＥ要求はクライアントアプリケーション１（９９８）からテレビ会議サーバ２０５内のＳＩＰモジュール３０４ｄに送られる（ステップ９０３）。ＳＩＰモジュール３０４ｄは、メッセージをデコードし、セッションマネージャ３２０にＩＮＶＩＴＥ要求を転送する（ステップ９０６）。セッションマネージャ３２０は、セッションが正しく設定されるように、アクティブセッションデータベース３１２、メンバーデータベース３１４、およびネットワークアーキテクチャデータベース３１６内のポリシーデータベース９９９をチェックする（それぞれステップ９０９、９１２、９１５）。セッションが正しく設定できたとき、アクティブセッションデータベース３１２、メンバーデータベース３１４、ポリシーデータベース９９９は、セッションマネージャ３２０にＯＫメッセージを送信する（ステップ９１８、９２１、９２４）。この検証プロセスが完了すると、テレビ会議サーバ２０５は、他のテレビ会議サーバにシステム状態の変更を知らせる（ステップ９２７、９３０）。

セッションマネージャ３２０はＩＮＶＩＴＥメッセージをＳＩＰモジュール３０４ｄに転送し（ステップ９３３）、このＳＩＰモジュール３０４ｄはそのＩＮＶＩＴＥメッセージをクライアントアプリケーション２（９９７）に転送する（ステップ９３６）。このＩＮＶＩＴＥメッセージを受信すると、クライアントアプリケーション２（９９７）は、ＳＩＰモジュール３０４ｄがＩＮＶＩＴＥメッセージを受信したことを示す１８０Ｒｉｎｇｉｎｇメッセージで、ＳＩＰモジュール３０４ｄに応答する（ステップ９３９）。この１８０ＲｉｎｇｉｎｇメッセージはＳＩＰモジュール３０４ｄにより受信、デコードされ、セッションマネージャ３２０に転送される（ステップ９４２）。テレビ会議サーバ２０５内の図９に示した各データベースのクライアントの状態が更新される（ステップ９４５、９４８、９５１、９５４、９５７、９５８）。

１８０Ｒｉｎｇｉｎｇメッセージはセッションマネージャ３２０からクライアントアプリケーション１（９９８）に転送される（ステップ９６０、９６３）。２００ＯＫメッセージは、クライアントアプリケーション２（９９７）からＳＩＰモジュール３０４ｄに送られ（ステップ９６６）、ＳＩＰモジュール３０４ｄからセッションマネージャ３２０に転送される（ステップ９６９）。この２００ＯＫメッセージは、クライアントアプリケーション２（９９７）がテレビ会議セッションへの誘いを受諾することを示す。

テレビ会議サーバ２０５内の図９に示した各データベースで、クライアントの状態が更新される（ステップ９７２、９７５、９７８、９８１、９８４、９８５）。ＯＫメッセージがセッションマネージャ３２０からＳＩＰモジュール３０４ｄに送られ、ＳＩＰモジュール３０４ｄからクライアントアプリケーション１（９９８）に転送される（ステップ９８８、９９１）。ＡＣＫメッセージはクライアントアプリケーション１（９９８）からクライアントアプリケーション２（９８７）に送られ、セッションの設定が完了する（ステップ９９４）。

本発明の一実施形態によるマルチキャストテレビ会議セッション設定に対応するセッション動作シナリオについて説明する。マルチキャストセッション設定を提供するために、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）が使用される。ＳＤＰプロトコルはマルチキャストアドレスとポート番号を伝えることができる。

マルチキャストセッション設定は、マルチキャストアドレスが必要な点を除いてユニキャストセッション設定と同様である。マルチキャストアドレスはネットワーク内のＭＡＤＣＡＰサーバ２１５により割り当てられる。

図１０は、本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたマルチキャストテレビ会議セッションを設定する方法を示す図である。図１０の例は、テレビ会議クライアントアプリケーション＃１（クライアント＃１）１００２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアントアプリケーション＃２（クライアント＃２）１００６、およびＭＡＤＣＡＰサーバ２１５を含む。

ＩＮＶＩＴＥ要求はクライアント＃１（１００２）からサーバ２０５に送られる（ステップ１０１０）。ＭＡＤＣＡＰ要求は、サーバ２０５からＭＡＤＣＡＰサーバ２１５に送られる（ステップ１０１５）。アクノレッジメッセージＡＣＫはＭＡＤＣＡＰサーバ２１５からサーバ２０５に送られる（ステップ１０２０）。ＩＮＶＩＴＥ要求はサーバ２０５からクライアント＃２（１００６）に転送される（ステップ１０２５）。

１８０リンギングメッセージは、クライアント＃２（１００６）からサーバ２０５に送られる（ステップ１０３０）。この１８０リンギングメッセージはサーバ２０５からクライアント＃１（１００２）に転送される（ステップ１０３５）。

２００ＯＫメッセージがクライアント＃２（１００６）からサーバ２０５に送られる（ステップ１０４０）。２００ＯＫメッセージはサーバ２０５からクライアント＃１（１００２）に転送される（ステップ１０４５）。

アクノレッジメッセージＡＣＫはクライアント＃１（１００２）からクライアント＃２（１００６）に送られる（ステップ１０５０）。テレビ会議セッション（メディアセッション）は二つのノード（クライアント＃１（１００２）と＃２（１００６））の間に発生する（ステップ１０５５）。

本発明の一実施形態によるテレビ会議セッションのキャンセルに対応するセッション動作シナリオについて説明する。ＣＡＮＣＥＬメッセージがペンディングとなっているセッション設定試行を終了させるのに使用される。クライアントはこのメッセージを使って、クライアントが以前開始したペンディングとなっているテレビ会議セッション設定試行をキャンセルすることができる。サーバが、ＩＮＶＩＴＥが送られたのと同じロケーションに、ペンディング要求とともにＣＡＮＣＥＬメッセージを転送する。クライアントはＣＡＮＣＥＬメッセージに「２００ＯＫ」メッセージで応答してはいけない。ＣＡＮＣＥＬメッセージが不成功のとき、セッション終了シーケンスを使用することができる（すなわちＢＹＥメッセージ）。

図１１は、本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたテレビセッションをキャンセルする方法を示す図である。図１１の例は、テレビ会議クライアントアプリケーション＃１（クライアント＃１）１１０２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアントアプリケーション＃２（クライアント＃２）１１０６を含む。

ＩＮＶＩＴＥ要求はクライアント＃１（１１０２）からサーバ２０５に送られる（ステップ１１１０）。このＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２（１１０６）に転送される（ステップ１１１５）。

１８０リンギングメッセージはクライアント＃２（１１０６）からサーバ２０５に送られる（ステップ１１２０）。この１８０リンギングメッセージは、サーバ２０５からクライアント＃１（１１０２）に転送される（ステップ１１２５）。

ＣＡＮＣＥＬメッセージは、クライアント＃１（１１０２）からサーバ２０５に送られる（ステップ１１３０）。このＣＡＮＣＥＬメッセージは、サーバ２０５からクライアント＃２（１１０６）に転送される（ステップ１１３５）。

本発明の一実施形態によるテレビ会議セッションの終了に対応するセッション動作シナリオについて説明する。図１２は、本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いた二つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１２の例は、第１のクライアント（テレビ会議クライアントアプリケーション＃１）１２０２、テレビ会議サーバ（サーバ）２０５、及び第２のクライアント（テレビ会議クライアントアプリケーション＃２）１２０６を含む。

クライアント＃１（１２０２）は、クライアント＃２（１２０６）とのコールを続けないことを決める。よって、クライアント＃１（１２０２）は、サーバ２０５にＢＹＥメッセージを送る（ステップ１２１０）。サーバ２０５は、このＢＹＥメッセージをクライアント＃２（１２０６）に転送する（ステップ１２２０）。

クライアント＃２（１２０６）は、クライアント＃２（１２０６）が切断したことを示す２００ＯＫメッセージをサーバ２０５に送り返す（ステップ１２３０）。サーバ２０５は、切断に成功したことを示す２００ＯＫメッセージをクライアント＃１（１２０２）に転送する（ステップ１２４０）。

図１３は、本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いた三つのクライアント間のテレビ会議セッションを終了するための方法を示す図である。図１３の例は、第１のクライアント（テレビ会議クライアントアプリケーション＃１）１３０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアントアプリケーション＃２）１３０６、および第３のクライアント（テレビ会議クライアントアプリケーション＃３）１３０８を含む。

クライアント＃１（１３０２）は、クライアント＃２（１３０６）とクライアント＃３（１３０８）とのコールを切断することを決める。これはクライアント＃２（１３０６）とクライアント＃３（１３０８）の間のセッションを破棄することではない。

クライアント＃１（１３０２）は、サーバ２０５にＢＹＥメッセージを送る（ステップ１３１０）。サーバ２０５は、このＢＹＥメッセージを解釈し、クライアント＃２（１３０６）とクライアント＃３（１３０８）とがクライアント＃１（１３０２）とのテレビ会議セッションに加わっていることを理解し、ＢＹＥメッセージをクライアント＃２（１３０６）とクライアント＃３（１３０８）の両方に転送する（ステップ１３２０）。

クライアント＃２（１３０６）は２００ＯＫメッセージをサーバ２０５に返す（ステップ１３４０）。サーバ２０５は、この２００ＯＫメッセージをクライアント＃１（１３０２）に転送する（ステップ１３５０）。クライアント＃３（１３０８）は２００ＯＫメッセージをサーバ２０５に返す（ステップ１３６０）。サーバ２０５は、この２００ＯＫメッセージをクライアント＃１（１３０２）に転送する（ステップ１３７０）。

図１４は、本発明の他の実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いた三つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図４の例は、第１のクライアント（テレビ会議クライアントアプリケーション＃１）１４０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアントアプリケーション＃２）１４０６、および第３のクライアント（テレビ会議クライアントアプリケーション＃３）１４０６を含む。

クライアント＃１（１４０２）は、クライアント＃２（１４０６）とクライアント＃３（１４０８）とのコールを切断することを決める。これはクライアント＃２（１４０６）とクライアント＃３（１４０６）の間のセッションを破棄することではない。

クライアント＃１（１４０２）は、クライアント＃２（１４０６）に送るために、サー０羽２０５にＢＹＥメッセージを送る（ステップ１４１０）。サーバ２０５は、クライアント＃２（１４０６）にこのＢＹＥメッセージを転送する。クライアント＃１（１４０２）は、クライアント＃３（１４０６）に送るために、サーバ２０５にＢＹＥメッセージを送る。サーバ２０５はこのＢＹＥメッセージをクライアント＃３（１４０６）に転送する（ステップ１４４０）。

暗いなんと＃２（１４０６）は、２００ＯＫメッセージをサーバ２０５に返す（ステップ１４５０）。サーバ２０５は、この２００ＯＫメッセージをクライアント＃１（１４０２）に返す（ステップ１４６０）。クライアント＃３（１４０８）はサーバ２０５に２００ＯＫメッセージを返す（ステップ１４７０）。サーバ２０５は、クライアント＃１（１４０２）にこの２００ＯＫメッセージを返す（ステップ１４８０）。

図１２から１４に関して説明した前記の例に加えて、テレビ会議の参加者が所属するマルチキャストグループにＢＹＥメッセージを送信することにより終了することもできる。この方法を用いて、サーバと他のクライアントアプリケーションはこのメッセージを受信する。オーバーヘッドが低いため、セッションを終了するメカニズムとしては、一般的で効率的である。

本発明の一実施形態による解像度とフレームレートの調整に対応する動作シナリオについて説明する。テレビ会議においては、コンピュータネットワーク上で異なるロケーションにあるユーザ間で、ライブの双方向ビデオを送信することが必要となる。リアルタイムのインターラクティブなビデオには、制限された遅れの下に大量の情報を送信する必要がある。このため、テレビ会議システムに使用するコンピュータネットワークは、セッションに参加する各ユーザに、適当なバンド幅とサービス品質を提供できなければならない。バンド幅は時によって制限されたリソースとなり、ネットワーク全体でサービス品質を常に保証することはできないので、一定の制限が存在する。私企業のネットワークにおいては、サービス品質を保証することは可能であるが、大量のバンド幅を保証することは必ずしも可能ではない。

企業のコンピュータネットワークのインフラストラクチャとして、高速のローカルエリアネットワーク（ＬＡＮ）が低速のリンクで接続されている場合がある（例えば図２を見よ）。各高速ＬＡＮは、普通、単一の地理的ロケーションにあるネットワークインフラストラクチャを表し、低速リンクは、その地理的ロケーションを接続する長い輸送リンクである。低速のリンクが使用される理由は、長い輸送リンクのコストが比較的高く、ネットワークトラッフィックのほとんどは、普通ローカルエリアネットワーク内に局在しているためで、それゆえ大量のデータはこれら長い輸送リンクを超えては交換されない。

ＩＰベースのネットワーク経由のサービスの品質は最近よくなったので、他のタイプの情報がこれらネットワークを経由して送信されるようになった。これにより、リアルタイムデータでないトラフィックに加え、リアルタイム情報（すなわち、オーディオおよびビデオ）を送信するためのドアが開かれた。ネットワークのサービス品質を利用するテレビ会議サービスは、このインフラストラクチャに乗せるのに適している。異なる地理的ロケーションにいる二人のユーザがリアルタイムテレビ会議セッションを行うことができる。テレビ会議セッションの一つの欠点は、リアルタイムビデオの送信が極端に大きなバンド幅を消費し、利用可能なネットワークリソースを消耗することである。ネットワークを通して送信されるリアルタイムビデオのビットレートは、ビデオ解像度と使用する圧縮アルゴリズムに主に依存する。典型的には、異なる地理的ロケーションにいる２、３、または４ユーザの間の一つのテレビ会議セッションは、適当なバンド幅をもつネットワークに適当にされ得る。しかし、一般的に、テレビ会議セッションにおいて、４人を超えるユーザはサポートしきれず、バンド幅の制限により、二つ目のテレビ会議セッションをサポートすることもできなかった。テレビ会議システムを制限するファクターは、地理的ロケーションの間の低速の長い輸送リンクである。

一つの解決策は、システムにおいてより多くのユーザをサポートするために、二つの地理的ロケーションの間の長い輸送リンクのバンド幅を大きくすることである。このアプローチの欠点は、バンド幅が非常に高価であることである。第２の解決策は、テレビ会議セッションの限定された数のユーザ（すなわち、アクティブユーザ）だけが、高分解能かつ高ビットレートで送信でき、セッションの残りのユーザ（パッシブユーザ）は、限定されたビットレートかつ限定された分解能で送信できるシステムとすることである。テレビ会議セッションオーガナイザが、どのユーザが高解像度で送信し、どのユーザが低解像度で送信するかを制御する。ユーザがセッションにおいて積極的に話したり情報を交換していないとき、そのユーザのビデオを高い解像度で送る必要はない。このようなアプローチにより、はなはだしい分量のバンド幅を節約することができる。

図１８Ａのテレビ会議クライアントアプリケーション１８００を参照して、このアプローチは、様々なウィンドウサイズ（すなわち、高解像度と低解像度のデコードされたビデオストリームを表す異なったサイズの表示ウィンドウ）をサポートするテレビ会議クライアントアプリケーション１８００のユーザインターフェイス１８０８と、サーバ２０５と他のクライアントアプリケーションの間の通信を特定するメッセージングシステム１８４２（図１８Ａのテレビ会議クライアントアプリケーション１８００にまた含まれるネットワークエンティティ１８０６に含まれる）とを有する。メッセージングシステム１８４２は、各クライアントアプリケーションのエンコードする解像度と送信するビットレートを制御するメッセージを含む。

本発明の一実施形態による解像度とフレームレートの調整に対応するメッセージについて説明する。特に、ＭＳＧ ＷＩＮＤＯＷ ＳＷＩＴＣＨメッセージとＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣメッセージについて説明する。

ＭＳＧ ＷＩＮＤＯＷ ＳＷＩＴＣＨメッセージは、クライアントからサーバに送られ、アクティブユーザとパッシブユーザ間のスイッチを示す。テレビ会議サーバはクライアントのこの要求を受けたことを通知する。

ＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣメッセージは、サーバから各クライアントに送られる。ＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣメッセージはクライアントが送るべき解像度（すなわち、ＣＩＦまたはＱＣＩＦ）とフレームレートを示す。各クライアントはＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣメッセージを受けたことを通知する。

図１５は、本発明の一実施形態による解像度とフレームレートを調整するシグナル方法を示す図である。図１５の例は、テレビ会議サーバ（サーバ）２０５、クライアント１（１５０４）、クライアント２（１５０６）、クライアント３（１５０８）、およびクライアント４（１５１０）を含む。

ＭＳＧ ＷＩＮＤＯＷ ＳＷＩＴＣＨメッセージは、クライアント１（１５０４）からサーバ２０５に送られる（ステップ１５２０）。アクノレッジメッセージＡＣＫがサーバ２０５からクライアント１（１５０４）に送られる（ステップ１５２５）。

ＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣ（ｌｏｗ）メッセージが、サーバ２０５からクライアント１（１５０４）に送られる（ステップ１５３０）。アクノレッジメッセージＡＣＫがクライアント１（１５０４）からサーバ２０５に送られる（ステップ１５３５）。

ＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣ（ｈｉｇｈ）メッセージが、サーバ２０５からクライアント２（１５０６）に送られる（ステップ１５４０）。アクノレッジメッセージＡＣＫがクライアント２（１５０６）からサーバ２０５に送られる（ステップ１５４５）。

ＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣ（ｌｏｗ）メッセージが、サーバ２０５からクライアント３（１５０８）に送られる（ステップ１５５０）。アクノレッジメッセージＡＣＫがクライアント３（１５０８）からサーバ２０５に送られる（ステップ１５５５）。

ＭＳＧ ＡＤＪＵＳＴ ＣＯＤＥＣ（ｌｏｗ）メッセージが、サーバ２０５からクライアント４（１５１０）に送られる（ステップ１５６０）。アクノレッジメッセージＡＣＫがクライアント４（１５１０）からサーバ２０５に送られる（ステップ１５６５）。

図１６は、本発明の一実施形態による解像度およびフレームレート調整（クライアント２および３）前のシグナリングを示す図である。図１７は、本発明の一実施形態による解像度とフレームレート調整（クライアント２および３）後のシグナリングを示す図である。図１６および１７は、クライアント１（１６０２）、クライアント２（１６０４）、ネットワークルータ１６０６、クライアント３（１６０８）、クライアント４（１６１０）を含む。

「低ビットレート／解像で送信」メッセージがクライアント１（１６０２）からネットワークルータ１６０６に送信される（ステップ１６２０）。「低ビットレート／解像度で送信」メッセージがクライアント２（１６０４）からネットワークルータ１６０６に送信される（ステップ１６３０）。「高ビットレート／解像度で送信」メッセージがクライアント４からネットワークルータ１６０６に送信される（ステップ１６３５）。

データがネットワークルータ１６０６からクライアント２（１６０４）、クライアント３（１６０８）、クライアント１（１６０２）およびクライアント４（１６１０）に、マルチキャストアドレスを用いて送信される（それぞれステップ１６４０、１６４５、１６５０、１６５５）。

図１７に進んで、「低ビットレート／解像度で送信」メッセージがクライアント１（１６０２）からネットワークルータ１６０６に送信される（ステップ１７２０）。「高ビットレート／解像度で送信」メッセージがクライアント３（１６０８）からネットワークルータ１６０６に送られる（ステップ１７２５）。「高ビットレート／解像度で送信」メッセージがクライアント２（１６０４）からネットワークルータ１６０６に送られる（ステップ１６３０）。「低ビットレート／解像度で送信」メッセージがクライアント４（１６１０）からネットワークルータ１６０６に送信される（ステップ１６３５）。

データがネットワークルータ１６０６からクライアント２（１６０４）、クライアント３（１６０８）、クライアント１（１６０２）およびクライアント４（１６１０）に、マルチキャストアドレスを用いて送信される（それぞれステップ１７４０、１７４５、１７５０、１７５５）。

本発明の一実施形態によるクライアントアプリケーションアーキテクチャについて説明する。クライアントアプリケーションは、ユーザと情報を交換し、他のクライアントアプリケーションとマルチメディアコンテントを交換し、サーバアプリケーションとコールを管理する役割を果たす。さらに、クライアントアプリケーションはそれ自身にサーバの機能を含めることができることは理解すべきである。図１８Ａは、本発明の一実施形態によるテレビ会議クライアントアプリケーション１８００のブロック図である。テレビ会議クライアントアプリケーション１８００は、例えばコンピュータ２２０ａ−ｆやコンピュータ２３０ａ−ｆなど、どのコンピュータ上にあってもよいことは理解すべきである。

テレビ会議クライアントアプリケーション１８００は、次の４つの基本的機能エンティティを含む：マルチメディアインターフェイスレイヤー１８０２、コード１８０４（オーディオコード１８０４ａおよびビデオコード１８０４ｂ）、ネットワークエンティティ１８０６、ユーザインターフェイス１８０８。

マルチメディアインターフェイスレイヤー１８０２はテレビ会議クライアントアプリケーション１８００の主要な制御インスタンスである。すべてのシステムない通信はマルチメディアインターフェイスレイヤー１８０２を通してルーティングされ、制御される。マルチメディアインターフェイスレイヤー１８０の鍵となる特徴のひとつは、異なるオーディオおよびビデオコード１８０４を容易に交換することができることである。これに加えて、マルチメディアインターフェイスレイヤー１８０２は、オペレーティングシステム（ＯＳ）依存のユーザ入出力エンティティおよびネットワークサブシステムにインターフェイスを提供する。マルチメディアインターフェイスレイヤー１８０２は、メンバーデータベース１８２０、主制御モジュール１８２２、オーディオミキサー１８９９、エコーキャンセレーションモジュール１８９８を含む。

ユーザインターフェイス１８０８は、エンドユーザがテレビ会議クライアントアプリケーション１８００と情報を交換する点を提供する。ユーザインターフェイス１８０８はＯＳ依存のモジュールとして実施されることが望ましいが、必ずしもそうすることが必要ではない。多くのグラフィカルユーザインターフェイスは、それが使用する特定のＯＳに依存する。ユーザインターフェイス１８０８の４つの主要な機能は、ビデオキャプチャ、ビデオディスプレイ、オーティオキャプチャ、オーディオ再生である。ユーザインターフェイス１８０８は、オーディオ／ビデオキャプチャインターフェイス１８３０、オーディオ／ビデオプレイバックモジュール１８３２、メンバービューモジュール１８３４、チャットモジュール１８３６、ユーザセレクション／メニュー１８３８を含む。オーディオ／ビデオキャプチャインターフェイス１８３０は、カメラインターフェイス１８３０ａ、マイクロフォンインターフェイス１８３０ｂ、ファイルインターフェイス１８３０ｃを含む。オーディオ／ビデオプレイバックモジュール１８３４は、ビデオディスプレイ１８３２ａ、オーディオプレイバックモジュール１８３２ｂ、ファイルインターフェイス１８３２ｃを含む。

ネットワークエンティティ１８０６はテレビ会議クライアントアプリケーション１８００の通信サブシステムを表す。ネットワークエンティティ１８０６の機能は、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）およびオーディオおよびビデオストリームの送信と受信に基づくクライアントツーサーバメッセージングである。ネットワークエンティティ１８０６は、クライアント間のメディアストリームの認証および暗号通信の基本セキュリティ機能も含む。ネットワークエンティティ１８０６は、セキュリティモジュール１８４０、メッセージングシステム１８４２、ビデオストリームモジュール１８４４、オーディオストリームモジュール１８４６、ＩＰソケット１８４８ａ−ｃを含む。

オーディオコーデック１８０４ａとビデオコーデック１８０４ｂは、デジタルメディアの圧縮と伸張を取り扱うサブシステムである。コーデックとのインターフェイスは、コーデックを容易に交換できるように単純で一般的でなければならない。マルチメディアインターフェイスレイヤー１８０２とコーデック１８０４の間の単純な関係は、実施のための実例としてのテンプレートまたはガイドとして定められている。オーディオコーデック１８０４ａとビデオコーデック１８０４ｂはそれぞれ、エンコーダ１８８０とデコーダ１８９０を含む。エンコーダ１８８０とデコーダ１８９０はそれぞれキュー１８９５を含む。

テレビ会議クライアントアプリケーション１８００は、少なくともテレビ会議サーバ２０５およびその他のクライアント１８７０とインターフェイスしている。

本発明の一実施形態による、図１８Ａのマルチメディアインターフェイスレイヤー１８０２に含まれるメンバーデータベース１８２０について説明する。メンバーデータベース１８２０は、セッションごとに参加する各ユーザに関する情報を記憶する。メンバーデータベース１８２０は、送信／受信ＩＰアドレスに関する情報、クライアントの能力、特定のコーデックに関する情報、異なるユーザの状態についての詳細を含む。前記アイテムは例示であり、それゆえ、本発明の精神および範囲を維持しながら、前記アイテムに加えてまたは代わりの他のアイテムがメンバーデータベース１８２０に保管されてもよい。メンバーデータベース１８２０に含まれる情報は、オーディオおよびビデオデコーダ１８９０に向けて到来する情報を制御するために使用される。ネットワークから到来するメディア情報は、正しいオーディオおよびビデオデコーダ１８９０にルーティングされる必要がある。オーディオおよびビデオエンコーダ１８９０から来るメディア情報は、正しいユニキャストまたはマルチキャストアドレスにルーティングされ配布される必要があることは、同じように重要である。メンバーデータベース１８２０に含まれる基本情報は、エンドユーザがセッションへの参加者とそれらの能力を知るために、ユーザインターフェイス１８０８にもルーティングされる。ＩＮＶＩＴＥ要求がテレビ会議サーバ２０５から受信されるとすぐに、ユーザはメンバーデータベース１８２０に追加され、ＢＹＥ要求がテレビ会議サーバ２０５から受信されるとすぐに、ユーザは削除される。メンバーデータベース１８２０はセッションが終了すると、その情報は消去される。

本発明の一実施形態による、図１８Ａのマルチメディアインターフェイスレイヤー１８０２に含まれる主制御モジュール１８２２について説明する。

主制御モジュール１８２２は、マルチメディアインターフェイスレイヤー１８０２の非常に重要な一部である。主制御モジュール１８２２は中央管理サブシステムとして機能し、次のキーとなる機能を提供する：オーディオおよびビデオデコーダおよびプレイバックのための同期メカニズム、デコーダの宛先をスクリーンまたはレコーディング目的のファイルに接続する、およびアプリケーションレイヤーのサービス品質。

オーディオおよびビデオプレイバックが同期していることは、ユーザの最適なテレビ会議のためになくてはならない。二つのメディアストリームを正確に同期させるため、タイムスタンプを使用しメディア紺点ととともに送信する必要がある。Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）は、この目的のためにタイムスタンプとシーケンスナンバーを含む一般的ヘッダを提供する。タイムスタンプは、二つのネットワークノードクロックを同期させるために提供されるものではなく、オーディオとビデオストリームを一致させてプレイバックするための同期を取るためのものである。このタイムスタンプは、キャプチャしたときの同じノードの共通クロックから取る必要がある。例えば、ビデオフレームがキャプチャされたとき、そのビデオフレームがキャプチャされたときの時間が記録されねばならない。オーディオでも同じことである。ＲＴＰの使用に関するより詳細な情報とガイドラインについては別途説明する。

オーディオとビデオを同期させるときの主制御モジュール１８２２の機能は、メタデータ（タイムスタンプとシーケンスナンバーを含む）とマルチメディアデータを適当に配信するために、ネットワークエンティティ１８０６とコーデック１８０４の間の接続をすることである。パケットが遅配されると、システムの現状によるデコードの前または後に、遅配されたパケットは捨てられることもある。ＲＴＰタイムスタンプは、プレゼンテーションおよびプレイバックタイムスタンプを生成するのに使用される。

主制御モジュール１８２２は、オーディオおよびビデオデコーダ１８９０の出力を、プレイバックのためスクリーンに、レコーディングのためファイルに、あるいは両方のために方向付ける役割も果たす。各でコーダ１８９０は独立に取り扱われ、それゆえ、例えば第１のデコーダの出力をスクリーンに表示し、第２の出力をファイルにレコードし、第３のデコーダからの出力をファイルとスクリーンに同時に送ることもできる。

上記の役割に加えて、主制御モジュール１８２２はアプリケーションレイヤーサービス品質にも関係する。主制御モジュール１８２２は、パケットドロップ、送受信したバイトに関する情報を集め、この情報に基づき動作する。メッセージを他のクライアントまたはテレビ会議サーバ２０５に送信し、ネットワークで発生した事態を修復するのを助けてもよい。Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＲＴＣＰ）は、統計とパケットロスをレポートするのに使用してもよく、特定アプリケーションのシグナリングに使用してもよい。

図１８Ｂは、本発明の一実施形態による、図１８Ａのマルチメディアインターフェイスレイヤー１８０２に含まれるオーディオミキサー１８９９をさらに示すブロック図である。オーディオミキサー１８９９（「ゲインコントロールモジュール」とも呼ぶ）は、複数のオーディオでコーダ１８９０と動作的に結合している。複数のオーディオでコーダ１８８０は、圧縮されたオーディオストリームを受信し、圧縮されていないオーディオストリームを出力する。圧縮されていないオーディオストリームはオーディオミキサー１８９９に入力され、結合したオーディオストリームとして出力される。

図１８Ｃは、本発明の一実施形態による、図１８Ａのマルチメディアインターフェイスレイヤー１８０２に含まれるエコーキャンセレーションモジュール１８９８をさらに示すブロック図である。エコーキャンセレーションモジュール（「エコーキャンセラー」とも呼ぶ）１８９８はスピーカ１８９７（例えばオーディオプレイバックモジュール１８３２ｂ）とマイクロホン１８９６（例えば、マイクロホンインターフェイス１８３０ｂ）に、動作的に結合している。スピーカ１８９７からのサウンドが全二重または二方向通信システムで生成されるとき、ローカルな聴取者に聞かれるように意図されている。しかし、生成されたサウンドは、ローカルマイクロホン１８９６によっても聞かれ、これにより信号が反対側に戻されエコーとして聞こえる。このため、テレビ会議クライアントアプリケーション１８００は、ユーザの使用感をよりよくするためにこの効果を緩和するエコーキャンセルモジュール１８９８を必要とする。

本発明の一実施形態によるテレビ会議クライアントアプリケーション１８００のサブシステムが利用できるインターフェイスについて説明する。このインターフェイスは、ユーザインターフェイス１８０８、ネットワークエンティティ１８０６、コーデック１８０４と情報交換する点を含む。ユーザインターフェイス１８０８は、キャプチャされたオーディオおよびビデオを、それらの対応するタイムスタンプと共に受信する機能を提供する。これに加え、表示と再生のためにオーディオとビデオをユーザインターフェイス１８０８に送信するための機能を有していなければならない。ネットワークエンティティ１８０６インターフェイスは、セッションコントロールとセキュリティのために、入出するメッセージをシグナリングするための機能を提供する。オーディオおよびビデオコーデック１８０４ａ、ｂは、圧縮または伸張のためにパケットを送受信するのと同様に、コンフィギュレーションコントロールのために基本的なインターフェイスを提供する。

本発明の一実施形態によるオーディオおよびビデオコーデック１８０４ａ、ｂについて説明する。

テレビ会議に使用可能なオーディオおよびビデオコーデックがある。本発明により使用されるコーデックはソフトウェアベースであることが好ましいが必ずしも必要ではない。本発明の一実施形態によると、通常のデスクトップコンピュータの処理パワーの制限により、Ｈ．２６３がビデオの圧縮伸張に使用される。将来、デスクトップコンピュータがよりパワフルになるにしたがって、Ｈ．２６Ｌのようなより進んだコーデックを使用する能力が実現され、利用されるであろう。もちろん、本発明は前記のタイプのコーデックに限定されるものではなく、それゆえ、本発明の精神と範囲を維持したままで他のタイプのコーデックを仕様してもよい。

本発明の一実施形態によるコーデック１８０４ａ、ｂへのインターフェイスについて説明する。説明にはＤａｔａＩｎ機能、ｃａｌｌｂａｃｋ機能、およびｃｏｄｅｃオプションを含む。コーデック１８０４ａ、ｂへのインターフェイスは十分柔軟性があり、将来新しいコーデックを付加することを許容すると共に、コーデックの互換性を許容するために一般的に定義されているべきである。この柔軟で一般的なインターフェイスを実施するために提案されたインターフェイスは、ユーザに限られた数の機能を与える非常に簡単なものである。

ＤａｔａＩｎ機能は、エンコーダまたはデコーダクラスのフレームまたはパケットを記憶するのに使用される。

マルチメディアインターフェイスレイヤー１８０２とマルチメディアコーデック１８０４の間の簡単な接続を提供するため、データ出力機能はコールバックとして実施される。マルチメディアインターフェイスレイヤー１８０２は、このコールバック機能を受信するエンティティの入力機能に設定する。例えば、コーデックがフレームのエンコーディングまたはデコーディングを完了したとき、エンコードまたはデコードプロセスからこの意図した情報を配布するために、この機能がコールされる。このコールバックの間、コーデックが何もできないという制限があるため、待機やシステムにおける不必要な遅れを防ぐため、この機能は可能な限り早く戻らねばならない。共有されたリソースにアクセスするときに、この機能において実行しなければならないただ一つの追加的な待機はミューテックスロックである。

異なるタイプのコーデックに利用可能なオプションの範囲は変化する。これらのオプションを管理するための必要性を満たすため、簡単なインターフェイスを使用すべきである。テキストベースのインターフェイスはその柔軟性の故に好ましい（しかし、必ずしもテキストベースでなくてもよい）。ＳＴＡＲＴおよびＳＴＯＰ等の共通セットのコマンドがあり、コーデック特有のコマンドがある。この方法によるとインターフェイスは簡単であるが、簡単なインタープリターが必要なのでコーデックはより複雑になる。例として、Ｏｐｔｉｏｎｓ関数は十分に一般的でありオプションを読み書きできる。

例： Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｓｔａｒｔ”）；Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｒｅｓｏｌｕｔｉｏｎ＝ＣＩＦ”）；等

例えば、コーデック間の共通のオプションの一部は次のように標準化されなければならない：スタート；ストップ；ポーズ；品質インデックス（０−１００）；分解能。

品質インデックスはコーデックの全般的な品質を０％から１００％の間の値として表現するファクターである。この値が高いほどビデオの品質が高いとされる。

図１９は、本発明の一実施形態による、オーディオコーデック１８０４ａおよび／または１８０４ｂのいずれかに含まれるデコーダ１８９０により使用される方法を示す図である。デコーダコンテクスト１９０１とコーラコンテクスト１９０２に関してこの方法を説明する。この方法は少なくとも次の入出力を用いて動作する：「データイン」１９９９、「シグナルイン」１９９８、「シグナルアウトコールバック」１９９７、「セットコールバックファンクション」１９９６、「データアウトコールバック」１９９５。入力「データイン」１９９９は、入力キューにデータを記憶するために使用される（ステップ１９０５）。

初期化ステップ（Ｉｎｉｔ）がデコーダ１８９０を初期化するために実行される（ステップ１９１０）。主ループが実行され、スタートコマンドかエグジットコマンドを待つ（ステップ１９２０）。エグジットコマンドが受信されたとき、メソッドが励起され（ステップ１９２２）、例えば他の動作が行われる（ステップ１９２４）。

データが入力キュー１８９５から読み出されるか、または、入力キュー１８９５が空っぽな場合、待ち条件が課される（ステップ１９３０）。データがステップ１９３０で読み出されたとき、出コードされる（ステップ１９４０）。「データアウトコールバック」１９９５がステップ１９２０に供給される。

本発明の一実施形態による、ネットワーク２００により使用される通信について説明する。この説明はネットワーク通信に関する上記の説明を補足するものである。

メッセージングシステム１８４２（図１８Ａのネットワークエンティティ１８０６に含まれる）は、テレビ会議クライアントアプリケーション１８００とテレビ会議サーバ２０５の間のインターフェイスを提供する。セッション管理（すなわちセッション設定と終了）のために使用するものである。全てのシグナリングメッセージは、テレビ会議サーバ２０５を通して通信され、クライアントからクライアントへ直接は行かない。マルチメディアコンテントのようなデータとプライベートなチャットメッセージは、クライアント間を直接送信される情報にのみ含まれる。メッセージングシステムは、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）に基づく標準を使用する。

テレビ会議クライアントアプリケーション１８００の機能を統合する異なるプロトコルがいくつかある。例えば、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）、Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）、Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＲＴＣＰ）、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）が使用されてもよい。

Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）の目的はセッション管理である。ＳＩＰは、ＩＰベースネットワークにおいて一人以上の参加者がいるマルチメディアセッションを生成し、変更し、終了するための、テキストベースのアプリケーションレイヤー制御プロトコルである。ＳＩＰはこれを達成するため、クライアントとサーバの間で使用される。ＳＩＰはテレビ会議サーバ２０５に関して上で説明している。

Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）は、リアルタイムマルチメディア（すなわちオーディオとビデオ）の送信に使用される。ＲＴＰは、マルチメディア情報のタイプに関するより詳細な情報を提供するためのアプリケーションレイヤープロトコルである。ＲＴＰは、トランスポートレイヤーの上にあり、普通はＵｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）の先頭で送られる。クライアントアプリケーションにおけるＲＴＰの主な機能は、それが付加されている（例えば、ＭＰＥＧ４、Ｈ．２６３、Ｇ７２３など）ペイロードのタイプを特定するのと同様に、（オーディオおよびビデオの同期のための）タイムスタンプとシーケンスナンバーを送信することである。

図２０は、本発明の一実施形態によるユーザプレーンプロトコルスタック２０００を示す図である。スタック２０００は、一つのレイヤー上のビデオ２０１０とボイス２０２０、別のレイヤー上のビデオ２０１０とボイス２０２０のためのＲＴＰ２０３０、さらに他のレイヤー上のＵＤＰポート＃Ｘ２０４０とＵＤＰポート＃Ｙ２０５０、ＩＰレイヤー２０６０、リンクレイヤー２０７０、物理レイヤー２０８０を含む。コーデック特有のＲＴＰヘッダーが一般的ＲＴＰヘッダーに加えて使用される。

Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＲＴＣＰ）はＲＴＰ標準の一部である。ＲＴＣＰは、送信者と受信者との間の統計れポーティングツールとして使用される。各テレビ会議クライアントアプリケーション１８００は、それらの統計を収集し、お互いにおよびサーバ２０５に送信する。テレビ会議サーバ２０５は、このデータに基づいてセッションで発生したかもしれない問題についての情報を記録する。

図２１は、本発明の一実施形態による制御プレーンプロトコルスタック２１００を示す図である。スタック２１００は、ＳＩＰ２１１０、ＵＩコーデックチェンジメッセージング２１２０、一つのレイヤー上のＲＴＣＰ２１３０、ＴＣＰレイヤー２１４０、ＩＰレイヤー２１５０、リンクレイヤー２１６０、物理レイヤー２１７０。

ＳＤＰの主な目的は、セッションのメディアストリームについての情報を送ることである。ＳＤＰは次のアイテムを含むが、これに限定されるものではない：セッション名および目的、セッションがアクティブな時間、セッションを構成するメディア、メディアを受信する情報（すなわち、アドレス、ポート、フォーマット等）、メディアのタイプ、トランスポートプロトコル（ＲＴＰ／ＵＤＰ／ＩＰ）、メディアのフォーマット（Ｈ．２６３等）、マルチキャスト、メディアのマルチキャストアドレス、メディアの転送ポート、ユニキャスト、メディアのリモートアドレス。

ＳＤＰ情報は、ＳＩＰメッセージのためのメッセージ本体である。それらは一緒に送信される。

本発明の一実施形態による、図１８Ａのユーザインターフェイスについてさらに説明する。ユーザインターフェイスは、テレビ会議クライアントアプリケーション１８００の非常に重要な構成要素である。ユーザインターフェイス１８０８は、いくつかのビュー（ディスプレイ／ボタン／メニュー／．．．）を含み、全ての入力データ（オーディオ／ビデオキャプチャ、ボタン、キーストローク）を取り扱うことができる。

図２２は、本発明の一実施形態による、図１８Ａのユーザインターフェイス１８０８に対応するスクリーンショット２２００を示すブロック図である。スクリーンショット２２００は、「大ビュー」２２１０、「小ビュー」２２２０、チャットビュー部分２２３０、メンバービュー部分２２４０、チャット編集部分２２５０を含む。

図１８Ａを再び参照して、ビデオキャプチャーインターフェイス１８３０は、次のいずれかを含むことができる：ウェブカム（図示せず）、キャプチャカードと高品質カメラ（図示せず）、カメラインターフェイス１８３０ａ、マイクロホンインターフェイス１８３０ｂ、ファイルインターフェイス１８３０ｃ等。

ウェブカムは、ウィンドウズ（登録商標）オペレーティングシステムにより提供されるＶｉｄｅｏ Ｆｏｒ Ｗｉｎｄｏｗｓ（登録商標）（ＶＦＷ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を用いるＵＳＢまたはファイヤーワイヤ（ＩＥＥＥ１３９４）、またはリナックス等の他のオペレーティングシステムの下で使用される代替的なキャプチャドライバーを通してサポートされる。もちろん、本発明は前記のインターフェイス、オペレーティングシステム、ドライバーに限定されず、それゆえ、本発明の精神および範囲を維持したまま、その他のインターフェイス、オペレーティングシステム、ドライバーを用いてもよい。

メンバービューモジュール１８３４は、進行中のコールに参加しているメンバーを示すのに使用される。コールのイニシエータ（すなわちマスター）は、欲しないメンバーを落とすか、アクティブなメンバーを選択することができる。いずれのメンバーもプライベートなチャットメッセージを交換するために一以上のメンバーを選択することができる。また、メンバーの状態は、メンバービューモジュール１８３４でシグナルされる。メンバーは自分自身の状態を、例えば「Ｕｎａｖａｉｌａｂｌｅ」とし、他のメンバーに、現在は不在だがすぐに戻ることを知らせることもできる。

ビデオストリームに加えて、いずれのメンバーもチャットモジュール１８３６を用いて全てまたは一部の他のメンバーにチャットメッセージを送信する機会を有する。メッセージはチャットビューに表示され、チャットエディットビューで編集される。スクロールバーにより古いメッセージを見ることもできる。

本発明の一実施形態によるクライアントアプリケーション１８００のための動作シナリオについて説明する。以下の説明は、クライアントアプリケーション１８００の特徴の一部の基本的なガイドラインであり、特徴をすべて挙げようとしたものではない。ログイン、コール開始、コール受理、ログオフについて説明する。

クライアントアプリケーション１８００が最初に開始されるときログインがなされる。ログインは、起動時にオペレーティングシステムに提供されたログインネームに基づき、自動的に行われ、またはログインとは独立した他のインターフェイスが使用できる。現在使用されているネットワークの好ましい認証方法、およびポリシーが管理されている方法に依存する。最も簡単な方法は、ネーミングを統一し、すでにあるユーザデータベースを（もし該当するなら）再利用できるようにするため、ウィンドウズ（登録商標）オペレーティングシステムにおいて使われているのと同じログインネームを使用することである。

図２３は、本発明の一実施形態によるログインインターフェイス２３００を示す図である。サインアップフィーチャ２３３０は、ユーザがサーバに現在アカウントを有していないときに使用する。電子メールアドレスは、アクセスを簡単にするため、いずれかの電子メールアドレス入力ボックス２３４０に入れることができる。コールを開始するため、クライアントアプリケーション１８００は、サーバ２０５にアベイラブルな候補者のリストをサーバ２０５に問い合わせる。クライアントは、テレビ会議セッションに参加して欲しいユーザを選択できる。セッションは、二人の参加者がいるときは、ユニキャストとして設定され、さもなくば、二人より多い参加者がいるときは、マルチキャストとして設定される。

図２４は、本発明の一実施形態による、セッション開始のためのユーザセレクションインターフェイス２４００を示すブロック図である。

ユーザがコールに参加すると、その画面にイニシエータの名前を示すメッセージが表示される。ユーザはそのコールを受理するか拒否することができる。もしユーザがそのコールを受理するとき、クライアントアプリケーション１８００は受理（またはアクノレッジ）メッセージをサーバ２０５に送信する。サーバ２０５は、コールに現在参加しているメンバー全員に新しいメンバーについて通知する。ユーザがサーバ２０５にキャンセルメッセージを送信することによりそのコールを拒否したとき、他の全てのメンバーはそのイベントについて通知される。図２５は、本発明の一実施形態による、入ってくるコールを受理するか拒絶するためのインビテーションインターフェイス２５００を示すブロック図である。

ログオフにより、ユーザはテレビ会議サーバ２０５のデータベースエンティティ３０２に含まれるメンバーデータベース３１４から削除される。ＢＹＥメッセージがセッションの各傘下クライアントに送信される。これはマルチキャストでもユニキャストでも可能である。マルチキャストが、このメッセージを送信する方法としては好ましい。

例示のため、本発明の以下の説明は、図２に示したネットワーク２００に関してなされている。しかし、本発明は図２に示した特定のネットワーク構成に限定されるものではないことは理解すべきであり、それゆえ、本発明の精神と範囲を維持したまま、ネットワークの他の構成と実施を本発明により採用することができる。

図２６は、本発明の一実施形態による三つのクライアント間のマルチキャストテレビ会議セッションを設定する方法を示すフロー図である。この方法は、テレビ会議クライアント＃１（クライアント１）２６０２、テレビ会議クライアント＃２（クライアント＃２）２６０４、テレビ会議クライアント＃３（クライアント＃３）２６０６、テレビ会議サーバ（サーバ）２０５、ルータ＃１（２４０）、ルータ＃２（２４５）に関して実施される。図２６の実施形態において、クライアント＃１（２６０２）は開始クライアントであり、クライアント＃２（２６０４）とクライアント＃３（２６０６）はデスティネーションクライアントであり、すべて交換可能にそのように参照される。

開始クライアント２６０２とデスティネーションクライアント２６０４、２６０６は、最初サーバ２０５に登録される（ステップ２６１０）。本発明の一実施形態によると、開始クライアント２６０２とデスティネーションクライアント２６０４、２６０６は、対応するクライアントコンピュータのＩＰアドレスを使用してサーバ２０６に登録される。ＩＰアドレスは電子メールアドレスまたはユーザネーム等のユニークな識別子に関連させてもよい。

テレビ会議セッションの要求は、開始クライアント２６０２からサーバ２０５に送信される（ステップ２６１５）。この要求は、開始クライアントテレビ会議セッションに参加するデスティネーションクライアント２６０４、２６０６を特定する。

サーバ２０５はマルチキャストＩＰグループアドレスを開始クライアント２６０２に送信する（ステップ２６２０）。開始クライアント２６０２はＩｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ（ＩＧＭＰ）参加リクエストをＩＰルータ＃１（２４０）に送信する（ステップ２６２５）。

サーバ２０５は、マルチキャストＩＰグループアドレスを送信し、デスティネーションクライアント２６０４、２６０６の各々に参加を要求する（ステップ２６３０）。デスティネーションクライアント２６０４、２６０６の各々は、サーバ２０５に受理または拒否の通知を送信する（ステップ２６３５）。通知は、サーバ２０５から開始クライアント２６０２に転送される（ステップ２６４０）。

ＩＧＭＰ参加要求は、デスティネーションクライアント２６０４、２６０６からＩＰルータ＃２（２４５）（ステップ２６４２）へ送信され、ＩＰルータ＃２（２４５）からＩＰルータ＃１（２４０）へ転送される（ステップ２６４５）。

コンテント（オーディオおよび／またはビデオ）は開始クライアント２６０２からＩＰルータ＃２（２４５）に転送され（ステップ２６４７）、マルチキャストＩＰグループアドレスを用いて、ＩＰルータ＃２（２４５）からデスティネーションクライアント２６０４、２６０６の各々に転送される（ステップ２６５０）。コンテントは、デスティネーションクライアント２６０４、２６０６からＩＰルータ＃２（２４５）へ転送される（ステップ２６５５）。

ＩＰルータ＃１（２４０）とＩＰルータ＃２（２４５）への参照は、本発明の方法をサポートするネットワーキングルーティングアーキテクチャの役割を示すためであることを理解すべきである。したがって、本発明の精神および範囲を維持したまま、ここに説明したものの替わりに、またはそれに追加して、他のネットワークルーティングデバイスを使用してもよい。

本発明はテレビ会議セッションだけに制限されるものではなく、同じプロトコルを用いて、複数のクライアントに一方向のマルチキャストセッションを設定するために使用してもよい。このシナリオにおいて、アプリケーションは、受信クライアントにはマルチキャストグループＩＰアドレスを送信させ内容に制限すべきである。

添付した図面を参照して実施形態をここに説明したが、本発明はこれらの実施形態に限定されるものではなく、本発明の範囲と精神から逸脱せずに当該技術分野における知識を持ったものにより、様々な変更や修正をできることは理解すべきである。それら全ての変更と修正は、添付したクレームにより特定される発明の範囲内に含めることができる。

本発明の一実施形態による、本発明が適用されるコンピュータシステム１００を示すブロック図である。 本発明の一実施形態による、ユニキャストテレビ会議セッションを示すブロック図である。 本発明の一実施形態による、マルチキャストテレビ会議セッションを示すブロック図である。 本発明の一実施形態による、本発明が適用されるネットワーク２００を示すブロック図である。 本発明の一実施形態による、図２のテレビ会議サーバ２０５を示すブロック図である。 本発明の一実施形態による、図３のデータベースエンティティに含まれるメンバーデータベースのためのメンバーデータベースエントリー４００を示す図である。 本発明の一実施形態による、図３のデータベースエンティティ３０２に含まれるアクティブセッションデータベース３１２のためのアクティブセッションエントリー５００を示すブロック図である。 本発明の一実施形態による、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）クライアントサーバアーキテクチャ６００を示すブロック図である。 本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたテレビ会議セッションのためのレジスターする方法を示す図である。 本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたユニキャストテレビ会議セッションを設定する方法を示す図である。 本発明の一実施形態による、ＩＮＶＩＴＥ要求がクライアント＃１８０２から受信されたとき（図８Ａのステップ８１０）、図２のテレビ会議サーバ２０５により実行されるステップを示す図である。 本発明の一実施形態による、図８Ａの方法をさらに示す図である。 本発明の他の実施形態によるＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたマルチキャストテレビ会議セッションを設定する方法を示す図である。 本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いたテレビ会議セッションをキャンセルする方法を示す図である。 本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を二つのクライアントの間のテレビ会議セッションを終了させる方法を示す図である。 本発明の一実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いて三つのクライアントの間のテレビ会議セッションを終了させる方法を示す図である。 本発明の他の実施形態による、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を用いた三つのクライアントの間のテレビ会議セッションを終了させる方法を示す図である。 本発明の一実施形態による、解像度とフレームレートを修正する信号方法を示す図である。 本発明の一実施形態による、解像度とフレームレートを修正する（クライアント２及び３）前の信号を示す図である。 本発明の一実施形態による、解像度およびフレームレートを修正した（クライアント２及び３）後の信号を示す図である。 本発明の一実施形態による、テレビ会議クライアントアプリケーション１８００のブロック図である。 本発明の一実施形態による、図１８Ａのマルチメディアインターフェイスレイヤー１８０２に含まれるオーディオミキサー１８９９をさらに示すブロック図である。 本発明の一実施形態による、図１８Ａのマルチメディアインターフェイスレイヤー１８０２に含まれるエコーキャンセレーションモジュールをさらに示すブロック図である。 本発明の一実施形態による、オーディオコーデック１８０４ａおよび／またはビデオコーデック１８０４ｂに含まれるデコーダ１８９０により使用される方法を示す図である。 本発明の一実施形態による、ユーザプレーンプロトコルスタック２０００を示す図である。 本発明の一実施形態による、コントロールプレーンプロトコルスタック２１００を示す図である。 本発明の一実施形態による、図１８Ａのユーザインターフェイス１８０８に対応するスクリーンショット２２００を示すブロック図である。 本発明の一実施形態による、ログインインターフェイス２３００を示す図である。 本発明の一実施形態による、セッション開始のためのユーザセレクションインターフェイス２４００を示すブロック図である。 本発明の一実施形態による、到来するコールを受ける若しくは拒絶するためのインビテーションインターフェイス２５００を示すブロック図である。 本発明の一実施形態による、三つのクライアント間のマルチキャストテレビ電話セッションを設定する方法を示すフロー図である。

Claims (24)

1. クライアント間にマルチキャストセッションを設定する方法であって、
   前記クライアントが前記ビデオ会議セッションに参加するように共通マルチキャストＩＰアドレスを割り当てるステップと、
   前記クライアントの少なくとも一つに前記共通マルチキャストＩＰアドレスを送信するステップとを含む方法。
2. 請求項１記載の方法であって、前記共通マルチキャストＩＰアドレスを用いて前記少なくとも一つのクライアントにテレビ会議コンテントを送信するステップをさらに含む方法。
3. 請求項１記載の方法であって、前記マルチキャストセッションに関して前記少なくとも一つのクライアントを登録するステップをさらに含む方法。
4. 請求項３記載の方法であって、前記登録するステップは、前記少なくとも一つのクライアントの各々を対応するＩＰアドレスに関連付けるステップをさらに含むことを特徴とする方法。
5. 請求項４記載の方法であって、前記登録するステップは、前記少なくとも一つのクライアントの各々の前記対応するＩＰアドレスを電子メールアドレスおよびユーザ名のうち少なくとも一方と関連付ける方法。
6. 請求項１記載の方法であって、前記マルチキャストセッションに参加すべき前記クライアントを特定する、前記マルチキャストセッションを求める最初の要求を受信するステップをさらに含む方法。
7. 請求項１記載の方法であって、前記少なくとも一つのクライアントに前記マルチキャストセッションへの参加要求への受諾または拒否を送信するステップをさらに含む方法。
8. 請求項７記載の方法であって、前記少なくとも一つのクライアントから、前記マルチキャストセッションへの参加要求に対する受諾または拒否を受信するステップをさらに含む方法。
9. 請求項１記載の方法であって、
   前記少なくとも一つのクライアントからＩｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ（ＩＧＭＰ）参加要求を受信するステップと、
   ＩＧＭＰ参加要求に応じて、前記共通マルチキャストＩＰアドレスを用いて前記少なくとも一つのクライアントにコンテントを送信するステップとをさらに含む方法。
10. クライアント間にマルチキャストセッションを設定するシステムであって、
    前記クライアントが前記セッションに参加するように共通マルチキャストＩＰアドレスを割り当てる手段と、
    前記割り当てる手段とデータ通信をする、前記クライアントの少なくとも一つに前記共通マルチキャストＩＰアドレスを送信する手段と
    が設けられたシステム。
11. 請求項１０記載のシステムであって、前記共通マルチキャストＩＰアドレスを用いて前記少なくとも一つのクライアントにテレビ会議コンテントを送信する手段がさらに設けられたシステム。
12. 請求項１０記載のシステムであって、前記マルチキャストセッションに関して前記少なくとも一つのクライアントを登録する手段がさらに設けられたシステム。
13. 請求項１２記載のシステムであって、前記登録する手段は、前記少なくとも一つのクライアントの各々を対応するＩＰアドレスに関連付ける手段がさらに設けられたことを特徴とするシステム。
14. 請求項１３記載のシステムであって、前記登録する手段は、前記少なくとも一つのクライアントの各々の前記対応するＩＰアドレスを電子メールアドレスおよびユーザ名のうち少なくとも一方と関連付けるシステム。
15. 請求項１０記載のシステムであって、前記マルチキャストセッションに参加すべき前記クライアントを特定する、前記マルチキャストセッションを求める最初の要求を受信する手段がさらに設けられたシステム。
16. 請求項１０記載のシステムであって、前記少なくとも一つのクライアントの各々に、前記マルチキャストセッションへの参加要求を送信する手段がさらに設けられたシステム。
17. 請求項１６記載のシステムであって、前記少なくとも一つのクライアントの各々から、前記マルチキャストセッションへの参加要求に対する受諾または拒否を受信する手段がさらに設けられたシステム。
18. 請求項１０記載のシステムであって、
    前記少なくとも一つのクライアントの各々からＩｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ（ＩＧＭＰ）参加要求を受信する手段と、
    ＩＧＭＰ参加要求に応じて、前記共通マルチキャストＩＰアドレスを用いて前記少なくとも一つのクライアントにコンテントを送信する手段とをさらに含むシステム。
19. クライアント間にマルチキャストセッションを設定する方法であって、
    前記テレビ会議セッションのための共通マルチキャストＩＰアドレスを受信する能力を提供するステップと、
    前記共通マルチキャストＩＰアドレスを用いてテレビ会議コンテントを受信する能力を提供するステップとを含む方法。
20. 請求項１９記載の方法であって、前記マルチキャストセッションに関して登録する能力を提供するステップをさらに含む方法。
21. 請求項１９記載の方法であって、前記マルチキャストセッションに参加すべき前記クライアントを特定する、前記マルチキャストセッションを求める最初の要求を送信する能力を提供するステップをさらに含む方法。
22. 請求項１９記載の方法であって、前記マルチキャストセッションに参加する要求を受信する能力を提供するステップをさらに含む方法。
23. 請求項２２記載の方法であって、前記マルチキャストセッションへの参加要求に対する受諾または拒否を送信する能力を提供するステップをさらに含む方法。
24. 請求項１９記載の方法であって、
    Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ（ＩＧＭＰ）参加要求を送信する能力を提供するステップと、
    ＩＧＭＰ参加要求に応じて、前記共通マルチキャストＩＰアドレスを用いてコンテントを受信する能力を提供するステップとをさらに含む方法。

Images