JP2004179764A - Ｉｐ網におけるｓｉｐサーバ障害検出方式 - Google Patents
Ｉｐ網におけるｓｉｐサーバ障害検出方式 Download PDFInfo
- Publication number
- JP2004179764A JP2004179764A JP2002341108A JP2002341108A JP2004179764A JP 2004179764 A JP2004179764 A JP 2004179764A JP 2002341108 A JP2002341108 A JP 2002341108A JP 2002341108 A JP2002341108 A JP 2002341108A JP 2004179764 A JP2004179764 A JP 2004179764A
- Authority
- JP
- Japan
- Prior art keywords
- sip server
- sip
- failure
- invite message
- health check
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ＳＩＰサーバの呼制御機能の障害を検出する。
【解決手段】ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した複数のＳＩＰサーバが相互に接続されているＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網において、１つのＳＩＰサーバから対向するＳＩＰサーバに送出されるＳＩＰにおけるＩＮＶＩＴＥメッセージに対する応答信号が返送されない時に、前記１つのＳＩＰサーバが前記対向するＳＩＰサーバの呼制御機能の障害であることを検出する、ことを特徴とする。
【選択図】 図１
【解決手段】ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した複数のＳＩＰサーバが相互に接続されているＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網において、１つのＳＩＰサーバから対向するＳＩＰサーバに送出されるＳＩＰにおけるＩＮＶＩＴＥメッセージに対する応答信号が返送されない時に、前記１つのＳＩＰサーバが前記対向するＳＩＰサーバの呼制御機能の障害であることを検出する、ことを特徴とする。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明はＩＰ網におけるＳＩＰサーバ障害検出方式に関し、特にＳＩＰサーバの呼制御機能の障害を検出することを可能とする、ＩＰ網におけるＳＩＰサーバ障害検出方式に関する。
【０００２】
【従来の技術】
近年のインターネットの発達に伴い、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネット・プロトコル）網を利用した各種のネットワークサービス、例えば、各種のコンテンツサービスやＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ：ＩＰ上の音声）サービスなどが提供されるようになってきている。
【０００３】
そして、ＶｏＩＰサービスなどのようにＩＰ網を使用した電話サービスを実現するために、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した所謂ＳＩＰサーバがＩＰ網内に導入されるようになってきている。
【０００４】
ＳＩＰは、ＩＰ網における電話サービスを実現するために、一般の電話サービスの有する呼の制御を行うためのプロトコルであり、インターネットの標準化を推進しているＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２５４３にその仕様が述べられているものである。
【０００５】
通信プロトコルとしてＴＣＰ／ＩＰ（Ｔｒａｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使用するＩＰ網において、ＩＰ網を構成するサーバやルータ、或いはゲートウェイや通信路の障害を検出するためには、通常、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＥｃｈｏコマンド（通称ｐｉｎｇコマンド）を発信し、このコマンドを受信した装置がその応答を返す、というヘルスチェックの仕組みを利用して障害検出を行うようになっている（例えば、特許文献１参照。）。
【０００６】
【特許文献１】
特開平１０−２４２９７１号公報（図１、２、３）
【０００７】
【発明が解決しようとする課題】
上述した従来のｐｉｎｇコマンドによるヘルスチェックの方式は、ＩＣＭＰがＴＣＰ／ＩＰと同一のネットワーク層（第３層）に実装されるため、ＩＰパケットレベルの障害検出は可能となっている。しかし、障害検出を行いたい対向装置がＳＩＰサーバである場合には、ＳＩＰはＴＣＰ／ＩＰの上位層に実装されるため、ＳＩＰの有する呼制御機能の障害検出は行うことが出来ない。例えば、ＳＩＰサーバの呼制御機能が障害状態であるが、ＳＩＰサーバのＴＣＰ／ＩＰ以下の層の機能が正常状態である場合に、該ＳＩＰサーバがｐｉｎｇコマンドを受信すると、ＴＣＰ／ＩＰ以下の層が正常であるため、ｐｉｎｇコマンドの応答は正常に返送されてしまう。すなわち、ｐｉｎｇコマンドだけでは、ＳＩＰサーバの呼制御機能の障害検出を正確に行うことは出来ない。
【０００８】
本発明は、上述した事情を改善するために成されたものであり、本発明の目的は、対向ＳＩＰサーバに対し、ｐｉｎｇコマンドの代わりにＩＮＶＩＴＥメッセージを用いたヘルスチェックを行うことにより、ＳＩＰサーバの呼制御機能の障害を検出することを可能とする、ＩＰ網におけるＳＩＰサーバ障害検出方式を提供することにある。
【０００９】
【課題を解決するための手段】
本発明のＩＰ網におけるＳＩＰサーバ障害検出方式は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した複数のＳＩＰサーバが相互に接続されているＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網において、１つのＳＩＰサーバから対向するＳＩＰサーバに送出されるＳＩＰにおけるＩＮＶＩＴＥメッセージに対する応答信号が返送されない時に、前記１つのＳＩＰサーバが前記対向するＳＩＰサーバの呼制御機能の障害であることを検出する、ことを特徴とする。
【００１０】
また、ＳＩＰサーバの各々は、電話の呼の生起を検知して呼の接続、解放等の制御を行う呼制御処理手段と、呼の接続先の決定などを行うルーティング処理手段と、対向するＳＩＰサーバの障害を検出した場合に、障害となったＳＩＰサーバに対してヘルスチェックを実行するヘルスチェック専用処理手段と、対向するＳＩＰサーバの障害を検出した場合に該ＳＩＰサーバが障害状態にあることを登録する障害管理テーブルと、対向するＳＩＰサーバにＩＮＶＩＴＥメッセージを再送する上限値を記憶する障害検出用再送閾値記憶部と、を備えることを特徴とする。
【００１１】
さらに、呼が生起された場合に該呼の生起を検知したＳＩＰサーバが、該呼のルーティング先となったＳＩＰサーバに対してＩＮＶＩＴＥメッセージを送出し、該ＩＮＶＩＴＥメッセージに対する応答信号が前記ルーティング先となったＳＩＰサーバから返送されない場合にはＩＮＶＩＴＥメッセージを再送し、ＩＮＶＩＴＥメッセージの再送を前記障害検出用再送閾値記憶部に記憶されている回数行っても、前記ルーティング先となったＳＩＰサーバから応答信号が返送されない場合に、前記ルーティング先となったＳＩＰサーバの呼制御機能の障害であることを検出し、前記ルーティング先となったＳＩＰサーバの対地名を前記障害管理テーブルに登録する、ことを特徴とする。
【００１２】
また、呼制御機能の障害であることを検出されたＳＩＰサーバに対し、前記ヘルスチェック専用処理手段が、ヘルスチェックＩＮＶＩＴＥメッセージを送出し、前記ヘルスチェックＩＮＶＩＴＥメッセージに対する応答信号（エラー応答）が返送されない場合は前記障害であることを検出されたＳＩＰサーバは、障害中であると判定して、定期的にヘルスチェックＩＮＶＩＴＥメッセージを送出することによりヘルスチェックを継続し、前記ヘルスチェックＩＮＶＩＴＥメッセージに対する応答信号（エラー応答）が返送された場合は前記障害であることを検出されたＳＩＰサーバの障害が復旧したと判定して、前記障害管理テーブルに登録されていた該当ＳＩＰサーバの対地名を前記障害管理テーブルから削除する、ことを特徴とする。
【００１３】
さらに、前記障害管理テーブルから対地名が削除されたＳＩＰサーバに対しては、前記ヘルスチェック専用処理手段が実行していたヘルスチェックを行わないようにする、ことを特徴とする。
【００１４】
また、前記ヘルスチェックＩＮＶＩＴＥメッセージの形式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージの一部分を特殊な形式に変更し、ＳＩＰにおけるルーティングが不可能な形式となっている、ことを特徴とする。
【００１５】
さらに、前記ヘルスチェックＩＮＶＩＴＥメッセージの形式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージの宛先電話番号を記載する部分を、全て空白文字で埋めたものであり、ＳＩＰにおけるルーティングが不可能な形式となっている、ことを特徴とする。
【００１６】
また、１つのＳＩＰサーバから見て迂回ルートを設定可能な複数のＳＩＰサーバを１つのグループとし、前記１つのＳＩＰサーバが生起した呼のルートを前記グループ化された複数のＳＩＰサーバの内の何れかに設定する場合には、前記１つのＳＩＰサーバは、前記障害管理テーブルに対地名が登録されていないＳＩＰサーバを選択して、該ＳＩＰサーバに該呼のルーティングを行う、ことを特徴とする。
【００１７】
さらに、前記１つのＳＩＰサーバが、前記グループ化された複数のＳＩＰサーバの対地名が全て前記障害管理テーブルに登録されていることを検出した場合には、該呼を呼損として処理する、ことを特徴とする。
【００１８】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００１９】
図１は、本発明のＩＰ網におけるＳＩＰサーバ障害検出方式の一実施形態を示すブロック図である。
【００２０】
図１に示す本実施の形態は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網に複数ｎ個のＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した所謂ＳＩＰサーバ１０が、相互に網目状に設置されている内の、一部分の接続形態を示すものであり、ＳＩＰサーバ１０−０に複数ｍ個のＳＩＰサーバ１０−１、１０−２、１０−３、・・１０−ｍが接続されている様子を示しており、その他のＳＩＰサーバ１０については図示を省略している。なお、ＳＩＰサーバ１０は、ＳＩＰを搭載した情報処理装置で構成され、ＩＰ網における電話サービス等を実現するために、呼制御機能を有するサーバである。
【００２１】
そして、ＳＩＰサーバ１０−０に接続されているＳＩＰサーバ１０−１〜１０−ｍの内の、ＳＩＰサーバ１０−１、１０−２、１０−３は、ＳＩＰサーバ１０−０から見て迂回ルートを設定可能なサーバであるため、１つのグループとしてグループ化されている。ここで、グループ化されているＳＩＰサーバ１０−１〜１０−３には、以降の説明の容易化のため、別名として、対向ＳＩＰサーバＡ、対向ＳＩＰサーバＢ、対向ＳＩＰサーバＣをそれぞれ付しておくものとする。また、これらの別名は、ＳＩＰサーバ１０−０からの回線接続時の接続先としての対地名としても用いるものとする。
【００２２】
次に、図２を参照して、ＳＩＰサーバ１０の構成について説明する。
【００２３】
図２は、ＳＩＰサーバの一例を示す詳細ブロック図である。
【００２４】
図２において、ＳＩＰサーバ１０は、電話の呼の生起を検知して呼の接続、解放等の制御を行う呼制御処理部１１と、呼の接続先の決定などを行うルーティング処理部１３と、対向して接続されているＳＩＰサーバ１０の障害を検出した場合に、障害となったＳＩＰサーバ１０に対してヘルスチェックを実行するヘルスチェック専用処理部１２と、から構成されている。
【００２５】
また、ＳＩＰサーバ１０は、対向して接続されているＳＩＰサーバ１０の障害を検出した場合、該ＳＩＰサーバ１０が障害状態にあることを登録する障害管理テーブル１６を備えている。
【００２６】
また、ＳＩＰサーバ１０は、呼の接続を開始するにあたり、ＳＩＰのＩＮＶＩＴＥメッセージを接続先のＳＩＰサーバ１０に送出するようになっている。そして、ＩＮＶＩＴＥメッセージに対する肯定応答（Ａｃｋ）を受信した後、ＳＩＰで規定された手順に従って呼の接続、解放等を行うようになっている。肯定応答（Ａｃｋ）を受信できなかった場合には、ＩＮＶＩＴＥメッセージを再送し、再送を何回か繰り返しても肯定応答（Ａｃｋ）を受信できなかった場合には、接続先のＳＩＰサーバ１０が障害状態にあるものと判断するようになっている。
【００２７】
そこで、ＳＩＰサーバ１０には、ＩＮＶＩＴＥメッセージを何回再送したら、接続先のＳＩＰサーバ１０が障害状態にあるかを判定するための閾値として、障害検出用再送閾値１５も備えられている。障害検出用再送閾値１５の値は、ＳＩＰサーバ１０内に予め設定可能であるものとし、例えば「６回」などの値を設定しておくものとする。
【００２８】
次に、図３、４、５、６、７を参照して、本実施形態の動作について詳細に説明する。先ず図３、図４、図５を参照して、障害検出時の動作について説明する。
【００２９】
図３は、本実施形態の障害検出時の動作を説明するフローチャートである。
【００３０】
図３においては、ＳＩＰサーバ１０−０が呼の生起を検知し、該呼をＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）にルーティングしようとした場合の動作を説明するものである。ここで、ＳＩＰサーバ１０−１の呼制御処理部１１は障害状態にあるものとし、ＩＮＶＩＴＥメッセージに対する肯定応答（Ａｃｋ）を返送出来ない状態であるものとする。
【００３１】
先ず、ＳＩＰサーバ１０−０は、呼の接続を開始するためのＩＮＶＩＴＥメッセージを、ＳＩＰサーバ１０−１に対して送出する（図３のＳ３０１）。ＳＩＰサーバ１０−１が障害状態に無ければ肯定応答（Ａｃｋ）を返送するので呼の接続を行うことが可能となるが、現在、ＳＩＰサーバ１０−１は障害中であるため、肯定応答（Ａｃｋ）を返送しない。従って、ＳＩＰサーバ１０−０はＩＮＶＩＴＥメッセージの再送を行う（Ｓ３０２）。
【００３２】
ＳＩＰサーバ１０−１は障害中であるため、ステップＳ３０２で再送されたＩＮＶＩＴＥメッセージに対しても肯定応答（Ａｃｋ）を返送しない。ＳＩＰサーバ１０−０は、障害検出用再送閾値１５に設定されている値（例えば６回）まで、ＩＮＶＩＴＥメッセージを再送する（Ｓ３０６）。しかし、ＳＩＰサーバ１０−１は障害中であるため、何れのＩＮＶＩＴＥメッセージに対しても肯定応答（Ａｃｋ）を返送しない。
【００３３】
ＳＩＰサーバ１０−０は、障害検出用再送閾値１５に設定されている回数のＩＮＶＩＴＥメッセージを送出しても、ＳＩＰサーバ１０−１から肯定応答（Ａｃｋ）が返送されないため、ＳＩＰサーバ１０−１の呼制御処理部１１は障害状態であると判定し（Ｓ３０７）、ＳＩＰサーバ１０−１すなわち対向ＳＩＰサーバＡを障害対地とみなす。そして、障害とみなしたＳＩＰサーバ１０−１の対地名（対向ＳＩＰサーバＡ）を障害管理テーブル１６に登録する（Ｓ３０８）。
【００３４】
図４は、障害管理テーブルの一例を示す図である。
【００３５】
図４において、障害管理テーブル１６は、障害とみなしたＳＩＰサーバ１０の対地名を記載する障害ＳＩＰサーバの対地名欄１６１と、該当する障害ＳＩＰサーバのＩＰアドレスを記載するＩＰアドレス欄１６２と、該当する障害ＳＩＰサーバの接続されているポート番号を記載するポート番号欄１６３と、から構成されている。
【００３６】
そして、上述のステップＳ３０８においては、ＳＩＰサーバ１０−１が障害であるとみなされたため、ＳＩＰサーバ１０−１の対地名すなわち「対向ＳＩＰサーバＡ」を、障害管理テーブル１６の障害ＳＩＰサーバの対地名欄１６１に登録する（図４の１６５の行）。そして、必要に応じて、ＩＰアドレス欄１６２にＳＩＰサーバ１０−１のＩＰアドレス「××××」を登録し、ポート番号欄１６３にポート番号「○○」を登録する（何れも図４の１６５の行）。
【００３７】
ステップＳ３０８により、障害とみなしたＳＩＰサーバ１０−１の対地名（対向ＳＩＰサーバＡ）を障害管理テーブル１６に登録すると、ＳＩＰサーバ１０−０は、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２にこのことを通知する（図３のＳ３０９）。
【００３８】
ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、障害とみなされたＳＩＰサーバ１０−１に対し、特殊なフォーマットを有するＩＮＶＩＴＥメッセージ（「ヘルスチェックＩＮＶＩＴＥ」メッセージと称することとする。）を定期的に送信する（図３のＳ３１０、Ｓ３１１など）ことにより、ＳＩＰサーバ１０−１のヘルスチェックを行うようになる。
【００３９】
ここで、図５を参照して、ヘルスチェックＩＮＶＩＴＥメッセージのフォーマットについて説明する。
【００４０】
図５は、ヘルスチェックＩＮＶＩＴＥメッセージのフォーマットの一例を説明する図である。
【００４１】
図５において、（ａ）は、ＳＩＰで規定されている通常のＩＮＶＩＴＥメッセージのフォーマットを示すものであり、ＩＮＶＩＴＥメッセージの中に、着呼先を示す宛先電話番号欄５０１を有しており、宛先電話番号欄５０１には宛先の電話番号、例えば「０１−２３４５−６７８９」、が記載されるようになっている。そして、このような形式のＩＮＶＩＴＥメッセージであれば、ＳＩＰの規定上、正しいルーティングが可能なようになっている。
【００４２】
図５の（ｂ）は、本実施形態で使用するヘルスチェックＩＮＶＩＴＥメッセージのフォーマットを示すものであり、（ａ）で示したと同一の位置の宛先電話番号欄５０２に、全て空白文字「△△−△△△△−△△△△」を記載した形式となっている。このような形式のヘルスチェックＩＮＶＩＴＥメッセージを、ＳＩＰサーバ１０の呼制御処理部１１が受信したものとすると、宛先電話番号欄５０２が全て空白文字で埋められているため、ＳＩＰの規定ではルーティングが不可能となり、図３の（＊１）の注釈として示したように、ＳＩＰルーティングが出来ないＩＮＶＩＴＥメッセージとなる。そして、本実施形態においては、図５（ｂ）に示した形式のヘルスチェックＩＮＶＩＴＥメッセージを、ＳＩＰサーバ１０の間で行うヘルスチェックに使用するものとする。
【００４３】
なお、図５（ｂ）で示したヘルスチェックＩＮＶＩＴＥメッセージのフォーマットは、単なる一例であり、他のフォーマットであっても、ＳＩＰルーティングが出来ない形式となっていれば、それで本実施形態のヘルスチェックＩＮＶＩＴＥメッセージとして使用可能である。
【００４４】
次に、図６を参照して、ＳＩＰサーバ１０が障害中における本実施形態の動作について説明する。
【００４５】
図６は、ＳＩＰサーバが障害中における本実施形態の動作を説明するフローチャートである。
【００４６】
図６においては、ＳＩＰサーバ１０−０が呼の生起を検知し、該呼をグループ化されているＳＩＰサーバ１０−１、１０−２、１０−３の何れかにルーティングしようとした場合の動作を説明するものである。
【００４７】
図６において、新規の呼が発呼されると（図６のＳ６０１）、ＳＩＰサーバ１０−０の呼制御処理部１１がこれを検知し、該呼のルーティング先をルーティング処理部１３に決定させる。ルーティング処理部１３は、先ず、グループ化されているＳＩＰサーバ１０（１０−１、１０−２、１０−３）の内のＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）にルーティングするよう決定する（Ｓ６０２）。そして、ルーティング先の対地（対向ＳＩＰサーバＡ）が、障害管理テーブル１６に登録されているかのチェックを行う（Ｓ６０３）。次に、障害管理テーブル１６にルーティング先の対地（対向ＳＩＰサーバＡ）が登録されているか否かの判定を行い（Ｓ６０４）、登録されていなければ（ステップＳ６０４で未登録）、呼制御処理部１１にルーティング先（対向ＳＩＰサーバＡ）へそのままＩＮＶＩＴＥメッセージを送信させ（Ｓ６０５）、呼の接続処理を開始させるようにする。
【００４８】
ルーティング先の対地（対向ＳＩＰサーバＡ）が、障害管理テーブル１６に登録されている場合には（ステップＳ６０４で登録）、今決定したルーティング先（対向ＳＩＰサーバＡ）は障害であるため、グループ内の他のＳＩＰサーバ１０に迂回する処理を行う（Ｓ６０６）。すなわち、グループ内の次のＳＩＰサーバ１０−２（対向ＳＩＰサーバＢ）にルーティングするよう決定し（Ｓ６０７）、ルーティング先の対地（対向ＳＩＰサーバＢ）が、障害管理テーブル１６に登録されているかのチェックを行う（Ｓ６０８）。そして、障害管理テーブル１６にルーティング先の対地（対向ＳＩＰサーバＢ）が登録されているか否かの判定を行い（Ｓ６０９）、登録されていなければ（ステップＳ６０９で未登録）、呼制御処理部１１にルーティング先（対向ＳＩＰサーバＢ）へそのままＩＮＶＩＴＥメッセージを送信させ（Ｓ６１０）、呼の接続処理を開始させるようにする。
【００４９】
ルーティング先の対地（対向ＳＩＰサーバＢ）が、障害管理テーブル１６に登録されている場合には（ステップＳ６０９で登録）、今決定したルーティング先（対向ＳＩＰサーバＢ）は障害であるため、グループ内の他のＳＩＰサーバ１０に迂回する処理を行う（Ｓ６１１）。
【００５０】
このように、グループ内のＳＩＰサーバ１０（１０−１、１０−２、１０−３）に対し、障害管理テーブル１６に登録されていない対地が決定されるまで、他のＳＩＰサーバ１０への迂回を行い、グループ内のＳＩＰサーバ１０の全てが障害であった場合には、呼損としてルーティング処理を終了する。
【００５１】
次に、図７を参照して、ＳＩＰサーバ１０の障害が回復した時の本実施形態の動作について説明する。
【００５２】
図７は、ＳＩＰサーバの障害が回復した時の本実施形態の動作を説明するフローチャートである。
【００５３】
図７においては、ＳＩＰサーバ１０−０がＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）の障害状態を検出していたため、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２がＳＩＰサーバ１０−１に対してヘルスチェックを行っており、ＳＩＰサーバ１０−１の障害状態がある時点で回復した場合の、ＳＩＰサーバ１０−０の動作を説明するものである。
【００５４】
図７において、ＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）が障害中であることを検出したＳＩＰサーバ１０−０は、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２によって、ヘルスチェックＩＮＶＩＴＥメッセージを送出する（図７のＳ７０１）。ステップＳ７０１で送出するヘルスチェックＩＮＶＩＴＥメッセージは、図５にて説明した通りの「ＳＩＰルーティングが出来ないＩＮＶＩＴＥメッセージ」である（図７の（＊１）の注釈として示す）。これは、以降のステップにおいても同様である。
【００５５】
ステップＳ７０１にてヘルスチェックＩＮＶＩＴＥメッセージを送出しても、ＳＩＰサーバ１０−１は障害中であるため、何の応答も返送しない。そこで、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、続けて定期的にヘルスチェックＩＮＶＩＴＥメッセージを送出する（Ｓ７０２、Ｓ７０３）。ここでもＳＩＰサーバ１０−１は障害中であるため、何の応答も返送しない。
【００５６】
図７のＳ７０４の時点で、ＳＩＰサーバ１０−１の障害が回復したものとする。ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２が、次のヘルスチェックＩＮＶＩＴＥメッセージを送出する（Ｓ７０５）。すると、この時点ではＳＩＰサーバ１０−１の障害が回復しているため、ＳＩＰサーバ１０−１の呼制御処理部１１は、ステップＳ７０５で送出されたヘルスチェックＩＮＶＩＴＥメッセージを受信可能な状態になっており、受信に対して応答信号を返送する（Ｓ７０６）。但し、ここで返送される応答信号は、通常のＩＮＶＩＴＥメッセージに対する応答信号（Ａｃｋ）ではなく、ヘルスチェックＩＮＶＩＴＥメッセージ、すなわち、「ＳＩＰルーティングが出来ないＩＮＶＩＴＥメッセージ」、に対する応答信号であるため、ステップＳ７０６で返送される応答信号は、「ＳＩＰルーティングが出来ない」旨を示すところの応答信号（エラー応答）である。
【００５７】
ステップＳ７０６で返送された応答信号（エラー応答）を受信したＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、ＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）の障害が回復したものと判断し、ＳＩＰサーバ１０−０の障害管理テーブル１６から該当するＳＩＰサーバ１０−１の対地名（対向ＳＩＰサーバＡ）を削除する（Ｓ７０７）。これにより、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、ＳＩＰサーバ１０−１に対するヘルスチェックを行わないようになり、ＳＩＰサーバ１０が正常に動作を行っている時の状態に復帰することとなる。
【００５８】
以上、本実施形態の動作について詳細に説明した。
【００５９】
上述した本実施形態においては、ＳＩＰを実装するＳＩＰサーバの呼制御機能の障害を検出可能とする方式について説明したが、ＳＩＰに限らず、呼制御処理で用いるプロトコル信号を用いてヘルスチェックを行うようにすれば、他のプロトコルであっても呼制御処理レベルでの障害検出が可能となることは言うまでも無い。
【００６０】
【発明の効果】
以上説明したように、本発明のＩＰ網におけるＳＩＰサーバ障害検出方式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージによって対向ＳＩＰサーバの障害検出を行うようにしているので、ＳＩＰサーバの呼制御機能の障害を正確に検出可能となる、という効果を有している。
【００６１】
また、障害を検出したＳＩＰサーバに対してだけヘルスチェックを行うようにしているため、ＩＰ網に収容されている対向ＳＩＰサーバの全てに対してヘルスチェックを行う必要が無く、ヘルスチェックに要する負荷が軽減される、という効果を有している。
【００６２】
さらに、ヘルスチェックを行う必要がある場合には、ヘルスチェック専用処理部によって行うため、呼制御処理部の行う呼制御処理に影響を与えることが無い、という効果を有している。
【図面の簡単な説明】
【図１】本発明のＩＰ網におけるＳＩＰサーバ障害検出方式の一実施形態を示すブロック図である。
【図２】ＳＩＰサーバの一例を示す詳細ブロック図である。
【図３】本実施形態の障害検出時の動作を説明するフローチャートである。
【図４】障害管理テーブルの一例を示す図である。
【図５】ヘルスチェックＩＮＶＩＴＥメッセージのフォーマットの一例を説明する図である。
【図６】ＳＩＰサーバが障害中における本実施形態の動作を説明するフローチャートである。
【図７】ＳＩＰサーバの障害が回復した時の本実施形態の動作を説明するフローチャートである。
【符号の説明】
１０ ＳＩＰサーバ
１１ 呼制御処理部
１２ ヘルスチェック専用処理部
１３ ルーティング処理部
１５ 障害検出用再送閾値
１６ 障害管理テーブル
【発明の属する技術分野】
本発明はＩＰ網におけるＳＩＰサーバ障害検出方式に関し、特にＳＩＰサーバの呼制御機能の障害を検出することを可能とする、ＩＰ網におけるＳＩＰサーバ障害検出方式に関する。
【０００２】
【従来の技術】
近年のインターネットの発達に伴い、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネット・プロトコル）網を利用した各種のネットワークサービス、例えば、各種のコンテンツサービスやＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ：ＩＰ上の音声）サービスなどが提供されるようになってきている。
【０００３】
そして、ＶｏＩＰサービスなどのようにＩＰ網を使用した電話サービスを実現するために、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した所謂ＳＩＰサーバがＩＰ網内に導入されるようになってきている。
【０００４】
ＳＩＰは、ＩＰ網における電話サービスを実現するために、一般の電話サービスの有する呼の制御を行うためのプロトコルであり、インターネットの標準化を推進しているＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２５４３にその仕様が述べられているものである。
【０００５】
通信プロトコルとしてＴＣＰ／ＩＰ（Ｔｒａｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使用するＩＰ網において、ＩＰ網を構成するサーバやルータ、或いはゲートウェイや通信路の障害を検出するためには、通常、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＥｃｈｏコマンド（通称ｐｉｎｇコマンド）を発信し、このコマンドを受信した装置がその応答を返す、というヘルスチェックの仕組みを利用して障害検出を行うようになっている（例えば、特許文献１参照。）。
【０００６】
【特許文献１】
特開平１０−２４２９７１号公報（図１、２、３）
【０００７】
【発明が解決しようとする課題】
上述した従来のｐｉｎｇコマンドによるヘルスチェックの方式は、ＩＣＭＰがＴＣＰ／ＩＰと同一のネットワーク層（第３層）に実装されるため、ＩＰパケットレベルの障害検出は可能となっている。しかし、障害検出を行いたい対向装置がＳＩＰサーバである場合には、ＳＩＰはＴＣＰ／ＩＰの上位層に実装されるため、ＳＩＰの有する呼制御機能の障害検出は行うことが出来ない。例えば、ＳＩＰサーバの呼制御機能が障害状態であるが、ＳＩＰサーバのＴＣＰ／ＩＰ以下の層の機能が正常状態である場合に、該ＳＩＰサーバがｐｉｎｇコマンドを受信すると、ＴＣＰ／ＩＰ以下の層が正常であるため、ｐｉｎｇコマンドの応答は正常に返送されてしまう。すなわち、ｐｉｎｇコマンドだけでは、ＳＩＰサーバの呼制御機能の障害検出を正確に行うことは出来ない。
【０００８】
本発明は、上述した事情を改善するために成されたものであり、本発明の目的は、対向ＳＩＰサーバに対し、ｐｉｎｇコマンドの代わりにＩＮＶＩＴＥメッセージを用いたヘルスチェックを行うことにより、ＳＩＰサーバの呼制御機能の障害を検出することを可能とする、ＩＰ網におけるＳＩＰサーバ障害検出方式を提供することにある。
【０００９】
【課題を解決するための手段】
本発明のＩＰ網におけるＳＩＰサーバ障害検出方式は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した複数のＳＩＰサーバが相互に接続されているＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網において、１つのＳＩＰサーバから対向するＳＩＰサーバに送出されるＳＩＰにおけるＩＮＶＩＴＥメッセージに対する応答信号が返送されない時に、前記１つのＳＩＰサーバが前記対向するＳＩＰサーバの呼制御機能の障害であることを検出する、ことを特徴とする。
【００１０】
また、ＳＩＰサーバの各々は、電話の呼の生起を検知して呼の接続、解放等の制御を行う呼制御処理手段と、呼の接続先の決定などを行うルーティング処理手段と、対向するＳＩＰサーバの障害を検出した場合に、障害となったＳＩＰサーバに対してヘルスチェックを実行するヘルスチェック専用処理手段と、対向するＳＩＰサーバの障害を検出した場合に該ＳＩＰサーバが障害状態にあることを登録する障害管理テーブルと、対向するＳＩＰサーバにＩＮＶＩＴＥメッセージを再送する上限値を記憶する障害検出用再送閾値記憶部と、を備えることを特徴とする。
【００１１】
さらに、呼が生起された場合に該呼の生起を検知したＳＩＰサーバが、該呼のルーティング先となったＳＩＰサーバに対してＩＮＶＩＴＥメッセージを送出し、該ＩＮＶＩＴＥメッセージに対する応答信号が前記ルーティング先となったＳＩＰサーバから返送されない場合にはＩＮＶＩＴＥメッセージを再送し、ＩＮＶＩＴＥメッセージの再送を前記障害検出用再送閾値記憶部に記憶されている回数行っても、前記ルーティング先となったＳＩＰサーバから応答信号が返送されない場合に、前記ルーティング先となったＳＩＰサーバの呼制御機能の障害であることを検出し、前記ルーティング先となったＳＩＰサーバの対地名を前記障害管理テーブルに登録する、ことを特徴とする。
【００１２】
また、呼制御機能の障害であることを検出されたＳＩＰサーバに対し、前記ヘルスチェック専用処理手段が、ヘルスチェックＩＮＶＩＴＥメッセージを送出し、前記ヘルスチェックＩＮＶＩＴＥメッセージに対する応答信号（エラー応答）が返送されない場合は前記障害であることを検出されたＳＩＰサーバは、障害中であると判定して、定期的にヘルスチェックＩＮＶＩＴＥメッセージを送出することによりヘルスチェックを継続し、前記ヘルスチェックＩＮＶＩＴＥメッセージに対する応答信号（エラー応答）が返送された場合は前記障害であることを検出されたＳＩＰサーバの障害が復旧したと判定して、前記障害管理テーブルに登録されていた該当ＳＩＰサーバの対地名を前記障害管理テーブルから削除する、ことを特徴とする。
【００１３】
さらに、前記障害管理テーブルから対地名が削除されたＳＩＰサーバに対しては、前記ヘルスチェック専用処理手段が実行していたヘルスチェックを行わないようにする、ことを特徴とする。
【００１４】
また、前記ヘルスチェックＩＮＶＩＴＥメッセージの形式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージの一部分を特殊な形式に変更し、ＳＩＰにおけるルーティングが不可能な形式となっている、ことを特徴とする。
【００１５】
さらに、前記ヘルスチェックＩＮＶＩＴＥメッセージの形式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージの宛先電話番号を記載する部分を、全て空白文字で埋めたものであり、ＳＩＰにおけるルーティングが不可能な形式となっている、ことを特徴とする。
【００１６】
また、１つのＳＩＰサーバから見て迂回ルートを設定可能な複数のＳＩＰサーバを１つのグループとし、前記１つのＳＩＰサーバが生起した呼のルートを前記グループ化された複数のＳＩＰサーバの内の何れかに設定する場合には、前記１つのＳＩＰサーバは、前記障害管理テーブルに対地名が登録されていないＳＩＰサーバを選択して、該ＳＩＰサーバに該呼のルーティングを行う、ことを特徴とする。
【００１７】
さらに、前記１つのＳＩＰサーバが、前記グループ化された複数のＳＩＰサーバの対地名が全て前記障害管理テーブルに登録されていることを検出した場合には、該呼を呼損として処理する、ことを特徴とする。
【００１８】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００１９】
図１は、本発明のＩＰ網におけるＳＩＰサーバ障害検出方式の一実施形態を示すブロック図である。
【００２０】
図１に示す本実施の形態は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網に複数ｎ個のＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した所謂ＳＩＰサーバ１０が、相互に網目状に設置されている内の、一部分の接続形態を示すものであり、ＳＩＰサーバ１０−０に複数ｍ個のＳＩＰサーバ１０−１、１０−２、１０−３、・・１０−ｍが接続されている様子を示しており、その他のＳＩＰサーバ１０については図示を省略している。なお、ＳＩＰサーバ１０は、ＳＩＰを搭載した情報処理装置で構成され、ＩＰ網における電話サービス等を実現するために、呼制御機能を有するサーバである。
【００２１】
そして、ＳＩＰサーバ１０−０に接続されているＳＩＰサーバ１０−１〜１０−ｍの内の、ＳＩＰサーバ１０−１、１０−２、１０−３は、ＳＩＰサーバ１０−０から見て迂回ルートを設定可能なサーバであるため、１つのグループとしてグループ化されている。ここで、グループ化されているＳＩＰサーバ１０−１〜１０−３には、以降の説明の容易化のため、別名として、対向ＳＩＰサーバＡ、対向ＳＩＰサーバＢ、対向ＳＩＰサーバＣをそれぞれ付しておくものとする。また、これらの別名は、ＳＩＰサーバ１０−０からの回線接続時の接続先としての対地名としても用いるものとする。
【００２２】
次に、図２を参照して、ＳＩＰサーバ１０の構成について説明する。
【００２３】
図２は、ＳＩＰサーバの一例を示す詳細ブロック図である。
【００２４】
図２において、ＳＩＰサーバ１０は、電話の呼の生起を検知して呼の接続、解放等の制御を行う呼制御処理部１１と、呼の接続先の決定などを行うルーティング処理部１３と、対向して接続されているＳＩＰサーバ１０の障害を検出した場合に、障害となったＳＩＰサーバ１０に対してヘルスチェックを実行するヘルスチェック専用処理部１２と、から構成されている。
【００２５】
また、ＳＩＰサーバ１０は、対向して接続されているＳＩＰサーバ１０の障害を検出した場合、該ＳＩＰサーバ１０が障害状態にあることを登録する障害管理テーブル１６を備えている。
【００２６】
また、ＳＩＰサーバ１０は、呼の接続を開始するにあたり、ＳＩＰのＩＮＶＩＴＥメッセージを接続先のＳＩＰサーバ１０に送出するようになっている。そして、ＩＮＶＩＴＥメッセージに対する肯定応答（Ａｃｋ）を受信した後、ＳＩＰで規定された手順に従って呼の接続、解放等を行うようになっている。肯定応答（Ａｃｋ）を受信できなかった場合には、ＩＮＶＩＴＥメッセージを再送し、再送を何回か繰り返しても肯定応答（Ａｃｋ）を受信できなかった場合には、接続先のＳＩＰサーバ１０が障害状態にあるものと判断するようになっている。
【００２７】
そこで、ＳＩＰサーバ１０には、ＩＮＶＩＴＥメッセージを何回再送したら、接続先のＳＩＰサーバ１０が障害状態にあるかを判定するための閾値として、障害検出用再送閾値１５も備えられている。障害検出用再送閾値１５の値は、ＳＩＰサーバ１０内に予め設定可能であるものとし、例えば「６回」などの値を設定しておくものとする。
【００２８】
次に、図３、４、５、６、７を参照して、本実施形態の動作について詳細に説明する。先ず図３、図４、図５を参照して、障害検出時の動作について説明する。
【００２９】
図３は、本実施形態の障害検出時の動作を説明するフローチャートである。
【００３０】
図３においては、ＳＩＰサーバ１０−０が呼の生起を検知し、該呼をＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）にルーティングしようとした場合の動作を説明するものである。ここで、ＳＩＰサーバ１０−１の呼制御処理部１１は障害状態にあるものとし、ＩＮＶＩＴＥメッセージに対する肯定応答（Ａｃｋ）を返送出来ない状態であるものとする。
【００３１】
先ず、ＳＩＰサーバ１０−０は、呼の接続を開始するためのＩＮＶＩＴＥメッセージを、ＳＩＰサーバ１０−１に対して送出する（図３のＳ３０１）。ＳＩＰサーバ１０−１が障害状態に無ければ肯定応答（Ａｃｋ）を返送するので呼の接続を行うことが可能となるが、現在、ＳＩＰサーバ１０−１は障害中であるため、肯定応答（Ａｃｋ）を返送しない。従って、ＳＩＰサーバ１０−０はＩＮＶＩＴＥメッセージの再送を行う（Ｓ３０２）。
【００３２】
ＳＩＰサーバ１０−１は障害中であるため、ステップＳ３０２で再送されたＩＮＶＩＴＥメッセージに対しても肯定応答（Ａｃｋ）を返送しない。ＳＩＰサーバ１０−０は、障害検出用再送閾値１５に設定されている値（例えば６回）まで、ＩＮＶＩＴＥメッセージを再送する（Ｓ３０６）。しかし、ＳＩＰサーバ１０−１は障害中であるため、何れのＩＮＶＩＴＥメッセージに対しても肯定応答（Ａｃｋ）を返送しない。
【００３３】
ＳＩＰサーバ１０−０は、障害検出用再送閾値１５に設定されている回数のＩＮＶＩＴＥメッセージを送出しても、ＳＩＰサーバ１０−１から肯定応答（Ａｃｋ）が返送されないため、ＳＩＰサーバ１０−１の呼制御処理部１１は障害状態であると判定し（Ｓ３０７）、ＳＩＰサーバ１０−１すなわち対向ＳＩＰサーバＡを障害対地とみなす。そして、障害とみなしたＳＩＰサーバ１０−１の対地名（対向ＳＩＰサーバＡ）を障害管理テーブル１６に登録する（Ｓ３０８）。
【００３４】
図４は、障害管理テーブルの一例を示す図である。
【００３５】
図４において、障害管理テーブル１６は、障害とみなしたＳＩＰサーバ１０の対地名を記載する障害ＳＩＰサーバの対地名欄１６１と、該当する障害ＳＩＰサーバのＩＰアドレスを記載するＩＰアドレス欄１６２と、該当する障害ＳＩＰサーバの接続されているポート番号を記載するポート番号欄１６３と、から構成されている。
【００３６】
そして、上述のステップＳ３０８においては、ＳＩＰサーバ１０−１が障害であるとみなされたため、ＳＩＰサーバ１０−１の対地名すなわち「対向ＳＩＰサーバＡ」を、障害管理テーブル１６の障害ＳＩＰサーバの対地名欄１６１に登録する（図４の１６５の行）。そして、必要に応じて、ＩＰアドレス欄１６２にＳＩＰサーバ１０−１のＩＰアドレス「××××」を登録し、ポート番号欄１６３にポート番号「○○」を登録する（何れも図４の１６５の行）。
【００３７】
ステップＳ３０８により、障害とみなしたＳＩＰサーバ１０−１の対地名（対向ＳＩＰサーバＡ）を障害管理テーブル１６に登録すると、ＳＩＰサーバ１０−０は、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２にこのことを通知する（図３のＳ３０９）。
【００３８】
ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、障害とみなされたＳＩＰサーバ１０−１に対し、特殊なフォーマットを有するＩＮＶＩＴＥメッセージ（「ヘルスチェックＩＮＶＩＴＥ」メッセージと称することとする。）を定期的に送信する（図３のＳ３１０、Ｓ３１１など）ことにより、ＳＩＰサーバ１０−１のヘルスチェックを行うようになる。
【００３９】
ここで、図５を参照して、ヘルスチェックＩＮＶＩＴＥメッセージのフォーマットについて説明する。
【００４０】
図５は、ヘルスチェックＩＮＶＩＴＥメッセージのフォーマットの一例を説明する図である。
【００４１】
図５において、（ａ）は、ＳＩＰで規定されている通常のＩＮＶＩＴＥメッセージのフォーマットを示すものであり、ＩＮＶＩＴＥメッセージの中に、着呼先を示す宛先電話番号欄５０１を有しており、宛先電話番号欄５０１には宛先の電話番号、例えば「０１−２３４５−６７８９」、が記載されるようになっている。そして、このような形式のＩＮＶＩＴＥメッセージであれば、ＳＩＰの規定上、正しいルーティングが可能なようになっている。
【００４２】
図５の（ｂ）は、本実施形態で使用するヘルスチェックＩＮＶＩＴＥメッセージのフォーマットを示すものであり、（ａ）で示したと同一の位置の宛先電話番号欄５０２に、全て空白文字「△△−△△△△−△△△△」を記載した形式となっている。このような形式のヘルスチェックＩＮＶＩＴＥメッセージを、ＳＩＰサーバ１０の呼制御処理部１１が受信したものとすると、宛先電話番号欄５０２が全て空白文字で埋められているため、ＳＩＰの規定ではルーティングが不可能となり、図３の（＊１）の注釈として示したように、ＳＩＰルーティングが出来ないＩＮＶＩＴＥメッセージとなる。そして、本実施形態においては、図５（ｂ）に示した形式のヘルスチェックＩＮＶＩＴＥメッセージを、ＳＩＰサーバ１０の間で行うヘルスチェックに使用するものとする。
【００４３】
なお、図５（ｂ）で示したヘルスチェックＩＮＶＩＴＥメッセージのフォーマットは、単なる一例であり、他のフォーマットであっても、ＳＩＰルーティングが出来ない形式となっていれば、それで本実施形態のヘルスチェックＩＮＶＩＴＥメッセージとして使用可能である。
【００４４】
次に、図６を参照して、ＳＩＰサーバ１０が障害中における本実施形態の動作について説明する。
【００４５】
図６は、ＳＩＰサーバが障害中における本実施形態の動作を説明するフローチャートである。
【００４６】
図６においては、ＳＩＰサーバ１０−０が呼の生起を検知し、該呼をグループ化されているＳＩＰサーバ１０−１、１０−２、１０−３の何れかにルーティングしようとした場合の動作を説明するものである。
【００４７】
図６において、新規の呼が発呼されると（図６のＳ６０１）、ＳＩＰサーバ１０−０の呼制御処理部１１がこれを検知し、該呼のルーティング先をルーティング処理部１３に決定させる。ルーティング処理部１３は、先ず、グループ化されているＳＩＰサーバ１０（１０−１、１０−２、１０−３）の内のＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）にルーティングするよう決定する（Ｓ６０２）。そして、ルーティング先の対地（対向ＳＩＰサーバＡ）が、障害管理テーブル１６に登録されているかのチェックを行う（Ｓ６０３）。次に、障害管理テーブル１６にルーティング先の対地（対向ＳＩＰサーバＡ）が登録されているか否かの判定を行い（Ｓ６０４）、登録されていなければ（ステップＳ６０４で未登録）、呼制御処理部１１にルーティング先（対向ＳＩＰサーバＡ）へそのままＩＮＶＩＴＥメッセージを送信させ（Ｓ６０５）、呼の接続処理を開始させるようにする。
【００４８】
ルーティング先の対地（対向ＳＩＰサーバＡ）が、障害管理テーブル１６に登録されている場合には（ステップＳ６０４で登録）、今決定したルーティング先（対向ＳＩＰサーバＡ）は障害であるため、グループ内の他のＳＩＰサーバ１０に迂回する処理を行う（Ｓ６０６）。すなわち、グループ内の次のＳＩＰサーバ１０−２（対向ＳＩＰサーバＢ）にルーティングするよう決定し（Ｓ６０７）、ルーティング先の対地（対向ＳＩＰサーバＢ）が、障害管理テーブル１６に登録されているかのチェックを行う（Ｓ６０８）。そして、障害管理テーブル１６にルーティング先の対地（対向ＳＩＰサーバＢ）が登録されているか否かの判定を行い（Ｓ６０９）、登録されていなければ（ステップＳ６０９で未登録）、呼制御処理部１１にルーティング先（対向ＳＩＰサーバＢ）へそのままＩＮＶＩＴＥメッセージを送信させ（Ｓ６１０）、呼の接続処理を開始させるようにする。
【００４９】
ルーティング先の対地（対向ＳＩＰサーバＢ）が、障害管理テーブル１６に登録されている場合には（ステップＳ６０９で登録）、今決定したルーティング先（対向ＳＩＰサーバＢ）は障害であるため、グループ内の他のＳＩＰサーバ１０に迂回する処理を行う（Ｓ６１１）。
【００５０】
このように、グループ内のＳＩＰサーバ１０（１０−１、１０−２、１０−３）に対し、障害管理テーブル１６に登録されていない対地が決定されるまで、他のＳＩＰサーバ１０への迂回を行い、グループ内のＳＩＰサーバ１０の全てが障害であった場合には、呼損としてルーティング処理を終了する。
【００５１】
次に、図７を参照して、ＳＩＰサーバ１０の障害が回復した時の本実施形態の動作について説明する。
【００５２】
図７は、ＳＩＰサーバの障害が回復した時の本実施形態の動作を説明するフローチャートである。
【００５３】
図７においては、ＳＩＰサーバ１０−０がＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）の障害状態を検出していたため、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２がＳＩＰサーバ１０−１に対してヘルスチェックを行っており、ＳＩＰサーバ１０−１の障害状態がある時点で回復した場合の、ＳＩＰサーバ１０−０の動作を説明するものである。
【００５４】
図７において、ＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）が障害中であることを検出したＳＩＰサーバ１０−０は、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２によって、ヘルスチェックＩＮＶＩＴＥメッセージを送出する（図７のＳ７０１）。ステップＳ７０１で送出するヘルスチェックＩＮＶＩＴＥメッセージは、図５にて説明した通りの「ＳＩＰルーティングが出来ないＩＮＶＩＴＥメッセージ」である（図７の（＊１）の注釈として示す）。これは、以降のステップにおいても同様である。
【００５５】
ステップＳ７０１にてヘルスチェックＩＮＶＩＴＥメッセージを送出しても、ＳＩＰサーバ１０−１は障害中であるため、何の応答も返送しない。そこで、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、続けて定期的にヘルスチェックＩＮＶＩＴＥメッセージを送出する（Ｓ７０２、Ｓ７０３）。ここでもＳＩＰサーバ１０−１は障害中であるため、何の応答も返送しない。
【００５６】
図７のＳ７０４の時点で、ＳＩＰサーバ１０−１の障害が回復したものとする。ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２が、次のヘルスチェックＩＮＶＩＴＥメッセージを送出する（Ｓ７０５）。すると、この時点ではＳＩＰサーバ１０−１の障害が回復しているため、ＳＩＰサーバ１０−１の呼制御処理部１１は、ステップＳ７０５で送出されたヘルスチェックＩＮＶＩＴＥメッセージを受信可能な状態になっており、受信に対して応答信号を返送する（Ｓ７０６）。但し、ここで返送される応答信号は、通常のＩＮＶＩＴＥメッセージに対する応答信号（Ａｃｋ）ではなく、ヘルスチェックＩＮＶＩＴＥメッセージ、すなわち、「ＳＩＰルーティングが出来ないＩＮＶＩＴＥメッセージ」、に対する応答信号であるため、ステップＳ７０６で返送される応答信号は、「ＳＩＰルーティングが出来ない」旨を示すところの応答信号（エラー応答）である。
【００５７】
ステップＳ７０６で返送された応答信号（エラー応答）を受信したＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、ＳＩＰサーバ１０−１（対向ＳＩＰサーバＡ）の障害が回復したものと判断し、ＳＩＰサーバ１０−０の障害管理テーブル１６から該当するＳＩＰサーバ１０−１の対地名（対向ＳＩＰサーバＡ）を削除する（Ｓ７０７）。これにより、ＳＩＰサーバ１０−０のヘルスチェック専用処理部１２は、ＳＩＰサーバ１０−１に対するヘルスチェックを行わないようになり、ＳＩＰサーバ１０が正常に動作を行っている時の状態に復帰することとなる。
【００５８】
以上、本実施形態の動作について詳細に説明した。
【００５９】
上述した本実施形態においては、ＳＩＰを実装するＳＩＰサーバの呼制御機能の障害を検出可能とする方式について説明したが、ＳＩＰに限らず、呼制御処理で用いるプロトコル信号を用いてヘルスチェックを行うようにすれば、他のプロトコルであっても呼制御処理レベルでの障害検出が可能となることは言うまでも無い。
【００６０】
【発明の効果】
以上説明したように、本発明のＩＰ網におけるＳＩＰサーバ障害検出方式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージによって対向ＳＩＰサーバの障害検出を行うようにしているので、ＳＩＰサーバの呼制御機能の障害を正確に検出可能となる、という効果を有している。
【００６１】
また、障害を検出したＳＩＰサーバに対してだけヘルスチェックを行うようにしているため、ＩＰ網に収容されている対向ＳＩＰサーバの全てに対してヘルスチェックを行う必要が無く、ヘルスチェックに要する負荷が軽減される、という効果を有している。
【００６２】
さらに、ヘルスチェックを行う必要がある場合には、ヘルスチェック専用処理部によって行うため、呼制御処理部の行う呼制御処理に影響を与えることが無い、という効果を有している。
【図面の簡単な説明】
【図１】本発明のＩＰ網におけるＳＩＰサーバ障害検出方式の一実施形態を示すブロック図である。
【図２】ＳＩＰサーバの一例を示す詳細ブロック図である。
【図３】本実施形態の障害検出時の動作を説明するフローチャートである。
【図４】障害管理テーブルの一例を示す図である。
【図５】ヘルスチェックＩＮＶＩＴＥメッセージのフォーマットの一例を説明する図である。
【図６】ＳＩＰサーバが障害中における本実施形態の動作を説明するフローチャートである。
【図７】ＳＩＰサーバの障害が回復した時の本実施形態の動作を説明するフローチャートである。
【符号の説明】
１０ ＳＩＰサーバ
１１ 呼制御処理部
１２ ヘルスチェック専用処理部
１３ ルーティング処理部
１５ 障害検出用再送閾値
１６ 障害管理テーブル
Claims (9)
- ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）を搭載した複数のＳＩＰサーバが相互に接続されているＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網において、１つのＳＩＰサーバから対向するＳＩＰサーバに送出されるＳＩＰにおけるＩＮＶＩＴＥメッセージに対する応答信号が返送されない時に、前記１つのＳＩＰサーバが前記対向するＳＩＰサーバの呼制御機能の障害であることを検出する、ことを特徴とするＩＰ網におけるＳＩＰサーバ障害検出方式。
- ＳＩＰサーバの各々は、電話の呼の生起を検知して呼の接続、解放等の制御を行う呼制御処理手段と、呼の接続先の決定などを行うルーティング処理手段と、対向するＳＩＰサーバの障害を検出した場合に、障害となったＳＩＰサーバに対してヘルスチェックを実行するヘルスチェック専用処理手段と、対向するＳＩＰサーバの障害を検出した場合に該ＳＩＰサーバが障害状態にあることを登録する障害管理テーブルと、対向するＳＩＰサーバにＩＮＶＩＴＥメッセージを再送する上限値を記憶する障害検出用再送閾値記憶部と、を備えることを特徴とする請求項１に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- 呼が生起された場合に該呼の生起を検知したＳＩＰサーバが、該呼のルーティング先となったＳＩＰサーバに対してＩＮＶＩＴＥメッセージを送出し、該ＩＮＶＩＴＥメッセージに対する応答信号が前記ルーティング先となったＳＩＰサーバから返送されない場合にはＩＮＶＩＴＥメッセージを再送し、ＩＮＶＩＴＥメッセージの再送を前記障害検出用再送閾値記憶部に記憶されている回数行っても、前記ルーティング先となったＳＩＰサーバから応答信号が返送されない場合に、前記ルーティング先となったＳＩＰサーバの呼制御機能の障害であることを検出し、前記ルーティング先となったＳＩＰサーバの対地名を前記障害管理テーブルに登録する、ことを特徴とする請求項２に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- 呼制御機能の障害であることを検出されたＳＩＰサーバに対し、前記ヘルスチェック専用処理手段が、ヘルスチェックＩＮＶＩＴＥメッセージを送出し、前記ヘルスチェックＩＮＶＩＴＥメッセージに対する応答信号（エラー応答）が返送されない場合は前記障害であることを検出されたＳＩＰサーバは、障害中であると判定して、定期的にヘルスチェックＩＮＶＩＴＥメッセージを送出することによりヘルスチェックを継続し、前記ヘルスチェックＩＮＶＩＴＥメッセージに対する応答信号（エラー応答）が返送された場合は前記障害であることを検出されたＳＩＰサーバの障害が復旧したと判定して、前記障害管理テーブルに登録されていた該当ＳＩＰサーバの対地名を前記障害管理テーブルから削除する、ことを特徴とする請求項３に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- 前記障害管理テーブルから対地名が削除されたＳＩＰサーバに対しては、前記ヘルスチェック専用処理手段が実行していたヘルスチェックを行わないようにする、ことを特徴とする請求項４に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- 前記ヘルスチェックＩＮＶＩＴＥメッセージの形式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージの一部分を特殊な形式に変更し、ＳＩＰにおけるルーティングが不可能な形式となっている、ことを特徴とする請求項４或いは請求項５の何れか１項に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- 前記ヘルスチェックＩＮＶＩＴＥメッセージの形式は、ＳＩＰにおけるＩＮＶＩＴＥメッセージの宛先電話番号を記載する部分を、全て空白文字で埋めたものであり、ＳＩＰにおけるルーティングが不可能な形式となっている、ことを特徴とする請求項４或いは請求項５の何れか１項に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- １つのＳＩＰサーバから見て迂回ルートを設定可能な複数のＳＩＰサーバを１つのグループとし、前記１つのＳＩＰサーバが生起した呼のルートを前記グループ化された複数のＳＩＰサーバの内の何れかに設定する場合には、前記１つのＳＩＰサーバは、前記障害管理テーブルに対地名が登録されていないＳＩＰサーバを選択して、該ＳＩＰサーバに該呼のルーティングを行う、ことを特徴とする請求項３から請求項７の何れか１項に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
- 前記１つのＳＩＰサーバが、前記グループ化された複数のＳＩＰサーバの対地名が全て前記障害管理テーブルに登録されていることを検出した場合には、該呼を呼損として処理する、ことを特徴とする請求項８に記載のＩＰ網におけるＳＩＰサーバ障害検出方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002341108A JP3761509B2 (ja) | 2002-11-25 | 2002-11-25 | Ｉｐ網におけるｓｉｐサーバ障害検出方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002341108A JP3761509B2 (ja) | 2002-11-25 | 2002-11-25 | Ｉｐ網におけるｓｉｐサーバ障害検出方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004179764A true JP2004179764A (ja) | 2004-06-24 |
| JP3761509B2 JP3761509B2 (ja) | 2006-03-29 |
Family
ID=32703568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002341108A Expired - Fee Related JP3761509B2 (ja) | 2002-11-25 | 2002-11-25 | Ｉｐ網におけるｓｉｐサーバ障害検出方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3761509B2 (ja) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006237950A (ja) * | 2005-02-24 | 2006-09-07 | Saxa Inc | Ｉｐ電話端末およびプログラム |
| JP2007235556A (ja) * | 2006-03-01 | 2007-09-13 | Nec Corp | 中継サーバ及び接続制御方法並びにプログラム |
| JP2008236003A (ja) * | 2007-03-16 | 2008-10-02 | Fujitsu Ltd | Ｓｉｐサーバ |
| CN100454849C (zh) * | 2005-08-05 | 2009-01-21 | 华为技术有限公司 | 下一代网络中的故障检测方法 |
| JP2010504045A (ja) * | 2006-09-12 | 2010-02-04 | クゥアルコム・インコーポレイテッド | 通信セッション管理におけるトランザクションタイムアウト処理 |
| JP2010507269A (ja) * | 2006-10-16 | 2010-03-04 | フランス・テレコム | 中間ノードが利用不可能な場合にｓｉｐメッセージを経路指定する方法 |
| EP2209283A1 (en) | 2009-01-20 | 2010-07-21 | Vodafone Group PLC | Node failure detection system and method for SIP sessions in communication networks. |
| JP2010541348A (ja) * | 2007-09-28 | 2010-12-24 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｉｐマルチメディア・サブシステム・ネットワークにおける障害回復 |
| US8054955B2 (en) | 2008-03-26 | 2011-11-08 | Kabushiki Kaisha Toshiba | Telephone system, associated exchange, and transmission control method |
| KR101368693B1 (ko) * | 2012-03-08 | 2014-03-03 | 텔코웨어 주식회사 | Ｉｍｓ망에서 트래픽 처리 방법 및 장치 |
| KR101391059B1 (ko) * | 2008-03-26 | 2014-06-18 | 아바야 인코포레이티드 | Ｓｉｐ 생존가능 구성에서 ｓｉｐ 메시지를 이용한 페일오버/페일백 트리거 |
| KR101525312B1 (ko) * | 2013-10-14 | 2015-06-02 | 주식회사 엘지유플러스 | 통신 단말기에 재시도 에러 응답 신호를 전송하는 요청 응답 서버 및 그 제어방법과, 그 제어방법을 실행하기 위한 프로그램을 기록한 기록 매체 |
| JPWO2013132541A1 (ja) * | 2012-03-09 | 2015-07-30 | ネクシオン株式会社 | 映像データ伝送システム |
| CN113472568A (zh) * | 2021-06-22 | 2021-10-01 | 深圳市亿联无限科技有限公司 | 语音网关报障呼叫方法和系统 |
-
2002
- 2002-11-25 JP JP2002341108A patent/JP3761509B2/ja not_active Expired - Fee Related
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006237950A (ja) * | 2005-02-24 | 2006-09-07 | Saxa Inc | Ｉｐ電話端末およびプログラム |
| US8015297B2 (en) | 2005-08-05 | 2011-09-06 | Huawei Technologies Co., Ltd. | Method for detecting fault in next generation network |
| CN100454849C (zh) * | 2005-08-05 | 2009-01-21 | 华为技术有限公司 | 下一代网络中的故障检测方法 |
| JP4609345B2 (ja) * | 2006-03-01 | 2011-01-12 | 日本電気株式会社 | 中継サーバ及び接続制御方法並びにプログラム |
| JP2007235556A (ja) * | 2006-03-01 | 2007-09-13 | Nec Corp | 中継サーバ及び接続制御方法並びにプログラム |
| JP2010504045A (ja) * | 2006-09-12 | 2010-02-04 | クゥアルコム・インコーポレイテッド | 通信セッション管理におけるトランザクションタイムアウト処理 |
| US8213295B2 (en) | 2006-09-12 | 2012-07-03 | Qualcomm Incorporated | Transaction timeout handling in communication session management |
| JP2010507269A (ja) * | 2006-10-16 | 2010-03-04 | フランス・テレコム | 中間ノードが利用不可能な場合にｓｉｐメッセージを経路指定する方法 |
| JP2008236003A (ja) * | 2007-03-16 | 2008-10-02 | Fujitsu Ltd | Ｓｉｐサーバ |
| JP2010541348A (ja) * | 2007-09-28 | 2010-12-24 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｉｐマルチメディア・サブシステム・ネットワークにおける障害回復 |
| US8054955B2 (en) | 2008-03-26 | 2011-11-08 | Kabushiki Kaisha Toshiba | Telephone system, associated exchange, and transmission control method |
| KR101391059B1 (ko) * | 2008-03-26 | 2014-06-18 | 아바야 인코포레이티드 | Ｓｉｐ 생존가능 구성에서 ｓｉｐ 메시지를 이용한 페일오버/페일백 트리거 |
| EP2209283A1 (en) | 2009-01-20 | 2010-07-21 | Vodafone Group PLC | Node failure detection system and method for SIP sessions in communication networks. |
| KR101368693B1 (ko) * | 2012-03-08 | 2014-03-03 | 텔코웨어 주식회사 | Ｉｍｓ망에서 트래픽 처리 방법 및 장치 |
| JPWO2013132541A1 (ja) * | 2012-03-09 | 2015-07-30 | ネクシオン株式会社 | 映像データ伝送システム |
| KR101525312B1 (ko) * | 2013-10-14 | 2015-06-02 | 주식회사 엘지유플러스 | 통신 단말기에 재시도 에러 응답 신호를 전송하는 요청 응답 서버 및 그 제어방법과, 그 제어방법을 실행하기 위한 프로그램을 기록한 기록 매체 |
| CN113472568A (zh) * | 2021-06-22 | 2021-10-01 | 深圳市亿联无限科技有限公司 | 语音网关报障呼叫方法和系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3761509B2 (ja) | 2006-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1349347B1 (en) | Method and apparatus for redundant signaling links | |
| JP3761509B2 (ja) | Ｉｐ網におけるｓｉｐサーバ障害検出方式 | |
| US7664044B2 (en) | Method of failure detection in an IP forwarding plane | |
| EP1465440B1 (en) | Method and apparatus for changeover of associations between signalling processes | |
| US20070280100A1 (en) | Network routing device and network routing method | |
| US8868997B2 (en) | Data transfer method | |
| JP4153502B2 (ja) | 通信装置及び論理リンク異常検出方法 | |
| US6760766B1 (en) | Data transmission method and device | |
| JP4470934B2 (ja) | プロキシ・サーバ、通信システム、通信方法及びプログラム | |
| KR100693320B1 (ko) | 소스 어드레스 선택시스템, 라우터장치, 라우터장치로서 컴퓨터를 기능시키기 위한 프로그램을 기록한 컴퓨터 독출가능한 기록매체, 통신노드 및 소스 어드레스 선택방법 | |
| US20060137002A1 (en) | System, method and program product to route message packets | |
| JPH06501360A (ja) | ネットワークトラフィック管理 | |
| WO2008055426A1 (fr) | Procédé, système et appareil de nœud pour transmettre un message de gestion de défaut de connectivité ethernet | |
| US20100218034A1 (en) | Method And System For Providing High Availability SCTP Applications | |
| JP2001339431A (ja) | 通信方式、中継装置、エンドシステム及び通信方法 | |
| US20080225835A1 (en) | Communication server | |
| EP1727309A1 (en) | Methods and apparatus for monitoring link integrity for signaling traffic over a path traversing hybrid ATM/ethernet infrastructure in support of packet voice service provisioning | |
| JP2005229273A (ja) | サーババックアップ装置 | |
| EP1207709B1 (en) | Retransmission control method and the apparatus | |
| CA2391037A1 (en) | Method and system for dynamic gateway selection in an ip telephony network | |
| US20070115943A1 (en) | System and method for establishing emergency communications in a telecommunication network | |
| JP2008227917A (ja) | 通信システム及びルータ | |
| KR20060050694A (ko) | 메시지 라우팅 방법 및 사전-ｄｎｓ 리졸버 | |
| US20110066641A1 (en) | Handling enum queries in a communication network | |
| EP1395004A1 (en) | Flushing method with separated sets for type 5 link state advertisement in open shortest path first protocol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040423 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20050322 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050829 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050906 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051107 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051213 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060110 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100120 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110120 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110120 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120120 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130120 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130120 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |