JP2005513869A - テレビ会議帯域選定メカニズム - 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