JP4491403B2 - システム復旧方法 - Google Patents

Description

本発明は、システム復旧方法に関し、特にＶｏＩＰシステムにおけるシステム復旧方法に関する。

ＩＰネットワークを利用した通話を行うための基盤技術としてＶｏＩＰ（Voice over Internet Protocol）が存在する。ＶｏＩＰによるシステムは、リアルタイム性が強く要求されるため、他のコンピュータシステムと同様に冗長化が図られている。

図１は、ＶｏＩＰ冗長化システムの基本構成例を示す図である。図１のＶｏＩＰ冗長化システム５００において、コールマネージャ５１０Ｐ、コールマネージャ５１０Ｓ、複数のＩＰ電話機５２０、及びＶｏＩＰゲートウェイ５３０等は、有線又は無線のＩＰ（Internet Protocol）ネットワーク５４０を介して接続されている。ＶｏＩＰ冗長化システム５００は、また、ＶｏＩＰゲートウェイ５３０を介して公衆キャリア網５５０に接続されている。

コールマネージャ５１０Ｐは、プライマリのコールマネージャであり、コールマネージャ５１０Ｓは、セカンダリのコールマネージャである。すなわち、通常はコールマネージャ５１０Ｐが起動系であり、コールマネージャ５１０Ｓはスタンバイ系である。コールマネージャ５１０Ｐに異常が発生した際に、コールマネージャ５１０Ｓが起動系となり、システム全体のダウンを回避する。

ところで、一般的にＶｏＩＰシステムにおいては、ＩＰ電話機から定期的にそのロケーション情報が起動系のコールマネージャに送信され、登録されている。ここで、ロケーション情報とは、例えば、当該ＩＰ電話機の電話番号及びＩＰアドレス等を含む情報であり、コールマネージャは、登録されたロケーション情報に基づいて、呼制御を行う。

図２は、従来のロケーション情報の通知処理を説明するためのシーケンス図である。

通常運用時は、ステップＳ１００１からステップＳ１００４に示されるように、定期的にＩＰ電話機５２０からプライマリのコールマネージャ５１０Ｐに対してロケーション情報の登録要求が行われ（Ｓ１００１、Ｓ１００３）、その登録要求に対する応答がコールマネージャ５１０Ｐより返信される（Ｓ１００２、Ｓ１００４）。

コールマネージャ５１０Ｐに障害が発生すると、起動系がコールマネージャ５１０Ｐからコールマネージャ５１０Ｓに切り替わる（Ｓ１００５）。

ＩＰ電話機５１０は、ロケーション情報の通知に対する応答が無いことでコールマネージャ５１０Ｐの障害を検出し（Ｓ１００６、Ｓ１００７）、ロケーション情報の送信先をコールマネージャ５１０Ｓに切り替える。その後、コールマネージャ５１０Ｐが復旧されるまで、コールマネージャ５１０Ｓに対してロケーション情報の登録要求が行われ（Ｓ１００８、Ｓ１０１０）、その登録要求に対する応答がコールマネージャ５１０Ｓよりなされる（Ｓ１００９、Ｓ１０１１）。

起動系となったセカンダリのコールマネージャ５１０Ｓは、コールマネージャ５１０Ｐの障害発生後に受信したロケーション情報に基づいて、呼制御を行う。
特開平１１−８８３５３号公報

しかしながら、上述のように従来のＶｏＩＰ冗長化システムでは、通常運用時はプライマリのコールマネージャのみがロケーション情報を保持管理しているため、プライマリのコールマネージャの障害により、起動系がセカンダリのコールマネージャに切り替わった時点では、セカンダリのコールマネージャは、ロケーション情報を保持していない。したがって、セカンダリのコールマネージャが各ＩＰ電話機のロケーション情報の登録を完了するまではある程度の時間を要し、その間、一時的な停止状態が発生し得るという問題があった。

かかる様子を図示したのが、図３である。図３は、従来のコールマネージャの自動切り替え時の問題点を説明するための図である。

