(57)【要約】  現在行われているテレビ会議セッションをユニキャストからマルチキャストに切り替える方法。該方法はインビテーションをサーバから追加関係者に送信する工程（２６２０）、共通マルチキャスト・インターネット・プロトコル（ＩＰ）アドレスを割り当てて該共通マリチキャストＩＰアドレスをテレビ会議セッションにおける現在の参加者及びテレビ会議セッションに追加される追加関係者に対して送信する工程（２６４０）、ＩＧＭＰメッセージを現在の参加者及び追加関係者からネットワークに対して送信する工程（２６５０）、及びマルチキャスト・アドレス上でテレビ会議セッションをホストする工程（２６６０）を含む。
2005513836.tif 000002
【特許請求の範囲】
【請求項１】
現在行われているテレビ会議セッションをユニキャストからマルチキャストに切り換える方法であって：
共通のマルチキャスト・インターネット・プロトコル（ＩＰ）アドレスを割り当てる工程；及び
該共通のマルチキャストＩＰアドレスを前記テレビ会議セッションにおける少なくとも一現行参加者及び該テレビ会議セッションに追加される追加関係者に送信する工程；
を有することを特徴とする方法。
【請求項２】
請求項１記載の方法であって、更に：
前記共通のマルチキャストＩＰアドレス上で前記テレビ会議セッションに関する全てのトラフィックを送信して受信することができることを設ける工程；
を有することを特徴とする方法。
【請求項３】
請求項１記載の方法であって、更に：
前記少なくとも一現行参加者及び前記追加関係者からインターネット・グループ・マルチキャスト・プロトコル（すなわち、ＩＧＭＰ）を受信する工程；
を有することを特徴とする方法。
【請求項４】
請求項１記載の方法であって、更に：
前記テレビ会議セッションに追加される前記追加関係者を特定する要求を受信する工程；及び
該追加関係者に対して該テレビ会議セッションに対するインビテーションを送信する工程；
を有することを特徴とする方法。
【請求項５】
請求項４記載の方法であって、更に：
前記インビテーションに関する承諾又は辞退を受信する工程；
を有することを特徴とする方法。
【請求項６】
請求項１記載の方法であって、更に：
全てのユニキャスト通信を中止することができることを設ける工程；
を有することを特徴とする方法。
【請求項７】
現在行われているテレビ会議セッションをユニキャストからマルチキャストに切り換えるシステムであって：
共通のマルチキャスト・インターネット・プロトコル（ＩＰ）アドレスを割り当てる手段；及び
該共通のマルチキャストＩＰアドレスを前記テレビ会議セッションにおける少なくとも一現行参加者及び該テレビ会議セッションに追加される追加関係者に送信する手段；
を有することを特徴とするシステム。
【請求項８】
請求項７記載のシステムであって、更に：
前記共通のマルチキャストＩＰアドレス上で前記テレビ会議セッションに関する全てのトラフィックを送信して受信する手段；
を有することを特徴とするシステム。
【請求項９】
請求項７記載のシステムであって、更に：
前記少なくとも一現行参加者及び前記追加関係者からインターネット・グループ・マルチキャスト・プロトコル（すなわち、ＩＧＭＰ）を受信する手段；
を有することを特徴とするシステム。
【請求項１０】
請求項７記載のシステムであって、更に：
前記テレビ会議セッションに追加される前記追加関係者を特定する要求を受信する手段；及び
該追加関係者に対して該テレビ会議セッションに対するインビテーションを送信する手段；
を有することを特徴とするシステム。
【請求項１１】
請求項１０記載のシステムであって、更に：
前記インビテーションに関する承諾又は辞退を受信する手段；
を有することを特徴とするシステム。
【請求項１２】
請求項１１記載のシステムであって、更に：
全てのユニキャスト通信を中止する手段；
を有することを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、テレビ会議、特に、インターネット・プロトコル（ＩＰ）ベースのテレビ会議をユニキャストからマルチキャストに切り替える方法、に関するものである。
【背景技術】
【０００２】
典型的なテレビ会議が２つのクライアント間で設定される場合、このセッションに参加するクライアントは２つのみであることが当初、想定される。参加者が２者のみの場合、お互いにトラフィックを直接送信し得る。これによってＩＰユニキャストを用いるようテレビ会議セッションを設定することが可能になる。これはお互いに直接、アドレスを指定してトラフィックを送信することを意味する。一般に、マルチキャストを用いるよう全てのテレビ会議を設定することは可能でないが、これは使用可能なマルチキャスト・アドレスが限られた数しかないからである。
【０００３】
第３の人物が別の局からテレビ会議に参加するようインバイトされた場合、追加ユニキャスト接続を設定する必要がある。各ノードは２つのユニキャスト・セッションを必要とする。このアプローチの欠点は、各ノード上で、各ユニキャスト・セッションの発信トラフィックが同様なものになることである。テレビ会議アプリケーションは映像ストリームを２つの別個の行き先に２度送信する。これは、実際に必要となるよりも２倍の帯域量を発信インタフェース上で費やすことになる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、ＩＰベースのテレビ会議セッションをユニキャストからマルチキャストに切り替える方法を有することが望ましく、かつ、特に効果的である。
【課題を解決するための手段】
【０００５】
上記の課題、更には、先行技術の関連する課題、は本発明、ＩＰベースのテレビ会議セッションをユニキャストからマルチキャストに切り替える方法、によって解決されるものである。本発明は、例えば、追加参加者が既存のテレビ会議セッションに参加する場合に使用されることが効果的であり得る。そのような場合においては、全てのトラフィックが一度に、発信インタフェース上でマルチキャスト・グループを表す特定ＩＰアドレスに対して送信される。
【発明を実施するための最良の形態】
【０００６】
本発明の特徴によって、現在行われているテレビ会議をユニキャストからマルチキャストに切り替える方法を設ける。該方法は共通マルチキャスト・インターネット・プロトコル（ＩＰ）アドレスを割り当てる工程、及びテレビ会議セッションにおける少なくとも現行の参加者及びテレビ会議セッションに追加される追加関係者に対して共通のマルチキャストＩＰアドレスを送信する工程を含む。
【０００７】
本発明の別の特徴によって、現在行われているテレビ会議をユニキャストからマルチキャストに切り替えるシステムを設ける。該方法は共通マルチキャスト・インターネット・プロトコル（ＩＰ）アドレスを割り当てる手段、及びテレビ会議セッションにおける少なくとも現行の参加者及びテレビ会議セッションに追加される追加関係者に対して共通のマルチキャストＩＰアドレスを送信する手段を含む。
【０００８】
本発明のこれら及び他の特徴、特性、及び効果は好適実施例の以下の詳細説明、更には、添付図面、からわかるものである。
【０００９】
本発明はインターネット・プロトコル（ＩＰ）ベースのテレビ会議をユニキャストからマルチキャストに切り替える方法に関する。本発明は、例えば、追加参加者が既存のテレビ会議に参加する場合に効果的に利用し得る。そのような場合、全てのトラフィックが発信インタフェース上でマルチキャスト・グループを表す特定のＩＰアドレスに対して１度、送信される。
【００１０】
本発明はハードウェア、ソフトウェア、ファームウェア、特定用途向プロセッサ、又はその組み合わせの種々の形態において実施し得ることがわかる。本発明はハードウェア及びソフトウェアの組み合わせとして実施されるのが好適である。更に、ソフトウェアはプログラム記憶装置上で明白に実施されたアプリケーション・プログラムとして実施されることが好適である。アプリケーション・プログラムは如何なる適切なアーキテクチャを有するマシンに対してもアップロードし得、如何なる適切なアーキテクチャを有するマシンによっても実行し得る。マシンは１つ以上の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、及び入出力（Ｉ／Ｏ）インタフェースのようなハードウェアを有するコンピュータ・プラットフォーム上で実施される。コンピュータ・プラットフォームは更にオペレーティング・システム及びマイクロインストラクション・コードを含む。ここに記載する種々の処理及び機能は、オペレーティング・システムによって実行される、マイクロインストラクション・コードの一部又はアプリケーション・プログラムの一部（又はその組み合わせ）の何れかであり得る。更に、別のデータ記憶装置及び印刷装置のような種々の他の周辺装置をコンピュータ・プラットフォームに接続し得る。
【００１１】
更に、添付図面に表す構成システム部分及び方法工程の一部はソフトウェアによって実施されるのが好適であるので、システム構成部分（又は処理工程）間の実際の接続は本発明がプログラム化される方法によって変わってくることがあることがわかる。ここに表す教示を前提とすると、当業者は本発明のこれら及び類似した実施例及び構成を企図することができる。
【実施例】
【００１２】
図１Ａは本発明の例示的実施例による、本発明を形成し得るコンピュータ・システム１００を示す構成図である。コンピュータ処理システム１００はシステム・バス１０４経由で他の構成部分に動作するよう結合された少なくとも１つのプロセッサ（ＣＰＵ）１０２を含む。読み取り専用メモリ（ＲＯＭ）１０６、ランダム・アクセス・メモリ（ＲＡＭ）１０８、表示アダプタ１１０、入出力アダプタ１１２、ユーザ・インタフェース・アダプタ１１４、サウンド・アダプタ１９９、及びネットワーク・アダプタ１９８がシステム・バス１０４に動作するよう結合される。
【００１３】
表示装置１１６は表示アダプタ１１０によってシステム・バス１０４に動作するよう結合される。ディスク記憶装置（例えば、磁気又は光ディスク記憶装置）１１８は入出力アダプタ１１２によってシステム・バス１０４に動作するよう結合される。
【００１４】
マウス１２０及びキーボード１２２はユーザ・インタフェース・アダプタ１１４によってシステム・バス１０４に動作するよう結合される。マウス１２０及びキーボード１２２は情報をシステム１００に入力して該システムから出力するのに用いられる。
【００１５】
少なくとも１つのスピーカ（以降「スピーカ」）１９７はサウンド・アダプタ１９９によってシステム・バス１０４に動作するよう結合される。
【００１６】
（ディジタル及び／又はアナログ）モデム１９６はネットワーク・アダプタ１９８によってシステム・バス１０４に動作するよう結合される。
【００１７】
次に、本発明の例示的実施例による、ポリシー・ベースのネットワーク管理（ＰＢＮＭ）を説明する。ＰＢＮＭはネットワークを管理するようポリシーを規定して配信することができることを設ける技術である（本発明を形成し得る例示的ネットワークを図２によって以下に説明する。）。これらのポリシーによって帯域及びセキュリティのようなクリティカルなネットワーク・リソースの制御を連携させることを可能にする。ＰＢＮＭはネットワーク上で差異のある待遇を必要とする、ＩＰベースのテレビ会議のような、アプリケーションを動作可能にする。ＰＢＭＮは異なる種類のアプリケーションが単一のネットワーク上で共存してこれらのアプリケーション各々に対して必要なリソースを設けることを可能にする基礎を設ける。
【００１８】
更に詳細には、ＰＢＮＭはネットワーク・リソースを消費するアプリケーション及びユーザに対するポリシーを規定する。例えば、ビジネス・クリティカルなアプリケーションはネットワーク上の最高の優先度及び帯域の一部を得ることができ、ビデオ会議及びボイス・オーバＩＰは次に高い優先度を得ることができ、更に、最後に、厳密な帯域又はタイム・クリティカルな制約を有しないウェブ・トラフィック及びファイル転送はネットワーク上の残りのリソースを得ることができる。このユーザ及びアプリケーションの差異はＰＢＮＭによって実現し得る。
【００１９】
テレビ会議システムはテレビ会議アプリケーションに相当するポリシーに対するネットワーク・ポリシー・サーバを問い合わせることによってＰＢＮＭシステムに接続する。テレビ会議サーバはポリシーをネットワーク・ポリシー・サーバから取得して受信パラメータに基づいてビデオ会議用ネットワークにおいて利用可能なリソースを判定する。ポリシーは一般に、例えば、一日の特定の時間帯又は特定のユーザに対してのみこのアプリケーションが利用可能な帯域に相当する。構成は、容易に、ポリシー及び又はその一部に、例えば、追加、削除、置換、修正、など、を行うことによって修正し得る。その結果、テレビ会議サーバはネットワーク上の会議セッションを管理するようポリシーにおいて設けられた情報を用いる。
【００２０】
図２は本発明の例示的実施例による、本発明を形成し得るネットワーク２００を示す構成図である。ネットワーク２００は：テレビ会議サーバ２０５；ポリシー及びＱｏＳマネージャ２１０；ＭＡＤＣＡＰサーバ２１５；第１複数コンピュータ２２０ａ乃至ｆ；第１ローカル・エリア・ネットワーク２２５；第１ルータ２４０；第２複数コンピュータ２３０ａ乃至ｅ；第２ローカル・エリア・ネットワーク２３５；第２ルータ２４５；及びワイド・エリア・ネットワーク２５０；を含む。
【００２１】
次に、本発明の例示的実施例による、サーバ・アーキテクチャを説明する。図３は本発明の例示的実施例による、図２のテレビ会議サーバ２０５を示す構成図である。テレビ会議サーバ２０５は以下の３つの基本エンティティ：データベース・エンティティ３０２；ネットワーク通信エンティティ３０４、及びセッション管理エンティティ３０６；を含むとみなし得る。
【００２２】
セッション管理エンティティ３０６はテレビ会議セッションの設定及びティア・ダウンを管理する役割を果たす。セッション管理エンティティ３０６は更に、テレビ会議サーバ２０５に対するたいていの主制御を設ける。セッション管理エンティティ３０６はセッション管理エンティティ３０６の機能を実施するセッション・マネージャ３２０を含む。
【００２３】
ネットワーク通信エンティティ３０４はテレビ会議システムにおいて用いられる多くの異なるプロトコルをカプセル化する役割を果たす。プロトコルは遠隔管理及び運営用シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）、ポリシー管理用共通オープン・ポリシー・サービス（ＯＰＳ）又はポリシー管理用軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）のような別のプロトコル、マルチキャスト・アドレス割り当て用マルチキャスト・アドレス動的クライアント割り当てプロトコル（ＭＡＤＣＡＰ）、テレビ会議セッション管理用セッション開始プロトコル（ＳＩＰ）、及び分散テレビ会議サーバ管理用サーバ間メッセージングを含み得る。したがって、ネットワーク通信エンティティ３０４は：ＳＮＭＰモジュール３０４ａ；ＬＤＡＰクライアント・モジュール３０４ｂ；ＭＡＤＣＡＰクライアント・モジュール３０４ｃ；ＳＩＰモジュール３０４ｄ；及びサーバ間管理モジュール３０４ｅ；を含む。更に、上記の構成部分３０４ａ乃至ｅ各々は以下の構成部分：遠隔管理端末３８２；ネットワーク・ポリシー・サーバ（帯域ブローカ）３８４；ＭＡＤＣＡＰサーバ２１５；デスクトップ会議クライアント３８８；及び他のビデオ会議サーバ３９０；と通信し合う。そのような通信は更に、併せてプロトコル・モジュール３３０によって表す、伝送制御プロトコル（ＴＣＰ）、ユーザ・データグラム・プロトコル（ＵＤＰ）、インターネット・プロトコル（ＩＰ）を用いて実施し得る。上記のプロトコル及び相当する構成部分は単に、例示的なものであるので、他のプロトコル及び相当する構成部分も、本発明の精神及び範囲を維持しながら、容易に使用し得ることがわかる。
【００２４】
更に、テレビ会議サーバ２０５のアーキテクチャは、テレビ会議セッションからのコンテンツを送受信するよう携帯デバイス上のユーザが仮想私設網（ＶＰＮ）を通じて企業インフラストラクチャに接続するのに適していることがわかる。
【００２５】
データベース・エンティティ３０２は以下の４つのデータベース：スケジューリング・データベース３１０、アクティブ・セッション・データベース３１２、メンバ・データベース３１４、及びネットワーク・アーキテクチャ・データベース３１６；を含む。
【００２６】
テレビ会議システム・サーバ２０５は更に、企業ＬＤＡＰサーバ（ユーザ情報）３４０及びオプションの外部データベース３４２を含むか、少なくとも、該サーバ及びデータベースとインタフェースする。オプションの外部データベース３４２はＬＤＡＰクライアント３０４ｂを含む。
【００２７】
次に、本発明の実施例によって、図３のデータべース・エンティティ３０２に含まれるメンバ・データベース３１４を説明する。メンバ・データベース３１４はテレビ会議システムにログ・インした各ユーザの情報を含む。例として、以下の情報：ユーザ名；（該当する場合）パスワード；サポート・ビデオ・コデック及びキャプチャ・ソルーション；サポート・オーディオ・コデック；現行ＩＰアドレス；（現在、実行中のコールのメンバである場合）現行コール番号；利用可能性（利用可能又は利用不能）；ビデオ・カメラの種類及び型式；ネットワーク上の場所（各場所は制限帯域ワイド・エリア・ネットワークによって接続される）；及びＣＰＵの種類並びに処理パワー；をユーザ毎にメンバ・データベース３１４に保持し得る。上記の項目は単に例示的なものであるので、上記の項目の一部又は全てに追加した他の項目又は上記の項目の一部又は全ての代わりの他の項目を更に、本発明の精神及び範囲を維持しながら、ユーザ毎にメンバ・データベース３１４に保持し得ることがわかる。
【００２８】
図４は、本発明の例示的実施例による、図３のデータベース・エンティティ３０２に含まれるメンバ・データベース３１４に対するメンバ・データベース・エントリ４００を示す図である。図４の例示的実施例においては、メンバ・データベース３１４は簡単なリンク・リストを用いて実施される。しかしながら、本発明の他の実施例においては、メンバ・データベース３１４の異なる実施例を、本発明の精神及び範囲を維持しながら、使用し得ることがわかる。１つの例として、データベースのＬＤＡＰの種類のものを、メンバ情報を記憶するのに、用い得る。
【００２９】
次に、本発明の例示的実施例による、図３のデータベース・エンティティ３０２に含まれるアクティブ・セッション・データベース３１２の説明をする。アクティブ・セッション・データベース３１２は現在行われているテレビ会議セッション毎の情報を含む。例として、以下の情報：コールＩＤ（識別子）；記述；マルチキャスト（はい／いいえ）；マルチキャストの場合、マルチキャストＩＰアドレス；参加者毎に、ネットワーク場所、現行送信解像度、現行送信ビットレート、ビデオ及びオーディオ・コデック；パブリック／プライベート・コール（他が参加可能か？）；セッションのスケジュール時間；セッションの開始時間；及び如何なる他のオプションをも、アクティブ・セッション・データベース３１２においてコール毎に保持し得る。上記の項目は単に例示的なものであるので、上記の項目の一部又は全部に加えた他の項目又は上記の項目の一部又は全部の代わりの他の項目を、本発明の精神及び範囲を維持しながら、保持し得る。
【００３０】
図５は本発明の例示的実施例による、図３のデータベース・エンティティ３０２に含まれるアクティブ・セッション・データベース３１２におけるアクティブ・セッション・エントリ５００を示す構成図である。図５の例示的実施例においては、アクティブ・セッション・データベース３１２は簡単なリンク・リストを用いて実施される。しかしながら、本発明の別の実施例においては、アクティブ・セッション・データベース３１２の異なる実施例を、本発明の精神及び範囲を維持しながら、使用し得る。
【００３１】
もう一度図３を用いて、本発明の例示的実施例による、図３のデータベース・エンティティ３０２に含まれるネットワーク・アーキテクチャ・データベース３１６を説明する。ネットワーク・アーキテクチャ・データベース３１６は全体のネットワークを完全にマッピングしたものを含む。ネットワーク・アーキテクチャ・データベース３１６はアクティブなネットワーク構成部分（すなわち、ＩＰルータ、イーサネット（登録商標）スイッチなど）毎の情報及びルータ並びにスイッチをお互いに接続するリンクの情報を含む。ネットワークにおける帯域及びサービス品質を効果的に管理するよう、テレビ会議サーバ２０５はこの情報を知る必要がある。
【００３２】
同時に行うことが可能なテレビ会議セッションの数、テレビ会議セッションのビットレート、及び帯域制限もネットワーク・アーキテクチャ・データベース３１６において規定し得る。ネットワーク・アーキテクチャはネットワーク・アーキテクチャ・データベース３１６内部で加重グラフとして表し得る。ネットワーク・アーキテクチャ・データベース３１６はテレビ会議サーバ２０５におけるオプションのデータベースであることがわかる。ネットワーク・アーキテクチャ・データベース３１６はポリシー・サーバ２１０から要求されたポリシーをキャッシュするのに用い得る。
【００３３】
次に、本発明の例示的実施例による、図３のデータベース・エンティティ３０２に含まれるスケジューリング・データベース３１０を説明する。スケジューリング・データベース３１０はユーザがテレビ会議システムを用いる時間を予約するよう、スケジュールを有する。これは、例えば、ワイド・エリア・ネットワーク２５０上の特定のリンクで同時に起こり得るテレビ会議セッションの数に関して情報システム部が機能させているポリシーによって左右される。
【００３４】
次に、図３のネットワーク通信エンティティ３０４について説明する。ネットワーク通信エンティティ３０４は：シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モジュール３０４ａ；軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クライアント・モジュール３０４ｂ；マルチキャスト・アドレス動的クライアント割り当てプロトコル（ＭＡＤＣＡＰ）クライアント・モジュール３０４ｃ；セッション開始プロトコル（ＳＩＰ）モジュール３０４ｄ；及びサーバ間管理モジュール３０４ｅ；を含む。
【００３５】
次に、本発明の例示的実施例による、図３のネットワーク通信エンティティ３０４に含まれるシンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モジュール３０４ａを説明する。図６は本発明の例示的実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント・サーバ・アーキテクチャ６００を示す構成図である。アーキテクチャ６００はＳＮＭＰモジュール３０４ａの一実施例を表す；しかしながら、本発明は図６に表すアーキテクチャに限定されないものであるので、別のＳＮＭＰアーキテクチャを、本発明の精神及び範囲を維持しながら、使用し得ることがわかる。ＳＮＭＰはテレビ会議サーバの遠隔管理及び監視に用いられる。
【００３６】
シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント・サーバ・アーキテクチャ６００はＳＮＭＰ管理ステーション６１０及びＳＮＭＰ管理エンティティ６２０を含む。ＳＮＭＰ管理ステーション６１０は管理アプリケーション６１０ａ及びＳＮＭＰマネージャ６１０ｂを含む。ＳＮＭＰ管理エンティティ６２０は管理リソース６２０ａ、ＳＮＭＰ管理オブジェクト６２０ｂ、及びＳＮＭＰエージェント６２０ｃを含む。更に、ＳＮＭＰ管理ステーション６１０及びＳＮＭＰ管理エンティティ６２０は更に、ＵＤＰ層６３０、ＩＰ層６４０、媒体アクセス制御（ＭＡＣ）層６５０、及び物理層６６０を含む。
【００３７】
ＳＮＭＰエージェント６２０ｃによってＳＮＭＰ管理ステーション６１０からの監視及び管理が可能になる。ＳＮＭＰエージェント６２０ｃはＳＮＭＰアーキテクチャ６００におけるクライアントである。ＳＮＭＰエージェント６２０ｃは基本的に、ＳＮＭＰ管理ステーション６１０からの情報及び動作に対する要求に対して応答する役目を担う。ＳＮＭＰ管理ステーション６１０はＳＮＭＰアーキテクチャ６００におけるサーバである。ＳＮＭＰ管理ステーション６１０はネットワークにおけるエージェントを管理する中心エンティティである。ＳＮＭＰ管理ステーション６１０は管理者がＳＮＭＰエージェント６２０ｃから統計を収集してＳＮＭＰエージェント６２０ｃの構成パラメータを変更する役目を担う。
【００３８】
ＳＮＭＰモデルを用いて、テレビ会議サーバ２０５におけるリソースはこれらのリソースをオブジェクトとして表すことによって管理し得る。各オブジェクトは管理エージェントの一特徴を表すデータ変数である。オブジェクトの集まりを通常、管理情報ベース（ＭＩＢ）と呼ぶ。ＭＩＢはＳＮＭＰ管理ステーション６１０に対するＳＮＭＰエージェント６２０ｃでのアクセス・ポイントの集まりとしての役目を果たす。ＳＮＭＰ管理ステーション６１０はＳＮＭＰエージェント６２０ｃにおけるＭＩＢオブジェクトの値を取り出すことによって監視を行うことができる。ＳＮＭＰ管理ステーション６１０は更に、ＳＮＭＰエージェント６２０ｃで動作を行わせることができるか、ＳＮＭＰエージェント６２０ｃでの構成設定を変更し得る。
【００３９】
ＳＮＭＰはＩＰ層６４０上で動作してそのトランスポート・プロトコルにＵＤＰ層６３０を用いる。
【００４０】
ＳＮＭＰ管理プロトコルにおいて用いられる基本メッセージは以下の：ＧＥＴ、ＳＥＴ；及びＴＲＡＰ；である。ＧＥＴメッセージによってＳＮＭＰ管理ステーション６１０がＳＮＭＰエージェント６２０ｃでオブジェクトの値を取り出すことを可能にする。ＳＥＴメッセージはＳＮＭＰ管理ステーション６１０がＳＮＭＰエージェント６２０ｃでオブジェクトの値を設定することを可能にする。ＴＲＡＰメッセージはＳＮＭＰエージェント６２０ｃが重大なイベントをＳＮＭＰ管理ステーション６１０に通知することを可能にする。
【００４１】
次に、本発明の例示的実施例による、ＳＮＭＰ管理エンティティ６２０に含まれるＳＮＭＰ管理リソース６２０ａを説明する。遠隔管理はテレビ会議サーバ２０５内部で以下のリソース：アクティブ・セッション及び関連する統計；セッション・ログ；ビデオ会議用ネットワーク・ポリシー；セッション開始プロトコル（ＳＩＰ）パラメータ及び統計；及びＭＡＤＣＡＰパラメータ及び統計；を監視及び／又は制御し得る。
【００４２】
ＳＮＭＰ管理ステーション６１０から、以下の３つの種類のＳＮＭＰメッセージ：ＧｅｔＲｅｑｕｅｓｔ；ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ；及びＳｅｔＲｅｑｕｅｓｔ；が管理アプリケーションのために送出される。最初の２つはＧＥＴファンクションの変形である。３つのメッセージは全てＳＮＭＰエージェント６２０ｃによってＧｅｔＲｅｓｐｏｎｓｅメッセージの形態で受信確認されて、それは管理アプリケーション６１０ａまで渡される。ＳＮＭＰエージェント６２０ｃは更に、管理リソースにおいて発生したイベントに応じてトラップ・メッセージを送出し得る。
【００４３】
もう一度図３を用いて、次に、本発明の例示的実施例による、図３のネットワーク通信エンティティ３０４に含まれる軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クライアント・モジュール３０４ｂを説明する。ＬＤＡＰモジュール３０４ｂは共通ディレクトリ情報をアクセスする標準的なＩＰベースのプロトコルである。ＬＤＡＰは：ユーザ特有基準を満たすエントリをサーチする；エントリを追加する；エントリを削除する；エントリを修正する；及びエントリを比較する；ようなディレクトリ・エントリをアクセスして修正する動作を規定する。
【００４４】
次に、本発明の例示的実施例による、図３のネットワーク通信エンティティに含まれるマルチキャスト・アドレス動的クライアント割り当てプロトコル（ＭＡＤＣＡＰ）クライアント・モジュール３０４ｃを説明する。ＭＡＤＣＡＰモジュール３０４ｃは、ホストがマルチキャスト・アドレス割り当てサーバからマルチキャスト・アドレス割り当てサービスを要求することを可能にするプロトコルである、ＭＡＤＣＡＰを利用する。ビデオ会議セッションがマルチキャスティング・サービスを用いるよう設定される場合、テレビ会議サーバ２０５はセッションにおけるクライアントに対して割り当てるマルチキャスト・アドレスを取得する必要がある。テレビ会議サーバ２０５は動的にマルチキャスト・アドレスを、マルチキャスト・アドレス割り当てサーバからＭＡＤＣＡＰプロトコルを用いて、取得し得る。
【００４５】
次に、本発明の例示的実施例による、図３のネットワーク通信エンティティ３０４に含まれるセッション開始プロトコル（ＳＩＰ）モジュール３０４ｄを説明する。ＳＩＰモジュール３０４ｄは、ＩＰベースのネットワーク上での１つ以上の参加者とのマルチメディア・セッションの生成、修正及び終了を行うアプリケーション層制御プロトコルである、ＳＩＰを利用する。ＳＩＰはテキスト・メッセージ・ベースのプロトコルである。
【００４６】
ＳＩＰベースのテレビ会議システムにおいては、各クライアント及びサーバはＳＩＰ  ＵＲＬ（ユニフォーム・リソース・ロケータ）によって識別される。ＳＩＰ  ＵＲＬはｕｓｅｒ＠ｈｏｓｔの形式をとり、それは電子メール・アドレスと同様なフォーマットで、ほとんどの場合、ＳＩＰ  ＵＲＬはユーザの電子メール・アドレスにある。
【００４７】
次に、本発明の例示的実施例による、図３のネットワーク通信エンティティ３０４に含まれるサーバ間管理モジュール３０４ｅを説明する。サーバ間モジュール３０４ｅはテレビ会議サーバ間で情報を交換するメッセージを利用する。サーバ間管理モジュール３０４ｅは、一意のテレビ会議サーバ（例えば、テレビ会議サーバ２０５）が、それがサポートするネットワーク（例えば、ＬＡＮ２２５）に対して局所的に設定されるので、いくつかのテレビ会議サーバが全社的ネットワーク（例えば、ネットワーク２００）に存在し得る、典型的な配置において利用されるのが好適である。情報を交換するメッセージの主要目的のいくつかはデータベースを同期化することとネットワーク・リソースの利用可能性を確かめることとを含む。
【００４８】
次に、以下のメッセージ：ＱＵＥＲＹ―遠隔サーバにおけるエントリを問い合わせる；ＡＤＤ―遠隔サーバに対してエントリを追加する；ＤＥＬＥＴＥ―遠隔サーバからエントリを削除する；及びＵＰＤＡＴＥ−遠隔サーバ上のエントリを更新する；を定義する。
【００４９】
サーバ間メッセージングは各サーバ間でのＴＣＰベースの接続を用い得る。１つのサーバのステータスが変わる場合、残りのサーバは同様な情報によって更新される。
【００５０】
次に、本発明の例示的実施例による、テレビ会議サーバ２０５の動作シナリオを説明する。当初、テレビ会議セッションの設定に相当する動作シナリオの説明、続いて、テレビ会議セッション中の解像度及びフレーム・レート調整に相当する動作シナリオの説明、を設ける。セッション動作シナリオはＳＩＰサーバ・ディスカバリ、メンバ登録、セッション設定、セッション取り消し、及びセッション終了を含む。
【００５１】
次に、本発明の例示的実施例による、ＳＩＰサーバ・ディスカバリに相当するセッション動作シナリオを説明する。ユーザ（テレビ会議クライアント・アプリケーション）は（手作業でプロビジョニングされた）あらかじめ構成されたテレビ会議サーバに、又は、起動時に、周知の「全てのＳＩＰサーバ」マルチキャスト・アドレス「ｓｉｐ．ｍｃａｓｔ．ｎｅｔ」（２２４．０．１．７５）に対してＲＥＧＩＳＴＥＲ要求を送信することによって、登録し得る。第２のメカニズム（ＲＥＧＩＳＴＥＲ要求）が好適であるがそれは各ユーザが手作業でテレビ会議クライアント・アプリケーションにおける局所ＳＩＰサーバのアドレスを構成する必要がないからである。この場合、マルチキャスト・アドレスは、ユーザがテレビ会議用の正しいＳＩＰサーバに対して登録していることを徹底するようネットワークにおいてマルチキャスト・アドレスを正しく範囲設定する必要がある。上記の方法に加えて、プロビジョンニング処理を簡素化させる別の方法においては、ＳＩＰ仕様は管理者がＳＩＰサーバをｓｉｐ．ｄｏｍａｉｎｎａｍｅ規則（例えば、ｓｉｐ．ｐｒｉｎｃｅｔｏｎ．ｔｃｅ．ｃｏｍ）を用いて命名することを推奨する。
【００５２】
次に、本発明の例示的実施例による、メンバ登録に相当するセッション動作シナリオを説明する。図７は、本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてテレビ会議セッションに対して登録する方法を示す図である。図７の例はテレビ会議クライアント・アプリケーション（クライアント）７０２及びテレビ会議サーバ（サーバ）２０５を含む。本明細書及び特許請求の範囲の原文における句「ｃｌｉｅｎｔ  ａｐｐｌｉｃａｔｉｏｎ」及び「ｃｌｉｅｎｔ」は交換できるよう用いられている。
【００５３】
メンバ登録機能においては、クライアント７０２はサーバ２０５に対してＳＩＰ  ＲＥＧＩＳＴＥＲ要求を送信する（工程７１０）。サーバ２０５はこのメッセージを受信してメンバ・データベース３１４においてクライアント７０２のＩＰアドレス及びＳＩＰ  ＵＲＬを記憶する。
【００５４】
ＲＥＧＩＳＴＥＲ要求はメッセージ本体を含み得るが、その使用は標準では規定されていない。メッセージ本体はサーバ２０５と登録するクライアント７０２の構成オプションに関する追加情報を含み得る。
【００５５】
サーバ２０５は２００ＯＫメッセージをクライアント７０２に返信することによって登録を受信確認する（工程７２０）。
【００５６】
次に、本発明の例示的実施例による、ユニキャスト及びマルチキャストのテレビ会議セッションを説明する。図１Ｂ及び１Ｃは各々、本発明の２つの例示的実施例による、ユニキャストのテレビ会議セッション及びマルチキャストのテレビ会議セッションを示す構成図である。図１Ｂ及び１Ｃの例はクライアント１  １３０、クライアント２  １３２、クライアント３  １３４、イーサネット（登録商標）スイッチ１３６、ＩＰルータ１３８、及びＩＰルータ１４０、及びＷＡＮ１４２を含む。
【００５７】
ユニキャストの例においては、一意のストリームが各クライアントから各々の他方のクライアントに送信される。そのようなアプローチによれば、更に多くの参加者がネットワークに参加するにつれて、多くの帯域を費やし得る。対照的に、マルチキャスト・アプローチにおいては、１つのストリームのみが各クライアントから送信される。したがって、マルチキャスト・アプローチはユニキャスト・アプローチと比較すると費やす、帯域のような、ネットワークのリソースは少なくなる。
【００５８】
次に、本発明の例示的実施例による、設定されるユニキャスト・テレビ会議セッションに相当するセッション動作シナリオを説明する。図８Ａは本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてユニキャスト・テレビ会議セッションを設定する方法を示す図である。図８Ａの例はテレビ会議クライアント・アプリケーション＃１（クライアント＃１）８０２、テレビ会議サーバ（サーバ）２０５及びテレビ会議クライアント・アプリケーション＃２（クライアント＃２）８０６を含む。
【００５９】
ＩＮＶＩＴＥ要求はクライアント＃１  ８０２からサーバ２０５に送信される（工程８１０）。ＩＮＶＩＴＥ要求はサーバ２０５からクライアント＃２  ８０６に対して転送される（工程８１５）。
【００６０】
１８０呼び出しメッセージがクライアント＃２  ７０６からサーバ２０５に対して送信される（工程８２０）。１８０呼び出しメッセージはサーバ２０５からクライアント＃１  ７０２に転送される（工程８２５）。
【００６１】
２００ＯＫメッセージはクライアント＃２  ７０６からサーバ２０５に対して送信される（工程８３０）。２００ＯＫメッセージはサーバ２０５からクライアント＃１７０２に対して転送される（工程８３５）。
【００６２】
受信要求メッセージＡＣＫがクライアント＃１  ７０２からクライアント＃２  ７０６に対して送信される（工程８４０）。テレビ会議セッション（メディア・セッション）は２つのノード（クライアント＃１  ８０２及び＃２  ８０６）間で行われる（工程８４５）。
【００６３】
図８Ｂは、本発明の例示的実施例による、ＩＮＶＩＴＥ要求がテレビ会議クライアント・アプリケーション＃１  ８０２から受信される場合（図８Ａの工程８１０）、テレビ会議サーバがたどる工程を示す図である。
【００６４】
サーバ２０５は当初、要求ユーザ（クライアント＃１  ８０２）がサーバ２０５に登録されているかを確かめて、更に、呼び出されているユーザ（クライアント＃２  ８０６）がサーバ２０５に登録されているかを確かめる（工程８５０）。
【００６５】
サーバ２０５はネットワーク上の各ユーザの場所を判定して（工程８５５）（場所が異なる場合）２つの場所を接続している低帯域ＷＡＮリンク（例えば、ＷＡＮ２５０）があるかを判定する（工程８６０）。
【００６６】
２つの場所をお互いに接続する低帯域リンクのＷＡＮがない場合には、サーバ２０５はコールを進める（工程８６５）。しかしながら、２つのユーザの間で低帯域リンクがある場合には、方法は工程８７０に進む。
【００６７】
工程８７０では、サーバ２０５がＷＡＮ２５０上のテレビ会議セッションについてのポリシーを確かめる；これは基本的には「Ｘセッションが最大ビットレートＹで行い得る」と言い換えられる。サーバ２０５はこのポリシーに基づいて利用可能性を確かめる（工程８７５）。利用可能性がない場合、サーバ２０５は以下の如何なるメッセージ：「６００−どこでも動作中」、「４８６−ここでは動作中」、「５０３−サービス利用不能」、又は「６０３−拒否」；を送信することによってもＩＮＶＩＴＥ要求が却下されて（工程８８０）、当該方法は（図８Ａの方法の工程８１５に続くことなく）終了する。しかしながら、利用可能性がある場合、サーバ２０５はコールを進める（工程８６５）。工程８６５は図８Ａの方法の工程８１５に続く。
【００６８】
図９は更に、本発明の例示的実施例による、図８Ａの方法を示す図である。図９の例はクライアント・アプリケーション１  ９９８、クライアント・アプリケーション２  ９９７、テレビ会議サーバ２０５、及び他のテレビ会議サーバ９８６を含む。図９にも表すテレビ会議サーバ２０５の構成部分はメンバ・データベース３１４、アクティブ・セッション・データベース３１２、ネットワーク・アーキテクチャ・データベース３１６に含まれるポリシー・データベース９９９、セッション・マネージャ３２０、ＳＩＰモジュール３０４ｄ、及びサーバ間管理モジュール３０４ｅを含む。
【００６９】
図９はテレビ会議サーバ２０５内部での相互作用を表すよう設けるものであるので、テレビ会議サーバ２０５のエンティティ間の通知フローの例を設けるよう基本レベルのみで表すものである。
【００７０】
ＩＮＶＩＴＥ要求はテレビ会議サーバ２０５内部でクライアント・アプリケーション１  ９９８からＳＩＰモジュール３０４ｄに対して送信される。ＳＩＰモジュール３０４ｄはメッセージを復号化してＩＮＶＩＴＥ要求をセッション・マネージャ３２０に対して転送する（工程９０６）。セッション・マネージャ３２０は、セッションが正しく設定されることを徹底するよう、ネットワーク・アーキテクチャ・データベース３１６内部でアクティブ・セッション・データベース３１２、メンバ・データベース３１４、及びポリシー・データベース９９９を確かめる（各々、工程９０９、９１２、及び９１５）。セッションが正しく設定され得る場合、アクティブ・セッション・データベース３１２、メンバ・データベース３１４、及びポリシー・データベース９９９はＯＫメッセージをセッション・マネージャ３２０に対して送信する（工程９１８、９２１、及び９２４）。この検証処理が完了すると、テレビ会議サーバ２０５はシステム・ステータスにおける変更を他のビデオ会議サーバに通知する（工程９２７及び９３０）。セッション・マネージャ３２０はＩＮＶＩＴＥメッセージをＳＩＰモジュール３０４ｄに転送して（工程９３３）更にＩＮＶＩＴＥメッセージをクライアント２  ９９７に転送する（工程９３６）。ＩＮＶＩＴＥメッセージを受信すると、クライアント・アプリケーション２  ９９７はＳＩＰモジュール３０４ｄがＩＮＶＩＴＥメッセージを受信したことを示す１８０呼び出しメッセージによってＳＩＰモジュール３０４ｄに応答する（工程９３９）。１８０呼び出しメッセージはＳＩＰモジュール３０４ｄによって受信され、復号化されて更にセッション・マネージャ３２０に転送される（工程９４２）。クライアントのステータスが更新される（工程９４５、９４８，９５１、９５４、９５７、及び９５８）が、それはテレビ会議サーバ２０５内部の図９に表すデータベース各々においてである。
【００７１】
１８０呼び出しメッセージはセッション・マネージャ３２０からクライアント・アプリケーション１  ９９８に転送される（工程９６０及び９６３）。２００ＯＫメッセージは更に、クライアント・アプリケーション２  ９９７からＳＩＰモジュール３０４ｄに送信されて（工程９６６）ＳＩＰモジュール３０４ｄからセッション・マネージャ３２０に転送される（工程９６９）。２００ＯＫメッセージはクライアント・アプリケーション２  ９９７がテレビ会議セッションに対するインビテーションを受理することを示す。
【００７２】
クライアントのステータスがテレビ会議サーバ２０５内部の図９に表すデータベース各々において更新される（工程９７２、９７５、９７８、９８１、９８４、及び９８５）。ＯＫメッセージがセッション・マネージャ３２０からＳＩＰモジュール３０４ｄに送信されてＳＩＰモジュール３０４ｄからクライアント・アプリケーション１  ９９８に転送される（工程９８８及び９９１）。ＡＣＫメッセージがクライアント・アプリケーション１  ９９８からセッション設定を完了するクライアント・アプリケーション２  ９８７に送信される（工程９９４）。
【００７３】
次に、本発明の例示的実施例による、マルチキャスト・テレビ会議セッション設定に相当するセッション動作シナリオを説明する。マルチキャスト・セッション設定を設けるよう、セッション記述プロトコル（ＳＤＰ）が用いられる。ＳＤＰプロトコルはマルチキャスト・アドレス及びポート番号を伝達することができる。
【００７４】
マルチキャスト・セッション設定は、マルチキャスト・アドレスを必要とする以外は、ユニキャスト・セッション設定と類似したものである。マルチキャスト・アドレスはネットワークにおけるＭＡＤＣＡＰサーバ２１５によって割り当てられる。
【００７５】
図１０は本発明の別の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてマルチキャスト・テレビ会議セッションを設定する方法を示す図である。図１０の例はテレビ会議クライアント・アプリケーション＃１（クライアント＃１）１００２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）１００６及びＭＡＤＣＡＰサーバ２１５を含む。
【００７６】
ＩＮＶＩＴＥ要求はクライアント＃１  １００２からサーバ２０５に送信される（工程１０１０）。ＭＡＤＣＡＰ要求はサーバ２０５からＭＡＤＣＡＰサーバ２１５に送信される（工程１０１５）。受信確認メッセージＡＣＫはＭＡＤＣＡＰサーバ２１５からサーバ２０５に送信される（工程１０２０）。ＩＮＶＩＴＥ要求はサーバ２０５からクライアント＃２  １００６に転送される（工程１０２５）。
【００７７】
１８０呼び出し・メッセージがクライアント＃２  １００６からサーバ２０５に送信される（工程１０３０）。１８０呼び出しメッセージがサーバ２０５からクライアント＃１  １００２に転送される（工程１０３５）。
【００７８】
２００ＯＫメッセージがクライアント＃２  １００６からサーバ２０５に送信される（工程１０４０）。２００ＯＫメッセージがサーバ２０５からクライアント＃１  １００２に転送される（工程１０４５）。
【００７９】
受信確認メッセージＡＣＫがクライアント＃１  １００２からクライアント＃２  １００６に送信される（工程１０５０）。テレビ会議セッション（メディア・セッション）は２つのノード（クライアント＃１  １００２及びクライアント＃２  １００６）の間で行われる（工程１０５５）。
【００８０】
次に、本発明の例示的実施例による、テレビ会議セッションの取り消しに相当するセッション動作シナリオを説明する。ＣＡＮＣＥＬメッセージは一時停止セッション設定試行を終了するのに用いられる。クライアントは、クライアントが以前に開始した一時停止テレビ会議セッション設定試行を取り消すよう、このメッセージを用い得る。サーバはＩＮＶＩＴＥが送信された一時停止要求と同じ場所に対してＣＡＮＣＥＬメッセージを転送する。クライアントは「２００ＯＫ」メッセージによってＣＡＮＣＥＬメッセージに対して応答すべきでない。ＣＡＮＣＥＬメッセージが正常でない場合、セッション終了シーケンス（例えば、ＢＹＥメッセージ）を用い得る。
【００８１】
図１１は本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてテレビ会議セッションを取り消す方法を示す図である。図１１の例はテレビ会議クライアント・アプリケーション＃１（クライアント＃１）１１０２、テレビ会議サーバ（サーバ）２０５、及びテレビ会議クライアント＃２（クライアント＃２）１１０６を含む。
【００８２】
ＩＮＶＩＴＥ要求がクライアント＃１  １１０２からサーバ２０５に送信される（工程１１１０）。ＩＮＶＩＴＥ要求がサーバ２０５からクライアント＃２  １１０６に転送される（工程１１１５）。
【００８３】
１８０呼び出しメッセージがクライアント＃２  １１０６からサーバ２０５に送信される（工程１１２０）。１８０呼び出しメッセージがサーバ２０５からクライアント＃２  １１０２に転送される（工程１１２５）。
【００８４】
ＣＡＮＣＥＬメッセージがクライアント＃１  １１０２からサーバ２０５に送信される（工程１１３０）。ＣＡＮＣＥＬメッセージがサーバ２０５からクライアント＃２  １１０６に転送される（工程１１３５）。
【００８５】
次に、本発明の例示的実施例による、テレビ会議セッションの終了に相当するセッション動作シナリオを説明する。図１２は本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いて２つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１２の例は第１クライアント（テレビ会議クライアント・アプリケーション＃１）１２０２、テレビ会議サーバ（サーバ）２０５、及び第２クライアント（テレビ会議クライアント・アプリケーション＃２）１２０６を示す。
【００８６】
クライアント＃１  １２０２はクライアント＃２  １２０６とのコールを停止することを決定する。したがって、クライアント＃１  １２０２はＢＹＥメッセージをサーバ２０５に送信する（工程１２１０）。サーバ２０５はＢＹＥメッセージをクライアント＃２  １２０６に転送する（工程１２２０）。
【００８７】
クライアント＃２  １２０６は、クライアント＃２  １２０６が停止したことを示す２００ＯＫメッセージをサーバ２０５に返信する（工程１２３０）。サーバ２０５はクライアント＃１  １２０２に対して停止が正常であることを示す２００ＯＫメッセージを転送する（工程１２４０）。
【００８８】
図１３は本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いて３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１３の例は第１クライアント（テレビ会議クライアント・アプリケーション＃１）１３０２、テレビ会議サーバ（サーバ）２０５、第２クライアント（テレビ会議クライアント・アプリケーション＃２）１３０６、及び第３クライアント（テレビ会議クライアント・アプリケーション＃３）１３０８を含む。
【００８９】
クライアント＃１  １３０２はクライアント＃２  １３０６及びクライアント＃３  １３０８とのコールを停止することを決定する；これはクライアント＃２  １３０６とクライアント＃３  １３０８との間のセッションをティア・ダウンするものでない。
【００９０】
クライアント＃１  １３０２はＢＹＥメッセージをサーバ２０５に送信する（工程１３１０）。サーバ２０５はＢＹＥメッセージを解釈してクライアント＃２  １３０６及びクライアント＃３  １３０８がクライアント＃１  １３０２とのテレビ会議セッションに関与していることがわかってＢＹＥメッセージをクライアント＃２  １３０６とクライアント＃３  １３０８との両方に転送する（工程１３２０及び１３３０）。
【００９１】
クライアント＃２  １３０６はサーバ２０５に２００ＯＫメッセージを返信する（工程１３４０）。サーバ２０５は２００ＯＫメッセージをクライアント＃１  １３０２まで転送し戻す（工程１３５０）。クライアント＃３  １３０８は２００ＯＫメッセージをサーバ２０５に返信する。サーバ２０５は２００ＯＫメッセージをクライアント＃１  １３０２に転送し戻す。
【００９２】
図１４は、本発明の別の例示的実施例によって、セッション開始プロトコル（ＳＩＰ）を用いて３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１４の例は第１クライアント（テレビ会議クライアント・アプリケーション＃１）１４０２、テレビ会議サーバ（サーバ）２０５、第２クライアント（テレビ会議クライアント・アプリケーション＃２）１４０６、及び第３クライアント（テレビ会議クライアント・アプリケーション＃３）１４０６を含む。
【００９３】
クライアント＃１  １４０２はクライアント＃２  １４０６及びクライアント＃３  １４０６とのコールを停止することを決定する；これはクライアント＃２  １４０６とクライアント＃３  １４０６との間のセッションをティア・ダウンするものでない。
【００９４】
クライアント＃１  １４０２はクライアント＃２  １４０６向けを企図したＢＹＥメッセージをサーバ２０５に送信する（工程１４１０）。サーバ２０５はＢＹＥメッセージをクライアント＃２  １４０６に転送する（１４２０）。クライアント＃１  １４０２はクライアント＃３  １４０６向けを企図したＢＹＥメッセージをサーバ２０５に送信する。サーバ２０５はＢＹＥメッセージをクライアント＃３  １４０６に転送する（工程１４４０）。
【００９５】
クライアント＃２  １４０６は２００ＯＫメッセージをサーバ２０５に返信する（工程１４５０）。サーバ２０５は２００ＯＫメッセージをクライアント＃１  １４０２に転送し戻す（工程１４６０）。クライアント＃３  １４０８は２００ＯＫメッセージをサーバ２０５に返信する（工程１４７０）。サーバ２０５は２００ＯＫメッセージをクライアント＃１  １４０２に転送し戻す（工程１４８０）。
【００９６】
図１２乃至１４による上記の例に加えて、終了は、テレビ会議加入者が関係するマルチキャスト・グループ・アドレスに対してＢＹＥメッセージを送信することによって起動し得る。この方法を用いて、サーバ及び他のクライアント・アプリケーションはメッセージを受信する。これは関連するオーバヘッドの量が少ないため、セッションを終了する更に普遍的で効率的なメカニズムである。
【００９７】
次に、本発明の例示的実施例による、解像度及びフレーム・レート調整に相当する動作シナリオを説明する。テレビ会議はコンピュータ・ネットワーク上の異なる場所にいる数ユーザ間での生の、双方向対話型映像を送信することに関係する。リアル・タイム対話型映像は制約遅延を伴った情報を大量に送信することを必要とする。これによってテレビ会議システムが接続されるコンピュータ・ネットワークはセッションに関与するユーザ毎に十分な帯域及びサービス品質を設けなければならないことを必要とする。帯域はたまに、制限リソースになり得てサービス品質は常に全てのネットワークにおいて保証し得ないので、制約がいくらか存在する。私設企業ネットワークにおいては、サービス品質を保証することが考えられるが、大量の帯域を保証することが常に可能なわけではない。
【００９８】
基本企業コンピュータ・ネットワーク・インフラストラクチャは低速リンクを通じてお互いに接続された、いくつかの高速ローカル・エリア・ネットワーク（ＬＡＮ）を含む（例えば、図２参照。）。高速ＬＡＮ各々は通常、単一の地理的場所でのネットワーク・インフラストラクチャを表して低速リンクは複数の物理的場所をお互いに接続する長距離リンクである。低速リンクが用いられるのは、長距離リンクのコストが比較的高くて更にネットワーク・トラフィックのほとんどがローカル・エリア・ネットワーク内部で局所化されているので、大量のデータは通常、これらの長距離リンク上で交換されることがないからである。
【００９９】
ＩＰベースのネットワーク上のサービス品質における昨今の発展によって、今日では、他の種類の情報がこれらのネットワークを越えて送信されることを可能にする手段を設けている。これは非リアル・タイム・データ・トラフィックに加えてリアル・タイム情報（すなわち、オーディオ及び映像）を、インフラストラクチャを越えて、送信することを可能にする。ネットワークのサービス品質を利用するテレビ会議サービスはこのインフラストラクチャにオーバレイするのに良く適している。更に、リアル・タイムのテレビ会議セッションにおいて２ユーザが２つの異なる物理的場所にいることが考えられる。テレビ会議セッションの１つの欠点にはリアル・タイム映像を伝送することによって極めて大量の帯域を費やして容易に、利用可能なネットワークを使い果たすことがあり得る。ネットワークを越えて伝送されるリアル・タイム映像のビットレートは主に、用いられる映像解像度及び圧縮アルゴリズムに左右される。一般に、異なる地理的場所での２、３、又は４ユーザ間の一テレビ会議セッションは適量の帯域のあるネットワーク上でサポートし得る。しかしながら、一般に、テレビ会議セッションにおける４を超える数の追加ユーザはサポートし得ないし、帯域の制約が理由で第２のテレビ会議セッションもサポートし得ない。テレビ会議システムの制限要因は地理的場所間の低速長距離リンクである。
【０１００】
１つの考えられる解決策は当該システムにおいて更に多くのユーザをサポートするよう２つの地理的場所間での長距離リンクの帯域を増やすことである。第２の解決策はテレビ会議セッションにおける限定数のユーザ（すなわち、アクティブ・ユーザ）のみが高解像度及び高ビットレートで伝送することが可能で、セッションにおける残りのユーザ（すなわち、パッシブ・ユーザ）は限定ビットレート及び限定解像度でしか伝送し得ない、システムを有することである。テレビ会議セッション運営者はどのユーザが高解像度で伝送してどのユーザが低解像度で伝送するかを左右する。ユーザが能動的に話したり対話したりしていなければ、映像を高解像度で送信する必要はない。そのようなアプローチは帯域における多大な節減を設け得る。
【０１０１】
次に図１８Ａのテレビ会議クライアント・アプリケーション１８００による、このアプローチは、テレビ会議クライアント・アプリケーション１８００における、種々のウィンドウ・サイズ（すなわち、高解像度及び低解像度復号化映像ストリームを表す異なるサイズの表示ウィンドウ）をサポートする、ユーザ・インタフェース１８０８及びサーバ２０５と他のクライアントのアプリケーションとの間の通信を規定する（図１８Ａのテレビ会議クライアント・アプリケーション１８００に含まれたネットワーク・エンティティ１８０６に含まれた）メッセージング・システム１８４２を有することに関係する。メッセージング・システム１８４２はクライアントのアプリケーションの各々の符号化解像度及び送信ビットレートを制御するメッセージを含む。
【０１０２】
次に、本発明の例示的実施例による、解像度及びフレーム・レート調整に相当するメッセージについて説明する。特に、ＭＳＧ＿ＷＩＮＤＯＷＳ（登録商標）＿ＳＷＩＴＣＨメッセージ及びＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージを説明する。
【０１０３】
アクティブ・ユーザとパッシブ・ユーザとの間の切り替えを示す、ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージはクライアントからサーバに送信される；すなわち、アクティブ・ユーザはパッシブになって、パッシブ・ユーザはアクティブになる。テレビ会議サーバはこの要求をクライアントと受信確認する。
【０１０４】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージはサーバから各クライアントに送信される。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージはクライアントがどの解像度（すなわち、ＣＩＦ（共通中間フォーマット）又はＱＣＩＦ（４分の１共通中間フォーマット）及びフレーム・レートで送信すべきかをクライアントに対して示す。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは各クライアントによって受信確認される。
【０１０５】
図１５は本発明の例示的実施例による、解像度及びフレーム・レート調整の通知方法を示す図である。図１５の例はテレビ会議サーバ（サーバ）２０５、クライアント１  １５０４、クライアント２  １５０６、クライアント３  １５０８、及びクライアント４  １５１０を含む。
【０１０６】
ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージはクライアント１  １５０４からサーバ２０５に送信される（工程１５２０）。受信確認メッセージＡＣＫがサーバ２０５からクライアント１  １５０４に送信される（工程１５２５）。
【０１０７】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（低）メッセージはサーバ２０５からクライアント１  １５０４に送信される（工程１５３０）。受信確認メッセージＡＣＫがクライアント１  １５０４からサーバ２０５に送信される（工程１５３５）。
【０１０８】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（高）メッセージがサーバ２０５からクライアント２  １５０６に送信される（工程１５４０）。受信確認メッセージＡＣＫがクライアント２  １５０６からサーバ２０５に送信される（工程１５４５）。
【０１０９】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（低）メッセージがサーバ２０５からクライアント３  １５０８に送信される（工程１５５０）。受信確認メッセージＡＣＫがクライアント３  １５０８からサーバ２０５に送信される（工程１５５５）。
【０１１０】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（低）メッセージがサーバ２０５からクライアント４  １５１０に送信される（工程１５６０）。受信確認メッセージＡＣＫがクライアント４  １５１０からサーバ２０５に送信される（工程１５６５）。
【０１１１】
図１６は、本発明の例示的実施例による、解像度及びフレーム・レート調整前の通知（クライアント２及び３）を示す図である。図１７は、本発明の例示的実施例による、解像度及びフレーム・レート調整後の通知（クライアント２及び３）を示す図である。図１６及び１７の例はクライアント１  １６０２、クライアント２  １６０４、ネットワーク・ルータ１６０６、クライアント３  １６０８、及びクライアント４  １６１０を含む。
【０１１２】
「低ビットレート／解像度での送信」メッセージはクライアント１  １６０２からネットワーク・ルータ１６０６に送信される（工程１６２０）。「高ビットレート／解像度での送信」メッセージはクライアント３  １６０８からネットワーク・ルータ１６０６に送信される（工程１６２５）。「低ビットレート／解像度での送信」メッセージはクライアント２  １６０４からネットワーク・ルータ１６０６に送信される（工程１６３０）。「高ビットレート／解像度での送信」メッセージはクライアント４  １６１０からネットワーク・ルータ１６０６に送信される（工程１６３５）。
【０１１３】
データはネットワーク・ルータ１６０６からクライアント２  １６０４、クライアント３  １６０８、クライアント１  １６０２、及びクライアント４  １６１０に、マルチキャスト・アドレスを用いて送信される（工程１６４０、１６４５、１６５０、及び１６５５各々）
図１７に進むと、「低ビットレート／解像度での送信」メッセージはクライアント１  １６０２からネットワーク・ルータ１６０６に送信される（工程１７２０）。「高ビットレート／解像度での送信」メッセージはクライアント３  １６０８からネットワーク・ルータ１６０６に送信される（工程１７２５）。「高ビットレート／解像度での送信」メッセージはクライアント２  １６０４からネットワーク・ルータ１６０６に送信される（工程１６３０）。「低ビットレート／解像度での送信」メッセージはクライアント４  １６１０からネットワーク・ルータ１６０６に送信される（工程１６３５）。
【０１１４】
データはネットワーク・ルータ１６０６からクライアント２  １６０４、クライアント３  １６０３、クライアント１  １６０２、及びクライアント４  １６１０に、マルチキャスト・アドレスを用いて送信される（工程１７４０、１７４５、１７５０、及び１７５５各々）
次に、本発明の例示的実施例による、クライアント・アプリケーション・アーキテクチャを説明する。クライアント・アプリケーションはユーザと相互作用し、マルチメディア・コンテンツを他のクライアント・アプリケーションと交換して、サーバ・アプリケーションとのコールを管理する役目を担う。更に、クライアント・アプリケーション自体がサーバ機能を含めることもできることがわかる。図１８Ａは本発明の例示的実施例による、テレビ会議クライアント・アプリケーション１８００の構成図である。テレビ会議クライアント・アプリケーション１８００はコンピュータ２００ａ乃至ｆの何れか及び／又はコンピュータ２３０ａ乃至ｃの何れかのようなコンピュータ上で見出し得る。
【０１１５】
テレビ会議クライアント・アプリケーション１８００は以下の４つの基本機能エンティティ：マルチメディア・インタフェース層１８０２；コデック１８０４（オーディオ・コデック１８０４ａ及びビデオ・コデック１８０４ｂ）；ネットワーク・エンティティ１８０６；及びユーザ・インタフェース１８０８；を含む。
【０１１６】
マルチメディア・インタフェース層１８０２はテレビ会議クライアント・アプリケーション１８００の主制御インスタンスである。全てのシステム内通信はマルチメディア・インタフェース層１８０２を通じて送られて該層によって制御される。マルチメディア・インタフェース層１８０２の基礎をなす重要な特徴は異なるオーディオ及びビデオ・コデック１８０４を容易に交換し得ることである。これに加えて、マルチメディア・インタフェース層１８０２はオペレーティング・システム（ＯＳ）依存ユーザ入出力エンティティ及びネットワーク・サブ・システムに対するインタフェースを設ける。マルチメディア・インタフェース層１８０２はメンバ・データベース１８２０、主制御モジュール１８２２、オーディオ・ミキサ１８９９、及びエコー・キャンセレーション・モジュール１８９８を含む。
【０１１７】
ユーザ・インタフェース１８０８はエンド・ユーザがテレビ会議クライアント・アプリケーションと相互作用するポイントを設ける。ユーザ・インタフェース１８０８はＯＳ依存モジュールとして実施されることが好適であるが、必ずしもそうでなくてよい。多くのグラフィカル・ユーザ・インタフェースは使用している特定のＯＳに左右される。ユーザ・インタフェース１８０８の４つの主要機能は映像キャプチャ、映像表示、オーディオ・キャプチャ、及びオーディオ再生である。ユーザ・インタフェース１８０８はオーディオ／映像キャプチャ・インタフェース１８３０、オーディオ／映像再生モジュール１８３２、メンバ・ビュー・モジュール１８３４、チャット・モジュール１８３６、及びユーザ選定／メニュー１８３８を有する。オーディオ／映像キャプチャ・インタフェース１８３０はカメラ・インタフェース１８３０ａ、マイクロフォン・インタフェース１８３０ｂ、及びファイル・インタフェース１８３０ｃを含む。オーディオ／映像再生モジュール１８３４は映像表示１８３２ａ、オーディオ再生モジュール１８３２ｂ、及びファイル・インタフェース１８３２ｃを含む。
【０１１８】
ネットワーク・エンティティ１８０６はテレビ会議クライアント・アプリケーション１８００の通信サブ・システムを表す。ネットワーク・エンティティ１８０６の役目はセッション開始プロトコル（ＳＩＰ）に基づいてクライアントからサーバにメッセージングしてオーディオ及び映像ストリームを送受信することにある。ネットワーク・エンティティ１８０６は更に、クライアント間でのメディア・ストリームの認証及び暗号化通信に関する基本的なセキュリティ機能も含む。ネットワーク・エンティティ１８０６はセキュリティ・モジュール１８４０、メッセージング・システム１８４２、映像ストリーム・モジュール１８４４、オーディオ・ストリーム・モジュール１８４６、及びＩＰソケット１８４８ａ乃至ｃを含む。
【０１１９】
オーディオ・コデック１８０４ａ及びビデオ・コデック１８０４ｂはディジタル・メディアの圧縮及び復元を扱うサブ・システムである。コデックに対するインタフェースはそれらの間の交換を容易にするよう簡単で汎用であるべきである。マルチメディア・インタフェース層１８０２とコデック１８０４との間の簡単な関係を以降、実施における例示的テンプレート又はガイドとして規定する。オーディオ・コデック１８０４ａ及びビデオ・コデック１８０４ｂは各々符号器１８８０及び復号器１８９０を含む。符号器１８８０及び復号器１８９０各々はキュー１８９５を含む。
【０１２０】
テレビ会議クライアント・アプリケーション１８００は、少なくとも、テレビ会議サーバ２０５及び他のクライアント１８７０とインタフェースする。
【０１２１】
次に、本発明の例示的実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれるメンバ・データベース１８２０を説明する。メンバ・データベース１８２０はセッション毎に各参加ユーザについての情報を記憶する。メンバ・データベース１８２０は送受信ＩＰアドレス、クライアント処理能力、特定のコデックについての情報、及びいろいろなユーザのステータスについての詳細を含む。上記の項目は単に例示的なものであるので、上記の項目の一部若しくは全部に加えた他の項目又は上記の項目の一部若しくは全部の代わりの他の項目を、本発明の精神及び範囲を維持しながら、メンバ・データベース１８２０に保持し得る。メンバ・データベース１８２０に含まれる情報はオーディオ及び映像復号器１８２０行きの着信情報を制御するのに用いられる。ネットワークから着信するメディア情報は正しいオーディオ及び映像復号器１８９０に送られる必要がある。同様に重要なことは、オーディオ及び映像符号器１８９０から来るメディア情報は配信するよう正しいユニキャスト又はマルチキャスト・アドレスに対して送られる必要がある。メンバ・データベース１８２０に含まれる基本情報は更に、エンド・ユーザがセッションにおける参加者及び処理能力について知っているようユーザ・インタフェース１８０８に送られる。ＩＮＶＩＴＥ要求がテレビ会議サーバ２０５から受信されると直ちに、ユーザがメンバ・データベース１８２０に追加されてＢＹＥ要求がテレビ会議サーバ２０５から受信されると直ちにユーザが取り除かれる。メンバ・データベース１８２０はセッションが終了すると消去される。
【０１２２】
次に、本発明の例示的実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれる主制御モジュール１８２２を説明する。
【０１２３】
主制御モジュール１８２２はマルチメディア・インタフェース層１８０２の非常に重要な部分である。主制御モジュール１８２２は中央管理サブ・システムとして役割を果たして以下の主要な機能：オーディオ及び映像復号器及び再生に関する同期化メカニズム；記録目的での復号器の行き先の画面又はファイルとの接続；及びアプリケーション層サービス品質；を設ける。
【０１２４】
オーディオ及び映像再生の同期化は最適なテレビ会議ユーザ経験にとって欠かすことができない。２つのメディア・ストリームを正確に同期化するよう、タイムスタンプを用いてメディア・コンテンツとともに送信する必要がある。リアル・タイム・プロトコル（ＲＴＰ）はこの目的でタイムスタンプ及び連番を含める汎用ヘッダを設ける。タイムスタンプは２つのネットワーク・ノード・クロックを同期化するよう企図されているものではないが、一致して再生するようオーディオ及び映像ストリームを同期化するよう企図されているものである。これらのタイムスタンプはキャプチャ時に同じノード上の共通クロックから導き出される必要がある。例えば、映像フレームがキャプチャされた場合、映像フレームがキャプチャされた時間を記録しなければならない。オーディオについても同様である。ＲＴＰを用いる詳細及び指針は更に、本明細書及び特許請求の範囲において別途、記載する。
【０１２５】
オーディオ及び映像を同期化する主制御モジュール１８２２の役目は（タイムスタンプ及び連番を含む）メタデータを適切に配信するようネットワーク・エンティティ１８０６及びコデック１８０４間の接続を行うことにある。パケットが遅延した場合、システムの現行の状態に応じて復号化前又は後に取り去り得る。ＲＴＰタイムスタンプはその後、表示及び再生タイムスタンプを生成するよう用い得る。
【０１２６】
主制御モジュール１８２２は更に、再生するよう画面に、記録するようファイルに、又は両方に、オーディオ及び映像復号器１８９０の出力を向ける役割を果たす。各復号器１８９０は無関係に扱われるので、例の場合において、１つの復号器の出力が画面に表示されて、第２復号器の出力がファイルにおいて記録されて、第３復号器からの出力が同時にファイル及び画面に達することを可能にする。
【０１２７】
上記の役割に加えて、主制御モジュール１８２２は更にアプリケーション層のサービス品質に関係する。主制御モジュール１８２２はパケット喪失、送受信バイトに関する情報を収集して、この情報に基づいて適宜、動作する。これはネットワークにおいて発生している状況を改善するのを助力するよう別のクライアント又はテレビ会議サーバ２０５に対するメッセージを送信することに関係し得る。リアル・タイム制御プロトコル（ＲＴＣＰ）は統計及びパケット喪失を通知するのに用い得、更にアプリケーション特有通知にも用い得る。
【０１２８】
図１８Ｂは、本発明の例示的実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれるオーディオ・ミキサ１８９９を更に示す構成図である。オーディオ・ミキサ１８９９はここでは「利得制御モジュール」とも呼ばれ、複数のオーディオ復号器１８９０に動作するよう結合される。複数のオーディオ復号器１８８０は圧縮オーディオ・ストリームを受信して非圧縮オーディオ・ストリームを出力する。非圧縮オーディオ・ストリームはオーディオ・ミキサ１８９９に入力されて合成オーディオ・ストリームとして出力される。
【０１２９】
図１８Ｃは本発明の例示的実施例による、更に、図１８Ａのマルチメディア・インタフェース・層１８０２に含まれるエコー・キャンセレーション・モジュールを示す図である。エコー・キャンセレーション・モジュール（更にここでは「エコー・キャンセラ」と呼ぶ）１８９８はスピーカ１８９７（例えば、オーディオ・プレイバック・モジュール１８３２ｂ）及びマイクロフォン１８９６（例えば、マイクロフォン・インタフェース１８３０ｂ）に動作するよう結合される。スピーカ１８９７からの音が全２重又は双方向通信システムにおいて生成される場合、局所のリスナからのみ聴かれることが企図されている。しかしながら、生成音は更に、局所マイクロフォン１８９６によって聴かれるので、信号が遠端に返信されることが可能になってエコーとして聴かれる。このために、テレビ会議クライアント・アプリケーション１８００はエコー・キャンセレーション・モジュール１８９８にこの効果を軽減することを要求するので、更に良いユーザ経験をもたらす。
【０１３０】
次に、本発明の例示的実施例による、テレビ会議クライアント・アプリケーション１８００のサブ・システムが利用可能なインタフェースを説明する。該インタフェースはユーザ・インタフェース１８０８、ネットワーク・エンティティ１８０６、及びコデック１８０４との相互作用のポイントを含む。ユーザ・インタフェース１８０８はキャプチャされたオーディオ及び映像を相当するタイムスタンプとともに受信する機能を設ける。これに加えて、表示して再生するようユーザ・インタフェース１８０８に対してオーディオ及び映像を送信する機能を設けなければならない。ネットワーク・エンティティ１８０６インタフェースはセッション制御及びセキュリティ用着信及び発信メッセージを通知する機能を設ける。オーディオ及びビデオ・コデック１８０４ａ，ｂは構成制御用基本インタフェースを設けるとともに、圧縮又は復元するようパケットを送信又は受信する。
【０１３１】
次に、本発明の例示的実施例による、オーディオ及びビデオ・コデック１８０４ａ、ｂを説明する。
【０１３２】
テレビ会議における使用に利用可能なオーディオ及びビデオ・コデック１８０４ａ、ｂはいくつかある。本発明によって使用されるコデックはソフトウェア・ベースのものであることが好適であるが、必ずしもそうでなくてよい。本発明の一例示的実施例によれば、典型的なデスクトップ・コンピュータの処理能力の制約が理由で、Ｈ．２６３が映像圧縮及び復元に用いられる。デスクトップ・コンピュータが将来更に強力になるにつれて、Ｈ．２６Ｌのような更に高度なコデックを用いることができることが実現し得て利用し得る。当然、本発明は上記の種類のコデックに限定されるものでなく、他の種類のコデックを、本発明の精神及び範囲を維持しながら、用い得る。
【０１３３】
次に、本発明の例示的実施例による、コデック１８０４ａ，ｂに対するインタフェースを説明する。該説明はＤａｔａＩｎファンクション、呼び戻し・ファンクション、及びコデックのオプションを包含する。コデック１８０４ａ，ｂに対するインタフェースは、コデックを相互に交換できることを可能にして将来において更に、新しいコデックを追加することを可能にするよう、十分柔軟で一般的に規定されているべきである。この柔軟で汎用的なインタフェースを実施する当該企図されたインタフェースはユーザに設けられるファンクションの数が限定された非常に簡単なインタフェースである。
【０１３４】
ＤａｔａＩｎファンクションは単に、符号器又は復号器クラスのフレーム又はパケットを記憶するのに用いられる。
【０１３５】
マルチメディア・インタフェース層１８０２とマルチメディア・コデック１８０４との間の簡単な接続を設けるよう、データ出力ファンクションは呼び戻しとして実施すべきである。マルチメディア・インタフェース層１８０２はこの呼び戻し・ファンクションを受信エンティティの入力ファンクションに設定する。例えば、コデックがフレームの符号化又は復号化を完了した場合、このファンクションが、符号化又は復号化処理からの企図された情報を配信するよう、コデックによってコールされる。コデックがこの呼び戻し中には何もできない制約が理由で、このファンクションはシステムにおける待ち及び不必要な遅延を防止してできるだけ速くリターンべきである。このファンクションにおいて行うべき追加の待ちはただ、共有リソースをアクセスする場合のミューテックスのロックである。
【０１３６】
利用可能なオプションの範囲はコデックの異なる種類によって変わってくる。これらのオプションを管理する要件を満たすよう、簡単なインタフェースを用いるべきである。テキスト・ベースのインタフェースが好適である（が必須ではない）がそれは設けられる柔軟性が理由である。ＳＴＡＲＴ及びＳＴＯＰのような共通のコマンド群、更には、コデック特有コマンドがあるべきである。この方法は簡単なインタフェースを設けるが、簡単なインタプリタを要するのでコデックに対して更に複雑性が付加される。例えば、オプション・ファンクションはオプションを読み書きするのに十分汎用であり得る：
例：  結果＝オプション（「開始」）；結果＝オプション（「解像度＝ＣＩＦ」）；例
例えば、コデック間の共通オプションのいくつかは以下：開始；停止；中断；品質指標（０−１００）；及び解像度；のように標準化すべきである。
【０１３７】
品質指標は０％と１００％との間の値としてコデックの全般的な品質を表す要素である。これは、値が高いほど映像品質が良いという前提に従うものである。
【０１３８】
図１９は本発明の例示的実施例による、オーディオ・コデック１８０４ａ及び／又は映像コデック１８０４ｂ何れかに含まれる復号器１８９０によって使用される方法を示す図である。該方法は復号器コンテキスト１９０１及び呼び出し側コンテキスト１９０２に関して説明する。該方法は少なくとも以下の入力及び出力：「データ入力」１９９９；「信号入力」１９９８；「信号出力呼び戻し」１９９７；「呼び戻しファンクション設定」１９９６；及び「データ出力呼び戻し」１９９５；を用いて動作する。入力「データ入力」１９９９は入力キューにデータを記憶するのに用いられる（工程１９０５）。
【０１３９】
初期化工程（Ｉｎｉｔ）は復号器１８９０を初期化するよう行われる（工程１９１０）。開始又は終了コマンドを待つ、主ループが実行される（工程１９２０）。終了コマンドが受信された場合、該方法は終了して（工程１９２２）リターンが、例えば、別の動作に対して、行われる（１９２４）。
【０１４０】
データが入力キュー１８９５から読み出されるか、入力キュー１８９５が空き状態の場合、待ち状態が課される（工程１９３０）。データは、工程１９３０で読み出された場合は、復号化される（工程１９４０）。「データ出力呼び戻し」１９９５は工程１９２０に設けられる。
【０１４１】
次に、本発明の例示的実施例による、ネットワーク２００によって使用される通信を説明する。該説明はネットワーク通信に関して上記に設けたものを補足する。
【０１４２】
（図１８Ａのネットワーク・エンティティ１８０６に含まれた）メッセージング・システム１８４２はテレビ会議クライアント・アプリケーション１８００とテレビ会議サーバ２０５との間のインタフェースを設ける。これはセッション管理（すなわち、セッション設定及びティア・ダウン）に用いられる。全ての通知メッセージはテレビ会議サーバ２０５を通じて、クライアントからクライアントに直接ではなく、通知される。マルチメディア・コンテンツ及びプラーベート・チャット・メッセージのようなデータはクライアント間で直接送信される唯一の情報を構成する。メッセージング・システムは標準ベースのセッション開始プロトコル（ＳＩＰ）を用いる。
【０１４３】
テレビ会議クライアント・アプリケーション１８００の機能を支配する異なるプロトコルはいくつかある。例えば、セッション開始プロトコル（ＳＩＰ）、リアル・タイム・プロトコル（ＲＴＰ）、リアル・タイム制御プロトコル（ＲＴＣＰ）、及びセッション記述プロトコル（ＳＤＰ）を使用し得る。
【０１４４】
セッション開始プロトコル（ＳＩＰ）の目的はセッション管理である。ＳＩＰはＩＰベース・ネットワーク上の一以上の参加者とのマルチメディア・セッションの生成、修正、及び終了を行うテキスト・ベースのアプリケーション層制御プロトコルである。ＳＩＰはこれを実現するようクライアントとサーバとの間で用いられる。ＳＩＰは更に、テレビ会議サーバ２０５に関して上記に説明されている。
【０１４５】
リアル・タイム・プロトコル（ＲＴＰ）はリアル・タイムのマルチメディア（すなわち、オーディオ及び映像）の伝送に用いられる。  ＲＴＰは伝達するマルチメディア情報の種類に関して更に詳細を設けるアプリケーション層プロトコルである。ＲＴＰはトランスポート層の上にあってユーザ・データグラム・プロトコル（ＵＤＰ）の上で伝達される。クライアント・アプリケーションにおけるＲＴＰの主要な役目は（オーディオ及び映像を同期化する）タイムスタンプ、連番、をトランスポートすること及びカプセル化するペイロードの種類（例えば、ＭＰＥＧ４、Ｈ．２６３、Ｇ．７２３など）を識別することにある。
【０１４６】
図２０は、本発明の例示的実施例による、ユーザ・プレーン・プロトコル・スタック２０００を示す図である。スタック２０００は１つの層上に映像２０１０及び音声２０２０、別の層上に映像２０１０及び音声２０２０の両方のＲＴＰ２０３０、更に別の層上にＵＤＰポート＃ｘ２０４０及びＵＤＰポート＃Ｙ２０５０、ＩＰ層２０６０、リンク層２０７０、及び物理層２０８０を含む。コデック特有ＲＴＰヘッダは汎用ＲＴＰヘッダに加えて用いられる。
【０１４７】
リアル・タイム制御プロトコル（ＲＴＣＰ）はＲＴＰ要求の一部である。ＲＴＣＰは送信者及び受信者間の統計通知ツールとして用いられる。各テレビ会議クライアント・アプリケーション１８００は統計を収集してそれらをお互いに、更に、サーバ２０５に対して、送信する。テレビ会議サーバ２０５はこのデータに基づいてセッションにおいて発生したかもしれない問題に関する情報を記録する。
【０１４８】
図２１は、本発明の例示的実施例による、制御プレーン・プロトコル・スタック２１００を示す図である。スタック２１００は１つの層上のＳＩＰ２１１０、ＵＩ（ユーザ・インタフェース）コデック変更メッセージング２１２０、ＲＴＣＰ２１３０、ＴＣＰ層２１４０、ＩＰ層２１５０、リンク層２１６０、及び物理層２１７０を含む。
【０１４９】
ＳＤＰの主な目的はセッションのメディア・ストリームについての情報を伝達することにある。ＳＤＰは以下のもの：セッション名及び目的；セッションが実行中の時間；セッションを有するメディア；メディアを受信する情報（すなわち、アドレス、ポート、フォーマットなど）；メディアの種類；トランスポート・プロトコル（ＲＴＰ／ＵＤＰ／ＩＰ）；メディアのフォーマット（Ｈ．２６３など）；マルチキャスト；メディア用マルチキャスト・アドレス；メディア用トランスポート・ポート；ユニキャスト；及びメディア用遠隔アドレス；を含むがそれらには限定されない。
【０１５０】
ＳＤＰ情報はＳＩＰメッセージに対するメッセージ本体である。それらは一緒に送信される。
【０１５１】
次に、本発明の例示的実施例による、図１８Ａのユーザ・インタフェース１８０８を説明する。ユーザ・インタフェース１８０８はテレビ会議クライアント・アプリケーション１８００の非常に重要な要素である。ユーザ・インタフェース１８０８はいくつかのビュー（表示／ボタン／メニュー／。。。）を含み、全ての入力データ（オーディオ／映像キャプチャ、ボタン、キーストローク）を扱い得る。
【０１５２】
図２２は、本発明の例示的実施例による、図１８Ａのユーザ・インタフェース１８０８に相当するスクリーン・ショット２２００を示す構成図である。スクリーン・ショット２２００は「大ビュー」２２１０、「小ビュー」２２２０、チャット・ビュー部２２３０、メンバ・ビュー部２２４０、及びチャット編集部２２５０を含む。
【０１５３】
もう一度図１８Ａによれば、映像キャプチャ・インタフェース１８３０は以下の如何なるもの：ウェブ・カム（図なし）；キャプチャ・カード及び高品質カメラ（図なし）；カメラ・インタフェース１８３０ａ；マイクロフォン・インタフェース１８３０ｂ；ファイル・インタフェース１８３０ｃ；などをも含み得る。
【０１５４】
ウェブ・カムはウィンドウズ（登録商標）・オペレーティング・システムによって設けられたビデオ・フォー・ウィンドウズ（登録商標）（ＶＦＷ）アプリケーション・プログラミング・インタフェース（ＡＰＩ）を用いたＵＳＢ（ユニバーサル・シリアル・バス）又はファイアワイヤ（ＩＥＥＥ（米国電気電子学会）１３９４）を通じて又はリナックスのような別のオペレーティング・システム下で用いられる別のキャプチャ・ドライバを通じてサポートすべきである。当然、本発明は上記のインタフェース、オペレーティング・システム、又はドライバに限定されるものでないので、他のインタフェース、オペレーティング・システム、及びドライバも、本発明の精神及び範囲を維持しながら、用い得る。
【０１５５】
メンバ・ビュー・モジュール１８３４は進行中のコールに参加しているメンバに対して表示するのに用いられる。コールの起動者（すなわち、マスタ）は所望しないメンバを取り去るかアクティブなメンバを選定するかの何れかを行い得る。全てのメンバがプライベート・チャット・メッセージ交換に１人以上のメンバを選定し得る。更に、メンバのステータスはメンバ・ビュー・モジュール１８３４に通知される。メンバは更に、自らのステータスを、例えば、現在は不在であるが直ぐに戻る旨を他方に通知するよう、「不在」に、設定し得る。
【０１５６】
映像ストリームに加えて、各メンバはチャット・モジュール１８３６を用いて他の全てのメンバか一部のメンバかの何れかに対してチャット・メッセージを送信する機会がある。メッセージはチャット・ビューに表示されてチャット編集ビューにおいて編集される。スクロールバーは更に古いメッセージを視ることを可能にする。
【０１５７】
次に、本発明の例示的実施例による、クライアント・アプリケーション１８００の動作シナリオを説明する。以下の説明は単に、クライアント・アプリケーション１８００の特徴の一部の基本的な指針であって特徴の完全な一覧を表すことを企図するものでない。該説明はログ・イン、コールの開始、コールの受理、及びログ・オフを包含する。
【０１５８】
ログ・インはクライアント・アプリケーション１８００が当初開始される場合に行われる。ログ・インは起動時にオペレーティング・システムに設けられるログ・イン名に基づいて自動的に行われるか、ログ・インに無関係で異なるインタフェースを用い得る。現在用いられているネットワークに対する認証の好適方法及びポリシーがどのように実行されているかによって変わってくる。最も簡単な方法は命名の一貫性を維持して（該当する場合）既存のユーザ・インタフェースを再使用することができるようウィンドウズ（登録商標）・オペレーティング・システムにおいて用いられるのと同様なログ・イン名を用いる。
【０１５９】
図２３は、本発明の例示的実施例による、ログ・イン・インタフェース２３００を示す図である。サイン・アップ機能２２３０はユーザがサーバ上で現在アカウントを有していない場合に用いられる。電子メール・アドレスは簡単にアクセスするよう如何なる電子メール・アドレス入力ボックス２３４０にも設け得る。
【０１６０】
コールを始動するには、クライアント・アプリケーション１８００は利用可能な候補者のリストをサーバ２０５に問い合わせる。クライアントはテレビ会議セッションに引き入れたいユーザを選定し得る。セッションは参加者２者が関係する場合にユニキャストとして設定される；さもなければ、２者を超える参加者が関係する場合、セッションはマルチキャスト・セッションとして設定される。
【０１６１】
図２４は、本発明の例示的実施例による、セッションを開始するユーザ選定インタフェース２４００を示す構成図である。
【０１６２】
ユーザがコールにインバイトされると、起動者の名前を表すメッセージが画面上に表示される。ユーザは更に、コールを受理するか却下するかの何れかを行い得る。ユーザがコールを受理する場合、クライアント・アプリケーション１８００は受理（又は受信確認）メッセージをサーバ２０５に送信する。サーバ２０５は更に新規メンバに関してコールに現在参加している全てのメンバに通知する。ユーザがサーバ２０５に取り消しメッセージを送信することによってコールを拒否する場合、他のメンバも全てそのイベントについて通知される。図２５は、本発明の例示的実施例による、着信コールを受理又は却下するインビテーション・インタフェース２５００を示す構成図である。
【０１６３】
ログ・オフはテレビ会議サーバ２０５のデータベース・エンティティ３０２に含まれるメンバ・データベース３１４からユーザを除去する。ＢＹＥメッセージがセッションの各参加クライアントに送信される。これはマルチキャスト又はユニキャストの何れかを通じて行い得る。マルチキャストはこのメッセージを送信する好適方法である。
【０１６４】
ＩＰマルチキャストは情報が単一の送信者から複数の受信者に転送される場合にネットワーク輻輳を解決するのを助力する技術である。マルチキャスティングによって情報が送信者によって一度だけ送信されてネットワークにおいてインテリジェントに複製されることが可能になる。これによってネットワークがその利用可能なリソースを効率的に利用することを可能にする。
【０１６５】
ユニキャスト・セッションからマルチキャスト・セッションへの切り替えは別の参加者がテレビ会議セッションに参加することになる場合に発生する。例示的目的で、既存のテレビ会議セッションに新規参加者をインバイトすることに関する２つのアプローチを次に説明する。しかしながら、当業者は、本発明の精神及び範囲を維持しながら、本発明によって既存のテレビ会議セッションに新規参加者を追加し得る、これら及び他のアプローチを考案することがわかる。第１アプローチでは、起動参加者（テレビ会議セッションを当初要求した参加者）は追加の者（新規参加者）が既存のテレビ会議に参加することを可能にするようサーバに対して通知する。第２アプローチにおいては、インビテーションが現在参加中のクライアントの１つからインバイトしたい者（新規参加者）のサーバに送信される。サーバは更に、インビテーションを新規参加者に送信する。
【０１６６】
図２６は本発明の例示的実施例による、ユニキャストからマルチキャストにＩＰベースのテレビ会議を切り替える方法を示す流れ図である。該方法はネットワークにおける現行の参加者間のテレビ会議セッションに対して別の参加者を追加することについて説明する。
【０１６７】
要求はテレビ会議セッションにおける現在の参加者の１者からテレビ会議セッションに追加される別の関係者を特定するテレビ会議サーバに送信される（工程２６１０）。現行の参加者及び別の関係者は同一サーバ上又は１つを超えるサーバによって扱われることがあることがわかる。後者の場合、現在の参加者が要求を別の関係者を扱うサーバに送信する。
【０１６８】
インビテーションはテレビ会議サーバから別の関係者に送信される（工程２６２０）。インビテーションの受理又は拒否を示すメッセージが別の関係者から受信される（工程２６３０）。
【０１６９】
インビテーションが受理された場合、マルチキャスト。アドレスが割り当てられてテレビ会議サーバが現在の参加者及び別の関係者を含むテレビ会議セッションに関係する参加者の各々に対してマルチキャスト・アドレスが送信される（工程２６４０）。現在の参加者及び別の参加者を含む参加者各々はインターネット・グループ・マルチキャスト・プロトコル（すなわち、ＩＧＭＰ）要求をネットワークに送信する（工程２６５０）。テレビ会議に関する全てのトラフィックはテレビ会議サーバによって割り当てられたマルチキャスト・アドレス上で送信及び受信される（工程２６６０）。
【０１７０】
別の追加関係者が（（起動参加者又はある他の参加者（又はネットワーク管理者）が事前に他者も現行のテレビ会議に参加可能であることを示している場合）自発的に又はインビテーションによって）テレビ会議セッションに参加する場合、工程２６１０乃至２６５０をマルチキャスト・テレビ会議セッションに他の追加関係者を追加するよう繰り返し得る。そのような場合は、他方の追加関係者を識別する要求が（上記の工程において直前に追加された関係者を含む）現行の関係者の一方によって又は（テレビ会議アプリケーションがそのような参加を既存のテレビ会議セッションにおいて許可するよう構成されている場合）他方の追加関係者によっても送信し得る。
【０１７１】
したがって、追加参加者が、各クライアント間の追加ユニキャスト・セッションを生成するかわりに、既存のテレビ会議セッションに参加することを所望する場合（例えば、図１Ｂ参照。）、マルチキャスト・セッションが開始される。マルチキャストを用いる主要な利点の１つは、複数コピーのかわりにコンテンツの単一コピーを送信することによって、ネットワーク・リソースが更に効率的に用いられることにある。
【０１７２】
例示的実施例がここでは添付図面とともに説明されたが、本発明はまさにこれらの実施例に限定されるものでなく、種々の他の変更及び修正が当業者によって本発明の範囲又は精神から逸脱することなく、もたらされ得ることがわかる。これらの全ての変更及び修正は本特許請求の範囲によって規定された本発明の範囲内に含まれることが企図されている。
【図面の簡単な説明】
【０１７３】
【図１Ａ】本発明の例示的実施例による、本発明を形成し得るコンピュータ・システム１００を示す構成図である。
【図１Ｂ】本発明の例示的実施例による、ユニキャスト・テレビ会議セッションを示す構成図である。
【図１Ｃ】本発明の例示的実施例による、マルチキャスト・テレビ会議セッションを示す構成図である。
【図２】本発明の例示的実施例による、本発明を形成し得るネットワーク２００を示す構成図である。
【図３】本発明の例示的実施例による、図２のテレビ会議サーバ２０５を示す構成図である。
【図４】本発明の例示的実施例による、図３のデータベース・エンティティに含まれるメンバ・データベース３１４に対するメンバ・データベース・エントリ４００を示す図である。
【図５】本発明の例示的実施例による、図３のデータベース・エンティティ３０２に含まれるアクティブ・セッション・データベース３１２に対するアクティブ・セッション・エントリ５００を示す構成図である。
【図６】本発明の例示的実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント・サーバ・アーキテクチャ６００を示す構成図である。
【図７】本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてテレビ会議セッションに登録する方法を示す図である。
【図８Ａ】本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてユニキャスト・テレビ会議セッションを設定する方法を示す図である。
【図８Ｂ】本発明の例示的実施例による、ＩＮＶＩＴＥ要求がクライアント＃１  ８０２（図８Ａの工程８１０）から受信された場合に、図２のテレビ会議サーバ２０５がたどる工程を示す図である。
【図９】本発明の例示的実施例による、図８Ａの方法を更に示す図である。
【図１０】本発明の別の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてマルチキャスト・テレビ会議セッションを設定する方法を示す図である。
【図１１】本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いてテレビ会議セッションを取り消す方法を示す図である。
【図１２】本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いて２つのクライアント間のテレビ会議セッションを終了する方法を示す図である。
【図１３】本発明の例示的実施例による、セッション開始プロトコル（ＳＩＰ）を用いて３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。
【図１４】本発明の別の例示的実施例によって、セッション開始プロトコル（ＳＩＰ）を用いて３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。
【図１５】本発明の例示的実施例による、解像度及びフレーム・レート調整に関する通知方法を示す図である。
【図１６】本発明の例示的実施例による、解像度及びフレーム・レート調整前の通知（クライアント２及び３）を示す図である。
【図１７】本発明の例示的実施例による、解像度及びフレーム・レート調整後の通知（クライアント２及び３）を示す図である。
【図１８Ａ】本発明の例示的実施例による、テレビ会議クライアント・アプリケーション１８００を示す構成図である。
【図１８Ｂ】本発明の例示的実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれるオーディオ・ミキサ１８９９を更に示す構成図である。
【図１８Ｃ】本発明の例示的実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれるエコー・キャンセレーション・モジュール１８９８を更に示す構成図である。
【図１９】本発明の例示的実施例による、オーディオ・コデック１８０４ａ及び／又はビデオ・コデック１８０４ｂの何れかに含まれる復号器１８９０によって使用される方法を示す図である。
【図２０】本発明の例示的実施例による、ユーザ・プレーン・プロトコル・スタック２０００を示す図である。
【図２１】本発明の例示的実施例による、制御プレーン・プロトコル・スタック２１００を示す図である。
【図２２】本発明の例示的実施例による、図１８Ａのユーザ・インタフェース１８０８に相当するスクリーン・ショット２２００を示す構成図である。
【図２３】本発明の例示的実施例による、ログ・イン・インタフェース２３００を示す図である。
【図２４】本発明の例示的実施例による、セッション開始に対するユーザ選定インタフェース２４００を示す構成図である。
【図２５】本発明の例示的実施例による、着信コールを受理するか拒否するインビテーション・インタフェース２５００を示す構成図である。
【図２６】本発明の例示的実施例による、ＩＰベースのテレビ会議をユニキャストからマルチキャストに切り替える方法を示す流れ図である。
【図１Ａ】
2005513836.tif 000003
【図１Ｂ】
2005513836.tif 000004
【図１Ｃ】
2005513836.tif 000005
【図２】
2005513836.tif 000006
【図３】
2005513836.tif 000007
【図４】
2005513836.tif 000008
【図５】
2005513836.tif 000009
【図６】
2005513836.tif 000010
【図７】
2005513836.tif 000011
【図８Ａ】
2005513836.tif 000012
【図８Ｂ】
2005513836.tif 000013
【図９】
2005513836.tif 000014
【図１０】
2005513836.tif 000015
【図１１】
2005513836.tif 000016
【図１２】
2005513836.tif 000017
【図１３】
2005513836.tif 000018
【図１４】
2005513836.tif 000019
【図１５】
2005513836.tif 000020
【図１６】
2005513836.tif 000021
【図１７】
2005513836.tif 000022
【図１８Ａ】
2005513836.tif 000023
【図１８Ｂ】
2005513836.tif 000024
【図１８Ｃ】
2005513836.tif 000025
【図１９】
2005513836.tif 000026
【図２０】
2005513836.tif 000027
【図２１】
2005513836.tif 000028
【図２２】
2005513836.tif 000029
【図２３】
2005513836.tif 000030
【図２４】
2005513836.tif 000031
【図２５】
2005513836.tif 000032
【図２６】
2005513836.tif 000033
【国際調査報告】
2005513836.tif 000034