JP5700700B2

JP5700700B2 - 会議サーバ装置、およびプログラム

Info

Publication number: JP5700700B2
Application number: JP2012114076A
Authority: JP
Inventors: 大安藤; 篤中平; 隆文向内; 岡本　学; 学岡本; 佐藤　敦; 敦佐藤
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-05-18
Filing date: 2012-05-18
Publication date: 2015-04-15
Anticipated expiration: 2032-05-18
Also published as: JP2013243442A

Description

本発明は、ネットワークを介して複数の会議参加端末に会議サービスを提供する会議サーバ装置、およびプログラムに関する。

現在、各種の通信事業者により、一般コンシューマあるいは企業ユーザを対象とした様々な通信サービスが提供されている。これら通信サービスの一つとして、複数の拠点を接続して、多地点間の音声会議やテレビ会議を提供する多地点会議サービスが提供されている。この種のサービスを提供するシステムは、通常、ユーザ側が利用しやすいよう、例えば図８に示すように、通信事業者などのサービス提供事業者側で多地点会議を行うシステムを構築し、ユーザ側はクライアント端末となるパソコンや電話機等のみを用意すればよいような構成が一般的である（例えば、非特許文献１参照）。

また、事業者側で用意される多地点会議サーバは、１つのサーバ内で、呼制御、会議室管理、会議参加者と送受信する音声や映像等のメディアデータ処理を一括して行うものが一般的である（例えば、非特許文献２参照）。

高品質なPC多地点接続を実現するTV会議技術、［online］、インターネット＜URL: http://www.ntt.co.jp/journal/0507/files/jn200507013.html＞ビデオ会議ASPサービス「ビデオ会議＠PTOP」、［online］、インターネット＜URL: http://www.om-nix.com/solution/video/vc-ptop.html＞

しかし、上記のような通信事業者による多地点会議サービスにおいては、設備が事業者側にあることで、ユーザの利用しやすさという点では利点がある一方、事業者側としては、多くのユーザを収容するために設備が大規模になり、初期投資が膨大になってしまうという問題点がある。特に、システム設計においては、想定される最大利用時にも耐えうる設計をすることが多く、そのため大規模なハードウェアを用意することになるが、多地点会議サーバマシン用に用意されたハードウェアのリソースは、一般的に複数の会議室が使用または予約されることを想定している。このため、会議の開催率や予約率が低く、会議室が空いていて、その分、当該サーバマシンのリソースが空いていた状況であっても、それを他の目的のために使用する（当該サーバマシンで、多地点会議以外のサーバアプリケーションを動作させること）といった設備の効率的な運用は難しいという問題点がある。

また、上記のような多地点会議サービスにおいては、１つの会議で異常が発生すると、当該会議だけでなく、サーバ全体が影響を受けてしまうという問題点がある。

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、不要なリソースの確保を回避するとともに、ある会議室で異常が発生した場合に当該異常を他の会議室に影響させない会議サーバ装置、およびプログラムを提供することにある。

上記目的を達成するため、本発明は、会議サーバ装置であって、端末から送信された会議開催を要求する呼を着信し、当該呼を制御するサーバ呼制御手段と、前記会議開催の要求に応じて、リソースを確保し、会議プロセスを起動するプロセス制御手段と、を備え、前記サーバ呼制御手段は、前記会議プロセスの起動後に、前記端末からの呼を前記会議プロセスに引継ぎ、前記会議プロセスと前記端末との間で呼が接続されると、前記端末との呼を切断し、前記会議プロセスは、前記端末とメディア情報を送受信するメディア処理手段と、前記サーバ呼制御手段から引継いだ前記端末との呼を制御するプロセス呼制御手段と、を備える。

本発明は、前記会議サーバ装置として、コンピュータを機能させるためのプログラムである。

本発明によれば、不要なリソースの確保を回避するとともに、ある会議室で異常が発生した場合に当該異常を他の会議室に影響させない会議サーバ装置、およびプログラムを提供することができる。

本発明の第１の実施形態に係る多地点会議サーバの構成を示す図である。会議機能モジュールプログラムの構成を示す図である。第１の実施形態の多地点会議サーバの動作を説明するための説明図である。第２の実施形態の多地点会議サーバの構成および動作を説明する説明図である。第３の実施形態の多地点会議サーバの構成および動作を説明する説明図である。比較例の多地点会議サーバの構成を示す図である。比較例の多地点会議サーバのリソースの状態を示す図である。会議システムの構成例を示す図である。

以下、本発明の実施の形態について、図面を参照して説明する。