（Ａ）に示されるように、通常運用時は、ＩＰ電話機５２０よりロケーション情報の登録要求がプライマリのコールマネージャ５１０Ｐになされ（ａ１）、それに対する応答がコールマネージャ５１０Ｐよりなされる（ａ２）。また、セカンダリのコールマネージャ５１０Ｓは、死活監視メッセージをコールマネージャ５１０Ｐに送信し（ａ３）、それに対する応答があることで障害が発生していないことを確認する（ａ４）。

（Ｂ）に示されるように、コールマネージャ５１０Ｐがダウンすると、ＩＰ電話機５２０からのロケーション情報の登録要求（ｂ１）に対する応答は行われない。これによって、ＩＰ電話機５２０は、コールマネージャ５１０Ｐのダウンを検出する。また、コールマネージャ５１０Ｓからの死活監視メッセージ（ｂ２）に対する応答も行われない。これによって、コールマネージャ５１０Ｓは、プライマリのダウンを検出し、自らが起動系となる。

（Ｃ）に示されるように、コールマネージャ５１０Ｐのダウンを検出した各ＩＰ電話機５２０は、ロケーション情報の登録要求を、新たに起動系となったコールマネージャ５１０Ｓに送信するようになり（ｃ１）、それに対する応答がコールマネージャ５１０Ｓより行われる（ｃ２）。但し、各ＩＰ電話機５２０がロケーション情報の登録要求を送信するタイミングは異なるため、コールマネージャ５１０Ｓは、全てのＩＰ電話機５２０のロケーション情報の登録を完了する前に起動系となる。

したがって、（Ｄ）に示されるように、コールマネージャ５１０Ｓは、ロケーション情報が登録されているＩＰ電話機５２０の発着信については受付可能であるが、ロケーション情報が登録されていないＩＰ電話機５２０については、着信先が分からず着信できないという状態が発生し得る。

かかる問題は、プライマリ側が復旧した場合の切り戻し時にも発生する。図４は、従来のコールマネージャの自動切り戻し時の問題点を説明するための図である。

（Ｅ）は、セカンダリのコールマネージャ５１０Ｓが、起動系となっている状態を示す。この場合、ＩＰ電話機５２０からは、コールマネージャ５１０Ｓに対してロケーション情報の登録要求が行われ（ｅ１）、それに対する応答がコールマネージャ５１０Ｓより行われる（ｅ２）。また、コールマネージャ５１０Ｓは、プライマリの復旧を検出するための死活監視メッセージをコールマネージャ５１０Ｐに送信し（ｅ３）、その応答が無いことでプライマリが復旧していないことを確認する。

（Ｆ）に示されるように、コールマネージャ５１０Ｐが復旧したとしても、ＩＰ電話機５２０は、セカンダリのコールマネージャ５１０Ｓからの応答がある限り、ロケーション情報の登録要求はセカンダリに送り続ける（ｆ１）。一方、コールマネージャ５１０Ｐは、復旧後に受信した死活監視メッセージ（ｆ２）に対して直ちに応答を返信する（ｆ３）。これによって、コールマネージャ５１０Ｓは、プライマリの復旧を検出する。

（Ｇ）に示されるように、プライマリの復旧を検出したコールマネージャ５１０Ｓは、スタンバイ状態となる。したがって、ＩＰ電話機５２０からのロケーション情報に対する応答は行われなくなる。

（Ｈ）に示されるように、コールマネージャ５１０Ｓからの応答が行われなくなると、ＩＰ電話機５２０は、ロケーション情報の送信先をコールマネージャ５１０Ｐに切り替える（ｈ１）。但し、障害発生以前に蓄積されたロケーション情報は破棄されてしまっており、また、各ＩＰ電話機５２０がロケーション情報の登録要求を送信するタイミングは異なるため、コールマネージャ５１０Ｐが、全てのＩＰ電話機５２０のロケーション情報の登録を完了するまでにはある程度の時間を要する。したがって、ロケーション情報が登録されているＩＰ電話機５２０の発着信については受付可能であるが、ロケーション情報が登録されていないＩＰ電話機５２０については、着信先が分からず着信できないという状態が発生し得る。なお、障害発生以前に蓄積されたロケーション情報が破棄されてしまうのは、障害復旧に時間を要する場合があり、復旧中のネットワーク構成の変更により、障害発生以前のロケーション情報が現在のネットワーク構成に対応しているとは限らないからである。

