(57)【要約】【課題】端末の接続替え等を自動化し、利用者における利便性を向上させることができる通信会議システムを提供する。【解決手段】サーバ１０と複数の端末２１〜２５とを用いて構築される通信会議システムであって、サーバ１０が各端末２１〜２５に対して端末間の接続を指示する機能を有し、各端末２１〜２５がサーバ１０からの指示に基づいてマルチメディア信号を送受信するための最大２個のセッション５１〜５４を端末間で確立し、他の端末との間で２個のセッションを確立した端末２２〜２４でマルチメディア信号を混合（あるいは合成）や転送するＭＣＵ機能４２〜４４を実行する通信会議システム。【選択図】            図１
2006148479.tif 000002
【特許請求の範囲】
【請求項１】
サーバと複数の端末とを用いて構築される通信会議システムであって、
サーバが各端末に対して端末間の接続を指示する機能を有し、
各端末がサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する機能を実行する
ことを特徴とする通信会議システム。
【請求項２】
前記サーバが各端末に対して端末間の接続を指示し、端末間を接続する信号がテキスト情報を伝送するのに適した第１の通信プロトコル（ＨＴＴＰ）によってなされ、
前記マルチメディア信号を送受信するための通信手段が第１の通信プロトコルとは異なるプロトコルであってマルチメディア信号をストリーミング伝送するのに適したプロトコル（ＳＩＰ）によるセッションである
ことを特徴とする請求項１記載の通信会議システム。
【請求項３】
前記各端末が通信手段に接続障害が発生した場合にその旨をサーバに対して通知する機能を有し、
前記サーバが接続障害の発生を通知された場合に１個の通信手段が利用可能な端末を介して新たな通信手段を確立するよう指示を出す機能を有している
ことを特徴とする請求項１又は２記載の通信会議システム。
【請求項４】
サーバと複数の端末とを用いて実行される通信会議方法であって、
サーバが各端末に対して端末間の接続を指示し、
各端末がサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する
ことを特徴とする通信会議方法。
【請求項５】
サーバと複数の端末とを用いて実行される通信会議プログラムであって、
サーバが各端末に対して端末間の接続を指示する過程と、
各端末がサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する過程と
をコンピュータによって実行するための記述を含む
ことを特徴とする通信会議プログラム。
【請求項６】
サーバと複数の端末とを用いて構築される通信会議システムで用いられる端末であって、
サーバから各端末に対して出された端末間の接続を指示する信号を受信する機能を有し、
サーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する機能を実行するものである
ことを特徴とする通信会議用端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信回線を介して接続された複数の端末を用いて会議を行う際に用いて好適な通信会議システムに関する。
【背景技術】
【０００２】
従来、カンファレンス（会議）を開催するためのシステムでは、特別にカンファレンスサーバを設置し、参加者全員によるカンファレンスサーバへのアクセスによってカンファレンスが実現されている。このカンファレンスサーバは各参加者の音声信号を混合するための音声ミキシング機能（ＭＣＵ：Multipoint control unit）を具備している。
【０００３】
また、カンファレンスサーバを利用せずに通信会議システムを実現する構成も提案されている。このシステムでは、クライアント自身に有するミキシング機能を利用することによって、カンファレンスが実現されている。すなわち、１または複数の端末をＭＣＵとして機能させることで、カンファレンスサーバの設置を不要としている。簡易かつ少人数での会議はこのようなシステムで実現されている。
【特許文献１】特開平７−１７７１４５号公報
【特許文献２】特開平８−３２９５０号公報
【特許文献３】特開２００３−６９９６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、カンファレンスサーバを利用しない従来のシステムでは、端末自身であて先（会議参加者）を指示し、ダイヤルすることで会議が開催されている。そのため、本人もしくは端末自身がＭＣＵとして機能している端末であることを認識しておかなければならなかった。例えば、会議途中にＭＣＵとして機能している端末が抜けてしまった場合には、他の端末は接続先を変更するとともにＭＣＵとして機能する端末を変更する必要が発生する場合があった。その場合の接続替え等は利用者本人で考えて実施するしかなく、自動化されていなかった。
【０００５】
本発明は、上記のような事情を考慮してなされたものであって、端末の接続替え等を自動化し、利用者における利便性を向上させることができる通信会議システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、請求項１記載は、サーバと複数の端末とを用いて構築される通信会議システムであって、サーバが各端末に対して端末間の接続を指示する機能を有し、各端末がサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する機能を実行することを特徴とする。
【０００７】
請求項２記載の発明は、前記サーバが各端末に対して端末間の接続を指示し、端末間を接続する信号がテキスト情報を伝送するのに適した第１の通信プロトコル（ＨＴＴＰ）によってなされ、前記マルチメディア信号を送受信するための通信手段が第１の通信プロトコルとは異なるプロトコルであってマルチメディア信号をストリーミング伝送するのに適したプロトコル（ＳＩＰ）によるセッションであることを特徴とする。
【０００８】
請求項３記載の発明は、前記各端末が通信手段に接続障害が発生した場合にその旨をサーバに対して通知する機能を有し、前記サーバが接続障害の発生を通知された場合に１個の通信手段が利用可能な端末を介して新たな通信手段を確立するよう指示を出す機能を有していることを特徴とする。
【０００９】
請求項４記載の発明は、サーバと複数の端末とを用いて実行される通信会議方法であって、サーバが各端末に対して端末間の接続を指示し、各端末がサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送することを特徴とする。
【００１０】
請求項５記載の発明は、サーバと複数の端末とを用いて実行される通信会議プログラムであって、サーバが各端末に対して端末間の接続を指示する過程と、各端末がサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する過程とをコンピュータによって実行するための記述を含むことを特徴とする。
【００１１】
請求項６記載の発明は、サーバと複数の端末とを用いて構築される通信会議システムで用いられる端末であって、サーバから各端末に対して出された端末間の接続を指示する信号を受信する機能を有し、サーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合（あるいは合成）や転送する機能を実行するものであることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、サーバから各端末に対して端末間の接続の指示を行うようにするとともに、各端末でサーバからの指示に基づいてマルチメディア信号を送受信するための最大２個の通信手段を端末間で確立し、他の端末との間で２個の通信手段を確立した端末でマルチメディア信号を混合又は合成する機能を実行するようにしたので、各端末共通のＭＣＵの設置を省略した場合に、端末間に接続替え等を自動化することができる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施の形態について説明する。図１は本発明の一実施の形態の構成を示すシステム図である。図１に示す通信会議システムは、サーバ１０と、サーバ１０に通信回線を介して接続されている複数の端末２１、２２、２３、２４および２５とから構成されている。
【００１４】
サーバ１０はコンピュータであり、所定のＯＳ（Operating System）上でＡＰサーバ（アプリケーションサーバ）１１を実行している。ＡＰサーバ１１は、Ｗｅｂ（ウェブ）アプリケーションサーバと呼ばれるサーバであり、端末２１〜２５との間で主にテキスト情報を伝送するのに適した通信プロトコルであるＨＴＴＰ（HyperText Transfer Protocol）によってアプリケーションレベルで通信を行い、端末２１〜２５から要求を受けてそれに応じた処理を行ったり、端末２１〜２５に対して所定の指示や情報を送り出したりする。サーバ１０は、また、各端末の状態の管理するためのＤＢ（データベース）を備えている。
【００１５】
端末２１〜２５は、携帯型パーソナルコンピュータ等のコンピュータ端末である。各端末２１〜２５では、所定の通信回線（通信網）へ接続する機能と、映像撮影機能や音声録音・再生機能が利用可能となっている。各端末２１〜２５上では、通信会議を実現するためのプログラムであるソフトフォン３１〜３５が実行されている。ソフトフォンとは、一般に、パーソナルコンピュータ、ＰＤＡ（Personal Digital(Data) Assistants）等の端末で、所定のプログラム（アプリケーションソフトウェア）を実行することで、インターネット等のネットワークを介して音声通話やテレビ電話等の通信を実現するための機能である。本実施の形態では、各ソフトフォン３１〜３５が、ＳＩＰ／ＲＴＰによって他の最大２個のソフトフォンとの間でセッションを確立（生成）できるようになっている。また、各ソフトフォン３１〜３５は、ＨＴＴＰによる通信によって、ＡＰサーバ１１から各セッションの接続先やその変更についての指示や、端末２１〜２５の表示装置に表示すべき映像画面の画面数の情報を入手するように構成されている。さらに、各ソフトフォン３１〜３５は、ＭＣＵとしての機能を提供できるようになっていて、ＭＣＵによって、他の端末から送られてきた音声情報を自己の端末で録音中の音声情報と混合して他の端末へ送信することができるようになっている。また、映像信号については時分割で多重することで複数端末分の信号を１つのセッションで転送するようにしてもよいし、あるいはＭＣＵにさらに映像情報等を自己の端末で撮影中の映像情報等と合成して他の端末へ送信する機能を備えさせることで、合成した情報を転送するようにしてもよい。
【００１６】
なお、ＳＩＰ（Session Initiation Protocol）はＶｏＩＰ（Voice over Internet Protocol）を応用したインターネット会議、インターネット電話等で用いられるプロトコルであり、ＲＴＰ（Real-time Transport Protocol）は音声や映像等のマルチメディア信号をストリーミング伝送するのに適した通信プロトコルである。
【００１７】
図１に示す例では、５台の端末２１〜２５が、図２に示すように最大２本のＲＴＰによるセッション５１〜５４を確立することで、デイジーチェーン方式で接続される。ただし、映像と音声で端末間を異なるセッションにより確立する。各ソフトフォン３１〜３５によって１端末当たり最大２個のＲＴＰポート３１１、３１２〜３５１、３５２が利用可能となっている。この場合、各端末２１〜２５（ソフトフォン＃Ａ〜＃Ｅ）のうち端部に位置する端末２１（ソフトフォン３１）および端末２５（ソフトフォン３５）は、各１個のＲＴＰポート３１１およびＲＴＰポート３５２を使用して、端末２２（ソフトフォン３２）および端末２４（ソフトフォン３４）と各１個のセッション５１およびセッション５４を確立している。一方、中間部に位置する端末２２（ソフトフォン３２）、端末２３（ソフトフォン３３）、および端末２４（ソフトフォン３４）は、各２個のＲＴＰポート３２１および３２２、３３１および３３２、ならびに３４１および３４２を使用して、各２個のセッション５１および５２、５２および５３、ならびに５３および５４を他のソフトフォンとの間で確立している。
【００１８】
したがって、中間部に位置する端末２２（ソフトフォン３２）、端末２３（ソフトフォン３３）、および端末２４（ソフトフォン３４）では、ＭＣＵ機能４２、４３、および４４が実行されている。これらの端末２２、２３および２４では、ＭＣＵ機能４２、４３、および４４によって、音声等のマルチメディア信号の混合（あるいは合成）処理や転送処理が行われる。
【００１９】
さらに、各ソフトフォン３１〜３５は、接続端末のスクリーニングを行う機能を有している。本実施の形態では、各ソフトフォン３１〜３５がＡＰサーバ１１からのＨＴＴＰによる指示を受けることで、指示されたソフトフォン間のセッションがＳＩＰによって生成される。その際、各ソフトフォンは、接続要求してきたソフトフォンがＡＰサーバ１１から指示されたものかどうかを判定し、指示されたものであると判定された場合にのみセッションが確立されるようになっている（スクリーニング機能）。
【００２０】
各セッション５１〜５４は、各ソフトフォン３１〜３５間のＳＩＰによるデータ通信によって確立される。その際、ＶｏＩＰアドレス（番号）、ＩＰ（Internet Protocol）アドレス等の接続先の情報は、ＨＴＴＰによるデータ通信で、ＡＰサーバ１１から各ソフトフォン３１〜３５に対して通知される。
【００２１】
なお、図１に示す構成において、ＡＰサーバ１１と各ソフトフォン３１〜３５間で通信を行う際に用いるソフトウェアは、端末３１〜３５で稼働するＯＳとＡＰサーバ１１とによって共通に利用可能なコンポーネント（部品）を用いて構成されることが望ましい。例えばＯＳをＷｉｎｄｏｗｓ（登録商標）とした場合、ＡＰサーバ１１がＡｃｔｉｖｅＸ（登録商標）で各ソフトフォン３１〜３５の呼状態（接続状態）を収集できるようにしたり、ＡＰサーバ１１から各ソフトフォン３１〜３５への指示をＡｃｔｉｖｅＸ（同上）で行えるようにしたりすることが考えられる。また、各ソフトフォン３１〜３５における通信インターフェースのソフトウェア構成は、言語や実行場所によらずに利用可能なコンポーネントを組み合わせた形態であることが望ましい。
【００２２】
次に、図３を参照して、図１の構成の動作例について説明する。図３は、図１に示す構成において、５台の端末２１〜２５で通信会議を開始する際の処理の流れの一例を示している。図３では、図１に示すものと同一の構成に同一の符号を付けている。ただし、図３では、サーバ１０（あるいはＡＰサーバ１１）によって提供される機能をより詳細に分割した形で示している。すなわち、サーバ１０が、入力制御部１０１、接続制御部１０２、画面制御部１０３、およびＤＢ１０４に分けて示されている。入力制御部１０１は、各ソフトフォン３１〜３５からの信号を入力するためのインターフェースとなる構成である。接続制御部１０２は、各ソフトフォン３１〜３５に対して接続先を指示したり、接続エラー（障害）が発生した場合に各端末２１〜２５から受信したエラーを示す信号を処理したりするための機能を実現する。画面制御部１０３は、各ソフトフォン３１〜３５で画面表示すべきエラーメッセージの内容を指示するための機能を実現する。図３ではこれらの各部１０１〜１０４においてＨＴＴＰによるデータ通信が相互に行われるものとしている。
【００２３】
なお、図３において、破線の矢印がＨＴＴＰによる通信を示し、実線の矢印がＳＩＰによる通信を示している。また、会議の開始の手順は、あるソフトフォンから会議の参加者を指定した会議開催要求があった場合に、要求された参加者のソフトフォンに対して回線予約を行い、それに基づいて各ソフトフォン間で直接ＲＴＰセッションが確立される、という流れで行われるものとしている。
【００２４】
図３に示す例では、端末２１の利用者がソフトフォン３１を操作することで、自端末２１（ユーザ＃Ａ）と端末２２〜２５（ユーザ＃Ｂ〜＃Ｅ）を参加者とする会議の開催要求が出されている（Ｓ１０１）。これを受信した入力制御部１０１は、接続制御部１０２に対して接続要求を送出する（Ｓ１０２）。接続制御部１０２は、ＤＢ１０４にアクセスし、接続要求に応じて、接続先となるソフトフォン３１〜３５のユーザ名、ＶｏＩＰ番号等の情報を収集する（Ｓ１０３）。
【００２５】
次に接続制御部１０２は、各ソフトフォン３１〜３５に対して回線予約を行うよう要求する信号を、接続先のＶｏＩＰ番号と、表示画面数の情報とともにＨＴＴＰによって送信する（Ｓ１０４〜Ｓ１０８）。例えば、ソフトフォン３１（ユーザ＃Ａ）に対しては、ソフトフォン３２（ユーザ＃Ｂ）を接続先として回線予約を要求する信号を、画面数「５」（＝参加人数）を示す情報とともに送信し、同時に接続指示を要求する（Ｓ１０４）。ソフトフォン３２（ユーザ＃Ｂ）に対しては、ソフトフォン３１（ユーザ＃Ａ）とソフトフォン３３（ユーザ＃Ｃ）を接続先として回線予約を要求する信号を、画面数「５」（＝参加人数）を示す情報とともに送信する（Ｓ１０５）。
【００２６】
次にソフトフォン３１（ユーザ＃Ａ）が、ソフトフォン３２（ユーザ＃Ｂ）に対してＳＩＰによってセッションの確立を要求し、ソフトフォン３２がスクリーニングを実施して、接続可能と判定された場合には、セッションが確立する（Ｓ１０９）。次にソフトフォン３２（ユーザ＃Ｂ）が、ソフトフォン３３（ユーザ＃Ｃ）に対してＳＩＰによってセッションの確立を要求し、ソフトフォン３３がスクリーニングを実施して、接続可能と判定された場合には、セッションが確立する（Ｓ１１０）。次にソフトフォン３３（ユーザ＃Ｃ）が、ソフトフォン３４（ユーザ＃Ｄ）に対してＳＩＰによってセッションの確立を要求し、ソフトフォン３４がスクリーニングを実施して、接続可能と判定された場合には、セッションが確立する（Ｓ１１１）。
【００２７】
次に、図３の例では、ソフトフォン３４（ユーザ＃Ｄ）が、ソフトフォン３５（ユーザ＃Ｅ）に対してＳＩＰによってセッションの確立を要求したときに、何らかの障害が発生したとすると（Ｓ１１２）、ソフトフォン３４（ユーザ＃Ｄ）は、エラーの種別等を示すエラー番号を内容とするエラー通知を、入力制御部１０１に対してＨＴＴＰによって送信する（Ｓ１１３）。入力制御部１０１はエラー通知を接続制御部１０２に転送し（Ｓ１１４）、接続制御部１０２が画面制御部１０３にエラー通知を再度転送する（Ｓ１１５）。
【００２８】
画面制御部１０３は、受信したエラー通知の内容に基づいて、この例ではエラーが発生したソフトフォン３４および３５においてエラーメッセージの表示と、再接続中である旨の表示を行うよう指示する信号を、ソフトフォン３４とソフトフォン３５に対してＨＴＴＰで送信する（Ｓ１１６〜Ｓ１１７）。エラーメッセージは、エラー前の各ソフトフォンの状態やエラーの内容に応じて予め登録していた文字や図形情報によって生成される。
【００２９】
次に、接続制御部１０２は、ソフトフォン３５（ユーザ＃Ｅ）に対して、ソフトフォン３１（ユーザ＃Ａ）を接続先として回線予約するよう要求する信号を、画面数「５」を示す情報とともに送信する（Ｓ１１８）。すなわち、接続が失敗して、まだ接続されていないソフトフォン３５（ユーザ＃Ｅ）に対して、まだセッション数が「２」に達していなくて、かつエラーを発生したときの接続元（ユーザ＃Ｄ）ではないソフトフォン（ユーザ＃Ａ）との間でセッションの確立を指示するための信号がＨＴＴＰで送信される。
【００３０】
次に接続制御部１０２は、ソフトフォン３１（ユーザ＃Ａ）に対して、ソフトフォン３５（ユーザ＃Ｅ）を接続先として回線予約するよう要求する信号を、画面数「５」を示す情報とともに送信する（Ｓ１１９）。次にソフトフォン３５（ユーザ＃Ｅ）が、ソフトフォン３１（ユーザ＃Ａ）に対してＳＩＰによってセッションの確立を要求し、ソフトフォン３１がスクリーニングを実施して、接続可能と判定された場合には、セッションが確立する（Ｓ１２０）。
【００３１】
このように、本実施の形態では、ＡＰサーバ１１によって各ソフトフォン３１〜３５に対して接続先が指示されるので、各ソフトフォン３１〜３５あるいはユーザで接続先を管理する必要がなくなる。また、ＳＩＰによるセッションの確立が失敗したような場合には、エラー番号をＡＰサーバ１１に送信し、ＡＰサーバ１１でエラー番号をユーザの理解しやすい表現である文字列や図形情報に変換して表示要求を該当するソフトフォンへ送信するようにした。その際、メッセージの内容は、ＡＰサーバ１１が把握した複数のソフトフォンの状態に応じて決定することができるので、例えば各ソフトフォンで単独でＳＩＰの通信履歴等に基づいてメッセージを表示するよりも、容易に的確で詳細なメッセージを表示できるようにすることができる。
【００３２】
なお、図３では接続に失敗した場合を例として説明したが、接続中にＭＣＵ機能を利用しているソフトフォンが接続を停止したようなときも、上記と同様に、その両方のソフトフォンがＡＰサーバ１１に対してエラーメッセージを送信する等すれば、適切な接続先への接続替えが実行できる。
【００３３】
以上のように本実施の形態によれば、端末状態をＡＰサーバ１１で管理することで、端末側（ソフトフォン側）ではＡＰサーバ１１からの指示による受動的な動作のみでカンファレンスの開始・継続が可能となる。また、スクリーニングを実施することによって、予約された会議参加者以外からの着信を自動拒否することが可能である。また、ＡＰサーバ１１とソフトフォン３１〜３５が連携することによって、ＭＣＵ機能を実行しているソフトフォンが退室した時の再接続や、接続失敗時の再接続が自動的に行えるようになる。
【００３４】
なお、図１では会議参加端末をソフトフォンによるもののみとしているが、ハードフォンの場合でも、ファームウェアの変更等でＡＰサーバ１１の機能を利用できるようにすることで、本システムによる転送動作を採用したカンファレンスサーバなしの会議に参加することが可能である。
【００３５】
なお、上記実施の形態では、１ユーザ（ソフトフォン）あたり、2ライン（セッション）の通話ラインを有するようにして、各ユーザをデイジーチェーン接続するようにしている。ＭＣＵ相当の機能を実現するユーザでは２ラインを利用し、ＶｏＩＰカンファレンスが提供されている。このような構成では、空きラインのあるユーザが必ず２ユーザ存在する（単部のユーザ）。そこで、新たにユーザを追加する場合には、中間部の複数のユーザの接続替えを行うのではなく、空きラインのあるユーザを利用したセッション確立を行うようにしている。
【００３６】
次に、図４を参照して、図１に示す構成の変形例について説明する。図４に示すシステムでは、図１の構成に対して新たにサーバ６０を追加し、ＳＩＰ−Ｐｒｏｘｙ（プロキシ）サーバ６１の機能を利用できるようにしている。この構成では、ＳＩＰによる通信を、端末間直接だけでなく、ＳＩＰ−Ｐｒｏｘｙ６１を介して行うことが可能である。なお、図４では、図１と同一の構成には同一の参照符号を用いている。ただし、図４では端末２１と端末２２の２台の端末のみを示している。また、破線（間隔大）はＨＴＴＰによる信号の流れ、破線（間隔小）はＳＩＰによる信号の流れを示している。
【００３７】
図４に示す構成で、例えばソフトフォン３１からソフトフォン３２に対してセッション５１を確立しようとした際に障害が発生した場合に、ソフトフォン３１がＨＴＴＰによってＡＰサーバ１１とエラー信号およびエラーメッセージ信号を送受信することで、ソフトフォン３１によるエラーメッセージの表示が可能となっている。また、ソフトフォン３１は、エラー発生時に、エラー番号をＳＩＰによってＳＩＰ−Ｐｒｏｘｙ６１に送信する。ＳＩＰ−Ｐｒｏｘｙ６１はＳＩＰによってこのエラー番号をソフトフォン３２に対して送信する。ここでソフトフォン３２はエラーの発生を認識することができ、ソフトフォン３２がＨＴＴＰによってＡＰサーバ１１とエラー信号およびエラーメッセージ信号を送受信することで、ソフトフォン３２でエラーメッセージの表示が可能となる。
【００３８】
図４に示す実施の形態によれば、エラー発生を最初に認識したソフトフォン３１が、ＡＰサーバ１１とＳＩＰ−Ｐｒｏｘｙ６１の両方に異なる通信プロトコルでエラーの発生を通知するので、ソフトフォン３２はＳＩＰ−Ｐｒｏｘｙ６１経由でＳＩＰによってエラーの発生を認識できるようになる。
【００３９】
以上説明したように、本発明によれば、卓上ＩＰ電話機（ハードフォン）、およびＰＣ（パーソナルコンピュータ）内ＩＰ電話（ソフトフォン）に関係なく、ＡＰサーバ主導による会議が開催可能になった。また、ＰＣ内ＩＰ電話ではＡｃｔｉｖｅＸ（登録商標）等の汎用の通信コンポーネントの連携よって通話状態が監視可能となったことから、ＭＣＵ動作中端末が抜けた場合に無通話時間を少なくすることができ、既存会議への自動接続による通話継続が可能となった。また、同様に、通話接続失敗時についても当該情報によって、システム自動による再接続が可能となった。
【００４０】
なお、本発明の実施の形態は上記のものに限定されず、例えば端末やサーバで実現される各機能を統合あるいは分散する等の変更が適宜可能である。例えば、図３に示す入力制御部１０１〜ＤＢ１０４を分散して配置したり、各部を統合することが可能である。また、本発明の実施の形態は、コンピュータとソフトウェアとを用いて構成することができ、その場合のソフトウェア（プログラム）は、コンピュータ読み取り可能な記録媒体または通信回線を介して配布することが可能である。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施の形態の構成を示すシステム図。
【図２】図１の各ソフトフォン３１〜３５の接続形態を示す説明図。
【図３】図１の構成における通信処理の流れを示すシーケンス図。
【図４】図１の実施形態の変形例を示すシステム図。
【符号の説明】
【００４２】
１０，６０  サーバ
１１  ＡＰサーバ
２１〜２５  端末
３１〜３５  ソフトフォン
４２〜４４  ＭＣＵ
５１〜５４  セッション（通信ライン）
６１  ＳＩＰ−Ｐｒｏｘｙサーバ
【図１】
2006148479.tif 000003
【図２】
2006148479.tif 000004
【図３】
2006148479.tif 000005
【図４】
2006148479.tif 000006