＜第１の実施形態＞
図１に、第１の実施形態の多地点会議サーバ（会議サーバ装置）１の構成例を示す。多地点会議サーバ１は、一般公衆電話網、インターネット網、専用線網等のネットワーク（ＩＰパケット網）に接続され、当該ネットワークに接続された会議参加端末（不図示）に、多地点会議サービスを提供するサーバである。本実施形態の多地点会議サーバ１は、当該多地点会議サーバ１を制御する部分と、会議機能を提供する会議機能モジュールプログラムとに機能を分離する。

多地点会議サーバ１の制御部分として、多地点会議サーバ１は、サーバ制御部１１と、サーバ呼制御部１２（サーバ呼制御手段）と、リソース管理部１３と、会議機能モジュール制御部１４（プロセス制御手段）とを備える。

会議機能を提供するモジュールプログラムとして、多地点会議サーバ１は、会議機能モジュールプログラムを備える。記憶装置２１（例：ハードディスク等）には、映像符号化方式が異なる、複数の会議機能モジュールプログラムが格納されている。記憶装置２１は、多地点会議サーバ１内に備えるものであっても、多地点会議サーバ１に接続される外部記憶装置であってもよい。

サーバ制御部１１は、サーバ呼制御部１２、リソース管理部１３および会議機能モジュール制御部１４を管理および制御する。サーバ呼制御部１２は、会議参加端末から送信された会議開催を要求する呼を着信し、当該呼を制御する。リソース管理部１３は、当該多地点会議サーバ１のハードウェア内の空きリソースを管理する。会議機能モジュール制御部１４は、サーバ制御部１１の制御により、会議参加端末からの会議開催の要求があった時点で、当該要求で指定された映像符号化方式の会議機能モジュールを起動するためのリソースを確保し、当該会議機能モジュールを選択して、会議機能プロセスを生成する。

会議機能モジュールの起動後、サーバ呼制御部１２は、会議参加端末からの呼を、生成された会議機能プロセス内のプロセス呼制御部に引継ぎ、呼制御処理を移行する。これにより、会議開催に係る処理を全て会議機能プロセスで実行させ、会議終了後は会議機能プロセスを終了させることで、当該会議機能プロセスが使用していたリソースを解放する。

記憶装置２１に記憶される複数の会議機能モジュールプログラムは、所定の符号化方式に準拠した会議機能モジュールであって、図１に示す例では、符号化方式Ａ用の会議機能モジュールプログラムと、符号化方式Ｂ用の会議機能モジュールプログラムとが記憶されているものとする。なお、符号化方式は、映像だけでなく音声も含まれるものとする。

図２は、会議機能モジュールプログラムの一例を示すものである。本実施形態の各会議機能モジュールプログラムは、ある映像符号化方式に準拠した、会議サービスを提供するモジュールプログラムである。図示する会議機能モジュールプログラムは、メディア処理機能部（メディア処理手段）２０と、呼制御部（プロセス呼制御手段）２９と、モジュール制御部３０とを有する。

メディア処理機能部２０は、会議参加端末とメディア情報（音声、映像など）を送受信するものであって、例えば、映像ストリーム送受信部２１と、複数の映像復号化部２２と、映像合成部２３と、複数の映像符号化部２４と、音声ストリーム送受信部２５と、複数の音声復号化部２６と、音声合成部２７と、複数の音声符号化部２８とを備える。メディア処理機能部２０は、会議参加端末から入力・送信された映像および音声を当該符号化方式にて復号化し、それぞれ合成した後、再度同じ符号化方式にて符号化して、各会議参加端末に送信する。

呼制御部２９、サーバ呼制御部１２から引継いだ会議参加端末との呼を制御する。モジュール制御部３０は、メディア処理機能部２０および呼制御部２９を制御するとともに、当該会議機能モジュールプログラム以外の外部（サーバ呼制御部１２、会議機能モジュール制御部１４など）との情報の送受信を行う。このような会議機能モジュールプログラムにより、モジュール単体で、対応する符号化方式による多地点会議のための通信を行うことが可能となる。

なお、図１では、会議機能モジュールプログラムを実行することで起動される会議機能プロセスには、説明を簡単にするために、メディア処理機能部２０および呼制御部２９のみを示している。

上記説明した多地点会議サーバ１には、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた多地点会議サーバ１用のプログラムを実行することにより、多地点会議サーバ１の各機能が実現される。また、多地点会議サーバ１用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

次に、本実施形態の動作について説明する。

図３は、本実施形態における多地点会議サーバ１の動作例を説明するための説明図である。図示する例では、記憶装置には、符号化方式がMPEG-4方式の会議機能モジュールプログラムと、符号化方式がH.264方式の会議機能モジュールプログラムとが記憶され、会議参加端末＜A-1＞および会議参加端末＜A-2＞の符号化方式はMPEG-4方式であり、会議参加端末＜B-1＞の符号化方式はH.264方式であるものとする。

