JP5242590B2 - Ｖｏｉｐ会議 - Google Patents

Description

本発明は、一般に、電話会議の分野に、より詳細にはＶＯＩＰベース（ボイス・オーバ・インターネット・プロトコル）会議システムに関する。

本発明は、「ＶｏＩＰ Ｃｏｎｆｅｒｅｎｃｉｎｇ」と題され、参照により本明細書に組み込まれる、２００６年３月１５日付けで提出された仮特許出願第６０／７８２，５６９号への優先権を主張する。

ＶＯＩＰ（ボイス・オーバ・インターネット・プロトコル）は、標準的なＰＳＴＮ（公衆交換電話網）に対して著しい費用優位を提供する。さらに、ＶＯＩＰシステムに機能を追加することは、ＰＳＴＮシステムよりも容易である。この傾向は、電話会議システムにまで及んでいる。しかし、現在ＰＳＴＮ用に使用されているのと同じ技術をＶＯＩＰ会議用に使用することは、例えば会議設備間の負荷分散及び設備障害からの回復等の特に信頼性を改善する機能に関して、ＶＯＩＰ会議システムを不必要に制限するであろう。

よって、インターネットを含むネットワーク化を使用することにより提供され得る機能を利用するＶＯＩＰ会議システムに対する要求が存在する。

本発明は、内部的にＶＯＩＰに基づく会議システムであり、並びに容易に異なるプロトコルを処理し、複数のアプリケーションサーバとメディア資源との間で負荷分散を行い、且つ障害状況に対処する。会議システムは、ＰＳＴＮ（公衆交換電話網）に結合されるゲートウェイを有することが可能であり、それにより伝統的なＰＳＴＮ発呼側のための従来のサービスアクセス方法を維持する。発明の本実施は、内部的発呼制御プロトコルとしてＳＩＰを用いるが、ＳＩＰの代わりに又は加えて、他のプロトコルが用いられてもよい。

外部発生の発呼は、ＰＳＴＮ起源か生来のＶｏＩＰかにかかわらず、１つ以上のプロキシサーバを介して会議システムにＳＩＰで通信する。プロキシは、新しい発呼要求を識別し、且つ、これを最初にボイス・サービス・ディレクタ（ＶＳＤ）アプリケーションに転送し、その上複数の利用可能なＶＳＤインスタンスの中で負荷分散を実行する。ＶＳＤは、音声自動応答（ＩＶＲ）機構を使用することにより、発呼を認証し且つ／又は所望の会議を識別する。ＶＳＤは、ＳＩＰを発呼制御プロトコルとして用いて、発呼側に音声プロンプトを再生し且つＤＴＭＦ検出機能を実行するメディアサーバを制御するために、バック・トゥ・バック・ユーザエージェント（Ｂ２ＢＵＡ）を使用する。Ｂ２ＢＵＡの使用は、発呼側をＶＳＤにより使用される特定のメディアサーバ資源から分離し、ＶＳＤに利用可能な任意のメディアサーバ資源を利用させる。発呼側の発呼制御はＶＳＤにおいて終端し、一方でＶＳＤは、発呼側の個々のメディアストリームを処理するために割り当てられるメディアサーバ資源を独立して管理する。

メディアサーバ資源と連携してＶＳＤが発呼側から必要な情報を収集した後、ＶＳＤは、パスコードが有効であるかどうかを確かめ、有効であれば、発呼側を次にどこに送るべきかを確かめるために、バックオフィスサーバに問い合わせを行う。これが会議の最初の発呼側である場合、バックオフィスは、負荷分散アルゴリズムを使用して、どのブリッジで会議を開始するかを決定する。他方で、会議が既に開始されている場合は、バックオフィスは、会議が行われているブリッジを識別するであろう。このブリッジ選択情報は、次に発呼側を所望のブリッジに転送するＶＳＤに送り返される。