なお、従来のＶｏＩＰ制御装置間における他の冗長化方法としては、サーバのクラスタ制御のような技術がある。しかし、システム的に高価で、且つ、構築条件など難易度の高い設定が必要とされるという問題がある。

本発明は、上記の点に鑑みてなされたものであって、ＶｏＩＰの冗長化システムにおいてプライマリの復旧後の切り戻しを適切に行うことのできるシステム復旧方法の提供を目的とする。

そこで上記課題を解決するため、本発明は、クライアントのロケーション情報に基づいて呼制御を行うコールマネージャとして、プライマリのコールマネージャと、前記コールマネージャに対して定期的に監視メッセージを送信しその応答に基づいて前記プライマリのコールマネージャの稼動状態を監視するセカンダリのコールマネージャとを有するＶｏＩＰシステムにおけるシステム復旧方法であって、前記プライマリのコールマネージャは、障害からの復旧後、前記クライアントより送信されるロケーション情報の登録を開始し、前記復旧から所定の期間が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とする。

このようなシステム復旧方法では、プライマリの復旧後の切り戻しを適切に行うことができる。

本発明によれば、ＶｏＩＰの冗長化システムにおいてプライマリの復旧後の切り戻しを適切に行うことのできるシステム復旧方法を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図５は、本発明の実施の形態におけるＶｏＩＰ（Voice over Internet Protocol）冗長化システムの基本構成例を示す図である。

図５のＶｏＩＰ冗長化システム１において、コールマネージャ１０Ｐ、コールマネージャ１０Ｓ、複数のＩＰ電話機（ＶｏＩＰ端末）２０、及びＶｏＩＰゲートウェイ３０等は、有線又は無線のＩＰ（Internet Protocol）ネットワーク４０を介して接続されている。ＶｏＩＰ冗長化システム１は、また、ＶｏＩＰゲートウェイ３０を介して公衆キャリア網５０に接続されている。

コールマネージャ１０Ｐは、プライマリのコールマネージャ（ＶｏＩＰ制御装置）であり、コールマネージャ１０Ｓは、セカンダリのコールマネージャである。すなわち、通常はコールマネージャ１０が起動系であり、コールマネージャ１０Ｓはスタンバイ系である。コールマネージャ１０Ｐに異常が発生した際に、コールマネージャ１０Ｓが起動系となり、システム全体のダウンを回避する。なお、以下においてコールマネージャ１０Ｐ及びコールマネージャ１０Ｓを総称する場合、「コールマネージャ１０」という。

図６は、本発明の実施の形態におけるコールマネージャのハードウェア構成例を示す図である。図６のコールマネージャ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。

コールマネージャ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。

補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってコールマネージャ１０に係る機能を実行する。インタフェース装置１０５は、図５のネットワーク４０に接続するために用いられる。

次に、ＶｏＩＰ冗長化システム１の処理概要について図７及び図８を用いて説明する。図７は、本発明の実施の形態におけるＶｏＩＰ冗長化システムの処理概要を説明するための図である。また、図８は、本発明の実施の形態におけるＶｏＩＰ冗長化システムの処理概要を説明するためのシーケンス図である。なお、図７と図８とのステップ番号は対応している。

通常運用時において、各ＩＰ電話機２０は、プライマリのコールマネージャ１０Ｐのみならず（Ｓ１１、Ｓ１４）、セカンダリのコールマネージャ１０Ｓにもロケーション（レジスト）情報の登録要求を一定の周期で送信する（Ｓ１３、Ｓ１６）。したがって、本実施の形態では、プライマリ側とセカンダリ側の双方のコールマネージャ１０において、同様のロケーション情報が登録される。ここで、ロケーション情報とは、当該ＩＰ電話機の電話番号、ＩＰアドレス及び種別（ハードフォン、ソフトフォン、及び無線電話等の別）等を含む情報をいう。コールマネージャ１０は、登録されたロケーション情報に基づいて、呼制御を行う。なお、ロケーション情報の登録要求が一定の周期（例えば、数分おき）で送信されるのは、ネットワーク構成の変更等があり得ることを考慮し、最新のネットワーク構成に対応したロケーション情報を保持するためである。

