JP2015012477A - 通信制御システム、通信制御装置及び通信制御プログラム - Google Patents

Abstract

【課題】セッション確立プロトコルを用いて他ノード装置の状態を認識する際に、対象ノード装置に代わって応答を行うことができるようにする。【解決手段】本発明は、中継装置を介して第１のノード装置がセッション制御プロトコルを用いて１又は複数の第２のノード装置の状態確認を行う通信制御システムで、中継装置が、セッション制御プロトコルを用いて定期的に１又は複数の第２のノード装置の状態確認を行う状態確認手段と、状態確認手段により確認された各第２のノード装置の状態を第２のノード装置毎に記憶する状態管理手段と、第１のノード装置からの第２のノード装置宛の状態確認リクエストに対して、対応の第２のノード装置の状態に応じた応答信号を第１のノード装置に返信する応答返信手段とを備える。【選択図】 図１

Description

本発明の通信制御システム、通信制御装置及び通信制御プログラムに関し、例えば、セッション確立プロトコルを用いて、他ノードの状態を認識する通信制御システム、通信制御装置及び通信制御プログラムに適用し得るものである。

例えばＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を採用したネットワーク内において、複数のノード装置同士が、ＳＩＰのＯＰＴＩＯＮＳメソッドを利用して他ノード装置の障害状態を認識するヘルスチェック方法がある（非特許文献１参照）。

例えば、あるノード装置が、ヘルスチェック対象の宛先にＳＩＰ ＯＰＴＩＯＮＳリクエストメッセージ（以下、ＯＰＴＩＯＮＳリクエストと呼ぶ。）を含むパケットを送信する。ＯＰＴＩＯＮＳリクエストを受信したノード装置は、ＯＰＴＩＯＮＳリクエストの宛先を確認し、自身宛である場合（すなわち、ＯＰＴＩＯＮＳリクエストが自身宛のヘルスチェックである場合）には送信元のノード装置に対してＳＩＰ ＯＰＴＩＯＮＳ応答メッセージ（以下、ＯＰＴＩＯＮＳ応答と呼ぶ。）を返信し、自身宛でない場合には宛先に向けてＯＰＴＩＯＮＳリクエスト転送している。

ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ） ＲＦＣ３２６１

ところで、例えばＳＩＰを採用したそれぞれ異なる事業者ネットワーク間の通信方式の差分を吸収するために、複数のネットワーク間のＮＮＩ（Ｎｅｔｗｏｒｋ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）に、ＳＩＰ−ＡＬＧ（ＳＩＰ Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｇａｔｅｗａｙ）装置を配置する場合がある。

ＳＩＰ−ＡＬＧ装置がヘルスチェックでないＯＰＴＩＯＮＳリクエストを受信及び転送する際、転送先ノード装置が障害等で機能していない場合、転送先ノード装置からのＯＰＴＩＯＮＳ応答が期待できないという課題が生じ得る。この場合、要求元は、要求先の状態を確認することができないという問題が生じ得る。

また、ＳＩＰ−ＡＬＧ装置は、ＯＰＴＩＯＮＳリクエストの送信側のノード装置から再送リクエスト等を受信した場合、再度ＯＰＴＩＯＮＳリクエストを宛先に向けて転送することになるため、リクエスト送信タイマ等の不要リソースの確保及びネットワークの輻輳が懸念される。

そのため、上記課題に鑑み、セッション確立プロトコルを用いて他ノード装置の状態を認識する際に、対象とするノード装置が応答できない場合でも、当該ノード装置に代わって応答を行うことができ、制御信号を終端することができる通信制御システム、通信制御装置及び通信制御プログラムが求められている。

かかる課題を解決するために、第１の本発明は、中継装置を介して、第１のノード装置が、セッション制御プロトコルを用いて、１又は複数の第２のノード装置の状態確認を行う通信制御システムにおいて、中継装置が、セッション制御プロトコルを用いて、定期的に、１又は複数の第２のノード装置の状態確認を行う状態確認手段と、状態確認手段により確認された各第２のノード装置の状態を第２のノード装置毎に記憶する状態管理手段と、第１のノード装置から受信した第２のノード装置宛の状態確認リクエストに対して、状態管理手段における対応の第２のノード装置の状態に応じた応答信号を第１のノード装置に返信する応答返信手段とを備えることを特徴とする通信制御システムである。

第２の本発明は、第１のノード装置と第２のノード装置との間でセッション制御プロトコルに係るメッセージを中継する中継装置の通信制御装置において、セッション制御プロトコルを用いて、定期的に、１又は複数の第２のノード装置の状態確認を行う状態確認手段と、状態確認手段により確認された各第２のノード装置の状態を第２のノード装置毎に記憶する状態管理手段と、第１のノード装置から受信した第２のノード装置宛の状態確認リクエストに対して、状態管理手段における対応の第２のノード装置の状態に応じた応答信号を第１のノード装置に返信する応答返信手段とを備えることを特徴とする通信制御装置である。

第３の本発明は、第１のノード装置と第２のノード装置との間でセッション制御プロトコルに係るメッセージを中継する中継装置の通信制御プロトコルにおいて、コンピュータを、セッション制御プロトコルを用いて、定期的に、１又は複数の第２のノード装置の状態確認を行う状態確認手段、状態確認手段により確認された各第２のノード装置の状態を第２のノード装置毎に記憶する状態管理手段、第１のノード装置から受信した第２のノード装置宛の状態確認リクエストに対して、状態管理手段における対応の第２のノード装置の状態に応じた応答信号を第１のノード装置に返信する応答返信手段として機能させることを特徴とする通信制御プログラムである。

本発明によれば、セッション確立プロトコルを用いて他ノード装置の状態を認識する際に、対象とするノード装置が応答できない場合でも、当該ノード装置に代わって応答を行うことができ制御信号を終端することができる。

実施形態に係る通信制御システムの全体構成を示す全体構成図である。 実施形態に係るゲートウェイ装置の内部構成を示す内部構成図である。 実施形態に係る状態確認条件を説明する説明図である。 実施形態に係る状態管理情報の構成を示す構成図である。 実施形態に係るノード装置の内部構成を示す内部構成図である。 実施形態に係る通信制御システムにおけるノード装置の状態確認処理の動作を説明する説明図である。 実施形態のゲートウェイ装置がノード装置の状態確認処理の一例を示すシーケンス図である（その１）。 実施形態のゲートウェイ装置がノード装置の状態確認処理の一例を示すシーケンス図である（その２）。 実施形態に係る通信制御システムにおけるノード装置の状態確認処理を示すシーケンス図である。 実施形態のゲートウェイ装置における宛先判定処理を示すフローチャートである。 実施形態のゲートウェイ装置がＲｅｑｕｅｓｔ−ＵＲＩのｈｏｓｔ部のチェックのより詳細な処理を示すフローチャートである。