Ｓ１：まず、システム起動時に、リソース管理部が、ＯＳにアクセスし、現在、多地点会議サーバで動作しているプロセスと、その使用リソースを取得し、会議機能モジュールが利用可能な空きリソース量を把握しておくものとする。

Ｓ２：会議の開催を希望する会議参加端末＜A-1＞は、多地点会議サーバの電話番号に対して発呼する。多地点会議サーバのサーバ呼制御部は、会議参加端末＜A-1＞の呼を着信する。この時、サーバ呼制御部は、会議参加端末＜A-1＞からの発呼メッセージ内に記述された端末能力より、該会議参加端末＜A-1＞が使用を希望しているメディアが音声＋映像であること、および映像の符号化方式としてMPEG-4方式を希望していることを把握する。次に、サーバ制御部１１は、サーバ呼制御部１２を介して、会議参加端末＜A-1＞に対して、新規会議か、既存会議への参加かを入力するよう会議参加端末＜A-1＞に要求する。会議参加端末＜A-1＞が、新規会議の参加（会議開催）を要求した場合、Ｓ３に進む。

Ｓ３：新規会議への参加要求を受信した多地点会議サーバのサーバ制御部は、リソース管理部に、現在の空きリソース状況で、新規の会議機能モジュールを起動可能かを問合せる。リソース管理部が、新規の会議機能モジュールを起動可能と判断した場合、Ｓ４に進む。

Ｓ４：サーバ制御部が、会議機能モジュール制御部に、会議参加端末＜A-1＞が使用を希望する符号化方式（＝MPEG-4）の会議機能プロセス＜A＞を、新規に起動する指示を出力する。

Ｓ５：会議機能モジュール制御部が、記憶装置から会議機能モジュールプログラム（MPEG-4）を読み出し、会議機能プロセス＜A＞を起動する。この時、会議機能モジュール制御部は、会議機能プロセス＜A＞に、内線番号<2>を付与して、生成・起動する。また、この時、サーバ呼制御部を介して、該会議機能プロセス＜A＞の内線番号<2>が、会議参加端末＜A-1＞に通知される。なお、多地点会議サーバのサーバ呼制御部には、あらかじめ内線番号<1>が付与されているものとする。

Ｓ６：会議機能プロセス＜A＞の起動後、多地点会議サーバのサーバ制御部は、サーバ呼制御部（＝内線番号<1>）に対して、会議参加端末＜A-1＞との呼制御情報を、内線番号が<2>である会議機能プロセス＜A＞内の呼制御部＜A＞に転送するよう指示する。

Ｓ７：これにより、サーバ呼制御部（＝内線番号<1>）は、会議参加端末＜A-1＞との呼制御情報（発呼元のアドレス、使用ポート番号等）を、会議機能プロセス＜A＞内の呼制御部＜A＞（＝内線番号<2>）に転送し、会議参加端末からの呼を会議機能プロセス＜A＞に引継ぐ。

Ｓ８：その結果、会議機能プロセス＜A＞内の呼制御部＜A＞が、会議参加端末＜A-1＞と、直接通信を開始し、会議で使用するメディア能力のネゴシエーションを行うが、双方とも、MPEG-4方式に対応しているため、MPEG-4方式による映像通信が可能となる。また、呼制御部＜A＞と会議参加端末＜A-1＞の通信が開始された時点で、会議参加端末＜A-1＞とサーバ呼制御部との通信（呼）は切断される。その結果、会議参加端末＜A-1＞と会議機能プロセス＜A＞との間で、通信が確立し、メディアデータの送受信が行われる。

Ｓ９：次に、新たな会議参加端末＜A-2＞が、多地点会議サーバの電話番号に発呼した後、既存会議への参加を選択し、会議機能プロセス＜A＞の内線番号<2>を入力する。これにより、多地点会議サーバのサーバ制御部は、サーバ呼制御部に対し、会議参加端末＜A-2＞との呼制御情報を、内線番号が<2>である会議機能プロセス＜A＞内の呼制御部＜A＞に転送するよう指示し、会議参加端末＜A-2＞と会議機能プロセス＜A＞間での通信が確立することで、会議参加端末＜A-2＞は、会議参加端末＜A-1＞と同じ会議へ参加することになる。

Ｓ１０：また、新たな会議参加端末＜B-1＞が、会議参加端末＜A-1＞とは、別の会議を、新規に要求した場合には、会議参加端末＜A-1＞の場合のＳ２〜Ｓ４と同様の手順を行う。

Ｓ１１：そして、会議参加端末＜B-1＞が使用を希望する符号化方式がH.264方式であることを取得し、会議機能モジュールプログラム（H.264）が記憶装置から読み出され、符号化方式がH.264方式の会議機能プロセス＜B＞及び呼制御部＜B＞（＝内線番号<3>）が、生成、起動される。