ＩＰ電話機２０からのロケーション情報の登録要求に対する応答は、起動系のコールマネージャ１０Ｐのみが行う（Ｓ１２、Ｓ１５）。これによって、ＩＰ電話機２０は、コールマネージャ１０Ｐが正常に動作していることを確認する。

プライマリのコールマネージャ１０Ｐに障害が発生すると（Ｓ１７）、セカンダリのコールマネージャ１０Ｓは、その旨を検出し、起動系に切り替わる（Ｓ１８）。但し、同様のロケーション情報がプライマリ側及びセカンダリ側の双方に定期的に登録されているため、コールマネージャ１０Ｓは、起動系に切り替わると同時に適切に呼制御（発着信・通話）を行うことができる。

例えば、ＩＰ電話機２０ｂが、障害発生直後にコールマネージャ１０Ｐに対して発呼要求を行ったとする（Ｓ１９）。この場合、ＩＰ電話機２０ｂは、コールマネージャ１０Ｐからの応答が無いため、セカンダリのコールマネージャ１０Ｓに発呼迂回要求を行う（Ｓ２０）。コールマネージャ１０Ｓは、スタンバイ時に登録されているロケーション情報に基づいて着信先を特定し、ＩＰ電話機２０ａに着呼要求を行う（Ｓ２２）。それによって、ＩＰ電話機２０ａとＩＰ電話機２０ｂとの通話が可能となる（Ｓ２３）。

なお、ステップＳ１９〜Ｓ２７までのステップにおいて、ＳＩＰ（Session Initiation Protocol）に基づく一般的な処理は、明細書本文及び図７において適宜省略されている。

以下、ＶｏＩＰ冗長化システム１の処理手順について更に詳細に説明する。図９は、第一の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するための図である。第一の実施の形態では、プライマリ側に障害が発生し、起動系がプライマリ側からセカンダリ側に自動的に切り替わる際の処理を説明する。なお、図９において、クライアント２５は、ＩＰ電話機２０及びＶｏＩＰゲートウェイ３０等、コールマネージャ１０に対してクライアントとなり得るものを表現している。

（１）に示されるように、通常運用時は、クライアント２５よりロケーション情報の登録要求がプライマリのコールマネージャ１０Ｐに一定の周期で送信され（Ｓ１０１）、それに対する応答がコールマネージャ１０Ｐより返信される（Ｓ１０２）。クライアント２５は、また、セカンダリのコールマネージャ１０Ｓに対して一定の周期でロケーション情報の登録要求を送信する（Ｓ１０３）。したがって、プライマリ側及びセカンダリ側の双方のコールマネージャ１０Ｐにおいて各クライアント２５のロケーション情報が定期的に登録される。但し、コールマネージャ１０Ｓは、ロケーション情報のみを受信し、発着信要求等を受けた場合は破棄するようにする。これにより、呼制御の不一致を防止することができる。

他方において、セカンダリのコールマネージャ１０Ｓは、死活監視メッセージをコールマネージャ１０Ｐに定期的に送信し（Ｓ１０４）、それに対する応答の有無に基づいてコールマネージャ１０Ｐの稼動状態を監視する（Ｓ１０５）。

（２）に示されるように、コールマネージャ１０Ｐがダウンすると、クライアント２５からのロケーション情報の登録要求（Ｓ１０６）に対するコールマネージャ１０Ｐによる応答は行われない。これによって、クライアント２５は、コールマネージャ１０Ｐのダウンを検出する。また、コールマネージャ１０Ｓからの死活監視メッセージ（Ｓ１０８）に対する応答も行われない。これによって、コールマネージャ１０Ｓは、プライマリのダウンを検出し、自らが起動系となる。

（３）に示されるように、各クライアント２５は、コールマネージャ１０Ｐのダウンを検出した後もロケーション情報の登録要求を各コールマネージャ１０に送信し（Ｓ１０９、Ｓ１１０）、新たに起動系となったコールマネージャ１０Ｓは、クライアント２５に対する応答を返信する（Ｓ１１１）。

ところで、コールマネージャ１０Ｓではスタンバイ状態においてもロケーション情報の登録が定期的に行われているため、新たに起動系となった時点で既に各クライアント２５のロケーション情報が登録されている。

したがって、（４）に示されるように、コールマネージャ１０Ｓは、一時的な停止状態等を発生させることなく、各クライアント２５に対する呼制御を適切に行うことができる。

次に、第二の実施の形態について説明する。第二の実施の形態では、プライマリ側が復旧し、起動系がセカンダリ側からプライマリ側に自動的に切り戻される際の処理を説明する。

図１０は、第二の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するための図である。また、図１１は、第二の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するためのシーケンス図である。なお、図１０と図１１とのステップ番号は対応している。

（２１）は、プライマリのコールマネージャ１０Ｐがダウンし、セカンダリのコールマネージャ１０Ｓが起動系となっている状態を示す。この場合、クライアント２５からは、コールマネージャ１０Ｐ及びコールマネージャ１０Ｓの双方にロケーション情報の登録要求が一定の周期で行われる（Ｓ２０１，Ｓ２０２）。起動系のコールマネージャ１０Ｓは、ロケーション情報を登録後、クライアント２５に対する応答を行う（Ｓ２０３）。一方、ダウンしているコールマネージャ１０Ｐにはロケーション情報は登録されない。また、コールマネージャ１０Ｓは、プライマリの復旧を検出するための死活監視メッセージをコールマネージャ１０Ｐに定期的に送信し、その応答の有無に基づいてコールマネージャ１０Ｐの稼動状態を監視する（Ｓ２０４）。

（２２）に示されるように、コールマネージャ１０Ｐは、障害から復旧すると、クライアント２５からのロケーション情報の登録要求に応じてロケーション情報の登録を開始する（Ｓ２０５、Ｓ２０９）。但し、コールマネージャ１０Ｓからの死活監視メッセージ（Ｓ２０６）に対する応答は直ちには行わない。すなわち、各クライアント２５からのロケーション情報の登録要求のタイミングは必ずしも一致しないため、直ちに死活監視メッセージに対する応答を行ってしまうと、各クライアント２５のロケーション情報が登録される前に起動系が切り戻されてしまい、適切な呼制御を行えない可能性が高いからである。したがって、コールマネージャ１０Ｐは、所定の期間が経過するまでは、死活監視メッセージを無視し続ける。一方、コールマネージャ１０Ｓは、プライマリ側の復旧は検出せずに、起動系として各クライアント２５からのロケーション情報の登録要求（Ｓ２０７、Ｓ２１０）に対する応答や（Ｓ２０８、Ｓ２１１）、呼制御を行う。

（２３）に示されるように、コールマネージャ１０Ｐは、障害の復旧から所定の期間が経過すると死活監視メッセージ（Ｓ２１２）に対する応答を返信する（Ｓ２１３）。

（２４）に示されるように、コールマネージャ１０Ｓは、死活監視メッセージに対する応答に基づいて自らをスタンバイ系とする。これによって、起動系がコールマネージャ１０Ｐに切り戻される。したがって、以降のロケーションの登録要求（Ｓ２１４、Ｓ２１６）に対する応答や呼制御は、コールマネージャ１０Ｐが行う（Ｓ２１５）。

ところで、コールマネージャ１０Ｐが復旧してから死活監視メッセージに対して応答を行うために待ち合わせる所定の期間は、コールマネージャ１０Ｐにおいて各クライアント２５のロケーション情報の登録が完了するために十分な期間であることが望ましい。例えば、各クライアント２５からの登録要求の周期が同じ（例えば、全てのクライアント２５が５分おきに登録要求を送信する。）であれば、最初にいずれかのクライアント２５からの登録要求を受けた時点から当該周期分（例えば、５分）だけ待ち合わせればよい。または、コールマネージャ１０Ｐが、全てのクライアント２５を管理テーブル等で把握している場合は、当該管理テーブルに登録されている全てのクライアント２５のロケーション情報の登録が完了した時点で待ち合わせを終了してもよい。

したがって、起動系が切り戻された時点で、コールマネージャ１０Ｐには、各クライアント２５のロケーション情報が登録されていることとなる。よって、その後の発呼要求等に対しては、待ち合わせ期間中に登録されたロケーション情報に基づいて適切な呼制御を行うことができる（図１１：Ｓ２１７〜Ｓ２２４）。

なお、クライアント２５からの登録要求は、その後も継続的に送信されることを考慮すれば、必ずしも全てのクライアントの登録が確実に完了するまで待ち合わせる必要はなく、システムの早期復旧を優先して上記の周期とは別に定められた所定時間だけ待ち合わせるようにしてもよい。

上述したように、第二の実施の形態によれば、プライマリに切戻す際に、プライマリにロケーション情報が再登録されるまでの間、コールマネージャ間の死活監視メッセージによる切替えが抑制される。したがって、プライマリは、自動的に切戻った時点で直ちに呼制御（発着信・通話）を行うことができ、システム全体として停止状態の発生を回避することができる。

次に、第三の実施の形態について説明する。第三の実施の形態では、プライマリ側が復旧し、起動系がセカンダリ側からプライマリ側に自動的に切り戻される際の処理について第二の実施の形態とは別の例を説明する。

図１２は、第三の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するための図である。また、図１３は、第三の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するためのシーケンス図である。なお、図１２と図１３とのステップ番号は対応している。

（３１）は、プライマリのコールマネージャ１０Ｐがダウンし、セカンダリのコールマネージャ１０Ｓが起動系となっている状態を示す。この場合、クライアント２５からは、コールマネージャ１０Ｐ及びコールマネージャ１０Ｓの双方にロケーション情報の登録要求が一定の周期で行われる（Ｓ３０１，Ｓ３０２）。起動系のコールマネージャ１０Ｓは、ロケーション情報を登録後、クライアント２５に対する応答を行う（Ｓ３０３）。一方、ダウンしているコールマネージャ１０Ｐにはロケーション情報は登録されない。また、コールマネージャ１０Ｓは、プライマリの復旧を検出するための死活監視メッセージをコールマネージャ１０Ｐに定期的に送信し、その応答の有無に基づいてコールマネージャ１０Ｐの稼動状態を監視する（Ｓ３０４）。

（３２）に示されるように、コールマネージャ１０Ｐは、障害から復旧すると自らの管理化にある各クライアント２５に対して、ロケーション情報の登録要求の送信を促す（要求する）メッセージを送信する（Ｓ３０５、Ｓ３０９）。ここで、管理下にある各クライアント２５とは、例えば、コールマネージャ１０Ｐの所定のテーブル（以下「クライアント管理テーブル」という。）にその属性情報が登録されているクライアント２５をいう。

図１４は、クライアント管理テーブルの構成例を示す図である。図１４のクライアント管理テーブル１１は、管理下のクライアント２５ごとに、クライアント名、電話番号、ＩＰアドレス、及び種別等が予め登録されているテーブルである。また、「状態」は、例えば、「ｏｎｌｉｎｅ」及び「ｏｆｆｌｉｎｅ」の値を持ち、ロケーション情報が登録されたクライアント２５については、「ｏｎｌｉｎｅ」が設定される。すなわち、図１４の例では、クライアント管理テーブル１１の登録内容にロケーション情報が含まれているため、改めてロケーション情報を登録するためのテーブルを設けるのではなく、ロケーション情報の登録の有無を識別するための項目として「状態」が設けられている。但し、クライアント管理テーブル１１の管理情報は、ロケーション情報の全てを含んでいる必要はなく、少なくともロケーション情報の登録要求の促進メッセージの送信に必要な情報（例えば、ＩＰアドレス）を含んでいればよい。

