JP2010171663A - 通信方法、通信システム、通信装置、およびコンピュータプログラム - Google Patents

Abstract

【課題】多数の通信装置が参加するシステムにおいて、障害が発生した２者間の通信を、予備の回線を用意することなく継続する。
【解決手段】端末装置２Ｂと端末装置２Ｃとの間の第一のセッションに障害が発生した場合に、端末装置２Ｃと端末装置２Ａとの間に第二のセッションを確立し、端末装置２Ｂと端末装置２Ａとの間に第三のセッションを確立する。端末装置２Ａは、端末装置２Ｂが発信したデータを受信すると、端末装置２Ｃへ第二のセッションを介してこのデータを転送する。さらに、端末装置２Ａは、端末装置２Ｃが発信したデータを受信すると、端末装置２Ｂへ第三のセッションを介してこのデータを転送する。
【選択図】図１６

Description

本発明は、電子会議システムのような、多数の通信装置が参加する通信システムおよびそれに用いられる通信方法などに関する。

ＩＰ（Internet Protocol）およびブロードバンド回線を使用して２台の通信装置間で動画像または音声をやり取りする技術が普及している。

さらに、３台以上の通信装置が相互に動画像または音声をやり取りする通信（いわゆる多者間通信）によって電子会議システムが実現されている。電子会議システムによると、多数の者が互いに離れた場所にいながら会議を行うことができる。

ところで、一般的なブロードバンド回線は、ベストエフォード型を通信形態として採用している。

ベストエフォード型のネットワークは、導入のコストが安いが、回線の通信速度を保証していない。よって、ブロードバンド回線を介して動画像または音声をやり取りしている間に、回線の輻輳によって必要な帯域が確保できずにパケットが欠損し、映像品質の低下（ブロックノイズ等）および音声の品質の低下（音切れ等）が発生してしまうことが、ある。

回線の障害によって通信の品質が低下する問題を解決するために、従来、障害が発生した回線を予備の回線に切り換える方法が採られている（特許文献１参照）。

特開２００７−８３３４９号公報

しかし、電子会議システムのような、多数の通信装置が参加して相互にデータを交換し合うシステムに、予備の回線を用意することは、コストの増大を招いてしまう。

本発明は、このような問題点に鑑み、多数の通信装置が参加するシステムにおいて、障害が発生した２者間の通信を予備の回線を用意することなく再開できるようにすることを、目的とする。

本発明の一形態に係る通信方法は、第一の通信装置と第二の通信装置との間で通信を行う通信方法であって、前記第一の通信装置と前記第二の通信装置との間の第一のセッションに障害が発生した場合に、前記第二の通信装置と、前記第一の通信装置から第一のデータを受信することができる第三の通信装置との間に、第二のセッションを確立し、前記第一の通信装置と、前記第二の通信装置から第二のデータを受信することができる第四の通信装置との間に、第三のセッションを確立し、前記第一のデータを、前記第三の通信装置から前記第二の装置へ前記第二のセッションを介して送信し、前記第二のデータを、前記第四の通信装置から前記第一の装置へ前記第三のセッションを介して送信する。前記第三の通信装置と前記第四の通信装置とは同一の通信装置であってもよい。

本発明によると、多数の通信装置が参加するシステムにおいて、障害が発生した２者間の通信を、予備の回線を用意することなく継続することができる。

電子会議システムの全体的な構成の例を示す図である。 端末装置同士の接続形態の例を示す図である。 端末装置のハードウェア構成の例を示す図である。 端末装置の機能的構成の例を示す図である。 接続順管理テーブルの例を示す図である。 主催者側接続処理の流れの例を説明するフローチャートである。 被招待者側接続処理の流れの例を説明するフローチャートである。 電子会議の形成の処理の流れの例を示すシーケンス図である。 電子会議の形成の処理の流れの例を示すシーケンス図である。 電子会議の画面の例を示す図である。 障害の発生を検知する処理の手順の第一の例を説明するための図である。 障害の発生を検知する処理の手順の第一の例を説明するための図である。 セッション切換処理部の構成の例を示す図である。 転送依頼先決定処理の流れの例を説明するフローチャートである。 転送依頼メッセージの例を示す図である。 セッションの変更後の端末装置同士の接続形態の例を示す図である。 セッションの変更の処理の流れの第一の例を示すシーケンス図である。 ＩＮＶＩＴＥメッセージの例を示す図である。 ＯＫメッセージの例を示す図である。 ＯＫメッセージの例を示す図である。 セッションの変更の処理の流れの第二の例を示すシーケンス図である。 端末装置の全体的な処理の流れの例を説明するフローチャートである。 セッションの変更後の端末装置同士の接続形態の例を示す図である。

サーバを用いずに電子会議を行うためのシステムを実現した。

図１は電子会議システム１の全体的な構成の例を示す図、図２は端末装置２同士の接続形態の例を示す図、図３は端末装置２のハードウェア構成の例を示す図、図４は端末装置２の機能的構成の例を示す図である。

図１において、電子会議システム１は、互いに離れた場所にいるユーザ同士が会議を行うためのシステムである。

電子会議システム１は、複数台の端末装置２および通信回線ＮＴなどを有する。端末装置２同士は通信回線ＮＴを介して互いに接続可能である。通信回線ＮＴとして、公衆回線、インターネット、またはLocal Area Network（ＬＡＮ）回線などが用いられる。

ユーザは、会議に参加するためには、原則として、自分の端末装置２を他のすべての参加者の端末装置２に接続させなければならない。したがって、参加者の端末装置２によって、図２に示すようなフルメッシュ型の接続形態が形成される。

端末装置２は、図３に示すように、制御装置２０ａ、Random Access Memory（ＲＡＭ）２０ｂ、Read Only Memory（ＲＯＭ）２０ｃ、ハードディスク２０ｄ、Network Interface Card（ＮＩＣ）２０ｅ、キーボード２０ｆ、ポインティングデバイス２０ｇ、入出力インタフェース２０ｈ、グラフィックボード２０ｉ、ディスプレイ２０ｊ、サウンドボード２０ｋ、およびスピーカ２０ｍなどを有する。

制御装置２０ａは、Central Processing Unit（ＣＰＵ）またはMicro Processing Unit（ＭＰＵ）などであって、ＲＡＭ２０ｂまたはＲＯＭ２０ｃに記憶されているプログラムを実行する。なお、制御装置２０ａがＭＰＵである場合は、ＲＡＭ２０ｂおよびＲＯＭ２０ｃが制御装置２０ａに一体的に組み込まれていることがある。