なお、各会議機能プロセスにおいて、当該会議機能プロセスに参加している全ての会議参加端末との通信が切断された場合、当該会議機能プロセスは、自動的に終了し、当該会議機能プロセスが使用していたリソースが解放される。例えば、会議参加端末＜A-1＞および会議参加端末＜A-2＞の２台とも、会議機能プロセス＜A＞との通信を切断した場合、会議機能プロセス＜A＞は、自動的に終了し、当該会議機能プロセス＜A＞が使用していたリソースが解放される。

その結果、多地点会議サーバ用のハードウェアとして、一定程度の空きリソースが残された状態を保つことが可能となり、当該ハードウェア内で、多地点会議サーバ以外のサーバアプリケーションを動作させることが可能となる。

また、会議機能プロセス＜A＞は、多地点会議サーバを制御する部分とは別の、会議参加端末と直接通信が可能なプロセスであり、仮に当該会議機能プロセス＜A＞に異常があったとしても、多地点会議サーバ全体および会議機能プロセス＜B＞は会議を継続することが可能である。

また、会議機能プロセス＜A＞および会議機能プロセス＜B＞は、それぞれ単一の符号化方式に対応した会議機能プロセスであり、それぞれのプログラム規模は、両方の符号化方式を実装する場合に比べて、小型化することが可能となる。

＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。

図４は、第２の実施形態における多地点会議サーバ１Ａの構成例及び動作例を示す図である。第２の実施形態は、第１の実施形態（図１、図３参照）における多地点会議サーバ１の構成に、ＶＭ（仮想マシン）制御部１５を追加したものであり、その他については、第１の実施形態の多地点会議サーバ１と同様である。すなわち、第２の実施形態の多地点会議サーバ１Ａは、会議機能モジュールプログラムを起動時に、ＶＭ（仮想マシン）を生成し、その上で、当該会議機能モジュールプログラムを起動する。

以下に、図４を参照して、本実施形態の動作について説明する。

Ｓ３１：まず、システム起動時に、リソース管理部が、ＯＳにアクセスし、現在、多地点会議サーバで動作しているプロセスと、その使用リソースを取得し、会議機能モジュールが利用可能な空きリソース量を把握しておくものとする。

Ｓ３２：会議の開催を希望する会議参加端末＜A-1＞は、多地点会議サーバの電話番号に対して発呼する。多地点会議サーバのサーバ呼制御部は、会議参加端末＜A-1＞の呼を着信する。この時、サーバ呼制御部は、会議参加端末＜A-1＞からの発呼メッセージ内に記述された端末能力より、会議参加端末＜A-1＞が使用を希望しているメディアが音声＋映像であること、および映像の符号化方式としてMPEG-4方式を希望していることを把握する。次に、サーバ制御部１１は、サーバ呼制御部１２を介して、会議参加端末＜A-1＞に対して、新規会議か、既存会議への参加かを入力するよう会議参加端末＜A-1＞に要求する。会議参加端末＜A-1＞が、新規の会議参加（会議開催）を要求した場合、Ｓ３３に進む。

Ｓ３３：新規会議への参加要求を受信した多地点会議サーバのサーバ制御部は、リソース管理部に、現在の空きリソース状況で、新規の会議機能モジュールを起動可能かを問合せる。リソース管理部が、新規の会議機能モジュールを起動可能と判断した場合、Ｓ３４に進む。

Ｓ３４：サーバ制御部が、会議機能モジュール制御部に、会議参加端末＜A-1＞が使用を希望する符号化方式（＝MPEG-4）の会議機能プロセス＜A＞を、新規に起動する指示を出力する。

Ｓ３５：これにより、会議機能モジュール制御部が、VM制御部に対して、新規のVM＜A＞を作成するよう指示する。

Ｓ３６：これにより、VM制御部が、新規のVM＜A＞を生成し、その上で、ゲストOSを起動した後、VM生成の終了を、会議機能モジュール制御部へ通知する。

Ｓ３７：会議機能モジュール制御部が、記憶装置から会議機能モジュールプログラム（MPEG-4）を読み出し、会議機能プロセス＜A＞を起動する。この時、会議機能モジュール制御部は、会議機能プロセス＜A＞に、内線番号<2>を付与して、生成・起動する。また、この時、サーバ呼制御部を介して、該会議機能プロセス＜A＞の内線番号<2>が、会議参加端末＜A-1＞に通知される。なお、多地点会議サーバのサーバ呼制御部には、あらかじめ内線番号<1>が付与されているものとする。

Ｓ３８：会議機能プロセス＜A＞の起動後、多地点会議サーバのサーバ制御部は、サーバ呼制御部（＝内線番号<1>）に対して、会議参加端末＜A-1＞との呼制御情報を、内線番号が<2>である会議機能プロセス＜A＞内の呼制御部＜A＞に転送するよう指示する。

