(57)【要約】広域ネットワーク（ＷＡＮ）（１４２）を介したテレビ会議システムのための、再生制御システムが提供される。この再生制御システムは、種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを有するユーザー・インタフェースと、ポリシーおよびＱｏＳマネージャ（２１０）により個々の表示要件に従って表示特性およびトランスポート特性を管理するためのメッセージング・システムとを備えている。
2005534207.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介したテレビ会議システムのための再生制御システムであって、
種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを有するユーザー・インタフェースと、
個々の表示要件に従って表示特性およびトランスポート特性を管理するためのメッセージング・システムとを備える再生制御システム。
【請求項２】
前記表示特性およびトランスポート特性が、符号化解像度および伝送ビット・レートを含む、請求項１に記載の再生制御システム。
【請求項３】
前記メッセージング・システムが、現テレビ会議セッションに対して能動的な参加者から受動的な参加者への変更と、受動的な参加者から能動的な参加者への変更とのうちの一方を示すメッセージを送信することと受信することのうちの少なくとも一方を行う機能を備える、請求項１に記載の再生制御システム。
【請求項４】
テレビ会議セッションにおける能動的な参加者が、前記テレビ会議セッションにおける受動的な参加者よりも高い解像度と高いフレーム・レートのうちの少なくとも一方でビデオ・データを伝送するように、前記ユーザー・インタフェースおよび前記メッセージング・システムが適合された、請求項１に記載の再生制御システム。
【請求項５】
対応する参加者が、現テレビ会議セッションに対して能動的な参加者か受動的な参加者かに基づいて、前記ユーザー・インタフェースが前記複数の表示ウィンドウの間で切り替えることができる、請求項１に記載の再生制御システム。
【請求項６】
前記メッセージング・システムが、現テレビ会議セッションに対してビデオ・データを伝送する際に使用すべき解像度およびフレーム・レートを示すメッセージを送信することと受信することのうちの少なくとも一方を行う機能を備える、請求項１に記載の再生制御システム。
【請求項７】
前記ユーザー・インタフェースが、テレビ会議セッション中に複数のデコーダを生成する機能を有する、請求項１に記載の再生制御システム。
【請求項８】
前記ユーザー・インタフェースが、各受信ビデオ・データ・ストリーム毎に１つのデコーダを生成する機能を有する、請求項１に記載の再生制御システム。
【請求項９】
前記ユーザー・インタフェースが、同じテレビ会議セッション中に異なるデコーダを生成し、交換し、採用する機能を有する、請求項１に記載の再生制御システム。
【請求項１０】
前記ユーザー・インタフェースが、異なるテレビ会議セッション毎に異なるデコーダを生成し、交換し、採用する機能を有する、請求項１に記載の再生制御システム。
【請求項１１】
ローカル音声データとローカル・ビデオ・データのうちの少なくとも一方を少なくとも取り込むための音声／ビデオ・キャプチャ・インタフェースを更に備える、請求項１に記載の再生制御システム。
【請求項１２】
前記音声／ビデオ・キャプチャ・インタフェースが、カメラ・インタフェース、マイクロホン・インタフェース、ファイル・インタフェースのうちの少なくとも１つを備える、請求項１１に記載の再生制御システム。
【請求項１３】
前記ユーザー・インタフェースが、対応する参加者が現テレビ会議セッションに対して能動的な参加者から受動的な参加者への切替えと受動的な参加者から能動的な参加者への切替えのうちの一方を要求していることを示すためのページング・ボタンを備える、請求項１に記載の再生制御システム。
【請求項１４】
前記ネットワークが、少なくとも２つのクライアント装置および少なくとも１つのサーバを含み、前記ユーザー・インタフェースが、前記少なくとも２つのクライアント装置の何れかにより使用されるように適合された、請求項１に記載の再生制御システム。
【請求項１５】
前記ネットワークが、少なくとも２つのクライアント装置および少なくとも１つのサーバを含み、前記メッセージング・システムが、前記サーバと前記少なくとも２つのクライアント装置とのうちの何れかにより使用されるように適合された、請求項１に記載の再生制御システム。
【請求項１６】
テレビ会議システムのためのユーザー・インタフェースであって、
同時に表示することができ種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを有するビデオ再生装置を備えるユーザー・インタフェース。
【請求項１７】
テレビ会議セッションにおける能動的な参加者が、前記テレビ会議セッションにおける受動的な参加者よりも高い解像度と高いフレーム・レートのうちの少なくとも一方でビデオ・データを伝送するように、前記ビデオ再生装置が適合された、請求項１６に記載のユーザー・インタフェース。
【請求項１８】
前記ビデオ再生装置が、テレビ会議セッション中に複数のデコーダを生成する機能を有する、請求項１６に記載のユーザー・インタフェース。
【請求項１９】
前記ビデオ再生装置が、各受信ビデオ・データ・ストリーム毎に１つのデコーダを生成する機能を有する、請求項１６に記載のユーザー・インタフェース。
【請求項２０】
前記ビデオ再生装置が、同じテレビ会議セッション中に異なるデコーダを生成し、交換し、採用する機能を有する、請求項１６に記載のユーザー・インタフェース。
【請求項２１】
前記ビデオ再生装置が、異なるテレビ会議セッション毎に異なるデコーダを生成し、交換し、採用する機能を有する、請求項１６に記載のユーザー・インタフェース。
【請求項２２】
ローカル音声データとローカル・ビデオ・データのうちの少なくとも一方を少なくとも取り込むための音声／ビデオ・キャプチャ・インタフェースを更に備える、請求項１６に記載のユーザー・インタフェース。
【請求項２３】
前記音声／ビデオ・キャプチャ・インタフェースが、カメラ・インタフェース、マイクロホン・インタフェース、ファイル・インタフェースのうちの少なくとも１つを備える、請求項２２に記載のユーザー・インタフェース。
【請求項２４】
対応する参加者が現テレビ会議セッションに対して能動的な参加者から受動的な参加者への切替えと受動的な参加者から能動的な参加者への切替えのうちの一方を要求していることを示すためのページング・ボタンを備える、請求項１６に記載のユーザー・インタフェース。
【請求項２５】
ネットワークを介したテレビ会議システムのためのサーバであって、
個々の表示要件に従って表示特性およびトランスポート特性を管理するためのメッセージング・システムを備えるサーバ。
【請求項２６】
前記メッセージング・システムが、現テレビ会議セッションに対して能動的な参加者から受動的な参加者への変更と、受動的な参加者から能動的な参加者への変更とのうちの一方を示すメッセージを送信することと受信することのうちの少なくとも一方を行う機能を備える、請求項２５に記載のサーバ。
【請求項２７】
前記メッセージング・システムが、現テレビ会議セッションに対してコンテンツを伝送する際に使用すべき解像度およびフレーム・レートを示すメッセージを送信することと受信することのうちの少なくとも一方を行う機能を備える、請求項２５に記載のサーバ。
【請求項２８】
テレビ会議セッションに対応するコンテンツを表示する方法であって、
同時に表示することができ種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを生成するステップを含む方法。
【請求項２９】
前記提供するステップが、対応する参加者が前記テレビ会議セッションに対して能動的な参加者か受動的な参加者かに基づいて、前記複数の表示ウィンドウの間で切り替える機能を提供するステップを含む、請求項２８に記載の方法。
【請求項３０】
前記テレビ会議セッション中に複数のデコーダを生成する機能を提供するステップを更に含む、請求項２８に記載の方法。
【請求項３１】
各受信ビデオ・データ・ストリーム毎に１つのデコーダを生成する機能を提供するステップを更に含む、請求項２８に記載の方法。
【請求項３２】
前記テレビ会議セッション中に異なるデコーダを生成すること、交換すること、採用することのうちの少なくとも１つを行う機能を提供するステップを更に含む、請求項２８に記載の方法。
【請求項３３】
個々の表示要件に従って表示特性およびトランスポート特性を管理する機能を提供するステップを更に含む、請求項２８に記載の方法。
【請求項３４】
前記表示特性およびトランスポート特性が符号化解像度および伝送ビット・レートを含む、請求項３３に記載の方法。
【請求項３５】
表示特性およびトランスポート特性を管理する機能を提供する前記ステップが、前記テレビ会議セッションに対して能動的な参加者から受動的な参加者への変更と、受動的な参加者から能動的な参加者への変更とのうちの一方を示すメッセージを送信することと受信することのうちの少なくとも一方を行う機能を提供するステップを含む、請求項３３に記載の方法。
【請求項３６】
前記テレビ会議セッションにおける能動的な参加者に対して、前記テレビ会議セッションにおける受動的な参加者よりも高い解像度でコンテンツを符号化および伝送する機能を提供するステップを更に含む、請求項２８に記載の方法。
【請求項３７】
表示特性およびトランスポート特性を管理する機能を提供する前記ステップが、前記テレビ会議セッションに対応するコンテンツを伝送するための解像度およびフレーム・レートを示すメッセージを送信することと受信することのうちの少なくとも一方を行う機能を提供するステップを含む、請求項３２に記載の方法。
【請求項３８】
対応する参加者が能動的な参加者から受動的な参加者への切替えと受動的な参加者から能動的な参加者への切替えのうちの一方を要求していることを示すページング信号を出力する機能を提供するステップを更に含む、請求項２８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本明細書は、２００１年１２月１５日出願の「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ  ＡＰＰＬＩＣＡＴＩＯＮ  ＵＳＥＲ  ＩＮＴＥＲＦＡＣＥ」という名称の仮出願第６０／３４１，８０１号、弁理士整理番号第ＰＵ０１０３１１号の利益を、米国特許法第１１９条に従って請求する本出願である。また、本願は、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯ  ＣＯＮＦＥＲＥＮＣＩＮＧ  ＢＡＮＤＷＩＤＴＨ  ＳＥＬＥＣＴＩＯＮ  ＭＥＣＨＡＮＩＳＭ」という名称の仮出願第６０／３４１，７２０号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＱＵＡＬＩＴＹ  ＯＦ  ＳＥＲＶＩＣＥ  ＳＥＴＵＰ  ＯＮ  Ａ  ＴＩＭＥ  ＲＥＳＥＲＶＡＴＩＯＮ  ＢＡＳＩＳ」という名称の仮出願第６０／３４１，６７１号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯ  ＣＯＮＦＥＲＥＮＣＩＮＧ  ＣＡＬＬ  ＳＥＴＵＰ  ＭＥＴＨＯＤ」という名称の仮出願第６０／３４１，７９７号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ  ＳＥＳＳＩＯＮ  ＳＷＩＴＣＨＩＮＧ  ＦＲＯＭ  ＵＮＩＣＡＳＴ  ＴＯ  ＭＵＬＴＩＣＡＳＴ」という名称の仮出願第６０／３４１，８００号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＰＲＯＶＩＤＩＮＧ  Ａ  ＰＲＩＶＡＴＥ  ＣＯＮＶＥＲＳＡＴＩＯＮ  ＣＨＡＮＮＥＬ  ＩＮ  Ａ  ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＩＮＧ  ＳＹＳＴＥＭ」という名称の仮出願第６０／３４１，７９９号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＳＥＲＶＥＲ  ＩＮＶＯＫＥＤ  ＴＩＭＥ  ＳＣＨＥＤＵＬＥＤ  ＶＩＤＥＯ  ＣＯＮＦＥＲＥＮＣＥ」という名称の仮出願第６０／３４１，８１９号と、２００２年３月２０日出願の「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ  ＳＹＳＴＥＭ  ＡＲＣＨＩＴＥＣＴＵＲＥ」という名称の仮出願第６０／３６６，３３１号にも関連する。
【０００２】
本発明は、一般にテレビ会議（ｖｉｄｅｏｃｏｎｆｅｒｅｎｃｅ）に関し、より詳細には、テレビ会議アプリケーション・ユーザー・インタフェースと、このユーザー・インタフェース上に表示されるビデオ・データのパラメータを制御するためのメッセージング・システムとに関する。
【背景技術】
【０００３】
テレビ会議は、コンピュータ・ネットワーク上の様々な位置、場所にいる複数のユーザー間で、生（ライブ）の双方向対話式ビデオを伝送することを含んでいる。リアルタイムの対話式ビデオは、遅延を強いられながら多量の情報を伝送することを必要とする。テレビ会議の欠点の１つは、リアルタイム・ビデオの伝送が、極度に帯域幅を使い切る可能性があり、状況により、利用可能なネットワーク・リソースを容易に使い尽くす可能性がある点である。ネットワークを介して伝送されるリアルタイム・ビデオのビット・レートは、主に、使用されるビデオ解像度および圧縮アルゴリズムにより決まる。企業環境では、ネットワークは通常、１つまたは複数の広域ネットワーク（ＷＡＮ）により結合された複数のローカル・エリア・ネットワーク（ＬＡＮ）を含んでいる。一般的なテレビ会議システムの制限要因は、地理的位置間の長距離リンク（例えば、ＷＡＮ）である。
【０００４】
従って、従来技術の欠点を解決するテレビ会議アプリケーション・ユーザー・インタフェースを提供することが望ましく、また非常に有利である。
【発明の開示】
【０００５】
（発明の概要）
上述の問題並びに従来技術におけるその他の関連する問題は、本発明、即ちテレビ会議アプリケーション・ユーザー・インタフェースと、このユーザー・インタフェース上に表示されるビデオ・データのパラメータを制御するためのメッセージング・システムとにより解決される。
【０００６】
本発明の一態様によれば、ネットワークを介したテレビ会議システムのための、再生制御システムが提供される。この再生制御システムは、種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを有するユーザー・インタフェースと、個々の表示要件に従って表示特性およびトランスポート特性を管理するためのメッセージング・システムとを備えている。
【０００７】
本発明の別の態様によれば、テレビ会議システムのためのユーザー・インタフェースが提供される。このユーザー・インタフェースは、同時に表示することができ種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを有するビデオ再生装置を備えている。
【０００８】
本発明の別の態様によれば、ネットワークを介したテレビ会議システムのためのサーバが提供される。このサーバは、個々の表示要件に従って表示特性およびトランスポート特性を管理するためのメッセージング・システムを備えている。
【０００９】
本発明の別の態様によれば、テレビ会議セッションに対応するコンテンツを表示する方法が提供される。この方法は、同時に表示することができ種々の解像度およびフレーム・レートが可能である複数の表示ウィンドウを提供するステップを含んでいる。
【００１０】
本発明のこれらおよび他の態様、特徴、および利点は、添付の図面と共に読むべき、好ましい実施例に関する以下の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１１】
本発明は、テレビ会議アプリケーション・ユーザー・インタフェースと、このユーザー・インタフェース上に表示されるビデオ・データのパラメータを制御するためのメッセージング・システムとを対象とする。
【００１２】
本発明は、様々な形式のハードウェア、ソフトウェア、ファームウェア、専用処理回路、またはこれらの組合せにおいて実現できることを理解されたい。好ましくは、本発明はハードウェアとソフトウェアの組合せとして実現される。更に、ソフトウェアは、プログラム記憶装置上に有形に具体化されたアプリケーション・プログラムとして実現されることが好ましい。アプリケーション・プログラムは、任意の適当なアーキテクチャを構成するコンピュータにアップロードして実行する。コンピュータは、１つまたは複数の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、入出力（Ｉ／Ｏ）インタフェースなどのハードウェアを有するコンピュータ・プラットフォーム上で実現されることが好ましい。また、コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも備えている。本明細書に述べる様々な処理および機能は、マイクロ命令コードの一部またはアプリケーション・プログラムの一部（或いはこれらの組合せ）とすることができ、これはオペレーティング・システムを介して実行される。更に、コンピュータ・プラットフォームには、追加のデータ記憶装置や印刷装置など、その他の様々な周辺装置を接続できる。
【００１３】
更に、添付の図に示す、構成要素をなすシステム構成要素および方法ステップの幾つかはソフトウェアで実現することが好ましいので、システム構成要素（または処理ステップ）間の実際の接続関係は、本発明がプログラムされる方式に応じて異なる場合があることを理解されたい。本明細書の開示があれば、当業者なら、本発明に関するこれらおよび類似の実現形態または構成を考案することができるであろう。
【００１４】
図１Ａは、本発明の説明に役立つ一実施例による、本発明を適用することのできるコンピュータ・システム１００を示すブロック図である。コンピュータ処理システム１００は、システム・バス１０４を介して他の構成要素に動作可能になるように結合された少なくとも１つの処理回路（ＣＰＵ）１０２を備えている。システム・バス１０４には、読出し専用メモリ（ＲＯＭ）１０６、ランダム・アクセス・メモリ（ＲＡＭ）１０８、表示アダプタ１１０、入出力（Ｉ／Ｏ）アダプタ１１２、ユーザー・インタフェース・アダプタ１１４、音声アダプタ１９９、ネットワーク・アダプタ１９８が動作可能になるように結合されている。
【００１５】
表示装置１１６が、表示アダプタ１１０によりシステム・バス１０４に動作可能になるように結合されている。ディスク記憶装置（例えば、磁気または光ディスク記憶装置）１１８が、Ｉ／Ｏアダプタ１１２によりシステム・バス１０４に動作可能になるように結合されている。
【００１６】
マウス１２０およびキーボード１２２が、ユーザー・インタフェース・アダプタ１１４によりシステム・バス１０４に動作可能になるように結合されている。マウス１２０およびキーボード１２２は、システム１００との間で情報を入出力するのに使用される。
【００１７】
少なくとも１つのスピーカ（以下、「スピーカ」とする）１９７が、音声アダプタ１９９によりシステム・バス１０４に動作可能になるように結合されている。
【００１８】
（ディジタルおよび／またはアナログ）モデム１９６が、ネットワーク・アダプタ１９８によりシステム・バス１０４に動作可能になるように結合されている。
【００１９】
次に、本発明の説明に役立つ一実施例による、ポリシー・ベース・ネットワーク管理（ＰＢＮＭ：Ｐｏｌｉｃｙ  Ｂａｓｅｄ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ）について述べる。ＰＢＮＭは、ネットワークを管理するためのポリシーを定義および配布する機能をもたらす技術である（本発明を適用することのできる例示的なネットワークについては図２に関連して後述する）。これらのポリシーにより、帯域幅やセキュリティなどのクリティカル（ｃｒｉｔｉｃａｌ：重大な、重要な、決定的な）なネットワーク・リソース（資源）を協調的に制御する。ＰＢＮＭは、ＩＰベースのテレビ会議など、ネットワーク上で差別化して扱う必要のあるアプリケーションを利用可能にする。ＰＢＮＭは、種々のタイプのアプリケーションが単一のネットワーク上で共存できるようにするための基盤を提供し、必要なリソースをこれらの各アプリケーションに提供する。
【００２０】
更に詳細には、ポリシー・ベース・ネットワーク管理（ＰＢＮＭ）は、ネットワーク・リソースを使い切るアプリケーションおよびユーザーに対してポリシーを定義する。例えば、ビジネス・クリティカルなアプリケーションには、ネットワーク上で最高の優先順位および帯域幅割合を与え、テレビ会議およびボイス・オーバーＩＰ（ＶｏＩＰ）には、次に高い優先順位を与え、最後に、厳しい帯域幅クリティカルなまたは時間クリティカルな制約を持たないウェブ（Ｗｅｂ）トラフィックおよびファイル転送には、ネットワーク上の残りのリソース量を与えることができる。ＰＢＮＭを使用して、このようなユーザーおよびアプリケーションの差別化を達成する。
【００２１】
テレビ会議システムは、テレビ会議アプリケーションに対応するポリシーをネットワーク・ポリシー・サーバに照会することにより、ポリシー・ベース・ネットワーク管理（ＰＢＮＭ）システムに繋がる。テレビ会議サーバは、ネットワーク・ポリシー・サーバからポリシーを入手し、受け取ったパラメータに基づいて、テレビ会議に利用可能なネットワーク中のリソースを決定する。通常、ポリシーは、例えば、一日のうちの一定の時間帯にこのアプリケーションに利用可能な帯域幅、または一定のユーザーだけに利用可能な帯域幅に対応するものになる。この構成は、例えばポリシーおよび／またはその一部を追加、削除、置換、変更することなどにより、容易に変更される。この結果、テレビ会議サーバは、ポリシー中で提供された情報を使用してネットワーク上の会議セッションを管理することになる。
【００２２】
図２は、本発明の説明に役立つ一実施例による、本発明を適用することのできるネットワーク２００を示すブロック図である。ネットワーク２００は、テレビ会議サーバ２０５、ポリシーおよびサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）マネージャ２１０、ＭＡＤＣＡＰサーバ２１５、第１の複数のコンピュータ２２０ａ〜ｆ、第１のローカル・エリア・ネットワーク２２５、第１のルータ２４０、第２の複数のコンピュータ２３０ａ〜ｅ、第２のローカル・エリア・ネットワーク２３５、第２のルータ２４５、広域ネットワーク２５０を含んでいる。
【００２３】
次に、本発明の説明に役立つ一実施例によるサーバ・アーキテクチャについて述べる。図３は、本発明の説明に役立つ一実施例による、図２のテレビ会議サーバ２０５を示すブロック図である。テレビ会議サーバ２０５は、３つの基本構成要素、即ちデータベース構成要素３０２、ネットワーク通信構成要素３０４、セッション管理構成要素３０６を備えるものと考えることができる。
【００２４】
セッション管理構成要素３０６は、テレビ会議セッションのセットアップ（ｓｅｔｕｐ：開始）および終了（ｔｅａｒｄｏｗｎ：解体）を管理することを担う。また、セッション管理構成要素３０６は、テレビ会議サーバ２０５に関する主要な制御のほとんどを提供する。セッション管理構成要素３０６は、セッション管理構成要素３０６の機能を実施するためのセッション・マネージャ３２０を備えている。
【００２５】
ネットワーク通信構成要素３０４は、テレビ会議システムに使用される多くの様々なプロトコルをカプセル化することを担う。プロトコルには、リモート監理および管理のためのシンプル・ネットワーク管理プロトコル（ＳＮＭＰ：Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、ポリシー管理のためのコモン・オープン・ポリシー・サービス（ＣＯＰＳ：Ｃｏｍｍｏｎ  Ｏｐｅｎ  Ｐｏｌｉｃｙ  Ｓｅｒｖｉｃｅｓ）または別のプロトコル（簡易（ライトウェイト）ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）など）、同報通信割振りのための同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ：Ｍｕｌｔｉｃａｓｔ  Ａｄｄｒｅｓｓ  Ｄｙｎａｍｉｃ  Ｃｌｉｅｎｔ  Ａｌｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、テレビ会議セッション管理のためのセッション開始プロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、分散テレビ会議サーバ管理のためのサーバ間メッセージングを含めることができる。従って、ネットワーク通信構成要素３０４は、ＳＮＭＰモジュール３０４ａ、ＬＤＡＰクライアント・モジュール３０４ｂ、ＭＡＤＣＡＰクライアント・モジュール３０４ｃ、ＳＩＰモジュール３０４ｄ、サーバ間管理（ｓｅｒｖｅｒ−ｔｏ―ｓｅｒｖｅｒ  ｍａｎａｇｅｍｅｎｔ）モジュール３０４ｅを備えている。更に、これらの要素３０４ａ〜３０４ｅはそれぞれ、リモート監理端末３８２、ネットワーク・ポリシー・サーバ（帯域幅ブローカ）３８４、ＭＡＤＣＡＰサーバ２１５、デスクトップ会議クライアント３８８、他のテレビ会議サーバ３９０の各要素と通信する。このような通信は、伝送制御プロトコル（ＴＣＰ）、ユーザー・データグラム・プロトコル（ＵＤＰ）、インターネット・プロトコル（ＩＰ）も使用して実現することができ、これらは一括してプロトコル・モジュール３３０で表す。これらのプロトコルおよび対応する要素は、例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、その他のプロトコルおよび対応する要素も容易に採用することができることを理解されたい。
【００２６】
更に、テレビ会議サーバ２０５のアーキテクチャは、ポータブル・デバイス上のユーザーが、仮想私設ネットワーク（ＶＰＮ）を介して企業インフラストラクチャに接続し、テレビ会議セッションに対してコンテンツを送受信するのにも適していることを理解されたい。
【００２７】
データベース構成要素３０２は、４つのデータベース、即ちスケジューリング・データベース３１０、アクティブ・セッション・データベース３１２、メンバ・データベース３１４、およびネットワーク・アーキテクチャ・データベース３１６を備えている。
【００２８】
更に、テレビ会議システム・サーバ２０５は、会社の簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）サーバ（ユーザー情報）３４０およびオプション外部データベース３４２を備えるか、または少なくともこれらとインタフェースする。オプション外部データベース３４２は、ＬＤＡＰクライアント３０４ｂを備えている。
【００２９】
次に、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるメンバ・データベース３１４について述べる。メンバ・データベース３１４は、テレビ会議システムにログインした各ユーザーに関する情報を含んでいる。例えば、メンバ・データベース３１４中には、各ユーザーについて以下の情報を保持する。即ち、ユーザー名、パスワード（適用可能なら）、サポートされるビデオ・コーデックおよびキャプチャ解像度、サポートされる音声コーデック、現在のＩＰアドレス、現在の呼番号（現在アクティブな呼のメンバである場合）、利用可能性（利用可能か利用不可能か）、ビデオ・カメラのタイプおよびモデル、ネットワーク上の位置（各位置は限られた帯域幅の広域ネットワーク（ＷＡＮ）リンクで接続される）、ＣＰＵのタイプおよび処理能力である。これらの項目は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、これらの項目の幾つかまたは全てに加えて、またはそれに代えて、他の項目を各ユーザーについてメンバ・データベース３１４中に保持することもできることを理解されたい。
【００３０】
図４は、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるメンバ・データベース３１４のメンバ・データベース項目４００を示す図である。説明に役立つ図４の実施例では、メンバ・データベース３１４は、単純なリンクリストを使用して実現されている。ただし、本発明の他の実施例では、本発明の趣旨および範囲を維持しながら、メンバ・データベース３１４の異なる実現形態を採用することもできることを理解されたい。例えば、簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）タイプのデータベースを使用してメンバ情報を記憶してもよい。
【００３１】
次に、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるアクティブ・セッション・データベース３１２について述べる。アクティブ・セッション・データベース３１２は、現在行われている各テレビ会議セッションに関する情報を含んでいる。例えば、アクティブ・セッション・データベース３１２中には、各呼について以下の情報を保持する。即ち、呼ＩＤ、説明、同報通信（ｙｅｓ／ｎｏ）、同報通信の場合は同報通信ＩＰアドレス、各参加者についてのネットワーク位置、現在の伝送解像度、現在の伝送ビット・レート、ビデオ・コーデックおよび音声コーデック、公開呼（ｐｕｂｌｉｃ  ｃａｌｌ）／秘密呼（ｐｒｉｖａｔｅ  ｃａｌｌ）（他者が参加できるかどうか）、セッション予定時間、セッション開始時間、任意の追加オプションである。これらの項目は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、これらの項目の幾つかまたは全てに加えて、またはそれに代えて、他の項目をアクティブ・セッション・データベース３１２中に保持することもできることを理解されたい。
【００３２】
図５は、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるアクティブ・セッション・データベース３１２中のアクティブ・セッション項目５００を示すブロック図である。説明に役立つ図５の実施例では、アクティブ・セッション・データベース３１２は、単純なリンクリストを使用して実現されている。ただし、本発明の他の実施例では、本発明の趣旨および範囲を維持しながら、アクティブ・セッション・データベース３１２の異なる実現形態を採用することもできることを理解されたい。
【００３３】
次に、再び図３を参照しながら、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるネットワーク・アーキテクチャ・データベース３１６について述べる。ネットワーク・アーキテクチャ・データベース３１６は、ネットワーク全体の完全なマッピングを含んでいる。ネットワーク・アーキテクチャ・データベース３１６は、アクティブな各ネットワーク要素（即ち、ＩＰルータやイーサネット（登録商標）スイッチなど）に関する情報と、ルータおよびスイッチを共に接続するリンクに関する情報を含んでいる。ネットワーク中の帯域幅およびサービス品質を効果的に管理するために、テレビ会議サーバ２０５は、この情報を知る必要がある。
【００３４】
ネットワーク・アーキテクチャ・データベース３１６中では、同時に行うことが許容されるテレビ会議セッションの数、テレビ会議セッションのビット・レート、帯域幅制限に関して、ポリシー情報を定義することもできる。ネットワーク・アーキテクチャ・データベース３１６内では、ネットワーク・アーキテクチャを重み付きグラフとして表すことができる。ネットワーク・アーキテクチャ・データベース３１６は、テレビ会議サーバ２０５中のオプションのデータベースであることを理解されたい。ネットワーク・アーキテクチャ・データベース３１６を使用して、ポリシー・サーバ２１０に要求されるポリシーをキャッシュする。
【００３５】
次に、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるスケジューリング・データベース３１０について述べる。スケジューリング・データベース３１０は、テレビ会議システムを使用する時間をユーザーが予約するためのスケジュールを含んでいる。これはポリシーに依存する。例えば、広域ネットワーク（ＷＡＮ）２５０を介した一定のリンク上で同時に行うことのできるテレビ会議セッションの数に関して情報システム部門が適所で有するポリシーに依存する。
【００３６】
次に、図３のネットワーク通信構成要素３０４について述べる。ネットワーク通信構成要素３０４は、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モジュール３０４ａ、簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クライアント・モジュール３０４ｂ、同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ）クライアント・モジュール３０４ｃ、セッション開始プロトコル（ＳＩＰ）モジュール３０４ｄ、サーバ間管理モジュール３０４ｅを備えている。
【００３７】
次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わるシンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モジュール３０４ａについて述べる。図６は、本発明の説明に役立つ一実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント−サーバ・アーキテクチャ６００を示すブロック図である。アーキテクチャ６００は、ＳＮＭＰモジュール３０４ａの一実現形態を表すが、本発明は図６に示すアーキテクチャに限定されず、従って、本発明の趣旨および範囲を維持しながら、他のＳＮＭＰアーキテクチャを採用することもできることを理解されたい。ＳＮＭＰは、テレビ会議サーバのリモート監理および監視に使用される。
【００３８】
シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント−サーバ・アーキテクチャ６００は、ＳＮＭＰ管理局６１０およびＳＮＭＰ被管理構成要素６２０を含んでいる。ＳＮＭＰ管理局６１０は、管理アプリケーション６１０ａおよびＳＮＭＰマネージャ６１０ｂを備えている。ＳＮＭＰ被管理構成要素６２０は、被管理リソース６２０ａ、ＳＮＭＰ被管理オブジェクト６２０ｂ、ＳＮＭＰエージェント６２０ｃを備えている。更に、ＳＮＭＰ管理局６１０およびＳＮＭＰ被管理構成要素６２０はそれぞれ、ＵＤＰ層６３０、ＩＰ層６４０、媒体アクセス制御（ＭＡＣ）層６５０、物理層６６０も備えている。
【００３９】
シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）エージェント６２０ｃは、ＳＮＭＰ管理局６１０からの監視および監理を可能にする。ＳＮＭＰエージェント６２０ｃは、ＳＮＭＰアーキテクチャ６００中のクライアントである。ＳＮＭＰエージェント６２０ｃは基本的に、情報およびアクションを求めるＳＮＭＰ管理局６１０からの要求に応答する役割を担う。ＳＮＭＰ管理局６１０は、ＳＮＭＰアーキテクチャ６００中のサーバである。ＳＮＭＰ管理局６１０は、ネットワーク中のエージェントを管理する中央構成要素である。ＳＮＭＰ管理局６１０は、管理者がＳＮＭＰエージェント６２０ｃから統計を収集し、ＳＮＭＰエージェント６２０ｃの構成パラメータを変更することを可能にする機能を提供する。
【００４０】
シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モデルを使用した場合、テレビ会議サーバ２０５中のリソース（資源）をオブジェクトとして表すことにより、これらのリソースを管理する。各オブジェクトは、被管理エージェントの特徴の１つを表すデータ変数である。このオブジェクト集合は、一般に管理情報ベース（ＭＩＢ：Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）と呼ばれる。ＭＩＢは、ＳＮＭＰ管理局６１０に対する、ＳＮＭＰエージェント６２０ｃにおけるアクセス・ポイントの集合として機能する。ＳＮＭＰ管理局６１０は、ＳＮＭＰエージェント６２０ｃ中のＭＩＢオブジェクトの値を取り出すことにより監視を行うことができる。また、ＳＮＭＰ管理局６１０は、ＳＮＭＰエージェント６２０ｃにおいてアクションが行われるようにすることができ、或いはＳＮＭＰエージェント６２０ｃにおける構成設定を変更する。
【００４１】
ＳＮＭＰは、ＩＰ層６４０を介して動作し、そのトランスポート・プロトコルのためにＵＤＰ層６３０を使用する。
【００４２】
シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）で使用される基本的なメッセージは、ＧＥＴ、ＳＥＴ、ＴＲＡＰである。ＧＥＴメッセージは、ＳＮＭＰ管理局６１０が、ＳＮＭＰエージェント６２０ｃにおけるオブジェクトの値を取り出すことを可能にする。ＳＥＴメッセージは、ＳＮＭＰ管理局６１０が、ＳＮＭＰエージェント６２０ｃにおけるオブジェクトの値を設定することを可能にする。ＴＲＡＰメッセージは、ＳＮＭＰエージェント６２０ｃが、ＳＮＭＰ管理局６１０に重要なイベントを通知することを可能にする。
【００４３】
次に、本発明の説明に役立つ一実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）構成要素６２０に備わるＳＮＭＰ被管理リソース６２０ａについて述べる。リモート監理は、テレビ会議サーバ２０５内の以下のリソースを監視および／または制御する。即ち、アクティブ・セッションおよび関連する統計と、セッション・ログと、テレビ会議のためのネットワーク・ポリシーと、セッション開始プロトコル（ＳＩＰ）パラメータおよび統計と、同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ）パラメータおよび統計である。
【００４４】
シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）管理局６１０から、管理アプリケーションに代わってＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ、ＳｅｔＲｅｑｕｅｓｔの３つのタイプのＳＮＭＰメッセージが発行される。最初の２つは、ＧＥＴ関数の変形である。３つのメッセージは全て、ＳＮＭＰエージェント６２０ｃによりＧｅｔＲｅｓｐｏｎｓｅメッセージの形式で肯定応答され、このメッセージは、上方の管理アプリケーション６１０ａに渡される。また、ＳＮＭＰエージェント６２０ｃは、被管理リソース中で生じたイベントに応答してＴＲＡＰメッセージを発行することもできる。
【００４５】
次に、再び図３を参照しながら、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わる簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クライアント・モジュール３０４ｂについて述べる。ＬＤＡＰモジュール３０４ｂは、共通ディレクトリ情報にアクセスするための標準的なＩＰベースのプロトコルであるＬＤＡＰを利用する。ＬＤＡＰは、ユーザー特有の基準を満たす項目の検索、項目の追加、項目の削除、項目の変更、項目の比較など、ディレクトリ項目に対するアクセスおよび変更を行うための動作を定義する。
【００４６】
次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わる同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ）クライアント・モジュール３０４ｃについて述べる。ＭＡＤＣＡＰモジュール３０４ｃは、ホストが同報通信アドレス割振りサーバに同報通信アドレス割振りサービスを要求することを可能にするプロトコルであるＭＡＤＣＡＰを利用する。同報通信サービスを利用するためにテレビ会議セッションがセットアップされるとき、テレビ会議サーバ２０５は、セッション内のクライアントに割り振るための同報通信アドレスを得る必要がある。テレビ会議サーバ２０５は、ＭＡＤＣＡＰプロトコルを使用して、同報通信アドレスを同報通信アドレス割振りサーバから動的に得ることができる。
【００４７】
次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わるセッション開始プロトコル（ＳＩＰ）モジュール３０４ｄについて述べる。ＳＩＰモジュール３０４ｄは、ＩＰベースのネットワーク上にいる１人または複数の参加者とのマルチメディア・セッションを生成、変更、終了するためのアプリケーション層制御プロトコルであるＳＩＰを利用する。ＳＩＰは、文字メッセージ・ベースのプロトコルである。
【００４８】
セッション開始プロトコル（ＳＩＰ）ベースのテレビ会議システムでは、クライアントおよびサーバはそれぞれ、ＳＩＰ  ＵＲＬで識別される。ＳＩＰ  ＵＲＬは、ｕｓｅｒ＠ｈｏｓｔの形式をとるが、これは電子メール・アドレスと同じフォーマットであり、ほとんどの場合、ＳＩＰ  ＵＲＬは、ユーザーの電子メール・アドレスである。
【００４９】
次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わるサーバ間管理モジュール３０４ｅについて述べる。サーバ間管理モジュール３０４ｅは、テレビ会議サーバ間で情報を交換するためのメッセージを利用する。サーバ間管理モジュール３０４ｅは、固有のテレビ会議サーバ（例えば、テレビ会議サーバ２０５）がそのサポートするネットワーク（例えば、ＬＡＮ２２５）にローカルにセットアップされている典型的な配置で利用されることが好ましく、それにより、複数のテレビ会議サーバが会社全体のネットワーク（例えば、ネットワーク２００）中に存在する。情報交換用メッセージの主な目的の幾つかには、データベースの同期をとること、およびネットワーク・リソースの利用可能性をチェックすることが含まれる。
【００５０】
次のようなメッセージが定義される。
ＱＵＥＲＹ：リモート・サーバ中の項目を照会する。
ＡＤＤ：リモート・サーバに項目を追加する。
ＤＥＬＥＴＥ：リモート・サーバから項目を削除する。
ＵＰＤＡＴＥ：リモート・サーバ上の項目を更新する。
【００５１】
サーバ間メッセージングでは、各サーバ間のＴＣＰベースの接続を使用する。あるサーバの状態が変化したとき、残りのサーバは同じ情報で更新される。
【００５２】
次に、本発明の説明に役立つ一実施例による、テレビ会議サーバ２０５の動作手順について述べる。最初に、テレビ会議セッションのセットアップに対応する動作手順について述べ、その後で、テレビ会議セッションの間の解像度およびフレーム・レート調整に対応する動作手順について述べる。セッション動作手順には、ＳＩＰサーバ発見、メンバ登録、セッション・セットアップ、セッション・キャンセル、セッション終了が含まれる。
【００５３】
次に、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）サーバ発見に対応するセッション動作手順について述べる。ユーザー（テレビ会議クライアント・アプリケーション）は、事前構成済みのテレビ会議サーバ（手動でプロビジョニングされた）に登録するか、または起動時にＲＥＧＩＳＴＥＲ要求を周知の「全てのＳＩＰサーバ」の同報通信アドレス「ｓｉｐ．ｍｃａｓｔ．ｎｅｔ」（２２４．０．１．７５）に送信することにより登録する。第２の機構（ＲＥＧＩＳＴＥＲ要求）は、各ユーザーが自分のテレビ会議クライアント・アプリケーション中でローカルＳＩＰサーバのアドレスを手動で構成する必要がないので、好ましい。この場合、ユーザーがテレビ会議のための正しいＳＩＰサーバに登録中であることを保証するために、同報通信アドレスがネットワーク中で正しく探される必要がある。これらの方法に加えて、プロビジョニング処理をより単純にするための別の方法では、管理者が「ｓｉｐ．ドメイン名」規定を使用して自分のＳＩＰサーバに名前を付けることが、ＳＩＰ仕様で推奨されている（例えばｓｉｐ．ｐｒｉｎｃｅｔｏｎ．ｔｃｅ．ｃｏｍ）。
【００５４】
次に、本発明の説明に役立つ一実施例による、メンバ登録に対応するセッション動作手順について述べる。図７は、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議に登録する方法を示す図である。図７の例は、テレビ会議クライアント・アプリケーション（クライアント）７０２、およびテレビ会議サーバ（サーバ）２０５を含んでいる。本明細書では、「クライアント・アプリケーション」と「クライアント」という語句を交換可能に使用することを理解されたい。
【００５５】
メンバ登録機能において、クライアント７０２は、ＳＩＰ  ＲＥＧＩＳＴＥＲ要求をサーバ２０５に送信する（ステップ７１０）。サーバ２０５は、このメッセージを受信し、クライアント７０２のＩＰアドレスおよびＳＩＰ  ＵＲＬをメンバ・データベース３１４に記憶する。
【００５６】
ＲＥＧＩＳＴＥＲ要求はメッセージ本体を含むことができるが、この使用法は標準方式で定められているわけではない。メッセージ本体は、サーバ２０５に登録中であるクライアント７０２の構成オプションに関係のある追加情報を含んでいてもよい。
【００５７】
サーバ２０５は、クライアント７０２に２００  ＯＫメッセージを返信することにより登録を承認する（ステップ７２０）。
【００５８】
次に、本発明の説明に役立つ実施例による、単一通信および同報通信テレビ会議セッションについて述べる。図１Ｂおよび図１Ｃは、本発明の説明に役立つ２つの実施例による、単一通信テレビ会議セッションおよび同報通信テレビ会議セッションをそれぞれ示すブロック図である。図１Ｂおよび図１Ｃの例は、クライアント１  １３０、クライアント２  １３２、クライアント３  １３４、イーサネット（登録商標）スイッチ１３６、ＩＰルータ１３８およびＩＰルータ１４０、ＷＡＮ１４２を含んでいる。
【００５９】
単一通信の例では、各クライアントから他方の各クライアント毎に、固有のストリームが送信される。このような手法は、ネットワークに加わる参加者が多くなるにつれて多量の帯域幅を使い切る可能性がある。対照的に、同報通信手法では、各クライアントから１つのストリームだけが送信される。従って同報通信手法は、単一通信手法と比較して、帯域幅などのネットワーク・リソースの使用量がより少ない。
【００６０】
次に、本発明の説明に役立つ一実施例による、単一通信テレビ会議セッションのセットアップに対応するセッション動作手順について述べる。図８Ａは、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して単一通信テレビ会議セッションをセットアップする方法を示す図である。図８Ａの例は、テレビ会議クライアント・アプリケーション＃１（クライアント＃１）８０２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）８０６を含んでいる。
【００６１】
ＩＮＶＩＴＥ要求が、クライアント＃１  ８０２からサーバ２０５に送信される（ステップ８１０）。ＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２  ８０６に転送される（ステップ８１５）。
【００６２】
１８０Ｒｉｎｇｉｎｇメッセージが、クライアント＃２  ８０６からサーバ２０５に送信される（ステップ８２０）。１８０Ｒｉｎｇｉｎｇメッセージは、サーバ２０５からクライアント＃１  ８０２に転送される（ステップ８２５）。
【００６３】
２００  ＯＫメッセージが、クライアント＃２  ８０６からサーバ２０５に送信される（ステップ８３０）。２００  ＯＫメッセージは、サーバ２０５からクライアント＃１  ８０２に転送される（ステップ８３５）。
【００６４】
肯定応答メッセージＡＣＫが、クライアント＃１  ８０２からクライアント＃２  ８０６に送信される（ステップ８４０）。テレビ会議セッション（メディア・セッション）が、２つのノード（クライアント＃１  ８０２と＃２  ８０６）との間で行われる（ステップ８４５）。
【００６５】
図８Ｂは、本発明の説明に役立つ一実施例による、ＩＮＶＩＴＥ要求がテレビ会議クライアント・アプリケーション＃１  ８０２から受信されたときに（図８Ａのステップ８１０）テレビ会議サーバ２０５により実施されるステップを示す図である。
【００６６】
サーバ２０５はまず、要求元ユーザー（クライアント＃１  ８０２）がサーバ２０５に登録しているかどうかをチェックし、また、呼び出されているユーザー（クライアント＃２  ８０６）がサーバ２０５に登録しているかどうかをチェックする（ステップ８５０）。
【００６７】
サーバ２０５は、ネットワーク上の各ユーザーの位置を決定し（ステップ８５５）、それらの２つの位置（異なる場合）を接続する低帯域幅ＷＡＮリンク（例えば、ＷＡＮ２５０）があるかどうかを決定する（ステップ８６０）。
【００６８】
２つの位置を共に接続する低帯域幅リンクのＷＡＮがない場合は、サーバ２０５は呼を続行する（ステップ８６５）。しかし、２人のユーザー間に低帯域幅リンクがある場合は、ステップ８７０に進む。
【００６９】
ステップ８７０で、サーバ２０５は、ＷＡＮ２５０上のテレビ会議セッションに対するポリシーをチェックする。これは基本的に、「Ｘ個のセッションを最大ビット・レートＹで実施することができる」と言い換えられる。サーバ２０５は、このポリシーに基づいて利用可能性をチェックする（ステップ８７５）。利用可能性がない場合は、サーバ２０５は、「６００−Ｂｕｓｙ  Ｅｖｅｒｙｗｈｅｒｅ（どこもビジー）」、「４８６−Ｂｕｓｙ  Ｈｅｒｅ（ここはビジー）」、「５０３−Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ（サービス利用不可）」、「６０３−Ｄｅｃｌｉｎｅ（拒否）」の何れかのメッセージを送信することによりＩＮＶＩＴＥ要求を拒否し（ステップ８８０）、本方法は終了する（図８Ａの方法のステップ８１５に進まない）。しかし、利用可能性がある場合は、サーバ２０５は呼を続行する（ステップ８６５）。ステップ８６５の後に、図８Ａの方法のステップ８１５が続くことを理解されたい。
【００７０】
図９は、本発明の説明に役立つ一実施例による、図８Ａの方法を更に示す図である。図９の例は、クライアント・アプリケーション１  ９９８、クライアント・アプリケーション２  ９９７、テレビ会議サーバ２０５、他のテレビ会議サーバ９８６を含んでいる。図９にはテレビ会議サーバ２０５の要素も示されており、これらには、メンバ・データベース３１４と、アクティブ・セッション・データベース３１２と、ネットワーク・アーキテクチャ・データベース３１６に備わるポリシー・データベース９９９と、セッション・マネージャ３２０と、ＳＩＰモジュール３０４ｄと、サーバ間管理モジュール３０４ｅが含まれる。
【００７１】
図９は、テレビ会議サーバ２０５内の内部対話を示すために提供するものであり、従って、テレビ会議サーバ２０５の構成要素間の情報伝送フローの例を提供するために基本的なレベルでのみ示す。
【００７２】
ＩＮＶＩＴＥ要求が、クライアント・アプリケーション１  ９９８から、テレビ会議サーバ２０５内のＳＩＰモジュール３０４ｄに送信される（ステップ９０３）。ＳＩＰモジュール３０４ｄは、メッセージを復号し、ＩＮＶＩＴＥ要求をセッション・マネージャ３２０に転送する（ステップ９０６）。セッション・マネージャ３２０は、アクティブ・セッション・データベース３１２と、メンバ・データベース３１４と、ネットワーク・アーキテクチャ・データベース３１６内のポリシー・データベース９９９とをチェックして、セッションを正しくセットアップできることを確認する（それぞれステップ９０９、９１２、９１５）。セッションを正しくセットアップすることができる場合は、アクティブ・セッション・データベース３１２、メンバ・データベース３１４、およびポリシー・データベース９９９は、ＯＫメッセージをセッション・マネージャ３２０に送信する（ステップ９１８、９２１、９２４）。この検証処理が完了すると、テレビ会議サーバ２０５は、システム状態の変更を他のテレビ会議サーバに通知する（ステップ９２７および９３０）。
【００７３】
セッション・マネージャ３２０は、ＩＮＶＩＴＥメッセージをＳＩＰモジュール３０４ｄに転送し（ステップ９３３）、次いでＳＩＰモジュール３０４ｄは、ＩＮＶＩＴＥメッセージをクライアント・アプリケーション２  ９９７に転送する（ステップ９３６）。クライアント・アプリケーション２  ９９７は、ＩＮＶＩＴＥメッセージを受信すると、ＳＩＰモジュール３０４ｄがＩＮＶＩＴＥメッセージを受信したことを示す１８０Ｒｉｎｇｉｎｇメッセージにより、ＳＩＰモジュール３０４ｄに応答する（ステップ９３９）。１８０Ｒｉｎｇｉｎｇメッセージは、ＳＩＰモジュール３０４ｄにより受信され、復号され、次いでセッション・マネージャ３２０に転送される（ステップ９４２）。図９に示すテレビ会議サーバ２０５内の各データベース中で、クライアント状態が更新される（ステップ９４５、９４８、９５１、９５４、９５７、９５８）。
【００７４】
１８０Ｒｉｎｇｉｎｇメッセージは、セッション・マネージャ３２０からクライアント・アプリケーション１  ９９８に転送される（ステップ９６０および９６３）。次いで、２００  ＯＫメッセージが、クライアント・アプリケーション２  ９９７からＳＩＰモジュール３０４ｄに送信され（ステップ９６６）、ＳＩＰモジュール３０４ｄからセッション・マネージャ３２０に転送される（ステップ９６９）。２００  ＯＫメッセージは、クライアント・アプリケーション２  ９９７がテレビ会議セッションへの招待を受諾していることを示す。
【００７５】
図９に示すテレビ会議サーバ２０５内の各データベース中で、クライアント状態が更新される（ステップ９７２、９７５、９７８、９８１、９８４、９８５）。ＯＫメッセージが、セッション・マネージャ３２０からＳＩＰモジュール３０４ｄに送信され、ＳＩＰモジュール３０４ｄからクライアント・アプリケーション１  ９９８に転送される（ステップ９８８および９９１）。ＡＣＫメッセージが、クライアント・アプリケーション１  ９９８からクライアント・アプリケーション２  ９９７に送信され、セッションのセットアップが終了する（ステップ９９４）。
【００７６】
次に、本発明の説明に役立つ一実施例による、同報通信テレビ会議セッションのセットアップに対応するセッション動作手順について述べる。同報通信セッションのセットアップを提供するためには、セッション記述プロトコル（ＳＤＰ：Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使用する。ＳＤＰプロトコルは、同報通信アドレスおよびポート番号を搬送する。
【００７７】
同報通信セッションのセットアップは、同報通信アドレスが必要なことを除いては、単一通信セッションのセットアップと同様である。同報通信アドレスは、ネットワーク中のＭＡＤＣＡＰサーバ２１５により割り振られる。
【００７８】
図１０は、本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して同報通信テレビ会議セッションをセットアップする方法を示す図である。図１０の例は、テレビ会議クライアント・アプリケーション＃１（クライアント＃１）１００２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）１００６、ＭＡＤＣＡＰサーバ２１５を含んでいる。
【００７９】
ＩＮＶＩＴＥ要求が、クライアント＃１  １００２からサーバ２０５に送信される（ステップ１０１０）。ＭＡＤＣＡＰ要求が、サーバ２０５からＭＡＤＣＡＰサーバ２１５に送信される（ステップ１０１５）。肯定応答メッセージＡＣＫが、ＭＡＤＣＡＰサーバ２１５からサーバ２０５に送信される（ステップ１０２０）。ＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２  １００６に転送される（ステップ１０２５）。
【００８０】
１８０Ｒｉｎｇｉｎｇ（呼出し）メッセージが、クライアント＃２  １００６からサーバ２０５に送信される（ステップ１０３０）。１８０Ｒｉｎｇｉｎｇメッセージは、サーバ２０５からクライアント＃１  １００２に転送される（ステップ１０３５）。
【００８１】
２００  ＯＫメッセージが、クライアント＃２  １００６からサーバ２０５に送信される（ステップ１０４０）。２００  ＯＫメッセージは、サーバ２０５からクライアント＃１  １００２に転送される（ステップ１０４５）。
【００８２】
肯定応答メッセージＡＣＫが、クライアント＃１  １００２からクライアント＃２  １００６に送信される（ステップ１０５０）。テレビ会議セッション（メディア・セッション）が、２つのノード（クライアント＃１  １００２と＃２  １００６）との間で行われる（ステップ１０５５）。
【００８３】
次に、本発明の説明に役立つ一実施例による、テレビ会議セッションのキャンセルに対応するセッション動作手順について述べる。ＣＡＮＣＥＬ（キャンセル）メッセージを使用して、未成立のセッション・セットアップの試みを終了する。クライアントはこのメッセージを使用して、前に開始させてまだ成立させていないテレビ会議セッション・セットアップの試みをキャンセルする。サーバは、ＩＮＶＩＴＥ（招待）が送信されたのと同じ位置に、ＣＡＮＣＥＬメッセージを未成立要求と共に転送する。クライアントは、ＣＡＮＣＥＬメッセージに「２００  ＯＫ」メッセージで応答すべきではない。ＣＡＮＣＥＬメッセージが失敗した場合は、セッション終了シーケンス（即ち、ＢＹＥ（さよなら）メッセージ）を使用する。
【００８４】
図１１は、本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議セッションをキャンセルする方法を示す図である。図１１の例は、テレビ会議クライアント・アプリケーション＃１（クライアント＃１）１１０２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）１１０６を含んでいる。
【００８５】
ＩＮＶＩＴＥ（招待）要求が、クライアント＃１  １１０２からサーバ２０５に送信される（ステップ１１１０）。ＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２  １１０６に転送される（ステップ１１１５）。
【００８６】
１８０Ｒｉｎｇｉｎｇ（呼出し）メッセージが、クライアント＃２  １１０６からサーバ２０５に送信される（ステップ１１２０）。１８０Ｒｉｎｇｉｎｇメッセージは、サーバ２０５からクライアント＃１  １１０２に転送される（ステップ１１２５）。
【００８７】
ＣＡＮＣＥＬ（キャンセル）メッセージが、クライアント＃１  １１０２からサーバ２０５に送信される（ステップ１１３０）。ＣＡＮＣＥＬメッセージは、サーバ２０５からクライアント＃２  １１０６に転送される（ステップ１１３５）。
【００８８】
次に、本発明の説明に役立つ一実施例による、テレビ会議セッションの終了に対応するセッション動作手順について述べる。図１２は、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して２つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１２の例は、第１のクライアント（テレビ会議クライアント・アプリケーション＃１）１２０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアント・アプリケーション＃２）１２０６を含んでいる。
【００８９】
クライアント＃１  １２０２は、クライアント＃２  １２０６との呼を停止することを決定する。従って、クライアント＃１  １２０２は、サーバ２０５にＢＹＥ（さよなら）メッセージを送信する（ステップ１２１０）。サーバ２０５は、クライアント＃２  １２０６にＢＹＥ（さよなら）メッセージを転送する（ステップ１２２０）。
【００９０】
クライアント＃２  １２０６は、２００  ＯＫメッセージをサーバ２０５に返信して、それ（クライアント＃２  １２０６）が切断されたことを示す（ステップ１２３０）。サーバ２０５は、２００  ＯＫメッセージをクライアント＃１  １２０２に転送して、切断の成功を示す（ステップ１２４０）。
【００９１】
図１３は、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１３の例は、第１のクライアント（テレビ会議クライアント・アプリケーション＃１）１３０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアント・アプリケーション＃２）１３０６、第３のクライアント（テレビ会議クライアント・アプリケーション＃３）１３０８を含んでいる。
【００９２】
クライアント＃１  １３０２は、クライアント＃２  １３０６およびクライアント＃３  １３０８との呼を停止することを決定する。これは、クライアント＃２  １３０６とクライアント＃３  １３０８との間のセッションは終了しない。
【００９３】
クライアント＃１  １３０２は、ＢＹＥ（さよなら）メッセージをサーバ２０５に送信する（ステップ１３１０）。サーバ２０５は、ＢＹＥメッセージを解釈し、クライアント＃２  １３０６およびクライアント＃３  １３０８がクライアント＃１  １３０２とのテレビ会議セッションに関わっていることを理解し、ＢＹＥメッセージをクライアント＃２  １３０６とクライアント＃３  １３０８の両方に転送する（ステップ１３２０および１３３０）。
【００９４】
クライアント＃２  １３０６は、２００  ＯＫメッセージをサーバ２０５に返信する（ステップ１３４０）。サーバ２０５は、２００  ＯＫメッセージをクライアント＃１  １３０２に転送し返す（ステップ１３５０）。クライアント＃３  １３０８は、２００  ＯＫメッセージをサーバ２０５に返信する（ステップ１３６０）。サーバ２０５は、２００  ＯＫメッセージをクライアント＃１  １３０２に転送し返す（ステップ１３７０）。
【００９５】
図１４は、本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１４の例は、第１のクライアント（テレビ会議クライアント・アプリケーション＃１）１４０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアント・アプリケーション＃２）１４０６、第３のクライアント（テレビ会議クライアント・アプリケーション＃３）１４０８を含んでいる。
【００９６】
クライアント＃１  １４０２は、クライアント＃２  １４０６およびクライアント＃３  １４０８との呼を停止することを決定する。これは、クライアント＃２  １４０６とクライアント＃３  １４０８との間のセッションは終了しない。
【００９７】
クライアント＃１  １４０２は、クライアント＃２  １４０６に向けたＢＹＥ（さよなら）メッセージをサーバ２０５に送信する（ステップ１４１０）。サーバ２０５は、ＢＹＥメッセージをクライアント＃２  １４０６に転送する（１４２０）。クライアント＃１  １４０２は、クライアント＃３  １４０８に向けたＢＹＥメッセージをサーバ２０５に送信する（１４３０）。サーバ２０５は、ＢＹＥメッセージをクライアント＃３  １４０８に転送する（ステップ１４４０）。
【００９８】
クライアント＃２  １４０６は、２００  ＯＫメッセージをサーバ２０５に返信する（ステップ１４５０）。サーバ２０５は、２００  ＯＫメッセージをクライアント＃１  １４０２に転送し返す（ステップ１４６０）。クライアント＃３  １４０８は、２００  ＯＫメッセージをサーバ２０５に返信する（ステップ１４７０）。サーバ２０５は、２００  ＯＫメッセージをクライアント＃１  １４０２に転送し返す（ステップ１４８０）。
【００９９】
図１２〜図１４に関して前に説明した例に加えて、テレビ会議の加入者が属する同報通信グループ・アドレスにＢＹＥ（さよなら）メッセージを送信することにより終了を引き起こすこともできる。この方法を使用した場合、サーバおよび他のクライアント・アプリケーションはこのメッセージを受信することになる。これは、関連するオーバーヘッドがより少ないため、より全般的で効率的なセッション終了機構である。
【０１００】
次に、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整に対応する動作手順について述べる。テレビ会議は、コンピュータ・ネットワーク上の異なる位置にいる複数のユーザー間で、生の双方向対話式ビデオを伝送することを含んでいる。リアルタイムの対話式ビデオは、制約された遅延で多量の情報を伝送することを必要とする。このために、テレビ会議システムが結合しているコンピュータ・ネットワークは、セッションに関わっている各ユーザーに十分な帯域幅量およびサービス品質を提供できなければならない。帯域幅は、時として限られたリソースである可能性があり、サービス品質は、全てのネットワークで常に保証できるわけではない。従って、幾つかの制限が存在することになる。私設の企業ネットワークでは、サービス品質を保証することは可能だが、多量の帯域幅を常に保証できるわけではない。
【０１０１】
基本的な企業コンピュータ・ネットワーク設備は、低速リンクを介して共に接続された幾つかの高速ローカル・エリア・ネットワーク（ＬＡＮ）を含む（例えば図２参照）。各高速ＬＡＮは通常、単一の地理的位置におけるネットワーク設備を表し、低速リンクは、複数の地理的位置を共に接続する長距離リンクである。低速リンクを使用する理由は、長距離リンクのコストが相対的に高いからであり、また、ほとんどのネットワーク・トラフィックが通常はローカル・エリア・ネットワーク内で局在化され、従って一般には多量のデータがこれらの長距離リンクを介して交換されることはないからである。
【０１０２】
ＩＰベースのネットワークを介したサービス品質における最近の進歩により、現在、これらのネットワークを介して他のタイプの情報を伝送することのできる手段が提供されつつある。これは、リアルタイムでないデータ・トラフィックに加えて、このインフラストラクチャを介してリアルタイムの情報（即ち、音声およびビデオ）を伝送するための扉を開くものである。ネットワークのサービス品質を利用したテレビ会議サービスは、このインフラストラクチャの上に載せるのによく適している。今や、異なる２つの地理的位置にいる２人のユーザーが、リアルタイムのテレビ会議セッションに参加することが可能である。テレビ会議の欠点の１つは、リアルタイム・ビデオの伝送が極度に帯域幅を使い切る可能性があり、状況によりは、利用可能なネットワーク・リソースを容易に使い尽くす可能性があることである。ネットワークを介して伝送されるリアルタイム・ビデオのビット・レートは、主に、使用されるビデオ解像度および圧縮アルゴリズムにより決まる。通常、異なる地理的位置にいる２人、３人、または４人のユーザー間における１つのテレビ会議セッションは、妥当な量の帯域幅を有するネットワーク上で適切にサポートする。しかし一般に、４人を超えるユーザーをテレビ会議セッションに加えることはサポートできておらず、また、第２のテレビ会議セッションも、帯域幅制約が原因でサポートできていない。テレビ会議システムの制限要因は、地理的位置間の低速長距離リンクである。
【０１０３】
可能な解決法の１つは、より多くのユーザーをシステム中でサポートするために、２つの地理的位置間の長距離リンクの帯域幅を増大させることである。この手法の欠点は、帯域幅が非常に高価なことである。第２の解決法は、テレビ会議セッション内の限られた人数のユーザー（即ち、能動的なユーザー）だけが高解像度および高ビット・レートで伝送することが許され、セッション内の残りのユーザー（即ち、受動的なユーザー）は制限されたビット・レートおよび解像度でしか伝送することができないシステムを有することである。テレビ会議セッションの組織者は、どのユーザーが高解像度で伝送し、どのユーザーが低解像度で伝送するかに関する制御権を有することになる。ユーザーがセッションで能動的に会話または対話していない場合は、このユーザーのビデオを高解像度で送信する必要はない。このような手法は、非常に大きな帯域幅節約をもたらすことができる。
【０１０４】
先に進んで図１８Ａのテレビ会議クライアント・アプリケーション１８００を参照すると、この手法は、テレビ会議クライアント・アプリケーション１８００中の、様々なウィンドウ・サイズ（即ち、高解像度と低解像度の復号済みビデオ・ストリームを表示するための各種サイズの表示ウィンドウ）をサポートするユーザー・インタフェース１８０８と、サーバ２０５および他のクライアントのアプリケーションとの間の通信を指定するメッセージング・システム１８４２（ネットワーク構成要素１８０６に含まれる。ネットワーク構成要素１８０６は図１８Ａのテレビ会議クライアント・アプリケーション１８００に含まれる）とを有することを含んでいる。メッセージング・システム１８４２は、各クライアント・アプリケーションの符号化解像度および伝送ビット・レートを制御するメッセージを含むことになる。
【０１０５】
次に、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整に対応するメッセージについて述べる。特に、ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージおよびＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージについて述べる。
【０１０６】
ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージは、クライアントからサーバに送信され、能動的なユーザーと受動的なユーザーとの切替えを示す。即ち、能動的なユーザーは受動的になり、受動的なユーザーは能動的になる。テレビ会議サーバは、クライアントによるこの要求を承認することになる。
【０１０７】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、サーバから各クライアントに送信される。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、クライアントがどの解像度（即ちＣＩＦかＱＣＩＦか）およびどのフレーム・レートで送信すべきかを、クライアントに示すことになる。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、各クライアントにより肯定応答される。
【０１０８】
図１５は、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整のための情報伝送方法を示す図である。図１５の例は、テレビ会議サーバ（サーバ）２０５、クライアント１  １５０４、クライアント２  １５０６、クライアント３  １５０８、クライアント４  １５１０を含んでいる。
【０１０９】
ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨ（メッセージ・ウィンドウ切換え）メッセージが、クライアント１  １５０４からサーバ２０５に送信される（ステップ１５２０）。肯定応答メッセージＡＣＫが、サーバ２０５からクライアント１  １５０４に送信される（ステップ１５２５）。
【０１１０】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（メッセージ調整コーデック）（低）メッセージが、サーバ２０５からクライアント１  １５０４に送信される（ステップ１５３０）。肯定応答メッセージＡＣＫが、クライアント１  １５０４からサーバ２０５に送信される（ステップ１５３５）。
【０１１１】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（高）メッセージが、サーバ２０５からクライアント２  １５０６に送信される（ステップ１５４０）。肯定応答メッセージＡＣＫが、クライアント２  １５０６からサーバ２０５に送信される（ステップ１５４５）。
【０１１２】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（低）メッセージが、サーバ２０５からクライアント３  １５０８に送信される（ステップ１５５０）。肯定応答メッセージＡＣＫが、クライアント３  １５０８からサーバ２０５に送信される（ステップ１５５５）。
【０１１３】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（高）メッセージが、サーバ２０５からクライアント４  １５１０に送信される（ステップ１５６０）。肯定応答メッセージＡＣＫが、クライアント４  １５１０からサーバ２０５に送信される（ステップ１５６５）。
【０１１４】
図１６は、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の前の情報伝送を示す図である。図１７は、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の後の情報伝送を示す図である。図１６および図１７の例は、クライアント１  １６０２、クライアント２  １６０４、ネットワーク・ルータ１６０６、クライアント３  １６０８、クライアント４  １６１０を含んでいる。
【０１１５】
「低ビット・レート／解像度で送る」メッセージが、クライアント１  １６０２からネットワーク・ルータ１６０６に送信される（ステップ１６２０）。「高ビット・レート／解像度で送る」メッセージが、クライアント３  １６０８からネットワーク・ルータ１６０６に送信される（ステップ１６２５）。「低ビット・レート／解像度で送る」メッセージが、クライアント２  １６０４からネットワーク・ルータ１６０６に送信される（ステップ１６３０）。「高ビット・レート／解像度で送る」メッセージが、クライアント４  １６１０からネットワーク・ルータ１６０６に送信される（ステップ１６３５）。
【０１１６】
同報通信アドレスを使用して、データがネットワーク・ルータ１６０６からクライアント２  １６０４、クライアント３  １６０８、クライアント１  １６０２、クライアント４  １６１０に送信される（それぞれステップ１６４０、１６４５、１６５０、１６５５）。
【０１１７】
図１７に進むと、「低ビット・レート／解像度で送る」メッセージが、クライアント１  １６０２からネットワーク・ルータ１６０６に送信される（ステップ１７２０）。「高ビット・レート／解像度で送る」メッセージが、クライアント３  １６０８からネットワーク・ルータ１６０６に送信される（ステップ１７２５）。「高ビット・レート／解像度で送る」メッセージが、クライアント２  １６０４からネットワーク・ルータ１６０６に送信される（ステップ１７３０）。「低ビット・レート／解像度で送る」メッセージが、クライアント４  １６１０からネットワーク・ルータ１６０６に送信される（ステップ１７３５）。
【０１１８】
同報通信アドレスを使用して、データがネットワーク・ルータ１６０６からクライアント２  １６０４、クライアント３  １６０８、クライアント１  １６０２、クライアント４  １６１０に送信される（それぞれステップ１７４０、１７４５、１７５０、１７５５）。
【０１１９】
次に、本発明の説明に役立つ一実施例によるクライアント・アプリケーション・アーキテクチャについて述べる。クライアント・アプリケーションは、ユーザーとの対話、他のクライアント・アプリケーションとのマルチメディア・コンテンツ交換、サーバ・アプリケーションとの呼の管理を担う。図１８Ａは、本発明の説明に役立つ一実施例による、テレビ会議クライアント・アプリケーション１８００のブロック図である。テレビ会議クライアント・アプリケーション１８００は、コンピュータ２２０ａ〜ｆの何れか、および／またはコンピュータ２３０ａ〜ｅの何れかなどのコンピュータ上に見られるものとすることができることを理解されたい。
【０１２０】
テレビ会議クライアント・アプリケーション１８００は、４つの基本的な機能構成要素、即ちマルチメディア・インタフェース層１８０２、コーデック１８０４（音声コーデック１８０４ａおよびビデオ・コーデック１８０４ｂ）、ネットワーク構成要素１８０６、ユーザー・インタフェース１８０８を備えている。
【０１２１】
マルチメディア・インタフェース層１８０２は、テレビ会議クライアント・アプリケーション１８００の主制御インスタンスである。全てのシステム内通信は、マルチメディア・インタフェース層１８０２を介して経路指定され、マルチメディア・インタフェース層１８０２により制御される。マルチメディア・インタフェース層１８０２の基礎をなす重要な特徴の１つは、異なる音声コーデックおよびビデオ・コーデック１８０４を容易に交換できることである。これに加えて、マルチメディア・インタフェース層１８０２は、オペレーティング・システム（ＯＳ）依存のユーザー入出力構成要素およびネットワーク・サブシステムへの、インタフェースも提供する。マルチメディア・インタフェース層１８０２は、メンバ・データベース１８２０、主制御モジュール１８２２、音声ミクサー１８９９、エコー・キャンセル・モジュール１８９８を備えている。
【０１２２】
ユーザー・インタフェース１８０８は、テレビ会議クライアント・アプリケーション１８００との対話ポイントをエンド・ユーザーに提供する。必須ではないが、ユーザー・インタフェース１８０８は、ＯＳ依存のモジュールとして実現することが好ましい。多くのグラフィカル・ユーザー・インタフェース（ＧＵＩ）は、それらが使用している特定のＯＳに依存する。ユーザー・インタフェース１８０８の４つの主要機能は、ビデオ取込み、ビデオ表示、音声取込み、音声再生である。ユーザー・インタフェース１８０８は、音声／ビデオ・キャプチャ・インタフェース１８３０、音声／ビデオ再生モジュール１８３２、メンバ・ビュー・モジュール１８３４、チャット・モジュール１８３６、ユーザー選択／メニュー１８３８を備えている。音声／ビデオ・キャプチャ・インタフェース１８３０は、カメラ・インタフェース１８３０ａ、マイクロホン・インタフェース１８３０ｂ、ファイル・インタフェース１８３０ｃを備えている。音声／ビデオ再生モジュール１８３２は、ビデオ表示１８３２ａ、音声再生モジュール１８３２ｂ、ファイル・インタフェース１８３２ｃを備えている。
【０１２３】
ネットワーク構成要素１８０６は、テレビ会議クライアント・アプリケーション１８００の通信サブシステムを表す。ネットワーク構成要素１８０６の機能は、セッション開始プロトコル（ＳＩＰ）に基づくクライアント−サーバ・メッセージングと、音声およびビデオ・ストリームの送受信である。また、ネットワーク構成要素１８０６は、クライアント間のメディア・ストリームを認証および暗号化通信するための基本的なセキュリティ機能も備えている。ネットワーク構成要素１８０６は、セキュリティ・モジュール１８４０、メッセージング・システム１８４２、ビデオ・ストリーム・モジュール１８４４、音声ストリーム・モジュール１８４６、ＩＰソケット１８４８ａ〜ｃを備えている。
【０１２４】
音声コーデック１８０４ａおよびビデオ・コーデック１８０４ｂは、ディジタル・メディアの圧縮および圧縮解除を扱うサブシステムである。コーデックを交換しやすくするために、コーデックへのインタフェースは単純で一般的なものであるべきである。以下では、マルチメディア・インタフェース層１８０２とコーデック１８０４との間の単純な関係を、実施のための例示的なテンプレートまたはガイドとして定義する。音声コーデック１８０４ａおよびビデオ・コーデック１８０４ｂはそれぞれ、エンコーダ１８８０およびデコーダ１８９０を備えている。エンコーダ１８８０およびデコーダ１８９０はそれぞれ、キュー１８９５を備えている。
【０１２５】
テレビ会議クライアント・アプリケーション１８００は、少なくとも、テレビ会議サーバ２０５および他のクライアント１８７０とインタフェースする。
【０１２６】
次に、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わるメンバ・データベース１８２０について述べる。メンバ・データベース１８２０は、各参加ユーザーに関する情報をセッション毎に記憶する。メンバ・データベース１８２０は、ＩＰアドレスの送受信に関連する情報、クライアントの機能、特定のコーデックに関する情報、種々のユーザーの状態に関する詳細を含んでいる。これらの項目は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、これらの項目の幾つかまたは全てに加えて、またはそれに代えて、他の項目をメンバ・データベース１８２０中に保持することもできることを理解されたい。メンバ・データベース１８２０に含まれる情報を使用して、音声デコーダおよびビデオ・デコーダ１８９０に向けられた入来情報が制御される。ネットワークから入来したメディア情報は、正しい音声デコーダおよびビデオ・デコーダ１８９０に経路指定される必要がある。等しく重要なことだが、音声エンコーダおよびビデオ・エンコーダ１８９０から来たメディア情報は、配信のために正しい単一通信または同報通信アドレスに経路指定される必要がある。メンバ・データベース１８２０に含まれる基本的な情報はまた、エンド・ユーザーがセッションへの参加者および参加者機能を認識できるように、ユーザー・インタフェース１８０８にも経路指定される。ＩＮＶＩＴＥ要求がテレビ会議サーバ２０５から受信されるとすぐに、ユーザーがメンバ・データベース１８２０に追加され、ＢＹＥ要求がテレビ会議サーバ２０５から受信されるとすぐに、ユーザーが削除される。セッションが終了したときは、メンバ・データベース１８２０はフラッシュされる。
【０１２７】
次に、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わる主制御モジュール１８２２について述べる。
【０１２８】
主制御モジュール１８２２は、マルチメディア・インタフェース層１８０２の非常に重要な部分である。主制御モジュール１８２２は、中央管理サブシステムとして働き、以下の重要な機能を提供する。即ち、音声デコーダとビデオ・デコーダのためおよび再生のための同期機構と、記録のためにデコーダの宛先をスクリーンまたはファイルに接続することと、アプリケーション層のサービス品質である。
【０１２９】
最適なテレビ会議ユーザー体験のためには、音声とビデオの再生を同期させることが非常に重要である。２つのメディア・ストリームを正確に同期させるために、タイムスタンプを使用して、これをメディア・コンテンツと共に送信することが必要になる。リアルタイム・プロトコル（ＲＴＰ：Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）は、この目的で、タイムスタンプおよびシーケンス番号を含めるための包括的なヘッダを提供する。提供されるタイムスタンプは、２つのネットワーク・ノード・クロックを同期させるように意図されたものではなく、一貫した再生のために音声とビデオのストリームを同期させるように意図されたものである。これらのタイムスタンプは、取込み時に同じノード上の共通クロックから得る必要がある。例えば、ビデオ・フレームが取り込まれるときは、ビデオ・フレームが取り込まれた時間が記録されなければならない。同じことが音声にも当てはまる。ＲＴＰを使用するためのその他の詳細およびガイドラインについては、本明細書の別の箇所で述べる。
【０１３０】
音声とビデオを同期させる際の主制御モジュール１８２２の機能は、メタデータ（タイムスタンプおよびシーケンス番号を含む）とマルチメディア・データが正しく伝送されるように、ネットワーク構成要素１８０６とコーデック１８０４との間の接続を生成することである。パケットが遅れた場合は、システムの現状態に応答して、復号の前または後でこれらのパケットをドロップする。その後、ＲＴＰタイムスタンプを使用して、提示および再生タイムスタンプを生成する。
【０１３１】
主制御モジュール１８２２はまた、音声デコーダおよびビデオ・デコーダ１８９０の出力を、再生のためにスクリーンに向けて送るか、記録のためにファイルに向けて送るか、この両方を行うことを担う。各デコーダ１８９０は独立して扱われ、従ってこれにより、例示的な状況では、あるデコーダの出力はスクリーンに表示され、第２のデコーダの出力はファイルに記録され、第３のデコーダからの出力はファイルとスクリーンの両方に向かうことが、同時に可能である。
【０１３２】
上述の任務に加えて、主制御モジュール１８２２は、アプリケーション層のサービス品質にも関与する。主制御モジュール１８２２は、パケット・ドロップや送受信されたバイトに関する情報を収集し、この情報に基づいて動作する。これは、ネットワーク中で発生している状況を修復するのを助けるために、別のクライアントまたはテレビ会議サーバ２０５にメッセージを送信することを含む可能性がある。リアルタイム制御プロトコル（ＲＴＣＰ：Ｒｅａｌ  Ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を、統計およびパケット損失を報告するのに使用することができ、また、アプリケーション特有の情報伝送のためにも使用する。
【０１３３】
図１８Ｂは、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わる音声ミクサー１８９９を更に示すブロック図である。音声ミクサー１８９９（本明細書では「利得制御モジュール」とも呼ぶ）は、複数の音声デコーダ１８９０に動作可能になるように結合される。複数の音声デコーダ１８９０は、圧縮音声ストリームを受け取り、圧縮解除済み音声ストリームを出力する。圧縮解除済み音声ストリームは、音声ミクサー１８９９に入力され、合成音声ストリームとして出力される。
【０１３４】
図１８Ｃは、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わるエコー・キャンセル・モジュール１８９８を更に示すブロック図である。エコー・キャンセル・モジュール（本明細書では「エコー・キャンセラ」とも呼ぶ）１８９８は、スピーカ１８９７（例えば、音声再生モジュール１８３２ｂ）およびマイクロホン１８９６（例えば、マイクロホン・インタフェース１８３０ｂ）に動作可能になるように結合される。スピーカ１８９７からの音声が全二重または双方向通信システムで生成されるとき、音声はローカルの聴取者だけに聞こえるように意図される。しかし、生成された音声はローカル・マイクロホン１８９６にも聞こえ、次いでマイクロホン１８９６により、信号は遠方端に返信されてエコーとして聞こえる。このため、この効果を緩和して、それにより、よりよいユーザー体験を生み出すために、テレビ会議クライアント・アプリケーション１８００はエコー・キャンセル・モジュール１８９８を必要とする。
【０１３５】
次に、本発明の説明に役立つ一実施例による、テレビ会議クライアント・アプリケーション１８００のサブシステムに利用可能なインタフェースについて述べる。インタフェースには、ユーザー・インタフェース１８０８、ネットワーク構成要素１８０６、コーデック１８０４との、対話ポイントが含まれる。ユーザー・インタフェース１８０８は、取り込まれた音声およびビデオをそれらに対応するタイムスタンプと共に受け取るための機能を提供する。これに加えて、音声およびビデオを表示再生のためにユーザー・インタフェース１８０８に送るための機能が提供されなければならない。ネットワーク構成要素１８０６インタフェースは、セッション制御およびセキュリティのための入来および送出メッセージを情報伝送するための機能を提供する。音声コーデックおよびビデオ・コーデック１８０４ａ、ｂは、構成制御のための、並びに圧縮または圧縮解除に向けたパケット送受信のための、基本的なインタフェースを提供する。
【０１３６】
次に、本発明の説明に役立つ一実施例による、音声コーデックおよびビデオ・コーデック１８０４ａ、ｂについて述べる。
【０１３７】
テレビ会議で使用するために入手できる音声コーデックおよびビデオ・コーデックには、幾つかのものがある。必須ではないが、本発明により採用されるコーデックはソフトウェアベースであることが好ましい。本発明の説明に役立つ一実施例によれば、一般的なデスクトップ・コンピュータの処理力の制約により、ビデオ圧縮および圧縮解除にはＨ．２６３を使用する。将来、デスクトップ・コンピュータがより強力になるのに伴って、Ｈ．２６Ｌなどのより高度なコーデックを使用する機能を実現してこれを利用する。当然、本発明はこれらのタイプのコーデックに限定されるわけではなく、従って、本発明の趣旨および範囲を維持しながら、他のタイプのコーデックを使用することもできる。
【０１３８】
次に、本発明の説明に役立つ一実施例による、コーデック１８０４ａ、ｂへのインタフェースについて述べる。この記述は、ＤａｔａＩｎ関数、コールバック関数、コーデック・オプションを含んでいる。コーデック１８０４ａ、ｂへのインタフェースは、コーデックを交換できるようにする共にと共に新しいコーデックを将来追加できるように、十分にフレキシブルであるべきであり、且つ一般的に定義されるべきである。このフレキシブルで一般的なインタフェースを実現するための提案インタフェースは、ユーザーに提供される機能の数が限られた、非常に単純なインタフェースである。
【０１３９】
ＤａｔａＩｎ関数は、単純に、エンコーダ・クラスまたはデコーダ・クラスのフレームまたはパケットを記憶するのに使用される。
【０１４０】
マルチメディア・インタフェース層１８０２とマルチメディア・コーデック１８０４との間の単純な接続を提供するために、データ出力関数はコールバックとして実現すべきである。マルチメディア・インタフェース層１８０２は、このコールバック関数を、受信構成要素の入力関数に設定する。例えば、コーデックがフレームの符号化または復号を完了したとき、コーデックは、意図された情報を符号化プロセスまたは復号プロセスから伝送するためにこの関数を呼び出す。コーデックはこのコールバック中に何もできないという制約があるので、この関数は、システム中の待機および不要な遅延を防止するためにできるだけ早く返すべきである。この関数で行われるべき唯一の追加の待機は、共有リソースにアクセスするときの相互排除ロックだけであるべきである。
【０１４１】
種々のタイプのコーデックに利用可能なオプションの範囲は、様々となる。これらのオプションを管理するための要件を満たすために、単純なインタフェースを使用すべきである。文字ベースのインタフェースは、フレキシビリティをもたらすので好ましい（ただし必須ではない）。ＳＴＡＲＴ（スタート）やＳＴＯＰ（ストップ）などの共通コマンド・セットがあるべきであり、更にコーデック特有のコマンドがあるべきである。この方法は単純なインタフェースを提供するが、単純なインタープリタが必要なので、コーデックに更に複雑さが加わる。例えば、Ｏｐｔｉｏｎｓ関数は、オプションを読み書きできるよう十分に一般的なものとする。
例：Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｓｔａｒｔ”）、Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｒｅｓｏｌｕｔｉｏｎ＝ＣＩＦ”）など。
【０１４２】
例えば、コーデック間の共通オプションの幾つかは、開始、停止、一時停止、品質指数（０〜１００）、解像度として標準化されるべきである。
【０１４３】
品質指数（ｑｕａｌｉｔｙ  ｉｎｄｅｘ）は、コーデックの全体的な品質を０％と１００％の間の値として記述する因子である。これは、値が大きいほどビデオ品質が高いという基本的な前提に従う。
【０１４４】
図１９は、本発明の説明に役立つ一実施例による、音声コーデック１８０４ａおよび／またはビデオ・コーデック１８０４ｂに備わるデコーダ１８９０により採用される方法を示す図である。この方法を、デコーダ・コンテキスト１９０１および発呼側コンテキスト１９０２に関して述べる。この方法は、少なくとも以下の入力および出力を使用して動作する。即ち、「データ・イン」１９９９、「信号イン」１９９８、「信号アウト・コールバック」１９９７、「セット・コールバック関数」１９９６、「データ・アウト・コールバック」１９９５である。入力「データ・イン」１９９９を使用して、データを入力キューに記憶する（ステップ１９０５）。
【０１４５】
初期化ステップ（Ｉｎｉｔ）を実施して、デコーダ１８９０を初期化する（ステップ１９１０）。主ループを実行し、開始コマンドまたは終了コマンドを待機する（ステップ１９２０）。終了コマンドを受け取った場合、方法は終了し（ステップ１９２２）、例えば別の動作に戻る（１９２４）。
【０１４６】
入力キュー１８９５からデータを読み出すか、或いは入力キュー１８９５が空の場合は待機状態になる（ステップ１９３０）。ステップ１９３０でデータを読み出した場合、データを復号する（ステップ１９４０）。「データ・アウト・コールバック」１９９５がステップ１９２０に提供される。
【０１４７】
次に、本発明の説明に役立つ一実施例による、ネットワーク２００により採用される通信について述べる。この記述は、ネットワーク通信に関して上述したことを補足するものである。
【０１４８】
メッセージング・システム１８４２（図１８Ａのネットワーク構成要素１８０６に備わる）は、テレビ会議クライアント・アプリケーション１８００とテレビ会議サーバ２０５との間のインタフェースを提供する。これは、セッション管理（即ち、セッションのセットアップおよび終了）に使用されるように意図されている。全ての情報伝送メッセージは、テレビ会議サーバ２０５を介して通信され、クライアントからクライアントに直接通信されることはない。マルチメディア・コンテンツや非公開チャット・メッセージなどのデータは、クライアント間で直接送信される情報だけを含んでいる。メッセージング・システムは、標準方式に基づくセッション開始プロトコル（ＳＩＰ）を使用する。
【０１４９】
テレビ会議クライアント・アプリケーション１８００の機能を統制するプロトコルには、幾つかの異なるプロトコルがある。例えば、セッション開始プロトコル（ＳＩＰ）、リアルタイム・プロトコル（ＲＴＰ）、リアルタイム制御プロトコル（ＲＴＣＰ）、セッション記述プロトコル（ＳＤＰ：Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を採用する。
【０１５０】
セッション開始プロトコル（ＳＩＰ）の目的は、セッション管理である。ＳＩＰは、ＩＰベースのネットワーク上の１人または複数の参加者とのマルチメディア・セッションを生成、変更、終了するための、文字ベースのアプリケーション層制御プロトコルである。ＳＩＰをクライアントとサーバの間で使用して、これを達成する。ＳＩＰについては、上にテレビ会議サーバ２０５に関して更に述べてある。
【０１５１】
リアルタイム・プロトコル（ＲＴＰ）は、リアルタイム・マルチメディア（即ち、音声およびビデオ）の伝送に使用される。ＲＴＰは、搬送中のマルチメディア情報のタイプに関連する追加の詳細を提供するためのアプリケーション層プロトコルである。ＲＴＰは、トランスポート層の上にあり、通常はユーザー・データグラム・プロトコル（ＵＤＰ）の最上部で搬送される。クライアント・アプリケーション中でのＲＴＰの主な機能は、タイムスタンプ（音声とビデオの同期をとるため）、シーケンス番号、並びにそれがカプセル化しているペイロードのタイプ（例えば、ＭＰＥＧ４、Ｈ．２６３、Ｇ．７２３など）の識別をトランスポートすることである。
【０１５２】
図２０は、本発明の説明に役立つ一実施例による、ユーザー・プレーン・プロトコル・スタック２０００を示す図である。スタック２０００は、１つの層上にビデオ２０１０および音声２０２０を含み、別の層上にビデオ２０１０と音声２０２０の両方についてのＲＴＰ２０３０を含み、別の層上にＵＤＰポート＃Ｘ２０４０およびＵＤＰポート＃Ｙ２０５０を含み、更に、ＩＰ層２０６０、リンク層２０７０、物理層２０８０を含んでいる。包括的なＲＴＰヘッダに加えて、コーデック特有のＲＴＰヘッダが使用される。
【０１５３】
リアルタイム制御プロトコル（ＲＴＣＰ）は、ＲＴＰ標準方式の一部である。ＲＴＣＰは、送信側と受信側の間の統計報告ツールとして使用される。各テレビ会議クライアント・アプリケーション１８００は、その統計を収集し、相互に送信すると共にサーバ２０５に送信する。テレビ会議サーバ２０５は、このデータに基づいて、セッション中に生じた問題に関する情報を記録する。
【０１５４】
図２１は、本発明の説明に役立つ一実施例による、制御プレーン・プロトコル・スタック２１００を示す図である。スタック２１００は、１つの層上にＳＩＰ２１１０、ＵＩコーデック変更メッセージング２１２０、ＲＴＣＰ２１３０を含み、更にＴＣＰ層２１４０、ＩＰ層２１５０、リンク層２１６０、物理層２１７０を含んでいる。
【０１５５】
セッション記述プロトコル（ＳＤＰ）の主な目的は、セッションのメディア・ストリームに関する情報を搬送することである。ＳＤＰは、限定しないが以下の項目を含んでいる。即ち、セッション名および目的、セッションがアクティブな時間、セッションを含むメディア、メディアを受信するための情報（即ち、アドレス、ポート、フォーマットなど）、メディアのタイプ、トランスポート・プロトコル（ＲＴＰ／ＵＤＰ／ＩＰ）、メディアのフォーマット（Ｈ．２６３など）、同報通信、メディアの同報通信アドレス、メディアのトランスポート・ポート、単一通信、メディアのリモート・アドレスである。
【０１５６】
セッション記述プロトコル（ＳＤＰ）情報は、ＳＩＰメッセージのメッセージ本体である。これらは共に伝送される。
【０１５７】
次に、本発明の説明に役立つ一実施例による、図１８Ａのユーザー・インタフェース１８０８について更に述べる。ユーザー・インタフェース１８０８は、テレビ会議クライアント・アプリケーション１８００の非常に重要な要素である。ユーザー・インタフェース１８０８は、複数のビュー（表示装置／ボタン／メニュー／．．．）を含み、全ての入力データ（音声／ビデオ・キャプチャ、ボタン、キーストローク）を扱うことができる。
【０１５８】
図２２は、本発明の説明に役立つ一実施例による、図１８Ａのユーザー・インタフェース１８０８に対応するスクリーン・ショット２２００を示すブロック図である。スクリーン・ショット２２００は、「大きいビュー」２２１０、「小さいビュー」２２２０、チャット・ビュー部分２２３０、メンバ・ビュー部分２２４０、チャット編集部分２２５０を含んでいる。
【０１５９】
再び図１８Ａを参照すると、ビデオ・キャプチャ・インタフェース１８３０は、ウェブ・カム（図示せず）、キャプチャ・カードおよび高品質カメラ（図示せず）、カメラ・インタフェース１８３０ａ、マイクロホン・インタフェース１８３０ｂ、ファイル・インタフェース１８３０ｃなどのうちの何れかを備えるものとする。
【０１６０】
ウェブ・カムは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムにより提供されるビデオ・フォー・ウィンドウズ（登録商標）（ＶＦＷ：Ｖｉｄｅｏ  Ｆｏｒ  Ｗｉｎｄｏｗｓ（登録商標））アプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用して、或いはＬｉｎｕｘなどの異なるオペレーティング・システムの下で使用される他のキャプチャ・ドライバにより、ＵＳＢまたはＦｉｒｅＷｉｒｅ（ＩＥＥＥ１３９４）インタフェースを介してサポートされるべきである。当然ながら本発明は、これらのインタフェース、オペレーティング・システム、またはドライバに限定されるわけではなく、従って、本発明の趣旨および範囲を維持しながら、他のインタフェース、オペレーティング・システム、およびドライバを使用することもできる。
【０１６１】
メンバ・ビュー・モジュール１８３４は、進行中の呼に参加しているメンバを表示するのに使用される。呼の開始者（即ち、マスタ）は、不要なメンバをドロップするか、または能動的なメンバを選択する。あらゆるメンバは、非公開チャット・メッセージを交換するために１人または複数のメンバを選択する。更に、メンバ・ビュー・モジュール１８３４中では、メンバの状態が信号で伝えられる。この場合、メンバは自分自身の状態を設定する。例えば、「退席中」に設定して、現在は参加できないがすぐに戻ることを他者に信号で伝えることができる。
【０１６２】
ビデオ・ストリームに加えて、あらゆるメンバは、チャット・モジュール１８３６を使用して他のメンバの全員または何人かだけにチャット・メッセージを送信する機会も有する。メッセージは、チャット・ビュー中に表示され、チャット編集ビュー中で編集される。スクロールバーで、より古いメッセージを見ることができる。
【０１６３】
次に、本発明の説明に役立つ一実施例による、クライアント・アプリケーション１８００についての動作手順について述べる。以下の記述は、単にクライアント・アプリケーション１８００の幾つかの機能の基本的なガイドラインであり、全ての機能を列挙して表すものではない。この記述は、ログイン、呼の開始、呼の受諾、ログオフを含んでいる。
【０１６４】
ログインは、クライアント・アプリケーション１８００が最初に起動されたときに行われる。ログインは、起動時にオペレーティング・システムに提供されたログイン名に基づいて自動的に行われるものとしてもよく、ログインから独立した別のインタフェースを使用してもよい。これは、現在使用中のネットワークに対して好ましい認証方法、およびどのようにポリシーが管理されるかにより決まる。最も単純な方法は、ウィンドウズ（登録商標）オペレーティング・システムで使用されるのと同じログイン名を使用して、名前付けの一貫性を維持し、また既存のユーザー・データベースを再利用（適切なら）できるようにすることであろう。
【０１６５】
図２３は、本発明の説明に役立つ一実施例による、ログイン・インタフェース２３００を示す図である。ユーザーが現在、サーバ上にアカウントを持っていない場合は、サインアップ機能２３３０を使用する。アクセスを容易にするために、任意の電子メール・アドレス入力ボックス２３４０に電子メール・アドレスを提供する。
【０１６６】
呼を開始するために、クライアント・アプリケーション１８００は、参加可能な候補のリストをサーバ２０５に照会する。クライアントは、テレビ会議セッションに参加させたいと思うユーザーを選択する。２人の参加者が関与する場合は、セッションは単一通信としてセットアップされる。そうではなく、３人以上の参加者が関与する場合は、セッションは同報通信としてセットアップされる。
【０１６７】
図２４は、本発明の説明に役立つ一実施例による、セッションを開始するためのユーザー選択インタフェース２４００を示すブロック図である。
【０１６８】
ユーザーが呼に招待されると、開始者の名前を示すメッセージがユーザーのスクリーンに表示される。次いでユーザーは、呼を受諾するか拒否する。ユーザーが呼を受諾した場合、次いでクライアント・アプリケーション１８００は、受諾（または肯定応答）メッセージをサーバ２０５に送信する。次いでサーバ２０５は、呼に現在参加しているあらゆるメンバに、新しいメンバを通知する。ユーザーがキャンセル・メッセージをサーバ２０５に送信することにより呼を拒否した場合は、他の全てのメンバにもこのイベントが通知される。図２５は、本発明の説明に役立つ一実施例による、入来呼を受諾または拒否するための招待インタフェース２５００を示すブロック図である。
【０１６９】
ログオフの場合、テレビ会議サーバ２０５のデータベース構成要素３０２に備わるメンバ・データベース３１４からユーザーを削除する。ＢＹＥメッセージが、セッションの各参加クライアントに送信される。これは、同報通信と単一通信のどちらかにより行うことができる。このメッセージを送信するのに好ましい方法は、同報通信である。
【０１７０】
本発明は、テレビ会議アプリケーションのためのユーザー・インタフェースを提供し、このユーザー・インタフェースは、複数のビデオ表示ウィンドウ・サイズ（高解像度と低解像度の復号済みビデオ・ストリームを表示するための各種サイズの表示ウィンドウ）をサポートする。更に本発明は、テレビ会議セッションを制御するクライアントまたはネットワーク装置から送信されたメッセージに基づいてサーバが個々のクライアントのビデオ符号化パラメータを制御できるようにするメッセージング・システムも提供する。このユーザー・インタフェースおよびメッセージング・システムは、テレビ会議セッション内の限られた人数のユーザー（即ち、能動的なユーザー）だけが高解像度および高ビット・レートで伝送することが許され、テレビ会議セッション内の残りのユーザー（即ち、受動的なユーザー）は制限されたビット・レートおよび解像度でしか伝送することができない環境を生み出す。テレビ会議セッションに能動的に参加していないユーザーにはビデオを高解像度および高ビット・レートで送信しないようにすることにより、ネットワーク中の帯域幅をより効率的に使用する。本明細書では、このユーザー・インタフェースおよびメッセージング・システムをまとめて「再生制御システム」とも呼ぶ。本明細書では、「能動的なユーザー」と「能動的な参加者」という語句を交換可能に使用することを理解されたい。更に、本明細書では「受動的なユーザー」と「受動的な参加者」という語句を交換可能に使用することも理解されたい。能動的な参加者は、テレビ会議セッションに能動的に関与（例えば、会話）している者であり、対照的に受動的な参加者は、テレビ会議セッションに能動的に関与していない者である。
【０１７１】
本発明の説明に役立つ一実施例では、テレビ会議セッション制御者（以下「セッション制御者」とする）が、どのユーザーが高解像度で伝送し、どのユーザーが低解像度で伝送するかに関する制御権を有することになる。説明に役立つ実施例では、セッション制御者は、テレビ会議セッションへの（他の）参加者のユーザー・インタフェースよりも高度なユーザー・インタフェースを有し、それによりセッション制御者は、どの参加者が能動的な参加者であってどの参加者が受動的な参加者であるかを選択する。セッション制御者は、テレビ会議セッションの開始者、または他の何らかの人物（テレビ会議セッションへの別の参加者、更には非参加者も含まれる）とする。本発明の説明に役立つ実施例を単一のセッション制御者に関して述べるが、本発明は複数のセッション制御者でも容易に実現できることを理解されたい。更に、本明細書では、能動的なユーザーと受動的なユーザーの選択を２つの異なるユーザー・インタフェース（一方（より高度）はセッション制御者用、他方はテレビ会議の（他の）参加者用）に関して述べるが、当業者なら、本発明の趣旨および範囲を維持しながら、その他の数のユーザー・インタフェース、並びにその他の構成および実現形態のユーザー・インタフェースも容易に実現することができる。セッション制御者のユーザー・インタフェースについては図２７に関して後述し、（他の）参加者のユーザー・インタフェースについては図２６に関して後述する。
【０１７２】
図２６は、本発明の説明に役立つ一実施例による、ユーザー・インタフェース２６００を示すブロック図である。本発明の説明に役立つ実施例によれば、ユーザー・インタフェース２６００は、テレビ会議システムで異なる解像度をサポートするために、２つの異なるサイズの表示ウィンドウを備えている。例示のために、２つの異なるウィンドウ・サイズは、高解像度用の３５２×２８８ウィンドウ２６３０と、低解像度用の８８×７２ウィンドウ２６４０として選択されている。本発明は、これらの数の異なるウィンドウ・サイズに限定されるわけではなく、これらの解像度に限定されるわけでもなく、従って、本発明の趣旨および範囲を維持しながら、その他の数の異なるウィンドウ・サイズ、およびその他の解像度を採用することもできることを理解されたい。即ち、本明細書に提供する本発明の開示があれば、当業者なら、本発明の趣旨および範囲を維持しながら、本発明に関するこれらおよび他の様々な構成および実現形態を容易に考案するであろう。
【０１７３】
説明に役立つ実施例では、２人の主参加者（即ち能動的な参加者）が、高い方の解像度で符号化および伝送しており、これらは大きい方のウィンドウに表示される。残りの参加者（即ち受動的な参加者）は、低い方の解像度で符号化および伝送しており、これらは小さいほうのウィンドウに表示される。
【０１７４】
図２７は、本発明の説明に役立つ別の実施例による、ユーザー・インタフェース２７００を示すブロック図である。本発明の説明に役立つ実施例によれば、テレビ会議セッションのセッション制御者は、複数の参加者のうちの誰がテレビ会議セッションにおける主（即ち能動的な）参加者になるかを自分で選択することが可能な、より高度なユーザー・インタフェースを有することになる。本発明の説明に役立つ実施例によれば、セッション制御者は、自分のスクリーンの右側にあるウィンドウ２６４０の１つ（低解像度ウィンドウの１つ）を選択することにより、主参加者を選択する。この画像をダブルクリックすることにより、またはドラッグアンドドロップ処理により、選択された参加者が低解像度モードから高解像度モードに切り替わる。次いで、現在高解像度モードにある参加者の１人が低解像度モードに切り替わる。ユーザー・インタフェース２７００は、高解像度用の３５２×２８８ウィンドウ２６３０および低解像度用の８８×７２ウィンドウ２６４０に加えて、文字チャット・ウィンドウ２７５０および状態ウィンドウ２７６０も備えている。
【０１７５】
テレビ会議セッションの参加者が能動的なユーザーになりたいと思っていることをセッション制御者に通知することができるように、ページング・ボタン２７９０などの追加機能を使用する。次いでセッション制御者は、手動でこの参加者を高解像度モードに切り替えることができる。或いは、これは自動化された処理により行われてもよい。
【０１７６】
図１５に戻るが、メッセージ「ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨ」が、クライアント（例えばセッション制御者）からサーバ２０５に送信される。ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージを使用して、２人の参加者が解像度を切り替えつつあることをサーバに通知する。即ち、１人の参加者が高解像度から低解像度に切り替え、別の参加者が低解像度から高解像度に切り替えている。従って、２人の参加者は、能動的な参加者と受動的な参加者としての役割を交換する。ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージは、セッション制御者が新しい能動的な参加者を選択したときに生成される。サーバ２０５がＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージを受信すると、サーバ２０５は、このメッセージを処理し、セッションに参加している各クライアントにメッセージ（ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ）を送出する。
【０１７７】
「ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ」メッセージは、サーバ２０５からテレビ会議セッション内の各クライアントに送信される。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、各クライアントがどのビット・レートで伝送すべきか（例えば高ビット・レートか低ビット・レートか）を各クライアントに通知する。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージはまた、高ビット・レートで伝送するクライアントのＩＰアドレスも含んでいる。この情報を使用して、各入来ビデオ・ストリームがユーザー・インタフェース上のどのウィンドウに表示されるかが決定される。
【０１７８】
従って、上述した図１６および１７は、２人の参加者（クライアント２と３）を能動的な参加者と受動的な参加者との間で切り替える前と後の、ネットワーク中のデータ伝送をそれぞれ表す。図１５は、この切替えを実施するために採用される情報伝送を示す。
【０１７９】
本明細書では、説明に役立つ実施例を添付の図面に関して述べたが、本発明はこれらの正確な実施例に限定されるわけではなく、当業者なら本発明の範囲または趣旨を逸脱することなく他の様々な変更および修正を加えることができることを理解されたい。このような変更および修正も全て、特許請求の範囲により定義する本発明の範囲に含まれるものとする。
【図面の簡単な説明】
【０１８０】
【図１Ａ】本発明の説明に役立つ一実施例による、本発明を適用することのできるコンピュータ・システム１００を示すブロック図である。
【図１Ｂ】本発明の説明に役立つ一実施例による、単一通信テレビ会議セッションを示すブロック図である。
【図１Ｃ】本発明の説明に役立つ一実施例による、同報通信テレビ会議セッションを示すブロック図である。
【図２】本発明の説明に役立つ一実施例による、本発明を適用することのできるネットワーク２００を示すブロック図である。
【図３】本発明の説明に役立つ一実施例による、図２のテレビ会議サーバ２０５を示すブロック図である。
【図４】本発明の説明に役立つ一実施例による、図３のデータベース構成要素に備わるメンバ・データベース３１４のメンバ・データベース項目４００を示す図である。
【図５】本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるアクティブ・セッション・データベース３１２のアクティブ・セッション項目５００を示すブロック図である。
【図６】本発明の説明に役立つ一実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント−サーバ・アーキテクチャ６００を示すブロック図である。
【図７】本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議に登録する方法を示す図である。
【図８Ａ】本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して単一通信テレビ会議セッションをセットアップする方法を示す図である。
【図８Ｂ】本発明の説明に役立つ一実施例による、ＩＮＶＩＴＥ要求がテレビ会議クライアント・アプリケーション＃１  ８０２から受け取られたとき（図８Ａのステップ８１０）に図２のテレビ会議サーバ２０５により実施されるステップを示す図である。
【図９】本発明の説明に役立つ一実施例による、図８Ａの方法を更に示す図である。
【図１０】本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して同報通信テレビ会議セッションをセットアップする方法を示す図である。
【図１１】本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議セッションをキャンセルする方法を示す図である。
【図１２】本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して２つのクライアント間のテレビ会議セッションを終了する方法を示す図である。
【図１３】本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。
【図１４】本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。
【図１５】本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整のための情報伝送方法を示す図である。
【図１６】本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の前の情報伝送を示す図である。
【図１７】本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の後の情報伝送を示す図である。
【図１８Ａ】本発明の説明に役立つ一実施例による、テレビ会議クライアント・アプリケーション１８００のブロック図である。
【図１８Ｂ】本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれる音声ミクサー１８９９を更に示すブロック図である。
【図１８Ｃ】本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれるエコー・キャンセル・モジュール１８９８を更に示すブロック図である。
【図１９】本発明の説明に役立つ一実施例による、音声コーデック１８０４ａおよび／またはビデオ・コーデック１８０４ｂに備わるデコーダ１８９０により採用される方法を示す図である。
【図２０】本発明の説明に役立つ一実施例による、ユーザー・プレーン・プロトコル・スタック２０００を示す図である。
【図２１】本発明の説明に役立つ一実施例による、制御プレーン・プロトコル・スタック２１００を示す図である。
【図２２】本発明の説明に役立つ一実施例による、図１８Ａのユーザー・インタフェース１８０８に対応するスクリーン・ショット２２００を示すブロック図である。
【図２３】本発明の説明に役立つ一実施例による、ログイン・インタフェース２３００を示す図である。
【図２４】本発明の説明に役立つ一実施例による、セッションを開始するためのユーザー選択インタフェース２４００を示すブロック図である。
【図２５】本発明の説明に役立つ一実施例による、入来呼を受諾または拒否するための招待インタフェース２５００を示すブロック図である。
【図２６】本発明の説明に役立つ一実施例による、ユーザー・インタフェース２６００を示すブロック図である。
【図２７】本発明の説明に役立つ一実施例による、ユーザー・インタフェース２７００を示すブロック図である。
【図１Ａ】
2005534207.tif 000003
【図１Ｂ】
2005534207.tif 000004
【図１Ｃ】
2005534207.tif 000005
【図２】
2005534207.tif 000006
【図３】
2005534207.tif 000007
【図４】
2005534207.tif 000008
【図５】
2005534207.tif 000009
【図６】
2005534207.tif 000010
【図７】
2005534207.tif 000011
【図８Ａ】
2005534207.tif 000012
【図８Ｂ】
2005534207.tif 000013
【図９】
2005534207.tif 000014
【図１０】
2005534207.tif 000015
【図１１】
2005534207.tif 000016
【図１２】
2005534207.tif 000017
【図１３】
2005534207.tif 000018
【図１４】
2005534207.tif 000019
【図１５】
2005534207.tif 000020
【図１６】
2005534207.tif 000021
【図１７】
2005534207.tif 000022
【図１８Ａ】
2005534207.tif 000023
【図１８Ｂ】
2005534207.tif 000024
【図１８Ｃ】
2005534207.tif 000025
【図１９】
2005534207.tif 000026
【図２０】
2005534207.tif 000027
【図２１】
2005534207.tif 000028
【図２２】
2005534207.tif 000029
【図２３】
2005534207.tif 000030
【図２４】
2005534207.tif 000031
【図２５】
2005534207.tif 000032
【図２６】
2005534207.tif 000033
【図２７】
2005534207.tif 000034
【国際調査報告】
2005534207.tif 000035
2005534207.tif 000036