ＲＯＭ２０ｃまたはハードディスク２０ｄには、オペレーティングシステムのほか、図４に示すSession Initiation Protocol（ＳＩＰ）関連プログラムＰＧ１、電子会議プログラムＰＧ２、および障害回避プログラムＰＧ３が記憶されている。これらのプログラムは、必要に応じてＲＡＭ２０ｂにロードされ、制御装置２０ａによって実行される。

ＮＩＣ２０ｅは、いわゆるＬＡＮカードであって、他の端末装置２と通信を行うために用いられる。

キーボード２０ｆおよびポインティングデバイス２０ｇは、ユーザがコマンドおよびデータを端末装置２に入力するための入力装置である。

入出力インタフェース２０ｈは、ビデオカメラ３Ｖおよびマイク３Ｍを端末装置２に繋げるためのインタフェースである。入出力インタフェース２０ｈとして、Universal Serial Bus（ＵＳＢ）またはInstitute of Electrical and Electronics Engineer（ＩＥＥＥ）１３９４などが用いられる。

グラフィックボード２０ｉは、制御装置２０ａからの指令に基づいて描画を行い、ディスプレイ２０ｊへ映像（動画像）の信号を出力する。

ディスプレイ２０ｊは、グラフィックボード２０ｉから出力される信号に基づいて、会議に参加する者の映像などを表示する。

サウンドボード２０ｋは、制御装置２０ａからの指令に基づいて音声の信号を生成し、スピーカ２０ｍへ出力する。

スピーカ２０ｍは、サウンドボード２０ｋから出力される信号に基づいて、会議に参加する者の音声を再生する。

端末装置２として、通信機能が備えられたパーソナルコンピュータまたはPersonal Digital Assistant（ＰＤＡ）などの通信装置が用いられる。以下、各端末装置２を「端末装置２Ａ」、「端末装置２Ｂ」、…と区別して記載することがある。

図４において、ＳＩＰ関連プログラムＰＧ１は、ＳＩＰに基づいて他の端末装置２と通信するための処理を行うプログラムである。ＳＩＰ関連プログラムＰＧ１によると、呼制御部５１１、Real-time Transport Protocol（ＲＴＰ）制御部５１２、およびRTP Control Protocol（ＲＴＣＰ）制御部５１３などが実現される。

電子会議プログラムＰＧ２は、会議を招集したり端末装置２を会議に参加させたりするためのアプリケーションである。電子会議プログラムＰＧ２によると、被招待者指定受付部５２１、電子会議形成処理部５２２、接続順管理テーブル５２３、マルチメディアデータ生成部５２４、会議画面表示処理部５２５、および音声出力処理部５２６などが実現される。

障害回避プログラムＰＧ３は、他の端末装置２とのセッションの障害を検知し当該他の端末装置２との通信の経路を変更するためのプログラムである。障害回避プログラムＰＧ３によると、ロス率閾値記憶部５３１、受信パケットカウンタ５３２、ネットワーク品質判定部５３３、およびセッション切換処理部５３４などが実現される。

以下、図４に示す各部の処理内容などを、４人のユーザＵＡ、ＵＢ、ＵＣ、およびＵＤがそれぞれ４台の端末装置２Ａ、２Ｂ、２Ｃ、および２Ｄを用いて会議を行う場合を例に、説明する。

〔会議の開催のための処理〕
図５は接続順管理テーブル５２３の例を示す図、図６は主催者側接続処理の流れの例を説明するフローチャート、図７は被招待者側接続処理の流れの例を説明するフローチャート、図８および図９は電子会議の形成の処理の流れの例を示すシーケンス図、図１０は電子会議の画面の例を示す図である。

ＳＩＰ関連プログラムＰＧ１の呼制御部５１１は、端末装置２自身と他の端末装置２との間の呼制御を行う。つまり、両装置間のセッションを確立しまたは切断する処理を行う。例えば、端末装置２Ａの呼制御部５１１は、端末装置２Ａと端末装置２Ｂ、２Ｃ、および２Ｄそれぞれとの間の呼制御を行う。

ＲＴＰ制御部５１２は、端末装置２自身のユーザの音声および映像のデータをＲＴＰに基づいてパケット化し、他の端末装置２へ送信する処理を行う。以下、ＲＴＰに基づいて生成されたパケットを「ＲＴＰパケット６」と記載する。さらに、ＲＴＰ制御部５１２は、他の端末装置２から送信されてきたＲＴＰパケット６を受け付けて組み立てることによって、当該他の端末装置２のユーザの音声および映像のデータを再生成するための処理を行う。

ＲＴＣＰ制御部５１３は、ＲＴＣＰに基づいて、ＲＴＰパケット６に関する監視を行いその結果の統計（図１１、図１２参照）を他の端末装置２へ通知する処理を行う。さらに、他の端末装置２からＲＴＰパケット６に関する監視の結果の統計を受け取る処理を行う。

電子会議プログラムＰＧ２の被招待者指定受付部５２１は、会議の主催者であるユーザによる、会議へ招待する者（被招待者）の指定を受け付ける。具体的には、所定のコマンドが入力されると、入力用の画面がディスプレイ２０ｊに表示されるように、グラフィックボード２０ｉを制御する。そして、入力用の画面に入力された者を、被招待者として受け付ける。

例えば、ユーザＵＡが主催者である場合は、ユーザＵＡは、入力用の画面に、ユーザＵＢ、ＵＣ、およびＵＤを指定する。端末装置２Ａの被招待者指定受付部５２１は、ユーザＵＢ、ＵＣ、およびＵＤを被招待者として受け付ける。

電子会議形成処理部５２２は、端末装置２自身と他の端末装置２とのセッションの確立し会議（電子会議）を形成するための処理を行う。

接続順管理テーブル５２３には、図５のように、会議を形成する端末装置２の所有者およびＩＰアドレスが、会議に加わった順に示されている。会議が終了するごとに、接続順管理テーブル５２３は、リセットされ、どの端末装置２をも示さなくなる。

そのほか、どのユーザ名のユーザがどのＩＰアドレスの端末装置２を使用するのかを示すテーブルが、端末装置２に用意されている。

ここで、ユーザＵＡが主催者でありユーザＵＢ、ＵＣ、およびＵＤが被招待者である場合を例に、各端末装置２の電子会議形成処理部５２２の処理内容および各端末装置２の接続順管理テーブル５２３の変化について説明する。

ユーザＵＡの端末装置２（２Ａ）の電子会議形成処理部５２２は、図６のフローチャートに示す手順で処理を実行する。

ユーザＵＡがユーザＵＢ、ＵＣ、およびＵＤの順に被招待者を指定したとする。すると、電子会議形成処理部５２２は、自らの接続順管理テーブル５２３に、主催者つまりユーザＵＡのユーザ名および端末装置２Ａ自身のＩＰアドレスを示すレコードを追加する（＃６０１）。さらに、電子会議形成処理部５２２は、ユーザＵＡが指定した順に、各被参加者の端末装置２に対して、次の処理を行う。

電子会議形成処理部５２２は、１番目に指定されたユーザＵＢの端末装置２（端末装置２Ｂ）へＩＮＶＩＴＥメッセージを送信し（＃６０２）、端末装置２Ａ自身と端末装置２Ｂとのセッションの確立を図る（＃６０３）。

セッションの確立の処理と並行してまたは前後して、電子会議形成処理部５２２は、ユーザＵＢのユーザ名および端末装置２ＢのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３の最後尾に追加する（＃６０４）。

電子会議形成処理部５２２は、残りの被参加者の端末装置２に対しても、ユーザＵＡが指定した順に同様の処理を行う（＃６０２〜＃６０４）。

なお、電子会議形成処理部５２２は、ＩＮＶＩＴＥメッセージを送信する際に、Ｎ番目の端末装置２に対して、Ｎ番目までの被招待者の端末装置２のＩＰアドレスを通知する。

また、ＩＮＶＩＴＥメッセージの送信およびセッションの確立の処理は、ＳＩＰ関連プログラムＰＧ１の呼制御部５１１と連携して行われる。後述する各メッセージの送受信およびセッションの切断などの処理も、呼制御部５１１と連携して行われる。

一方、被招待者の端末装置２（２Ｂ、２Ｃ、２Ｄ）において、電子会議形成処理部５２２は、端末装置２ＡからＩＮＶＩＴＥメッセージを受信すると、図７のフローチャートに示す手順で処理を実行する。

電子会議形成処理部５２２は、主催者のユーザＵＡの端末装置２（２Ａ）を自らの接続順管理テーブル５２３の最後尾に追加する（＃６１１）。

電子会議形成処理部５２２は、端末装置２Ａから通知された被招待者の端末装置２の中に、他の端末装置２が含まれていない場合は（＃６１２でＮｏ）、自らの所有者であるユーザのユーザ名および自らのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３の最後尾に追加する（＃６１５）。本例では、端末装置２Ｂの電子会議形成処理部５２２が、この場合に該当する。

一方、電子会議形成処理部５２２は、端末装置２Ａから通知された被招待者の端末装置２の中に、他の端末装置２が含まれている場合は（＃６１２でＹｅｓ）、若い他の端末装置２から順に、セッションの確立を図るとともに（＃６１３）、当該他の端末装置２のユーザのユーザ名および自らのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３の最後尾に追加する（＃６１４）。そして、自らの所有者であるユーザのユーザ名および自らのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３の最後尾に追加する（＃６１５）。

その後、会議が開始するなどの所定のタイミングが訪れるまで、電子会議形成処理部５２２は、他の被招待者の端末装置２からＩＮＶＩＴＥメッセージを受信するごとに（＃６１６）、当該他の被招待者のユーザ名および当該他の被招待者の端末装置２のＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３の最後尾に追加する（＃６１７）。

各端末装置２における上記の処理を、図８および図９のシーケンス図を参照しながら、さらに詳細に説明する。

ユーザＵＡがユーザＵＢ、ＵＣ、およびＵＤの順に被招待者を指定すると、端末装置２Ａは、ユーザＵＡのユーザ名および端末装置２ＡのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（図８の＃７１１）。

さらに、端末装置２Ａは、１番目に指定されたユーザＵＢの端末装置２つまり端末装置２ＢへＩＮＶＩＴＥメッセージを送信し（＃７１２）、ユーザＵＢのユーザ名および端末装置２ＢのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７１３）。なお、端末装置２Ａは、ＩＮＶＩＴＥメッセージを送信する際に、被招待者の端末装置２のＩＰアドレスとして、端末装置２ＢのＩＰアドレスのみを端末装置２Ｂへ通知する。

端末装置２Ｂは、端末装置２ＡからＩＮＶＩＴＥメッセージを受信すると（＃７３１）、主催者つまりユーザＵＡのユーザ名および端末装置２ＡのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７３２）。

端末装置２Ｂは、被招待者の端末装置２のＩＰアドレスとして、端末装置２Ｂ自らのＩＰアドレスしか通知されていないので、他の被招待者の端末装置２とのセッションの確立を実行することなく、ユーザＵＢのユーザ名および端末装置２Ｂ自身のＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７３３）。そして、ＯＫメッセージを端末装置２Ａへ返信する（＃７３４）。

端末装置２Ａは、ステップ＃７１２で送信したＩＮＶＩＴＥメッセージに対するＯＫメッセージを端末装置２Ｂから受信すると（＃７１４）、ＡＣＫメッセージを端末装置２Ｂへ返信する（＃７１５）。そして、端末装置２ＢがＡＣＫメッセージを受信すると（＃７３５）、端末装置２Ａ、２Ｂは、両者間のセッションを確立する。

端末装置２Ａは、２番目に指定されたユーザＵＣの端末装置２つまり端末装置２ＣへＩＮＶＩＴＥメッセージを送信し（＃７１６）、ユーザＵＣのユーザ名および端末装置２ＣのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７１７）。なお、端末装置２Ａは、ＩＮＶＩＴＥメッセージを送信する際に、被招待者の端末装置２のＩＰアドレスとして、端末装置２Ｂおよび端末装置２ＣそれぞれのＩＰアドレスを端末装置２Ｃへ通知する。

端末装置２Ｃは、端末装置２ＡからＩＮＶＩＴＥメッセージを受信すると（＃７５１）、主催者つまりユーザＵＡのユーザ名および端末装置２ＡのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７５２）。

端末装置２Ｃは、被招待者の端末装置２のＩＰアドレスとして、端末装置２Ｃ自らのＩＰアドレスだけでなく端末装置２ＢのＩＰアドレスをも通知される。そこで、端末装置２Ｃは、端末装置２Ｂとのセッションの確立を図る。

すなわち、端末装置２Ｃは、端末装置２ＢへＩＮＶＩＴＥメッセージを送信する（＃７５３）。

端末装置２Ｂは、ＩＮＶＩＴＥメッセージを受信すると（＃７３６）、ユーザＵＣのユーザ名および端末装置２ＣのＩＰアドレスを示すレコード（つまり、ＩＮＶＩＴＥメッセージの送信元のレコード）を自らの接続順管理テーブル５２３の最後尾に追加する（＃７３７）。そして、端末装置２Ｂは、端末装置２ＣへＯＫメッセージを返信する（＃７３８）。