Ｓ３９：これにより、サーバ呼制御部（＝内線番号<1>）は、会議参加端末＜A-1＞との呼制御情報（発呼元のアドレス、使用ポート番号等）を、会議機能プロセス＜A＞内の呼制御部＜A＞（＝内線番号<2>）に転送し、会議参加端末からの呼を会議機能プロセス＜A＞に引継ぐ。

Ｓ４０：その結果、会議機能プロセス＜A＞内の呼制御部＜A＞が、会議参加端末＜A-1＞と、直接通信を開始し、会議で使用するメディア能力のネゴシエーションを行うが、双方とも、MPEG-4方式に対応しているため、MPEG-4方式による映像通信が可能となる。また、呼制御部＜A＞と会議参加端末＜A-1＞の通信が開始された時点で、会議参加端末＜A-1＞とサーバ呼制御部との通信（呼）は切断される。その結果、会議参加端末＜A-1＞と会議機能プロセス＜A＞との間で、通信が確立し、メディアデータの送受信が行われる。

Ｓ４１：次に、新たな会議参加端末＜A-2＞が、多地点会議サーバの電話番号に発呼した後、既存会議への参加を選択し、会議機能プロセス＜A＞の内線番号<2>を入力する。これにより、多地点会議サーバのサーバ制御部は、サーバ呼制御部に対し、会議参加端末＜A-2＞との呼制御情報を、内線番号が<2>である会議機能プロセス＜A＞内の呼制御部＜A＞に転送するよう指示し、会議参加端末＜A-2＞と会議機能プロセス＜A＞間での通信が確立することで、会議参加端末＜A-2＞は、会議参加端末＜A-1＞と同じ会議へ参加することになる。

Ｓ４２：また、新たな会議参加端末＜B-1＞が、会議参加端末＜A-1＞とは、別の会議を、新規に要求した場合には、会議参加端末＜A-1＞の場合のＳ３２〜Ｓ３４と同様の手順を行う。

Ｓ４３：そして、VM制御部は、会議参加端末＜B-1＞が使用を希望する符号化方式がH.264方式であることを取得し、Ｓ３６と同様に、新たなVM＜B＞を生成し、ゲストOSを起動した後、VM生成の終了を、会議機能モジュール制御部へ通知する。

Ｓ４４：そして、会議機能モジュール制御部が、会議機能モジュールプログラム（H.264）を記憶装置２１から読み出し、符号化方式がH.264方式の会議機能プロセス＜B＞及び呼制御部＜B＞（＝内線番号<3>）が、生成、起動される。

第２の実施形態においても、第１の実施形態と同様の効果を得ることができる。また、第２の実施形態では、会議機能プロセス＜A＞と会議機能プロセス＜B＞をVM上で動作させることにより、会議機能プロセス＜A＞において、ＯＳレベルの異常が発生した場合であっても、影響を受ける会議を会議機能プロセス＜A＞に限定することが可能となり、第１の実施形態よりも、システムの安定性をより高めることが可能となる。

＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。

図５は、第３の実施形態における多地点会議サーバ１Ｂ、１Ｃの構成例および動作例を示す図である。第３の実施形態は、第１の実施形態（図１、図３参照）における多地点会議サーバ１の構成から、リソース管理部を別サーバマシンに切り出したものである。すなわち、図５に示す多地点会議サーバ１Ｂ、１Ｃ内には、リソース管理部は存在しない。その代わり、別途、リソース管理サーバ３０を設置し、その中に、システム内に存在する全ての多地点会議サーバのリソース情報を管理するリソース管理部３１が存在している。

ある多地点会議サーバが、自多地点会議サーバ内で会議を開催する場合、リソース管理サーバ３０に、会議機能モジュールの起動が可能かを問合せ、リソース管理サーバ３０が、問合せ元の多地点会議サーバに、会議機能モジュールを起動可能なリソースがある場合には、起動を許可し、会議機能モジュールを起動可能なリソースが無い場合には、起動可能なリソースを持つ、代替の多地点会議サーバの情報を通知する。問合せ元の多地点会議サーバは、会議機能モジュールの起動を許可された場合には、自サーバ内で、会議機能モジュールを起動し、不許可で代替の多地点会議サーバの情報を受信した場合には、代替の多地点会議サーバに、着信した会議参加端末との呼制御情報を転送し、代替の多地点会議サーバにて、会議機能モジュールの起動が行われる。