（Ａ）主たる実施形態
以下では、本発明の通信制御システム、通信制御装置及び通信制御プログラムの実施形態を、図面を参照しながら詳細に説明する。

この実施形態では、ネットワークにおけるセッション確立プロトコルとしてＳＩＰを採用する場合の実施形態を例示する。

（Ａ−１）実施形態の構成
（Ａ−１−１）全体構成
図１は、実施形態に係る通信制御システムの全体構成を示す全体構成図である。図１において、実施形態に係る通信制御システム１００は、中継装置としてのゲートウェイ装置１、ノード装置２、ノード装置３−１及び３−２を有する。

図１において、実施形態に係る通信制御システム１００は、それぞれ異なる事業者のネットワークＡとネットワークＢとが接続するネットワークを想定する。

なお、図１では、２個のネットワークが接続する場合を例示するが、３個以上のネットワークが接続するものであっても良い。３個以上のネットワークが存在する場合、複数のネットワークが接続する各ＮＮＩとしてゲートウェイ装置１が配置される。

ネットワークＡとネットワークＢとはそれぞれ、セッション確立プロトコルとしてＳＩＰを採用するネットワークである。そのため、ネットワークＡとネットワークＢには、ＳＩＰを用いたセッション確立処理を行う１又は複数のサーバを有する。図１の例では、説明を容易にするため、ネットワークＡにはＳＩＰサーバとして機能するノード装置２が存在するものとして、ネットワークＢにはＳＩＰサーバとして機能するノード装置３−１及び３−２が存在するものとする。

ノード装置２は、ネットワークＡに存在するセッション確立サーバであり、例えばＳＩＰサーバである。ＳＩＰサーバとしてのノード装置２は、要求されたセッションを確立することに加えて、他のノード装置の状態を確認する状態確認機能（ヘルスチェック機能）を有する。

ノード装置３−１及び３−２はそれぞれ、ネットワークＢに存在するセッション確立サーバであり、例えばＳＩＰサーバである。ＳＩＰサーバとして機能するノード装置３−１及び３−２も、ノード装置２と同様に、要求されたセッションを確立することに加えて、他ノード装置の状態を確認する状態確認機能（ヘルスチェック機能）を有する。

なお、図１では、説明を容易にするために、ネットワークＡに存在するノード装置２が、ゲートウェイ装置１を介して、別のネットワークＢに存在するノード装置３−１及び３−２の状態確認を行う場合を例示している。つまり、一方のネットワーク上のノード装置が、ゲートウェイ装置１を介して、他方のネットワーク上の他ノード装置の状態確認を行う場合を示している。

勿論、ノード装置２、ノード装置３−１、ノード装置３−２は、同一ネットワーク上の他ノード装置の状態確認を行うようにしても良い。又、ネットワークＢ上のノード装置３−１、ノード装置３−２が、別のネットワークＡ上のノード装置２の状態確認を行うようにしても良い。さらに、ゲートウェイ装置１もＳＩＰ ＵＡ（ＳＩＰ ユーザエージェント）と見ることができるので、ノード装置２が、ゲートウェイ装置１の状態確認を行うようにしても良い。

ここで、他ノード装置の状態確認とは、対象とするノード装置の動作可能な状態（すなわち、セッション確立プロトコルによる処理動作が可能な状態）であるか否かを確認することを意味する。

また、ノード装置２とノード装置３−１及び３−２とが行う他ノード装置の状態確認方法（ヘルスチェック方法）の一例として、ＳＩＰのＯＰＴＩＯＮＳメソッドを用いた方法を適用することができる。ＯＰＴＩＯＮＳメソッドは、ＲＦＣ３２６１で定義されるＳＩＰメソッドの１つである。ＯＰＴＩＯＮＳメソッドの機能は、相手装置との間でセッションの確立動作を行うことなく、相手装置の状態等を認識することができる。例えば、図１に示すように、状態確認の問い合せを行うノード装置２は、ＯＰＴＩＯＮＳリクエストのＲｅｑｕｅｓｔ−ＵＲＩに状態確認の対象とする相手のノード装置３−１又は３−２のＵＲＩ（例えば、ｓｉｐ−ｕｒｉ、ｓｉｐｓ−ｕｒｉ等）を設定したＳＩＰメッセージを含むパケット（図１ではＳＩＰと表記する。）を、ゲートウェイ装置１を介して送信する。なお、対象とする複数のノード装置のＵＲＩを同時に設定するようにしても良い。ＯＰＴＩＯＮＳリクエストを受信したノード装置３−１又は３−２が正常に動作している場合、ＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳ応答（例えば、ステータスコードが「２００」の応答等であり、図１では２００ ＯＰＴＩＯＮＳと表記する。）を、ゲートウェイ装置１を介して要求元に返信する。このように、ＯＰＴＩＯＮＳリクエストに対してＯＰＴＩＯＮＳ応答が返信されることで、要求元のノード装置２は、要求先のノード装置３−１及び３−２が正常に動作していることを認識できる。

ゲートウェイ装置１は、ネットワークＡに存在し、ネットワークＡ上のノード装置２と、ネットワークＢ上のノード装置３−１及び３−２との間でＳＩＰメッセージを含むパケットの中継を行うものである。ゲートウェイ装置１は、例えばＳＩＰ−ＡＬＧ装置として機能する。

ＳＩＰ−ＡＬＧ装置として機能するゲートウェイ装置１は、ネットワークＡとネットワークＢとの間のＮＮＩに配置され、ネットワークＡとネットワークＢとの間の通信方式の差分を吸収するものである。例えば、それぞれのネットワークのＩＰアドレスがＩＰｖ４とＩＰｖ６と異なる場合、ＳＩＰ−ＡＬＧ装置としてのゲートウェイ装置１はＩＰアドレスの相互変換を行い、ＳＩＰメッセージを含むパケットの中継を行う。アドレス変換技術は、特に限定されるものではなく種々の技術を広く適用することができる。

