(57)【要約】  多地点会議の制御および管理用のシステムおよび方法が、本明細書で開示され、エンドポイントが、それらに送信されることになるストリームを選択的かつ個別に管理可能である。送信エンドポイントが、他の受信エンドポイントから情報を、または、サーバから集約されたそのような情報を収集し、それらを、それが次いでその動作のために使用する単一の組の動作パラメータに処理することを可能にする技法が説明されている。会議レベル表示、オンデマンド表示、表示パラメータの集約および伝搬、通知の伝搬を遂行するためのアルゴリズムが説明されている。表示要求でソースを記述するために識別されるパラメータは、ビットレート、ウィンドウサイズ、画素レート、および1秒あたりのフレームを含む。
2013543306.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークによって、メディアデータを送信または受信するための、1つまたは複数のエンドポイントと、
前記通信ネットワークによって、前記1つまたは複数のエンドポイントに、および相互に結合される、1つまたは複数のサーバとを備え、
前記1つまたは複数のサーバが、
直接、または前記1つもしくは複数のサーバを介して前記1つまたは複数のエンドポイントのうちの第1のエンドポイントから要求を受信すると、前記1つまたは複数のエンドポイントのうちの第2のエンドポイントからのメディアデータを提供するために、直接、または前記1つもしくは複数のサーバを介して前記1つまたは複数のエンドポイントのうちの前記第2のエンドポイントに前記要求を転送し、かつ、
直接、または前記1つもしくは複数のサーバを介して、前記1つまたは複数のエンドポイントのうちの前記第2のエンドポイントからメディアデータを受信すると、直接、または前記1つもしくは複数のサーバを介して、前記1つまたは複数のエンドポイントのうちの前記第1のエンドポイントに前記メディアデータを転送するように構成され、
前記1つまたは複数のエンドポイントが、
メディアデータを提供するために、1つまたは複数のエンドポイントのうちの1つから前記要求を受信すると、直接、または前記1つもしくは複数のサーバを介して、メディアデータを要求した、前記1つまたは複数のエンドポイントのうちの前記1つにメディアデータを送信することを開始するように構成される、
視聴覚通信システム。
【請求項２】
前記要求の前記転送すること、およびメディアデータの前記転送することが、前記1つまたは複数のサーバにより維持される経路指定情報によって遂行される、請求項1に記載のシステム。
【請求項３】
前記要求が、1つまたは複数のメディアパラメータを含み、前記1つまたは複数のエンドポイントが、前記要求を受信すると、それらの送信されるメディアデータを調整するために、前記パラメータを使用するようにさらに構成される、請求項1に記載のシステム。
【請求項４】
前記1つまたは複数のメディアパラメータが、ウィンドウサイズ、ビットレート、画素レート、および1秒あたりのフレームのうちの少なくとも1つを含む、請求項3に記載のシステム。
【請求項５】
前記1つまたは複数のサーバが、同じエンドポイントに転送されることになる要求からの、複数の組の受信されたメディアパラメータを、次いで前記エンドポイントに転送される、単一の組のメディアパラメータに組み合わせるように構成される、請求項3に記載のシステム。
【請求項６】
通信ネットワークによって、メディアデータを送信または受信するための、1つまたは複数のエンドポイントと、
前記通信ネットワークによって、前記1つまたは複数のエンドポイントに、および相互に結合される、1つまたは複数のサーバとを備え、
前記1つまたは複数のサーバが、
直接、または前記1つもしくは複数のサーバを介して前記1つまたは複数のエンドポイントのうちの第1のエンドポイントから要求を受信すると、前記1つまたは複数のエンドポイントの選択された部分集合からのメディアデータを提供するために、前記選択を適用し、かつ、直接、または前記1つもしくは複数のサーバを介して、それが現在受信している、前記1つまたは複数のエンドポイントの前記選択された部分集合からのメディアデータを、それを要求した、前記1つまたは複数のエンドポイントのうちの前記第1のエンドポイントに転送するように構成される、
視聴覚通信システム。
【請求項７】
前記1つまたは複数のサーバが、要求を受信すると、それらが結合されている他のサーバに前記要求を転送するようにさらに構成される、請求項6に記載のシステム。
【請求項８】
前記要求の前記転送することが、前記1つまたは複数のサーバにより維持される経路指定情報を使用して遂行される、請求項7に記載のシステム。
【請求項９】
前記1つまたは複数のサーバが、前記1つまたは複数のエンドポイントの前記選択された部分集合を算出するようにさらに構成される、請求項6に記載のシステム。
【請求項１０】
前記算出が、1人または複数の直近の活動的な話者のリストをコンピュータ処理する、請求項9に記載のシステム。
【請求項１１】
前記1つまたは複数のサーバが、外部手段から、前記選択された部分集合の算出を得るようにさらに構成される、請求項6に記載のシステム。
【請求項１２】
前記外部手段が、音声ブリッジである、請求項11に記載のシステム。
【請求項１３】
前記要求が、1つまたは複数の選択パラメータを含む、請求項6に記載のシステム。
【請求項１４】
前記選択パラメータが、直近の活動的な話者の数を含む、請求項13に記載のシステム。
【請求項１５】
視聴覚通信用の方法であって、サーバにおいて、
第2のエンドポイントからのメディアデータを提供するために、直接、または別のサーバを介して、第1のエンドポイントから要求を受信するステップと、
直接、または別のサーバを介して、前記第2のエンドポイントに前記要求を転送するステップと、
直接、または別のサーバを介して、前記第2のエンドポイントからメディアデータを受信するステップと、
直接、または前記1つもしくは複数のサーバを介して、前記第1のエンドポイントに前記メディアデータを転送するステップと
を含む、方法。
【請求項１６】
前記方法が、前記第2のエンドポイントにおいて、
メディアデータを提供するために、前記第1のエンドポイントから前記要求を受信するステップと、
直接、または前記1つもしくは複数のサーバを介して、前記第1のエンドポイントにメディアデータを送信するステップと
をさらに含む、請求項15に記載の方法。
【請求項１７】
前記要求を転送するステップ、およびメディアデータを転送するステップが、前記サーバにより維持される経路指定情報によって遂行される、請求項15に記載の方法。
【請求項１８】
前記要求が、1つまたは複数のメディアパラメータを含み、前記第2のエンドポイントが、前記要求を受信すると、それらの送信されるメディアデータを調整するために、前記パラメータを使用するようにさらに構成される、請求項16に記載の方法。
【請求項１９】
前記1つまたは複数のメディアパラメータが、ウィンドウサイズ、ビットレート、画素レート、または1秒あたりのフレームのうちの1つまたは複数を含む、請求項18に記載の方法。
【請求項２０】
前記サーバが、前記第2のエンドポイントに転送されることになる要求からの、複数の組の受信されたメディアパラメータを、単一の組のメディアパラメータに組み合わせ、次いで前記単一の組を前記エンドポイントに転送するように構成される、請求項18に記載の方法。
【請求項２１】
視聴覚通信用の方法であって、サーバにおいて、
エンドポイントの選択された部分集合からのメディアデータを提供するために、直接、または別のサーバを介して、第1のエンドポイントから要求を受信するステップと、
前記選択を適用するステップと、
直接、または前記1つもしくは複数のサーバを介して、それが現在受信している、エンドポイントの前記選択された部分集合からのメディアデータを、前記第1のエンドポイントに転送するステップと
を含む、方法。
【請求項２２】
前記サーバが、要求を受信すると、それが接続されている他のサーバに前記要求を転送するようにさらに構成される、請求項21に記載の方法。
【請求項２３】
前記要求の前記転送するステップが、前記サーバにより維持される経路指定情報を使用して遂行される、請求項22に記載の方法。
【請求項２４】
前記サーバが、エンドポイントの前記選択された部分集合を算出するようにさらに構成される、請求項21に記載の方法。
【請求項２５】
前記算出が、1人または複数の直近の活動的な話者のリストをコンピュータ処理する、請求項24に記載の方法。
【請求項２６】
前記1つまたは複数のサーバが、外部手段から、前記選択された部分集合の算出を得るようにさらに構成される、請求項21に記載の方法。
【請求項２７】
前記外部手段が、音声ブリッジである、請求項26に記載の方法。
【請求項２８】
要求が、1つまたは複数の選択パラメータを含む、請求項21に記載の方法。
【請求項２９】
前記選択パラメータが、直近の活動的な話者の数を含む、請求項28に記載の方法。
【請求項３０】
請求項15から29の少なくとも一項に記載の方法を遂行するための1組の命令を備える、非一時的なコンピュータ可読記録メディア。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、その全体が本明細書に参照により組み込まれている、2010年9月20日に出願した、米国仮特許出願第61/384,634号の利益を主張するものである。
【０００２】
本出願は、多地点会議の管理および制御に関する。特に、本出願は、0、1つまたは複数のサーバを含み得る多地点会議における参加者を追加または除去し、他の参加者からコンテンツまたは特定のコンテンツタイプを、選択的かつ動的に受信し、会議の状態の変化に関する通知を受信する等のための機構に関する。
【背景技術】
【０００３】
音声および映像の、通信および会議の分野では、過去30年にわたって著しい成長を経験してきた。インターネットが利用できること、ならびに、音声および映像のコーデックの設計での継続的な改善によって、音声または映像ベースのサービスが急増する結果になった。今日、だれでも、インターネット接続が存在する世界中の任意の場所から、音声、音声を伴う映像、およびマルチメディア(例えば、映像、音声、およびプレゼンテーション)を使用する、2地点間および多地点の通信セッションを行うことを可能にする、システムおよびサービスが存在する。これらのサービスの一部は、公に入手可能な規格(例えば、SIP、H.323、XMPP)に基づくものであり、一方で他のものは、プロプライエタリである(例えば、Skype)。これらのシステムおよびサービスは、インスタントメッセージング(「IM」)ソリューション、すなわち、ユーザが、他のユーザがオンラインであるかどうかを確認し(いわゆる「プレゼンス」の特徴的機能)、その人たちとテキストチャットを行うことを可能にするシステムによって供与されることが多い。音声および映像は、アプリケーションにより供与される追加的な特徴的機能となる。他のシステムでは、別個のシステムがテキストチャットの特徴的機能のために使用されることになることを想定して、映像および音声を専一に重点的に取り扱う(例えば、VidyoのVidyoDesktop)。
【０００４】
これらの通信システムを利用できることで、結果として、これらのシステムでの信号通信用の、熟慮された仕様を利用できることになった。例えば、SIP、H.323、さらにXMPPは、セッションをセットアップおよび解体し、送信器と受信器との間でシステムパラメータをネゴシエーションし、かつ、プレゼンス情報を管理する、または構造化データを送信する、信号通信用の広く使用されているファシリティである。SIPは、RFC 3261で規定され、勧告H.323は、国際電気通信連合から入手可能であり、XMPPは、RFC 6120、6121、および6122、ならびに、XMPPスタンダーズファウンデーション(XMPP Standards Foundation)により示されるXMPP拡張(XEP)で規定され、すべての参考文献は、それらの全体が参照により本明細書に組み込まれている。
【０００５】
これらのアーキテクチャは、総合的なシステムがどのように作動するはずであるかに関する、いくつかの想定を用いて設計されてきた。SIPまたはH.323などの、音声または視聴覚の通信に基づいている(すなわち、それらのために本来設計された)システムに対して、設計者は、システムがどのように動作するかの多少とも静的な構成、すなわち、映像解像度、フレームレート、ビットレート等のような符号化パラメータは、いったん設定されると、セッションの継続時間中は不変のままであるということを想定した。接続がセットアップされ、メディアが接続を介して流れ始めた後では、修正は予想もされず、また許可もされなかったので、いかなる変更も、セッションの再確立(例えば、SIPの再招待)を本質的に必要とする。
【０００６】
しかしながら、コーデックの設計、特に映像のコーデックの設計での最近の進展が、効果的ないわゆる「レイヤ表現」をもたらした。レイヤ表現は、元の信号が、対応する数のビットストリームを使用して、2つ以上の忠実度レベルで表現されるようなものである。
【０００７】
レイヤ表現の1つの例は、国際電気通信連合から入手可能であり、その全体が参照により本明細書に組み込まれている、勧告H.264アネックスG(スケーラブル映像符号化-SVC)で使用されるものなどの、スケーラブル符号化である。SVCなどのスケーラブル符号化では、第1の忠実度ポイントが、標準的な非スケーラブルな技法を使用して(例えば、H.264高度映像符号化-AVCを使用して)ソースを符号化することにより得られる。追加的な忠実度ポイントが、結果として生じる符号化誤差(元の信号と、第1の忠実度ポイントの復号化したバージョンとの間の差)を符号化し、それをそれ自体のビットストリームで送信することにより得ることができる。このピラミッド形の構造様式は、きわめて普通である(例えば、それは、MPEG-2およびMPEG-4パート3の映像で使用された)。
【０００８】
第1の(最低の)忠実度レベルのビットストリームを、ベースレイヤと呼び、追加的な忠実度ポイントを付与するビットストリームを、エンハンスメントレイヤと呼ぶ。忠実度エンハンスメントは、任意の忠実度の特質であり得る。例えば、映像に関しては、それは、時間的(フレームレート)、品質(SNR)、または空間的(ピクチャサイズ)であり得る。音声に関しては、それは、時間的(1秒あたりのサンプル)、品質(SNR)、または追加的なチャネルであり得る。様々なレイヤのビットストリームは、別個に送信可能、または、典型的には、個別のレイヤに対応するサブビットストリームの直接の抽出を可能にする適切な情報とともに、単一のビットストリームに多重化して送信可能であることに留意されたい。
【０００９】
レイヤ表現の別の例は、多重記述符号化である。ここでは、構造様式はピラミッド形ではなく、各々のレイヤは、独立に復号化可能であり、基本的な忠実度での表現をもたらし、これに対して、2つ以上のレイヤがデコーダに対して利用可能であるならば、より高いレベルの忠実度で元の信号の復号化された表現をもたらすことが可能である。1つの(平凡な)例では、映像信号の奇数および偶数のピクチャを、2つの別個のビットストリームとして送信することになる。各々のビットストリームは、単独で、第1のレベルの忠実度を供与し、一方で、他のビットストリームから受信される任意の情報が、この第1のレベルの忠実度をエンハンスするために使用することができる。すべてのストリームが受信されるならば、個々の表現によりもたらされる最大レベルの品質で、オリジナルが完全に表現される。
【００１０】
レイヤ表現のさらに別の極端な例は、同時送信である。この場合、元の信号の2つ以上の独立した表現が、それら自体のストリームで符号化かつ送信される。これは、例えば、標準画質TVの素材および高品位TVの素材を送信するために使用されることが多い。同時送信は、レイヤ間予測が使用されない、スケーラブル符号化の特別な場合であることに留意されたい。
【００１１】
IPベースのネットワークでの映像および音声の送信では、典型的には、トランスポートプロトコルとしてリアルタイムプロトコル(RTP)を使用する(その全体が参照により本明細書に組み込まれている、RFC 3550)。RTPは、典型的にはUDPの上位で動作し、ペイロードタイプ識別、シーケンス番号処理、タイムスタンプ処理、および送達監視などの、リアルタイムコンテンツを送信するために必要ないくつかの特徴的機能を付与する。RTPセッションによる各々のソースの送信は、一意的なSSRC(同期ソース)により識別される。RTPパケットのパケットシーケンス番号およびタイムスタンプは、その個々のSSRCに関連している。
【００１２】
音声または映像の信号のレイヤ表現が、パケットベースのネットワークによって送信されるとき、各々のレイヤ(またはレイヤの群)が、それ自体の接続、またはセッションによって送信されることには利点がある。この方途では、ベース品質を復号化することだけを望む受信器は、特定のセッションを受信する必要があるだけであり、追加的なレイヤを受信するために必要とされる追加的なビットレートによる負担がかからない。レイヤマルチキャストは、このアーキテクチャを使用する、よく知られている用途である。この場合、ソースが、複数のマルチキャストチャネルに対してコンテンツのレイヤをマルチキャストし、受信器は、それらが受信することを望むレイヤチャネルに対してのみ「サブスクライブする」。これに対して、映像会議などの他の用途では、すべてのレイヤが単一の接続によって多重化されて送信される場合が好ましい場合がある。これによって、ファイアウォールトラバーサル、暗号化等に関する管理がより容易になる。多地点システムに対しては、すべての映像ストリームが単一の接続によって送信されることが、やはり好ましい場合がある。
【００１３】
レイヤ表現は、2009年9月22日に発行され、本発明の譲受人に譲渡された、米国特許第7,593,032号、「System and Method for a Conference Server Architecture for Low Delay and Distributed Conferencing Applications」において、スケーラブル映像符号化サーバ(「SVCS」)と呼ぶ、新しいタイプの多地点制御ユニット(「MCU」)の設計において使用されている。SVCSは、従来のトランスコーディングMCUの複雑度が著しく低減される、映像通信システム用の完全に新しいアーキテクチャをもたらす。具体的には、映像データのレイヤ構造によって、SVCSは、個人向け仕様のレイアウト、ならびに、レートもしくは解像度の整合を供与するために、パケットの相応の選択的な転送を遂行する。信号処理がないことによって、SVCSがもたらす遅延はごくわずかである。非常に改善されたエラー回復力などの他の特徴的機能に加えて、以上のすべてによって、視覚通信の使用感の品質に関して今日可能であるものが一変した。両方とも、それらの全体が参照により本明細書に組み込まれている、本発明の譲受人に譲渡された、2006年12月8日に出願した、国際特許出願第PCT/US06/061815号、「Systems and Methods for Error Resilience and Random Access in Video Communication Systems」、および、2007年3月5日に出願した、第PCT/US07/63335号、「System and Method for Providing Error Resilience, Random Access, and Rate Control in Scalable Video Communications」では、レイヤ映像表現に対する、特定のエラー回復力、ランダムアクセス、およびレート制御技法を説明している。既存の信号通信プロトコルは、レイヤ表現が可能にするシステムの特徴的機能を考慮するようには設計されていなかった。例えば、レイヤ表現を用いると、セッションを再確立する必要なしに、同じセッションでストリームの映像解像度をスイッチすることが可能である。これは、例えば、その全体が本明細書に組み込まれている、2009年6月9日に出願した、本発明の譲受人に譲渡された、国際特許出願第PCT/US09/046758号、「System and Method for Improved View Layout Management in Scalable Video and Audio Communication Systems」で使用されている。同じ出願には、映像が、話者の活動に応じて、レイアウトに追加され、またはそれから除去されるアルゴリズムの説明がある。これらの機能では、合成が遂行されるエンドポイントが、それが、どのストリームを、および何のプロパティ(例えば、解像度)によって、受信することを望むかを、SVCSに指示可能であることを必要とする。
【発明の概要】
【課題を解決するための手段】
【００１４】
本明細書で開示するのは、エンドポイントが、エンドポイントに送信されることになるストリームを選択的かつ個別に管理可能である、多地点会議の制御および管理用の技法である。一部の実施形態では、開示する主題によって、送信エンドポイントが、他の受信エンドポイントから情報を収集し、送信エンドポイントが次いでその動作のために情報を使用する単一の組の動作パラメータに処理することが可能になる。別の実施形態では、収集は中間サーバにより遂行され、中間サーバは次いで、送信エンドポイントに集約されたデータを送信する。1つまたは複数の実施形態では、開示する主題では、会議レベル表示、オンデマンド表示、表示パラメータの集約および伝搬、カスケード型(またはメッシュ型)の動作のための通知の伝搬、ならびに、表示パラメータのヒント(ビットレート、ウィンドウサイズ、画素レート、fpsなど)を使用する。
【図面の簡単な説明】
【００１５】
【図１】開示する主題の実施形態による、複数の参加者および複数のサーバを伴う、視聴覚通信システムのシステム図を表示する。
【図２】開示する主題の実施形態による、クライアントおよびサーバでの、システムモジュールおよび関連するプロトコルコンポーネントの図を表示する。
【図３】開示する主題の態様による、クライアント起動の参加および離脱の動作のための、一例としてのCMCPメッセージ交換を図示する。
【図４】開示する主題の態様による、クライアント起動の参加およびサーバ起動の離脱の動作のための、一例としてのCMCPメッセージ交換を図示する。
【図５】開示する主題の態様による、自己観覧(self-view)を遂行するための、一例としてのCMCPメッセージ交換を図示する。
【図６】開示する主題の態様による、カスケード型のCMCP動作の分析のために使用される、一例としての会議セットアップを図示する。
【図７】開示する主題の態様による、カスケード型の構成でローカルソースを表示する処理を図示する。
【図８】開示する主題の態様による、カスケード型の構成でリモートソースを表示する処理を図示する。
【図９】開示する主題の実施形態による、カスケード型の構成で「選択された」ソースを表示する処理を図示する。
【図１０】本開示の実施形態を実装するのに適したコンピュータシステムのブロック図である。
【発明を実施するための形態】
【００１６】
図の全体を通して、同じ参照番号および符号は、別段に言明しない限り、例示する実施形態の同様の特徴的機能、要素、構成要素または一部分を図示するために使用される。さらに、開示する主題を、次に、図を参照して詳細に説明するが、このことは、例示的な実施形態に関して、そのように行われている。
【００１７】
開示する主題では、会議管理制御プロトコル(Conference Management and Control Protocol)(「CMCP」)と呼ぶ、多地点会議を管理かつ制御するための技法を説明する。それは、マルチメディア会議でのメンバーシップ、会議内のマルチメディアストリームの選択、およびストリームが受信される準拠となる特性の選定を、制御かつ管理するためのプロトコルである。
【００１８】
CMCPは、フォーカスベースの(focus-based)多地点マルチメディア会議を制御するためのプロトコルである。「フォーカス」すなわちサーバは、MCU(多地点制御ユニット)、(上記で解説したような)SVCS、または他のメディア認識ネットワーク要素(MANE)である。他のプロトコル(SIP、Jingle等)が、エンドポイントとサーバとの間でマルチメディアセッションをセットアップするために使用される。セッションが確立されると、1つまたは複数の会議に関連するストリームを移送するためにセッションを使用することができる。
【００１９】
図1は、開示する主題の実施形態による、視聴覚通信システム100の全体的なアーキテクチャを図示する。システムは、いくつかのサーバ110およびエンドポイント120を特徴とする。例として、図では、7つのエンドポイントおよび4つのサーバを表示するが、任意の数のエンドポイントおよびサーバに対応することができる。開示する主題の一部の実施形態では、サーバはSVCSであり、一方で、開示する主題の他の実施形態では、サーバは、MCU(スイッチングまたはトランスコーディング)、ゲートウェイ(例えば、VidyoGateway)または任意の他のタイプのサーバであり得る。図1では、すべてのサーバ110をSVCSとして図示する。SVCSの例は、市販で入手可能なVidyoRouterである。
【００２０】
エンドポイントは、スタンドアローンのルームシステム(例えば、市販で入手可能なVidyoRoom220)から、適切なソフトウェアを走らせる汎用コンピューティングデバイス(例えば、市販で入手可能なVidyoDesktopソフトウェアを走らせるコンピュータ)、電話またはタブレットデバイス(例えば、VidyoMobileを走らせるApple iPhoneまたはiPad)等までの、音声または映像のデータを送受信可能である任意のデバイスであり得る。一部の実施形態では、エンドポイントの一部は、メディアを送信しているのみである場合があり、一方で、一部の他のエンドポイントは、メディアを受信しているのみである場合がある。さらに別の実施形態では、一部のエンドポイントは、記録または再生の(すなわち、マイクロホン、カメラ、またはモニタを伴わない)デバイスである場合さえある。
【００２１】
各々のエンドポイントは、1つのサーバに接続される。サーバは、2つ以上のエンドポイントに、および2つ以上のサーバに接続可能である。開示する主題の一部の実施形態では、エンドポイントは、サーバと一体化される場合があり、その場合、そのエンドポイントは、2つ以上のサーバおよび/または他のエンドポイントに接続している場合がある。
【００２２】
図1を引き続き参照すると、サーバ110は、カスケード型の構成で表示され、1つのエンドポイントから別のものへの経路は、2つ以上のサーバ110を通過する。一部の実施形態では、単一のサーバ110が存在する場合がある(または、サーバは、その機能がエンドポイントの一方もしくは両方と一体化されているならば、全く存在しない場合がある)。
【００２３】
各々のエンドポイント-サーバ接続130またはサーバ-サーバ接続140は、セッションであり、音声および映像を含むRTPデータの送信のための2地点間接続を確立する。各々のそのような接続を介して同じタイプの2つ以上のストリームを移送可能であることに留意されたい。1つの例は、エンドポイントが、SVCSベースのサーバを介して複数の参加者から映像を受信する場合である。その関連するサーバは、単一のセッションを介してエンドポイントにすべての映像ストリームを送信することになる。図1を使用する例は、サーバSVCS BおよびSVCS Aを介して、エンドポイントA1に送信される、エンドポイントB1およびB2からの映像となる。エンドポイントA1とサーバSVCS Aとの間のセッションは、(サーバSVCS Bを介して)B1およびB2から来る映像ストリームの両方を搬送することになる。別の実施形態では、サーバは、例えば、各々の映像ストリームに対して各々1つの、複数のセッションを確立する場合がある。複数のストリームを必要とする場合があるさらなる例は、複数の映像ソースを伴うエンドポイントである。そのようなエンドポイントは、エンドポイントがその関連するサーバと確立したセッションによって、複数の映像を送信することになる。
【００２４】
エンドポイント120とサーバ110の両方は、信号通信および移送の機能を遂行するために適切なソフトウェアを走らせる。1つの実施形態では、これらのコンポーネントは、各々の構成要素(エンドポイントまたはサーバ)で使用される総合的なシステムソフトウェアアーキテクチャでのプラグインとして構築することができる。1つの実施形態では、システムソフトウェアアーキテクチャは、上述の機能を遂行する交換可能なプラグインを組み込む、ソフトウェア開発キット(SDK)に基づく。
【００２５】
開示する主題の一部の実施形態での、各々のエンドポイント120および各々のサーバ110でのシステムソフトウェアの論理構成を、図2に表示する。機能性の3つのレベル、すなわち、セッション、メンバーシップ、およびサブスクリプションが存在する。各々は、プラグインコンポーネントおよび処理の抽象化に関連する。
【００２６】
セッションレベルは、セッションを確立するために必要な必須の信号通信動作を含む。一部の実施形態では、信号通信は、(場合によっては、その全体が参照により本明細書に組み込まれている、RFC 3262、「Reliability of provisional responses in the Session Initiation Protocol」で規定される、PRACKの使用を伴う)XMPPまたはSIPなどの規格ベースの信号通信プロトコルを含み得る。一部の実施形態では、信号通信は、SCIPプロトコルを使用するなど、プロプライエタリであり得る。SCIPは、XMPPおよびSIPと本質的に同一である状態機械を用いたプロトコルである(実際、SCIPのメッセージをSIPに1対1でマッピングすることが可能である)。図2では、SCIPプロトコルが使用されていることを表示する。開示する主題では、信号通信プロトコルの厳格な選定は重要ではない。
【００２７】
図2を引き続き参照すると、機能性の第2のレベルは、会議のメンバーシップのそれである。会議は、1組のエンドポイントおよびサーバであり、それらの関連するセッションを伴う。セッションの概念は、会議のそれとは異なり、その結果、1つのセッションが、2つ以上の会議の部分となり得ることに留意されたい。これによって、エンドポイント(および当然ながらサーバ)が、2つ以上の会議の部分となることが可能になる。開示する主題の実施形態でのメンバーシップ動作は、CMCPプロトコルでの機能により遂行される。それらは、会議に加わる、および会議から離脱するための、「参加」および「離脱」などの動作、ならびに、所望の特性を伴うメディアストリームを提供するように、エンドポイントまたはサーバに命令するためのメッセージを含む。これらの機能を、後で詳細に説明する。
【００２８】
最後に、図2を引き続き参照すると、機能性の第3のレベルは、サブスクリプションに対処する。サブスクリプションもまた、CMCPプロトコルの部分であり、SIPに対して規定されたsubscribe/notify動作を基にして作成されている(その全体が参照により本明細書に組み込まれている、RFC 3265、「Session Initiation Protocol (SIP)-Specific Event Notification」)。この機構は、エンドポイントおよびサーバが、それらが参加する会議のステータスが変化する(参加者が会議から離脱した等)ときに通知されることを可能にするために使用される。
【００２９】
次に、CMCPプロトコルおよびその機能を詳細に説明する。開示する主題の一部の実施形態では、CMCPによって、クライアントが、セッションを会議に関連付けること(ConferenceJoinおよびConferenceLeave)、会議に関する情報を受信すること(SubscribeおよびNotify)、ならびに、会議において、特定のストリーム、もしくはストリームの特定のカテゴリを要求すること(ConferenceShowおよびConferenceShowSelected)が可能になる。
【００３０】
CMCPは、エンドポイントとサーバとの間の、または、2つのサーバ間の、動作の2つのモードを有する。後者のモードは、カスケード型または「メッシュ型」のモードとして知られており、後で考察する。
【００３１】
CMCPは、種々の可能な方法によって移送されるように設計される。1つの実施形態ではCMCPは、SIPによって移送することができる。開示する主題の別の実施形態では、CMCPは、(SIP Infoメッセージと同様の)SCIP Infoメッセージによって移送される。1つの実施形態では、CMCPは、XMLとして符号化され、そのシンタックスは、XSDスキーマにより規定される。バイナリのもの、または圧縮されるものを含めて、符号化の他の手段が当然ながら可能である。
【００３２】
一部の実施形態では、CMCPがマルチメディアセッションを制御するために使用されることになるとき、セッション確立プロトコルが、CMCPの使用、および、それがどのように移送されることになるかをネゴシエーションする。このCMCPセッションによって移送されるすべてのCMCPメッセージが、対応するマルチメディアセッションに関連する会議を記述する。
【００３３】
開示する主題の1つの実施形態では、CMCPは、ダイアログベースの要求/応答プロトコルとして動作する。複数のコマンドが、すべてを実行(execute-all)、または、最初の失敗で中止(abort-on-first-failure)のいずれかのセマンティックスを伴う、単一の要求にまとめられる場合がある。コマンドがまとめられるならば、返信もまた、それに対応してまとめられる。あらゆるコマンドは、成功応答またはエラーステータスのいずれかによって確認応答され、一部のコマンドは、記すように、それらの応答で追加的な情報をさらに搬送する。
【００３４】
ConferenceJoinメソッドは、マルチメディアセッションが会議に関連付けられることを要求する。それは、パラメータとして、参加すべき会議の名前、または他の適した識別子を搬送する。エンドポイントベースのCMCPセッションでは、それは、常に、エンドポイントからサーバに搬送される。
【００３５】
一部の実施形態では、ConferenceJoinメッセージは、エンドポイントが会議に含むことを望む、(セッションレベルで指定されるような)エンドポイントのソースのリストをさらに搬送する場合がある。このリストが存在しない場合は、エンドポイントの現在および将来のソースのすべてが、会議に対して利用可能である。
【００３６】
ConferenceJoinコマンドに対するプロトコルレベルの返信は、コマンドがサーバにより首尾よく受信されたかどうかの指示のみを搬送する。エンドポイントが会議に実際に参加可能であるかどうかをサーバが決定すると、サーバは、ConferenceAcceptまたはConferenceRejectのいずれかのコマンドをエンドポイントに送出する。
【００３７】
ConferenceJoinは、ダイアログ確立コマンドである。ConferenceAcceptおよびConferenceRejectのコマンドは、ConferenceJoinにより確立されたダイアログの中で送出される。ConferenceRejectが送出されるならば、それは、ConferenceJoinにより生成されたダイアログを終結させる。
【００３８】
ConferenceLeaveコマンドは、ConferenceJoinにより確立されたダイアログを終結させ、エンドポイントのセッションを対応する会議から除去する。開示する主題の1つの実施形態では、ConferenceLeaveコマンドは、履歴および文書化の理由で、離脱中の会議の名前を搬送するが、ダイアログ中の要求として、ConferenceLeaveコマンドは、ダイアログを確立するConferenceJoinにより生成された会議への接続を終結させる。
【００３９】
ConferenceLeaveは、会議がなぜ離脱中であるのかを指示する随意のステータスコードを搬送する。
【００４０】
ConferenceLeaveコマンドは、エンドポイントによって、またはサーバによってのいずれかで送出することができる。
【００４１】
Subscribeコマンドは、CMCPクライアントが、会議に関する動的情報を受信すること、および、情報が変化するときに更新されることを望むということを指示する。Notifyコマンドは、この情報を、それが利用可能であるときに提供する。上述のように、それは、SIPのSUBSCRIBEおよびNOTIFYを基にして、ごく近く作成されている。
【００４２】
Subscribeコマンドは、リソース、パッケージ、継続時間、および随意には、suppressIfMatchパラメータを搬送する。Subscribeコマンドは、ダイアログを確立する。Subscribeに対する返信は、Subscribeで要求される継続時間を調整し得る継続時間パラメータを搬送する。
【００４３】
1つの実施形態でのNotifyコマンドは、Subscribeコマンドにより、Subscribeで要求される情報を搬送するために確立されたダイアログの中で、サーバからクライアントに周期的に送出される。それは、リソース、パッケージ、eTag、およびイベントパラメータを搬送し、パッケージの本体は、イベントパラメータに包含される。eTagは、情報のバージョンを指示する一意的なタグであり、それは、「私はバージョンXを有しています、それが変化していないならばそれを再送しないでください」とある、SubscribeコマンドのsuppressIfMatchパラメータに配置されるものである。この概念は、その全体が参照により本明細書に組み込まれている、RFC 5389、「Session Traversal Utilities for NAT (STUN)」から得られる。
【００４４】
Unsubscribeコマンドは、Subscribeコマンドにより生成されたダイアログを終結させる。
【００４５】
開示する主題の1つの実施形態では、参加者および選択された参加者のCMCPパッケージが規定される。
【００４６】
参加者パッケージは、会議内の参加者のリスト、および各々の参加者のメディアソースのリストを配布する。
【００４７】
参加者パッケージ通知は、会議参加者のリストを包含する。リスト内の各々の参加者は、参加者URI、人間可読の表示テキスト、そのエンドポイントソフトウェアに関する情報、およびそのソースのリストを有する。
【００４８】
参加者に関してリストアップされた各々のソースは、そのソースID(そのメディアをエンドポイントに送信するために使用されることになるRTP SSRC)、その2次ソースID(再送信およびFECのために使用されることになるRTP SSRC)、そのメディアタイプ(音声、映像、アプリケーション、テキスト等)、その名前、および一般属性/値の対のリストを指示する。1つの実施形態では、参加者が、同じメディアタイプのいくつかの関係のあるソースを有するならば、ソースの空間的位置が、属性として使用される。1つのそのような例は、複数のカメラを用いるテレプレゼンスエンドポイントである。
【００４９】
参加者パッケージ通知は、完全な更新または部分的な更新のいずれかであり得る。部分的な更新は、前の通知からの変化のみを包含する。部分的な更新では、あらゆる参加者が、それが、リストに関して追加、更新または除去されているかどうかについてアノテーションされる。
【００５０】
選択された参加者パッケージは、会議の「選択された」参加者のリストを配布する。選択された参加者は、会議内で現在重要であり、急速に変化する参加者である。どの参加者が選択されるかは、会議のサーバのローカルポリシーの問題である。開示する主題の1つの実施形態では、それは、会議で最も声の大きな話者であり得る。
【００５１】
選択された参加者パッケージ更新は、現在の選択された参加者のリスト、および、(前の「世代」の選択された参加者として知られている)前に選択されていた参加者のリストを包含する。開示する主題の1つの実施形態では、16人の前の選択された参加者がリストアップされる。当業者には明らかなように、任意の他のより小さな、またはより大きな数を使用してもよい。各々の選択された参加者は、参加者パッケージでのそのURIに対応する、そのURIにより識別され、その世代を(0から計数して)数値的にリストアップする。参加者がリストに現れるのは多くても1回であり、前に選択された参加者がもう一度選択されるならば、それはリストの上部に移動される。
【００５２】
開示する主題の1つの実施形態では、選択された参加者パッケージは、部分的な更新をサポートせず、各々の通知は、現在の選択された参加者リスト全体を包含する。これは、選択された参加者リストのサイズが、典型的には小さいからである。他の実施形態では、参加者パッケージで使用される、同じ部分的な更新スキームを使用することが可能である。
【００５３】
1つの実施形態では、ConferenceShowコマンドが、エンドポイントに送出されるべき特定の(「静的」)ソース、および、エンドポイントがソースをどのようにレンダリングすることになるかをサーバが知るのに役立つヒントを提供する随意のパラメータを要求するために使用される。
【００５４】
開示する主題の1つの実施形態では、ConferenceShowは、ソースに対する3つのモード、すなわち、「オン」(常に送出する)、「自動」(選択された場合にのみ送出する)、または「オフ」(選択された場合でも送出しない、すなわちブラックリスト)の中の1つを指定することができる。ソースは、ConferenceShowコマンドが、それらに関して一度も送出されないならば、「自動」状態で開始する。ソースは、それらの(1次)ソースID値により、参加者パッケージで通信される際に指定される。
【００５５】
ConferenceShowは、エンドポイントがソースをどのように受信することを望むかに関するエンドポイントの所望および能力に関するヒントを提供する随意のパラメータをさらに含む。1つの実施形態では、パラメータは、映像ソースがレンダリングされることになるウィンドウの幅および高さであるwindowSize、エンドポイントがソースを表示するために使用することになる1秒あたりのフレームの最大数であるframesPerSec、エンドポイントがソースに対して復号化することを望む1秒あたりの最大画素であるpixelRate、ならびに、エンドポイントにより要求されるすべてのソースの中でのソースの相対的重要度である優先度(preference)を含む。サーバは、これらのパラメータを、ネットワークおよびシステムの制約条件が与えられる場合に、エンドシステムに対して最良の総合的な使用感をもたらすための、ソースを整形する方法を決定するために使用することができる。windowSize、framesPerSec、およびpixelRateのパラメータは、単に、映像(およびスクリーン/アプリケーションキャプチャ)ソースに対して意味がある。H.264 SVCの能力が働き始めるのはこの場合である、その理由は、このことが、符号化が行われた後に信号を適合することができるいくつかの方途を提供するからである。これは、サーバが、これらのパラメータを直接使用可能であり、サーバが、これらのパラメータを送信エンドポイントに転送する必要が必ずしもないということを意味する。パラメータが、送信エンドポイントに転送されることもまた可能である。
【００５６】
複数の組のパラメータは、別のサーバへの伝搬のために(メッシュ型の動作のために)、単一のものに統合される場合がある。例えば、15fpsおよび30fpsが個々のサーバから要求されるならば、そのサーバは、要求を単一の30fpsの要求に集約することができる。当業者には明らかなように、ConferenceShowでの随意のパラメータとして任意の数およびタイプの信号特性を使用することができる。一部の実施形態では、異なる値の代わりにパラメータの範囲、またはそれらの組み合わせを使用することもまた可能である。
【００５７】
2011年1月20日に出願し、その全体が参照により本明細書に組み込まれている、本発明の譲受人に譲渡された、国際特許出願第PCT/US11/021864号、「Participant-aware configuration for video encoder」では、H.264 SVC映像符号化規格を使用するエンコーダの場合を含む、そのようなパラメータを統合するための技法を説明している。
【００５８】
開示する主題の1つの実施形態では、各々のConferenceShowコマンドは、単一のソースのみを要求する。これに対して、前述のように、複数のCMCPコマンドが、単一のCMCP要求にまとめられる場合がある。
【００５９】
開示する主題の一部の実施形態では、ConferenceShowコマンドは、サーバに送出されるのみであり、エンドポイントには決して送出されない。サーバ-エンドポイントのソース選択は、セッションを確立したプロトコルを使用して行われる。SIPの場合では、これは、両方とも、それらの全体が参照により本明細書に組み込まれている、RFC5576、「Source-Specific Media Attributes in the Session Description Protocol」、および、インターネットドラフト「Media Source Selection in the Session Description Protocol (SDP)」(draft-lennox-mmusic-sdp-source-selection-02、作業中、2010年10月21日)を使用して行うことができる。
【００６０】
一部の実施形態では、動的ソース、および、それを用いてソースが観覧されることになるパラメータがエンドポイントに送出されるべきであるということを要求するために、ConferenceShowSelectedコマンドが使用される。それは2つの部分、映像および音声を有し、それらのどちらも存在し得る。
【００６１】
ConferenceShowSelectedコマンドの映像セクションは、動的に受信されるべき映像ソースを選択するために使用される。それは、観覧する映像世代のリスト、および、選択された参加者リストの要素がどのように要求される世代にマッピングするかに関するポリシー選定からなる。
【００６２】
選択された世代のリストは、どの選択された参加者世代が、エンドポイントに送出されるべきであるかを指示する。1つの実施形態では、各々の世代は、その数的識別子、および、エンドポイントがその世代を受信することを望むかどうかを指示する状態(「オン」または「オフ」)により識別される。さらに、各々の世代は、静的に観覧されるソースに対してと同じであり得る、その表示パラメータ、すなわち、windowSize、framesPerSec、pixelRate、および優先度をリストアップする。異なる組のパラメータもまた、使用することができる。
【００６３】
ConferenceShowSelectedコマンドでリストアップされていない選択された参加者世代は、それらの前の状態を保持する。ConferenceShowSelectedコマンドが、世代に関して一度も送出されていないならば、初期値は「オフ」である。
【００６４】
1つの実施形態では、世代のリストに続いて、2つのポリシー値、すなわち、自己観覧ポリシーおよび動的観覧ポリシーをさらに映像セクションが指定する。
【００６５】
自己観覧ポリシーは、エンドポイントが選択された参加者になるときに、エンドポイント自体のソースが、エンドポイントに経路指定されるべきであるかどうかを指定する。利用可能な選定は、「自己を隠す」(エンドポイントのソースは、決してエンドポイント自体に経路指定されない)、「自己を表示する」(エンドポイントのソースは、エンドポイントが選択された参加者であるならば、常にエンドポイント自体に経路指定されることになる)、および「他がなければ自己を表示する」(エンドポイントのソースは、エンドポイントが会議での唯一の参加者であるときにのみ、エンドポイント自体に経路指定される)である。エンドポイントがリストにある場合、ConferenceShowSelectedで要求される後続の世代が、代わりに経路指定される。
【００６６】
動的観覧ポリシーは、エンドポイントが静的に観覧しているソースが、エンドポイントが観覧している世代の1つとみなされるべきであるかどうかを指定する。値は、「静的に観覧されない場合に表示する」および「静的に観覧される場合でも表示する」であり、1つの実施形態では、後者がデフォルトである。前者の場合では、選択された参加者リストでの後続の世代が、ConferenceShowSelectedコマンドに関して経路指定される。
【００６７】
「静的に観覧される場合でも表示する」場合では、ソースが、選択された参加者であり、かつ、静的に観覧されているならば、その優先度は、その静的および動的な優先度の最大値である。
【００６８】
1つの実施形態では、ConferenceShowSelectedコマンドは、サーバに送出されるのみであり、エンドポイントには決して送出されない。
【００６９】
1つの実施形態では、ConferenceShowSelectedコマンドの音声セクションは、動的に受信されるべき音声ソースを選択するために使用される。ConferenceShowSelectedコマンドの音声セクションは、受信すべき動的音声ソースの数、および、動的音声ストリーム選択ポリシーからなる。ConferenceShowSelectedコマンドの音声セクションは、「最も声の大きな話者」の音声選択ポリシーを含むことになる。
【００７０】
ConferenceUpdateコマンドが、ConferenceJoinで送出されるパラメータを変更するために使用される。特に、ConferenceUpdateコマンドは、エンドポイントが、そのソースのどれが個々の会議に送出されるべきであるかを変更することを望む場合に使用される。
【００７１】
図3は、クライアント起動の会議の参加および離脱の動作のための、エンドポイント(クライアント)とサーバとの間のCMCPプロトコルの動作を表示する。開示する主題の1つの実施形態では、システムソフトウェアがSDKを基にしてビルドされていると想定する。メッセージ交換では、送信側で必要とされるメソッド(SDKにより呼び出されるプラグインのメソッド)、および受信側でトリガされるコールバック(SDKに対するプラグインのコールバック)を表示する。
【００７２】
トランザクションは、参加行為を指示するConfHostJoinedをトリガするMembershipJoinを、クライアントが呼び出すことから始まる。送信される「conf-join」メッセージは、すべてのそのようなメッセージの場合と同様に、確認応答されることに留意されたい。ある時点で、サーバは、参加者が会議に受け入れられたことを指示するConfPartAcceptを発行している。これは、クライアントへの「conf-accept」メッセージをトリガすることになり、それが今度は、参加動作の終結を指示するために、MembershipJoinCompletedをトリガすることになる。その後、クライアントは、会議を離脱するその所望を指示するMembershipLeaveを発行する。結果として生じる「conf-leave」メッセージは、サーバ側でのConfHostLeftコールバック、およびクライアントへの「ack」メッセージをトリガする。後者は、離脱動作が完了したことの指示をトリガする。
【００７３】
図4は、同様の筋書を表示する。ここでは、クライアント起動の参加およびサーバ起動の離脱を用いる。離脱動作のトリガは、クライアントでのMembershipTerminatedコールバックをもたらす、サーバ側でのConfParticipantBootメソッドである。
【００７４】
図5は、特定のソースを観覧する、この場合には自己観覧する際に必要とされる動作を表示する。この実施形態では、クライアントは、「conf-show」メッセージを発生させる、ソース(それ自体)を識別する、MembershipShowRemoteSourceを呼び出す。このメッセージは、この特定のソースがクライアントに送達されるように手配するように会議に命令する、ConferenceHandlerShowSourceをトリガする。会議のハンドラは、サーバから、特定のソースを提供し得るクライアント、この例では、表示要求の発信者へのSessionShowSourceを発生させることになる。SessionShowSourceは、関連性のあるストリームを送信することを開始するために、クライアントでSessionShowLocalSourceをトリガすることになる、「session-initiate」メッセージを生成することになる。一部の実施形態では、メディアの送信は、会議へ参加するときに開始せず、それは、実際には、サーバがクライアントへの表示コマンドを発生させるときに開始する。
【００７５】
次に、カスケード型またはメッシュ型の構成でのCMCPの動作を検討する。この場合では、図1に示すように、2つ以上のサーバが、2つのエンドポイント間の経路に存在する。一般に、任意の数のサーバを含むことができる。1つの実施形態において、2つ以上のサーバが含まれるとき、各々のサーバが、(本明細書では詳細に説明しない)信号通信手段によって、システムのトポロジーを完全に知っていると想定することにする。この情報を提供するための平凡な方途は、静的構成によるものである。代替の手段には、グラフ情報を、それを生成するために必要とされる各々のステップの間に送信することによる動的構成がある。接続性グラフとは、ループが存在せず、各々のエンドポイントをあらゆる他のエンドポイントに接続する経路が存在するものであるということをさらに想定する。これらの制約条件のいずれかを緩和することができる代替の実施形態は、経路指定する側に影響を及ぼす原因となるほど複雑度が増大するものの、やはり可能である。
【００７６】
カスケードトポロジー情報は、様々なサーバを介して、1つのエンドポイントから別のものにメディアを経路指定するため、さらには、必要に応じて、システム構成要素間でCMCPプロトコルメッセージを伝搬させるための両方で使用される。
【００７７】
例として、図6に表示する会議構成を使用するカスケード型の構成に対するCMCPプロトコルの動作を説明する。会議600は、各々が2つのエンドポイント120を伴う(A1およびA2、B1およびB2、C1およびC2)、「SVCS A」から「SVCS C」と呼ぶ3つのサーバ110を含む。エンドポイントは、それらが割当てられるSVCSサーバの文字にちなんで名付けられている(例えば、SVCS Aに対してA1およびA2)。個々の構成は、限定的であることは意図されず、単に例として使用され、行う説明は、任意のトポロジーに適用することができる。
【００７８】
図7は、ローカル表示コマンドが必要とされるときのCMCP動作を表示する。この例では、エンドポイントA1がエンドポイントA2を観覧することを望むと想定することにする。視覚的な明快さのために、構成要素間のセッション接続を除去したが、それらは、図6に表示するものと同一である。直線の矢印(例えば710)は、CMCPメッセージの送信を指示する。曲線の矢印(例えば712)は、メディアデータの送信を指示する。
【００７９】
第1のステップとして、エンドポイントA1は、SHOW(A2)コマンド710を、そのSVCS Aに対して起動する。SVCS Aは、エンドポイントA2がそれに割当てられていることを知っており、それは、SHOW(A2)コマンド711をエンドポイントA2に転送する。受信すると、エンドポイントA2は、そのメディア712を、そのSVCS Aに送信することを開始する。最後に、SVCS Aが今度は、メディア713をエンドポイントA1に転送する。SHOW()コマンドが、会議を通って正しい送出者に(SVCS Aを介して)どのように伝搬されたかがわかる。
【００８０】
図8は、同様の筋書を表示するが、次はリモートソースに対するものである。この例では、エンドポイントA1がエンドポイントB2からのメディアを観覧することを欲すると想定する。ここでも、第1のステップとして、エンドポイントA1は、SHOW(B2)コマンド810を、その関連するSVCS Aに対して発行する。SHOW()コマンドは、エンドポイントB2に伝搬されることになる。これは、SVCS AからSVCS Bに伝搬されるメッセージSHOW(B2)811、および、SVCS BからエンドポイントB2に伝搬されるSHOW(B2)812によって起こる。受信すると、エンドポイントB2は、メディア813をSVCS Bに送信することを開始し、SVCS Bは、それをメッセージ814によってSVCS Aに転送し、SVCS Aが今度は、それをメッセージ815によって、それを元々要求したエンドポイントA1に転送する。ここでも、SHOW()コマンド、および関連するメディアの両方が、会議を通ってどのように経路指定されるかがわかる。サーバは、会議のトポロジーを認識しているので、それらは、SHOWコマンド要求を適切なエンドポイントに常に経路指定可能である。同様に、エンドポイントから送信されるメディアデータは、その関連するサーバにより、正しいサーバおよびエンドポイントに経路指定される。
【００８１】
次に、エンドポイントA2もまた、B2を見ることを欲すると想定しよう。それは、SHOW(B2)コマンド816をSVCS Aに対して発行する。この時間の付近では、SVCS Aは、すでにB2からストリームを受信しているので、SHOW要求は、SVCS B(およびエンドポイントB)に戻るように伝搬される必要はない。それは、次いで直接、そのコピーを817としてエンドポイントA2に転送することを開始することができる。エンドポイントA2が、SVCS Aに対して、エンドポイントA1と異なる要求事項(例えば、異なる空間解像度)を実行依頼するならば、SVCS Aは、適切なエンコーダ構成が選択されるように、両方の要求から性能パラメータを整理統合し、それらをB2に戻るように伝搬させることができる。これを「表示集約」と呼ぶ。
【００８２】
集約は、2つの異なるパラメータ値を1つに組み合わせる形態であり得る(例えば、1つがQVGAを要求し、1つがVGAを要求するならば、サーバは、それらをVGA解像度の要求に組み合わせることになる)、または、それは、範囲も含み得る。代替の集約戦略が、異なるシステムの性能パラメータとトレードオフする場合がある。例えば、サーバが、720pの解像度に対する1つの要求、および180pに対する5つの要求を受信すると想定する。それらを720pの要求に組み合わせる代わりに、それは、360pの解像度を選択し、720pを要求するエンドポイントにアップスケーリングさせることができる。多数決、平均値または中央値、最小値および最大値等を含む、他のタイプの集約が、当業者には明らかなように可能である。
【００８３】
サーバが、新しい構成が必要とされることを決定するならば、それは、新しいSessionShowSourceコマンドを送出する(図5もまた参照)。別の、または同じ実施形態では、サーバは、可能であるとき、そのような適合をそれ自体に遂行することができる。
【００８４】
図9は、選択された参加者(動的SHOW)を伴う筋書を表示する。この例では、エンドポイントは、それらがどの参加者を見ることを欲するかは、それはシステムにより動的に決定されるので、事前にはわからない。決定は、いくつかの方途で遂行することができる。1つの実施形態では、受信されたメディアストリーム、またはストリームとともに含まれるメタデータ(例えば、音声ボリュームレベル指標)を検討することにより、各々のサーバは、それ自体により決定を遂行することができる。別の実施形態では、決定は、別個の音声ブリッジなどの、別のシステム構成要素により遂行することができる。さらに別の実施形態では、動きなどの異なる基準を、選択のために使用することができる。
【００８５】
図9を引き続き参照すると、第1のステップでは、エンドポイントA1、A2、C1、およびB2が、それらのそれぞれのSVCSにSHOW(Selected)コマンド910を送信すると想定する。1つの実施形態では、音声レベル指標または他の手段を使用して、SVCSは、選択された参加者がC2であると決定する。別の実施形態では、情報が、音声ストリームを処理する音声ブリッジにより提供される。代替の実施形態では、2つ以上のエンドポイントを選択可能である場合がある(例えば、N人の直近の話者)。選択されたエンドポイントが決定すると、SVCS A、B、およびCは、エンドポイントC2を具体的に目標とする、特定のSHOW(C2)メッセージ911を送信する。メッセージは、会議のトポロジーを知っていることを利用して転送される。このようにして、SVCS Aは、その要求をSVCS Bに送出し、SVCS Bは、その要求をSVCS Cに送出し、SVCS Cは、その要求をエンドポイントC2に送出する。次いで、メディアデータが、エンドポイントC2から912を通ってSVCS Cに、次いで、913を通ってエンドポイントC1およびSVCS Bに、914を通ってエンドポイントB2およびSVCS Aに、最後に、915を通ってエンドポイントA1およびA2に流れる。
【００８６】
ConferenceInviteまたはConferenceReferコマンドが、エンドポイントに、それが個々の会議に参加することを提案するための、サーバ-エンドポイント通信用に使用される。
【００８７】
上記で説明した、多地点会議を制御かつ管理するための方法は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、コンピュータ可読メディアに物理的に記憶することができる。コンピュータソフトウェアは、任意の適したコンピュータ言語を使用して符号化することができる。ソフトウェア命令は、様々なタイプのコンピュータ上で実行することができる。例えば、図10は、本開示の実施形態を実装するのに適したコンピュータシステム1000を例示する。
【００８８】
コンピュータシステム1000に関して図10に表示する構成要素は、本質的には一例としてのものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能性の範囲に関して、いかなる限定も示唆することは意図されない。構成要素の構成においてもまた、コンピュータシステムの一例としての実施形態で例示する構成要素の、いずれか1つまたは組み合わせに関して、いかなる依存性または要求事項も存在すると解釈すべきではない。コンピュータシステム1000は、集積回路、プリント回路板、(携帯電話またはPDAなどの)小型のハンドヘルドデバイス、パーソナルコンピュータ、またはスーパーコンピュータを含む、多くの物理的形態を有し得る。
【００８９】
コンピュータシステム1000は、ディスプレイ1032、1つまたは複数の入力デバイス1033(例えば、キーパッド、キーボード、マウス、スタイラス等)、1つまたは複数の出力デバイス1034(例えば、スピーカ)、1つまたは複数の記憶デバイス1035、様々なタイプの記憶メディア1036を含む。
【００９０】
システムバス1040は、多種多様のサブシステムとリンクする。当業者に理解されるように、「バス」は、共通機能をサービス提供する複数のデジタル信号線を指す。システムバス1040は、種々のバスアーキテクチャのいずれかを使用する、メモリバス、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれかであり得る。例として、および限定としてではなく、そのようなアーキテクチャには、業界標準アーキテクチャ(ISA)バス、拡張ISA(EISA)バス、マイクロチャネルアーキテクチャ(MCA)バス、ビデオ電子標準協会ローカル(VLB)バス、ペリフェラルコンポーネントインターコネクト(PCI)バス、PCI-Expressバス(PCI-X)、およびアクセラレーテッドグラフィックスポート(AGP)バスがある。
【００９１】
プロセッサ1001(中央処理装置またはCPUとも呼ぶ)は、随意に、命令、データ、またはコンピュータアドレスの一時的な局所記憶用のキャッシュメモリユニット1002を包含する。プロセッサ1001は、メモリ1003を含む記憶デバイスに結合される。メモリ1003は、ランダムアクセスメモリ(RAM)1004およびリードオンリーメモリ(ROM)1005を含む。当技術分野でよく知られているように、ROM1005は、プロセッサ1001に一方向にデータおよび命令を伝送する働きをし、RAM1004は、典型的には、双方向の様式でデータおよび命令を伝送するために使用される。これらのタイプのメモリは両方とも、下記で説明するコンピュータ可読メディアの任意の適したものを含み得る。
【００９２】
固定記憶装置1008が、随意には、記憶制御ユニット1007を介して、プロセッサ1001に双方向にさらに結合される。それは、追加的なデータ記憶容量を提供し、下記で説明するコンピュータ可読メディアのいずれかをやはり含み得る。記憶装置1008は、オペレーティングシステム1009、EXEC1010、アプリケーションプログラム1012、データ1011等を記憶するために使用することができるものであり、典型的には、主記憶装置より遅い補助記憶メディア(ハードディスクなど)である。記憶装置1008内部で保持される情報は、適切な場合には、メモリ1003に仮想メモリとして標準的な様式で組み込むことができることを理解されたい。
【００９３】
プロセッサ1001は、グラフィックス制御1021、映像インターフェース1022、入力インターフェース1023、出力インターフェース、記憶インターフェースなどの種々のインターフェースにさらに結合され、これらのインターフェースは、適切なデバイスに同様に結合される。一般に、入出力デバイスは、映像ディスプレイ、トラックボール、マウス、キーボード、マイクロホン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気もしくは紙のテープリーダ、タブレット、スタイラス、声もしくは手書きの認識装置、生体認証リーダ、または他のコンピュータのいずれかであり得る。プロセッサ1001は、ネットワークインターフェース1020を使用して、別のコンピュータまたは電気通信ネットワーク1030に結合することができる。そのようなネットワークインターフェース1020を用いると、CPU1001が、上記で説明した方法を遂行中に、ネットワーク1030から情報を受信可能であり、または、ネットワークに情報を出力可能であるということが企図される。さらに、本開示の方法の実施形態は、単にCPU1001上で実行可能であり、または、インターネットなどのネットワーク1030を介して、処理の一部分を分担するリモートCPU1001と連動して実行可能である。
【００９４】
様々な実施形態によれば、ネットワーク環境にあるとき、すなわち、コンピュータシステム1000がネットワーク1030に接続されているとき、コンピュータシステム1000は、やはりネットワーク1030に接続されている他のデバイスと通信可能である。通信は、ネットワークインターフェース1020を介して、コンピュータシステム1000を往来して送出することができる。例えば、1つまたは複数のパケットの形態での、別のデバイスからの要求または応答などの入来する通信は、ネットワークインターフェース1020でネットワーク1030から受信され、処理のためにメモリ1003内の選択されたセクションに記憶することができる。やはり1つまたは複数のパケットの形態での、別のデバイスへの要求または応答などの出発する通信もまた、メモリ1003内の選択されたセクションに記憶され、ネットワークインターフェース1020でネットワーク1030に送出することができる。プロセッサ1001は、処理のために、メモリ1003に記憶されるこれらの通信パケットにアクセス可能である。
【００９５】
加えて、本開示の実施形態は、さらに、様々なコンピュータ実装動作を遂行するためのコンピュータコードを有するコンピュータ可読メディアを伴う、コンピュータ記憶製品に関する。メディアおよびコンピュータコードは、本開示の目的のために特別に設計かつ構築されるものであり得る、または、それらは、コンピュータソフトウェアの技術分野の当業者によく知られ、かつ利用可能である種類のものであり得る。コンピュータ可読メディアの例には、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープなどの磁気メディア、CD-ROMおよびホログラフィックデバイスなどの光学メディア、フロプティカルディスクなどの光磁気メディア、ならびに、特定用途向け集積回路(ASIC)、プログラマブル論理デバイス(PLD)、ROMデバイスおよびRAMデバイスなどの、プログラムコードを記憶かつ実行するように特別に構成されているハードウェアデバイスがあるが、それらに限定されない。コンピュータコードの例には、コンパイラにより生み出されるような機械語コード、および、インタプリタを使用するコンピュータにより実行される、より高級のコードを包含するファイルがある。本開示の主題に関して使用されるような、用語「コンピュータ可読メディア」が、送信メディア、搬送波、または他の一時的な信号を包含しないことを、当業者であればさらに理解するはずである。
【００９６】
例として、および限定としてではなく、アーキテクチャ1000を有するコンピュータシステムは、メモリ1003などの、1つまたは複数の有形のコンピュータ可読メディアで実施されるソフトウェアを実行する、プロセッサ1001の結果としての機能性を提供することができる。本開示の様々な実施形態を実装するソフトウェアは、メモリ1003に記憶され、プロセッサ1001により実行することができる。コンピュータ可読メディアは、個々の必要性によって、1つまたは複数のメモリデバイスを含み得る。メモリ1003は、大容量記憶デバイス1035などの1つもしくは複数の他のコンピュータ可読メディアから、または、通信インターフェースを介して1つもしくは複数の他のソースから、ソフトウェアを読み出すことができる。ソフトウェアによって、プロセッサ1001が、メモリ1003に記憶されるデータ構造を規定すること、および、ソフトウェアにより規定される処理によって、そのようなデータ構造を修正することを含む、本明細書で説明した個々の処理、または個々の処理の個々の部分を実行することが可能になる。加えて、または代替として、コンピュータシステムは、本明細書で説明した個々の処理、または個々の処理の個々の部分を実行するために、ソフトウェアの代わりに、またはソフトウェアとともに動作可能である、ハードワイヤードの、または他の方法により回路で実施される論理の結果としての機能性を提供することができる。ソフトウェアに対する言及は、適切である場合には、論理を包含し得るものであり、その逆も同様である。コンピュータ可読メディアに対する言及は、適切である場合には、実行用のソフトウェアを記憶する回路(集積回路(IC)など)、実行用の論理を実施する回路、またはその両方を包含し得る。本開示は、ハードウェアおよびソフトウェアの任意の適した組み合わせを包含する。
【００９７】
本開示ではいくつかの一例としての実施形態を説明したが、開示した主題の範囲内に含まれる、代替、交換、および様々な置換等価物が存在する。開示した主題の方法および装置を実装する多くの代替の方途が存在することに、さらに留意されたい。
【符号の説明】
【００９８】
1000  コンピュータシステム、アーキテクチャ
1001  プロセッサ、CPU、リモートCPU
1002  キャッシュメモリユニット
1003  メモリ
1004  ランダムアクセスメモリ(RAM)
1005  リードオンリーメモリ(ROM)
1007  記憶制御ユニット
1008  固定記憶装置、記憶装置
1009  オペレーティングシステム
1010  EXEC
1011  データ
1012  アプリケーションプログラム
1020  ネットワークインターフェース
1021  グラフィックス制御
1022  映像インターフェース
1023  入力インターフェース
1030  電気通信ネットワーク、ネットワーク
1032  ディスプレイ
1033  入力デバイス
1034  出力デバイス
1035  記憶デバイス
1036  記憶メディア
1040  システムバス
【図１】
2013543306.tif 000003
【図３】
2013543306.tif 000004
【図４】
2013543306.tif 000005
【図５】
2013543306.tif 000006
【図６】
2013543306.tif 000007
【図７】
2013543306.tif 000008
【図８】
2013543306.tif 000009
【図９】
2013543306.tif 000010
【図１０】
2013543306.tif 000011
【図２】
2013543306.tif 000012
【国際調査報告】
2013543306.tif 000013
2013543306.tif 000014