Ｂ２ＢＵＡをも用いるブリッジソフトウェアは、高レベルで会議及び個々の発呼側を制御する会議「ブリッジ」として動作し、一方で低レベルメディア動作（例えば、オーディオ混合、プロンプト再生、及びＤＴＭＦ検出等）は、ブリッジソフトウェアアプリケーションにより制御されているメディアサーバ資源上で実行される。所与のブリッジソフトウェアアプリケーションは、複数のメディアサーバ資源を制御してもよく、且つ所与のメディア資源は、１つ以上のＶＳＤ又はブリッジソフトウェアアプリケーションにより利用されてもよい。ＶＳＤが発呼側を転送する場合、発呼側及び所望の行動（例えば、特定の会議に参加する）についての情報は、転送要求自身に含まれる。特に発呼側の電話番号及び／又はＩＰアドレス、会議パスコード、ダイヤルされる番号並びに他の情報は、ＳＩＰ ＲＥＦＥＲコマンドの「クッキー」パラメータに渡される。この機構の使用により、「帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）」の機構を介してＶＳＤとブリッジソフトウェアアプリケーションの間でこの必要な情報を渡す必要性が排除され、一方でその特定の発呼側に情報が明確に結び付けられる。

システムは、プロキシ、メディアサーバ、会議制御（「会議ブリッジ」）アプリケーション、バックオフィスサーバ及びボイス・サービス・ディレクタが異なる場所にあるように分散されてもよい。これは、特定の資源が障害を発生し、又は最大限若しくは過負荷になる場合、代替資源に切り替える機構を提供する。所与のメディアサーバ資源が最大限になる場合、ＶＳＤ又は「ブリッジ」は追加のメディアサーバを使用してもよい。「ブリッジ」に関しては、既存の会議を拡張し又は単一のメディアサーバ資源で通常処理され得るよりも大きな会議を許容するために、複数のメディアサーバを共に結び付けることもまた必要になる場合がある。単一の会議を処理するために複数の「ブリッジ」アプリケーションを共に結び付けることもまた有利であり、その上、この単一のインスタンスが過負荷になる場合があるので、単一の「ブリッジ」から多くのメディアサーバ資源を制御するよりも、むしろ各ブリッジは自身のメディア資源を制御する。この場合において、ブリッジアプリケーションは、メディアサーバ資源を直接管理するために必要とされる詳細化されたレベルよりも抽象化されたレベルの、高レベルで相互作用する。

システムはまた、ダイヤルアウトと呼ばれる発呼をＰＳＴＮ又はＶｏＩＰ終点のどちらかにもたらすことが出来る。発呼がゲートウェイを介して為されている場合、ＳＩＰ ＩＮＶＩＴＥメッセージは、宛先電話番号又は連絡情報を含むであろう。

本発明の１実施形態によるＶＯＩＰ会議システムのブロック図である。 本発明の１実施形態による分散ＶＯＩＰ会議システムのブロック図である。 本発明の１実施形態による分散ＶＯＩＰ会議システムを使用する分散会議のブロック図である。 本発明の１実施形態による典型的なＰＳＴＮ会議参加者の発呼流れ図である。 本発明の１実施形態による典型的な生来のＶＯＩＰ会議参加者の発呼流れ図である。

（図面の詳細な説明）
本発明は容易に、異なるプロトコルを処理し、資源を負荷分散し且つフェイルオーバ状況に対処することが出来るＶＯＩＰ会議システムである。知られていない可能性がある複数の用語が、本願において使用される。結果として、本願で使用されるいくつかの用語のリスト及び代表的な定義が、こうした用語を明確にするのを支援するために提供される。定義は代表的なものであって限定するものではないと考えられるべきである。
ゲートウェイ − １つの着信プロトコルを異なる発信プロトコルに変換する装置。
ＳＩＰ − ＩＥＴＦ ＲＦＣ３２６１（インターネット・エンジニアリング・タスク・フォース − リクエスト・フォー・コメント３２６１）で定義されるセッション・イニシエーション・プロトコル。
プロキシサーバ − 連絡の連結点のように振舞うコンピュータ上で実行される装置又はアプリケーション。
ＶＳＤ − ボイス・サービス・ディレクタ。発呼側と相互作用し且つグリーティング及び認証を提供するコンピュータ上で実行されるアプリケーション。
ＵＡ − ＩＥＴＦ ＲＦＣ３２６１（インターネット・エンジニアリング・タスク・フォース − リクエスト・フォー・コメント３２６１）で定義されるユーザエージェント。ユーザエージェントは、ＳＩＰメッセージのための終点又は起点として動作する。
メディアサーバ − 様々な音声信号と他のデータ関連メッセージを混合するコンピュータ上で実行されるアプリケーション。
ブリッジ − メディアサーバ及び会議を管理するコンピュータ上で実行されるアプリケーション。
ＡＰＳ − アドバンスド・プロトコル・サーバ。アプリケーション間メッセージのためのメッセージルータ。
ＤＤＳ − ダイアログ・データベース・サーバ。会議予約を管理するアプリケーションサーバ。
ＡＣＳ − アクティブ・カンファレンス・サーバ。リアルタイムの会議状態を維持し、メディアサーバ、ブリッジを選択し、且つ利用可能な資源の負荷分散を提供するアプリケーション。