また、本実施形態では、システム内に、複数の多地点会議サーバ１Ｂ、１Ｃを備えるものとする。図５に示す例では、多地点会議サーバ＜１＞１Ｂと多地点会議サーバ＜２＞１Ｃとを備え、両者は、同じ構成であるものとする。なお、ここでは、多地点会議サーバ＜１＞１Ｂでは、会議機能プロセス１０1以外に、別のサーバプロセス１０２が動作しているものとする。その他については、第１の実施形態の多地点会議サーバ１と同様である。

以下に、図５を参照して、本実施形態の動作について説明する。

Ｓ５１：まず、システム起動時に、多地点会議サーバ＜１＞１０Ｂのシステム制御部は、ＯＳにアクセスし、現在、自サーバマシンで動作しているプロセスと、その使用リソースを取得し、会議機能モジュールが利用可能な空きリソース量を把握しておくものとする。同様に、多地点会議サーバ＜２＞１０Ｃも、会議機能モジュールが利用可能な空きリソース量を把握しておく。

Ｓ５２：そして、多地点会議サーバ＜１＞１０Ｂおよび多地点会議サーバ＜２＞１０Ｃのシステム制御部は、それぞれ把握した空きリソース量を、リソース管理サーバ３０へ通知する。リソース管理サーバ３０内のリソース管理部３１は、システム内の全多地点会議サーバが会議機能モジュールに使用可能な空きリソース量を把握しておくものとする。

Ｓ５３：会議の開催を希望する会議参加端末＜A-1＞は、多地点会議サーバ＜１＞１Ｂの電話番号に対して発呼する。多地点会議サーバ＜１＞１Ｂのサーバ呼制御部は、会議参加端末＜A-1＞の呼を着信する。この時、多地点会議サーバ＜１＞１Ｂのサーバ呼制御部は、該会議参加端末＜A-1＞からの発呼メッセージ内に記述された端末能力より、会議参加端末＜A-1＞が使用を希望しているメディアが音声＋映像であること、および映像の符号化方式としてMPEG-4方式を希望していることを把握する。次に、多地点会議サーバ＜１＞１Ｂは、会議参加端末＜A-1＞に対して、新規会議か、既存会議への参加かを入力するよう会議参加端末＜A-1＞に要求する。会議参加端末＜A-1＞が、新規会議の参加（会議開催）を要求した場合、Ｓ５４に進む。

Ｓ５４：新規会議への参加要求を受信した多地点会議サーバ＜１＞１Ｂのサーバ制御部は、リソース管理サーバ３０に、現在の空きリソース状況で、多地点会議サーバ＜１＞１Ｂが、新規の会議機能モジュールを起動可能かを問合せる。リソース管理サーバ３０のリソース管理部３１が、新規の会議機能モジュールを起動可能と判断した場合、Ｓ５５に進む。

Ｓ５５：多地点会議サーバ＜１＞１Ｂのサーバ制御部が、会議機能モジュール制御部に、会議参加端末＜A-1＞が使用を希望する符号化方式（＝MPEG-4）の会議機能プロセス＜A＞を、新規に起動する指示を出力する。

Ｓ５６：多地点会議サーバ＜１＞１Ｂの会議機能モジュール制御部が、記憶装置から、会議機能モジュールプログラム（MPEG-4）を読み出し、会議機能プロセス＜A＞を起動する。この時、会議機能モジュール制御部は、会議機能プロセス＜A＞に、内線番号<2>を付与して、生成・起動する。また、この時、サーバ呼制御部を介して、会議機能プロセス＜A＞の内線番号<2>が、会議参加端末＜A-1＞に通知される。なお、多地点会議サーバ＜１＞１Ｂのサーバ呼制御部には、あらかじめ内線番号<1>が付与されているものとする。

Ｓ５７：会議機能プロセス＜A＞の起動後、多地点会議サーバ＜１＞１Ｂのサーバ制御部は、サーバ呼制御部（＝内線番号<1>）に対して、会議参加端末＜A-1＞との呼制御情報を、内線番号が<2>である会議機能プロセス＜A＞内の呼制御部＜A＞に転送するよう指示する。

Ｓ５８：これにより、多地点会議サーバ＜１＞１Ｂのサーバ呼制御部（＝内線番号<1>）は、会議参加端末＜A-1＞との呼制御情報（発呼元のアドレス、使用ポート番号等）を、会議機能プロセス＜A＞内の呼制御部＜A＞（＝内線番号<2>）に転送し、会議参加端末からの呼を会議機能プロセス＜A＞に引継ぐ。

Ｓ５９：その結果、会議機能プロセス＜A＞内の呼制御部＜A＞が、会議参加端末＜A-1＞と、直接通信を開始し、会議で使用するメディア能力のネゴシエーションを行うが、双方とも、MPEG-4方式に対応しているため、MPEG-4方式による映像通信が可能となる。また、多地点会議サーバ＜１＞１Ｂ内の呼制御部＜A＞と会議参加端末＜A-1＞の通信が開始された時点で、会議参加端末＜A-1＞と多地点会議サーバ＜１＞１Ｂのサーバ呼制御部との通信（呼）は切断される。その結果、会議参加端末＜A-1＞と会議機能プロセス＜A＞との間で、通信が確立し、メディアデータの送受信が行われる。