（Ａ−１−２）ゲートウェイ装置１の内部構成
図２は、この実施形態に係るゲートウェイ装置１の内部構成を示す内部構成図である。図２において、実施形態に係るゲートウェイ装置１は、制御部１０、通信部１５を有する。

通信部１５は、制御部１０の制御を受けて、ネットワークＡ、ネットワークＢの通信回線との間でパケットの送受信を行うものである。

制御部１０は、ゲートウェイ装置１全体の機能を司るものである。制御部１０は、例えば、ＣＰＵ、記憶装置、入出力インタフェース部等を有するものであり、ＣＰＵがＲＯＭに格納される処理プログラムを実行するソフトウェア処理により、ゲートウェイ装置１は図２に示す機能を実現することができる。処理プログラムはインストールにより構築することができ、その場合でも図２のように示すことができる。

制御部１０は、図２に例示するように、状態管理部１１、記憶部１２を有する。

状態管理部１１は、通信部１５を介して、受信したＯＰＴＩＯＮＳリクエストが自身宛のヘルスチェックである場合には、ＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳ応答を行ったり、又受信したＯＰＴＩＯＮＳリクエストが他ノード装置宛の場合には、他ノード装置の状態管理を行ったりするものである。

状態管理部１１は、定期的に、対象とする１又は複数のノード装置の状態を、ＳＩＰ ＯＰＴＩＯＮＳを用いて確認し、各ノード装置の状態管理を行うものである。また、状態管理部１１は、受信したＯＰＴＩＯＮＳリクエストが他ノード装置宛の場合であって、ＯＰＴＩＯＮＳリクエストの宛先のノード装置の状態管理をしているものであるとき、自身が管理している状態管理情報を参照して、要求元のノード装置に対してＯＰＴＩＯＮＳレスポンスを応答するものである。

つまり、状態管理部１１は、定期的に、他ノード装置宛のＯＰＴＩＯＮＳリクエストを他ノード装置に転送して、他ノード装置の状態管理を行う。当該他ノード装置からＯＰＴＩＯＮＳ応答がある場合、状態管理部１１は当該他ノード装置が「運用中」であると管理する。一方、当該他ノード装置からＯＰＴＩＯＮＳ応答がない場合、状態管理部１１は当該他ノード装置が「閉塞中」であると管理する。

また、状態管理部１１は、受信したＯＰＩＯＮＳリクエストの要求先のノード装置の状態管理を行っており、要求先ノード装置の状態管理情報に基づいて、受信したＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳレスポンスを要求元に返信する。これにより、ゲートウェイ装置１がＯＰＴＩＯＮＳリクエストを終端できるため、要求元のノード装置に対して要求先のノード装置に障害が生じた旨を知らせることができる。また、要求元のノード装置からのＯＰＴＩＯＮＳリクエストの再送を軽減できるため、リクエストに係るリソース負荷の軽減及びネットワーク全体の輻輳回避を図ることができる。

状態管理部１１は、リクエスト判定部１１１、状態管理情報検索部１１２、状態確認部１１３、障害検出部１１４、レスポンス返信部１１５、障害回復検出部１１６を有する。

リクエスト判定部１１１は、受信したＳＩＰメッセージのメソッド検査、ヘッダ検査等を行うものである。リクエスト判定部１１１は、受信したＳＩＰメッセージがＯＰＴＩＯＮＳメソッドのリクエストであること、ＯＰＴＩＯＮＳリクエストの宛先が自身宛であるか又は他ノード装置であるかを判定する。

状態管理情報検索部１１２は、リクエスト判定部１１１により受信したＯＰＴＩＯＮＳリクエストの宛先が自身でない場合（すなわち、宛先が他ノード装置の場合）、記憶部１２の状態管理情報１２２を参照して、ＯＰＴＩＯＮＳリクエストの宛先のノード装置の状態管理情報を検索するものである。

状態確認部１１３は、記憶部１２に記憶される状態確認条件１２１に従って、１又は複数の他ノード装置の状態確認（ヘルスチェック）を行うものである。状態確認部１１３の処理については、動作の項で詳細に説明する。

障害検出部１１４は、対象とする１又は複数のノード装置に送信したＯＰＴＩＯＮＳリクエストに対して、要求先のノード装置からの応答状況に基づいて、当該ノード装置の障害検出を行うものである。障害検出部１１４は、状態確認条件１２１に設定された障害検出条件に従って障害検出を行う。障害検出部１１４による障害検出の方法の詳細については後述する。

レスポンス返信部１１５は、受信したＯＰＴＩＯＮＳリクエストの宛先が自身である場合（自身宛のヘルスチェックである場合）、ＯＰＴＩＯＮＳ応答を要求元のノード装置に送信する。

レスポンス返信部１１５は、受信したＯＰＴＩＯＮＳリクエストの宛先が、自身が状態管理するノード装置である場合、状態管理検索部１１２による検索結果に基づいて、ＯＰＴＩＯＮＳレスポンスを返信するものである。

例えば、対象とするノード装置の状態が「運用中」である場合には、レスポンス返信部１１５は、ステータスコードが「２００」の応答をＯＰＴＩＯＮＳレスポンスとして返信する。また、対象とするノード装置の状態が「閉塞中」の場合（すなわち、障害が検出された場合）、レスポンス返信部１１５は、ステータスコードが「５０３」の応答をＯＰＴＩＯＮＳレスポンスとして返信する。

障害回復検出部１１６は、障害検出された他ノード装置に対してＯＰＴＩＯＮＳリクエストを送信し、ＯＰＴＩＯＮＳリクエストに対してＯＰＴＩＯＮＳ応答があった場合に、当該他ノード装置の障害回復を検出する。障害回復検出部１１６は、状態確認条件１２１に設定された障害回復条件に従って障害回復を検出する。

記憶部１２は、処理プログラムや処理に必要なデータ、状態確認条件１２１、状態管理情報１２２等を記憶するものである。

状態確認条件１２１は、ゲートウェイ装置１と他ノード装置との間のＳＩＰ ＯＰＴＩＯＮＳを用いた状態確認（ヘルスチェック）の実施条件である。上述したように、状態管理部１１は、状態確認条件１２１に従って他ノード装置の状態確認（ヘルスチェック）を行う。

