JP2009239343A - 監視装置、監視システムおよび監視プログラム - Google Patents
監視装置、監視システムおよび監視プログラム Download PDFInfo
- Publication number
- JP2009239343A JP2009239343A JP2008079048A JP2008079048A JP2009239343A JP 2009239343 A JP2009239343 A JP 2009239343A JP 2008079048 A JP2008079048 A JP 2008079048A JP 2008079048 A JP2008079048 A JP 2008079048A JP 2009239343 A JP2009239343 A JP 2009239343A
- Authority
- JP
- Japan
- Prior art keywords
- server
- message
- monitoring
- sip
- sip server
- 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
- Telephonic Communication Services (AREA)
Abstract
【課題】大容量のデータを取得し解析することなく、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの監視を行うことができる。
【解決手段】記憶部３３は、ＳＩＰサーバ１が送信および受信したメッセージの数を含んだ監視情報を記憶する。制御部３２は、記憶部３３より読み出した監視情報に基づいて、ＳＩＰシステムの通信状態を判断する。
【選択図】図２
【解決手段】記憶部３３は、ＳＩＰサーバ１が送信および受信したメッセージの数を含んだ監視情報を記憶する。制御部３２は、記憶部３３より読み出した監視情報に基づいて、ＳＩＰシステムの通信状態を判断する。
【選択図】図２
Description
本発明は、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの監視を行う監視装置、監視システムおよび監視プログラムに関する。
近年、通信キャリア網において、交換機による電話サービスを置き換える形で、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いたＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）サービスの提供が活発になってきている。ＶｏＩＰサービスでは、通信キャリアはユーザからの発呼・ユーザへの着呼をＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）というプロトコルで管理を行う（非特許文献１参照）。ＶｏＩＰサービスの提供において、ＳＩＰサーバは重要な役割を担っていため、ＳＩＰサーバの正常性の確認、ＳＩＰシグナリングの伝搬が正常性に行われていることを確認することは非常に重要になってきている。
通信キャリアなどＶｏＩＰサービスを展開するネットワーク上に広域分散配置されたＳＩＰサーバの障害監視に関して、ＳＩＰサーバの不良または中間経路上のネットワーク障害に起因するシグナリングメッセージのロスを検知し、ＳＩＰサーバのオペレータにアラートを上げる運用支援技術が知られている。この技術により、ＳＩＰサーバのオペレータは、ネットワーク上におけるＳＩＰサーバの障害やネットワーク障害などに起因するシグナリングメッセージのロスを検知することができる。
ＳＩＰサーバの障害やネットワーク障害などに起因するシグナリングメッセージのロスを検知するシステムとしては、ＳＩＰサーバに流入・流出する全シグナリングメッセージのパケットをキャプチャーすることにより、各ＳＩＰサーバ間のシーケンス、正常性を確認するツール・システムが知られている（例えば、非特許文献２参照）。
RFC3261「SIP:Session Initiation Protocol」. [online]. [retrieved on 2008-02-28]. Retrieved from Internet: <URL: http://www.faqs.org/rfcs/rfc3261.html＞ NetCall Monitor. [online]. Softfront. [retrieved on 2008-02-28]. Retrieved from Internet: <URL: http://www.softfront.co.jp/products/applience/netcall/netcall_monitor.html＞
RFC3261「SIP:Session Initiation Protocol」. [online]. [retrieved on 2008-02-28]. Retrieved from Internet: <URL: http://www.faqs.org/rfcs/rfc3261.html＞ NetCall Monitor. [online]. Softfront. [retrieved on 2008-02-28]. Retrieved from Internet: <URL: http://www.softfront.co.jp/products/applience/netcall/netcall_monitor.html＞
しかしながら、非特許文献２に示されるようなシステムでは、シグナリングメッセージのを全てキャプチャーする必要があり、シグナリングメッセージの数が増加してきた場合やＳＩＰサーバの数が増加した場合では、多くの拠点で大容量のデータを取得し解析する必要があり、監視の負荷が高くなるという問題があった。
本発明は上記の課題を解決するためになされたものであり、大容量のデータ（各サーバ間およびサーバ・端末装置間でやり取りされる全シグナリングメッセージ）を取得し解析することなく、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの監視を行うことができる監視装置、監視システムおよび監視プログラムを提供することを目的とする。
本発明は、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの通信状態を監視する監視装置において、前記サーバが送信および受信したメッセージの数を含んだ監視情報を記憶する記憶部と、前記記憶部より読み出した前記監視情報に基づいて、前記システムの通信状態を判断する判断部と、を備えたことを特徴とする監視装置である。
また、本発明の監視装置において、前記判断部は、前記監視情報に含まれている前記メッセージの送信数と受信数の差に基づいて、前記システムの通信状態を判断することを特徴とする。
また、本発明の監視装置において、前記判断部は、前記監視情報に含まれている前記メッセージの再送信数に基づいて、前記サーバに接続されている他のサーバ側で障害が起こっているかを判断することを特徴とする。
また、本発明の監視装置において、前記判断部は、前記監視情報に含まれている前記メッセージの再受信数に基づいて、前記サーバに接続されている端末装置側で障害が起こっているかを判断することを特徴とする。
また、本発明の監視装置において、前記判断部は、前記システムに含まれる各前記サーバについて、前記監視情報に含まれている前記メッセージの再送信数と再受信数とに基づいて、前記サーバに接続されている端末装置側で障害が起こっているか、それ以外で障害が起こっているか判断し、各前記サーバの前記判断結果に基づいて、前記システムに含まれる前記サーバ間を接続するネットワークのうち、障害が起こっている前記サーバ間のネットワークを判断することを特徴とする。
また、本発明は、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの通信状態を監視する監視システムにおいて、サーバが他の装置に送信および受信したメッセージの数を監視情報として記憶する取得装置記憶部と、前記取得装置記憶部が記憶する前記監視情報を送信する送信部とを備えたメッセージ数取得装置と、前記メッセージ数取得装置より送信された前記監視情報を受信する受信部と、前記受信部が受信した前記監視情報を記憶する記憶部と、前記記憶部より読み出した前記監視情報に基づいて、前記システムの通信状態を判断する判断部とを備えた監視装置と、を備えたことを特徴とする監視システムである。
また、本発明は、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの通信状態を監視する監視装置としてコンピュータを機能させるための監視プログラムにおいて、前記サーバが送信および受信したメッセージの数を含んだ監視情報を記憶する記憶部と、前記記憶部が記憶する前記監視情報に基づいて、前記システムの通信状態を判断する判断部としてコンピュータを機能させるための監視プログラムである。
本発明によれば、大容量のデータを取得し解析することなく、シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの監視を行うことができる。
以下、本発明の一実施形態について説明する。図１は、本実施形態におけるネットワークの構成を示した図である。図示する例では、ネットワークにはＳＩＰサーバ１と、ユーザ端末２（ＳＩＰクライアント）と、監視装置３とが含まれる。ＳＩＰサーバ１はユーザ端末２からの発呼、およびユーザ端末２への着呼の制御を行う装置である。本実施形態では、ＳＩＰサーバ１は、自身が送信・受信・再送信・再受信したＳＩＰシグナリングメッセージの数を自身が備える記憶部に記憶している。
なお、ＳＩＰサーバ１が送信・受信・再送信・再受信したＳＩＰシグナリングメッセージの数を取得するメッセージ数取得装置を別途設け、ＳＩＰサーバ１が送信・受信・再送信・再受信したＳＩＰシグナリングメッセージの数を、メッセージ数取得装置が取得してもよい。ユーザ端末２は、他のユーザ端末２に対して発呼し、ＳＩＰサーバ１によって接続が行われた後、互いに通信を行う装置である。例えば、ユーザ端末２は電話などである。監視装置３はＳＩＰサーバ１の監視を行う装置である。
また、図示する例では、ネットワークにはＳＩＰサーバ１が４台含まれており、他の３台のＳＩＰサーバ１と互いに通信を行うことができるように接続されている。また、本実施形態では、ＳＩＰサーバ１は東京と、大阪と、広島と、福岡とに設置されている。また、各ＳＩＰサーバ１は、それぞれ複数のユーザ端末２と接続している。また、監視装置３は、各ＳＩＰサーバ１と通信を行うことができるように接続されている。
図２は、本実施形態における監視装置３の構成を示した構成図である。図示する例では、監視装置３は通信部３１と、制御部３２と、記憶部３３とを備える。通信部３１は、ＳＩＰサーバ１より監視情報を受信する。監視情報は、各ＳＩＰサーバ１が送信及び受信した「ＳＩＰシグナリングメッセージ」の数、および各ＳＩＰサーバ１が再送信及び再送信した「ＳＩＰシグナリングメッセージ」の数である。制御部３２は、監視装置３の制御を行う。記憶部３３は、監視装置３が使用する情報を記憶する。
次に、ＳＩＰサーバ１が送受信するＳＩＰシグナリングメッセージについて説明する。図３は、本実施形態において、ＳＩＰサーバ１が１台のみでＳＩＰ制御を行う場合でのＳＩＰシグナリングメッセージの送信順を示したシーケンス図である。
（ステップＳ３０１）ユーザ端末２はＳＩＰサーバ１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ３０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ３０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ３０１からステップＳ３０３のシーケンスをタイプＡのシーケンスとする。
（ステップＳ３０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ３０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ３０１からステップＳ３０３のシーケンスをタイプＡのシーケンスとする。
（ステップＳ３０４）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ３０５）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ３０６）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ３０５）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ３０６）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ３０７）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ３０８）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ３０９）「Ｒｉｎｇｉｎｇ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
なお、ステップＳ３０４からステップＳ３０９のシーケンスをタイプＢ１のシーケンスとする。
（ステップＳ３０８）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ３０９）「Ｒｉｎｇｉｎｇ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
なお、ステップＳ３０４からステップＳ３０９のシーケンスをタイプＢ１のシーケンスとする。
（ステップＳ３１０）「Ｒｉｎｇｉｎｇ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＰＲＡＣＫ」メッセージを送信する。
（ステップＳ３１１）「ＰＲＡＣＫ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＰＲＡＣＫ」メッセージを送信する。
なお、ステップＳ３０８からステップＳ３１１のシーケンスをタイプＣ１のシーケンスとする。
（ステップＳ３１１）「ＰＲＡＣＫ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＰＲＡＣＫ」メッセージを送信する。
なお、ステップＳ３０８からステップＳ３１１のシーケンスをタイプＣ１のシーケンスとする。
（ステップＳ３１２）ユーザ端末２は、ＳＩＰサーバ１に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ３１３）「２００ＯＫ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ３１４）「２００ＯＫ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ３１５）「ＡＣＫ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ３１２からステップＳ３１５のシーケンスをタイプＣ１のシーケンスとする。
（ステップＳ３１３）「２００ＯＫ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ３１４）「２００ＯＫ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ３１５）「ＡＣＫ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ３１２からステップＳ３１５のシーケンスをタイプＣ１のシーケンスとする。
また、ステップＳ３１２〜３１５において、「２００ＯＫ」メッセージの代わりに「ＢＹＥ」メッセージとなり、「ＡＣＫ」メッセージの代わりに「２００ＯＫ」メッセージとなる場合もある。
図４は、本実施形態において、ＳＩＰサーバ１が２台でＳＩＰ制御を行う場合でのＳＩＰシグナリングメッセージの送信順を示したシーケンス図である。本図に関しては、ＳＩＰサーバ１が２台あるため、一方をＳＩＰサーバ１−１とし、他方をＳＩＰサーバ１−２とする。また、ＳＩＰサーバ１−１と接続しているユーザ端末をユーザ端末２−１とし、ＳＩＰサーバ１−２と接続しているユーザ端末をユーザ端末２−２とする。
（ステップＳ４０１）ユーザ端末２−１はＳＩＰサーバ１−１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ４０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ４０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２−１は、ＳＩＰサーバ１−１に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ４０１からステップＳ４０３のシーケンスをタイプＡのシーケンスとする。
（ステップＳ４０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ４０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２−１は、ＳＩＰサーバ１−１に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ４０１からステップＳ４０３のシーケンスをタイプＡのシーケンスとする。
（ステップＳ４０４）「ＡＵＴＨ」メッセージを受信したユーザ端末２−１は、ＳＩＰサーバ１−１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ４０５）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ４０６）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ４０５）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ４０６）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ４０７）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−２は、ユーザ端末２−２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ４０８）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ４０９）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ４０８）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ４０９）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ４１０）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ４１１）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ４１２）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
なお、ステップＳ４０４からステップＳ４１２のシーケンスをタイプＢ２のシーケンスとする。
（ステップＳ４１１）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ４１２）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
なお、ステップＳ４０４からステップＳ４１２のシーケンスをタイプＢ２のシーケンスとする。
（ステップＳ４１３）「Ｒｉｎｇｉｎｇ」メッセージを受信したユーザ端末２−１は、ＳＩＰサーバ１−１に対して「ＰＲＡＣＫ」メッセージを送信する。
（ステップＳ４１４）「ＰＲＡＣＫ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「ＰＲＡＣＫ」メッセージを送信する。
（ステップＳ４１５）「ＰＲＡＣＫ」メッセージを受信したＳＩＰサーバ１−２は、ユーザ端末２−２に対して「ＰＲＡＣＫ」メッセージを送信する。
なお、ステップＳ４１０からステップＳ４１５のシーケンスをタイプＣ２のシーケンスとする。
（ステップＳ４１４）「ＰＲＡＣＫ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「ＰＲＡＣＫ」メッセージを送信する。
（ステップＳ４１５）「ＰＲＡＣＫ」メッセージを受信したＳＩＰサーバ１−２は、ユーザ端末２−２に対して「ＰＲＡＣＫ」メッセージを送信する。
なお、ステップＳ４１０からステップＳ４１５のシーケンスをタイプＣ２のシーケンスとする。
（ステップＳ４１６）ユーザ端末２−１は、ＳＩＰサーバ１−１に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ４１７）「２００ＯＫ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ４１８）「２００ＯＫ」メッセージを受信したＳＩＰサーバ１−２は、ユーザ端末２−２に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ４１７）「２００ＯＫ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ４１８）「２００ＯＫ」メッセージを受信したＳＩＰサーバ１−２は、ユーザ端末２−２に対して「２００ＯＫ」メッセージを送信する。
（ステップＳ４１９）「２００ＯＫ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ４２０）「ＡＣＫ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ４２１）「ＡＣＫ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ４１６からステップＳ４２１のシーケンスをタイプＣ２のシーケンスとする。
（ステップＳ４２０）「ＡＣＫ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ４２１）「ＡＣＫ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「ＡＣＫ」メッセージを送信する。
なお、ステップＳ４１６からステップＳ４２１のシーケンスをタイプＣ２のシーケンスとする。
また、ステップＳ４１６〜４２１において、「２００ＯＫ」メッセージの代わりに「ＢＹＥ」メッセージとなり、「ＡＣＫ」メッセージの代わりに「２００ＯＫ」メッセージとなる場合もある。また、ステップＳ４１６〜ステップＳ４２１では、ユーザ端末２−１からシーケンスが開始しているが、ユーザ端末２−２からシーケンスが開始する場合もある。
次に、本実施形態におけるＳＩＰサーバ１の監視方法について説明する。本実施形態での監視方法は、サーバ障害の検出と、「ユーザ側」「非ユーザ側」での障害の検出と、サーバ間論理障害の検出との３つの検出方法を含む。なお、監視装置３が各検出方法を実施する前に各ＳＩＰサーバ１は監視装置に対して監視情報を送信する。また、ＳＩＰサーバ１より送信された監視情報を監視装置３の通信部３１は受信し、制御部３２は受信した監視情報を記憶部３３に記憶させる。
なお、先述したとおり、メッセージ数取得装置を別途設けても良い。この場合は、監視装置３が各検出方法を実施する前にメッセージ数取得装置は監視装置に対して監視情報を送信する。また、メッセージ数取得装置より送信された監視情報を監視装置３の通信部３１は受信し、制御部３２は受信した監視情報を記憶部３３に記憶させる。
なお、「ユーザ側」「非ユーザ側」の定義について図５を参照して説明する。「ユーザ側」「非ユーザ側」の定義については、着目（監視）対象のＳＩＰサーバ１に応じて定義する。図示する例では、ＳＩＰサーバ１−１，１−２と、ユーザ端末２−１，２−２とが含まれている。ＳＩＰサーバ１−１とユーザ端末２−１とが接続している。また、ＳＩＰサーバ１−２とユーザ端末２−２とが接続している。また、ＳＩＰサーバ１−１とＳＩＰサーバ１−２とが接続している。
図示する例では、ＳＩＰサーバ１−１を着目対象とする。なお、着目対象ではないＳＩＰサーバ１−２を非着目サーバと定義する。着目対象のＳＩＰサーバ１−１に接続しているユーザ端末２−１側の障害を「ユーザ側障害」と定義する。また、着目対象のＳＩＰサーバ１−１と接続しているＳＩＰサーバ１−２側の障害を「非ユーザ側障害」と定義する。
（サーバ障害の検出）
本実施形態におけるサーバ障害の検出は、ＳＩＰサーバ１毎に計測したＳＩＰシグナリングメッセージの送信数および受信数に基づいて行う。サーバ障害の検出で使用するＳＩＰシグナリングメッセージは、図３および図４で示した「ＰＲＡＣＫ」「２００ＯＫ」「ＢＹＥ」「ＡＣＫ」「ＡＵＴＨ」である。
本実施形態におけるサーバ障害の検出は、ＳＩＰサーバ１毎に計測したＳＩＰシグナリングメッセージの送信数および受信数に基づいて行う。サーバ障害の検出で使用するＳＩＰシグナリングメッセージは、図３および図４で示した「ＰＲＡＣＫ」「２００ＯＫ」「ＢＹＥ」「ＡＣＫ」「ＡＵＴＨ」である。
ＳＩＰサーバ１が正常に動作している場合、ＳＩＰサーバ１は、他の装置よりシグナリングメッセージを受信すると、受信したシグナリングメッセージに対応したシグナリングメッセージを他の装置に対して送信する。すなわち、ＳＩＰサーバ１に障害が起きていない場合は、ＳＩＰサーバ１が送信するシグナリングメッセージの数と、受信するシグナリングメッセージの数は同数となる。
ＳＩＰサーバ１で障害が起こると、ＳＩＰサーバ１は、他の装置よりシグナリングメッセージを受信した場合においても、受信したシグナリングメッセージに対応したシグナリングメッセージを他の装置に対して送信しない。または、シグナリングメッセージを受信していないにも関わらず、ＳＩＰサーバ１は他の装置にシグナリングメッセージを送信する。すなわち、ＳＩＰサーバ１に障害が起きている場合は、ＳＩＰサーバ１が送信するシグナリングメッセージの数と、受信するシグナリングメッセージの数は異なる。
以下、ＳＩＰサーバ１での障害の検出方法について説明する。
（ステップＳ１１）監視装置３の通信部３１は、ＳＩＰサーバ１より監視情報を受信する。その後、ステップＳ１２に進む。監視情報は、ＳＩＰサーバ１が送信及び送信した「ＰＲＡＣＫ」「２００ＯＫ」「ＢＹＥ」「ＡＣＫ」「ＡＵＴＨ」のメッセージの数である。
（ステップＳ１１）監視装置３の通信部３１は、ＳＩＰサーバ１より監視情報を受信する。その後、ステップＳ１２に進む。監視情報は、ＳＩＰサーバ１が送信及び送信した「ＰＲＡＣＫ」「２００ＯＫ」「ＢＹＥ」「ＡＣＫ」「ＡＵＴＨ」のメッセージの数である。
（ステップＳ１２）制御部３２は、通信部３１が受信した監視情報に基づいて、ＳＩＰサーバ１が送信した「ＰＲＡＣＫ」「２００ＯＫ」「ＢＹＥ」「ＡＣＫ」「ＡＵＴＨ」のメッセージ数の和を算出する。また、制御部３２は、通信部３１が受信した監視情報に基づいて、ＳＩＰサーバ１が受信した「ＰＲＡＣＫ」「２００ＯＫ」「ＢＹＥ」「ＡＣＫ」「ＡＵＴＨ」のメッセージ数の和を算出する。その後、ステップＳ１３に進む。
（ステップＳ１３）制御部３２は、算出した送信メッセージの和と、受信メッセージの和との差の絶対値を算出する。その後、ステップＳ１４に進む。
（ステップＳ１４）制御部３２は、予め決められている閾値と、ステップＳ１３で算出した値とを比較する。予め決められている閾値よりステップＳ１３で算出した値の方が大きければ、制御部３２は、ＳＩＰサーバ１で障害が起こっていると判断する。
（ステップＳ１４）制御部３２は、予め決められている閾値と、ステップＳ１３で算出した値とを比較する。予め決められている閾値よりステップＳ１３で算出した値の方が大きければ、制御部３２は、ＳＩＰサーバ１で障害が起こっていると判断する。
ステップＳ１１からステップＳ１４で説明したサーバ障害判定方法を式で表すと以下の通りとなる。なお、Ｅは閾値である。以下の式を満たす場合（閾値Ｅを超えた場合）、ＳＩＰサーバ１で障害が起こっていると判断する。
Ｅ＜｜（ＳＩＰサーバ１が受信したメッセージ数の総和）−（ＳＩＰサーバ１が送信したメッセージ数の総和）｜
Ｅ＜｜（ＳＩＰサーバ１が受信したメッセージ数の総和）−（ＳＩＰサーバ１が送信したメッセージ数の総和）｜
なお、閾値Ｅに関しては、システム利用者が設定する。また、シグナリングメッセージをカウントするタイミングによる誤差を踏まえて、システム利用者は閾値Ｅを決定する。
上述したとおり、ＳＩＰサーバ１より受信した監視情報に基づいてＳＩＰサーバ１の障害発生を判断することができる。
（「ユーザ側」「非ユーザ側」での障害の検出）
本実施形態における「ユーザ側」「非ユーザ側」での障害の検出は、ＳＩＰサーバ１毎に計測したＳＩＰシグナリングメッセージの再送信数および再受信数に基づいて行う。ＳＩＰサーバ間でやり取りされるＳＩＰシグナリングメッセージは、リクエストとそれに対応する応答という関係がある。例えば、図４で示した例では、ＲＩＮＧＩＮＧメッセージを受信した場合、ＰＲＡＣＫメッセージを送信する関係がある。
本実施形態における「ユーザ側」「非ユーザ側」での障害の検出は、ＳＩＰサーバ１毎に計測したＳＩＰシグナリングメッセージの再送信数および再受信数に基づいて行う。ＳＩＰサーバ間でやり取りされるＳＩＰシグナリングメッセージは、リクエストとそれに対応する応答という関係がある。例えば、図４で示した例では、ＲＩＮＧＩＮＧメッセージを受信した場合、ＰＲＡＣＫメッセージを送信する関係がある。
本実施形態では、ＳＩＰシグナリングメッセージの受信と送信との関係に着目し、図４で示した通り、ＳＩＰサーバ１が１台でＳＩＰ制御を行う場合は、ＳＩＰシグナリングメッセージのシーケンスのタイプをタイプＡ，タイプＢ１，タイプＣ１の３つに分類している。また、ＳＩＰサーバ１が２台でＳＩＰ制御を行う場合は、ＳＩＰシグナリングメッセージのシーケンスのタイプをタイプＡ，タイプＢ２，タイプＣ２の３つに分類している。
シーケンスのタイプにより「ユーザ側」「非ユーザ側」での障害の検出を行う方法について以下説明する。「ユーザ側」「非ユーザ側」の定義については、図５を参照して説明した定義と同様である。
（ステップＳ２１）監視装置３の通信部３１は、ＳＩＰサーバ１より監視情報を受信する。その後、ステップＳ２２に進む。監視情報は、「ＡＵＴＨ」「ＲＩＮＧＩＮＧ」「ＰＲＡＣＫ」「ＡＣＫ」メッセージについて、各メッセージの受信数、再受信数、送信数、再送信数である。
なお、ＳＩＰシグナリングメッセージの受信数、再受信数、送信数、再送信数について、ＳＩＰサーバ１は、ユーザ端末２（ＳＩＰサーバ１に接続している全てのユーザ端末２）に対して送受信および再送受信した数と、他のＳＩＰサーバ１に対して送受信および再送受信した数とを区別してカウントする。
ここで、着目サーバに複数の非着目サーバが接続している場合、すなわち、非ユーザ側に複数のＳＩＰサーバ１が接続している場合について説明する。非着目サーバ毎に障害を判定する場合、非着目サーバ毎に着目サーバがＳＩＰシグナリングメッセージを送信した数・受信した数・再送信した数・再受信した数をカウントする（カウント方法１）。非ユーザ側のいずれかに障害が起きていることを判断する場合、着目サーバが全ての非着目サーバに対してＳＩＰシグナリングメッセージを送信した数・受信した数・再送信した数・再受信した数をカウントする（カウント方法２）。
（ステップＳ２２）制御部３２は、通信部３１が受信した監視情報に基づいて障害の判定を行う。判定方法は以下の通りである。
・「Ａｕｔｈ」メッセージをユーザ側に対して再送信している場合は、ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡのケース）
・「ＲＩＮＧＩＮＧ」メッセージをユーザ側に対して再送信している場合は、ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＢのケース）
・「Ａｕｔｈ」メッセージをユーザ側に対して再送信している場合は、ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡのケース）
・「ＲＩＮＧＩＮＧ」メッセージをユーザ側に対して再送信している場合は、ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＢのケース）
・「ＰＲＡＣＫ」メッセージまたは「ＡＣＫ」メッセージをユーザ側に対して再送信している場合は、ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＣ２のケース）
・「ＰＲＡＣＫ」メッセージまたは「ＡＣＫ」メッセージをユーザ側から再受信している場合は、非ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＣ２のケース）
・「ＰＲＡＣＫ」メッセージまたは「ＡＣＫ」メッセージをユーザ側から再受信している場合は、非ユーザ側に障害があると判定する。（ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＣ２のケース）
以下、一例として、ＳＩＰシグナリングメッセージのシーケンスのタイプが、タイプＡの場合とタイプＢ２の場合における障害判定の根拠を説明する。
（タイプＡの場合）
図６は、本実施形態におけるＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡであり、正常にメッセージが送受信されている場合のメッセージの送信順を示したシーケンス図である。図示する例では、以下の手順でユーザ端末２とＳＩＰサーバ１とはメッセージの送受信を行っている。
図６は、本実施形態におけるＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡであり、正常にメッセージが送受信されている場合のメッセージの送信順を示したシーケンス図である。図示する例では、以下の手順でユーザ端末２とＳＩＰサーバ１とはメッセージの送受信を行っている。
（ステップＳ６０１）ユーザ端末２は、ＳＩＰサーバ１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ６０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ６０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ６０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ６０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
次に、ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡであり、「ＡＵＴＨ」メッセージがロスした場合について説明する。図７は、本実施形態におけるＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡであり、「ＡＵＴＨ」メッセージがロスした場合のメッセージの送信順を示したシーケンス図である。図示する例では、以下の手順でユーザ端末２とＳＩＰサーバ１とはメッセージの送受信を行っている。
（ステップＳ７０１）ユーザ端末２は、ＳＩＰサーバ１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ７０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。但し、送信した「ＡＵＴＨ」メッセージはユーザ端末２に届かない。
（ステップＳ７０３）ステップＳ７０２で送信した「ＩＮＶＩＴＥ」メッセージの返答メッセージである「ＡＣＫ」メッセージが届かないため、ＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを再送信する。
（ステップＳ７０４）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ７０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。但し、送信した「ＡＵＴＨ」メッセージはユーザ端末２に届かない。
（ステップＳ７０３）ステップＳ７０２で送信した「ＩＮＶＩＴＥ」メッセージの返答メッセージである「ＡＣＫ」メッセージが届かないため、ＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを再送信する。
（ステップＳ７０４）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
上述したとおり、ステップＳ７０２でＳＩＰサーバ１が送信した「ＡＵＴＨ」メッセージがユーザ端末２に届かなかった場合、ＳＩＰサーバ１は再度「ＡＵＴＨ」メッセージユーザ端末２に対して送信する。これにより、ユーザ端末２とＳＩＰサーバ１との間のネットワークで障害が起きており、「ＡＵＴＨ」メッセージがユーザ端末２に対して届かなかった場合、ＳＩＰサーバ１は再度「ＡＵＴＨ」メッセージを送信する。そのため、監視装置３は、ＳＩＰサーバ１が「ＡＵＴＨ」メッセージを再送信した場合、ユーザ端末２とＳＩＰサーバ１との間のネットワーク（ユーザ側のネットワーク）で障害が起きていると判断する。
次に、ＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡであり、「ＡＣＫ」メッセージがロスした場合について説明する。図８は、本実施形態におけるＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＡであり、「ＡＣＫ」メッセージがロスした場合のメッセージの送信順を示したシーケンス図である。図示する例では、以下の手順でユーザ端末２とＳＩＰサーバ１とはメッセージの送受信を行っている。
（ステップＳ８０１）ユーザ端末２は、ＳＩＰサーバ１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ８０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ８０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。但し、送信した「ＡＣＫ」メッセージはＳＩＰサーバ１に届かない。
（ステップＳ８０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを送信する。
（ステップＳ８０３）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。但し、送信した「ＡＣＫ」メッセージはＳＩＰサーバ１に届かない。
（ステップＳ８０４）ステップＳ８０２で送信した「ＩＮＶＩＴＥ」メッセージの返答メッセージである「ＡＣＫ」メッセージが届かないため、ＳＩＰサーバ１は、ユーザ端末２に対して「ＡＵＴＨ」メッセージを再送信する。
（ステップＳ８０５）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
（ステップＳ８０５）「ＡＵＴＨ」メッセージを受信したユーザ端末２は、ＳＩＰサーバ１に対して「ＡＣＫ」メッセージを送信する。
上述したとおり、ステップＳ８０３でユーザ端末２が送信した「ＡＣＫ」メッセージがＳＩＰサーバ１に届かなかった場合、ＳＩＰサーバ１は再度「ＡＵＴＨ」メッセージユーザ端末２に対して送信する。これにより、ユーザ端末２とＳＩＰサーバ１との間のネットワークで障害が起きており、「ＡＣＫ」メッセージがＳＩＰサーバ１に対して届かなかった場合、ＳＩＰサーバ１は再度「ＡＵＴＨ」メッセージを送信する。そのため、監視装置３は、ＳＩＰサーバ１が「ＡＵＴＨ」メッセージを再送信した場合、ユーザ端末２とＳＩＰサーバ１との間のネットワーク（ユーザ側のネットワーク）で障害が起きていると判断する。
（タイプＢの場合）
図９は、本実施形態におけるＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＢ２であり、正常にメッセージが送受信されている場合のメッセージの送信順を示したシーケンス図である。図示する例では、以下の手順でユーザ端末２−１，２−２とＳＩＰサーバ１−１，１−２とはメッセージの送受信を行っている。
図９は、本実施形態におけるＳＩＰシグナリングメッセージのシーケンスのタイプがタイプＢ２であり、正常にメッセージが送受信されている場合のメッセージの送信順を示したシーケンス図である。図示する例では、以下の手順でユーザ端末２−１，２−２とＳＩＰサーバ１−１，１−２とはメッセージの送受信を行っている。
（ステップＳ９０１）ユーザ端末２−１は、ＳＩＰサーバ１−１に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ９０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ９０３）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ９０２）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ＳＩＰサーバ１−２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ９０３）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ９０４）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−２は、ユーザ端末２−２に対して「ＩＮＶＩＴＥ」メッセージを送信する。
（ステップＳ９０５）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ９０６）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ９０５）「ＩＮＶＩＴＥ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ９０６）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「Ｔｒｙｉｎｇ」メッセージを送信する。
（ステップＳ９０７）「ＩＮＶＩＴＥ」メッセージを受信したユーザ端末２−２は、ＳＩＰサーバ１−２に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ９０８）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ９０９）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ９０８）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−２は、ＳＩＰサーバ１−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
（ステップＳ９０９）「Ｒｉｎｇｉｎｇ」メッセージを受信したＳＩＰサーバ１−１は、ユーザ端末２−１に対して「Ｒｉｎｇｉｎｇ」メッセージを送信する。
上述したとおり、正常にメッセージが送受信されている場合ではメッセージの再送信は起こらない。しかしながら、タイプＢ２では、いずれかのメッセージがロスした場合（パケットロスした場合）、ＳＩＰサーバ１−１はユーザ端末２−１（ユーザ側）に対して「ＩＮＶＩＴＥ」または「ＲＩＮＧＩＮＧ」のいずれかの再送を必ず行う。ここで、「ＩＮＶＩＴＥ」メッセージについては、タイプＡでの「ＩＮＶＩＴＥ」メッセージと区別してカウントするのは困難であるため、本実施形態では「ＲＩＮＧＩＮＧ」メッセージに着目し、監視装置３は、ＳＩＰサーバ１−１が「ＲＩＮＧＩＮＧ」メッセージをユーザ２−１に対して再送信した場合、ＳＩＰサーバ１−１とユーザ端末２−１との間のネットワーク（ユーザ側のネットワーク）で障害が起きていると判断する。
（ＳＩＰサーバ間の論理障害の検出１）
サーバ間論理リンクの障害の検出１を行う方法について以下説明する。なお、本実施形態では、図１に示した４台のＳＩＰサーバ１からなるネットワークにおけるサーバ間論理リンクの障害の検出を行う。また、４台のＳＩＰサーバ１をそれぞれＳＩＰサーバＳ１、Ｓ２、Ｓ３、Ｓ４とする。
サーバ間論理リンクの障害の検出１を行う方法について以下説明する。なお、本実施形態では、図１に示した４台のＳＩＰサーバ１からなるネットワークにおけるサーバ間論理リンクの障害の検出を行う。また、４台のＳＩＰサーバ１をそれぞれＳＩＰサーバＳ１、Ｓ２、Ｓ３、Ｓ４とする。
本実施形態におけるＳＩＰサーバ間の論理障害（サーバ間論理リンクの障害）の検出１は、先述したカウント方法１を用いてカウントした監視情報に基づいて行った、「ユーザ側」「非ユーザ側」障害検出で得た結果に基づいて行う。これにより、着目サーバと非着目サーバの組み合わせ毎に、「ユーザ側」「非ユーザ側」障害検出の結果がわかる。なお、ＳＩＰシグナリングメッセージが通過する物理経路を「サーバ間論理リンク」と定義する。
（ステップＳ１００１）監視装置３の制御部３２は、着目サーバＳ１〜Ｓ４と非着目サーバＳ１〜Ｓ４の組み合わせ毎の「ユーザ側」「非ユーザ側」障害検出結果を取得し、記憶部３３に記憶させる。その後、ステップＳ１００２に進む。
図１０は、本実施形態における「ユーザ側」「非ユーザ側」障害検出結果を示した図である。図示する例では、「ユーザ側」「非ユーザ側」障害検出結果は行列形式で示されている。行は着目サーバ名を示し、列は非着目サーバ名を示す。なお。着目サーバおよび非着目サーバの定義は図５を参照して説明した定義と同様である。また、着目サーバと非着目サーバとの間において、「非ユーザ側」の障害の場合、値を「１」とする。着目サーバと非着目サーバとの間において、障害がない場合、または「ユーザ側」の障害の場合、値を「０」とする。また、着目サーバと非着目サーバが同一の場合、そのサーバ自身での障害検出結果を示す。ＳＩＰサーバ自身に障害がある場合、値を「１」とし、障害がない場合、値を「０」とする。
図示する例では、行の値がＳ１で、列の値がＳ４の値は０である。これは着目サーバＳ１と非着目サーバＳ４の間において、障害がない、または「ユーザ側」の障害が起きていることを示す。また、行の値がＳ１で、列の値がＳ２の値は１である。これは着目サーバＳ１と非着目サーバＳ２の間において「非ユーザ側」の障害が起きていることを示す。また、行の値がＳ１で、列の値がＳ１の値は０である。これは、ＳＩＰサーバＳ１に障害が起きていないことを示す。他の値については図示する通りである。
（ステップＳ１００２）監視装置３の制御部３２は、ステップＳ１００１で記憶部３３に記憶させた「ユーザ側」「非ユーザ側」障害検出結果に基づいて、２つのＳＩＰサーバ間で互いに「非ユーザ側」で障害が起こっている組み合わせを探し出す。図示する例では、対称となる行列上の項目（例えば、行Ｓ１，列Ｓ２と、行Ｓ２，列Ｓ１との組み合わせ）の両方が１となっているＳＩＰサーバの組み合わせを探し出す。その後、制御部３２は、探し出した組み合わせのＳＩＰサーバ間で障害が起きていると判断する。
具体的には、図１０の例では、着目サーバＳ１と非着目サーバＳ３の間において「非ユーザ側」の障害が起きており、着目サーバＳ３と非着目サーバＳ１の間において「非ユーザ側」の障害が起きている。この場合、制御部３２は、ＳＩＰサーバＳ１とＳＩＰサーバＳ３との間の論理リンクで障害が起きていると判断する。また、図１０の例では、制御部３２は、ＳＩＰサーバＳ２とＳＩＰサーバＳ３との間の論理リンクでも障害が起きていると判断する。
以下、一例として、ＳＩＰサーバ間の論理障害判定の根拠を説明する。図１１および図１２は、本実施形態でのＳＩＰサーバとユーザ端末の接続状態を示した図である。図示する例では、ＳＩＰサーバＳ１とＳＩＰサーバＳ２とがネットワークにて接続されている。また、ＳＩＰサーバＳ１とユーザ端末２−１とがネットワークにて接続されている。また、ＳＩＰサーバＳ２とユーザ端末２−２とがネットワークにて接続されている。
図１１では、着目サーバはＳＩＰサーバＳ１である。図示する例では、「ユーザ側」「非ユーザ側」障害検出結果は「非ユーザ側」で障害が起きていると判定されている。よって、ユーザ端末２−１とＳＩＰサーバＳ１との間では障害が起きておらず、ＳＩＰサーバＳ１とＳＩＰサーバＳ２との間もしくはＳＩＰサーバＳ２とユーザ端末２−２との間で障害が起きていることがわかる。
また、図１２では、着目サーバはＳＩＰサーバＳ２である。図示する例では、「ユーザ側」「非ユーザ側」障害検出結果は「非ユーザ側」で障害が起きていると判定されている。よって、ユーザ端末２−２とＳＩＰサーバＳ２との間では障害が起きておらず、ＳＩＰサーバＳ１とＳＩＰサーバＳ２との間もしくはＳＩＰサーバＳ１とユーザ端末２−１との間で障害が起きていることがわかる。
よって、この場合、ＳＩＰサーバＳ１とＳＩＰサーバＳ２との間で障害が起きていることがわかる。
（ＳＩＰサーバ間の論理障害の検出２）
サーバ間論理リンクの障害の検出１を行う方法について以下説明する。なお、本実施形態では、図１に示した４台のＳＩＰサーバ１からなるネットワークにおけるサーバ間論理リンクの障害の検出を行う。また、４台のＳＩＰサーバ１をそれぞれＳＩＰサーバＳ１、Ｓ２、Ｓ３、Ｓ４とする。
サーバ間論理リンクの障害の検出１を行う方法について以下説明する。なお、本実施形態では、図１に示した４台のＳＩＰサーバ１からなるネットワークにおけるサーバ間論理リンクの障害の検出を行う。また、４台のＳＩＰサーバ１をそれぞれＳＩＰサーバＳ１、Ｓ２、Ｓ３、Ｓ４とする。
本実施形態におけるＳＩＰサーバ間の論理障害（サーバ間論理リンクの障害）の検出２は、先述したカウント方法２を用いてカウントした監視情報に基づいて行った、「ユーザ側」「非ユーザ側」障害検出で得た結果に基づいて行う。これにより、着目サーバは、非ユーザ側のいずれかに障害が起きているか否かを判断することができる。
（ステップＳ１１０１）監視装置３の制御部３２は、着目サーバをＳＩＰサーバＳ１〜Ｓ４とした場合の「ユーザ側」「非ユーザ側」障害検出結果を取得し、記憶部３３に記憶させる。その後、ステップＳ１００２に進む。
図１３は、本実施形態における「ユーザ側」「非ユーザ側」障害検出結果を示した図である。図示する例では、「ユーザ側」「非ユーザ側」障害検出結果は行列形式で示されている。行は着目サーバ名を示し、列は非着目サーバ名を示す。なお、着目サーバおよび非着目サーバの定義は図５を参照して説明した定義と同様である。また、着目サーバと非着目サーバとの間において、「非ユーザ側」に障害がある可能性がある場合は値を「？」とする。着目サーバと非着目サーバとの間において、「ユーザ側」の障害の場合は値を「１」とする。また、着目サーバと非着目サーバとの間において、障害が起きていない場合は値を「０」とする。また、着目サーバと非着目サーバが同一の場合、そのサーバ自身での障害検出結果を示す。ＳＩＰサーバ自身に障害がある場合は値を「１」とし、障害が起きていない場合は値を「０」とする。
図示する例では、行の値がＳ１で、列の値がＳ２の値は「？」である。これは着目サーバＳ１と非着目サーバＳ２の間において、「非ユーザ側」に障害がある可能性があることを示す。また、行の値がＳ２で、列の値がＳ１の値は「０」である。これは着目サーバＳ２と非着目サーバＳ１の間において障害が起きていないことを示す。また、行の値がＳ１で、列の値がＳ１の値は「０」である。これは、ＳＩＰサーバＳ１で障害が起きていないことを示す。また、行の値がＳ２で、列の値がＳ２の値は「１」である。これは、ＳＩＰサーバＳ１で障害が起きていることを示す。他の値については図示する通りである。
（ステップＳ１１０２）監視装置３の制御部３２は、ステップＳ１１０１で記憶部３３に記憶させた「ユーザ側」「非ユーザ側」障害検出結果に基づいて、対象サーバと非対象サーバを入れ替えると同一の組み合わせとなる組のＳＩＰサーバ間のネットワーク情報について更新する。図示する例では、対称となる行列上の項目（例えば、行Ｓ１，列Ｓ２と、行Ｓ２，列Ｓ１との組み合わせ）について更新する。
更新は、一方の値が「０」で他方の値が「？」の場合は両方の値を「０」とする。また、両方の値が「０」の場合はそのまま「０」とする。両方が「？」の場合はそのまま「？」とする。これは、２つの装置間のネットワークの状態は、通信の向きによらず同一の状態であるためである。また、一方の値が「０」で他方の値が「１」であることはありえないため、この場合は利用者に対してアルゴリズム自体に問題があることを通知する。
具体的には、図１３の例では、着目サーバＳ１と非着目サーバＳ４の間において「非ユーザ側」に障害がある可能性があり、着目サーバＳ４と非着目サーバＳ１の間において障害が起きていない。この場合、制御部３２は、ＳＩＰサーバＳ１とＳＩＰサーバＳ４との間の論理リンクで障害が起きていないと判断する。よって、制御部３２は、行の値がＳ１で、列の値がＳ４の値を「０」と更新する。他の値についても同様に更新する。更新後の「ユーザ側」「非ユーザ側」障害検出結果は図１４に示すとおりである。
図示する例では、行の値がＳ１で列の値がＳ２の値は「０」と更新されており、行の値がＳ１で列の値がＳ４の値は「０」と更新されており、行の値がＳ１で列の値がＳ２の値は「０」と更新されており、行の値がＳ３で列の値がＳ２の値は「０」と更新されており、行の値がＳ３で列の値がＳ４の値は「０」と更新されている。
（ステップＳ１１０３）監視装置３の制御部３２は、ステップＳ１１０２で更新した「ユーザ側」「非ユーザ側」障害検出結果に基づいて、「？」の値を特定する。各行または各列に「？」が１つのみ存在する場合は、その「？」を「１」に更新する。
具体的には、図１４の例では、行Ｓ１において、値が「？」である列は列Ｓ３のみである。この場合、制御部３２は、ＳＩＰサーバＳ１とＳＩＰサーバＳ３との間の論理リンクで障害が起きていると判断する。よって、制御部３２は、行の値がＳ１で列の値がＳ３の値を「１」と更新する。他の値についても同様に更新する。更新後の「ユーザ側」「非ユーザ側」障害検出結果は図１５に示すとおりである。
図示する例では、行の値がＳ１で列の値がＳ３の値は「１」と更新されており、行の値がＳ３で列の値がＳ１の値は「１」と更新されている。
（ステップＳ１１０４）監視装置３の制御部３２は、ステップＳ１１０２で更新した「ユーザ側」「非ユーザ側」障害検出結果に基づいて、障害が起きている箇所を判断する。判断方法は、値が「１」である箇所は障害が起きていると判断し、値が「０」である箇所は障害が起きていないと判断し、値が「？」である箇所は障害が起きている可能性があると判断する。
具体的には、図１５の例では、行の値がＳ１で列の値がＳ２の値は「０」である。よって、制御部３２は、サーバＳ１とサーバＳ２の間において、障害が起きていないと判断する。また、行の値がＳ１で列の値がＳ３の値は「１」である。よって、制御部３２は、サーバＳ１とサーバＳ３の間において障害が起きていると判断する。また、行の値がＳ１で列の値がＳ１の値は「０」である。よって、制御部３２は、サーバＳ１とサーバＳ１に接続しているユーザ端末では障害が起きていないと判断する。また、行の値がＳ２で列の値がＳ２の値は「１」である。よって、制御部３２は、サーバＳ２またはサーバＳ２に接続しているユーザ端末では障害が起きていると判断する。
上述したとおり、「ユーザ側」「非ユーザ側」障害検出で得た結果に基づいて、ＳＩＰサーバ間の論理障害を判断することができる。
以上、説明したとおり、本実施形態によれば、大容量のデータを取得し解析することなく、ＳＩＰサーバの監視を行うことができる。
なお、上述した実施形態における監視装置の機能全体あるいはその一部は、これらの機能実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時刻の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時刻プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
なお、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
例えば、本実施形態では、ＳＩＰプロトコルを使用するＳＩＰシステムを例として説明したが、ＳＩＰプロトコルに関わらず、各ノード間でのメッセージのやり取りの手続きが決められた他のシグナリングメッセージをやり取りするシステムにおいても本発明を適用することができる。
１・・・ＳＩＰサーバ、２・・・ユーザ端末、３・・・監視装置、３１・・・通信部、３２・・・制御部、３３・・・記憶部
Claims (7)
- シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの通信状態を監視する監視装置において、
前記サーバが送信および受信したメッセージの数を含んだ監視情報を記憶する記憶部と、
前記記憶部より読み出した前記監視情報に基づいて、前記システムの通信状態を判断する判断部と、
を備えたことを特徴とする監視装置。 - 前記判断部は、前記監視情報に含まれている前記メッセージの送信数と受信数の差に基づいて、前記システムの通信状態を判断する
ことを特徴とする請求項１に記載の監視装置。 - 前記判断部は、前記監視情報に含まれている前記メッセージの再送信数に基づいて、前記サーバに接続されている他のサーバ側で障害が起こっているかを判断する
ことを特徴とする請求項１または請求項２に記載の監視装置。 - 前記判断部は、前記監視情報に含まれている前記メッセージの再受信数に基づいて、前記サーバに接続されている端末装置側で障害が起こっているかを判断する
ことを特徴とする請求項１から請求項３のいずれか１項に記載の監視装置。 - 前記判断部は、前記システムに含まれる各前記サーバについて、前記監視情報に含まれている前記メッセージの再送信数と再受信数とに基づいて、前記サーバに接続されている端末装置側で障害が起こっているか、それ以外で障害が起こっているか判断し、各前記サーバの前記判断結果に基づいて、前記システムに含まれる前記サーバ間を接続するネットワークのうち、障害が起こっている前記サーバ間のネットワークを判断する
ことを特徴とする請求項１または請求項２のいずれか１項に記載の監視装置。 - シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの通信状態を監視する監視システムにおいて、
サーバが他の装置に送信および受信したメッセージの数を監視情報として記憶する取得装置記憶部と、前記取得装置記憶部が記憶する前記監視情報を送信する送信部とを備えたメッセージ数取得装置と、
前記メッセージ数取得装置より送信された前記監視情報を受信する受信部と、前記受信部が受信した前記監視情報を記憶する記憶部と、前記記憶部より読み出した前記監視情報に基づいて、前記システムの通信状態を判断する判断部とを備えた監視装置と、
を備えたことを特徴とする監視システム。 - シグナリングメッセージをやり取りするサーバと端末装置からなるシステムの通信状態を監視する監視装置としてコンピュータを機能させるための監視プログラムにおいて、
前記サーバが送信および受信したメッセージの数を含んだ監視情報を記憶する記憶部と、
前記記憶部が記憶する前記監視情報に基づいて、前記システムの通信状態を判断する判断部と
としてコンピュータを機能させるための監視プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008079048A JP5225725B2 (ja) | 2008-03-25 | 2008-03-25 | 監視装置、監視システムおよび監視プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008079048A JP5225725B2 (ja) | 2008-03-25 | 2008-03-25 | 監視装置、監視システムおよび監視プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009239343A true JP2009239343A (ja) | 2009-10-15 |
| JP5225725B2 JP5225725B2 (ja) | 2013-07-03 |
Family
ID=41252835
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008079048A Expired - Fee Related JP5225725B2 (ja) | 2008-03-25 | 2008-03-25 | 監視装置、監視システムおよび監視プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5225725B2 (ja) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63245148A (ja) * | 1987-03-31 | 1988-10-12 | Tokyo Electric Co Ltd | 通信システムの通信異常監視装置 |
| JP2000151607A (ja) * | 1998-09-11 | 2000-05-30 | Hitachi Ltd | Ｉｐパケット通信装置及び光ネットワ―ク |
| JP2001356801A (ja) * | 2000-06-13 | 2001-12-26 | Toshiba Corp | プラント監視装置および記憶媒体 |
| JP2003158550A (ja) * | 2001-07-23 | 2003-05-30 | Primary Networks Inc Dba Acme Packet Inc | リアルタイム・トランスポート・プロトコル・データフローのフロー品質統計値を求めるシステム及び方法 |
| JP2007134966A (ja) * | 2005-11-10 | 2007-05-31 | Oki Electric Ind Co Ltd | メッセージ入力管理装置、メッセージ入力管理方法、メッセージ入力管理プログラム及びｉｐ交換機 |
| JP2008035266A (ja) * | 2006-07-28 | 2008-02-14 | Ibm Japan Ltd | 情報システムの状態を解析する技術 |
-
2008
- 2008-03-25 JP JP2008079048A patent/JP5225725B2/ja not_active Expired - Fee Related
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63245148A (ja) * | 1987-03-31 | 1988-10-12 | Tokyo Electric Co Ltd | 通信システムの通信異常監視装置 |
| JP2000151607A (ja) * | 1998-09-11 | 2000-05-30 | Hitachi Ltd | Ｉｐパケット通信装置及び光ネットワ―ク |
| JP2001356801A (ja) * | 2000-06-13 | 2001-12-26 | Toshiba Corp | プラント監視装置および記憶媒体 |
| JP2003158550A (ja) * | 2001-07-23 | 2003-05-30 | Primary Networks Inc Dba Acme Packet Inc | リアルタイム・トランスポート・プロトコル・データフローのフロー品質統計値を求めるシステム及び方法 |
| JP2007134966A (ja) * | 2005-11-10 | 2007-05-31 | Oki Electric Ind Co Ltd | メッセージ入力管理装置、メッセージ入力管理方法、メッセージ入力管理プログラム及びｉｐ交換機 |
| JP2008035266A (ja) * | 2006-07-28 | 2008-02-14 | Ibm Japan Ltd | 情報システムの状態を解析する技術 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP5225725B2 (ja) | 2013-07-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7843842B2 (en) | Method and system for initiating a remote trace route | |
| CN101702712B (zh) | 一种探测技术与语音呼叫备份联动方法及装置 | |
| JP2006340348A (ja) | Ｖｏｉｐネットワークの特性付け | |
| US7508817B2 (en) | Method and apparatus for measuring data transport quality over an internet protocol | |
| US8737237B2 (en) | Network fault detection method and apparatus | |
| JP2007267151A (ja) | 異常トラフィック検知装置、異常トラフィック検知方法および異常トラフィック検知プログラム | |
| JP4857300B2 (ja) | 監視装置、監視システムおよび監視プログラム | |
| JP5225725B2 (ja) | 監視装置、監視システムおよび監視プログラム | |
| EP2738986B1 (en) | Systems and methods of routing IP telephony data packet communications | |
| US20140153562A1 (en) | Systems and methods of routing ip telephony data packet communciations | |
| JP2009188674A (ja) | 送信装置、受信装置、動画音声伝送品質評価方法および動画音声伝送品質評価プログラム | |
| US20140153409A1 (en) | Systems and methods of routing ip telephony data packet communciations | |
| JP6127615B2 (ja) | サーバ、ネットワーク機器、サーバシステム、通信先決定方法 | |
| CN113890950A (zh) | Voip终端网络检测方法、装置和voip终端 | |
| JP2011188450A (ja) | ネットワーク監視装置 | |
| JP5305533B2 (ja) | 疎通試験装置 | |
| JP6985606B2 (ja) | 障害検知装置、障害検知方法、および障害検知プログラム | |
| JP5018177B2 (ja) | Ｉｐ電話端末およびプログラム | |
| JP5798137B2 (ja) | 輻輳制御方法および発呼サーバ | |
| JP6340973B2 (ja) | 通信課金システムおよび通信課金方法 | |
| KR101368693B1 (ko) | Ｉｍｓ망에서 트래픽 처리 방법 및 장치 | |
| KR101705225B1 (ko) | 통신단말의 호 처리 부가서비스를 이용한 VoIP 무료통화 방법 | |
| JP6340972B2 (ja) | 通信課金システムおよび通信課金方法 | |
| CA2833904C (en) | Systems and methods of routing ip telephony data packet communications | |
| JP2012003575A (ja) | 災害情報通知システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100716 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20100720 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120221 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120605 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120803 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20120806 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20121002 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121228 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20130104 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130122 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20130125 |
|
| 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: 20130305 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130313 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5225725 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160322 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |