(57)【要約】【課題】ネットワーク負荷を増大させることなく、リアルタイムに各装置の状態を特定することができるネットワーク通信システムを提供する。【解決手段】ＲＴＰの拡張ヘッダとして、各拠点の識別子と各拠点の状態を示す情報を付加する。各拠点の情報に発話者を特定することができる情報（収音した音声のレベルが閾値以上であるかを示す情報）を含める。各拠点の会議端末では、受信したＲＴＰパケットに含まれる拡張ヘッダの情報を内部メモリに管理しておく。これにより、ネットワーク負荷を増大させることなくリアルタイムに発話者を特定することができる。【選択図】図３
2008306623.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される複数の端末からなるネットワーク通信システムであって、
前記端末は、他の端末の識別情報と他の端末の状態を示す情報とを記憶した記憶部と、
自身の端末の状態を検出する検出部と、
自身の端末の識別情報、および自身の端末の状態を示す情報、ならびに前記記憶部に記憶されている他の端末の識別情報、および他の端末の状態を示す情報、を所定のプロトコルに含まれる拡張情報として送信する通信部と、
前記通信部が他装置から拡張情報を受信したとき、この拡張情報に基づいて自身の端末の記憶部に記憶されている情報を更新し、
前記通信部に対し、拡張情報を送信した他の端末に自身の端末の情報を含めた拡張情報を送信するとき、当該他の端末の識別情報、および当該他の端末の状態を示す情報を含めずに送信するように設定する制御部と、
を備えたネットワーク通信システム。
【請求項２】
前記端末は、収音部と放音部とを備えた音声会議端末であり、
前記通信部は、前記収音部が収音した音声を前記所定のプロトコルに含まれる音声データとして送信し、
前記検出部は、前記収音部の収音した音声のレベルを検出し、そのレベルが所定の閾値以上であるか否かを示す情報を前記自身の端末の状態を示す情報に含める請求項１に記載のネットワーク通信システム。
【請求項３】
前記制御部は、前記拡張情報に他の端末の制御を行う制御情報を含めて送信するように前記通信部に設定する請求項１、または請求項２に記載のネットワーク通信システム。
【請求項４】
前記複数の端末を階層状に接続してなり、
前記検出部は、自身の端末の階層段階を前記自身の端末の状態を示す情報に含める請求項１、請求項２、または請求項３に記載のネットワーク通信システム。
【請求項５】
前記複数の端末のいずれかに接続される管理用端末を備え、
前記管理用端末は、接続される端末に対し、その端末の記憶部に記憶されている情報を送信する要求を行う要求部を備え、
前記端末の制御部は、前記要求を受信した場合、定期的または記憶部の内容に変化があったときに前記記憶部に記憶されている情報を前記管理用端末に送信する請求項１乃至請求項４のいずれかに記載のネットワーク通信システム。
【請求項６】
前記複数の端末に接続され、各端末からそれぞれの端末の状態を示す情報を受信する会議サーバを備えた請求項１乃至請求項５のいずれかに記載のネットワーク通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数の端末を相互に接続してなるネットワーク通信システムに関する。
【背景技術】
【０００２】
従来、遠隔地間で会議を行う会議システムが各種開示されている。このような会議システムでは、音声の品質を確保するために種々の提案がされている（例えば特許文献１、特許文献２参照）。特許文献１の装置は、受信側の処理能力に応じたデータを複数の端末に同時配信することで、どの端末でも最適な通話品質を確保することができるものである。また、特許文献２の装置は、サーバ装置が端末の数を音声データに付与して配信することにより、受信側で端末数に応じたレベル調整を行い、音声品質を確保するものである。
【０００３】
また、多地点で会議を行うため、各装置の状態（発話者の有無、接続の有無、等）が問題となる。そこで、参加者が発話者を特定することができる技術が開示されている（例えば特許文献３参照）。特許文献３の装置は、音声データとは別のデータとして発話有無の判定データを配信し、発話者を特定するものである。
【特許文献１】特開２００５−２７７９４９号公報
【特許文献２】特開２００３−２３４９９号公報
【特許文献３】特表２００３−５０６９０６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１、２の装置によれば、各装置の状態を検出できるわけではなかった。一方、特許文献３の構成によれば、音声データとは別のトラフィックが発生するため、ネットワーク負荷が増える。そのため、リアルタイム通信が阻害される結果となっていた。
【０００５】
そこで、この発明は、ネットワーク負荷を増大させることなく、リアルタイムに各装置の状態を特定することができるネットワーク通信システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
この発明のネットワーク通信システムは、ネットワークを介して接続される複数の端末からなるネットワーク通信システムであって、前記端末は、他の端末の識別情報と他の端末の状態を示す情報とを記憶した記憶部と、自身の端末の状態を検出する検出部と、自身の端末の識別情報、および自身の端末の状態を示す情報、ならびに前記記憶部に記憶されている他の端末の識別情報、および他の端末の状態を示す情報、を所定のプロトコルに含まれる拡張情報として送信する通信部と、前記通信部が他装置から拡張情報を受信したとき、この拡張情報に基づいて自身の端末の記憶部に記憶されている情報を更新し、前記通信部に対し、拡張情報を送信した他の端末に自身の端末の情報を含めた拡張情報を送信するとき、当該他の端末の識別情報、および当該他の端末の状態を示す情報を含めずに送信するように設定する制御部と、を備えたことを特徴とする。
【０００７】
この構成では、各端末が他装置の状態を示す情報をメモリに記録しておく。各装置は、自装置の状態を示す情報とメモリに記録された他装置の状態を示す情報とを所定のプロトコル（例えばＲＴＰ（Real-time Transport Protocol））に含まれる拡張情報（ＲＴＰ拡張ヘッダ）として送信する。受信側では、受信した拡張情報に基づいてメモリの記録内容を更新する。また、拡張情報を送信した端末に対してはその端末の状態を示す情報を送信しない。すなわち、送信先の装置の状態を示す情報は拡張ヘッダに含まれない。これにより、システム内の全ての端末が他装置の状態を記録しておくことができ、また、他装置の状態を示す情報はＲＴＰパケットに含まれる拡張ヘッダに記載されているため、ネットワーク負荷を増大させることがない。
【０００８】
また、この発明は、さらに、前記端末は、収音部と放音部とを備えた音声会議端末であり、前記通信部は、前記収音部が収音した音声を前記所定のプロトコルに含まれる音声データとして送信し、前記検出部は、前記収音部の収音した音声のレベルを検出し、そのレベルが所定の閾値以上であるか否かを示す情報を前記自身の端末の状態を示す情報に含めることを特徴とする。
【０００９】
この構成では、各端末が収音部と放音部を備えている。各端末は、収音した音声のレベルを検出し、そのレベルが所定の閾値以上であるか否かを検出する。所定の閾値以上であれば発話者が存在すると判断でき、閾値以上である旨を示す情報を装置の状態を示す情報に含めて送受信することで、各端末の発話者の有無を検出することができる。
【００１０】
また、この発明は、さらに、前記制御部は、前記拡張情報に他の端末の制御を行う制御情報を含めて送信するように前記通信部に設定することを特徴とする。
【００１１】
この構成では、拡張情報に他装置を制御する情報を含めて送信する。例えば他装置の音量制御を行う。
【００１２】
また、この発明は、さらに、前記複数の端末を階層状に接続してなり、前記検出部は、自身の端末の階層段階を前記自身の端末の状態を示す情報に含めることを特徴とする。
【００１３】
この構成では、各端末を階層状に接続する（カスケード接続する）。端末間では自装置の状態として階層段階を示す情報を送受信する。階層段階を示す情報を送受信することで、ネットワーク内の不具合（ループや階層制限オーバー等）を速やかに検出することができる。
【００１４】
また、この発明は、さらに、前記複数の端末のいずれかに接続される管理用端末を備え、前記管理用端末は、接続される端末に対し、その端末の記憶部に記憶されている情報を送信する要求を行う要求部を備え、前記端末の制御部は、前記要求を受信した場合、定期的または記憶部の内容に変化があったときに前記記憶部に記憶されている情報を前記管理用端末に送信することを特徴とする。
【００１５】
この構成では、管理用端末を備える。管理用端末は、最も簡易的にはパーソナルコンピュータ（ＰＣ）により実現されるが、いずれかの端末が管理用端末となってもよい。ＰＣがいずれかの端末にメモリの内容を送信するように要求し、その内容を受信することで、システム内の各端末の状態を一元に管理することができる。なお、端末のメモリ内容は、ＳＹＳＬＯＧとして送受信すればよい。
【００１６】
また、この発明は、さらに、前記複数の端末に接続され、各端末からそれぞれの端末の状態を示す情報を受信する会議サーバを備えたことを特徴とする。
【００１７】
この構成では、会議サーバを備える。会議サーバは、各端末からそれぞれの端末の状態を示す情報を受信する。会議サーバが各端末の状態を一元して管理する。会議サーバにＬＣＤ等の表示部を備えていれば、全端末の状態を表示することができる。
【発明の効果】
【００１８】
この発明によれば、ネットワーク負荷を増大させることなく、リアルタイムに各装置の状態を特定することができる。
【発明を実施するための最良の形態】
【００１９】
本発明の実施形態に係るネットワーク通信システムについて説明する。
【００２０】
図１は、ネットワーク通信システムの構成を示すブロック図である。音声通信システムは、インターネットであるネットワーク２００を介して接続される会議サーバ１０、会議端末１１Ａ〜１１Ｄ、およびＰＣ１２Ａを備えている。会議端末１１Ａ〜１１Ｄは、それぞれ別の場所である会議室１０１Ａ〜１０１Ｄに設置されている。また、ＰＣ１２Ａは、会議室１０１Ａに設置されている。会議サーバ１０は、いずれかの会議室に設置されていてもよいし、別の場所に設置されていてもよい。なお、各装置間は、実際にはルータを介してＶＰＮ等の暗号化通信により接続される。
【００２１】
図２は、会議端末１１Ａの構成を示すブロック図である。なお、会議端末１１Ａ〜１１Ｄは、全て同じ構成、機能を有する。そのため、図２においては代表して会議端末１１Ａの構成を示す。
【００２２】
会議端末１１Ａは、制御部１１１、ネットワークＩ／Ｆ１１２、放音用ミキサ１１３、音声検出部１１４、送信用ミキサ１１５、メモリ１１６、スピーカＳＰ、およびマイクＭＩＣを備えている。なお、本実施形態ではＡ／Ｄコンバータ、Ｄ／Ａコンバータ、パワーアンプ等を省略し、装置内を伝達する音声信号は全てデジタル音声信号とする。
【００２３】
制御部１１１は、会議端末１１Ａを統括的に制御する。また、ネットワークＩ／Ｆ１１２を制御して、自装置で収音した音声を所定のプロトコルでネットワークへ送信させる。本実施形態では、会議端末間を送受信するデータのプロトコルとして、ＲＴＰを用いる。
【００２４】
図３は、ＲＴＰに係る送信パケットの構成例を示す図である。同図左欄に示すように、ＲＴＰの送信パケットは、ＲＴＰ標準ヘッダ、ＲＴＰ拡張ヘッダ、および音声データから構成される。ＲＴＰ標準ヘッダは、汎用のＲＴＰに準じたヘッダであり、このＲＴＰ標準ヘッダにはパケット内に拡張ヘッダが含まれているか否かを示す情報やタイムスタンプ等が記載されている。
【００２５】
ＲＴＰ拡張ヘッダは、本実施形態のネットワーク通信システムで用いられる独自の拡張ヘッダである。ＲＴＰ拡張ヘッダには、同図右欄に示すように、ヘッダ識別子、データ長、接続数、バージョン、拠点識別子、拠点付加情報等の種々のデータが含まれている。
【００２６】
ヘッダ識別子は、ＲＴＰ拡張ヘッダの識別に用いられる。データ長は、ＲＴＰ拡張ヘッダのデータ長を表す。接続数は、自装置に接続されている端末数を示す。本実施形態では、各会議端末は１または複数の会議端末とメッシュ接続やカスケード接続（図５を参照）により接続される。図１に示した例では各会議端末は、それぞれ３台の端末と接続され、３チャンネルの通信を行うものである。バージョンは、ＲＴＰ拡張ヘッダのバージョンを示すものである。
【００２７】
拠点識別子は、そのあとに含まれる拠点付加情報を識別するために用いられるものである。拠点付加情報は、各拠点（会議室）の収音音声のレベルや機器の状態などの情報を示す。会議端末１１Ａの制御部１１１は、この拠点付加情報を基に、各拠点の会議端末の状態をメモリ１１６に記録する。詳細は後述する。
【００２８】
制御部１１１は、上記のＲＴＰ拡張ヘッダを生成するために、音声検出部１１４で検出される収音音声のレベルを取得し、閾値判定結果を取得する。
【００２９】
音声検出部１１４は、話者が発話した場合の音声レベルを判定する閾値が設定されており、入力された収音音声のレベルが閾値以上であるか否かを判定する。音声検出部１１４は、収音音声のレベルが閾値以上であれば、話者が存在する旨を示す閾値判定結果を制御部１１１に出力する。制御部１１１は、音声検出部１１４が検出した収音音声のレベルや、閾値判定結果を拠点付加情報に含めてネットワークＩ／Ｆ１１２を介して他装置に送信する。
【００３０】
ここで、ネットワークＩ／Ｆ１１２は、制御部１１１の制御に従って、送信用ミキサ１１５から入力される音声信号、および上記閾値判定結果等からＲＴＰパケットを生成する。送信用ミキサ１１５は、カスケード接続（図５（Ｂ）を参照）の場合、マイクＭＩＣから入力される音声信号と、ネットワークＩ／Ｆ１１２から入力される各拠点（会議端末１１Ｂ〜１１Ｄ）からのＲＴＰパケットに含まれる音声信号をミキシングしてネットワークＩ／Ｆ１１２に出力する。各会議端末には、それぞれ別個のＲＴＰパケットが送信される。
【００３１】
送信用ミキサ１１５は、制御部１１１の制御に従って、ミキシングする音声信号を選択する。例えばカスケード接続において会議端末１１ＢにＲＴＰパケットを送信する場合、制御部１１１は、送信用ミキサ１１５に会議端末１１Ｃおよび会議端末１１Ｄから受信したＲＴＰパケットに含まれる音声信号と、自装置で収音したマイクＭＩＣの収音信号とをミキシングするように送信用ミキサ１１５に設定する。そして、ネットワークＩ／Ｆ１１２でＲＴＰパケットを生成し、会議端末１１Ｂに送信する。
【００３２】
図４は、音声信号の送受信の態様を示した概念図である。同図に示すように、会議端末１１Ａの制御部１１１は、各会議端末にそれぞれ別個のＲＴＰパケットを送信する。すなわち、会議端末１１Ｂには、送信用ミキサ１１５に会議端末１１Ｃから受信したＲＴＰパケットに含まれる音声信号ｓ１３と、会議端末１１Ｄから受信したＲＴＰパケットに含まれる音声信号ｓ１４と、自装置で収音したマイクＭＩＣの収音信号ｓ１１と、をミキシングして音声データを生成し、さらに会議端末１１Ｃから受信したＲＴＰパケットに含まれる拡張ヘッダの情報、会議端末１１Ｄから受信したＲＴＰパケットに含まれる拡張ヘッダの情報、および自装置の情報、に基づいて拡張ヘッダを生成し、ＲＴＰパケットとして送信する。同様に、会議端末１１Ｃには、会議端末１１Ｂの音声信号ｓ１２と、会議端末１１Ｄの音声信号ｓ１４と、自装置の収音信号ｓ１１と、をミキシングして音声データを生成し、会議端末１１Ｂからの拡張ヘッダの情報、会議端末１１Ｄからの拡張ヘッダの情報、および自装置の情報、に基づいて拡張ヘッダを生成し、ＲＴＰパケットとして送信する。また、会議端末１１Ｄには、会議端末１１Ｂの音声信号ｓ１２と、会議端末１１Ｃの音声信号ｓ１３と、自装置の収音信号ｓ１１と、をミキシングして音声データを生成し、会議端末１１Ｂからの拡張ヘッダの情報、会議端末１１Ｃからの拡張ヘッダの情報、および自装置の情報、に基づいて拡張ヘッダを生成し、ＲＴＰパケットとして送信する。
【００３３】
会議端末１１Ａの放音用ミキサ１１３は、他の会議端末１１Ｂ〜１１Ｄから受信したＲＴＰパケットに含まれる音声信号をミキシングしてスピーカＳＰへ出力し、スピーカＳＰは、入力された音声信号に基づいて音声を放音する。図４の例では、他の会議端末１１Ｂ〜１１Ｄから受信したＲＴＰパケットに含まれる音声信号ｓ１２，ｓ１３，ｓ１４がミキシングされて放音される。なお、スピーカを複数備えている場合、ミキシングせずにそれぞれのスピーカから各拠点の音声を放音することも可能である。
【００３４】
以上のようなＲＴＰパケットの送受信を各会議端末が行うことで、音声会議を実現する。
【００３５】
次に、会議端末１１Ａ〜１１Ｄの接続態様について説明する。図５（Ａ）は、会議端末１１Ａ〜１１Ｄをメッシュ接続した態様を示す図であり、同図（Ｂ）は、会議端末１１Ａ〜１１Ｄと同じ構成からなる会議端末１１Ｅ〜１１Ｊをカスケード接続した態様を示す図である。なお、図１においては会議端末１１Ａ〜１１Ｄを接続した構成のみ示したが、図５（Ｂ）では、説明の便宜上、会議端末１１Ｅ〜１１Ｊを接続した構成を示す。
【００３６】
同図（Ａ）に示すメッシュ接続では、各会議端末が相互に接続され、ＲＴＰパケットを送受信する。同図（Ａ）のメッシュ接続では、４台の接続を示しているが、無論この接続数よりも少なくてもよいし、装置の仕様上さらに複数接続できる場合はさらに接続数が多くてもよい。
【００３７】
同図（Ｂ）に示すカスケード接続では、各会議端末は３台以下の端末と接続され、ＲＴＰパケットを送受信する。なお、装置の仕様上さらに複数の端末と接続できる場合はさらに接続数が多くてもよい。また、同図（Ｂ）のカスケード接続では、システム全体として会議端末１１Ｅ〜１１Ｊの６台の接続を示しているが、無論この接続数よりも少なくてもよいし、多くてもよい。カスケード接続においては、接続が階層化されている。例えば同図（Ｂ）の例において、会議端末１１Ｆを中心として考え、会議端末１１Ｈを上位側の階層とすると、会議端末１１Ｅおよび会議端末１１Ｇが下位側の階層である。会議端末１１Ｉおよび会議端末１１Ｊは、会議端末１１Ｈの下位側の階層である。階層の管理は後述の通信ホップ数によって行われる。
【００３８】
図６は、ＲＴＰパケットに含まれる拡張ヘッダ情報の送受信態様を示す図である。まず、図６（Ａ）において、メッシュ接続における拡張ヘッダ情報の送受信態様を示す。なお、実際には各会議端末間でＲＴＰパケットが送受信されているが、同図（Ａ）においては、説明の便宜上会議端末１１ＡがＲＴＰパケットを受信する例を示す。
【００３９】
会議端末１１Ａは、各会議端末からＲＴＰパケットを受信する。会議端末１１Ｂから受信するＲＴＰパケットには、会議端末１１Ｂにおける情報（収音音声のレベルや閾値判定結果）のほか、他の端末の情報として会議端末１１Ｃおよび会議端末１１Ｄの情報が含まれている。また、会議端末１１Ｃから受信するＲＴＰパケットには、会議端末１１Ｃにおける情報（収音音声のレベルや閾値判定結果）のほか、他の端末の情報として会議端末１１Ｂおよび会議端末１１Ｄの情報が含まれている。同様に、会議端末１１Ｄから受信するＲＴＰパケットには、会議端末１１Ｄにおける情報（収音音声のレベルや閾値判定結果）のほか、他の端末の情報として会議端末１１Ｂおよび会議端末１１Ｃの情報が含まれている。各会議端末は、他の端末の情報を送信するためにメモリ１１６に各拠点の会議端末の状態を記録しており、このメモリ１１６の記録に応じてＲＴＰパケットを送信する。
【００４０】
図７は、メモリ１１６に記録されている各拠点の会議端末の状態を示す情報である。同図上欄のＵｐ，Ｌｅｆｔ，Ｒｉｇｈｔは、配列上の相対的な位置を示し、それぞれ自装置に接続されている端末の識別情報（ノードリンク情報）を示す。なお、本実施形態では、３チャンネルの通信を行うため、Ｕｐ，Ｌｅｆｔ，Ｒｉｇｈｔに分けてノードリンクを管理しているが、さらに複数チャンネルの通信を行う場合には、別のノードリンク情報を付加すればよい。
【００４１】
ノード識別情報は、自装置の識別情報である。ノード識別情報は、各端末に固有の値であればどのようなものであってもよい。例えばＭＡＣアドレスを用いることができる。他装置からは、図３に示した拠点識別子としてこのノード識別情報が送信されるため、他装置のノード識別情報が上記ノードリンク情報として用いられる。例えば図６（Ａ）に示した例では、会議端末１１Ａは、Ｕｐとして会議端末１１Ｃのノード識別情報を記録し、Ｒｉｇｈｔとして会議端末１１Ｂのノード識別情報を記録し、Ｌｅｆｔとして会議端末１１Ｄのノード識別情報を記録する。また、図６（Ｂ）の例では、システム全体としてさらに多数の端末が接続されるが、各端末に接続される数は３つ以下であるため、ノードリンク情報として記録される数は上記と同様に３つである。図１０を用いて、図６（Ｂ）に示した接続を行う場合のノードリンク情報の具体例について説明する。図１０は、カスケード接続におけるノードリンク情報の具体的な例を示す図である。ここでは、会議端末１１Ｆを中心として考える。なお、同図においては説明の便宜上、ノード識別情報に会議端末の構成番号を付しているが、無論実際にはＭＡＣアドレス等が用いられる。
【００４２】
まず、会議端末１１Ｆの上位側には会議端末１１Ｈが接続されているため、ノードリンク情報のＵｐには１つ下の要素に記載されている会議端末１１Ｈの情報を示す１を記載する。同様に、Ｌｅｆｔには４つ下の要素に記載されている会議端末１１Ｅの情報を示す４を記載し、Ｒｉｇｈｔには５つ下の要素に記載されている会議端末１１Ｇの情報を示す５を記載する。また、会議端末１１Ｈの下位側には会議端末１１Ｉおよび会議端末１１Ｊが接続されているため、会議端末１１Ｈのノードリンク情報において、Ｕｐには会議端末１１Ｆの情報を示す−１を記載し、Ｌｅｆｔには１つ下の要素に記載されている会議端末１１Ｉの情報を示す１を記載し、Ｒｉｇｈｔには２つ下の要素に記載されている会議端末１１Ｊの情報を示す２を記載する。会議端末１１Ｉ、１１Ｊ、１１Ｅ、および１１Ｇにおいては、下位側に接続されている端末が存在しないため、ノードリンク情報にＵｐのみ記載される。
【００４３】
次に、ノードメタ情報には、各端末の状態が記録されている。各端末の状態として、例えば図７に示すように、閾値判定結果、暗騒音レベル、機器状態、通信ホップ数、ＣＤＢ（Command Descriptor Block）が含まれる。閾値判定結果は、上述したように発話者の存在有無を示す情報である。暗騒音レベルは、発話者が存在しない場合の音声信号のレベルを示す情報である。機器状態は、例えばその端末がミュート中であるか、マイクが故障中であるか、等を示す情報である。通信ホップ数は、その端末がどの階層に存在するかを示す情報である。図１０に示した例を参照すると、会議端末１１Ｆの通信ホップ数は自装置であるため０となる。会議端末１１Ｈは１段階上位側であるため通信ホップ数が１となり、会議端末１１Ｅおよび会議端末１１Ｇは１段階下位側であるため通信ホップ数は１となる。また、会議端末１１Ｉおよび会議端末１１Ｊは会議端末１１Ｈの１段階下位側であるため、通信ホップ数は２となる。なお、メッシュ接続においては、各端末が相互に接続されているため、通信ホップ数の管理を行わなくてもよい。ＣＤＢは、他装置を制御するコマンド情報であり、例えば他装置の音量制御を行う場合に、音量制御情報としてＲＴＰパケットにＣＤＢを含めて送信する。受信側では、制御部１１１がこのＣＤＢをメモリ１１６に記録し、音量制御を行う。なお、音量制御とは、送信する音声信号のレベルの制御と受信した音声信号のレベルの制御とを含むものである。すなわち、送信音声信号と受信音声信号のレベルを別々に制御することもできるものである。
【００４４】
制御部１１１は、各会議端末からＲＴＰパケットを受信したとき、図７に示すメモリ１１６の記録内容を更新する。例えば、ＲＴＰ拡張ヘッダ情報に存在するがメモリ１１６に記録されていないノード識別情報を受信した場合、そのノード識別情報に係る拠点付加情報をノードメタ情報に記録する。一方でメモリ１１６のノードメタ情報には記録されているが、ＲＴＰ拡張ヘッダ情報にその端末のノード識別情報が含まれていない場合、その端末の接続がシステム内から途切れたとしてメモリ１１６から削除する。
【００４５】
ここで、例えば会議端末１１Ｂと会議端末１１Ｃの接続が途切れている場合、会議端末１１Ｂから受信した拡張ヘッダ情報には、会議端末１１Ｃの情報が含まれていない。また、会議端末１１Ｃから受信した拡張ヘッダ情報には、会議端末１１Ｂの情報が含まれていない。しかし、会議端末１１Ｄから受信した拡張ヘッダ情報には、会議端末１１Ｂと会議端末１１Ｃの情報が含まれていることとなる。そのため、会議端末１１Ａは、各会議端末から受信した拡張ヘッダ情報を比較することで、会議端末１１Ｂと会議端末１１Ｃの接続が途切れたことを検出することができる。
【００４６】
同様の更新をカスケード接続においても行う。図６（Ｂ）は、カスケード接続における拡張ヘッダ情報の送受信態様を示す図である。各会議端末は自装置の情報を接続されている端末に送信する。例えば会議端末１１Ｅは、自装置の情報を会議端末１１Ｆに送信する。この会議端末１１Ｅの情報は、会議端末１１Ｆから順に下層側である会議端末１１Ｇ〜１１Ｈに送信される。また、会議端末１１Ｆは、自装置の情報を会議端末１１Ｅ、会議端末１１Ｇ、および会議端末１１Ｈに送信する。ここで、会議端末１１Ｆには、会議端末１１Ｇ、会議端末１１Ｈの情報に加え、会議端末１１Ｈの下層に接続されている会議端末１１Ｉと会議端末１１Ｊの情報が受信されているから、会議端末１１Ｅには会議端末１１Ｆ〜会議端末１１Ｊの全ての情報が送信される。したがって、カスケード接続においても各会議端末はシステム内に接続されている全ての会議端末の情報が受信される。なお、各会議端末の制御部１１１は、その端末から受信した情報を返信することがないため、情報がループすることがない。
【００４７】
ここで、カスケード接続に不具合が発生し、例えば会議端末１１Ｊと１１Ｅが接続されてしまった場合、会議端末１１Ｊから会議端末１１Ｅに、会議端末１１Ｊの情報が送信される。すなわち、会議端末１１Ｅでは、複数の端末から同じ端末の情報が重複して受信される。そのため、各会議端末では、受信した複数の拡張ヘッダ情報を比較することで、ループが発生していることを検出することができる。
【００４８】
また、本発明の実施形態に係るネットワーク通信システムによれば、図７や図１０に示した情報を各端末において記録しておくことで、一度会議に参加した端末同士で次回会議を行う場合、接続手順を簡略化することができる。各端末において、会議参加した端末、および接続態様を記録しておく。例えば図５（Ａ）の例では、会議端末１１Ａ〜１１Ｄが参加し、メッシュ接続である旨を示す情報を記録しておく。また、図５（Ｂ）の例では、会議端末１１Ｅ〜１１Ｊが参加し、カスケード接続である旨、および接続相手先（会議端末１１Ｆでは会議端末１１Ｅ、１１Ｈ、および１１Ｇ）を示す情報を記録しておく。これにより、次に会議を開始するとき、いずれかの端末（例えば会議端末１１Ｆ）でユーザが会議参加の動作を行うと、その会議端末（会議端末１１Ｆ）から各端末（会議端末１１Ｅ、１１Ｈ、および１１Ｇ）へ接続が開始され、接続先（会議端末１１Ｈ）でさらに他の端末（会議端末１１Ｉおよび１１Ｊ）へ接続が開始される。その結果、全端末との接続が容易に構築される。なお、各端末では上記の情報を通話履歴、アドレス帳、等としてユーザに分かりやすい情報として記録しておけばよい。アドレス帳として記録する場合、例えば「支店連絡会議」等のような名称を付けて記録しておくこともできる。
【００４９】
次に、図１における会議サーバ１０の機能、構成について説明する。図８は、会議サーバ１０の構成を示すブロック図である。同図に示すように、会議サーバ１０は、通信制御部１５０、スケジュール制御部１５１、話者情報管理部１５２、ネットワークＩ／Ｆ１５３、表示部１５４を備えている。
【００５０】
通信制御部１５０は、ネットワークＩ／Ｆ１５３を介して会議端末１１Ａ〜１１Ｄと通信する。具体的には、通信制御部１５０は、アドレス管理機能やプロキシサーバの機能を有し、各会議端末１１Ａ〜１１Ｄ間の通信網の確立や解除の制御を行う。また、通信制御部１５０は、各会議端末の閾値判定結果から話者の存在を検出し、話者情報管理部１５２にプレゼンス情報として記録しておく。
【００５１】
スケジュール制御部１５１は、タイマ機能を備え、予め入力された会議等のスケジュールを記憶し、会議の開始タイミングを検出すると、通信制御部１５０へ通信網の確立制御を行うように通知する。また、会議の終了タイミングを検出すると、通信制御部１５０へ通信網の解除制御を行うように通知する。また、スケジュール制御部１５１は、話者情報管理部１５２に対し、時刻情報を与える。
【００５２】
話者情報管理部１５２は、通信制御部１５０を介して、各会議端末１１Ａ〜１１Ｄのプレゼンス情報を取得し、スケジュール制御部１５１からの時刻情報と対応づけて、時系列でのプレゼンス状況データを生成する。この際、プレゼンス情報と会議端末とは関連付けされている。生成されたプレゼンス状況データは、表示部１５４へ与えられるとともに記憶され、通信制御部１５０を介してＰＣ１２Ａ等から要求されれば要求元へ送信される。
【００５３】
表示部１５４は、液晶パネル等からなり、話者情報管理部１５２から与えられた時刻情報、およびプレゼンス状況データに基づいて、話者の変化が視覚的に取得できるようなグラフィカル表示を行う。これにより、会議サーバ１０が設置された位置にいる人は、話者の状況を容易に且つ視覚的に確認することができる。
【００５４】
なお、実際には、各会議端末が会議サーバ１０のＩＰアドレスを保持しており、各会議端末が会議サーバ１０に対してＳＩＰ  ＲＥＧＩＳＴＥＲを送信することでプレゼンス情報を管理する。
【００５５】
次に、図１において、ＰＣ１２Ａは、いわゆる汎用パーソナルコンピュータであり、ネットワークＩ／Ｆや表示部等を備えている。ＰＣ１２Ａは、会議端末１１Ａと同じ拠点に設置されており、会議端末１１Ａのユーザ（例えば会議管理者）が会議を行いながら操作をするものである。
【００５６】
ＰＣ１２Ａは、会議サーバ１０からプレゼンス情報を受信し、これを自身の表示部に表示する。図９は、ネットワーク通信システムにおいてプレゼンス情報の送受信を示す図である。同図に示すように、ＰＣ１２Ａは、会議サーバ１０から例えばＨＴＴＰプロトコルによりプレゼンス情報を受信する。プレゼンス情報を受信することでどの拠点が会議に参加しているか、各拠点の参加状況等を視覚的に認識することができる。
【００５７】
また、ＰＣ１２Ａは、システム内のいずれかの会議端末にＳＹＳＬＯＧの送信要求を行う。同図の例では、同じ拠点に設置されている会議端末１１Ａに要求する。なお、ＰＣ１２Ａと会議端末１１Ａは、ネットワーク２００を介して通信するが、無論ＬＡＮ経由で通信してもよい。実際にはＳＹＳＬＯＧの送信要求はｔｅｌｎｅｔ等を用いて通知される。
【００５８】
会議端末１１Ａは、ＳＹＳＬＯＧの送信要求を受信すると、メモリ１１６に記録されている内容をＳＹＳＬＯＧとして定期的にＰＣ１２Ａに送信する。なお、メモリ１１６を更新した場合に、即時ＳＹＳＬＯＧを送信するようにしてもよい。ＰＣ１２Ａは、受信したＳＹＳＬＯＧの内容を表示部に表示する。これにより、システム内の各拠点の状態が容易に判断することができる。
【００５９】
また、ＰＣ１２Ａは会議端末１１Ａに定期的にｐｉｎｇを送信する。このｐｉｎｇは、会議端末１１Ａにおいて、ＰＣ１２Ａがハングアップしているか否かの情報として用いられる。すなわち、会議端末１１Ａは、内部にタイマを備えており、ｐｉｎｇを受信する毎にタイマをリセットする。タイマがタイムアウトした場合、ｐｉｎｇの送信が途切れたとして以後ＳＹＳＬＯＧの送信を停止する。これによりＳＹＳＬＯＧを送り続ける事態を防止する。なお、ｐｉｎｇの送信は本発明において必須の構成ではない。また、ＰＣ１２Ａがハングアップしているか否かを確認できるものであればｐｉｎｇに限るものではない。
【００６０】
ＰＣ１２Ａは、会議終了時など、各端末の管理を停止する場合、会議端末１１Ａに対し、ＳＹＳＬＯＧ送信停止要求を送信する。これにより会議端末１１ＡはＳＹＳＬＯＧの送信を停止する。なお、会議中に会議端末１１Ａがシステム内から切断された場合、ＰＣ１２Ａは他の会議端末にＳＹＳＬＯＧの送信要求を行えばよい。
【００６１】
なお、ＰＣ１２Ａの上記機能は、ソフトウェア（アプリケーション）により実現される。
【００６２】
なお、ＰＣ１２Ａや会議サーバ１０の構成は本発明において必須ではない。会議端末自身にＬＣＤ等の表示部が有れば、会議端末においてプレゼンス情報や端末状況を表示することも可能である。
【００６３】
なお、会議端末が話者位置を検出することができる場合、話者位置情報などを送受信してもよい。放音側で指向性を制御することができる場合、話者位置情報を送受信することで、特定の方向から放音されているように（話者位置から放音されているように）制御することができる。
【図面の簡単な説明】
【００６４】
【図１】ネットワーク通信システムの構成を示すブロック図である。
【図２】会議端末１１Ａの構成を示すブロック図である。
【図３】ＲＴＰに係る送信パケットの構成例を示す図である。
【図４】音声信号の送受信の態様を示した概念図である。
【図５】会議端末の接続態様を示す図である。
【図６】ＲＴＰパケットに含まれる拡張ヘッダの情報の送受信態様を示す図である。
【図７】メモリ１１６に記録されている各拠点の会議端末の状態を示す情報である。
【図８】会議サーバ１０の構成を示すブロック図である。
【図９】ネットワーク通信システムにおいてプレゼンス情報の送受信を示す図である。
【図１０】カスケード接続におけるノードリンク情報の具体的な例を示す図である。
【符号の説明】
【００６５】
１０−会議サーバ
１１Ａ〜１１Ｄ−会議端末
１２Ａ−ＰＣ
【図１】
2008306623.tif 000003
【図２】
2008306623.tif 000004
【図３】
2008306623.tif 000005
【図４】
2008306623.tif 000006
【図５】
2008306623.tif 000007
【図６】
2008306623.tif 000008
【図７】
2008306623.tif 000009
【図８】
2008306623.tif 000010
【図９】
2008306623.tif 000011
【図１０】
2008306623.tif 000012