図３は、実施形態に係る状態確認条件１２１を説明する説明図である。図３に示すように、実施形態に係る状態確認条件１２１は、項目として、起動条件２０１、実施周期２０２、成功条件２０３、再送期間２０４、障害検出条件２０５、障害回復条件２０６、カウント条件２０６を有する。

起動条件２０１は、ゲートウェイ装置１が他ノード装置の状態の保持及び管理を行う開始条件である。例えば、起動条件２０１は、他ノード装置に対する状態確認（ヘルスチェック）の実施の有無とすることができる。具体的には、対象とするノード装置の設定を行うようにしても良い、又は、ゲートウェイ装置１が受信したＯＰＴＩＯＮＳリクエストの宛先が他ノード装置宛である場合、ゲートウェイ装置１は当該ノード装置の状態管理を開始するようにしても良い。

実施周期２０２、対象とするノード装置の状態確認（ヘルスチェック）を周期的に実施する間隔である。実施周期２０２には、ヘルスチェックを実施するため、ＯＰＴＩＯＮＳリクエストの送信間隔が設定されている。実施周期２０２に設定される時間は、運用に応じて任意に決定することができる。

成功条件２０３は、対象とするノード装置が正常に動作していることを判断するための条件である。例えば、成功条件２０３は、ゲートウェイ装置１（ＳＩＰ−ＳＬＧ装置）が送信したＯＰＴＩＯＮＳリクエストに対して、ステータスコード「２００」以上のレスポンスをゲートウェイ装置１が受信した場合と設定することができる。レスポンスについては、ステータスコード「２００」の２００応答に限定されるものではなく、暫定応答（例えばステータスコード１８０応答等）を除いて、要求先のノード装置から応答があった場合、当該ノード装置は正常に動作していると判断する。

再送期間２０４は、ゲートウェイ装置１がＯＰＴＩＯＮＳリクエストを再送する期間である。再送期間２０４に設定される時間は、運用に応じて任意に決定することができる。

障害検出条件２０５は、対象とするノード装置が正常に動作していないことを判断するための条件である。例えば、障害検出条件２０５は、ゲートウェイ装置１が対象とするノード装置宛に送信したＯＰＴＩＯＮＳリクエストの送信状況や又は応答状況に基づいて決定することができる。ここでは、２種類の障害検出条件を例示する。

第１の障害検出条件２０５の例は、周期的に実施される状態確認時間（ヘルスチェック時間）が再送期間で設定された時間を越えた場合である。つまり、ＯＰＴＩＯＮＳリクエストを用いた状態確認（ヘルスチェック）は、ゲートウェイ装置１が周期的に行う。ゲートウェイ装置１が所定の送信間隔で送信するＯＰＴＩＯＮＳリクエストの再送時間が、所定のタイムアウト時間を越えた場合、当該ノードに障害が発生したと判断する。これは、ゲートウェイ装置１のＯＰＴＩＯＮＳリクエストの再送時間に基づいて、対象とするノード装置の障害を検出する条件と言い換えることができる。

第２の障害検出条件２０５の例は、ＯＰＴＩＯＮＳリクエストに対する応答を再送期間内に受信しない場合である。例えば、第２の障害検出条件２０５は、前回の実施周期で送信したＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳ応答が、今回の実施周期まで未受信である場合と設定できる。この場合、前回の実施周期で送信したＯＰＴＩＯＮＳリクエストの再送を停止することができる。これは、ゲートウェイ装置１のＯＰＴＩＯＮＳリクエストに対する応答状況に基づいて、対象とするノード装置の障害を検出する条件と言い換えることができる。

また、障害検出条件２０５は、後述するカウンタ条件２０７に設定される障害検出カウント条件に従って、ノード装置の障害が検出される。例えば、障害検出カウント条件が１回の場合、上記第１の障害検出条件又は上記第２の障害検出条件が１回生じたときに、ノード装置の障害と判断する。

障害回復条件２０６は、障害が生じたノード装置が回復したと判断するための条件である。例えば、障害回復条件２０６は、障害発生したノード装置に対して、ゲートウェイ装置１が実施周期に従ってＯＰＴＩＯＮＳリクエストを送信し、ステータスコード「２００」以上のレスポンスを受信した場合に当該ノード装置が障害回復したと判断する。

また、障害回復条件２０６は、後述するカウンタ条件２０７に設定される障害回復カウント条件に従って、ノード装置の障害回復が検出される。例えば、障害回復カウント条件が２回の場合、対象とするノード装置から連続して２回のレスポンスを受信したとき、当該ノード装置の障害回復を判断する。

カウント条件２０７は、対象とするノード装置の障害、障害回復を判断するための、障害検出条件２０５、障害回復条件２０６を満たす回数に関する条件である。カウント条件２０７は、ノード装置の障害発生を判断するための障害検出カウント条件と、ノード装置の障害回復を判断するための障害回復カウント条件とを有する。

この実施形態では、例えば障害検出カウント条件は１回とする。つまり、障害検出条件２０５を満たす事象が１回検出されると、対象とするノード装置に障害が発生したと判断する。また例えば、障害回復カウント条件は２回とする。つまり、障害回復条件２０６を満たす事象が２回連続して検出されると、対象とするノードは障害回復したと判断する。

状態管理情報１２２は、ゲートウェイ装置１による他ノード装置の状態管理に関する情報である。

図４は、実施形態に係る状態管理情報１２２の構成を示す構成図である。図４において、状態管理情報１２２は、項目として、他ノード装置の識別情報３０１、状態３０２を有する。他ノード装置の識別情報３０１は、状態確認の対象とするノード装置を識別する情報であり、例えば、ＩＰアドレス、ホスト名等とすることができる。状態３０２は、ノード装置の状態確認結果であり、状態確認条件１２１に従って、ノード装置が運用中であるか又は閉塞中であるかを示す情報が格納される。ここで、運用中とは、対象とするノード装置が正常にセッション確立プロトコル（ＳＩＰ）による処理動作が可能な状態であることを示す。閉塞中とは、対象とするノード装置が正常にセッション確立プロトコル（ＳＩＰ）による処理動作をしていない状態であることを示す。

なお、図４の状態管理情報１２２は、状態確認の対象とするノード装置の識別情報と状態確認結果とを対応付けたものであり、状態確認の実施時刻、障害検出の時刻、障害回復検出の時刻等を含むようにしても良い。

（Ａ−１−３）ノード装置の内部構成
図５は、実施形態に係るノード装置２、ノード装置３−１及び３−２の内部構成を示す内部構成図である。