Ｓ６０：次に、新たな会議参加端末＜A-2＞が、多地点会議サーバ＜１＞１Ｂの電話番号に発呼した後、既存会議への参加を選択し、会議機能プロセス＜A＞の内線番号<2>を入力する。これにより、多地点会議サーバ＜１＞１Ｂのサーバ制御部は、サーバ呼制御部に対し、会議参加端末＜A-2＞との呼制御情報を、内線番号が<2>である会議機能プロセス＜A＞内の呼制御部＜A＞に転送するよう指示し、会議参加端末＜A-2＞と会議機能プロセス＜A＞間での通信が確立することで、会議参加端末＜A-2＞は、会議参加端末＜A-1＞と同じ会議へ参加することになる。

Ｓ６１：また、新たな会議参加端末＜B-1＞が、会議参加端末＜A-1＞とは、別の会議を、新規に要求する場合には、会議参加端末＜B-1＞は、まず多地点会議サーバ＜１＞１Ｂの電話番号に対して発呼する。

Ｓ６２：Ｓ６１の発呼を着信した多地点会議サーバ＜１＞１Ｂのサーバ制御部は、リソース管理サーバ３０に、現在の空きリソース状況で、多地点会議サーバ＜１＞１Ｂが、新規の会議機能モジュールを起動可能か否かを問合せる。ここでは、多地点会議サーバ＜１＞１Ｂでは、別のサーバプロセス１０２も動作しているため、新規の会議機能モジュールを起動することは不可能であって、多地点会議サーバ＜２＞１Ｃであれば、現在、新規の会議機能モジュールを起動可能であるものとする。リソース管理サーバ３０のリソース管理部３１は、多地点会議サーバ＜１＞１Ｂでは、新規の会議機能モジュールの起動は不可能であるとの通知と共に、多地点会議サーバ＜２＞１Ｃでは、新規の会議機能モジュールを起動可能であるとの通知、および多地点会議サーバ＜２＞１Ｃの電話番号を通知する。

Ｓ６３：多地点会議サーバ＜１＞１Ｂは、自サーバ内で新規の会議機能モジュールを起動不可であることと、新規の会議機能モジュールを起動可能な多地点会議サーバ＜２＞１Ｃの電話番号とを受信し、会議参加端末＜B-1＞との呼制御情報を、多地点会議サーバ＜２＞１Ｃへ転送する。

Ｓ６４：多地点会議サーバ＜２＞１Ｃでは、会議参加端末＜B-1＞の呼制御情報を受信すると、会議参加端末＜B-1＞が使用を希望する符号化方式がH.264方式であることを把握し、自サーバ内の記憶装置から、会議機能モジュールプログラム（H.264）を読み出し、符号化方式がH.264方式の会議機能プロセス＜B＞及び呼制御部＜B＞（＝内線番号<3>）を、生成、起動する。

Ｓ６５：その結果、多地点会議サーバ＜２＞１Ｃ内の会議機能プロセス＜B＞の呼制御部＜B＞（不図示）が、会議参加端末＜B-1＞と、直接通信を開始し、会議で使用するメディア能力のネゴシエーションを行うが、双方とも、H.264方式に対応しているため、H.264方式による映像通信が可能となる。また、多地点会議サーバ＜２＞１Ｃ内の呼制御部＜B＞と会議参加端末＜B-1＞の通信が開始された時点で、会議参加端末＜B-1＞と多地点会議サーバ＜１＞１Ｂのサーバ呼制御部との通信は切断される。その結果、会議参加端末＜B-1＞と会議機能プロセス＜B＞との間で、通信が確立し、メディアデータの送受信が行われる。

第３の実施形態においても、第１の実施形態と同様の効果を得ることができる。また、第３の実施形態では、システム内のある多地点会議サーバのリソースが不足した場合に、別の多地点会議サーバで会議機能プロセスを実行することが可能となり、その分システムの拡張性を高めることができる。

＜比較例＞
図６は、第１から第３の本実施形態の比較例である多地点会議サーバの構成図である。図６の比較例では、会議管理部が、図７に示すように、使用が想定される所定の数の会議室のリソースをあらかじめ確保しておき、１つの呼制御部が各会議室を使用する端末との呼制御を行う。このため、比較例では、会議の開催率や予約率が低く、会議室が空いていて、その分、当該サーバマシンのリソースが空いていた状況であっても、それを他の目的のために使用することができない。また、全ての会議室を１つの呼制御部が制御するため、ある会議室で異常が発生すると、当該会議室だけでなく、他の会議室にも影響を及ぼす可能性がある。

これに対し、以上説明した第１から第３の本実施形態の多地点会議サーバでは、多地点会議サーバを制御する部分と、会議機能を提供するモジュールプログラムに機能を分離し、会議の開催要求があった時点で、リソースを確保して、会議機能プロセスを起動する。これにより、多地点会議サーバ用のハードウェアにおいて、不要なリソースの確保を回避し、全てのリソースが会議機能に占有されることなく、当該ハードウェアにおいて、会議機能以外のサーバアプリケーションを動作させることが可能となる。

また、会議機能プロセスの生成時に、その時点の空きリソース確認しているので、会議の開催可能数を増やしたい場合には、ソフトウェア的な設定等は変更しなくても、単純に、当該多地点会議サーバ用のハードウェアリソースのみを拡充すればよく、容易にシステムの拡張性を高めることができる。

また、本実施形態では、サーバ呼制御部の他に、会議機能プロセスが呼制御部を有し、サーバ呼制御部が取得した会議参加端末との呼制御情報を、全て起動した会議機能プロセスの呼制御部に引き継ぐことにより、起動した会議機能プロセスが、単独で会議参加端末との通信を行うことを可能とする。これにより、会議終了後、当該会議機能プロセスを終了するだけで、当該会議機能プロセスが使用していたリソースを解放可能となり、特定の会議機能プロセスにおいて異常が発生し、当該会議機能プロセスが異常終了した場合であっても、多地点会議サーバ全体へ、その異常が波及しない効果を得る。その結果、システムトラブルの影響を最小限に抑えることが可能となり、メンテナンスや運用性を向上させることが可能となる。

また、本実施形態では、会議機能モジュールプログラムとして、符号化方式が異なる複数の会議機能モジュールプログラムを用意し、会議参加要求を行った会議参加端末の能力に合った符号化方式の会議機能プロセスを起動することにより、会議機能モジュール自身を肥大化させることなく、多様な符号化方式の会議参加端末へ対応することを可能とする。具体的には、現在のテレビ電話端末が具備している符号化方式には、様々なものがあり、例えば、NTT東日本のテレビ電話機「フレッツフォン（http://flets.com/fletsphone/）」は、MPEG-4という方式を採用している。これに対して、近年標準化されたH.264という方式を採用したテレビ電話も増えてきている（例：リードテック社の「AMOR 8A10（http://www.leadtek.co.jp/videophone/amor_8a10_1.html）」）。しかし、MPEG-4は、ISO/IECが標準化団体であるのに対し、H.264はITU-Tが標準化団体であり、両者の方式には、上位互換のような関係性はない。そのため、MPEG-4方式のテレビ電話と、H.264方式のテレビ電話の両方対応した会議機能モジュールプログラムとする場合、両方の符号化方式を具備しなければならず、そのため多地点会議機能プログラムが肥大化してしまう。これに対し、本実施形態では、符号化方式が異なる複数の会議機能モジュールプログラムを用意することで、会議機能モジュール自身を肥大化させることなく、多様な符号化方式の会議参加端末へ対応することを可能とする。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１、１Ａ、１Ｂ、１Ｃ：多地点会議サーバ
１１：サーバ制御部
１２：サーバ呼制御部
１３：リソース管理部
１４：会議機能モジュール制御部
１５：VM制御部
２１：記憶装置
３０：リソース管理サーバ
３１：リソース管理部

Claims

会議サーバ装置であって、
端末から送信された会議開催を要求する呼を着信し、当該呼を制御するサーバ呼制御手段と、
前記会議開催の要求に応じて、リソースを確保し、会議プロセスを起動するプロセス制御手段と、を備え、
前記サーバ呼制御手段は、前記会議プロセスの起動後に、前記端末からの呼を前記会議プロセスに引継ぎ、前記会議プロセスと前記端末との間で呼が接続されると、前記端末との呼を切断し、
前記会議プロセスは、前記端末とメディア情報を送受信するメディア処理手段と、前記サーバ呼制御手段から引継いだ前記端末との呼を制御するプロセス呼制御手段と、を備えること
を特徴とする会議サーバ装置。
請求項１記載の会議サーバ装置であって、
符号化方式が異なる複数の会議モジュールプログラムを記憶する記憶手段を、さらに備え、
前記プロセス制御手段は、前記会議開催の要求で指定された符号化方式に対応する会議モジュールプログラムを前記記憶手段から選択して、前記会議プロセスを起動すること
を特徴とする会議サーバ装置。
請求項１または２に記載の会議サーバ装置として、コンピュータを機能させるためのプログラム。