端末装置２Ｃは、ＯＫメッセージを受信すると（＃７５５）、ユーザＵＣのユーザ名および端末装置２Ｃ自身のＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３の最後尾に追加する（＃７５６）。そして、ＡＣＫメッセージを端末装置２Ｂへ返信し（＃７５７）、ＯＫメッセージを端末装置２Ａへ返信する（＃７５８）。

端末装置２Ｃが端末装置２ＢからのＡＣＫメッセージを受信すると（＃７３９）、端末装置２Ｂおよび２Ｃは、両者間のセッションを確立する。

端末装置２Ａは、ステップ＃７１６で送信したＩＮＶＩＴＥメッセージに対するＯＫメッセージを端末装置２Ｃから受信すると（＃７１８）、ＡＣＫメッセージを端末装置２Ｃへ返信する（＃７１９）。そして、端末装置２ＣがＡＣＫメッセージを受信すると（＃７５９）、端末装置２Ａ、２Ｃは、両者間のセッションを確立する。

これにより、端末装置２Ａ、２Ｂ、および２Ｃの３者間の通信が可能になる。つまり、ユーザＵＡ、ＵＢ、およびＵＣによる会議が可能になる。

端末装置２Ａは、３番目に指定されたユーザＵＤの端末装置２つまり端末装置２ＤへＩＮＶＩＴＥメッセージを送信し（図９の＃７２０）、ユーザＵＤのユーザ名および端末装置２ＤのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７２１）。なお、端末装置２Ａは、ＩＮＶＩＴＥメッセージを送信する際に、被招待者の端末装置２のＩＰアドレスとして、端末装置２Ｂ、２Ｃ、および２ＤそれぞれのＩＰアドレスを端末装置２Ｄへ通知する。

端末装置２Ｄは、端末装置２ＡからＩＮＶＩＴＥメッセージを受信すると（＃７７１）、主催者つまりユーザＵＡのユーザ名および端末装置２ＡのＩＰアドレスを示すレコードを自らの接続順管理テーブル５２３に追加する（＃７７２）。

端末装置２Ｄは、被招待者の端末装置２のＩＰアドレスとして、端末装置２Ｄ自らのＩＰアドレスだけでなく端末装置２Ｂおよび２ＣそれぞれのＩＰアドレスをも通知される。そこで、端末装置２Ｄは、端末装置２Ｂおよび２Ｃそれぞれとのセッションの確立を図る。

すなわち、端末装置２Ｄは、まず、端末装置２Ｂとのセッションの確立のために、端末装置２Ｃが実行した図８のステップ＃７５３〜＃７５７と同様の処理を行う（＃７７３〜＃７７６）。ただし、ここでは、ユーザＵＢのユーザ名および端末装置２ＢのＩＰアドレスを示すレコードは追加するが（＃７７４）、ユーザＵＤのユーザ名および端末装置２Ｄ自らのＩＰアドレスを示すレコードは未だ追加しない。

端末装置２Ｂは、ステップ＃７３６〜＃７３９と同様の処理を、端末装置２Ｄを相手に行う（＃７４０〜＃７４３）。この際に、ユーザＵＤのユーザ名および端末装置２ＤのＩＰアドレスを示すレコードを追加する（＃７４１）。

端末装置２Ｄは、次に、端末装置２Ｃとのセッションの確立のために、図８のステップ＃７５３〜＃７５７と同様の処理を行う（＃７７７〜＃７８１）。この際に、ユーザＵＣのユーザ名および端末装置２ＣのＩＰアドレスを示すレコードを追加し（＃７７８）、さらに、ユーザＵＤのユーザ名および端末装置２Ｄ自らのＩＰアドレスを示すレコードを追加する（＃７８０）。

端末装置２Ｃは、端末装置２Ｂのステップ＃７３６〜＃７３９と同様の処理を、端末装置２Ｄを相手に行う（＃７６０〜＃７６３）。この際に、ユーザＵＤのユーザ名および端末装置２ＤのＩＰアドレスを示すレコードを追加する（＃７４１）。

端末装置２Ｄは、端末装置２Ｂおよび２Ｃそれぞれとのセッションが確立できたら、ＯＫメッセージを端末装置２Ａへ返信する（＃７８２）。

端末装置２Ａは、ステップ＃７２０で送信したＩＮＶＩＴＥメッセージに対するＯＫメッセージを端末装置２Ｄから受信すると（＃７２２）、ＡＣＫメッセージを端末装置２Ｄへ返信する（＃７２３）。そして、端末装置２ＤがＡＣＫメッセージを受信すると（＃７８３）、端末装置２Ａ、２Ｄは、両者間のセッションを確立する。

これにより、端末装置２Ａ、２Ｂ、２Ｃ、および２Ｄの４者間の通信が可能になる。つまり、ユーザＵＡ、ＵＢ、ＵＣ、およびＵＤによる会議が可能になる。

図４に戻って、電子会議プログラムＰＧ２のマルチメディアデータ生成部５２４は、会議の開催中、ビデオカメラ３Ｖによって撮影されまたはマイク３Ｍによって録音された、端末装置２自身のユーザの動画像および音声のマルチメディアデータ７ＭＤを生成する。

マルチメディアデータ７ＭＤは、ＳＩＰ関連プログラムＰＧ１のＲＴＰ制御部５１２によって分割されＲＴＰパケット６に変換される。そして、他の端末装置２へ送信される。例えば、端末装置２Ａにおいては、ユーザＵＡのマルチメディアデータ７ＭＤがＲＴＰパケット６に変換され、端末装置２Ｂ、２Ｃ、および２Ｄへ送信される。

また、前に述べた通り、ＲＴＰ制御部５１２は、他の端末装置２から送信されてきたＲＴＰパケット６を組み立て、マルチメディアデータ７ＭＤを再生成する。例えば、端末装置２Ａにおいては、端末装置２Ｂから送信されてきたＲＴＰパケット６を組み立てて、ユーザＵＢのマルチメディアデータ７ＭＤを再生成する。端末装置２Ｃから送信されてきたＲＴＰパケット６を組み立てて、ユーザＵＣのマルチメディアデータ７ＭＤを再生成する。さらに、端末装置２Ｄから送信されてきたＲＴＰパケット６を組み立てて、ユーザＵＤのマルチメディアデータ７ＭＤを再生成する。

会議画面表示処理部５２５は、再生成されたマルチメディアデータ７ＭＤを用いて他の端末装置２のユーザの動画像が図１０のようにディスプレイ２０ｊに表示されるように、グラフィックボード２０ｉを制御する。

音声出力処理部５２６は、再生されたマルチメディアデータ７ＭＤを用いて他の端末装置２のユーザの音声がスピーカ２０ｍから出力されるように、サウンドボード２０ｋを制御する。

〔セッションの障害を検知し回避するための処理〕
図１１は障害の発生を検知する処理の手順の第一の例を説明するための図、図１２は障害の発生を検知する処理の手順の第一の例を説明するための図、図１３はセッション切換処理部５３４の構成の例を示す図である。

障害回避プログラムＰＧ３のロス率閾値記憶部５３１は、セッションに障害が発生しているか否かを判定する基準であるロス率閾値αを記憶する。

受信パケットカウンタ５３２は、端末装置２自身が使用するセッションごとに、相手方から受信したＲＴＰパケット６の個数Ｋｒをカウントする。この際に、個数Ｋｒがどの時点のものであるか、つまり、タイムスタンプを、記録しておく。

ネットワーク品質判定部５３３は、セッションの品質の良否を、ＳＩＰ関連プログラムＰＧ１のＲＴＰ制御部５１２が現実に取り扱ったＲＴＰパケット６の個数とＲＴＣＰ制御部５１３によって得られた統計の情報に基づいて、判定する。以下、端末装置２Ａが端末装置２Ｂとのセッションの障害の有無を判定する場合を例に、ネットワーク品質判定部５３３の処理を、図１１を参照しながら説明する。

端末装置２Ａのネットワーク品質判定部５３３は、ＲＴＣＰ制御部５１３が統計の情報（以下、「統計情報７ＴＤ」と記載する。）を端末装置２Ｂから受信すると、その統計情報７ＴＤから、タイムスタンプに示される時点の、端末装置２Ｂから端末装置２Ａへ送信されたＲＴＰパケット６の個数Ｋｓをチェックする。さらに、同じ時点の、端末装置２Ａ自身が端末装置２Ｂから受信したＲＴＰパケット６の個数Ｋｒをチェックする。端末装置２Ｂから端末装置２Ａへ発信されたＲＴＰパケット６に対するロスしたＲＴＰパケット６個数の割合（例えば、５％。以下、「パケットロス率β」と記載する。）を、次の（１）式より算出する。
β＝｛（Ｋｓ−Ｋｒ）／Ｋｓ｝×１００［％］ …… （１）

そして、ネットワーク品質判定部５３３は、βがαを超えていれば、端末装置２Ｂとのセッションに障害が発生していると、判定する。

または、ネットワーク品質判定部５３３は、図１２に示すような方法でセッションの障害の有無を判定することも、できる。

例えば、端末装置２Ａのネットワーク品質判定部５３３は、ある期間における端末装置２Ｂとのセッションの障害の有無を判別するために、この期間の最初に端末装置２Ｂから受信した統計情報７ＴＤに示される個数Ｋｓ１と最後に端末装置２Ｂから受信した統計情報７ＴＤに示される個数Ｋｓ２との差である個数Ｋｓ３（個数Ｋｓ２−個数Ｋｓ１）を求める。さらに、同じ期間に端末装置２Ｂから受信したＲＴＰパケット６の個数Ｋｒ３をチェックする。端末装置２Ｂから端末装置２Ａへ発信されたＲＴＰパケット６に対するロスしたＲＴＰパケット６の個数の割合（以下、「パケットロス率β’」と記載する。）を、次の（２）式より算出する。
β’＝｛（Ｋｓ３−Ｋｒ３）／Ｋｓ３｝×１００［％］ …… （２）

そして、ネットワーク品質判定部５３３は、β’がαを超えていれば、端末装置２Ｂとのセッションに障害が発生していると、判定する。このようにして、ネットワーク品質判定部５３３によってセッションの障害が検知される。

図４に戻って、セッション切換処理部５３４は、セッションに障害が発生していると判定された場合に、そのセッションによって繋がれている２台の端末装置２間の通信を、別の経路を経由して行えるように、処理を行う。セッション切換処理部５３４は、図１３に示すように、転送依頼先決定部５５１、転送依頼要求部５５２、転送セッション確立制御部５５３、および転送処理部５５４を有する。転送依頼先決定部５５１および転送依頼要求部５５２は、自らのセッションの障害が検知された場合にそのセッションの相手からのデータを他の端末装置２から転送してもらうための処理を行う。転送セッション確立制御部５５３および転送処理部５５４は、障害が発生したセッションを有する他の端末装置２に対してデータを転送するための処理を行う。

以下、セッション切換処理部５３４の各部の処理内容を、端末装置２Ｂ、２Ｃ間のセッションに障害が発生した場合を例に、説明する。

（Ｉ） 端末装置２Ｂが端末装置２Ｃよりも先にセッションの障害を検知した場合
図１４は転送依頼先決定処理の流れの例を説明するフローチャート、図１５は転送依頼メッセージ７ＲＱの例を示す図、図１６はセッションの変更後の端末装置２同士の接続形態の例を示す図、図１７はセッションの変更の処理の流れの第一の例を示すシーケンス図、図１８はＩＮＶＩＴＥメッセージの例を示す図、図１９および図２０はＯＫメッセージの例を示す図である。

端末装置２Ｂにおいて、端末装置２Ｃとのセッションの障害が検知されると、転送依頼先決定部５５１は、端末装置２Ｃのユーザ（ユーザＵＣ）のデータをどの端末装置２から転送してもらうのかを、図１４に示す手順で決定する。

端末装置２Ｂの転送依頼先決定部５５１は、自らの接続順管理テーブル５２３（図５参照）の先頭のレコードをチェックする（図１４の＃６２１）。

そのレコードに端末装置２Ｂ自身のＩＰアドレスおよび障害が発生したセッションの相手（本例では、端末装置２Ｃ）のＩＰアドレスのいずれも示されていない場合は（＃６２２でＮｏかつ＃６２３でＮｏ）、チェックしたＩＰアドレスを有する端末装置２を、転送の依頼先に決定する（＃６２５）。

一方、端末装置２Ｂまたは２ＣいずれかのＩＰアドレスが示されている場合は（＃６２２でＹｅｓまたは＃６２３でＹｅｓ）、次のレコードをチェックする（＃６２４）。そして、いずれのＩＰアドレスも示されていない場合は（＃６２２でＮｏかつ＃６２３でＮｏ）、チェックしたＩＰアドレスの端末装置２を、転送の依頼先に決定する（＃６２５）。いずれかのＩＰアドレスが示される場合は（＃６２３でＹｅｓまたは＃６２４でＹｅｓ）、以下、同様に、その次のレコードのＩＰアドレスをチェックし（＃６２３）、それが端末装置２Ｂ、２ＣいずれのＩＰアドレスとも一致しなければ、それを有する端末装置２を、転送の依頼先に決定する（＃６２５）。

つまり、転送依頼先決定部５５１は、接続順管理テーブル５２３の中の、端末装置２ＢのＩＰアドレスも端末装置２ＣのＩＰアドレスも示されない最上位のレコードを検索し、そのレコードに示されるＩＰアドレスを有する端末装置２を、転送の依頼先に決定する。