ノード装置２、ノード装置３−１及び３−２における他ノード装置のヘルスチェックに係る構成は、基本的には、同一又は対応する構成とすることができる。そこで、ここでは、ノード装置２、ノード装置３−１及び３−２が備えるヘルスチェックに係る構成を、図５を参照して説明する。

図５において、ノード装置２、ノード装置３−１及び３−２は、制御部２０、通信部２５を有する。

通信部２５は、接続するネットワーク（ネットワークＡ、ネットワークＢ）の通信回線との間でパケットの送受信を行うものである。

制御部２０は、ノード装置２、３−１及び３−２全体の機能を司るものである。制御部２０は、例えば、ＣＰＵ、記憶装置、入出力インタフェース部等を有するものであり、ＣＰＵがＲＯＭに格納される処理プログラムを実行するソフトウェア処理により、ノード装置２、３−１及び３−２は図５に示す機能を実現することができる。処理プログラムはインストールにより構築することができ、その場合でも図５のように示すことができる。

制御部２０は、図５に例示するように、状態確認部２１、記憶部２２を有する。

状態確認部２１は、通信部１５を介して、対象とする他ノード装置宛にＯＰＴＩＯＮＳリクエストを送信したり、又は、受信した自身宛のＯＰＴＩＯＮＳリクエストに対してＯＰＴＩＯＮＳ応答を返信したりするものである。状態確認部２１は、図５に示すように、リクエスト送信部２１１、レスポンス返信部２１２、レスポンス受信判定部２１３を有する。

リクエスト送信部２１１は、状態確認の問い合せのため、ＯＰＴＩＯＮＳリクエストのＲｅｑｕｅｓｔ−ＵＲＩに対象とするノード装置のＵＲＩ（例えば、ｓｉｐ−ｕｒｉ、ｓｉｐｓ−ｕｒｉ等）を設定したＳＩＰメッセージを含むパケット（図１ではＳＩＰと表記する。）を送信するものである。

レスポンス返信部２１２は、自身宛のＯＰＴＩＯＮＳリクエストを受信すると、要求元のノード装置宛のＯＰＴＩＯＮＳ応答を返信するものである。例えば、レスポンス返信部２１２は、ＯＰＴＩＯＮＳリクエストに対してステータスコード「２００」のレスポンスを返信する。

レスポンス受信判定部２１３は、要求先のノード装置から受信したＯＰＴＩＯＮＳレスポンスの内容を判定するものである。レスポンス受信判定部２１３は、受信したＯＰＴＩＯＮＳレスポンスのステータスコードが「２００」以上のレスポンスである場合、要求先のノード装置は正常に動作していると判定する。一方、受信したＯＰＴＩＯＮＳレスポンスのステータスコードが「５０３」のレスポンスである場合、レスポンス受信判定部２１３は、要求先のノード装置が正常に動作していないと判定する。

記憶部２２は、処理プログラム、処理に必要なデータ、状態管理情報２２１等を記憶するものである。状態管理情報２２１は、レスポンス受信判定部２１３による判定結果を、対象とするノード装置毎に保持するものである。

（Ａ−２）実施形態の動作
次に、実施形態に係る通信制御システム１００におけるノード装置の状態確認処理の動作を、図面を参照しながら詳細に説明する。

（Ａ−２−１）ゲートウェイ装置１における状態管理処理
図６は、実施形態に係る通信制御システム１００におけるノード装置の状態確認処理の動作を説明する説明図である。

図６において、ネットワークＡに属するゲートウェイ装置１が、定期的に、ネットワークＢに存在するノード装置３−１及び３−２の状態を管理しているものとする。

図７は、実施形態のゲートウェイ装置１がノード装置の状態確認処理の一例を示すシーケンス図である。ここで、説明便宜上、対象とするノード装置については、ノード装置３と表記して説明する。

ゲートウェイ装置１において、状態確認部１１３は、状態確認条件１２１に従って、対象とするノード装置３の状態を確認する。状態確認部１１３は、状態確認条件１２１の実施周期２０２に基づいて、対象とするノード装置３宛のＯＰＴＩＯＮＳリクエストを送信する（Ｓ１０１）。

つまり、実施周期２０２で設定されている送信間隔で、状態確認部１１３は、ＯＰＴＩＯＮＳリクエストを送信する。これにより、ゲートウェイ装置１は、定期的に、対象とするノード装置３の状態管理を行うことができる。

このとき、状態確認部１１３は、ＯＰＴＩＯＮＳメソッドのＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩをノード装置３のＩＰアドレスとして、ＯＰＴＩＯＮＳリクエストをノード装置３に送信する。

ノード装置３が正常に動作している場合、ノード装置３は、受信したＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳレスポンスを返信する（Ｓ１０２）。例えば、ＯＰＴＩＯＮＳレスポンスは２００応答とする。そうすると、ゲートウェイ装置１において、状態確認部１１３は、状態確認条件１２１の成功条件２０３を満たすものと判断する。従って、状態確認部１１３は、状態管理情報１２２において、当該ノード装置３の状態が運用中であることを登録する。

ここで、ノード装置３に障害が発生したとする（Ｓ１０３）。ノード装置３の障害発生後、状態管理部１３１による次のヘルスチェックの実施周期の開始時に、状態確認部１１３がＯＰＴＩＯＮＳリクエストをノード装置３に送信する（Ｓ１０４）。しかし、ノード装置３が障害発生しているため、ＯＰＴＩＯＮＳリクエストに対する応答がなされない。ゲートウェイ装置１の状態確認部１１３は、ＯＰＴＩＯＮＳリクエストの再送を繰り返し行う（Ｓ１０５）。

ゲートウェイ装置１において、障害検出部１１４は、今回のヘルスチェックの実施周期における実施期間（実施時間）を管理しており、当該実施周期の実施期間が再送期間２０４を超えるか否かを判断している。そして、当該実施周期の実施期間が再送期間２０４を超えたとき、障害検出部１１４は、再送タイムアウト（再送Ｔ．Ｏ．）を検出する（Ｓ１０６）。

そうすると、障害検出部１１４は、状態確認条件１２１の障害検出条件２０５及びカウント条件２０７（障害検出カウント条件）に基づいて、当該ノード装置３の障害発生を検出する（Ｓ１０７）。なお、障害検出カウント条件は例えば１回と設定されているため（図３参照）、障害検出部１１４は、１回の再送Ｔ．Ｏ．検出で、障害検出と判断する。

