(57)【特許請求の範囲】
【請求項１】
端末間でネットワークを介して送受信されるメッセージを中継して該端末間のセッションを管理する、現用系としての第１の中継装置と、
端末間でネットワークを介して送受信されるメッセージを中継して該端末間のセッションを管理するための、コールドスタンバイで待機する待機系としての第２の中継装置と、
前記第１の中継装置により中継されるメッセージのメッセージログを記憶し、待機系から現用系へ切り替えられた前記第２の中継装置に該メッセージログを出力する記憶装置と
を備え、
前記第１の中継装置は、中継されるメッセージのメッセージログを前記記憶装置に出力し、
前記記憶装置は、
前記第１の中継装置から受信されたメッセージログが記憶されるログ保存部と、
障害時に接続状態を復元する呼又はセッションを示す呼救済対象識別子が予め記憶される呼救済対象リスト保存部と、
前記ログ保存部に記憶されたメッセージログから、前記呼救済対象リスト保存部に記憶された呼救済対象識別子が含まれるメッセージログを抽出するファイル作成部と、
抽出されたメッセージログを前記第２の中継装置に送信する送信部と
を有し、
前記呼救済対象リスト保存部に保存される呼救済対象識別子は、ＳＩＰヘッダのＣａｌｌ−ＩＤであり、
前記ファイル作成部は、前記ログ保存部に記憶されたメッセージログのＣａｌｌ−ＩＤと、前記呼救済対象リスト保存部に記憶されたＣａｌｌ−ＩＤとが一致するメッセージログを抽出し、
前記第２の中継装置は、
入力されるメッセージに応じた処理を実行し、端末を相互に接続する中継処理部と、
前記第１の中継装置の障害を検出して、自装置を待機系から現用系へ切り替える監視制御部と、
抽出されたメッセージログを前記記憶装置から受信し、メッセージログ又はメッセージログに基づく情報を前記中継処理部に出力する再開処理部と
を有し、
前記中継処理部は、前記再開処理部から入力したメッセージ又は情報に応じた処理を実行して、前記第１の中継装置での接続状態を復元する中継システム。
【請求項２】
前記メッセージログに基づく情報は、
リクエストの次の宛先を示すリクエストＵＲＩヘッダ情報と、リクエストの最終的な着信先を示すＴｏヘッダ情報と、リクエストの生成元を示すＦｒｏｍヘッダ情報と、接続状態を復元するための情報か又は運用中の情報かのいずれかを示す再開フラグとを含む請求項１に記載の中継システム。
【請求項３】
前記第１及び第２の中継装置は、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）に基づくＳＩＰメッセージを中継して、端末間のセッションを管理するＳＩＰサーバである請求項１に記載の中継システム。
【請求項４】
前記中継処理部は、
端末間のセッション状態を管理する状態管理部と、
メッセージの送受信処理、及び、送受信するパケットと内部で保持するメッセージ構造体とを相互に変換するメッセージ変換処理を行うプロトコル制御部と
を有する請求項１に記載の中継システム。
【請求項５】
前記再開処理部は、
前記記憶装置からメッセージログを受信する受信部と、
前記受信部で受信されたメッセージログ内の予め定められた情報と、接続状態を復元するための情報か又は運用中の情報かのいずれかを示す再開フラグとを含むメッセージ構造体を作成し、該メッセージ構造体を又はメッセージ構造体が保持されたメモリ上のアドレスを前記中継処理部へ出力するメッセージ作成部と、
を有し、
前記中継処理部は、前記メッセージ作成部からの出力に従いメッセージ構造体を参照してセッション状態を更新し、及び、メッセージ構造体の再開フラグに従いメッセージ構造体をパケットに変換して送信するか、若しくは、パケットを送信しないかを判断する請求項１に記載の中継システム。
【請求項６】
前記中継処理部は、
メッセージ構造体の再開フラグが、運用中の情報を示す場合にはメッセージ構造体をパケットに変換して送信し、接続状態を復元するための情報を示す場合には、パケットを送信しない請求項５に記載の中継システム。
【請求項７】
前記監視処理部は、
前記第１の中継装置へ監視信号を送信する監視信号送信部と、
タイマをセットするタイマ制御部と、
前記タイマを参照し、前記監視信号送信部からの監視信号に対する応答が予め定められた時間内に受信されないと、自装置を待機系から現用系へ切り替える現用待機切り替え部と
を有する請求項１に記載の中継システム。
【請求項８】
端末間でネットワークを介して送受信されるメッセージを中継して該端末間のセッションを管理する、現用系としての第１の中継装置は、中継されるメッセージのメッセージログを出力し、
第１の中継装置からのメッセージログを記憶し、
第１の中継装置の障害を検出して、コールドスタンバイで待機する待機系としての第２の中継装置を待機系から現用系へ切り替え、
記憶されたメッセージログから、該メッセージログのＣａｌｌ−ＩＤと障害時に接続状態を復元する呼又はセッションを示す予め記憶されたＳＩＰヘッダのＣａｌｌ−ＩＤとが一致するメッセージログを抽出し、
抽出されたメッセージログを第２の中継装置へ出力し、
第２の中継装置が、抽出されたメッセージログを受信し、メッセージログ又はメッセージログに基づく情報に応じた処理を実行して、第１の中継装置での接続状態を復元する呼救済方法。
【請求項９】
抽出されたメッセージログ内の予め定められた情報と、接続状態を復元するための情報か又は運用中の情報かのいずれかを示す再開フラグとを含むメッセージ構造体を作成することと、
該メッセージ構造体を参照してセッション状態を更新し、及び、メッセージ構造体の再開フラグに従いメッセージ構造体をパケットに変換して送信するか、若しくは、パケットを送信しないかを判断すること
をさらに含む請求項８に記載の呼救済方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、中継システムおよび呼救済方法に係り、特に、セッション制御および管理を行う装置が障害時に、既に確立されたセション情報を復旧するシステム及び方法、さらには、安価にシステムの信頼性を高めるための中継システムおよび呼救済方法に関する。
【背景技術】
【０００２】
インターネット上でＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）やインスタントメッセージング等のリアルタイムサービスに用いられるプロトコルとして、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）の標準化が行われ、ＩＥＴＦ  ＲＦＣ３２６１（非特許文献１）として制定されている。サービスの実現に当たっては、センタ側でＳＩＰプロキシー（Ｐｒｏｘｙ）の機能とＳＩＰ登録（Ｒｅｇｉｓｔｒａｒ）の機能を併せ持つＳＩＰサーバの提供が必要となる。ＳＩＰサーバは、複数の端末からの接続要求を受け付け、相手端末との通信（以降セッションと呼ぶ）の状態を管理している。従って、システムの実現に当たってはその信頼性および可用性に配慮した設計が重要となる。
【０００３】
一般に、システムの信頼性・可用性を確保する技術としてホットスタンバイ（ホットスペア）方式とコールドスタンバイ方式が知られている。ホットスタンバイは、同じ構成のシステムを２系統用意しておき、片方（現用系）を作動させ、もう一方（待機系）は同じ動作を行ないながら待機状態にしておく。待機系は現用系と常に同じ状態を保っておき、現用系に障害が発生すると即座に待機系に処理が引き継がれる。一方、コールドスタンバイは、同じ構成の２つのシステムを構築し、片方は通常通りに動作させておき、もう一方は予備として動作させずに待機させておく。通常動作を行っているシステムに障害が発生した場合に、予備のシステムを起動し、通常動作のシステムと同じ状態にした後に切り替える方式である。
【０００４】
コールドスタンバイでは、障害が発生してから予備のシステムを起動して切り替えるため、障害発生時にはシステム全体の停止時間が長くなる。通常時には予備のシステムを稼動しておく必要がないため、コストを安く抑えられるというメリットがある。一方、ホットスタンバイは、常に予備のシステムも動作させているためコストがかかるが、障害発生時には瞬時に切り替えられるため、システム全体の停止時間は短くなり、耐障害性が高まるというメリットがある。
【０００５】
電子交換機の分野においては、制御系装置内の以上でも呼救済を実現し、サービス追加に伴う救済処理の変更を大幅に軽減する方法等が開示されている（例えば、特許文献１参照）。また、現用（ＡＣＴ）系と予備（ＳＢＹ）系と、それらの系間で共有が必要なデータを記憶する領域を有する外部記憶装置と、外部記憶装置の接続系を切り替える切替スイッチを設け、系間の情報転送、運転同期を取る方式が開示されている（例えば、特許文献２参照）。また、アクティブサーバ及び非アクティブサーバの各々内蔵ハードディスクドライブの一部をミラー化することによりデータの２重化を行うことが開示されている（例えば、特許文献３参照）。
【特許文献１】特開平５−２２７６１号公報
【特許文献２】特開平５−２４４２６０号公報
【特許文献３】特開２００２−１７１５４４号公報
【非特許文献１】ＩＥＴＦ（ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）  ＲＦＣ３２６１
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、ＳＩＰサーバを高いコストパフォーマンスで実現するために考案されたものである。すなわち、ホットスタンバイでは、ＣＰＵ、メモリ、ディスク、ネットワークといった全てのハードウエアを二重化してこれを同時に動作させる必要があるため、コスト上昇が避けられない。コールドスタンバイにおける引継ぎ方式として現用系システムの全メモリ内容を外部記憶装置にバックアップし、待機系システムはこれを再ロードして再開するという方式が考えられる。しかし、この方式では全メモリ内容の書き込み負荷および再開時の再ロード時間が大きく、特に大規模システムの運用方式としては実用的ではない。
【０００７】
本発明は、以上の点に鑑み、コストの安いコールドスタンバイをベースとしてシステムの停止時間を短縮するための中継システムおよび呼救済方法を提供することを目的とする。また、本発明は、ＳＩＰサーバ固有の特性に着目することによって既に確立されたセッション状態の復元時間を高速化することでシステム全体の停止時間を短縮することを目的とする。
【０００８】
また、本発明は、ＳＩＰサーバの障害時のセッション情報の復旧を高いコストパフォーマンスで実現する手段を提供することを目的のひとつとする。本発明は、特殊なハードウエアやソフトウエアを用いる従来のホットスタンバイ方式に比べると安価に、かつ、従来のコールドスタンバイ方式における現用系装置の全メモリのバックアップ方式に比べると、高速にセッション情報を復旧させることを目的とする。例えば、本発明は、中継装置が扱う全セッションというよりある特定のセッションに着目し、この情報のみを読み込むことでシステムの復旧時間を短縮することを目的とする。また、本発明は、テキストベースのジャーナルファイルを読み込む方法を採用し、ＳＩＰサーバソフトウェアのバージョンやＳＩＰサーバの種類に依存することが少ないシステム及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
ＳＩＰサーバをコールドスタンバイ方式で構築し、外部記憶装置内にジャーナルファイルと呼救済対象リストを作成しておき、ＳＩＰメッセージの共通ヘッダにあるＣａｌｌ−ＩＤをキーとしてＳＩＰメッセージを待機系に入力することで該当するセッションの状態を復旧し、通信の信頼性を確保する。
【００１０】
本発明の中継装置は、ＳＩＰメッセージを中継する中継処理部と、再開処理を行う再開処理部と、監視制御を行う監視制御部とを備える。中継処理部は、セッション状態を管理、更新する状態管理部と、ＳＩＰメッセージの送受信処理及びメッセージ変換処理を行うＳＩＰプロトコル制御部とを有する。再開処理部は、ログファイルから呼救済処理を行うログだけを作成したファイル（以下、ジャーナルファイル）を受信するジャーナルファイル送受信部と、それを変換するメッセージ作成部とを有する。ネットワークに接続された二つの端末が中継装置となるＳＩＰサーバ経由でセッションを張る場合、中継装置はＳＩＰに関するログを外部記憶装置に掃きだし（出力し）ておくことで、中継装置を経由する全てのメッセージを外部記憶装置内に記録する。本発明の外部記憶装置は、メッセージのログを蓄積するログファイルと、救済すべきセッションを示す呼救済対象リストとを有する。
【００１１】
運用中に現用系の中継装置（ＳＩＰサーバ）が何らかの原因で障害となった場合、外部記憶装置内にあらかじめ登録した呼救済対象リストに基づいて、記録されたメッセージのうち救済するべき対象となるセッション情報を、待機系中継装置内の中継処理部が読み込む。これにより中継装置の状態を復元する。尚、どのセッションを救済するかは外部記憶装置内に登録される呼救済対象リストに応じて決定されるが、これは特定の発信端末、特定の着信端末、特定のアプリケーションやこれらの組み合わせによって選択することが可能である。
【００１２】
本発明の第１の解決手段によると、
端末間でネットワークを介して送受信されるメッセージを中継して該端末間のセッションを管理する、現用系としての第１の中継装置と、
端末間でネットワークを介して送受信されるメッセージを中継して該端末間のセッションを管理するための、コールドスタンバイで待機する待機系としての第２の中継装置と、
前記第１の中継装置により中継されるメッセージのメッセージログを記憶し、待機系から現用系へ切り替えられた前記第２の中継装置に該メッセージログを出力する記憶装置と
を備え、
前記第１の中継装置は、中継されるメッセージのメッセージログを前記記憶装置に出力し、
前記記憶装置は、
前記第１の中継装置から受信されたメッセージログが記憶されるログ保存部と、
障害時に接続状態を復元する呼又はセッションを示す呼救済対象識別子が予め記憶される呼救済対象リスト保存部と、
前記ログ保存部に記憶されたメッセージログから、前記呼救済対象リスト保存部に記憶された呼救済対象識別子が含まれるメッセージログを抽出するファイル作成部と、
抽出されたメッセージログを前記第２の中継装置に送信する送信部と
を有し、
前記第２の中継装置は、
入力されるメッセージに応じた処理を実行し、端末を相互に接続する中継処理部と、
前記第１の中継装置の障害を検出して、自装置を待機系から現用系へ切り替える監視制御部と、
抽出されたメッセージログを前記記憶装置から受信し、メッセージログ又はメッセージログに基づく情報を前記中継処理部に出力する再開処理部と
を有し、
前記中継処理部は、前記再開処理部から入力したメッセージ又は情報に応じた処理を実行して、前記第１の中継装置での接続状態を復元する中継システムが提供される。
本発明の第２の解決手段によると、
端末間でネットワークを介して送受信されるメッセージを中継して該端末間のセッションを管理する、現用系としての第１の中継装置は、中継されるメッセージのメッセージログを出力し、
第１の中継装置からのメッセージログを記憶し、
第１の中継装置の障害を検出して、コールドスタンバイで待機する待機系としての第２の中継装置を待機系から現用系へ切り替え、
記憶されたメッセージログから、障害時に接続状態を復元する呼又はセッションを示す予め記憶された呼救済対象識別子が含まれるメッセージログを抽出し、
抽出されたメッセージログを第２の中継装置へ出力し、
第２の中継装置が、抽出されたメッセージログを受信し、メッセージログ又はメッセージログに基づく情報に応じた処理を実行して、第１の中継装置での接続状態を復元する呼救済方法が提供される。
【発明の効果】
【００１３】
本発明によると、コストの安いコールドスタンバイをベースとして、システムの停止時間を短縮するための中継システムおよび呼救済方法を提供することができる。また、本発明によると、ＳＩＰサーバ固有の特性に着目することによって既に確立されたセッション状態の復元時間を高速化することでシステム全体の停止時間を短縮することができる。
【００１４】
本発明によると、ＳＩＰサーバの障害時のセッション情報の復旧を高いコストパフォーマンスで実現する手段を提供することができる。本発明によると、特殊なハードウエアやソフトウエアを用いる従来のホットスタンバイ方式に比べると安価に、かつ、従来のコールドスタンバイ方式における現用系装置の全メモリのバックアップ方式に比べると、高速にセッション情報を復旧させることが可能となる。これは、中継装置が扱う全セッションというよりある特定のセッションに着目し、この情報のみを読み込むことでシステムの復旧時間を短縮することが可能となるためである。また、本発明によると、テキストベースのジャーナルファイルを読み込む方法を採用しているため、ＳＩＰサーバソフトウェアのバージョンやＳＩＰサーバの種類に依存することが少ない利点がある。
【発明を実施するための最良の形態】
【００１５】
図１は、ＳＩＰサーバを用いたセッション確立〜データ通信〜セッション開放までのシーケンス図である。まず、端末Ａと端末Ｂが中継装置を介して通信する時の動作について図１を参照して説明する。
【００１６】
端末Ａと端末Ｂは、各々ネットワークに接続された時、中継装置（例えば、ＳＩＰサーバ）に対して自分の位置を登録するＲＥＧＩＳＴＥＲメッセージ１０１、１０２を送信する。中継装置１が、ＲＥＧＩＳＴＥＲメッセージを受け付けると、２００  ＯＫメッセージ１０３、１０４を返信する。その後、端末Ａが端末Ｂと通信をする時に、端末ＡはＩＮＶＩＴＥメッセージ１０５を中継装置１に送信し、中継装置１は端末Ｂと接続中であることを示す１００  Ｔｒｙｉｎｇ１０６を端末Ａに返信した後、中継装置１はＩＮＶＩＴＥ  １０７を端末Ｂに中継する。
【００１７】
端末Ｂは、中継装置１と接続中であることを示す１００  Ｔｒｙｉｎｇメッセージ１０８を返す。ＩＮＶＩＴＥメッセージ１０７を受信した端末Ｂは、通信ができる状態なら２００  ＯＫ１０９という応答を中継装置１に戻し、このメッセージは端末Ａに中継される。端末Ａは、２００  ＯＫ１１０の受信を待ってＡＣＫメッセージ１１１、１１２を中継装置１経由で端末Ｂに送信し、この結果として端末Ａと端末Ｂの間にセッションが張られることになる。この後、端末Ａ−端末Ｂ間ではＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）を用いた双方向のデータ通信が行われる。データ通信は端末間で行われるため中継装置１は転送に関与しない。
【００１８】
通信が終了する場合は、端末ＡまたはＢからＢＹＥメッセージ１１３が送信され、中継装置１はＢＹＥメッセージ１１４を転送し、一方の端末からの２００  ＯＫメッセージ１１５、１１６によってセッションは終了となる。端末Ａ、端末Ｂのデータのやりとりは、ＩＮＶＩＴＥ１０７、２００  ＯＫ１０９、ＡＣＫ１１２それぞれでネゴシエートした通信方式、ＩＰアドレスが用いられる
【００１９】
図２は、ＳＩＰメッセージにおけるヘッダ情報の例を示す図である。
端末と中継装置１間でやり取りされる各種のＳＩＰメッセージの先頭にあるＳＩＰヘッダの構成についてその代表例を図２で説明する。ＳＩＰヘッダは、例えば、図２に示すようにリクエストが送信された経路を示すＶｉａ、リクエストの生成元を示すＦｒｏｍ、リクエストの着信先を示すＴｏ、一つのセッションを識別するＣａｌｌ−ＩＤ、の他トランザクション毎にインクリメントされるＣＳｅｑ、ＳＩＰ  ＵＲＩの情報を示すＣｏｎｔａｃｔ、ボディ部のメディアタイプやそのサイズを示すＣｏｎｔｅｎｔ−ＴｙｐｅやＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ等を含む。
【００２０】
図３は、システム構成図である。
中継システムは、現用系としての中継装置（第１の中継装置）１１と、待機系又は予備系としての中継装置（第２の中継装置）１２と、外部記憶装置２とを備える。中継装置１１及び中継装置１２は、それぞれ外部記憶装置２と接続される。また、中継装置１１及び中継装置１２は、端末Ａ３、Ｂ４間の通信を中継する。中継装置としては、例えば、ＳＩＰサーバを用いることができる。なお、ネットワークには、適宜ルータ５等が備えられてもよい。なお、中継装置１２は、例えば、コールドスタンバイ方式で待機する。
【００２１】
中継装置は、ネットワークに接続された複数の端末を相互に接続するための２つの中継装置であり、第１の中継装置１１は端末からのメッセージログを外部記憶装置２に出力し、第２の中継装置１２は外部記憶装置２からの特定のメッセージログに基づいて端末との接続状態を復元する。特定のメッセージログとは、例えば、ＳＩＰヘッダのＣａｌｌ−ＩＤをキーとして検索された一連のデータ系列である。
【００２２】
ネットワークに接続された二つの端末Ａ３と端末Ｂ４が中継装置（ＳＩＰサーバ）経由でセッションを張る場合、中継装置１１はＳＩＰに関するログを外部記憶装置２に出力しておく。これにより中継装置１１を経由する全てのメッセージは外部記憶装置２に記録されることとなる。運用中に中継装置１１が何らかの原因で障害となった場合、中継装置１１内にある運用中のセッション情報は失われることとなるが、これを上記の外部記憶装置２を用いて復元する。復元の方法については後述する。
【００２３】
図４〜図７に中継装置の機能ブロックを示す。中継装置の詳細について以下に示す。
中継装置は、ＳＩＰメッセージ中継処理を行う中継処理部１Ａと、再開制御処理、ジャーナルファイル変換処理を行う再開処理部１Ｂと、現用待機監視処理を行う監視制御部１Ｃとを備える。中継装置１の中継処理部１Ａは、例えば図５に示すように、セッション状態を管理する状態管理部１Ａ１と、ＳＩＰメッセージ変換、送受信処理を行うＳＩＰプロトコル制御部（プロトコル制御部）１Ａ２とを備える。また、中継装置１の再開処理部１Ｂは、例えば図６に示すように、メッセージ作成部１Ｂ１と、ジャーナルファイル送受信部（受信部）１Ｂ２とを備える。中継装置１の監視制御部１Ｃは、例えば、図７に示すように、監視プログラム送信部１Ｃ１と、タイマ制御部１Ｃ２と、現用待機切替部１Ｃ３とを備える。中継装置１が障害と判断する際は監視制御部１Ｃで判断する。また、中継装置１は、適宜メモリを有することができる。
【００２４】
中継装置１１は、複数の端末をネットワークを介して相互に接続するための装置であり、現用系として動作する。中継装置１２は、複数の端末をネットワークを介して相互に接続するための装置であり、待機系又は予備系として中継装置１１の障害に備える。例えば、中継装置１２はコールドスタンバイで待機する。
【００２５】
中継処理部１Ａは、入力されるメッセージに応じた処理を実行し、端末を相互に接続する。監視制御部１Ｃは、現用系の中継装置の障害を検出して、自中継装置を待機系から現用系へ切り替える。再開処理部１Ｂは、監視制御部１Ｃにより現用系へ切り替えられると、抽出されたメッセージログを外部記憶装置２から受信し、メッセージログ又はメッセージログに基づく情報（例えば、メッセージログに基づくＳＩＰメッセージ構造体、イベント等）を中継処理部１Ａに出力し、出力したメッセージ又は情報に応じた処理を中継処理部１Ａに実行させて、中継装置１１での接続状態を復元させる。
【００２６】
図８は、外部記憶装置の機能ブロックを示す図である。
外部装置記憶装置２は、例えば図８に示すように、ジャーナルファイル作成部２Ａと、呼救済対象リスト保存部２Ｂと、ログ保存部２Ｃと、ジャーナルファイル送受信部２Ｄとの４ブロックを備える。
【００２７】
外部記憶装置２は、中継装置１１のメッセージログを保存し、中継装置１２が待機系から現用系へ切り替わる際に該メッセージログを中継装置１２へ出力する。なお、本実施の形態では、記憶装置を中継装置の外部に設けているが、中継装置１１及び１２のいずれかの内部の記憶装置を用いるなど、適宜の場所にあってもよい。
【００２８】
ログ保存部２Ｃは、中継装置１１と端末との間で送受信されるメッセージログ（通信ログ）が記憶される。呼救済対象リスト保存部２Ｂは、接続状態を復元する呼又はセッションを示す呼救済対象識別子が予め記憶される。ジャーナルファイル作成部２Ａは、ログ保存部２Ｃに記憶されたメッセージログから、呼救済対象リスト保存部２Ｂに記憶された呼救済対象識別子のメッセージログを抽出したジャーナルファイルを作成する。ジャーナルファイル送信部２Ｄは、抽出されたメッセージログ（ジャーナルファイル）を送信する。
【００２９】
全体のシステム構成としては、図３に示すようにネットワークに接続された端末Ａ３、端末Ｂ４に対して、センタ側では同一ＬＡＮに収容された２つの中継装置１１（現用系）と中継装置１２（待機系）をコールドスタンバイ方式で配備しておき、ログファイルと呼救済対象リストを持つ外部記憶装置２を共有ディスクとして２つの中継装置１１及び１２に接続する。通常の運用時は、中継装置１から外部記憶装置２のログファイルに対してセッションの確立や切断のために端末とやりとりするＳＩＰメッセージのログを出力しておく。また、運用中は、現用系と待機系の動作をモニターするために２つの中継装置１１及び１２上で動作する監視プログラムによって、相手中継装置の動作状態を監視しておく。現用系の中継装置１１の障害が検出され、処理が続行できなくなった時点で待機系の中継装置１２が現用系として切り替わり、外部記憶装置２に対して内部に登録された呼救済対象リストに示されるセッションに関する一連のログの出力を要求し、中継装置１２の中で該当するセッション情報の復元が実行される。あるいは、現用系装置１１から出力されるセッションログのうち呼救済対象リストに示されるセッションについては直ちに待機系の装置１２にログ情報を入力することで、待機系装置に現用系と同一のセッション状態を再生しておくことで現用系装置の障害時に対する普及時間の短縮を図ることも可能である。
【００３０】
図１０は、中継装置（現用）１１から中継装置（待機）１２に切り替わる際の概略処理シーケンス図である。各処理の詳細については後述する。
中継装置（待機系）１２は、監視メッセージを中継装置（現用系）１１に対して送信し（処理１２１）、監視メッセージに対する応答が所定時間内に返信されない場合、タイムアウト１２２の契機により現用、待機の切替を行う。次に、待機系の中継装置１２は、ジャーナルファイル読み込み要求を外部記憶装置２に送信する（処理１２３）。外部記憶装置２は、読み込み要求受付を送信した後（処理１２４）、その時点で保持しているログファイルを読み込み、呼救済対象ログのみを抽出したジャーナルファイルを作成する。外部記憶装置２は、ジャーナルファイルを待機系の中継装置１２に対して送信する（処理１２５）。待機系の中継装置２は、状態復元処理を行い、復元完了メッセージを送信して（処理１２６）待機系への切り替わり完了とする。
【００３１】
図１１は、上述の図１０の監視メッセージの送信（処理１２１）から待機、現用切り替わり処理までのシーケンスを詳細フロー化したものである。
中継装置１２は、監視プログラムを監視プログラム送信部１Ｃ１から送信する（処理１３２、図１０の処理１２１に相当）。なお、監視プログラム以外にも、監視メッセージ、監視信号等適宜の形式のデータを送信してもよい。また、タイマ制御部１Ｃ２により、タイマセット処理を行う（処理１３３）。
【００３２】
中継装置１２は、監視メッセージに対する応答をタイマ中（所定時間内）に受信するかどうか判定する（処理１３４）。例えば、中継装置１２は、所定時間内に応答メッセージを受信した場合（ＹＥＳ）は、中継装置１１が生存している（正常に動作している）ものとみなし、監視プログラム送信（処理１３２）からの処理を繰り返す。一方、処理１３４で所定時間内に応答メッセージを受信できなかった場合（ＮＯ）、待機から現用状態への切替処理を現用待機切替制御部１Ｃ３により行い（処理１３５）、待機系の中継装置（自中継装置）を現用系の中継装置として動作させる。また、中継装置１２は、読み込み要求を外部記憶装置２に送信する（処理１３６）。
【００３３】
図１２は、図１０の読み込み要求（処理１２３）からジャーナルファイル送信（処理１２５）までの詳細フローを示した図である。また、図９に、ジャーナルファイル作成処理の概要説明図を示す。
外部記憶装置２は、読み込み要求を受信すると（処理１４１）、呼救済対象リスト保存部２Ｂで保存している呼救済対象リスト２２（後述の図１４）を読み込み、メモリ上に展開する（処理１４２）。また、外部記憶装置２は、ログ保存部２Ｃにて保存している通信ログ２３を読み込む（処理１４３）。外部記憶装置２は、通信ログ２３が呼救済対象リストにヒットするかどうかをジャーナルファイル作成部２Ａにより判定する（処理１４４）。呼救済対象リスト２２は、救済するセッション情報を予め選択できるようにするためのものであり、選択にあたってはセッションをユニークに指定する。例えば、図２で述べたＳＩＰヘッダの中のＣａｌｌ−ＩＤをキーとし、例えば、ジャーナルファイル作成部２Ａは、ログ保存部２Ｃに記憶されたメッセージログのＣａｌｌ−ＩＤと、呼救済対象リスト保存部に２Ｂ記憶されたＣａｌｌ−ＩＤとが一致するメッセージログを抽出することができる。
【００３４】
外部記憶装置２は、通信ログ２３が呼救済対象リストにヒットする場合（処理１４４）、ヒットした通信ログをジャーナルファイルに書き込む（処理１４５）。一方、外部記憶装置２は、通信ログ２３が呼救済対象リストにヒットしない場合、処理１４６に移る。処理１４６では、外部記憶装置２は、全ログファイルについての判定が完了したか判断する。例えば、ログファイルを先頭からサーチして処理１４４の判定をしていき、ログファイルが残っていなければ全ログファフィルについて判定が完了したと判断し（処理１４６ではＹＥＳ）、一方、ログファフィルが残っていれば未完了（処理１４６ではＮＯ）と判断できる。外部記憶装置２は、全ログファフィルについて判定が完了したと判断すると（処理１４６：ＹＥＳ）、ジャーナルファイル作成部２Ａに書き込まれたジャーナルファイルを、ジャーナルファイル送信部２Ｄを介して中継装置１２に送信する（処理１４７）。一方、外部記憶装置２は、全ログファフィルについて判定が完了していないと判断すると（処理１４６：ＮＯ）、処理１４４に移り、以降の処理を繰り返す。
【００３５】
図１３に、通信ログ２３の具体的な記述例を示す。ログファイルは、ＳＩＰサーバから出力されたＳＩＰメッセージをそのまま保存しており、例えば、図２で示すＳＩＰヘッダの構成を含むものである。図１３中のＣａｌｌ−ＩＤは、一つのセッションに対してユニークにアサインされる（一意に割り当てられる）。
【００３６】
図１４に、呼救済対象リストの例を示す。図１４中のＣａｌｌ−ＩＤ例えば「１２３４５６＠１９２．１６８．０．１」に基づき通信ログを参照し、該当するＣａｌｌ−ＩＤを含む通信ログ２３をすべて抽出する。該当ログにヒットしないものについては抽出しない。また、Ｃａｌｌ−ＩＤの一部に「＠１９２．１６８．０．１」を含むものを全て抽出することもできる。
【００３７】
図１５に、ジャーナルファイル作成方法の概要を示す。このとき同一のＣａｌｌ−ＩＤで検索できるログ情報は、セッション情報の場合は以下のとおりとなる（以下、同一Ｃａｌｌ−ＩＤ情報と呼ぶ）。例えば、図１に示す処理の各情報である。なお、図１５の通信ログ、ジャーナルファイルには、便宜上、リクエストの種類（メソッド名）とＣａｌｌ−ＩＤのみを示している。
端末ＡからのＲＥＧＩＳＴＥＲ受信
端末Ａへの２００  ＯＫ
端末ＢからのＲＥＧＩＳＴＥＲ受信
端末Ｂへの２００  ＯＫ
端末ＡからのＩＮＶＩＴＥ受信
端末Ａへの１００  Ｔｒｙｉｎｇ送信
端末ＢへのＩＮＶＩＴＥ送信
端末Ｂからの１００  Ｔｒｙｉｎｇ受信
端末Ｂからの２００  ＯＫ受信
端末Ａへの２００  ＯＫ送信
端末ＡからのＡＣＫ受信
端末ＢへのＡＣＫ送信
端末ＡからのＢＹＥ受信
端末ＢへのＢＹＥ送信
端末Ｂからの２００  ＯＫ受信
端末Ａへの２００  ＯＫ送信
【００３８】
通信ログのＣａｌｌ−ＩＤが、呼救済対象リスト２３に一致するかどうかの判定処理を行い、一致する場合、該当する同一Ｃａｌｌ−ＩＤ情報をジャーナルファイルに書き込むことになる。外部記憶装置２は、図８のジャーナルファイル作成をどのタイミングでも行うことができ、運用中に予め行っておくことで待機系復旧時の時間短縮が可能である。
【００３９】
図１６に、図１０のジャーナルファイル送信（処理１２５）から復元完了（処理１２６）までの処理フローを示す。
まず、外部記憶装置２のジャーナルファイル送信部２Ｄからジャーナルファイルを送信する処理を行う（処理１５１）。中継装置１の再開処理部は、中継装置１２が既存のＳＩＰメッセージの受信ルートを併用できるようにジャーナルファイルを展開する（処理１５２）。
【００４０】
図１７は、中継装置の受信処理の説明図である。図１８は、中継処理部のメモリマップである。また、図１９は、イベント１Ａ３の構成例である。再開処理の説明の前に中継装置の受信処理概要について、図１７〜図１９を参照して説明する。
ＳＩＰパケット３１が、例えば端末Ａ３からルータ（Ｒｏｕｔｅｒ）５を経由して中継装置１に中継される場合、中継装置１は、ＳＩＰパケット３１をＳＩＰプロトコル制御部１Ａ２の送受信処理部１Ａ２２で受信する。また、メッセージ変換部１Ａ２１は、受信したＳＩＰパケット３１をＳＩＰメッセージ構造体（後述の図２３）として保持する。また、ＳＩＰメッセージ構造体として保持した情報を状態管理部１Ａ１に、例えばイベントとして通知する。
【００４１】
図２３は、本実施の形態におけるＳＩＰメッセージ構造体の説明図である。ＳＩＰメッセージ構造体は、例えば、Ｒｅｑｕｅｓｔ−ＵＲＩ１Ｂ２１、Ｆｒｏｍ１Ｂ２２、Ｔｏ１Ｂ２３、再開ｆｌａｇ（再開フラグ）１Ｂ２４を含む。また、これら以外にも、ＳＩＰメッセージに基づく適宜の情報を含むことができる。Ｒｅｑｕｅｓｔ−ＵＲＩ１Ｂ２１、Ｆｒｏｍ１Ｂ２２、Ｔｏ１Ｂ２３、は、受信されたパケットに含まれる情報が用いられる。再開ｆｌａｇ１Ｂ２４は、接続状態を復元するための情報か又は運用中の情報かのいずれかを示す。通常の運用中は、再開ｆｌａｇ１Ｂ２４のフラグは立てない。後述する中継装置１の再開処理部１Ｂで生成するＳＩＰパケット（メッセージ）のＳＩＰメッセージ構造体１Ｂ２においては、再開ｆｌａｇ１Ｂ２４にビットを立てて、再開用メッセージであることを意識付けする。また、ＳＩＰメッセージ構造体は、図１８のように中継装置のＳＩＰプロトコル制御部のメモリマップ上に存在する。
【００４２】
図１９に、イベント処理内容を示す。イベント処理内容は、例えば、ＳＩＰメッセージ構造体のアドレス１Ａ３１１と、受信ＩＰアドレス１Ａ３２２と、送信元ＩＰアドレス１Ａ３１３とを含む。図１９の例では、ＳＩＰメッセージ構造体のメモリのアドレス１Ａ３１１（０ｘ１２３４５６７８）をイベント１Ａ３で通知する。また、受信ＩＰアドレス１Ａ３２２には中継装置１のレイヤ３  ＩＰアドレス（１９２．１６８．１０．１）を保持し、送信元ＩＰアドレスには端末Ａ３のレイヤ３  ＩＰアドレス（１９２．１６８．２００．２２０）を保持する。これらのアドレスは、例えばＳＩＰパケットのヘッダから得ることができる。受信ＩＰアドレス、送信元ＩＰアドレスをイベント１Ａ３として通知する理由は、例えば、中継装置がレイヤ３  ＩＰアドレス情報と図２のＳＩＰヘッダ中のＣｏｎｔａｃｔにふくまれるＩＰアドレス情報とを見ることによりＩＰアドレス詐称を検知するためである。
【００４３】
受信したイベントを状態管理部１Ａ１で刈り取り（入力し）、状態更新処理を行った後に次に行うアクションを決定し、イベントを登録する。例えば、イベントをキューに出力する。ＳＩＰプロトコル制御部１Ａ２は、イベントを刈り取り（入力し）、メッセージ変換部１Ａ２１によりＳＩＰメッセージ構造体に再開ｆｌａｇ１Ｂ２４にビットが立っていないことを確認し、ＳＩＰパケット３１に変換する。その後、送受信処理部１Ａ２２によりＳＩＰパケット３１を送信する。
【００４４】
図２０は、中継装置での再開処理概要の説明図である。図２１は、中継処理部のメモリマップである。また、図２２は、再開処理部から状態管理部へ渡すイベントの構成例である。上述の中継装置の受信処理概要を踏まえて、図１６、図２０〜図２２を参照して中継装置の再開処理について説明する。
【００４５】
外部記憶装置２は、作成したジャーナルファイル２１を中継装置に送信し（図１６のジャーナルファイル送信１５１、図１０の処理１２５に対応）、中継装置では、再開処理部１Ｂのメッセージ作成部１Ｂ１でＳＩＰメッセージ構造体で保持する。メッセージ作成部１Ｂ１は、上述の図１７のＳＩＰプロトコル制御部１Ａ２のメッセージ変換部１Ａ２１と同等の機能を有するものである。また、再開処理部１ＢのＳＩＰメッセージ構造体は、前述のものと同様に図２１のように中継処理部のメモリマップ上に存在する。再開処理部１Ｂでは、ジャーナルファイル２１をＳＩＰメッセージ構造体１Ｂ２として保持する際、再開ｆｌａｇ  １Ｂ２４にビットを立てる。
【００４６】
再開処理部１Ｂは、ＳＩＰメッセージ構造体のアドレスを状態管理部１Ａ１へのイベント１Ａ４として登録する（図１６：イベント受信１５３）。図２２に、イベント１Ａ４のイベント内容を示す。イベント１Ａ４は、ＳＩＰメッセージ構造体アドレス１Ａ４１と、受信ＩＰアドレス１Ａ４２（１９２．１６８．１０．１）と、送信元ＩＰアドレス１Ａ４３（１９２．１６８．２００．２２０）とを含む。登録したイベント１Ａ４は、状態管理部１Ａ１が刈り取り（入力し）、状態更新（図１６の状態更新１５４）を行った後、次に行うアクションを決定し、イベント１Ａ５を登録する（図１６のイベント送信１５５）。
【００４７】
ＳＩＰプロトコル制御部１Ａ２で受け取ったイベント１Ａ５のアドレスに従い、メッセージ変換部１Ａ２１によりＳＩＰメッセージ構造体からＳＩＰパケットに変換して図１６のＳＩＰメッセージ送信を行おうとするが、再開ｆｌａｇ１Ｂ２４にビットが立っているため、ＳＩＰパケットには変換せずそのまま破棄する（処理１５６）。すなわち、ＳＩＰプロトコル制御部１Ａ２は、ＳＩＰメッセージ構造体の再開ｆｌａｇ１Ｂ２４を参照し、フラグが立っていなければＳＩＰメッセージ構造体をＳＩＰパケットに変換して送信し、一方、フラグが立っていればＳＩＰパケットに変換せず破棄する。これによりＳＩＰパケットを外に飛ばさず、状態更新だけを行うようにする。
【００４８】
上記の処理により、待機系の中継装置２にはあらかじめ指定されたＣａｌｌ−ＩＤを持つセッションが復元することが可能となる。なお、中継装置１２は、中継装置１１と並行して動作してもよく、中継装置１１の障害時にセッションの高速引継ぎが可能となる。
【産業上の利用可能性】
【００４９】
本発明は、ＳＩＰプロトコルを用いるＶｏＩＰサービス、インスタントメッセージングサービス等のリアルタイムコラボレーションサービスを実現するための装置・システムに適用することが可能である。接続される端末や適用するサービスの種類に応じてセッションの復元時間を高速化することができるようになる。
【図面の簡単な説明】
【００５０】
【図１】ＳＩＰサーバを用いたセッション確立〜データ通信〜セッション開放までのシーケンス図。
【図２】ＳＩＰメッセージにおけるヘッダ情報の例を示す図。
【図３】システム構成図。
【図４】中継装置機能ブロック。
【図５】中継処理部機能ブロックを示す図。
【図６】再開処理部機能ブロックを示す図。
【図７】監視制御部機能ブロックを示す図。
【図８】外部記憶装置機能ブロックを示す図。
【図９】外部記憶装置処理概要を示す図。
【図１０】障害検知から復元完了までの処理シーケンス図。
【図１１】障害検知の処理フローを示す図。
【図１２】ジャーナルファイル作成の処理フローを示す図。
【図１３】通信ログの例。
【図１４】呼救済対象リストの例。
【図１５】ジャーナルファイル作成を示す図。
【図１６】中継装置でのジャーナルファイル受信から復元完了までの処理シーケンス図。
【図１７】中継装置のＳＩＰパケット受信処理概要を示す図。
【図１８】中継装置ＳＩＰプロトコル制御部メモリマップ。
【図１９】ＳＩＰプロトコル制御部から状態管理部へ渡すイベント内容。
【図２０】中継装置での再開処理概要を示す図。
【図２１】中継処理部のメモリマップ。
【図２２】再開処理部から状態管理部へ渡すイベント内容。
【図２３】ＳＩＰメッセージ構造体。
【符号の説明】
【００５１】
１１  中継装置（現用系）
１２  中継装置（待機系）
２  外部記憶装置
１Ａ  中継処理部
１Ｂ  再開処理部
１Ｃ  監視制御部
１Ａ１  状態管理部
１Ａ２  ＳＩＰプロトコル制御部
１Ｂ１  メッセージ作成部
１Ｂ２  ジャーナルファイル送受信部
１Ｃ１  監視プログラム送信部
１Ｃ２  タイマ制御部
１Ｃ３  現用待機切替部
２Ａ  ジャーナルファイル作成部
２Ｂ  呼救済対象リスト保存部
２Ｃ  ログ保存部
２Ｄ  ジャーナルファイル送受信部
【図１】
0004425841.tif 000002
【図２】
0004425841.tif 000003
【図３】
0004425841.tif 000004
【図４】
0004425841.tif 000005
【図５】
0004425841.tif 000006
【図６】
0004425841.tif 000007
【図７】
0004425841.tif 000008
【図８】
0004425841.tif 000009
【図９】
0004425841.tif 000010
【図１０】
0004425841.tif 000011
【図１１】
0004425841.tif 000012
【図１２】
0004425841.tif 000013
【図１３】
0004425841.tif 000014
【図１４】
0004425841.tif 000015
【図１５】
0004425841.tif 000016
【図１６】
0004425841.tif 000017
【図１７】
0004425841.tif 000018
【図１８】
0004425841.tif 000019
【図１９】
0004425841.tif 000020
【図２０】
0004425841.tif 000021
【図２１】
0004425841.tif 000022
【図２２】
0004425841.tif 000023
【図２３】
0004425841.tif 000024