JP2015080210A

JP2015080210A - 会議セッションの現在状況に対する、会議システムのリアルタイム適合システム及び方法

Info

Publication number: JP2015080210A
Application number: JP2014210309A
Authority: JP
Inventors: アイゼンバーグアビブ; Eisenberg Aviv; デッカーエラン; Decker Eran; レイモンドニコルジョン; Raymond Nicol John; ロバートタッカーマイケル; Robert Tucker Michael
Original assignee: Polycom Inc
Current assignee: Polycom Inc
Priority date: 2013-10-15
Filing date: 2014-10-14
Publication date: 2015-04-23
Also published as: TWI559777B; EP2863632A1; CN104580991A; CN104580991B; EP2863632B1; US20150103137A1; US10091461B2; HK1204179A1; TW201524215A

Abstract

【課題】ビデオ会議システムを現在の会議セッションの複数の状況に適合させ、それら現在の状況に基づいて、セッションを１つの会議手法から別の会議手法に自動的に変換するためのルールに基づく手法を提供する。
【解決手段】複数のルールは、わけても参加者数、共通コーデックを使用するための能力を含む判定基準を含む。１つの拡大モジュールは、１つのタイプの会議セッションから別のタイプの間での移行を管理するために使用する。会議を１つのタイプから別のタイプに移行させる状況が生じた場合、その状況が適応されなくなれば、会議を自動的に元の会議タイプに戻す。
【選択図】図１

Description

この発明は、ビデオ会議に関し、詳しくは、１つの会議セッションの現在の状況（condition、コンディション、状態）に基づいて、１つの会議手法から別の会議手法に適合させる分野に関する。

日常の数多のアプリケーション及びサービスは目覚しい速さでインターネットプロトコール（ＩＰ）ネットワークに移行し、且つ、種々のマルチメディア会議設備は成長を続けているので、ますます多くの人々が、重要な通信方法として、マルチメディア会議に依存している。今日、マルチメディア会議通信は、複数の会議手法を使って実施され得る。会議手法の幾つかの例は、従来の（legacy；レガシーの、過去の）マルチメディア会議方式、メディア中継会議方式、及び、メッシュ会議方式を含む。この明細書において、マルチメディア会議、ビデオ会議（コンテンツ有り又は無し）、及び、オーディオ会議という用語は互換的に使用され、且つ、ビデオ会議という用語は、ビデオ、オーディオ及びマルチメディア会議を表す用語として使用される。

３人以上の参加者間での従来の多地点（multipoint；マルチポイント）会議は、１つの多地点制御ユニット（ＭＣＵ）を必要とする。かかるＭＣＵは、会議制御エンティティ（entity；実体、構成要素）であり、典型的には、複数のエンドポイント（Ｅｎｄｐｏｉｎｔ）から、様々なチャンネルを受信するネットワークのノード、又は、端末に設置されている。従来のＭＣＵは、何らかの基準（抽出条件）に従って、オーディオ及びビジュアル信号を処理し、そして、それらを１組の接続されたチャンネルを経由して複数の参加エンドポイントのそれぞれに分配する。それら従来のＭＣＵの例は、ポリコム社から入手できるＭＧＣ‐１００及びＲＭＸ２０００（登録商標）を含む（ＲＭＸ２０００は、ポリコム社の登録商標である）。レガシーエンドポイント（ＬＥＰ）と称される、従来の通信方法における端末は、ネットワーク上のエンティティであり、他のＬＥＰ又はＭＣＵとのリアルタイム双方向のオーディオ及び／又はオーディオ―ビジュアル通信を提供できる。ＬＥＰとＭＣＵのより詳細な定義は、例えば、例示に限定されないがＩＴＵのウェブサイトwww.itu.intに見つかるＨ．３２０、Ｈ３２４及びＨ．３２３などの国際電気通信（ＩＴＵ）規格を参照されたい。

共通のＭＣＵ（レガシーＭＣＵとも言う）は、複数のオーディオ及びビデオデコーダ、エンコーダ、及び、メディアコンバイナ（オーディオミキサ及び／又はビデオ画像ビルダー）を含んでよい。該ＭＣＵは、可変数の参加者（ＬＥＰ）の間でのオーディオ及びビデオ通信を処理するために、膨大な量の処理能力を使用するだろう。その通信は、多様な通信プロトコル及び圧縮規格に基づくことができ、且つ、異なる複数種類のＬＥＰを含んでいるだろう。ＭＣＵは、複数の入力オーディオストリーム又は入力ビデオストリームを、それぞれ少なくとも１つのオーディオ出力ストリーム又はビデオ出力ストリームに結合する必要があり、このことは、該出力ストリームの送信先となる少なくとも１つの会議出席者のＬＥＰの特質に矛盾しない。複数のエンドポイントから受信した複数の圧縮オーディオストリームは、デコードされ、且つ、その会議の１つのオーディオストリームに混合するために、何れの複数のオーディオストリームが選択されるかを決定するために、分析され得る。デコード及び解凍（decompress；デコンプレス、展開、圧縮解凍、復元）という用語は、この明細書では、互換的に使用されている。

１つの会議は、１以上のビデオ出力ストリームを有し、各出力ストリームは或る１つのレイアウトに関連付けられる。１つのレイアウトは、そのストリームを受信する１以上の会議出席者のディスプレイ上における１つの会議の見え方を定義する。１つのレイアウトは１以上のセグメントに分割され、各セグメントはそれぞれＬＥＰ経由で或る特定の会議出席者により送信された１つのビデオ入力ストリームに関連付けられる。各出力ストリームは、様々な入力ストリームにより構成され、その結果、常駐表示（continuous presence （ＣＰ）；画面分割）画像になる。ＣＰ会議において、リモート端末におけるユーザは、その会議内の他の幾人かの参加者を同時に見ることができる。各参加者は、前記レイアウト内の１つのセグメントに表示され、且つ、各セグメントは互いに同じサイズ又は異なるサイズを持っている。前記レイアウトの複数のセグメントに関連付られて、表示される複数の参加者の選択は、同じセッションに参加している複数の個別の会議出席者の間で一様でなくてよい。

２つ目のタイプの通信方法は、メディア中継会議（ＭＲＣ）である。ＭＲＣにおいて、メディア中継ＭＣＵ（ＭＲＭ）は、各参加メディア中継エンドポイント（ＭＲＥ）から、１以上のストリームを受信する。ＭＲＭは、会議内の他の複数のエンドポイントから受信された１組の複数のビデオストリームを、各参加エンドポイントに中継する。各受信エンドポイントは、１つのレイアウトに従うＣＰビデオ画像を生成するために、複数のストリームを使用し、また、混合された会議のオーディオを生成するためにも、該複数のストリームを使用する。ＣＰビデオ画像及び混合されたオーディオは、ＭＲＥのユーザに対して提示される。１つのＭＲＥは、当該セッション内の会議出席者の端末になり得、この端末は、或る１つのＭＲＭから中継されたメディアを受信し、且つ、１つのＭＲＭからの指示に従い圧縮されたメディアを伝送できる。ＭＲＣ、ＭＲＭ又はＭＲＥについての詳細は、米国特許番号第８２２８３６３号及び８７６０４９２号を参照されたい。且つ、それら出願に記載された全ての記載内容を本明細書に援用する。本明細書において、エンドポイントという用語は、ＬＥＰ又はＭＲＥのいずれも表すだろう。