端末装置２Ｂの転送依頼要求部５５２は、転送依頼先決定部５５１によって決定された転送先へ転送依頼メッセージ７ＲＱを送信する。

転送依頼メッセージ７ＲＱは、データの転送を依頼（要求）するメッセージである。図１５に示すように、転送依頼メッセージ７ＲＱには、呼識別子情報７ＲＱａ、供給元アドレス情報７ＲＱｂ、およびデータ取扱情報７ＲＱｃが含まれている。

呼識別子情報７ＲＱａは、この転送依頼メッセージ７ＲＱを識別するためのＣａｌｌ−ＩＤ（Identification）を示す。Ｃａｌｌ−ＩＤの「＠」の後ろは、この転送依頼メッセージ７ＲＱの送信側つまり端末装置２ＢのＩＰアドレスである。本例では、端末装置２ＢのＩＰアドレスである。

供給元アドレス情報７ＲＱｂは、転送の対象のデータの供給元のＩＰアドレスを示す。本例では、端末装置２ＣのＩＰアドレスが示される。

データ取扱情報７ＲＱｃは、この転送依頼メッセージ７ＲＱの発信側つまり端末装置２Ｂがデータを転送するのかされるのか、つまり、データを受信するのか送信するのかを、表わす。「ｒｅｃｖｏｎｌｙ」は受信するのみであることを示し、「ｓｅｎｄｏｎｌｙ」は送信するのみであることを示す。

図４および図５に戻って、端末装置２Ｂの転送依頼先決定部５５１は、図５の接続順管理テーブル５２３を用いた場合は、転送先を端末装置２Ａに決定する。よって、端末装置２Ｂの転送依頼要求部５５２は、転送依頼メッセージ７ＲＱを端末装置２Ａに送信する。

端末装置２Ａにおいて、転送セッション確立制御部５５３は、端末装置２Ｂから転送依頼メッセージ７ＲＱを受信すると、図１６に示すように、端末装置２Ｂとの間でセッションの確立の処理を行う。

そして、転送処理部５５４は、その転送依頼メッセージ７ＲＱの供給元アドレス情報７ＲＱｂに示されるＩＰアドレスを有する端末装置２（つまり、端末装置２Ｃ）から受信したＲＴＰパケット６をコピーして、呼識別子情報７ＲＱａに示されるＩＰアドレスを有する端末装置２（つまり、端末装置２Ｂ）へ転送する。または、受信したＲＴＰパケット６からペイロードを抽出し、パケット化し直して送信する。

さらに、転送セッション確立制御部５５３は、端末装置２Ｃとの間のセッションの確立の処理をも行う。そして、転送処理部５５４は、端末装置２Ｂから受信したＲＴＰパケット６をコピーして端末装置２Ｃへ転送する。または、受信したＲＴＰパケット６からペイロードを抽出し、パケット化し直して端末装置２Ｃへ送信する。

ここで、端末装置２Ａ、２Ｂ、および２Ｃの各処理を、図１７のシーケンス図を参照しながらさらに詳細に説明する。

端末装置２Ｂは、端末装置２Ｃとのセッションに障害が発生したことを検知すると、端末装置２ＣへＢＹＥメッセージを送信する（図１７の＃８１１）。端末装置２Ｃは、ＢＹＥメッセージを受信すると（＃８２１）、ＯＫメッセージを端末装置２Ｂへ返信する（＃８２２）。そして、端末装置２ＢがＯＫメッセージを受信すると（＃８１２）、端末装置２Ｂおよび２Ｃは、両者間のセッションを切断する。

端末装置２Ｂは、セッションの切断の処理と前後してまたは並行して、転送の依頼先を決定する（＃８１３）。

端末装置２Ｂは、転送先つまり端末装置２Ａへ、ＩＮＶＩＴＥメッセージを送信する（＃８１４）。ただし、このＩＮＶＩＴＥメッセージは、転送用のセッションを確立するためのものである。つまり、前に図１５で説明した転送依頼メッセージ７ＲＱである。

端末装置２Ａは、転送依頼メッセージ７ＲＱ（ＩＮＶＩＴＥメッセージ）を受信すると（＃８０１）、端末装置２Ｂとのセッションの確立および端末装置２Ｃとのセッションの確立の処理を次のように実行する。

端末装置２Ａは、ＩＮＶＩＴＥメッセージを端末装置２Ｃへ送信する（＃８０２）。このＩＮＶＩＴＥメッセージには、図１８のように、呼識別子情報７ＭＧａ、転送先アドレス情報７ＭＧｂ、およびデータ取扱情報７ＭＧｃが含まれる。

呼識別子情報７ＭＧａ、転送先アドレス情報７ＭＧｂ、およびデータ取扱情報７ＭＧｃの意味は、それぞれ、転送依頼メッセージ７ＲＱの呼識別子情報７ＲＱａ、転送先アドレス情報７ＲＱｂ、およびデータ取扱情報７ＲＱｃの意味と同じである。本例では、呼識別子情報７ＭＧａには、端末装置２ＡのＩＰアドレスが示される。転送先アドレス情報７ＭＧｂには、端末装置２ＢのＩＰアドレスが示される。データ取扱情報７ＭＧｃには、「ｓｅｎｄｏｎｌｙ」が示される。

図１７に戻って、端末装置２ＣがＩＮＶＩＴＥメッセージを受信すると、端末装置２Ａおよび２Ｃは、図１９に示すようなＯＫメッセージおよびＡＣＫメッセージをやり取りして、セッションを確立する（＃８２６、＃８０３、＃８０４、＃８２７）。

ただし、端末装置２Ｂ、２Ｃ間のセッションの障害の原因が通信の不能または品質の著しい低下である場合は、端末装置２Ｃは、ステップ＃８２１において端末装置２ＢからのＢＹＥメッセージを受信できないことがある。そこで、もしも、端末装置２Ｃが端末装置２Ｂとのセッションの切断の処理を実行していない場合は、端末装置２ＡからＩＮＶＩＴＥメッセージを受信したタイミングで、端末装置２Ｂとのセッションの切断の処理を図る（＃８２４、＃８２５）。

端末装置２Ａおよび２Ｂは、端末装置２Ａ、２Ｃ間のセッションの確立の処理と前後してまたは並行して、図２０に示すようなＯＫメッセージおよびＡＣＫメッセージをやり取りし、両者間のセッションの確立の処理を実行する（＃８０５、＃８１７、＃８０６、＃８１８）。

その後、端末装置２Ａは、図１６において太線で示すように、新たに確立したセッションを用いて、端末装置２Ｃから送られてくるユーザＵＣの動画像および音声のデータを端末装置２Ｂへ転送し、端末装置２Ｂから送られてくるユーザＵＢの動画像および音声のデータを端末装置２Ｃへ転送する。

（II） 端末装置２Ｂおよび２Ｃがほぼ同時にセッションの障害を検知した場合
図２１はセッションの変更の処理の流れの第二の例を示すシーケンス図である。

端末装置２Ｂと端末装置２Ｃとが極短い所定の時間差で（つまり、同時にまたはほぼ同時に）両者間のセッションの障害を検知することがあり得る。その場合は、両者ともに、それぞれが有する接続順管理テーブル５２３（図５参照）に基づいて、図１４で説明した手順で転送の依頼先を決定する。

図６、図７、図８、および図９で説明した方法によると、端末装置２Ｂの接続順管理テーブル５２３および端末装置２Ｃの接続順管理テーブル５２３には、同一のレコードが同一の順位で格納される。さらに、図１４で説明した方法によると、端末装置２Ｂの転送依頼先決定部５５１および端末装置２Ｃの転送依頼先決定部５５１は、ともに、同一の端末装置２を転送先として決定する。

よって、接続順管理テーブル５２３の内容が図５に示す通りである場合は、端末装置２Ｂの転送依頼要求部５５２も、端末装置２Ｃの転送依頼要求部５５２も、転送依頼メッセージ７ＲＱを端末装置２Ａに対して送信する。端末装置２Ａは、一方の転送依頼メッセージ７ＲＱを受け付け、もう一方の転送依頼メッセージ７ＲＱを拒否する。そして、端末装置２Ａは、端末装置２Ｂとのセッションを確立するとともに、端末装置２Ｃとのセッションを確立する。

ここで、端末装置２Ａ、２Ｂ、および２Ｃの各処理を、図２１のシーケンス図を参照しながらさらに詳細に説明する。

端末装置２Ｂおよび２Ｃは、両装置間のセッションに障害が発生したことを検知すると、端末装置２Ｂは端末装置２ＣへＢＹＥメッセージを送信し（図２１の＃８４１）、端末装置２Ｃは端末装置２ＢへＢＹＥメッセージを送信する（＃８４２）。端末装置２Ｂおよび２Ｃは、可能であれば、受信したＢＹＥメッセージに対するＯＫメッセージを相手方へ返信する（＃８４３、＃８５３、＃８５４、＃８４４）。そして、端末装置２Ｂおよび２Ｃは、両者間のセッションを切断する。

端末装置２Ｂおよび２Ｃは、自らの接続順管理テーブル５２３に基づいて転送の依頼先を決定する（＃８４５、＃８５５）。そして、それぞれが決定した依頼先（本例では、端末装置２Ａ）へ転送依頼メッセージ７ＲＱ（ＩＮＶＩＴＥメッセージ）を送信する（＃８４６）。

端末装置２Ａは、端末装置２Ｂからの転送依頼メッセージ７ＲＱおよび端末装置２Ｃからの転送依頼メッセージ７ＲＱをほぼ同時に受信する（＃８３１、＃８３２）。すると、端末装置２Ａは、一方を受け付け、もう一方を拒否する。以下、端末装置２Ｂからの転送依頼メッセージ７ＲＱを受け付けた場合を例に説明する。

端末装置２Ａは、端末装置２Ｂからの転送依頼メッセージ７ＲＱを受け付けると、それに対応して、端末装置２Ｂのデータの転送を通知するＩＮＶＩＴＥメッセージを端末装置２Ｃへ送信する（＃８３３）。さらに、端末装置２Ｃからの転送依頼メッセージ７ＲＱを拒否することを通知するメッセージを端末装置２Ｃへ通知する（＃８３４）。

端末装置２Ｃは、端末装置２Ａからの各メッセージに対する応答のメッセージを端末装置２Ａへ返信する（＃８５９、＃８６０）。すると、端末装置２Ａがそれらのメッセージを受信すると（＃８３６、＃８３７）、端末装置２Ａおよび２Ｃは、両者間のセッションを確立する。

端末装置２Ａ、２Ｃ間のセッションの確立の処理と前後してまたは並行して、端末装置２Ａは、ステップ＃８３１で受信した転送依頼メッセージ７ＲＱ（ＩＮＶＩＴＥメッセージ）を受け入れる旨のメッセージを返信し、端末装置２Ｂは、それに応答する（＃８３８、＃８４７、＃８４８、＃８３９）。そして、端末装置２Ａおよび２Ｂは、両者間のセッションを確立する。

図２２は端末装置２の全体的な処理の流れの例を説明するフローチャートである。次に、端末装置２Ａを例に、ある会議に用いられる際の端末装置２の全体的な処理の流れを、図２２のフローチャートを参照しながら説明する。

端末装置２Ａは、主催者であるユーザが当会議への出席を求める者（被招待者）を指定すると（＃１１でＹｅｓ）、被招待者それぞれの端末装置２とのセッションを確立するための処理を行う（＃１２）。この処理の手順は、前に図６で説明した通りである。

または、端末装置２Ａが主催者以外のユーザ（つまり、被招待者）によって使用される場合は、主催者の端末装置２からの要求に基づいて、参加者それぞれの端末装置２とのセッションを確立するための処理を行う（＃１３）。この処理の手順は、前に図７で説明した通りである。

端末装置２Ａは、他の参加者すべての端末装置２とのセッションの確立が完了すると、会議が終了するまで随時、ビデオカメラ３Ｖおよびマイク３Ｍによって得られた、ユーザＵＡの動画像および音声を、他の参加者すべての端末装置２へ配信する（＃１５）。さらに、他のユーザの動画像および音声を当該他のユーザ端末装置２から受信し再生する（＃１６）。また、転送の依頼を受けて代替用のセッションを確立している場合は（＃１７でＹｅｓ）、受信した動画像および音声を、決められた他の端末装置２へ転送する（＃１８）。

さらに、端末装置２Ａは、会議が終了するまで適宜、自らと他の端末装置２とのセッションの状態を監視する（＃１９）。監視方法は前に図１１および図１２で説明した通りである。そして、端末装置２Ａは、障害を検知した場合は（＃２０でＹｅｓ）、障害のあるセッションを使用して通信を行う相手側の端末装置２のデータを、他の端末装置２のうちのいずれに転送してもらうのかを決定し（＃２１）、決定した他の端末装置２に対して転送の依頼を行う（＃２２）。そして、決定した他の端末装置２との代替用のセッションを新たに確立する（＃２３）。依頼先の決定方法は、前に図１４で説明した通りである。

一方、他の２台の端末装置２同士のセッションに障害が発生し、当該他の２台の端末装置２のうちのいずれかから転送の依頼を受けた場合は（＃２４でＹｅｓ）、当該他の２台の端末装置２それぞれとの間に代替用の新たなセッションを確立する（＃２５）。例えば、端末装置２Ｂと端末装置２Ｃとの間のセッションの障害が発生した場合は、端末装置２Ａ、２Ｂ間に代替用のセッションを確立し、端末装置２Ａ、２Ｃ間に代替用のセッションを確立する。そして、その後は、ステップ＃１８において、図１６に示したように、代替用のセッションを介して、ユーザＵＢの動画像および音声を端末装置２Ｃへ転送し、ユーザＵＣの動画像および音声を端末装置２Ｂへ転送する。

なお、代替用のセッションの確立の処理の手順は、前に図１７および図２１で説明した通りである。

本実施形態によると、障害が発生した２者間の通信を、予備の回線を用意することなく継続することができる。

さらに、障害があったセッションのみを切断すればよいので、正常な他のセッションをそのまま維持することができ、音声および映像の品質の低下を回避することができる。

また、フルメッシュ型の接続形態を採用しているので、ＭＣＵ（Multipoint Control Unit）がなくても電子会議システムを実現することができる。

図２３はセッションの変更後の端末装置２同士の接続形態の例を示す図である。本実施形態では、１つのセッションに障害が発生した場合に代替用のセッションを確立しデータの転送を送信したが、さらに別のセッションに障害が発生した場合も、代替用のセッションを確立しデータの転送を送信することができる。例えば、端末装置２Ｂ、２Ｃ間のセッションに障害が発生し代替用のセッションを確立した後、端末装置２Ｃ、２Ｄ間のセッションに障害が発生した場合は、図２３に示すように、さらに代替用のセッションを確立しデータを転送するようにしてもよい。

本実施形態では、パケットのロス率に基づいて障害の有無を判定したが、一定の時間以上データのやり取りが行われていないセッションを、障害のあるセッションであると判定してもよい。

本発明は、電子会議システム以外の通信システム、例えば、多人数が参加するオンラインのゲームのシステムなどにも、適用することができる。

その他、電子会議システム１、端末装置２の全体または各部の構成、処理内容、処理順序、テーブルの構成などは、本発明の趣旨に沿って適宜変更することができる。

１ 電子会議システム（通信システム）
２ 端末装置（通信装置）
５１１ 呼制御部
５５２ 転送依頼要求部
５５３ 転送セッション確立制御部
５５４ 転送処理部
６ ＲＴＰパケット

Claims (5)

1. 第一の通信装置と第二の通信装置との間で通信を行う通信方法であって、
   前記第一の通信装置と前記第二の通信装置との間の第一のセッションに障害が発生した場合に、
   前記第二の通信装置と、前記第一の通信装置から第一のデータを受信することができる第三の通信装置との間に、第二のセッションを確立し、
   前記第一の通信装置と、前記第二の通信装置から第二のデータを受信することができる第四の通信装置との間に、第三のセッションを確立し、
   前記第一のデータを、前記第三の通信装置から前記第二の装置へ前記第二のセッションを介して送信し、
   前記第二のデータを、前記第四の通信装置から前記第一の装置へ前記第三のセッションを介して送信する、
   通信方法。
2. 相互にデータをやり取りすることができる第一の通信装置、第二の通信装置、および第三の通信装置を有する通信システムであって、
   前記第一の通信装置は、
   当該第一の通信装置と前記第二の通信装置との間のセッションの障害を検知する障害検知手段と、
   前記障害が検知された場合に、当該第一の通信装置と前記第三の通信装置との間に、前記セッションの代替用の第一の代替セッションを確立する、第一の代替セッション確立手段と、
   を有し、
   前記第二の通信装置は、
   前記障害が検知された場合に、当該第二の通信装置と前記第三の通信装置との間に、前記セッションの代替用の第二の代替セッションを確立する、第二の代替セッション確立手段、
   を有し、
   前記第三の通信装置は、
   前記障害が検知された後、前記第一の通信装置から受信した第一のデータを、前記セッションの代わりに前記第二の代替セッションを介して前記第二の装置へ転送し、前記第二の通信装置から受信した第二のデータを、前記セッションの代わりに前記第一の代替セッションを介して前記第一の装置へ転送する、データ転送手段、
   を有する、
   通信システム。
3. 第一の相手側装置と第一のセッションを介して通信する機能および第二の相手側装置と第二のセッションを介して通信する機能を有する通信装置であって、
   前記第一のセッションの障害を検知する障害検知手段と、
   前記障害が検知された場合に、当該通信装置と前記第二の相手側装置との間に、前記第一のセッションを代替するための代替セッションを確立する、代替セッション確立手段と、
   当該通信装置が前記第二のセッションを介して発信した発信データを前記第一の相手側装置へ転送するように要求する、転送要求手段と、
   前記第一の相手側装置から発信された相手側データを、前記代替セッションを介して前記第二の相手側装置から受信する、相手側データ受信手段と、
   を有する通信装置。
4. 第一の相手側装置と第一のセッションを介して通信する機能および第二の相手側装置と第二のセッションを介して通信する機能を有する通信装置であって、
   前記第一の相手側装置から要求があった場合に、当該通信装置と前記第一の相手側装置との間に前記第一の相手側装置と前記第二の相手側装置との間のセッションの代替用のセッションである第一の代替セッションを確立し、当該通信装置と前記第二の相手側装置との間に前記第一の相手側装置と前記第二の相手側装置との間のセッションの代替用のセッションである第二の代替セッションを確立する、代替セッション確立手段と、
   前記第一の相手側装置から前記第一のセッションを介して受信した第一のデータを、前記第二の代替セッションを介して前記第二の相手側装置へ転送し、前記第二の相手側装置から前記第二のセッションを介して受信した第二のデータを、前記第一の代替セッションを介して前記第一の相手側装置へ転送する、データ転送手段と、
   を有する通信装置。
5. 第一の相手側装置と第一のセッションを介して通信する機能および第二の相手側装置と第二のセッションを介して通信する機能を有するコンピュータに用いられるコンピュータプログラムであって、
   当該コンピュータに、
   前記第一のセッションの障害を検知する処理を実行させ、
   前記障害が検知された場合に当該通信装置と前記第二の相手側装置との間に前記第一のセッションを代替するための代替セッションを確立する処理を実行させ、
   当該通信装置が前記第二のセッションを介して発信した発信データを前記第一の相手側装置へ転送するように要求する処理を実行させ、
   前記第一の相手側装置から発信された相手側データを、前記代替セッションを介して前記第二の相手側装置から受信する処理を実行させる、
   コンピュータプログラム。
   

Images