そして、状態確認部１１３は、状態管理情報１２２において、当該ノード装置３の状態が閉塞中であることを登録する。

次のヘルスチェックの実施周期においても、状態確認部１１３は、ノード装置３に対してＯＰＴＩＯＮＳリクエストを送信する。図７のＳ１０８〜Ｓ１１０の場合も、当該実施周期の実施期間が再送期間２０４を超え、障害検出部１１４は、再送タイムアウト（再送Ｔ．Ｏ．）を検出する。このとき、状態確認部１１３は、状態管理情報１２２において、当該ノード装置３の状態が閉塞中であるため、そのまま管理情報を維持する。

ここで、次のヘルスチェックの実施周期になる前に、ノード装置３の障害が復旧したとする（Ｓ１１１）。ノード装置３の復旧後、次のヘルスチェックの実施周期に、状態確認部１１３がＯＰＴＩＯＮＳリクエストをノード装置３に送信する（Ｓ１１２）。このとき、ノード装置３は復旧しているため、ＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳレスポンス（図７では２００応答とする）が、ゲートウェイ装置１に受信される（Ｓ１１３）。

ゲートウェイ装置１において、障害回復検出部１１６は、受信したＯＰＴＩＯＮＳレスポンスの内容を判定する。このとき、受信したＯＰＴＩＯＮＳレスポンスがステータスコード「２００」以上のレスポンスであることを、障害回復検出部１１６は確認する。

次のヘルスチェックの実施周期に、状態確認部１１３がＯＰＴＩＯＮＳリクエストをノード装置３に送信し（Ｓ１１４）、ノード装置３がＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳレスポンス（図７では２００応答とする）がゲートウェイ装置１に送信する（Ｓ１１５）。

ゲートウェイ装置１において、障害回復検出部１１６は、２回連続ステータスコードが「２００」以上の応答の受信を検出した。そのため、障害回復検出部１１６は、状態確認条件１２１の障害回復条件２０６及びカウント条件（障害回復カウント条件）に基づいて、当該ノード装置３の障害回復を検出する。

そして、状態確認部１１３は、状態管理情報１２２において、当該ノード装置３の状態が運用中であることを登録する。

図８は、実施形態のゲートウェイ装置１がノード装置の状態確認処理の別の例を示すシーケンス図である。

上述した図７では、障害検出条件が再送タイムアウトである場合を例示したが、図８は、障害検出条件がＯＰＴＩＯＮＳレスポンスの未受信である場合を示す。

図８では、障害検出条件が図７の処理と異なるため、以下では、障害検出処理を中心に説明する。なお、図８において、図７と同一又は対応する処理には同一番号を付している。

図８において、ノード装置３に障害が発生したとする（Ｓ１０３）。ノード装置３の障害発生後、状態管理部１３１による次のヘルスチェックの実施周期に、状態確認部１１３がＯＰＴＩＯＮＳリクエストをノード装置３に送信する（Ｓ１０４）、状態確認部１１３は、ＯＰＴＩＯＮＳリクエストの再送を繰り返し行う（Ｓ１０５）。

ゲートウェイ装置１において、障害検出部１１４は、ＯＰＴＩＯＮＳリクエストに対する応答が再送期間２０４まで未受信である場合（Ｓ２０１）、状態確認条件１２１の障害検出条件２０５及びカウント条件２０７（障害検出カウント条件）に基づいて、当該ノード装置３の障害発生を検出する（Ｓ１０７）。

ここで、Ｓ２０１では、ＯＰＴＩＯＮＳリクエストに対する応答が再送期間２０４までに未受信である場合を例示したが、この障害検出条件は、ＯＰＴＩＯＮＳリクエストに対する応答がないことを判断できればよい。

そのため、再送期間２０４内に応答未受信を検出するようにしても良いし、又は、ヘルスチェックの実施に係る１周期内で、ＯＰＴＩＯＮＳリクエストに対する応答未受信を検出するようにしても良い。

そして、状態確認部１１３は、状態管理情報１２２において、当該ノード装置３の状態が閉塞中であることを登録する。

次のヘルスチェックの実施周期になると、状態確認部１１３は、前回の実施周期で送信していたＯＰＴＩＯＮＳリクエストの再送を停止する。次のヘルスチェックの実施周期においても、障害検出部１１４は、ＯＰＴＩＯＮＳリクエストに対する応答が再送期間２０４まで未受信である場合（Ｓ２０２）、当該ノード装置３の障害発生を検出する。

この場合、状態確認部１１３は、状態管理情報１２２において、当該ノード装置３の状態が閉塞中であるため、そのまま管理情報を維持する。

その後、ノード装置３が回復した後の処理は、図７の場合と同様であるため、ここでの説明は省略する。

（Ａ−２−２）ゲートウェイ装置１のＯＰＴＩＯＮＳリクエスト受信時
次に、ゲートウェイ装置１が、ＯＰＴＩＯＮＳリクエストを受信した場合の処理動作を、図面を参照しながら詳細に説明する。

ここでは、図６に示すように、ネットワークＡ上のノード装置２が要求元であり、要求元のノード装置２が、ゲートウェイ装置１を介して、ネットワークＢ上のノード装置３−１及び３−２の状態確認を行う場合を例示する。

また、図６に示すように、説明便宜上、要求先のノード装置３−１は障害が生じており正常に動作しておらず、要求先のノード装置３−２が正常に動作しているものとする。

図９は、実施形態に係る通信制御システム１００におけるノード装置の状態確認処理を示すシーケンス図である。

図９において、状態確認の要求元であるノード装置１において、ＯＰＴＩＯＮＳメソッドのリクエストが作成され（Ｓ３０１）、作成されたノード装置宛のＯＰＴＩＯＮＳリクエストを含むパケットが、ゲートウェイ装置１に送信される（Ｓ３０２）。

ゲートウェイ装置１では、受信パケットに含まれるＳＩＰメッセージがＯＰＴＩＯＮＳメソッドのリクエストであることが判定され、ＯＰＴＩＯＮＳリクエストの宛先判定がなされる（Ｓ３０３）。

図１０は、実施形態のゲートウェイ装置１における宛先判定処理を示すフローチャートである。