図１は、本発明の１実施形態によるＶＯＩＰ会議システム１０のブロック図である。以下の記載における任意の若しくは全てのアプリケーション及び／又はサーバは、システム容量を高め、且つ／又はシステム信頼性を改善し且つ／又はシステム応答時間を改善するために、単独であり、クラスタ化され又は負荷分散されることが出来る。システムは、ゲートウェイ（ＧＷ）１２を有する。これは、ＰＳＴＮ（公衆交換電話網）１８を介して電話機１４、１６に結合される。電話機１４、１６は、公衆交換電話ネットワークフォーマットを使用する。ゲートウェイ１２は、発呼のＰＳＴＮフォーマットを制御部分、通常はＳＩＰ（セッション・イニシエーション・プロトコル）又は制御部分、及びメディア部分、通常はＲＴＰ（リアル・タイム・プロトコル）に変換する。ゲートウェイは、例えばインターネット、ＬＡＮ又はＷＡＮ等のネットワークを介してプロキシ２０とつながる。プロキシ２０は、ＳＩＰ情報をＶＳＤ（ボイス・サービス・ディレクタ）２２に渡す。ＶＳＤ２２は、バック・トゥ・バック・ユーザエージェント（ＵＡ）２４、２６を有する。一方のユーザエージェント２４は、最初の発呼のための終点として動作しつつ、他方のユーザエージェント２６は、メディアサーバ資源２８と通信し且つそれを制御する。ＶＳＤはまた、何らかのバックオフィス通信プロトコル（ＢＯＣ）を使用して、Ｂ２ＢＵＡ（バック・トゥ・バック・ユーザエージェント）を介して又は別の機構及び／若しくはプロトコルを介して、バックオフィスサーバ３２とも通信する。バックオフィス３２は、バックオフィスメッセージをルーティングするアドバンスド・プロトコル・サーバ（ＡＰＳ）３４、会議情報を保持し且つユーザパスコードを認証するダイアログ・データベース・サーバ（ＤＤＳ）３６、及び活動中の会議についての情報を追跡記録するアクティブ・カンファレンス・サーバ（ＡＣＳ）３８を含む複数の制御サービスを有する。ＡＣＳ３８はまた、会議を様々なブリッジに割り当て、且つブリッジ間で負荷分散をする。一旦メディアサーバ２８が特定の会議のために指定されると、ＲＴＰメディア４０がゲートウェイ１２からメディアサーバ２８にルーティングされる。メディアサーバ２８は、音声（オーディオ、映像又はリアルタイムデータ）の混合を行う。各メディアサーバは、それぞれがさらに複数のポートを有する複数のブレードを有しても良いことに留意すべきである。結果として、所与のメディアサーバは、複数の会議のために音声混合を実行する場合がある。メディアサーバ２８は、ブリッジアプリケーション（会議ブリッジ、又は単に「ブリッジ」）４４に接続される。ブリッジ４４は、消音、記録並びに会議生成及び破棄のような機能を含む、活動中の会議のための制御機能を実行する。ユーザが電話機としてコンピュータ５０又はＶｏＩＰハードの電話機を使用している場合、それは次に発呼のＳＩＰ及びＲＴＰ部分を適切な場所にルーティングするプロキシ２０に直接接続することが出来る。電話機５０は、ＰＳＴＮではなく、ＶｏＩＰ接続を用いる。

ブリッジ４４は、ＳＩＰプロトコル３０を使用可能にされている。ＳＩＰＳｈｉｍ（制御層）５２は、ＳＩＰプロトコル及びＳＩＰ信号伝達イベントを直接処理するのではなく、一般的な高レベルコマンドを介してブリッジアプリケーション４４に発呼側及びメディアサーバ資源と相互作用させる、Ｂ２ＢＵＡの実装である。ＰＳＴＮユーザが発呼して会議に入る場合、発呼はゲートウェイ１２を介して、プロキシ２０を介して且つＶＳＤ２２にルーティングされる。ＶＳＤ２２は、グリーティングを再生し、且つパスコードをユーザに要求する。異なるパスコードが、特定の会議を選択することに加えて、所与の会議のための会議リーダーを区別するために使用されてもよい。こうしたパスコードは、ＶＳＤ２２の要求に応じてＤＤＳ３６により認証される。一般的なグリーティングを再生するのでは無く、ＤＮＩＳ、ＡＮＩ、パスコード、又はこれらの任意の組み合わせ（顧客定義コード）に基づいて、特定のグリーティングがＶＳＤにより選択されてもよい。次に、ＶＳＤは、ＡＣＳ３８にどのブリッジ４４に会議が割り当てられるかを問い合わせる。ＶＳＤ２２は、次に、適切な会議ブリッジに発呼側を転送し、ここで発呼側のメディアが会議に接続される。

バック・トゥ・バック・ユーザエージェント２４、２６は、システムに会議資源の障害を処理させる。電話機１４からの発呼は、第１のユーザエージェント２４で終端される。メディアサーバ２８が、機能を停止し又は差し迫った障害（障害モード）の兆候を示す場合、第２のユーザエージェント２６は、発呼を別のメディアサーバ資源に再ルーティングするよう命令される。バック・トゥ・バック・ユーザエージェント２４、２６はまた、システムに異なるプロトコルを処理させる。第１のユーザエージェント２４は、一般に、ＳＩＰプロトコル情報を受信するが、第２のユーザエージェント２６は、好都合であれば異なるプロトコルを使用することが出来る。これは、異なるプロトコルを使用する資源の間で、システム１０が相互運用することを可能にする。

ＳＩＰ／ＢＯＣチャネルに接続されるシステムは、会議制御システムの一部であるとみなすことが出来る一方で、ＲＴＰ又はメディアデータストリームに接続されるシステムは、会議システムのデータ部分の一部であるとみなすことが出来ることに留意するべきである。

図２は、本発明の１実施形態による分散ＶＯＩＰ会議システム６０のブロック図である。会議システム６０は、このシステムが分散され且つ図１のそれに似た複数のシステムのインスタンスを有する点を除いて、図１に示されたものに類似する。複数の会議センター６２、６４、６６、６８が国又は世界中に設置される。各会議センター６２、６４、６６、６８は、例えばインターネット等のネットワークに結合される。１つ以上のゲートウェイ７０ａ、ｂが、このネットワークに結合されることも可能であり、ＶｏＩＰ電話機又はＶｏＩＰベースの企業８０は、システムに連結することが出来る。各会議センターは、一般に、１つ以上のプロキシ７２ａ−ｄ、ＶＳＤ７４ａ−ｄ、ブリッジ７６ａ−ｄ及びメディアサーバ７８ａ−ｄを有するであろう。ソフトウェアベースの分散キャッシュ７９ａ−ｄ又は他の情報共有機構（例えばバックオフィス８０等）が、全てのＶＳＤ（ａ−ｄ）に利用可能にされ、且つ進行中の会議及び利用可能な資源についての共有情報を提供する。キャッシュ７９ａ−ｄは、ネットワーク８２を通じてこの情報を共有する。発呼は、ＬＡ６４のプロキシ７２ｂに着信し、且つニューヨーク６２のＶＳＤ７４ａにルーティングされてもよい。ＶＳＤ７４ａは、東京６８のメディアサーバ７８ｄ及びアトランタ６６のブリッジ７６ｃを選択してもよい。これは、プロキシ７２、ＶＳＤ７４及びブリッジ７６ｃにネットワーク６０上の全ての利用可能な資源を負荷分散させる。さらに、フェイルオーバ状態において、ニューヨークのＶＳＤ７４ａは、東京のブリッジ７６ｄが応答していないことを検出することが出来る。こうした状況により、ＶＳＤは、会議をアトランタのブリッジ７６ｃにリダイレクトすることが出来る。

図３は、本発明の１実施形態による分散ＶＯＩＰ会議システム９０を用いる分散会議のブロック図である。この図は、分散資源が共有され得る方法を示す。システム９０は、各々が多くの、恐らくは１０００以上の会議ポート資源を提供する３つのメディアサーバ９２、９４、９６を有する。公開会議において、参加者の人数は、最大人数までの任意の人数であり得る。会議１００が、メディアサーバ９２において開始すると仮定する。その会議に入って５分で、メディアサーバ９２において未使用のポートが１０個しか残されていないところに、新しく２０人がその会議に参加を希望する。こうした人々は、他のメディアサーバに割り当てられ得る。例えば、メディアサーバ９４において１１個のポート１０２を使用することが可能であり、メディアサーバ９６において１１個のポート１０４を使用することが可能である。ＲＴＰ又はメディアを他の２つのメディアサーバに結び付けるために、２つの追加の会議ポートが、元の会議及びメディアサーバ９２から要求されるであろう。他の２つのメディアサーバは、各々がその１０人の発呼側に加えて１つのメディア（ＲＴＰ）結合ポートを使用する。たとえ１つ以上のメディアサーバがブリッジの場所に対して遠隔の場所に設置されるとしても、単一のブリッジ９８が、ＳＩＰ１０６又は他のプロトコルを介して全３つのメディアサーバ９２、９４、９６を制御してもよい。会議ブリッジアプリケーションはまた、高レベルで結合されてもよく、ここで各ブリッジ９８、９９は、自身のメディアサーバ資源を制御し、ＳＩＰを含み得る何らかの形態のバックオフィス通信（ＢＯＣ）を介して結び付けられる。会議メディア（ＲＴＰ）の結合は、一般的に、親として動作する１つのブリッジから開始されつつ、他のメディアサーバにおいて及び恐らくは他のブリッジにおいても複数の従属の又は子の会議がインスタンス生成される。

この方法は、全ての子の会議が収束する共通の中心点を有することにより音声遅延を最小化する。しかし、この方法は親会議についてより多くの「結合」ポートを必要とする。それ故、最初の会議は、軽視されて子会議であっても良く、一方で第２の会議が親（又は義理の親）であるように割り当てられ、こうして全ての会議に対するメディアが中心点としての第２の会議に結び付けられる。第２の会議をインスタンス生成するとき、将来の追加の子会議を結び付けることを許容するために、十分なポートが残されてもよい。

会議を結び付けるこの方法は、多数の発呼が、例えばアジア及びヨーロッパ等の異なる地理的地域に、又は恐らくは例えばＶｏＩＰネットワーク及びＳｋｙｐｅのような商業ネットワークの組み合わせ等の異なる種類のネットワークに位置する場合にもあてはまるが、これらは互いに結び付けられる必要がある。全ての発呼を単一の場所に接続させるのではなく、各地域又はネットワークは、地域ブリッジに接続することが可能であり、その結果、ブリッジ及びメディアは互いに結合される。これは、同じ地域の発呼側に対する音声遅延を最小化し、且つメディア送信及び／又は変換費用をも低減し得る。各地域又はネットワークは、必要に応じて親及び子会議を使用することも可能であり、且つ異なる地域又はネットワークの２つの親（又は義理の親）会議のみが、そのメディアを互いに結び付けさせるであろう。

図４は、本発明の１実施形態による典型的なＰＳＴＮ会議参加者に関する発呼流れ図である。ゲートウェイ（ＧＷ）は、ＰＳＴＮからの着信発呼３００を受信する。ゲートウェイは、ＰＳＴＮ発呼を制御（ＳＩＰ）部分及びメディア（ＲＴＰ）部分に変換する。図４は、ゲートウェイに結合される発呼のＳＩＰ部分のみを示しており、メディアサーバに対するＳＩＰは図示されない。この図はメディアではなく制御メッセージ（ＳＩＰ）を詳細に説明するものであるので、ＲＴＰもまた図４には図示されない。プロキシは、着信発呼の制御部分をＶＳＤに転送する（３０２）。ＶＳＤは発呼に応答し（３０４）、次に発呼側に１つ以上のプロンプトを再生してパスコードの入力を要求する。発呼側が、ＤＴＭＦにより、不特定話者音声認識により、又は他の手段により必要な情報を入力した後、最初の発呼に対するメディアが保留にされる（３０６）。次に、ＶＳＤはパスコードが有効であるかどうか確認するためにバックオフィスシステムに問い合わせ、有効であれば、発呼側はバックオフィスシステムにより特定されたブリッジに転送される（３０８）。発呼側が電話を切ると（３１０）、ゲートウェイは、ブリッジにこのイベントを通知し（３１２）、それにより発呼は両端において終端される。

発呼の間、会議及び個々のユーザの状態は、発呼側によるＤＴＭＦを介して、又はバックオフィスを介してブリッジに結ばれる例えばウェブベースのインターフェース等の、直接的又は間接的にユーザにアクセスを許可する任意の他の機構から制御され得る。ブリッジは、続いて使用中のメディアサーバを制御するであろう。

ＶＳＤ及び会議ブリッジの両者に対して、発呼側が電話機に数字を押下するとき、数字の押下は、ＲＴＰ音声メディアストリーム内で帯域内トーンとして伝達され、又は選択的にゲートウェイによりＲＴＰ内で伝達される電話イベント信号伝達プロトコルに変換されてもよい。いずれの場合においても、数字の押下はメディアサーバにより検出され、且つＶＳＤ又はブリッジアプリケーションに報告される。上述の記載は、典型的な会議ユーザの基本的な発呼の流れである。

図５は、図４と同一の発呼の流れを示すが、ＰＳＴＮではなく生来のＶｏＩＰ発呼起源を用いるものである。主な相違は、ゲートウェイが必要とされないことである。

こうした流れの変形はまた、例えば発呼側が転送されたときにブリッジが応答に失敗する等の、発生する可能性があるエラー状態を処理するためにも必要とされる。これらは、明快性のために省略される。

以下は、図４及び５で示されるＳＩＰコマンドのリストである。

ＳＩＰ：ＩＥＴＰ標準ＲＦＣ３２６１により主に定義される、セッション・イニシエーション・プロトコル。
ＳＩＰは、例えばインターネット電話通信発呼等のマルチメディアセッションを確立し、修正し、及び終了させることが出来るアプリケーション層の制御プロトコルである。

ＩＮＶＩＴＥ：ＳＩＰベースの通信セッション（ＳＩＰ「ダイアログ」と呼ばれる）を設定（開始）するために用いられるＳＩＰ要求方法。

ＳＤＰ：セッション・デスクリプション・プロトコル。マルチメディアセッションを記述するためのテキストベースのメッセージフォーマットを定義するＩＥＴＦプロトコル。例えばバージョン番号、連絡情報、ブロードキャスト回数並びに音声及び映像符号化種類等のデータが、メッセージに含まれる。

ＡＣＫ：アクナレッジメント。ＳＩＰセッション又は「ダイアログ」の確立又は再交渉を終了させるためにＳＩＰ ＩＮＶＩＴＥトランザクション内で使用されるＳＩＰ要求。

１００、２００、２０２：ＳＩＰ要求の発信者に送り戻されるＳＩＰ応答符号。応答符号は、所与の要求に対する特定の結果を示す。

ＮＯＴＩＦＹ：一方のセッション又は「ダイアログ」の状態について別のＳＩＰセッションに情報を伝達するために使用されるＳＩＰ要求方法。

ＲＥＦＥＲ：ＳＩＰセッションの一端を異なるＳＩＰ宛先に転送するために使用されるＳＩＰ要求方法。

Ｓｉｐｆｒａｇ：ＳＩＰフラグメント。ＳＩＰ ＮＯＴＩＦＹメッセージの本体の一部として送られる、別のＳＩＰセッションからのＳＩＰメッセージ（例えば応答符号等）のフラグメント。

ＢＹＥ：既存のＳＩＰセッション又は「ダイアログ」を終了させるために使用されるＳＩＰ要求方法。

このようにして、容易に異なるプロトコルを処理し、メディア資源を負荷分散し且つフェイルオーバ状況に対処することが出来るＶＯＩＰ会議システムが説明された。

本明細書に記載された方法は、コンピュータにより実行されるときに本明細書に記載された方法を実行するであろうコンピュータ読取可能記憶装置に記憶されるコンピュータ可読命令として実行することが出来る。

本発明は、その特定の実施形態と共に説明されたが、多くの変更、修正、及び変形が上記記載に照らして当業者には明らかであることが明白である。従って、添付の特許請求の範囲において全てのこのような変更、修正及び変形を包含することが意図される。

Claims (15)

1. 第１及び第２のバック・トゥ・バック・ユーザエージェントを有するボイス・サービス・ディレクタを有する会議制御システムと、
   各々が複数のメディアデータストリームを混合し、且つ前記会議制御システムの前記第１のバック・トゥ・バック・ユーザエージェントにより制御される複数のメディアサーバと、
   前記第２のバック・トゥ・バック・ユーザエージェントで終端される複数の制御ストリーム及び前記複数のメディアデータストリームを生成する複数の会議参加者と
   を備える会議システムであって、
   前記複数の会議参加者が、少なくとも２つの異なる初期メディアデータフォーマットを有し、前記少なくとも２つの異なる初期メディアフォーマットが、公衆交換電話網のフォーマット及びボイス・オーバ・インターネット・プロトコルのフォーマットを含み、
   前記第１のバック・トゥ・バック・ユーザエージェントは、前記複数のメディアサーバの間で負荷分散を行い、制御データストリームがルーティングされているメディアサーバが障害モードにある場合、前記制御データストリームを異なるメディアサーバに再ルーティングする、ことを特徴とする会議システム。
2. 前記会議制御システムが、前記メディアサーバと通信する
   ことを特徴とする請求項１に記載の会議システム。
3. 前記会議制御システムが、前記公衆交換電話網に結合され、且つ公衆交換電話フォーマットを制御データフォーマット及びメディアデータフォーマットに変換するゲートウェイを有し、前記制御データフォーマットが、前記ボイス・サービス・ディレクタに結合される
   ことを特徴とする請求項２に記載の会議システム。
4. 複数のメディアサーバが存在する
   ことを特徴とする請求項３に記載の会議システム。
5. 前記会議制御システムが、前記複数のメディアサーバの間で負荷分散ルーチンを実行する
   ことを特徴とする請求項４に記載の会議システム。
6. ネットワークと、
   前記ネットワークに結合され、各々が前記会議制御システムを含む複数のＶｏＩＰ会議センターと
   を更に備える
   ことを特徴とする請求項１に記載の会議システム。
7. 前記ネットワークへの前記公衆交換電話網に結合するゲートウェイをさらに有する
   ことを特徴とする請求項６に記載の会議システム。
8. 前記複数のＶｏＩＰ会議センターの各々が、プロキシサーバを有する
   ことを特徴とする請求項６に記載の会議システム。
9. 前記複数のＶｏＩＰ会議センターの各々が、前記複数のメディアサーバを有する
   ことを特徴とする請求項６に記載の会議システム。
10. 前記複数のＶｏＩＰ会議センターの各々が、複数のブリッジを有する
    ことを特徴とする請求項６に記載の会議システム。
11. 前記複数のＶｏＩＰ会議センターの各々が、複数のボイス・サービス・ディレクタを有する
    ことを特徴とする請求項６に記載の会議システム。
12. 前記複数のボイス・サービス・ディレクタの各々が、前記第１及び第２のバック・トゥ・バック・ユーザエージェントを有する
    ことを特徴とする請求項１１に記載の会議システム。
13. 前記複数のブリッジの各々が、バック・トゥ・バック・ユーザエージェントを有する
    ことを特徴とする請求項１０に記載の会議システム。
14. 前記ネットワークに結合されるバックオフィスをさらに有する
    ことを特徴とする請求項６に記載の会議システム。
15. 前記複数のＶｏＩＰ会議センターの各々が、ソフトウェア分散キャッシュを有する
    ことを特徴とする請求項６に記載の会議システム。

Images