ところで、クライアント管理情報１１にロケーション情報が含まれているにもかかわらず、各クライアント２５からロケーション情報を定期的に受信するのは、ネットワークの構成の変更に応じて、ロケーション情報が変化する可能性があり、その変化に対応する必要があるからである。

なお、各クライアント２５に対するロケーション情報の登録要求の促進メッセージの送信は、クライアント２５ごとに個別に行ってもよいし、マルチキャストによって一斉に送信してもよい。

ロケーション情報の登録要求の促進メッセージに応じ、各クライアント２５は、定期的に送信する登録要求とは別に自らのロケーション情報の登録要求をコールマネージャ１０Ｐに送信する（Ｓ３０７、Ｓ３１１）。これによって、コールマネージャ１０Ｐには、クライアント２５がロケーション情報を送信する一定の周期分待つことなく各クライアント２５のロケーション情報が登録される。したがって、第二の実施の形態に比べて短期間で各クライアント２５のロケーション情報のコールマネージャ１０Ｐへの登録が完了する。

（３３）に示されるように、コールマネージャ１０Ｐは、自らの促進に対する各クライアントからの登録要求の受信を完了した時点で、もしくは、登録要求の受信待ち合わせがタイムアウトした時点（すなわち、受信待ち合わせがタイムアウトした該クライアントは、現時点では登録の必要が無いと判断できる）で、コールマネージャ１０Ｓからの死活監視メッセージ（Ｓ３１３）に対する応答を行う（Ｓ３１４）。但し、クライアント２５からの登録要求は、その後も継続的に送信されることを考慮すれば、必ずしも全てのクライアント２５の登録が確実に完了するまで待ち合わせる必要は無いのは、第二の実施の形態と同様である。

（３４）に示されるように、コールマネージャ１０Ｓは、死活監視メッセージに対する応答に基づいて自らをスタンバイ系とする。これによって、起動系がコールマネージャ１０Ｐに切り戻される。したがって、以降のロケーションの登録要求（Ｓ３１５、Ｓ３１７）に対する応答（Ｓ３１６）は、コールマネージャ１０Ｐが行う。また、コールマネージャ１０Ｐは、起動系に戻った時点で各クライアント２５のロケーション情報を取得しているため、その後の呼制御は、当該ロケーション情報に基づいて適切に行うことができる（図１３：Ｓ３１８〜Ｓ３２５）。

上述したように、第三の実施の形態によれば、第二の実施の形態に比べて短期間で各クライアント２５のロケーション情報のコールマネージャ１０Ｐへの登録が完了する。したがって、死活監視メッセージに対する応答、及びそれに基づく起動系の切り替えも短期間で完了させることができ、システムの信頼性をより向上させることができる。

なお、上記第一から第三の実施の形態において、各クライアント２５による、プライマリとセカンダリの両コールマネージャ１０に対する定期的なロケーション情報の登録要求の送信は、一定周期ごとに双方に（同時に）行ってもよいし、一定周期ごとに交互に行ってもよい。また、プライマリに対するロケーション情報の登録要求に対して応答がない場合に限って、セカンダリに対して送信するようにしてもよい。

以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１） クライアントのロケーション情報に基づいて呼制御を行うコールマネージャとして、プライマリのコールマネージャと、前記コールマネージャに対して定期的に監視メッセージを送信しその応答に基づいて前記プライマリのコールマネージャの稼動状態を監視するセカンダリのコールマネージャとを有するＶｏＩＰシステムにおけるシステム復旧方法であって、
前記プライマリのコールマネージャは、障害からの復旧後、前記クライアントより送信されるロケーション情報の登録を開始し、前記復旧から所定の期間が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とするシステム復旧方法。
（付記２） 前記ロケーション情報は、前記クライアントより一定の周期で送信され、
前記プライマリのコールマネージャは、前記障害からの復旧後、前記ロケーション情報を最初に受信した時点から少なくとも前記周期が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とする付記１記載のシステム復旧方法。
（付記３） 前記プライマリのコールマネージャは、前記障害からの復旧後、前記クライアントに対して前記ロケーション情報の送信を要求し、該要求に応じて前記クライアントより返信される前記ロケーション情報を登録することを特徴する付記１記載のシステム復旧方法。
（付記４） クライアントのロケーション情報に基づいて呼制御を行うＶｏＩＰ制御装置であって、
セカンダリのＶｏＩＰ制御装置より定期的に送信される監視メッセージに対し、稼動状態に応じて応答を返信する監視メッセージ応答手段と、
障害からの復旧後、前記クライアントより送信されるロケーション情報の登録を開始するロケーション情報登録手段とを有し、
前記監視メッセージ応答手段は、前記復旧から所定の期間が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とするＶｏＩＰ制御装置。
（付記５） クライアントのロケーション情報に基づいて呼制御を行うＶｏＩＰ制御装置を、
セカンダリのＶｏＩＰ制御装置より定期的に送信される監視メッセージに対し、稼動状態に応じて応答を返信する監視メッセージ応答手段と、
障害からの復旧後、前記クライアントより送信されるロケーション情報の登録を開始するロケーション情報登録手段として機能させるためのＶｏＩＰ制御プログラムであって、
前記監視メッセージ応答手段は、前記復旧から所定の期間が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とするＶｏＩＰ制御プログラム。

ＶｏＩＰ冗長化システムの基本構成例を示す図である。 従来のロケーション情報の通知処理を説明するためのシーケンス図である。 従来のコールマネージャの自動切り替え時の問題点を説明するための図である。 従来のコールマネージャの自動切り戻し時の問題点を説明するための図である。 本発明の実施の形態におけるＶｏＩＰ冗長化システムの基本構成例を示す図である。 本発明の実施の形態におけるコールマネージャのハードウェア構成例を示す図である。 本発明の実施の形態におけるＶｏＩＰ冗長化システムの処理概要を説明するための図である。 本発明の実施の形態におけるＶｏＩＰ冗長化システムの処理概要を説明するためのシーケンス図である。 第一の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するための図である。 第二の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するための図である。 第二の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するためのシーケンス図である。 第三の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するための図である。 第三の実施の形態におけるＶｏＩＰ冗長化システムの処理を説明するためのシーケンス図である。 クライアント管理テーブルの構成例を示す図である。

符号の説明

１ ＶｏＩＰ冗長化システム
１０Ｐ、１０Ｓ、５１０Ｐ、５１０Ｓ コールマネージャ
１１ クライアント管理マネージャ
２０、５２０ ＩＰ電話機
２５、 クライアント
３０、５３０ ＶｏＩＰゲートウェイ
４０、５４０ ＩＰネットワーク
５０、５５０ 公衆キャリア網
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
Ｂ バス

Claims (3)

1. クライアントのロケーション情報に基づいて呼制御を行うコールマネージャとして、プライマリのコールマネージャと、前記コールマネージャに対して定期的に監視メッセージを送信しその応答に基づいて前記プライマリのコールマネージャの稼動状態を監視するセカンダリのコールマネージャとを有するＶｏＩＰシステムにおけるシステム復旧方法であって、
   前記プライマリのコールマネージャは、障害からの復旧後、前記クライアントより送信されるロケーション情報の登録を開始し、前記復旧から所定の期間が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とするシステム復旧方法。
2. 前記ロケーション情報は、前記クライアントより一定の周期で送信され、
   前記プライマリのコールマネージャは、前記障害からの復旧後、前記ロケーション情報を最初に受信した時点から少なくとも前記周期が経過するまでは、前記監視メッセージに対する応答を行わないことを特徴とする請求項１記載のシステム復旧方法。
3. 前記プライマリのコールマネージャは、前記障害からの復旧後、前記クライアントに対して前記ロケーション情報の送信を要求し、該要求に応じて前記クライアントより返信される前記ロケーション情報を登録することを特徴する請求項１記載のシステム復旧方法。

Images