図１０において、受信されたＯＰＴＩＯＮＳリクエストは、スキームチェックが行なわれる（Ｓ５０１）。つまり、ゲートウェイ装置１において、リクエスト判定部１１１が、ＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩに基づいて、ｓｉｐ−ｕｒｉ又はｓｉｐｓ−ｕｒｉであるか否かを確認する。

ｓｉｐ−ｕｒｉ又はｓｉｐｓ−ｕｒｉである場合、処理はＳ５０２に移行する。一方、ｓｉｐ−ｕｒｉ又はｓｉｐｓ−ｕｒｉ以外の場合、処理はＳ５０５に移行し、リクエスト判定部１１１は転送対象のＳＩＰメッセージであると判定する（Ｓ５０５）。

Ｓ５０２では、リクエスト判定部１１１が、ＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩにｕｓｅｒｉｎｆｏ部が含まれているか否かをチェックする（Ｓ５０２）。

ｕｓｅｒｉｎｆｏ部が含まれていない場合、処理はＳ５０３に移行する。一方、ｕｓｅｒｉｎｆｏ部が含まれている場合、処理はＳ５０５に移行し、リクエスト判定部１１１は転送対象のＳＩＰメッセージであると判定する（Ｓ５０５）。

Ｓ５０３では、リクエスト判定部１１１が、Ｒｅｑｕｅｓｔ−ＵＲＩのｈｏｓｔ部の確認を行う（Ｓ５０３）。

そして、Ｒｅｑｕｅｓｔ−ＵＲＩのｈｏｓｔ部が自身（ゲートウェイ装置１）宛である場合、リクエスト判定部１１１は自身のヘルスチェック用ＯＰＴＩＯＮＳリクエストであると判定する（Ｓ５０４）。このとき、ゲートウェイ装置１において、レスポンス返信部１１５は、ＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳレスポンスとして２００応答を、要求元のノード装置２に送信する。

また、Ｒｅｑｕｅｓｔ−ＵＲＩのｈｏｓｔ部が自身宛でない場合（他ノード装置）である場合、リクエスト判定部１１１は転送対象のＳＩＰメッセージであると判定する（Ｓ５０５）。

ここで、図１１は、Ｒｅｑｕｅｓｔ−ＵＲＩのｈｏｓｔ部のチェックのより詳細な処理を示すフローチャートである。

図１１において、まず、リクエスト判定部１１１は、Ｒｅｑｕｅｓｔ−ＵＲＩのｈｏｓｔ部がＩＰアドレスであるか否かを確認する（Ｓ５１１）。

ｈｏｓｔ部がＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）である場合、処理はＳ５１２に移行する。一方、ｈｏｓｔ部がＩＰアドレスである場合、処理はＳ５１３に移行する。

Ｓ５１２では、リクエスト判定部１１１が、名前解決処理を実施して、ｈｏｓｔ部のＦＱＤＮに対応するＩＰアドレスを検索する（Ｓ５１２）。なお、名前解決のため、ゲートウェイ装置１は、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）を有するようにしても良いし、ゲートウェイ装置１が、ネットワーク上のＤＮＳサーバを用いて名前解決を行うようにしても良い。

Ｓ５１３では、リクエスト判定部１１１が、宛先のＩＰアドレスと自身（ゲートウェイ装置１）のＩＰアドレスとを比較する（Ｓ５１３）。そして、一致する場合、リクエスト判定部１１１は自身宛であると判定し（Ｓ５１４）、一致しない場合、リクエスト判定部１１１は他ノード宛であると判定する（Ｓ５１５）。

図９において、受信したＯＰＴＩＯＮＳリクエストの宛先が、他ノード装置宛であると判定されると、ゲートウェイ装置１において、状態管理情報検索部１１２は、記憶部１２の状態管理情報１２２から、対応するノード装置の状態管理情報を検索する（Ｓ３０４）。

ゲートウェイ装置１において、レスポンス返信部１１５は、状態管理情報検索部１１２による検索結果に基づいて、ＯＰＴＩＯＮＳリクエストに対するＯＰＴＩＯＮＳレスポンスを作成し（Ｓ３０５）、要求元にＯＰＴＩＯＮＳレスポンスを送信する（Ｓ３０６）。

例えば、ノード装置３−２のＩＰアドレスが「168.0.0.1」であり、図４の例の通り、ノード装置３−２の状態が「運用中」であるとする。また、ＯＰＴＩＯＮＳリクエストの宛先が「ＩＰアドレス：168.0.0.1」であるとする。状態管理情報検索部１１２は、ＯＰＴＩＯＮＳリクエストの宛先「ＩＰアドレス：168.0.0.1」に基づいて、状態管理情報１２２を参照して、当該対象のノード装置の状態が「運用中」であると判断する。この場合、レスポンス返信部１１５は、ＯＰＴＩＯＮＳレスポンスとして２００応答を作成して返信する。

また例えば、ノード装置３−１のＩＰアドレスが「168.0.0.2」であり、図４の例の通り、ノード装置３−１の状態が「閉塞中」であるとする。また、ＯＰＴＩＯＮＳリクエストの宛先が「ＩＰアドレス：168.0.0.2」であるとする。状態管理情報検索部１１２は、ＯＰＴＩＯＮＳリクエストの宛先「ＩＰアドレス：168.0.0.2」に基づいて、状態管理情報１２２を参照して、当該対象のノード装置の状態が「閉塞中」であると判断する。この場合、レスポンス返信部１１５は、ＯＰＴＩＯＮＳレスポンスとしてエラー応答（ステータスコード「５０３」応答：Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ）を作成して返信する。これにより、エラー応答を受けたノード装置は、ゲートウェイ装置１からのＯＰＴＩＯＮＳレスポンスに基づいて要求先のノード装置が故障していると判断することができ、例えば迂回等の処理を行うことで呼の接続を継続することができる。

（Ａ−３）実施形態の効果
以上のように、この実施形態によれば、ゲートウェイ装置が、ＯＰＴＩＯＮＳリクエストを用いてノード装置の状態を管理する。そして、ゲートウェイ装置を介したノード装置の状態確認がある場合に、転送先ノード装置が正常であればゲートウェイ装置が正常応答を返信し、転送先ノード装置に障害があれば、ゲートウェイ装置がエラー応答を返信する。これにより、要求元からのＳＩＰリクエストをゲートウェイ装置が終端することができるので、ノード装置間において不要リソースの削減及びネットワーク輻輳を低減することができる。

（Ｂ）他の実施形態
上述した実施形態においても、本発明の種々の変形実施形態を説明したが、本発明は、以下の他の実施形態も広く適用することができる。

上述した実施形態では、セッション制御プロトコルがＳＩＰである場合を例示した。しかし、セッション制御プロトコルは、ＳＩＰに限定されるものではなく、メディアゲートウェイ制御プロトコル（ＭＧＣＰ：Ｍｅｄｉａ Ｇａｔｅｗａｙ ＣｏｎｔｒｏＩ Ｐｒｏｔｏｃｏｌ）においても、同様に適用することが可能である。この場合、ＳＩＰ ＯＰＴＩＯＮＳ信号に代えて、Ｈ．２４８．１に規定されているＡｕｄｉｔ Ｖａｌｕｅ（Ｍｅｄｉａ Ｇａｔｅｗａｙ ＣｏｎｔｒｏＩ Ｐｒｏｔｏｃｏｌ）信号を用いることで実現することができる。

上述した実施形態では、ゲートウェイ装置に本発明を適用する場合を例示した。より具体的には、事業者が異なるネットワーク間のＮＮＩに配置されるセッションボーダコントローラが有するＳＩＰ−ＡＬＧ機能に、本発明を適用するようにしても良い。

１００…通信制御システム、１…ゲートウェイ装置（例えばＳＩＰ−ＡＬＧ）、２…ノード装置（例えばＳＩＰサーバ）、３−１及び３−２…ノード装置（例えばＳＩＰサーバ）、
１０…制御部、１１…状態管理部、１１１…リクエスト判定部、１１２…状態管理情報検索部、１１３…状態確認部、１１４…障害検出部、１１５…レスポンス返信部、１１６…障害回復検出部、１２…記憶部、１２１…状態確認条件、１２２…状態管理情報。

Claims (10)

1. 中継装置を介して、第１のノード装置が、セッション制御プロトコルを用いて、１又は複数の第２のノード装置の状態確認を行う通信制御システムにおいて、
   上記中継装置が、
   セッション制御プロトコルを用いて、定期的に、上記１又は複数の第２のノード装置の状態確認を行う状態確認手段と、
   上記状態確認手段により確認された上記各第２のノード装置の状態を上記第２のノード装置毎に記憶する状態管理手段と、
   上記第１のノード装置から受信した上記第２のノード装置宛の状態確認リクエストに対して、上記状態管理手段における対応の第２のノード装置の状態に応じた応答信号を上記第１のノード装置に返信する応答返信手段と
   を備える
   ことを特徴とする通信制御システム。
2. 上記応答返信手段が、上記状態管理手段を参照して、上記状態確認リクエストの要求先の第２のノード装置の状態が非正常状態の場合、受信した上記状態確認リクエストに対してエラー応答を返信するものであることを特徴とする請求項１に記載の通信制御システム。
3. 上記応答返信手段が、上記状態管理手段を参照して、上記状態確認リクエストの要求先の第２のノード装置の状態が正常状態の場合、受信した上記状態確認リクエストに対して正常応答を返信するものであることを特徴とする請求項１又は２に記載の通信制御システム。
4. 上記状態確認手段が、定期的に、上記１又は複数の第２のノード装置に対して状態確認リクエストを送信し、上記１又は複数の第２のノード装置からの応答状況に基づいて、上記各第２のノード装置の状態を確認するものであり、
   上記中継装置は、
   上記状態確認手段による上記各第２のノード装置の状態確認に係る実施期間が所定の期間を超えた場合、当該第２のノード装置の障害発生を検出する障害検出手段を備える
   ことを特徴とする請求項１〜３のいずれかに記載の通信制御システム。
5. 上記状態確認手段が、定期的に、上記１又は複数の第２のノード装置に対して状態確認リクエストを送信し、上記１又は複数の第２のノード装置からの応答状況に基づいて、上記各第２のノード装置の状態を確認するものであり、
   上記中継装置は、
   上記状態確認手段による今回の実施周期内で、上記第２のノード装置から上記状態確認リクエストに対する応答を未受信の場合、当該第２のノード装置の障害発生を検出する障害検出手段を備える
   ことを特徴とする請求項１〜３のいずれかに記載の通信制御システム。
6. 上記障害検出手段は、上記第２のノード装置の障害発生検出回数が所定の障害検出カウント条件を満たす場合、当該第２のノード装置に障害が発生したと判断するものであることを特徴とする請求項４又は５に記載の通信制御システム。
7. 上記中継装置は、
   上記障害検出手段により障害発生が認められた上記第２のノード装置から、上記状態確認手段が送信した上記状態確認リクエスト対する応答を受信したときに、当該第２のノード装置の障害回復を検出する障害回復検出手段を
   備えることを特徴とする請求項４〜６のいずれかに記載の通信制御システム。
8. 上記障害回復検出手段は、上記第２のノード装置の障害回復検出回数が所定の障害回復カウント条件を満たす場合、当該第２のノード装置における障害が回復したと判断するものであることを特徴とする請求項７に記載の通信制御システム。
9. 第１のノード装置と第２のノード装置との間でセッション制御プロトコルに係るメッセージを中継する中継装置の通信制御装置において、
   セッション制御プロトコルを用いて、定期的に、上記１又は複数の第２のノード装置の状態確認を行う状態確認手段と、
   上記状態確認手段により確認された上記各第２のノード装置の状態を上記第２のノード装置毎に記憶する状態管理手段と、
   上記第１のノード装置から受信した上記第２のノード装置宛の状態確認リクエストに対して、上記状態管理手段における対応の第２のノード装置の状態に応じた応答信号を上記第１のノード装置に返信する応答返信手段と
   を備えることを特徴とする通信制御装置。
10. 第１のノード装置と第２のノード装置との間でセッション制御プロトコルに係るメッセージを中継する中継装置の通信制御プロトコルにおいて、
    コンピュータを、
    セッション制御プロトコルを用いて、定期的に、上記１又は複数の第２のノード装置の状態確認を行う状態確認手段、
    上記状態確認手段により確認された上記各第２のノード装置の状態を上記第２のノード装置毎に記憶する状態管理手段、
    上記第１のノード装置から受信した上記第２のノード装置宛の状態確認リクエストに対して、上記状態管理手段における対応の第２のノード装置の状態に応じた応答信号を上記第１のノード装置に返信する応答返信手段
    として機能させることを特徴とする通信制御プログラム。

Images