いくつかのＭＲＣシステムにおいて、転送ＭＲＥは、２以上のストリームで自身からのビデオ映像を送信する。各ストリームは異なる品質レベルに関連付けられる。品質は、例えば、フレームレート、及び／又は、信号対雑音比(signal-to-noise ratio；ＳＮＲ、Ｓ／Ｎ比)などに関して、異なる。同様に、各中継ＭＲＥは、２以上のストリームで自身のオーディオを送信し、それらストリームは、例えば圧縮ビットレートなどに関して互いに異なる。かかるシステムは、レイアウト内での種々のセグメントサイズや、各受信エンドポイントにより使用される種々の解像度などを提供するために、複数のストリームを使用できる。更に、複数のストリームは、パケットロス（パケット損失）を克服するために使用され得る。

今日、ＭＲＣは、ますます一般的になっている。多くのビデオ会議システムは、１以上のストリーム内に複数の品質レベルを並行して伝送する。例えば、ビデオにとって、品質レベルは、例えば時間ドメイン（例えばフレーム毎秒）、空間ドメイン（例えば高精細度（ＨＤ）対ＣＩＦ（Common Intermediate Format））のようないくつかのドメイン（定義域）、及び／又は、品質（例えば鮮鋭度（シャープネス））により表現される。多品質（マルチクオリティ）ストリーム用に使用できる、例えば、ビデオ圧縮規格は、Ｈ．２６４ＡＶＣ、Ｈ．２６４ａｎｎｅｘＧ（ＳＶＣ）、ＭＰＥＧ‐４などである。Ｈ．２６４などこれら圧縮規格に関する更なる情報は、ＩＴＵのウェブサイトwww.itu.int、又は、www.mpeg.orgを参照されたい。

最初の２つの通信方法、レガシーＭＣＵ及びＭＲＣにおいては、中央エンティティがシグナリング並びに音声及びビデオメディアストリーム（それぞれＭＣＵ又はＭＲＭ）を処理するために必要である。各エンドポイントは、自身のメディアストリームを、ＭＣＵ又はＭＲＭに送信する。ＭＣＵ又はＭＲＭは、適用された通信方法の種類に従って前記メディアストリームを処理し、適切なストリームを受信エンドポイントに伝送する。ＭＣＵという用語は、本明細書では、ＭＲＭ及びレガシーＭＣＵを代表する用語として使用される。

３つ目のタイプの通信方法が使用され得る。３つ目の方法は、メッシュ会議システム（ＭＣＳ）と呼ばれ得る。ＭＣＳにおいては、メディアストリームを処理するための中央エンティティがない。その代わりとして、ＭＣＳにおいては、ロスターリストサーバ（Roster List Server、ＲＬＳ）が、中央のシグナリングエンティティとして使用され、複数のクライアントは互いに直接メディアを送信及び受信できる。ＭＣＳの例において、クライアントは、ＷｅｂＲＴＣ（Web Real‐Time Communication：ウェブリアルタイム通信）アプリケーションプログラムインタフェース（ＡＰＩ）を使用できる。ＷｅｂＲＴＣは、オーディオ、ビデオ及びデータ共有のブラウザ対ブラウザリアルタイム通信（Ｐ２Ｐ）を容易にするために、World Wide Web Consortium（ワールド・ワイド・ウェブ・コンソーシアム、Ｗ３Ｃ）により起草された。共通ＷｅｂＲＴＣは、ビデオ用にＶＰ８ビデオコーデックを使用し、オーディオ用にＯＰＵＳオーディオコーデックを使用する。ＶＰ８は、グーグル社（Ｇｏｏｇｌｅ．Ｉｎｃ）に所有されたビデオ圧縮フォーマットである。ＯＰＵＳは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）により開発された不可逆オーディオコーデックである。ＷｅｂＲＴＣ及び圧縮フォーマットＶＰ８は、現在、例えば、例示に限定されないが、Google CHROME（CHROMEはグーグル社の登録商標）、Mozilla FIREFOX (FIREFOXはモジラ財団の登録商標)、OPERA (OPERAはオペラソフトウェアＡＳＡの登録商標)などのブラウザアプリケーションにサポートされている。幾つかのブラウザは、ＷｅｂＲＴＣ及びＶＰ８コーデックを使用するためにプラグインを必要とする。他のＭＣＳは、メッシュ会議を伝えるために、その他のＷｅｂクライアント及びその他の圧縮基準を使用するだろう。

共通ＲＬＳは、複数の仮想会議室（ＶＭＲ）のディレクトリを保持できる。各ＶＭＲは、１つのビデオ会議セッションを表し、それはパスワード付き又はパスワード無しのＶＭＲ識別子（ＶＭＲＩＤ）に関連付けられている。幾つかのＭＣＳにおいて、各ＶＭＲは、個別の統一資源位置指定子（ＵＲＬ）又は統一資源位置識別子（ＵＲＩ）を持ってよい。更に、１つのＶＭＲは、当該ＶＭＲに既に接続された複数のエンドポイントのリストを備える。このリストにおいて、各エンドポイントは１以上のＵＲＬに関連付けられており、他の複数参加者が当該ＶＭＲにコンタクトできるようになっている。各ＵＲＬは、１つのメディアタイプ又はシグナリングに関連付けられる。共通ＭＣＳにおいて、ＲＴＳ状態テーブルとも呼ばれるＲＬＳリストは、ＶＭＲを訪問した最初の参加者から始まりリアルタイムで生成され、当該ＶＭＲに新しい参加者が加わるか又は現在の参加者が当該ＶＭＲから離れるたびに更新される。例示に限定されないが、ＲＬＳの一例は、www.Vline.com.である。

ユーザがメッシュビデオ会議セッションに参加したい場合、そのユーザは、ブラウザアプリケーションを使用し、会議要請により提供されたＵＲＬをクリックして１つのＲＬＳ内の仮想会議室にコンタクトするために、Ｗｅｂクライアントを使用するだろう。ＲＬＳは認証プロセスを開始し、完了次第、ＨＴＭＬ５ファイルがブラウザアプリケーションにダウンロードされ得る。ブラウザアプリケーションは、ＨＴＭＬ５ファイルを構文解析でき、当該仮想意会議室に既に関連付けられている複数ユーザのＵＲＬのリストをダウンロードできる。また、ＪａｖａＳｃｒｉｐｔ（登録商標）ＲＬＳＷｅｂクライアント（ＲＬＳＷＣ）は、ＲＬＳから、例えばGoogle CHROME（登録商標）、Mozilla FIREFOX (登録商標)、又は、OPERA (登録商標)モバイルなどの要求しているブラウザアプリケーションへ、展開され得る。ＲＬＳＷＣは、リアルタイムセッションを確立するために必要とされる論理モジュールを含み得る。ＲＬＳＷＣがブラウザアプリケーションを実行するプロセッサにより使用された場合、該プロセッサは、他のブラウザアプリケーションとのシグナリング及び制御接続を確立でき、メッシュビデオ会議を管理することができる。

幾つかの場合において、ＲＬＳは、また、１つのＶＭＲ状態テーブルを、新規の参加者に転送する。ＶＭＲ状態テーブルは、ビデオセッションに既に参加している複数の相手装置（peer、ピア）の情報を含む。それから、新規の参加者は、シグナリング及び制御接続を確立することにより、他の参加者のエンドポイントそれぞれとビデオ会議セッションを確立する必要がある。システムは、例えばSession Initiation Protocol（ＳＩＰ；セッションイニシエーションプロトコル、セッション確立プロトコル）又はＨ．３２３などに基づき得る。そして、各エンドポイントは、他の各参加エンドポイントに自身のビデオ画像及びオーディオストリームを送信し、且つ、他の各参加エンドポイントからビデオ画像及びオーディオストリームを受信するために、１以上のＳＲＴＰ／ＩＰ及びＳＲＴＣＰ／ＩＰ接続を確立する必要がある。ＳＲＴＰとは、Secure Real-Time Transport Protocol（セキュアＲＴＰ、セキュアリアルタイムトランスポートプロトコル）を表しており、ＳＲＴＣＰとは、Secure Real-Time Control Protocol（セキュアＲＴＣＰ、セキュアリアルタイムコントロールプロトコル）を表す。参加者が当該セッションを去る毎に、ＲＬＳは、それに応じてＶＭＲ状態テーブルを更新できる。ＶＭＲ状態テーブルの更新されたコピーは、最新の変更を現在接続された参加者のそれぞれに供給され得る。幾つかの場合において、更新されたＶＭＲ状態テーブル全体が送信される。別の場合、変更分のみが送信される。したがって、ＭＣＳにおいては、１つの中央エンティティも、参加エンドポイントからメディアストリームを受信、又は、参加エンドポイントへメディアストリームを送信しない。

ビデオ会議基準及びプロトコルの更なる詳細に詳細について知るには、ＩＴＵのＷｅｂサイト、www.itu.int.、また、Internet Engineering Task Force (インターネット技術タスクフォース、IETF)のＷｅｂサイト、www.ietf.org.を訪問することを勧める。従来の多地点会議システム、ＭＲＣ、ＭＣＳ、ＭＣＵ、ＲＬＳ、ＬＥＰ、ＭＲＥ、Ｗｅｂ会議クライアント及びＶＭＲは、技術分野における通常の知識を有する者に知られており、且つ、多くの特許、特許出願、及び、技術書に記載されている。したがって、それらを詳述はしない。下記特許文献１〜１０は、ビデオ会議システムを記載する特許及び特許出願の例である。

米国特許番号第６４９６２１６号米国特許番号第６７５７００５号米国特許番号第７１７４３６５号米国特許番号第７０８５２４３号米国特許番号第８４１１５９５号米国特許番号第７８３０８２４号米国特許番号第７５４２０６８号米国特許番号第８３４０２７１号米国特許番号第８２２８３６３号米国特許出願番号第２０１４００２８７８８号

従来のＭＣＳは、いくつかの制限に悩まされている。かかる制限の１つは帯域幅に集中する。１つメッシュ会議セッションに３つのエンドポイントが参加する場合、各エンドポイントは、２つのオーディオストリームと２つのビデオストリームを、他のエンドポイントそれぞれに１組ずつ伝達し、且つ、２つのオーディオストリームと２つのビデオストリームを、他のエンドポイントそれぞれから１組ずつ受信する。一般に、Ｎ人の参加者からなるフルメッシュ会議は、メディア種類毎にＮ（Ｎ−１）／２のピアーセッションを要する。Ｎ²プロパティは、少数のＮを超えるフルメッシュ会議を即座に使用できなくする。かかる数量のリアルタイムデータに必要な帯域幅は、１つのエンドポイントで利用可能な帯域幅の限界に近いだろう。いかなる追加の参加者も利用可能な帯域幅を超えてしまうだろう。したがって、セッションに参加するためのいかなる追加リクエストも否認されるか、或るいは、毎秒のフレーム数、シャープネス等を減少することにより、圧縮品質が減少される。このことは、係る会議体験の質を深刻に減少させることになる。

従来のＭＣＳの別の限界は、複数のエンドポイントの能力であり得る。例えば、従来のＭＣＳは、全てのエンドポイントが例示に限定されないが例えばＶＰ８など同じ圧縮フォーマットを使用できることを要求する。複数のエンドポイントのうち１つがこの要求を満たせない場合、そのエンドポイントは他のエンドポイントに直接ビデオデータを送信したり又は他のエンドポイントから直接ビデオデータを受信したりできない。

本発明は、上述の点に鑑みてなされたもので、会議システムを会議セッションの現在の状況（condition、コンディション、）にリアルタイムで適合させるためのシステム及び方法を提供することを目的とする。

一実施形態に従い、様々なビデオ会議エンドポイントを備える多地点ビデオ会議システム１００を説明する図。

一実施形態に従い、一実施例に係るＭＣＵの関連要素を示すブロック図。

拡大するメッシュ会議セッションにおける関連イベントのタイミング図。セッションの現在の必要に対して会議手法を適用するためのＲＬＳＷＣの関連アクションを説明するフローチャート。セッションの現在の必要に対して会議手法を適用するためのＲＬＳＷＣの関連アクションを説明するフローチャート。

上述した従来のＭＣＳを欠くことは、いかなる方法においても、この開示に係る発明概念の範囲を制限することを意図するものではない。この欠如は、説明の目的のためにのみ示されている。この開示は、セッションの現在の状況に従い、或るビデオ会議タイプから別のものへ自動移行（transiton）するための新規手法に向けられたものである。

新規手法の一実施形態は、或る会議システムを使用するための複数の状況又は複数のルールのリスト、及び、１つの会議システムから別の会議システムに移動）するための複数のルールのリストを持ち得る。前記複数のルールのリストは、ブラウザがＶＭＲのＵＲＬを要求したときにダウンロードされたＨＴＭＬファイルに埋め込まれ得る。以下は、ＭＣＳが使用され得る場合のための、ルールの幾つかの例である。或る１つのルールは、会議参加者数が或る設定可能な制限数よりも少数であることであり得、設定可能な制限数とは、例えば３から６人の参加者数範囲内であり得る。別のルールは、全てのエンドポイントが例えばＶＰ８など、同じ暗号化／復号化プロトコルを使用できること、であり得る。更に、３つ目のルールは、全てのエンドポイントが、例えばメッシュ会議に参加可能な関連するＲＬＳＷＣを実行できることなど、であり得る。以下は、いつＭＣＵが使用され得るかを決定するための、ルールの幾つかの例である。第１のルールは、会議参加者の数が或る制限数を上回ることであり得る。第２のルールは、個々のエンドポイントが異なる圧縮基準を使うことであり得る。

ＭＣＳからＭＲＣに移動するためのルールの例は、新規の会議参加者がビデオ会議セッションに参加したいこと、を含み得る。新規の会議参加者を含む会議参加者の数が関連するＭＣＳの許容範囲を超えている場合、前記新規の会議参加者を拒否すること又は当該セッションの品質を下げることの代わりに、当該セッションはＭＲＣに移動され得る。新規のセッションは、ＭＲＭを使用して、バックグラウンドで開始され得る。ＭＲＭがＭＲＣの確立を完了したとき、関連するエンドポイントは自動的にＭＲＭに切り替わり、ＭＲＭから取得されたビデオ及びオーディオストリームから生成されたＣＰビデオ画像及び混合オーディオ（mixed audio）を提示することを開始できる。各エンドポイントは、それから、互いのピアツーピアメディア及び制御接続を切断することにより、ＭＣＳセッションを終わらせてよい。それと並行して、ＭＲＭは、そのＭＲＭがＶＭＲＩＤに参加したいということを、ＲＬＳに通知できる。したがって、何れの追加的会議参加者がＲＬＳを呼び出して参加リクエストを送るときでも、新規のエンドポイントは、ＭＲＭを含む更新されたＶＭＲ状態テーブルを持つ参加通知を、取得するだろう。それに応じて、新規のエンドポイントは、ビデオ会議に参加するために、該ＶＭＲＩＤを使ってＭＲＭに自動的に接続するだろう。ＭＣＳからＭＲＣ又は従来の（legacy；レガシー）会議へ移動するための別のルールは、会議参加者の一人が大量のパケット損失を引き起こす不調な接続経由で接続された場合である。問題のセッションは、ＭＣＳからＭＲＣ又はレガシーＭＣＵへ切り替えられる。

例えば、ＭＣＳ又はＭＲＭから従来の会議システムへ移動するなど、或るタイプの会議から別のタイプの会議へ移動するための別のルールは、例えば他のエンドポイントがＶＰ８を圧縮フォーマットを使っているのに或るエンドポイントがＶＰ８を使えない場合など、新規参加者のエンドポイントが他の参加者たちと同じ圧縮フォーマットを使えない場合である。ルールの別の例は、或るエンドポイントが複数のエンドポイントからの複数のオーディオ及び／又はビデオストリームを処理し、それぞれ、復号化して、混合オーディオに混合する及び／又はＣＰビデオ画像を構築するための計算能力を持たない場合である。その場合、ＭＲＣ又はＭＣＳセッションは、従来のビデオ会議セッションに移動して、ＭＣＵを使用する。新規の会議参加者のエンドポイントは、ＶＭＲＩＤを使っているＭＣＵを呼び出し、該ＭＣＵを通して会議セッションを始めることができる。

上述した手法と同様にして、ＭＣＵを通じたセッションは、以前からの会議参加者の間でメッシュビデオ会議又はメディア中継ビデオ会議が続いている間にバックグラウンドで確立され得る。レガシーセッションが確立され、開始されたとき、ＭＣＵは、ＲＬＳにＶＭＲＩＤを含む参加リクエストを送信するように構成され得る。ＲＬＳは、新規の会議参加者として前記ＭＣＵを含む更新されたＶＭＲ状態テーブルに関連付けられた参加通知で応じることができる。並行して、更新されたＶＭＲ状態テーブルは、以前からの会議参加者のエンドポイントのそれぞれに送信され得る。以前からの会議参加者のエンドポイントは、自動的にＭＣＵに切り替えることができ、ＭＲＭから取得したＣＰビデオ画像及び混合オーディオの提示を開始できる。次に、以前からの会議参加者のエンドポイントは、ピアツーピアメディア及他のエンドポイント又はＭＲＭそれぞれのメディア及び制御接続を切断することによりＭＣＳ又はＭＲＣセッションを終わらせてよい。ＭＲＭが予め使用されていた場合、そのＭＲＭは、当該ＭＲＭがメッシュ会議セッションから切断されたことをＲＬＳに知らせる退去指標（indication）を該ＲＬＳに送信するよう構成され得る。それに応じて、ＭＲＭはＶＭＲ状態テーブルから削除され、更新されたＶＭＲ状態テーブルがＶＭＲＩＤ経由で現在接続されている全ての会議参加者に送信される。

幾つかの実施形態において、或るエンドポイントにより使用されているＲＬＳＷＣは、拡大手順（escalation procedure）を管理する拡大モジュール（escalation module）を含むように構成できる。拡大モジュールは、ＲＬＳＷＣの一体部分（integral part）であり、該モジュールはＲＬＳＷＣとともにＷｅｂ（ウェブ）ブラウザにダウンロードされ得る。拡大モジュールのソフトウェアは、例えば読み出し書き込み可能なハードディスク、ＣＤＲＯＭ、フラッシュメモリ、ＲＯＭ又はその他のメモリ又はストレージなど、コンピュータ読み取り可能な媒体に具体化されてよい。拡大手順を実行するために、ソフトウェアプログラムは、必要に応じて適宜のプロセッサにロードされてよい。拡大モジュールの一例は、どのビデオ会議タイプを使用するかに関する複数のルールのリスト及び何時或るタイプのビデオ会議システムから別のタイプに移動するかを示す複数のルールのリストを備えるように構成され得る。

ＶＭＲの一例は、ＩＤテーブルを用いて、２以上の中央エンティティ、ＲＬＳ、ＭＲＭ又はＭＣＵに関連付けられ得る。ＩＤテーブルは、各中央エンティティのＵＲＬ、各中央エンティティのＶＭＲＩＤ、各中央エンティティで使用されるべきパスワードの要否を含み得る。幾つかの実施形態において、ＶＭＲは、２以上の中央エンティティ同士で通信する間に使用され得る１つのパスワードを持つ１つのＩＤ番号を持ってよい。また、同種のＶＭＲとして使用できるＭＲＭ及びＭＣＵの一例は、それらのうち１つが、セッションを処理するように要求される毎、又は、セッションから切断される毎に、ＲＬＳに通知するように構成され得る。同様に、共通ＲＬＳＷＣもＲＬＳに通知できる。更に、各拡大モジュールは、何時ＭＲＭ又はＭＣＵがＶＭＲに接続されたかを識別するように構成される。

ＭＲＭ又はＭＣＵのセッション参加リクエストに応じて、ＲＬＳは、以前の会議参加者にＭＲＭ又はＭＣＵが参加したことを通知する更新されたＶＭＲ状態テーブルを送信してよい。かかる更新されたＶＭＲ状態テーブルを受信するにあたり、以前からの会議参加者のエンドポイントにおける拡大モジュールの一実施形態は、ＭＲＭ又はＭＣＵを呼び出して、そのＶＭＲＩＤに関連付けられたビデオ会議に参加することを開始するように構成され得る。シグナリング及び制御接続、ＭＲＭ又はＭＣＵからの及びＭＲＭ又はＭＣＵへのオーディオ及びビデオを搬送するためのＳＲＴＰ／ＩＰ及びＳＲＴＣＰ／ＩＰ接続を確立した後、そのエンドポイントは、他の以前からの会議参加者のエンドポイントとのメディア接続を切断する。したがって、会議セッションは、それぞれ、ＭＣＳからＭＲＣ又はレガシーセッションに移動された。

幾つかの実施形態において、拡大モジュールは、１つの会議タイプから別のタイプへ移動した理由を取り込むように構成され得る。その理由は、保存されて、後に使用され得る。元の拡大理由がもはや適用されていないことを決定するにあたり、一実施形態に係る拡大モジュールは、ＭＣＳに戻ってよい。例えば、拡大理由が「会議参加者の数が設定された制限を越えている」である場合、会議参加者の数が設定された制限よりも下に戻ったとき、残りのエンドポイントは、ＭＲＣ又はレガシー会議からＭＣＳに戻る。

レガシービデオ会議への拡大である場合、以前からの会議参加者のエンドポイントの拡大モジュールは、どのエンドポイントがＭＣＵのＶＭＲに既に接続されているか識別し、それらエンドポイントをＭＣＳに接続されたエンドポイントと比較するように構成される。ＭＣＳに接続されなかったエンドポイントは、その拡大理由とみなされ得る。それらエンドポイントがセッションから切断する場合、拡大モジュールは例えばＭＣＳ又はＭＲＣに戻ることができる。

幾つかの実施形態において、拡大モジュールは、１つのＲＬＳに具体化され得る。かかる実施形態において、ＲＬＳは、拡大処理（escalation process）を管理でき、複数の参加者のエンドポイントに或る通信タイプから別のタイプへ移動することを通知できる。

図の説明に移ると、これら図において同じ番号は様々な図を通じて同じ要素を表しており、当該開示の実施形態が描かれている。便宜上、共通グループ中の幾つかの要素にのみ、番号が付与されるだろう。図画の目的は実施形態の例を説明することであり、製造の目的ではない。したがって、図に示された特徴は、説明の便宜とわかりやすさのためにのみ選ばれたものである。なお、タイミング図に従う複数イベントは、縮尺を合わせて描かれてはない。更に、この開示に使用された言葉は、原則的に、読み易さ及び説明目的で選ばれており、発明の主題を描写又は制限したり、かかる発明の主題を定義するために必要な請求範囲を訴えたりするために選ばれているのではない。

明細書における“一実施形態”又は“或る実施形態”とは、その実施形態に関連して説明された個別の特徴、構造又は特質がこの発明の少なくとも１つの実施形態に含まれていることを意味しており、“一実施形態”又は“或る実施形態”に対する複数の言及は、必ずしも、同じ実施形態への言及の全てと、理解すべきではない。

また、以下の説明の幾つは、ソフトウェア又はファームウェアに関連する用語で記述されるが、複数の実施形態は、ここで記述された特徴及び機能を、要望通り、ソフトウェア、ファームウェア又はハードウェア、或いは、ソフトウェア、ファームウェア及びハードウェアの任意の組み合わせを含みで実装するだろう。以下の説明において、“ユニット”、“エレメント”、“モジュール”及び“論理モジュール”は互換的に使用されるだろう。ユニット又はモジュールとして示されたものは何でも、スタンドアローンユニット、又は、専用の若しくは統合されたモジュールであってよい。ユニット又はモジュールは、モジュラーであるか又はモジュラーの態様を持ち、取り外し及び別の同種のユニットモジュールへの取替えを簡単に行えるものである。各ユニット又はモジュールは、ソフトウェア、ハードウェア、及び／又は、ファームウェアのどれか１つ、又は、その任意の組み合わせであってよく、最終的に、ユニット又はモジュールに与えられた機能を実行するようにプログラムされた１以上の処理装置となる。加えて、同種の又は異なる種の複数のモジュールが、単一の処理装置により実装されてよい。論理モジュールのソフトウェアは、例えば読み書き可能なハードディスク、ＣＤＲＯＭ、フラッシュメモリ、ＲＯＭ、又は、その他のメモリ若しくはストレージなど、コンピュータ読み取り可能な媒体に記録されてよい。何らかのタスクを実行するために、ソフトウェアプログラムは、必要に応じて適宜の処理装置にロードされる。本開示において、用語“タスク”、“方法”、“処理”は互換的に使用できる。

図１は、本発明の一実施形態に従う、新規のマルチメディア会議システム１００を説明する図である。システム１００は、１つのネットワーク１１０、１以上のＲＬＳ１１４、１以上のＭＣＵ１１８、複数のＭＣＳエンドポイント（ＭＣＳＥＰ）１３２、複数のＭＲＥ１３４、及び、複数のＬＥＰ１３６を具備する。ネットワーク１１０は、例示に限定はされないが、例えば、パケット交換ネットワーク、回線交換ネットワーク、ＩＰネットワーク、又は、それらの任意の組み合わせであり得る。ネットワーク経由のマルチメディア通信は、例示に限定はされないが、例えば、Ｈ．３２０、Ｈ．３２３、ＳＩＰ、ＨＴＴＰ、ＨＴＭＬ５、ＳＤＰなどの通信プロトコルに基づき得るものであり、且つ、例示に限定はされないが、例えば、Ｈ．２６３、Ｈ．２６４、ＶＰ８、Ｇ．７１１、Ｇ．７１９及びＯｐｕｓなどのメディア圧縮規格を使用してよい。ＨＴＴＰはハイパーテキスト・トランスファー・プロトコルを表し、ＨＴＭＬはハイパーテキスト・マークアップ・ランゲージを表す。

ＲＬＳ１１４の一例は、共通のＨＴＴＰを使ってネットワーク１１０を通じて複数のコンピューティング装置と通信できるＷｅｂサーバであり得る。ＲＬＳ１１４は複数のＶＭＲファイルを保存できる。各ファイルは、１つのＶＭＲＩＤに関連付けられ、そのＶＭＲＩＤを示す１つのＵＲＬを持つ。

幾つかの実施形態において、ＶＭＲＨＴＭＬ５ファイルは、１つの会議手法から別の会議手法へ移動するための複数のルールのリストと、セッションに現在接続されたＭＣＳＥＰ１３２の全ての要素のＵＲＬを含むＶＭＲ状態テーブルと、ＶＭＲＩＤに接続されたＭＣＳＥＰ１３２から取得されるビデオ画像が配置されるウィンドウ画面についての情報と、ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションへのリンクと、ＭＣＵ１１８と通信するためのＳＩＰシグナリングを扱うことのできる別のＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションへのリンクとを含んでよい。このＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションは、ＳＩＰＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションと呼ばれ得る。ＲＬＳ１１４の幾つかの実施形態は、新規のＭＣＳＥＰ１３２がＶＭＲに接続されたとき、又は、或る会議参加者が該ＶＭＲから離れたとき、そのＶＭＲに既に接続された全ての参加中のＭＣＳＥＰ１３２に、更新されたＶＭＲ状態テーブルを送信するように構成される。

ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションの一実施形態において、ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションは、ブラウザアプリケーションにより実行されているときに、ＶＭＲ状態テーブルに従って別のＷｅｂＲＴＣピアーと１つのＲＴＣセッションを確立するようＷｅｂＲＴＣＡＰＩに要求するように構成され得る。ＷｅｂＲＴＣＡＰＩ及び基礎をなす能力は、元々からブラウザにサポートされている（パフォーマンスオーバヘッドを除去すること及びプラグインのダウンロードに関連するセキュリティー問題など）。ＷｅｂＲＴＣクライアントは、ＭＣＳＥＰ１３２を備える他の複数クライアントからの及び他の複数クライアントへのメディアを処理できる。

また、ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションは、会議セッションの現在の状況を調べ、それを複数ルールのリストと比較するように構成でき、それにより、現在のセッションの状況に従いリアルタイムで会議手法を適合させることにより、或る会議システム方法から別の会議システム方法へ適合させることができる。ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションの幾つかの実施形態は、ＶＭＲに接続された１つのＭＣＵを識別するように構成され得る。幾つかの実施形態において、ＶＭＲ状態テーブル内のＭＣＵのＵＲＬは、ＭＣＵの代表を含み得る。

ＭＣＳＥＰ１３２は、ネットワーク１１０を通じた有線又は無線通信能力を持つどのようなコンピューティング装置でもあり得る。ＭＣＳＥＰ１３２の一例は、ラップトップコンピュータ、ノートブック、スマートフォン、タブレット、タッチスクリーン式携帯電話などであり得る。ＭＣＳＥＰ１３２の一例は、例えば、ＷｅｂＲＴＣＡＰＩ又は同様の能力を持つ別のＡＰＩを有するブラウザアプリケーションを使用することにより、ネットワーク１１０を通じたメッシュビデオ会議セッションに参加できる。例えば、例示に限定はされないがGoogle CHROME（CHROMEはグーグル社の登録商標）、Mozilla FIREFOX (FIREFOXはモジラ財団の登録商標)、OPERA (OPERAはオペラソフトウェアＡＳＡの登録商標)などのブラウザアプリケーションが使用され得る。

或るＭＣＳＥＰ１３２のユーザは、或る１つのＶＭＲ経由で管理される会議セッションに参加するよう要請されるだろう。要請は、或るＶＭＲへの１つのリンク（典型的には１つのＵＲＬ）を含む電子メールであり得る。そのリンクはＲＬＳ１１４を指し、同様に、該ＶＭＲを識別するために使用されるＶＭＲＩＤを示し得る。そのリンクをクリックするにあたり、ユーザは、ＵＲＬ、ＶＭＲＨＴＭＬファイルに関連付けられたＨＴＭＬ５ファイルを要求するフェッチ要求を送信するブラウザアプリケーションをアクティブにする。受信されたＶＭＲＨＴＭＬファイルは、ブラウザによって構文解析され、ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションへのリンクをアクティブにするにあたり、ＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションがダウロードされ、アクティブにされ得る。ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションは、ＪａｖａＳｃｒｉｐｔ（登録商標）コードを含み、同様にＨＴＭＬ５を含み得る。ブラウザはＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションをアクティブにするとき、ＨＴＭＬファイルの構文解析を続ける。１つの会議手法から別の会議手法へ移動するための複数のルールのリスト、ＶＭＲ状態テーブル、ＶＲＭＩＤに関連付けられたＭＣＵ１１８のＩＤなどが保存されるだろう。そして、ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションは、例えば、例示に限定されないが、他の複数のピアーとメディア接続を設定するためのＷｅｂＲＴＣなど、Ｗｅｂクライアントを呼び出す。ここではＪａｖａＳｃｒｉｐｔ（登録商標）に関して説明したが、その他のスクリプト言語が使用され得る。

ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションの幾つかの実施形態は、更に、何時１つの会議手法から別の会議手法に切り替えるかを決定するように構成されてよい。決定は、複数ルールのリストに基づき得る。ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションが、従来の会議手法に切り替えてＭＣＵ１１８にセッションを管理させることを決定をしたとき、ＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーション実行可能なＳＩＰは、ＲＬＳ１１４からダウンロードされ、ＭＣＵ１１８に要請するためにアクティベートされ得る。幾つかの実施形態において、ＳＩＰＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションはＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションの部分であり得る。別の実施形態において、ＳＩＰＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションはＨＴＭＬ５ファイルに埋め込まれ得る。ＲＬＳＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションについての動作の更なる説明は、図３及び図４を参照して後述する。

ＭＣＵ１１８の一例は、複数のＬＥＰ１３６の間での従来のＣＰビデオ会議を管理するための共通ＭＣＵの要素を含むように構成され得る。また、ＭＣＵ１１８は、１以上のＭＲＥ１３４と通信するためのＭＲＩインタフェースモジュールを有し得る。更に、ＭＣＵ１１８の実施形態は、１以上のＭＣＳＥＰ１３２と通信するためのＭＣＳＥＰインタフェースモジュールを含むように構成され得る。

ＭＣＵ１１８は、ＶＭＲＩＤを処理するためのＣＰビデオ会議を確立することにより、ＭＲＥ１３４又はＬＥＰ１３６から受信したＶＭＲＩＤへの参加の最初のＳＩＰ要請に応答するように構成され得る。また、ＭＣＵ１１８は、ＶＭＲＩＤに参加したという指標（indication）をＲＬＳ１１４に送信するように構成される。それに応じて、ＲＬＳ１１４は、ＭＣＵ１１８のＵＲＬを持つＶＭＲ状態テーブルを更新でき、該ＶＭＲＩＤに既に接続されているＭＣＳＥＰ１３２に関連付けられた全ての以前からの参加者にそれを送信できる。ＭＣＵ１１８の動作の詳細は、図２〜図４に記載される。

ＬＥＰ１３６及びＭＲＥ１３４は、それぞれ、従来のＬＥＰ及びＭＲＥと同様な機能性を持ち得る。エンドポイントの各種類は、ＶＭＲへの参加を要請されたときにＭＣＵ１１８を呼び出すように構成され得る。

図２は、１つの会議手法から別の会議手法に移動可能に構成されたＭＣＵ２００の一実施形態に関連する要素を含むブロック図を描く。ＭＣＵ２００は、複数のＬＥＰ１３６と通信するための１以上のＬＥＰインタフェースモジュール２２２、複数のＭＲＥ１３４と通信するための１以上のＭＲＥインタフェースモジュール２２４、及び、複数のＭＣＳＥＰと通信するための１以上のＭＣＳＥＰインタフェースモジュール２８０を備えてよい。また、ＭＣＵ２００は、１つのオーディオモジュール２３０、１つのビデオモジュール２５０及び制御モジュール２４０を具備できる。

ＭＣＳＥＰインタフェースモジュール２８０は、ＨＴＭＬ５及びＪａｖａＳｃｒｉｐｔ（登録商標）モジュール２８４と、ＷｅｂＲＴＣモジュール２８２を具備する。オーディオモジュール２３０は、圧縮オーディオ入力モジュール２３１Ａ−Ｃを備え、圧縮オーディオ入力モジュール２３１Ａ−Ｃの各々はデコーダ２３２を含み、デコーダ２３２は圧縮オーディオを取得し、それをデコードして、デコードされたオーディオを共通インタフェースバス２３４に供給する。出力オーディオモジュール２３５Ａ−Ｃは、それぞれ、圧縮された混合オーディオを供給するために、分析器及びミキサ２３６とエンコーダ２３８を含む。ビデオモジュール２５０は、圧縮入力ビデオモジュール２５１Ａ−Ｃを備え、圧縮入力ビデオモジュール２５１Ａ−Ｃの各々は、圧縮ビデオをデコードし、デコードされたビデオを共通インタフェースバス２５４に配置するために、デコーダ２５２を含む。ビデオモジュール２５０はまた出力ビデオモジュール２５５Ａ−Ｃを備え、出力ビデオモジュール２５５Ａ−Ｃは、圧縮ビデオを供給するためのエディタ２５６及びエンコーダ２５８を含む。

制御モジュール２４０は、Ｔ１６から図３とともに下記に開示されるように拡大手順の間にＭＣＵ２００の内部モジュールの動作を制御するための拡大モジュール（escalation module）２４２を含む。

リンク２０３は、ＬＥＰインタフェースモジュール２２２をオーディオモジュール２３０に接続して、圧縮オーディオを供給する。リンク２８３ａは、ＭＣＳＥＰインタフェースモジュール２８０をオーディオモジュール２３０に接続して、デコードされたオーディオを供給する。リンク２８３ｂは、デコード済み混合オーディオバス２３４を、オーディオモジュール２３０からＭＣＳＥＰインタフェースモジュール２８０に接続して、デコード済み混合オーディオを関連するＭＣＳＥＰ１３２に供給する。リンク２０４は、制御モジュール２４０とＬＥＰ、ＭＲＥ及びＭＣＳＥＰインタフェースモジュール２２２、２２４及び２８０の間の制御リンクを提供する。リンク２８５ａは、ＭＣＳＥＰインタフェースモジュール２８０をデコード済みビデオを供給するビデオモジュール２５０に接続して、デコード済みビデオを供給する。リンク２８５ｂは、ビデオモジュール２５０のエディター２５６をＭＣＳＥＰインタフェースモジュール２８０に接続して、関連するＭＣＳＥＰ１３２にデコード済みＣＰビデオ画像を供給する。リンク２０５は、ビデオモジュール２５０をＬＥＰ及びＭＲＥインタフェースモジュール２２２及び２２４に接続して、圧縮ビデオを供給する。

ＬＥＰインタフェースモジュール２２２は、ＭＣＵ１１８経由で１以上のＬＥＰ１３６にネットワーク接続を提供する一方、ＭＲＥインタフェースモジュール２２４は、１以上のＭＲＥ１３４にネットワーク接続を提供し、ＭＣＳインタフェースモジュール２８０は、１以上のＭＣＳＥＰ１３２及びＲＬＳ１１４にネットワーク接続を提供する。ＬＥＰインタフェースモジュール２２２、オーディオモジュール２３０及びビデオモジュール２５０の一般的な動作は、当該技術分野の通常の知識を有するものに周知であり、詳述しない。また、ＨＴＴＰ，セキュアリアルタイムプロトコル（ＳＲＴＰ）など、ＨＴＭＬ５＋ＪＳＳＩＰモジュール２８４及びＷＥＢＲＴＣモジュール２８２の一般的な動作は周知であり、詳述しない。

図３は、ＶＭＲを管理し、メッシュ会議をレガシー会議に変換する間の、関連するイベントのタイミング図２００を示す。Ｔ０（不図示）において、ＶＭＲＩＤが開始される。Ｔ１からＴ１２の間、セッションは、３つのＭＣＳＥＰ１３２により実行された３つのＲＬＳＷＣの間でＭＣＳ技術を使用することにより処理される。Ｔ１において、ＶＭＲＩＤへの参加リクエストがＲＬＳＷＣＡからＲＬＳ１１４に送信され、ＲＬＳ１１４は、Ｔ２において、ＶＭＲ状態テーブルとともに応答する。同様に、Ｔ３において、ＲＬＳＷＣＢは、ＶＭＲＩＤにより識別される会議に参加することを要求する。そして、Ｔ４において、ＲＬＳＷＣＡ及びＲＬＳＷＣＢは、更新されたＶＭＲ状態テーブルを受信する。Ｔ５及びＴ６において、ＲＬＳＷＣＡ及びＲＬＳＷＣＢの間のメディア接続がなされる。同様に、Ｔ７〜Ｔ１２は、第３のエンドポイントＲＬＳＷＣＣが当該ＶＭＴでの会議に参加することを示す。

Ｔ１３において、第４のＲＬＳＷＣＤはセッションに参加したいが、そのことはＴ１４〜Ｔ３４の矢印により示されるように、ＶＭＲセッションをＭＣＵ１１８に移動させる原因となる。Ｔ１４において、ＲＬＳ１１４は、更新されたＶＭＲ状態テーブルを４つの全ての参加者に送信する。Ｔ１５において、ＲＬＳＷＣＤは、ＭＣＵ１１８に対して会議への参加を要請する。ＭＣＵ１１８は、Ｔ１６において、それを承認し、Ｔ１７において、ＲＬＳＷＣＤとのメディア接続を確立する。

ＭＣＵ１１８は、それから、Ｔ１８において、ＲＬＳ１１４にＶＭＲＩＤを送信することにより会議に参加することを要求し、Ｔ１９において、ＲＬＳ１１４に、更新されたＶＭＲ状態テーブルをＲＬＳＷＣＡ〜Ｄ及びＭＣＵ１１８宛に送信させる。Ｔ２０〜Ｔ２３において、ＲＬＳＷＣＡは、ＭＣＵ１１８に接続し、Ｔ２４においてＲＬＳＷＣＢ及びＣへの接続を中断する（ドロップする、dropping）前に、メディア通信を始める。同様に、ＲＬＳＷＣＢは、Ｔ２５〜Ｔ２８において、ＭＣＵ１１８に接続して、Ｔ２９においてＲＬＳＷＣＡ及びＣとの接続を中断する。最後に、ＲＬＳＷＣＣは、Ｔ２６〜Ｔ３３において、ＭＣＵ１１８に接続して、Ｔ３４においてＲＬＳＷＣＡ及びＢから切断する。メッシュ会議は、今や、レガシー会議になった。

図４Ａ及びＢは、ＲＬＳＷＣにより実行され得る手法４００の一例の関連するアクションのフローチャートを示しており、フローチャートの処理は１つの会議手法から別の手法に移動している間に、ＭＣＳＥＰ１３２により実行される。別の実施形態においては、手法４００はＲＬＳサーバ１１４により実行され得る。幾つかの実施形態において、例えば、拡大プロセスを終わらせる手法の一部が拡大モジュール２４２により実施され得る。

アクション４０２〜４２４は、会議手法を変更するかどうかを決定するための更新されたＶＭＲ状態テーブルの受信にあたりＲＬＳＷＣの一例が実行できるアクション（処理、actions）を示す。

ブロック４０２において、ＲＬＳＷＣタスクが始まる。ブロック４０４において、参加リクエストがＶＭＲＩＤとともに送信され、タイマーがリセットされる。ブロック４１０において、ＶＭＲ状態テーブルが受信されたかどうか決定される。受信されていない場合は、ブロック４１２においてタイマーがタイムアウト閾値を超過すると、ブロック４１４において、参加リクエストが不成功であったことがユーザに通知される。タイマーが閾値を超えていない場合は、タスクはブロック４１０に戻る。

ＶＭＲ状態テーブルが受信された場合、ＶＭＲ状態テーブルは、ブロック４１６において構文解析され、ブロック４２０〜４２４において複数ルールのリストと比較される。アクティブＭＣＵが用いられている場合（４２０）又はコーデックが他のエンドポイントのコーデックと一致（match）しない場合（４２２）、又は、会議参加者数Ｎが制限値Ｎ１を越えている場合（４２４）、ブロック４２６において、ＷｅｂＲＴＣＡＰＩはＭＣＵとメディア接続を設定するように命じる。アクション４２６〜４４４は、或るＭＣＳから或るＭＣＵへ手法を移動することを示す。ブロック４３１において、タスクはＭＣＵが接続されるまで待ち、そして、ブロック４３３において、図４Ｂのブロック４５０に進む前に、レイアウト上の適切なウィンドウ又はセグメント内にＣＰビデオ画像を提示することを開始する。

ＭＣＵが接続されておらず（４２０）、全てのコーデックが一致し（４２２）、且つ、ＮがＮ１よりも小さい場合、アクション４２８〜４４２において、セッションは、ＭＣＳとしての動作のままである。ブロック４２８において、ＷｅｂＲＴＣＡＰＩは、接続されたＲＬＳＷＣのそれぞれとのメッシュ会議を行い、受信されたビデオ画像を関連付けられたウィンドウに配置するように指示される。ブロック４３０において、タスクは、別のＶＭＲ状態テーブルを受信することを待つ。受信に応じて、ブロック４３２において、ＨＴＭＬ５ファイル及びＶＭＲ状態テーブルが構文解析され、ＭＣＵの状態が調べられる。ブロック４３４において、アクティブなＭＣＵが見つからない場合、タスクは、別のＶＭＲ状態テーブルを待つことに戻る。ブロック４３４において、アクティブなＭＣＵが見つかった場合、ブロック４３６において、ＷｅｂＲＴＣＡＰＩは、そのＭＣＵとのメディア接続を行うように指示され、該ＭＣＵが接続されるまで、ブロック４４０で待つ。接続に応じて、ブロック４４２において、ＲＬＳＷＣは、以前の独立したビデオ画像の提示を停止し、適切なウィンドウ内に前記ＭＣＵから受信したＣＰビデオ画像を提示することを開始する。幾つかの実施形態では、拡大の理由が保存される。ブロック４４４のタスクは、それから、図４Ｂのブロック４５０に進む。

アクション４５０（図４Ｂ）〜４６４は、ＭＣＵからＭＣＳに戻るときに実行され得るアクションを示す。ブロック４５０に入り、タスクはブロック４５１において、別のＶＭＲ状態テーブルを待つ。ブロック４５２において、ＶＭＲ状態テーブルが構文解析され、保存された拡大の理由と比較される。拡大の状況が依然として当てはまる場合（４５４）、タスクは、ブロック４５１において別のＶＭＲ状態テーブルを待つことに戻る。拡大の状況がもう存在しない場合、ブロック４５６において、タスクは、ＷｅｂＲＴＣＡＰＩは、他の接続されたＲＬＳＷＣとメッシュ接続を行うことを開始して、適当なウィンドウに受信されたビデオ画像を配置するように指示される。

ブロック４６０において全てのメッシュ接続が完了するのを待った後、ブロック４６２において、ＭＣＵ接続が切断され、ＷｅｂＲＴＣＡＰＩは、独立した各ビデオ画像を、ＨＴＭＬ５ファイル内の関連付けられたウィンドウに配置するように指示される。タスクは、それから、ブロック４６４において、図４Ａのブロック４３０に進む。

以上は、例示を意図したもので制限を意図したものではない。例えば、前述の実施形態は、互いに組み合わせて使用されてよい。上記の説明を吟味することで、当業者にとって他の多くの実施形態が明白であろう。

なお、上記は説明を意図したもので、制限を意図したものでないことが理解されるべきである。前記の装置、システム及び方法は、ステップの順番、及び、使用された正確な実施を変更することを含み、様々に変更されてよい。前記実施形態は種々の特徴を含んでいるが、それらの全てがこの開示における全ての実施形態に要求されるのではない。さらには、この開示の幾つかの実施形態は、幾つかの特徴のみ又は複数の特徴な可能な組み合わせのみを使用する。この開示に示された種々の特徴の組み合わせは、当業者に思いつくものであろう。更に、この開示の幾つかの実施形態は、この開示における異なる実施形態に関連して記載された特徴及び要素の組み合わせにより実施されてよい。この発明の範囲は、以下の特許請求範囲及びその等価物によってのみ制限される。

１００マルチメディア会議システム、１０１ネットワーク、１１４ロスターリストサーバ（ＲＬＳ）、１１８多地点制御ユニット（ＭＣＵ）、１３２メッシュ会議システムエンドポイント（ＭＣＳＥＰ）、１３４メディア中継エンドポイント（ＭＲＥ）、１３６レガシーエンドポイント（ＬＥＰ）

Claims

ビデオ会議セッションに現在メッシュ接続されている１以上のメッシュ会議システムエンドポイントを示す仮想会議室状態テーブルを受信することと、
複数のルールのリストを用いて前記仮想会議室状態テーブルを評価することと、
前記評価に応じて、１つの多地点制御ユニットに前記ビデオ会議セッションを管理するように要請するかどうかを決定すること
を備える方法。
前記仮想会議室状態テーブルは、メッシュウェブクライアントのためのアプケーションプログラムインタフェースを含むように構成された、或るメッシュ会議システムエンドポイントのプロセッサにより実行されるブラウザアプリケーションにより受信されることを特徴とする請求項１に記載の方法。
前記アプケーションプログラムインタフェースは、ウェブリアルタイム通信アプケーションプログラムインタフェースであることを特徴とする請求項２に記載の方法。
前記リストのうちの１つのルールは、前記ビデオ会議セッションに参加する前記メッシュ会議システムエンドポイントの数が或る閾値を越えた場合に、前記多地点制御ユニットに該ビデオ会議セッションを管理するように要請するものである請求項１に記載の方法。
前記閾値が設定可能であることを特徴とする請求項４に記載の方法。
前記閾値は３〜６人の参加者数の範囲内であることを特徴とする請求項４に記載の方法。
前記多地点制御ユニットは１つのメディア中継エンドポイントを前記ビデオ会議セッションに接続するように構成されることを特徴とする請求項１に記載の方法。
前記ビデオ会議セッションに現在参加している１以上の前記メッシュ会議システムエンドポイントからの複数のビデオ画像のデータを含む圧縮されたビデオの１つのストリームを伝送するように前記多地点制御ユニットを構成することを更に備える請求項１に記載の方法。
ビデオ会議セッションに参加している複数のメッシュ会議システムエンドポイントから圧縮されたオーディオ及び圧縮されたビデオを受信し、且つ、１以上の前記複数のメッシュ会議システムエンドポイントから受信された複数のビデオ画像を含む圧縮されたビデオの１つのストリームを前記メッシュ会議システムエンドポイントのそれぞれに伝送するように構成されたメッシュ会議システムエンドポイントインタフェースモジュールと、
オーディオモジュールと、
ビデオモジュールと、
この多地点制御ユニットの動作を制御するための制御モジュールと
を備える多地点制御ユニット。
前記メッシュ会議システムエンドポイントインタフェースモジュールが、更に、
前記オーディオモジュールからデコード済み混合オーディオを、また、前記ビデオモジュールからデコード済み常駐表示ビデオ画像を受信し、
前記混合オーディオ及び前記常駐表示ビデオ画像を圧縮し、且つ、
別のメッシュ会議システムエンドポイントに、前記圧縮された混合オーディオ及び前記圧縮された常駐表示ビデオ画像を伝送するように構成されることを特徴する請求項９に記載の多地点制御ユニット。
１つのビデオ会議セッションに参加している複数のメディア中継エンドポイントから複数の圧縮されたオーディオ及び圧縮されたビデオのストリームを受信し、前記複数のメディア中継エンドポイントのそれぞれに圧縮された混合オーディオ及び圧縮された常駐表示ビデオのストリームを伝送するように構成されたメディア中継エンドポイントインタフェースモジュールを更に備え、
前記圧縮された混合オーディオ及び前記圧縮された常駐表示ビデオは、前記ビデオ会議セッションに参加している１以上のメッシュ会議システムエンドポイントから受信されたオーディオ及びビデオのデータを含むものである、
ことを特徴とする請求項９に記載の多地点制御ユニット。
１つのビデオ会議セッションに参加している複数のレガシーエンドポイントから複数の圧縮されたオーディオ及び圧縮されたビデオのストリームを受信し、前記オーディオモジュールから混合オーディオを、また、前記ビデオモジュールから常駐表示ビデオ画像を受信し、前記混合オーディオと常駐表示ビデオ画像を圧縮し、且つ、前記圧縮された混合オーディオ及び前記圧縮された常駐表示ビデオ画像を、前記複数のレガシーエンドポイントに伝送するように構成されたレガシーエンドポイントインタフェースモジュールを更に備え、
前記圧縮された混合オーディオ及び前記圧縮された常駐表示ビデオは、前記ビデオ会議セッションに参加している１以上のメッシュ会議システムエンドポイントから受信されたオーディオ及びビデオのデータを含むものである、
ことを特徴とする請求項９に記載の多地点制御ユニット。
前記制御モジュールが、
１以上の拡大ルールを評価し、前記評価に応じて１つのレガシービデオ会議又は１つのメディア中継ビデオ会議を１つのメッシュビデオ会議に変換するように構成された拡大モジュール
を更に備えることを特徴とする請求項９に記載の多地点制御ユニット。
前記１以上の拡大ルールのうち１つの拡大ルールは、１つのメッシュビデオ会議内の最大参加者数を規定するものであることを特徴する請求項１３に記載の多地点制御ユニット。
前記１以上の拡大ルールのうち１つの拡大ルールは、何時１つのレガシービデオ会議又は１つのメディア中継ビデオ会議を１つのメッシュビデオ会議に変換するかを決定するための参加者数の閾値を規定するものであることを特徴する請求項１３に記載の多地点制御ユニット。
メッシュ会議システムエンドポイントのプロセッサによって実行される複数の命令からなるプログラムであって、前記プロセッサに、
１つの種類のビデオ会議から別の種類のビデオ会議に変換するための１又は複数のルールを評価するステップと、
前記１又は複数のルールの評価に基づいて、１つの多地点制御ユニットに前記ビデオ会議への参加を要請するステップ
を実行させるプログラム。
前記１又は複数のルールは、前記ビデオ会議への参加者数に基づく１つのルールを含むことを特徴する請求項１６に記載のプログラム。
前記１又は複数のルールは、前記多地点制御ユニットが前記ビデオ会議においてアクティブかどうかに基づく１つのルールを含むことを特徴する請求項１６に記載のプログラム。
前記１又は複数のルールは、前記ビデオ会議において複数の参加者によって用いられているコーデックに基づく１つのルールを含むことを特徴する請求項１６に記載のプログラム。