(57)【要約】【課題】ゲートウェイ装置の再開後に集中的なサービス停止期間の発生を防ぐ。【解決手段】通信装置を接続するゲートウェイ装置から起動通知を受信した回数をカウントし、リソースの生成要求をゲートウェイ装置へ送信し、生成要求を送信する際に、その時点でカウントしているカウント値である第１のカウント値を含むセッション情報を生成し、生成要求に対してゲートウェイ装置から送信されてきた応答信号に含まれるリソース識別情報をセッション情報に加え、ゲートウェイ装置のリソースの変更要求または削除要求をリソース識別情報を指定してゲートウェイ装置へ送信する際、セッション情報に含まれる第１のカウント値と、その時点でカウントしているカウント値である第２のカウント値とが異なる場合、セッション情報を解放し、第１のカウント値と第２のカウント値とが同じである場合のみ、ゲートウェイ装置へ変更要求または削除要求を送信する。【選択図】図１
2010166496.tif 000002
【特許請求の範囲】
【請求項１】
通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御装置であって、
前記ゲートウェイ装置から該ゲートウェイ装置が起動した旨を示す起動通知を受信した回数をカウントする起動回数カウント部と、
前記ゲートウェイ装置におけるリソースの生成を要求する生成要求を該ゲートウェイ装置へ送信し、また、前記ゲートウェイ装置のリソース状態の変更を要求する変更要求またはリソースの削除を要求する削除要求を、該リソースを識別するためのリソース識別情報を指定して該ゲートウェイ装置へ送信する要求信号送信部と、
前記要求信号送信部が前記生成要求を送信する際に、その時点で前記起動回数カウント部が示しているカウント値である第１のカウント値を含むセッション情報を生成し、前記生成要求に対して前記ゲートウェイ装置から送信されてきた応答信号に含まれる生成したリソースを識別するためのリソース識別情報を前記セッション情報に加えるセッション情報管理部と、
前記セッション情報を記憶する記憶部と、
前記要求信号送信部が前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求にて指定するリソース識別情報を含むセッション情報に含まれる前記第１のカウント値と、その時点で前記起動回数カウント部が示しているカウント値である第２のカウント値とを比較する比較部とを有し、
前記セッション情報管理部は、前記比較部における比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、該セッション情報を前記記憶部から削除し、
前記要求信号送信部は、前記比較部における比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記変更要求または前記削除要求を送信しないゲートウェイ制御装置。
【請求項２】
請求項１に記載のゲートウェイ制御装置において、
前記要求信号送信部が前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求するリソースのリソース識別情報を含むトランザクション情報を生成するトランザクション情報管理部をさらに有し、
前記比較部における比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記トランザクション情報管理部は、該トランザクション情報を解放することを特徴とするゲートウェイ制御装置。
【請求項３】
請求項２に記載のゲートウェイ制御装置において、
前記セッション情報管理部は、前記トランザクション情報管理部が解放したトランザクション情報に含まれるリソース識別情報を含むセッション情報を前記記憶部から削除することを特徴とするゲートウェイ制御装置。
【請求項４】
請求項１に記載のゲートウェイ制御装置において、
前記起動回数カウント部は、前記起動通知を受信した際、前記カウント値を１つカウントアップすることを特徴とするゲートウェイ制御装置。
【請求項５】
請求項１乃至４のいずれか１項に記載のゲートウェイ制御装置において、
当該ゲートウェイ制御装置と、前記ゲートウェイ装置との間の信号の送受信は、Ｈ．２４８のプロトコルに従うことを特徴とするゲートウェイ制御装置。
【請求項６】
通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御方法であって、
前記ゲートウェイ装置から該ゲートウェイ装置が起動した旨を示す起動通知を受信した回数をカウントする処理と、
前記ゲートウェイ装置におけるリソースの生成を要求する生成要求を該ゲートウェイ装置へ送信する処理と、
前記生成要求を送信する際に、その時点で前記カウントしているカウント値である第１のカウント値を含むセッション情報を生成する処理と、
前記生成要求に対して前記ゲートウェイ装置から送信されてきた応答信号に含まれる生成したリソースを識別するためのリソース識別情報を前記セッション情報に加える処理と、
前記ゲートウェイ装置のリソース状態の変更を要求する変更要求またはリソースの削除を要求する削除要求を、該リソースを識別するためのリソース識別情報を指定して該ゲートウェイ装置へ送信する送信処理と、
前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求にて指定するリソース識別情報を含むセッション情報に含まれる前記第１のカウント値と、その時点で前記カウントしているカウント値である第２のカウント値とを比較する処理と、
該比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記セッション情報を解放する処理とを有し、
前記送信処理は、前記比較の結果、前記第１のカウント値と前記第２のカウント値とが同じである場合のみ、前記ゲートウェイ装置への前記変更要求または前記削除要求を送信するゲートウェイ制御方法。
【請求項７】
請求項６に記載のゲートウェイ制御方法において、
前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求するリソースのリソース識別情報を含むトランザクション情報を生成する処理と、
前記比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記トランザクション情報を解放する処理とを有することを特徴とするゲートウェイ制御方法。
【請求項８】
請求項７に記載のゲートウェイ制御方法において、
前記解放したトランザクション情報に含まれるリソース識別情報を含むセッション情報を解放する処理を有することを特徴とするゲートウェイ制御方法。
【請求項９】
請求項６に記載のゲートウェイ制御方法において、
前記起動通知を受信した際、前記カウント値を１つカウントアップする処理を有することを特徴とするゲートウェイ制御方法。
【請求項１０】
通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御装置に、
前記ゲートウェイ装置から該ゲートウェイ装置が起動した旨を示す起動通知を受信した回数をカウントする手順と、
前記ゲートウェイ装置におけるリソースの生成を要求する生成要求を該ゲートウェイ装置へ送信する手順と、
前記生成要求を送信する際に、その時点で前記カウントしているカウント値である第１のカウント値を含むセッション情報を生成する手順と、
前記生成要求に対して前記ゲートウェイ装置から送信されてきた応答信号に含まれる生成したリソースを識別するためのリソース識別情報を前記セッション情報に加える手順と、
前記ゲートウェイ装置のリソース状態の変更を要求する変更要求またはリソースの削除を要求する削除要求を、該リソースを識別するためのリソース識別情報を指定して該ゲートウェイ装置へ送信する送信手順と、
前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求にて指定するリソース識別情報を含むセッション情報に含まれる前記第１のカウント値と、その時点で前記カウントしているカウント値である第２のカウント値とを比較する手順と、
該比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記セッション情報を解放する手順とを実行させ、
前記送信手順は、前記比較の結果、前記第１のカウント値と前記第２のカウント値とが同じである場合のみ、前記ゲートウェイ装置への前記変更要求または前記削除要求を送信するプログラム。
【請求項１１】
請求項１０に記載のプログラムにおいて、
前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求するリソースのリソース識別情報を含むトランザクション情報を生成する手順と、
前記比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記トランザクション情報を解放する手順とを実行させるためのプログラム。
【請求項１２】
請求項１１に記載のプログラムにおいて、
前記解放したトランザクション情報に含まれるリソース識別情報を含むセッション情報を解放する手順を実行させるためのプログラム。
【請求項１３】
請求項１０に記載のプログラムにおいて、
前記起動通知を受信した際、前記カウント値を１つカウントアップする手順を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御装置、ゲートウェイ制御方法及びプログラムに関する。
【背景技術】
【０００２】
近年、複数の通信装置間で通信を行う際、当該通信装置がそれぞれ属するネットワークを互いに接続するゲートウェイ装置（以下、ＭＧ：Ｍｅｄｉａ  Ｇａｔｅｗａｙと称する）が用いられている。
【０００３】
ゲートウェイ装置は、ネットワークと接続された通信装置と、他のネットワークと接続された通信装置との間で通信を行う際、互いのネットワークを接続するために用いられる。ここでネットワークとは、既存の電話交換網やＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網等のネットワークである。例えば、ゲートウェイ装置は、既存の電話交換網とＩＰ網とを、また、既存の電話交換網と既存の電話交換網とを、また、ＩＰ網とＩＰ網とを接続するために用いられる。
【０００４】
また、ＭＧを制御するゲートウェイ制御装置（以下、ＭＧＣ：Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌと称する）がＭＧと接続される。
【０００５】
このＭＧＣとＭＧとの間では、Ｈ．２４８という通信プロトコルを用いて、ＭＧＣがＭＧを制御している（例えば、非特許文献１参照。）。
【０００６】
図８は、ＭＧおよびＭＧＣを用いた一般的な通信システムの形態の一例を示す図である。
【０００７】
図８に示した通信システムは、ＳＩＰサーバ１０００と、ＭＧＣ２０００と、ＭＧ３０００と、端末４０００，５０００とから構成されている。
【０００８】
ＳＩＰサーバ１０００は、通信プロトコルの１つであるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用して端末４０００，５０００の呼制御を行うサーバである。
【０００９】
端末４０００は、通信機能を有する通信端末である。端末４０００は、既存の電話交換網と接続された通信端末であっても良いし、ＩＰ網と接続された通信端末であっても良い。
【００１０】
端末５０００は、通信機能を有する通信端末である。端末５０００は、既存の電話交換網と接続された通信端末であっても良いし、ＩＰ網と接続された通信端末であっても良い。
【００１１】
ＭＧ３０００は、端末４０００と端末５０００とを接続する。ここで、端末４０００と接続されたネットワークと端末５０００と接続されたネットワークとが同種のネットワークである場合（例えば、双方が既存の電話交換網である場合や、双方がＩＰ網である場合）、ＭＧ３０００は、不正パケットのフィルタリング、帯域制限、優先度制御、ＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  ａｎｄ  Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）変換等を行う。また、端末４０００と接続されたネットワークと端末５０００と接続されたネットワークとが異種のネットワークである場合（例えば、一方が既存の電話交換網であり、他方がＩＰ網である場合）、ＭＧ３０００は、既存の電話交換網のインタフェースとＩＰ網のインタフェースとの変換を行う。
【００１２】
ＭＧＣ２０００は、Ｈ．２４８のプロトコルを用いてＭＧ３０００を制御する。
【００１３】
以下に、図８に示した形態におけるゲートウェイ制御方法について説明する。
【００１４】
図９は、図８に示した形態におけるゲートウェイ制御方法を説明するためのシーケンス図である。
【００１５】
まず、ＭＧＣ２０００からＭＧ３０００へリソースの生成の要求をする場合、当該生成要求するために、トランザクション情報が生成される（ステップＳ５１）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。続いて、当該トランザクション情報がＭＧＣ２０００内に記憶される（ステップＳ５２）。
【００１６】
そして、当該トランザクション情報に応じたリソースの生成を要求する生成要求（Ａｄｄ  Ｒｅｑｕｅｓｔ）がＭＧＣ２０００からＭＧ３０００へ送信される（ステップＳ５３）。
【００１７】
ＭＧＣ２０００から送信されてきた生成要求がＭＧ３０００にて受信されると、ＭＧ３０００にてリソースが生成される（ステップＳ５４）。このとき、当該リソースを識別するためのリソース識別情報であるＣｏｎｔｅｘｔ  ＩＤが当該リソースに付与される。ここで付与されたＣｏｎｔｅｘｔ  ＩＤを「１」とする。
【００１８】
そして、生成要求に対する生成応答（Ａｄｄ  Ｒｅｐｌｙ）にＣｏｎｔｅｘｔ  ＩＤ＝１が付与されてＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ５５）。
【００１９】
ＭＧ３０００から送信されてきた生成応答に含まれるＣｏｎｔｅｘｔ  ＩＤ＝１が、ステップＳ５２にて記憶されたトランザクション情報に書き込まれる（追加される）。
【００２０】
その後、Ｃｏｎｔｅｘｔ  ＩＤ＝１のリソース状態の変更を要求する場合、当該変更要求するために、トランザクション情報が生成される（ステップＳ５６）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。また、変更を要求するリソースのＣｏｎｔｅｘｔ  ＩＤ＝１が当該トランザクション情報に含まれる。続いて、当該トランザクション情報がＭＧＣ２０００内に記憶される（ステップＳ５７）。
【００２１】
そして、Ｃｏｎｔｅｘｔ  ＩＤ＝１が含まれたリソース状態の変更を要求する変更要求（Ｍｏｄｉｆｙ  Ｒｅｑｕｅｓｔ）がＭＧＣ２０００からＭＧ３０００へ送信される（ステップＳ５８）。このリソース状態の変更要求は、通信先の電話のアドレスの変更要求や、リソースを一時的にクローズする要求等である。
【００２２】
ＭＧＣ２０００から送信されてきた変更要求がＭＧ３０００にて受信されると、変更要求に含まれるＣｏｎｔｅｘｔ  ＩＤ＝１のリソース状態が変更される（ステップＳ５９）。
【００２３】
そして、変更要求に対する変更応答（Ｍｏｄｉｆｙ  Ｒｅｐｌｙ）にＣｏｎｔｅｘｔ  ＩＤ＝１が付与されてＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ６０）。
【００２４】
その後、Ｃｏｎｔｅｘｔ  ＩＤ＝１のリソースの削除を要求する場合、当該削除要求するために、トランザクション情報が生成される（ステップＳ６１）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。また、削除を要求するリソースのＣｏｎｔｅｘｔ  ＩＤ＝１が当該トランザクション情報に含まれる。続いて、当該トランザクション情報がＭＧＣ２０００内に記憶される（ステップＳ６２）。
【００２５】
そして、Ｃｏｎｔｅｘｔ  ＩＤ＝１が含まれたリソースの削除を要求する削除要求（Ｓｕｂｔｒａｃｔ  Ｒｅｑｕｅｓｔ）がＭＧＣ２０００からＭＧ３０００へ送信される（ステップＳ６３）。
【００２６】
ＭＧＣ２０００から送信されてきた削除要求がＭＧ３０００にて受信されると、削除要求に含まれるＣｏｎｔｅｘｔ  ＩＤ＝１のリソースが削除される（ステップＳ６４）。
【００２７】
そして、削除要求に対する削除応答（Ｓｕｂｔｒａｃｔ  Ｒｅｐｌｙ）にＣｏｎｔｅｘｔ  ＩＤ＝１が付与されてＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ６５）。これにより、ＭＧＣ２０００内でＣｏｎｔｅｘｔ  ＩＤ＝１のリソースが削除されたことが認識できる。
【先行技術文献】
【非特許文献】
【００２８】
【非特許文献１】ＩＴＵ−Ｔ  ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＳＴＡＮＤＡＲＤＩＺＡＴＩＯＮ  ＳＥＣＴＯＲ  ＯＦ  ＩＴＵ  Ｈ．２４８．１（０９／２００５）
【発明の概要】
【発明が解決しようとする課題】
【００２９】
ここで、ＭＧ３０００に再開が発生した場合を考える。
【００３０】
図１０は、図８に示した形態においてＭＧ３０００に再開が発生した場合のゲートウェイ制御方法を説明するためのシーケンス図である。
【００３１】
まず、ＭＧＣ２０００からＭＧ３０００へリソースの生成の要求をする場合、当該生成要求するために、トランザクション情報が生成される（ステップＳ７１）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。続いて、当該トランザクション情報がＭＧＣ２０００内に記憶される（ステップＳ７２）。
【００３２】
そして、当該トランザクション情報に応じたリソースの生成を要求する生成要求（Ａｄｄ  Ｒｅｑｕｅｓｔ）がＭＧＣ２０００からＭＧ３０００へ送信される（ステップＳ７３）。
【００３３】
ＭＧＣ２０００から送信されてきた生成要求がＭＧ３０００にて受信されると、ＭＧ３０００にてリソースが生成される（ステップＳ７４）。このとき、当該リソースを識別するためのリソース識別情報であるＣｏｎｔｅｘｔ  ＩＤが当該リソースに付与される。ここで付与されたＣｏｎｔｅｘｔ  ＩＤを「１」とする。
【００３４】
そして、生成要求に対する生成応答（Ａｄｄ  Ｒｅｐｌｙ）にＣｏｎｔｅｘｔ  ＩＤ＝１が付与されてＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ７５）。
【００３５】
ＭＧ３０００から送信されてきた生成応答に含まれるＣｏｎｔｅｘｔ  ＩＤ＝１が、ステップＳ７２にて記憶されたトランザクション情報に書き込まれる（追加される）。
【００３６】
その後、ＭＧ３０００にて再開が発生した場合（ステップＳ７６）、再開が発生した旨を示す起動通知（Ｓｅｒｖｉｃｅ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ）がＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ７７）。この再開時、ＭＧ３０００にて管理されている払い出し（リソースに付与）中のＣｏｎｔｅｘｔ  ＩＤのリスト情報がすべてクリアされる。つまり、ステップＳ７４にて生成されたリソースに付与されたＣｏｎｔｅｘｔ  ＩＤ「１」についても、払い出し中のＣｏｎｔｅｘｔ  ＩＤには該当しなくなる。
【００３７】
さらにその後、ＭＧＣ２０００からＭＧ３０００へリソースの生成の要求をする場合、リソースの生成を要求する生成要求（Ａｄｄ  Ｒｅｑｕｅｓｔ）がＭＧＣ２０００からＭＧ３０００へ送信される（ステップＳ７８）。ここで、ステップＳ７１のトランザクション情報生成処理およびステップＳ７２のトランザクション情報記憶処理も行われるが、説明は割愛する。
【００３８】
ＭＧＣ２０００から送信されてきた生成要求がＭＧ３０００にて受信されると、リソースが生成される（ステップＳ７９）。このとき、当該リソースを識別するためのリソース識別情報であるＣｏｎｔｅｘｔ  ＩＤが当該リソースに付与される。ここで付与されたＣｏｎｔｅｘｔ  ＩＤを「１」とする。
【００３９】
ここで、Ｃｏｎｔｅｘｔ  ＩＤ＝１に相当するリソースは、ステップＳ７６にて発生した再開によって、ステップＳ７４にて生成されたリソースではなく、ステップＳ７９にて生成されたリソースとなっている。
【００４０】
その後、ＭＧＣ２０００からステップＳ７４にて生成されたリソースの削除を要求する場合、ステップＳ７４にて生成されたリソースをについてＣｏｎｔｅｘｔ  ＩＤ＝１を指定して削除要求が送信される（ステップＳ８０）。
【００４１】
ＭＧＣ２０００から送信されてきた削除要求がＭＧ３０００にて受信されると、Ｃｏｎｔｅｘｔ  ＩＤ＝１に相当するリソースは、ステップＳ７９にて生成されているリソースとなっているため、ステップＳ７９にて生成されたリソースが削除される（ステップＳ８１）。
【００４２】
そして、生成要求に対する生成応答（Ａｄｄ  Ｒｅｐｌｙ）にＣｏｎｔｅｘｔ  ＩＤ＝１が付与されてＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ８２）。また、削除要求に対する変更応答（Ｓｕｂｔｒａｃｔ  Ｒｅｐｌｙ）にＣｏｎｔｅｘｔ  ＩＤ＝１が付与されてＭＧ３０００からＭＧＣ２０００へ送信される（ステップＳ８３）。
【００４３】
この状態では、ステップＳ８０にて送信された削除要求に対して削除されたＣｏｎｔｅｘｔ  ＩＤ＝１に相当するリソースは、ステップＳ７９にて生成されたリソースである。それにもかかわらず、ＭＧＣ２０００は、ステップＳ８０にて送信された削除要求に対して削除されたＣｏｎｔｅｘｔ  ＩＤ＝１に相当するリソースは、ステップＳ７４にて生成されたリソースであると誤認識してしまう。
【００４４】
このように、ＭＧ３０００に再開が発生した場合、ＭＧＣ２０００が認識しているリソースのＣｏｎｔｅｘｔ  ＩＤ情報とＭＧ３０００が認識しているリソースのＣｏｎｔｅｘｔ  ＩＤ情報との間で、食い違いが生じてしまうという問題点がある。
【００４５】
この問題は、要求信号の再送時にも生じるものである。
【００４６】
例えば、削除要求が送信された後、一定期間応答が無い場合に当該削除要求が再送されるが、その送信から再送までの間にＭＧ３０００の再開が発生すると、送信時に指定したＣｏｎｔｅｘｔ  ＩＤが、再送時にはクリアされてしまっている。
【００４７】
このような問題を解決するために、ＭＧＣ２０００にてＭＧ３０００から再開を示す起動通知が受信された場合、ＭＧＣ２０００にて保持しているＣｏｎｔｅｘｔ  ＩＤ情報をクリアさせる方法が一般的に用いられている。
【００４８】
しかし、Ｃｏｎｔｅｘｔ  ＩＤ情報をクリアさせるには、クリア処理が行われている間は、他の処理を行うことができなくなり、サービス停止期間が生じてしまうという問題点がある。
【００４９】
本発明は、上述した課題を解決するゲートウェイ制御装置、ゲートウェイ制御方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００５０】
本発明のゲートウェイ制御装置は、
通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御装置であって、
前記ゲートウェイ装置から該ゲートウェイ装置が起動した旨を示す起動通知を受信した回数をカウントする起動回数カウント部と、
前記ゲートウェイ装置におけるリソースの生成を要求する生成要求を該ゲートウェイ装置へ送信し、また、前記ゲートウェイ装置のリソース状態の変更を要求する変更要求またはリソースの削除を要求する削除要求を、該リソースを識別するためのリソース識別情報を指定して該ゲートウェイ装置へ送信する要求信号送信部と、
前記要求信号送信部が前記生成要求を送信する際に、その時点で前記起動回数カウント部が示しているカウント値である第１のカウント値を含むセッション情報を生成し、前記生成要求に対して前記ゲートウェイ装置から送信されてきた応答信号に含まれる生成したリソースを識別するためのリソース識別情報を前記セッション情報に加えるセッション情報管理部と、
前記セッション情報を記憶する記憶部と、
前記要求信号送信部が前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求にて指定するリソース識別情報を含むセッション情報に含まれる前記第１のカウント値と、その時点で前記起動回数カウント部が示しているカウント値である第２のカウント値とを比較する比較部とを有し、
前記セッション情報管理部は、前記比較部における比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、該セッション情報を前記記憶部から削除し、
前記要求信号送信部は、前記比較部における比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記変更要求または前記削除要求を送信しない。
【００５１】
また、本発明のゲートウェイ制御方法は、
通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御方法であって、
前記ゲートウェイ装置から該ゲートウェイ装置が起動した旨を示す起動通知を受信した回数をカウントする処理と、
前記ゲートウェイ装置におけるリソースの生成を要求する生成要求を該ゲートウェイ装置へ送信する処理と、
前記ゲートウェイ装置のリソース状態の変更を要求する変更要求またはリソースの削除を要求する削除要求を、該リソースを識別するためのリソース識別情報を指定して該ゲートウェイ装置へ送信する送信処理と、
前記生成要求を送信する際に、その時点で前記カウントしているカウント値である第１のカウント値を含むセッション情報を生成する処理と、
前記生成要求に対して前記ゲートウェイ装置から送信されてきた応答信号に含まれる生成したリソースを識別するためのリソース識別情報を前記セッション情報に加える処理と、
前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求にて指定するリソース識別情報を含むセッション情報に含まれる前記第１のカウント値と、その時点で前記カウントしているカウント値である第２のカウント値とを比較する処理と、
該比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記セッション情報を解放する処理とを有し、
前記送信処理は、前記比較の結果、前記第１のカウント値と前記第２のカウント値とが同じである場合のみ、前記ゲートウェイ装置への前記変更要求または前記削除要求を送信する。
【００５２】
また、本発明のプログラムは、
通信装置を接続するゲートウェイ装置を制御するゲートウェイ制御装置に実行させるためのプログラムであって、
前記ゲートウェイ装置から該ゲートウェイ装置が起動した旨を示す起動通知を受信した回数をカウントする手順と、
前記ゲートウェイ装置におけるリソースの生成を要求する生成要求を該ゲートウェイ装置へ送信する手順と、
前記ゲートウェイ装置のリソース状態の変更を要求する変更要求またはリソースの削除を要求する削除要求を、該リソースを識別するためのリソース識別情報を指定して該ゲートウェイ装置へ送信する送信手順と、
前記生成要求を送信する際に、その時点で前記カウントしているカウント値である第１のカウント値を含むセッション情報を生成する手順と、
前記生成要求に対して前記ゲートウェイ装置から送信されてきた応答信号に含まれる生成したリソースを識別するためのリソース識別情報を前記セッション情報に加える手順と、
前記変更要求または前記削除要求を送信する際、該変更要求または該削除要求にて指定するリソース識別情報を含むセッション情報に含まれる前記第１のカウント値と、その時点で前記カウントしているカウント値である第２のカウント値とを比較する手順と、
該比較の結果、前記第１のカウント値と前記第２のカウント値とが異なる場合、前記セッション情報を解放する手順とを実行させ、
前記送信手順は、前記比較の結果、前記第１のカウント値と前記第２のカウント値とが同じである場合のみ、前記ゲートウェイ装置への前記変更要求または前記削除要求を送信する。
【発明の効果】
【００５３】
以上説明したように本発明においては、通信装置を接続するゲートウェイ装置から起動通知を受信した回数をカウントし、リソースの生成要求をゲートウェイ装置へ送信し、生成要求を送信する際に、その時点でカウントしているカウント値である第１のカウント値を含むセッション情報を生成し、生成要求に対してゲートウェイ装置から送信されてきた応答信号に含まれるリソース識別情報をセッション情報に加え、ゲートウェイ装置のリソースの変更要求または削除要求をリソース識別情報を指定してゲートウェイ装置へ送信する際、セッション情報に含まれる第１のカウント値と、その時点でカウントしているカウント値である第２のカウント値とが異なる場合、セッション情報を解放し、第１のカウント値と第２のカウント値とが同じである場合のみ、ゲートウェイ装置へ変更要求または削除要求を送信する構成としたため、ゲートウェイ装置の再開後に集中的なサービス停止期間の発生を防ぐことができる。
【図面の簡単な説明】
【００５４】
【図１】本発明のゲートウェイ制御装置の実施の一形態を示す図である。
【図２】図１に示したＭＧＣの内部構成の一例を示す図である。
【図３】図１に示したＭＧにて管理しているＣｏｎｔｅｘｔ  ＩＤ情報のリストの一例を示す図である。
【図４】図２に示したセッション情報管理部にて生成されるセッション情報の一例を示す図である。
【図５】図２に示したトランザクション情報管理部にて生成されるトランザクション情報の一例を示す図である。
【図６】本形態におけるゲートウェイ制御方法の第１の例を示すシーケンス図である。
【図７】本形態におけるゲートウェイ制御方法の第２の例を示すシーケンス図である。
【図８】ＭＧおよびＭＧＣを用いた一般的な通信システムの形態の一例を示す図である。
【図９】図８に示した形態におけるゲートウェイ制御方法を説明するためのシーケンス図である。
【図１０】図１０は、図８に示した形態においてＭＧに再開が発生した場合のゲートウェイ制御方法を説明するためのシーケンス図である。
【発明を実施するための形態】
【００５５】
以下に、本発明の実施の形態について図面を用いて説明する。
【００５６】
図１は、本発明のゲートウェイ制御装置の実施の一形態を示す図である。
【００５７】
本形態は図１に示すように、ＳＩＰサーバ１００と、ＭＧＣ２００と、ＭＧ３００と、端末４００，５００とから構成されている。
【００５８】
ＳＩＰサーバ１００は、通信プロトコルの１つであるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用して端末４００，５００の呼制御を行うサーバである。
【００５９】
端末４００は、通信機能を有する通信端末である。端末４００は、既存の電話交換網と接続された通信端末であっても良いし、ＩＰ網と接続された通信端末であっても良い。
【００６０】
端末５００は、通信機能を有する通信端末である。端末５００は、既存の電話交換網と接続された通信端末であっても良いし、ＩＰ網と接続された通信端末であっても良い。
【００６１】
ＭＧ３００は、端末４００と端末５００とを接続する。ここで、端末４００と接続されたネットワークと端末５００と接続されたネットワークとが同種のネットワークである場合（例えば、双方が既存の電話交換網である場合や、双方がＩＰ網である場合）、ＭＧ３００は、不正パケットのフィルタリング、帯域制限、優先度制御、ＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  ａｎｄ  Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）変換等を行う。また、端末４００と接続されたネットワークと端末５００と接続されたネットワークとが異種のネットワークである場合（例えば、一方が既存の電話交換網であり、他方がＩＰ網である場合）、ＭＧ３００は、既存の電話交換網のインタフェースとＩＰ網のインタフェースとの変換を行う。
【００６２】
ＭＧＣ２００は、Ｈ．２４８のプロトコルを用いてＭＧ３００を制御するゲートウェイ制御装置である。
【００６３】
図２は、図１に示したＭＧＣ２００の内部構成の一例を示す図である。
【００６４】
図１に示したＭＧＣ２００には図２に示すように、ＳＩＰサーバ通信部２０１と、ＭＧ通信部２０２と、起動回数カウント部２０３と、要求信号送信部２０４と、セッション情報管理部２０５と、記憶部２０６と、比較部２０７と、トランザクション情報管理部２０８とが設けられている。
【００６５】
ＳＩＰサーバ通信部２０１は、図１に示したＳＩＰサーバ１００と通信を行う。
【００６６】
ＭＧ通信部２０２は、図１に示したＭＧ３００と通信を行う。また、ＭＧ通信部２０２は、ＭＧ３００から送信されてきた応答信号に付与されたリソースを識別するためのリソース識別情報であるＣｏｎｔｅｘｔ  ＩＤをセッション情報管理部２０５へ出力する。また、ＭＧ通信部２０２は、ＭＧ３００が再開（起動）した際に送信されてくる起動通知であるＳｅｒｖｉｃｅ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔを起動回数カウント部２０３へ出力する。また、ＭＧ通信部２０２は、要求信号送信部２０４から出力された要求信号に対する応答信号がＭＧ３００から送信されてきた場合、その旨を要求信号送信部２０４へ通知する。
【００６７】
起動回数カウント部２０３は、ＭＧ通信部２０２からＳｅｒｖｉｃｅ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔが出力されてきた回数をカウントするカウンタである。また、起動回数カウント部２０３は、カウントした回数であるカウント値をセッション情報管理部２０５とトランザクション情報管理部２０８とへ出力する。
【００６８】
要求信号送信部２０４は、ＭＧ３００に対して、リソースの生成を要求する生成要求（Ａｄｄ  Ｒｅｑｕｅｓｔ）、リソースの状態の変更を要求する変更要求（Ｍｏｄｉｆｙ  Ｒｅｑｕｅｓｔ）、リソースの削除を要求する削除要求（Ｓｕｂｔｒａｃｔ  Ｒｅｑｕｅｓｔ）の要求信号を生成してＭＧ通信部２０２を介してＭＧ３００へ送信する。このとき、比較部２０７から出力された比較結果に基づいて要求信号を送信する。また、変更要求または削除要求を生成する場合、記憶部２０６に記憶されているＣｏｎｔｅｘｔ  ＩＤを付与して要求信号を生成する。これにより、変更または削除したいリソースのＣｏｎｔｅｘｔ  ＩＤを指定してリソースの状態変更や削除を要求することができる。
【００６９】
セッション情報管理部２０５は、要求信号送信部２０４が生成要求の要求信号を生成した際に、当該要求信号に応じたセッション情報を生成して記憶部２０６へ書き込む。また、セッション情報管理部２０５は、ＭＧ通信部２０２から出力されてきたＣｏｎｔｅｘｔ  ＩＤを記憶部２０６に記憶されている相応のセッション情報に追加する。また、起動回数カウント部２０３から出力されたカウント値を記憶部２０６に記憶されている相応のセッション情報に追加する。
【００７０】
記憶部２０６は、セッション情報管理部２０５によって書き込まれたセッション情報およびトランザクション情報管理部２０８によって書き込まれたトランザクション情報を記憶する。
【００７１】
比較部２０７は、トランザクション情報管理部２０８がトランザクション情報を生成する際に、記憶部２０６に記憶されている相応のセッション情報に含まれるカウント値（第１のカウント値）と、起動回数カウント部２０３が示すカウント値（第２のカウント値）とを比較する。また、比較部２０７は、当該比較の結果を要求信号送信部２０４へ出力する。
【００７２】
トランザクション情報管理部２０８は、要求信号送信部２０４が変更要求または削除要求の要求信号を生成した際に、当該要求信号に応じたトランザクション情報を生成して記憶部２０６へ書き込む。
【００７３】
図３は、図１に示したＭＧ３００にて管理しているＣｏｎｔｅｘｔ  ＩＤ情報のリストの一例を示す図である。
【００７４】
図１に示したＭＧ３００では図３に示すように、払い出し中（使用中）のリソースのＣｏｎｔｅｘｔ  ＩＤがリストアップされている。
【００７５】
例えば、図３に示すように、「０００１」と「０００３」と「００１０」と「００１５」とがリストアップされている。これは、「０００１」、「０００３」、「００１０」および「００１５」であるＣｏｎｔｅｘｔ  ＩＤはすでに使用されていることを示している。
【００７６】
図４は、図２に示したセッション情報管理部２０５にて生成されるセッション情報の一例を示す図である。
【００７７】
図２に示したセッション情報管理部２０５にて生成されるセッション情報は図４に示すように、当該セッション情報を識別するためのセッション識別情報であるＳｅｓｓｉｏｎ  ＩＤ、ＭＧ３００から付与された（払い出された）Ｃｏｎｔｅｘｔ  ＩＤ、そのリソースを付与したＭＧを識別するためのＭＧ識別情報であるＭＧ  ＩＤ、接続回数、当該セッション情報に応じて生成されたトランザクション情報を識別するためのトランザクション識別情報であるＴｒａｎｓａｃｔｉｏｎ  ＩＤ等が含まれている。
【００７８】
ここで接続回数は、当該セッション情報が生成されたときの起動回数カウント部２０３が示すカウント値である。
【００７９】
図５は、図２に示したトランザクション情報管理部２０８にて生成されるトランザクション情報の一例を示す図である。
【００８０】
図２に示したトランザクション情報管理部２０８にて生成されるトランザクション情報は図５に示すように、当該トランザクション情報を識別するためのトランザクション識別情報であるＴｒａｎｓａｃｔｉｏｎ  ＩＤ、そのリソースを付与したＭＧを識別するためのＭＧ識別情報であるＭＧ  ＩＤ、生成されるトランザクション情報に相応するセッション情報に含まれるＣｏｎｔｅｘｔ  ＩＤ、タイマ情報、接続回数等が含まれている。
【００８１】
ここでタイマ情報は、再送に用いる時間等を示す情報である。
【００８２】
また、接続回数は、当該セッション情報に相応する（Ｃｏｎｔｅｘｔ  ＩＤが当該セッション情報と同じである）トランザクション情報が生成されたときの起動回数カウント部２０３が示すカウント値である。
【００８３】
以下に、本形態におけるゲートウェイ制御方法について説明する。
【００８４】
図６は、本形態におけるゲートウェイ制御方法の第１の例を示すシーケンス図である。この第１の例では、ＭＧＣ２００からＭＧ３００へリソース生成を要求してから、リソース状態の変更を要求、リソース削除を要求するまで、ＭＧ３００が再開しなかった場合を例に挙げて説明する。
【００８５】
まず、ＭＧ３００にて再開が発生すると（ステップＳ１）、再開が発生した旨を示す起動通知（Ｓｅｒｖｉｃｅ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ）がＭＧ３００からＭＧＣ２００へ送信される（ステップＳ２）。
【００８６】
すると、起動回数カウント部２０３が示すカウント値が、１つカウントアップされる（ステップＳ３）。
【００８７】
その後、リソースの生成を要求する場合、当該生成要求するために、セッション情報がセッション情報管理部２０５にて生成される（ステップＳ４）。このセッション情報には固有の識別情報であるセッションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。このとき、起動回数カウント部２０３が示しているカウント値が接続回数として当該セッション情報に含まれる。そして、当該セッション情報がセッション情報管理部２０５によって記憶部２０６に記憶される（ステップＳ５）。
【００８８】
そして、リソースの生成を要求する生成要求（Ａｄｄ  Ｒｅｑｕｅｓｔ）が、要求信号送信部２０４からＭＧ通信部２０２を介してＭＧ３００へ送信される（ステップＳ６）。
【００８９】
ＭＧＣ２００から送信されてきた生成要求がＭＧ３００にて受信されると、ＭＧ３００にてリソースが生成される（ステップＳ７）。このとき、当該リソースを識別するためのリソース識別情報であるＣｏｎｔｅｘｔ  ＩＤが当該リソースに付与される。
【００９０】
そして、生成要求に対する生成応答（Ａｄｄ  Ｒｅｐｌｙ）に当該Ｃｏｎｔｅｘｔ  ＩＤが付与されてＭＧ３００からＭＧＣ２００へ送信される（ステップＳ８）。
【００９１】
ＭＧ３００から送信されてきた生成応答がＭＧ通信部２０２にて受信されると、当該生成応答に含まれるＣｏｎｔｅｘｔ  ＩＤが、ＭＧ通信部２０２からセッション情報管理部２０５へ出力される。
【００９２】
すると、セッション情報管理部２０５によって、ステップＳ５にて記憶されたセッション情報に当該Ｃｏｎｔｅｘｔ  ＩＤが書き込まれる（追加される）。
【００９３】
その後、当該Ｃｏｎｔｅｘｔ  ＩＤのリソース状態の変更を要求する場合、当該変更要求するために、トランザクション情報管理部２０８にてトランザクション情報が生成される（ステップＳ９）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。また、変更を要求するリソースのＣｏｎｔｅｘｔ  ＩＤが当該トランザクション情報に含まれる。
【００９４】
ここで、トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報に含まれる接続回数であるカウント値（第１のカウント値）と、このときの起動回数カウント部２０３が示しているカウント値（第２のカウント値）とが比較部２０７にて比較される（ステップＳ１０）。
【００９５】
ここでは、トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報に含まれる接続回数であるカウント値（第１のカウント値）と、このときの起動回数カウント部２０３が示しているカウント値（第２のカウント値）とが同じであるため、当該トランザクション情報がトランザクション情報管理部２０８によって記憶部２０６に記憶される（ステップＳ１１）。
【００９６】
そして、当該Ｃｏｎｔｅｘｔ  ＩＤが含まれたリソース状態の変更を要求する変更要求（Ｍｏｄｉｆｙ  Ｒｅｑｕｅｓｔ）が、要求信号送信部２０４からＭＧ通信部２０２を介してＭＧ３００へ送信される（ステップＳ１２）。
【００９７】
ＭＧＣ２００から送信されてきた変更要求がＭＧ３００にて受信されると、ＭＧ３００にて変更要求に含まれているＣｏｎｔｅｘｔ  ＩＤのリソース状態が変更される（ステップＳ１３）。
【００９８】
そして、変更要求に対する変更応答（Ｍｏｄｉｆｙ  Ｒｅｐｌｙ）に当該Ｃｏｎｔｅｘｔ  ＩＤが付与されてＭＧ３００からＭＧＣ２００へ送信される（ステップＳ１４）。
【００９９】
その後、当該Ｃｏｎｔｅｘｔ  ＩＤのリソースの削除を要求する場合、当該削除要求するために、トランザクション情報管理部２０８にてトランザクション情報が生成される（ステップＳ１５）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。また、削除を要求するリソースのＣｏｎｔｅｘｔ  ＩＤが当該トランザクション情報に含まれる。
【０１００】
ここで、トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報に含まれる接続回数であるカウント値（第１のカウント値）と、このときの起動回数カウント部２０３が示しているカウント値（第２のカウント値）とが比較部２０７にて比較される（ステップＳ１６）。
【０１０１】
ここでは、トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報に含まれる接続回数であるカウント値（第１のカウント値）と、このときの起動回数カウント部２０３が示しているカウント値（第２のカウント値）とが同じであるため、当該トランザクション情報がトランザクション情報管理部２０８によって記憶部２０６に記憶される（ステップＳ１７）。
【０１０２】
そして、当該Ｃｏｎｔｅｘｔ  ＩＤが含まれたリソースの削除を要求する削除要求（Ｓｕｂｔｒａｃｔ  Ｒｅｑｕｅｓｔ）が、要求信号送信部２０４からＭＧ通信部２０２を介してＭＧ３００へ送信される（ステップＳ１８）。
【０１０３】
ＭＧＣ２００から送信されてきた削除要求がＭＧ３００にて受信されると、ＭＧ３００にて削除要求に含まれているＣｏｎｔｅｘｔ  ＩＤのリソースが削除される（ステップＳ１９）。
【０１０４】
そして、削除要求に対する削除応答（Ｓｕｂｔｒａｃｔ  Ｒｅｐｌｙ）に当該Ｃｏｎｔｅｘｔ  ＩＤが付与されてＭＧ３００からＭＧＣ２００へ送信される（ステップＳ２０）。
【０１０５】
図７は、本形態におけるゲートウェイ制御方法の第２の例を示すシーケンス図である。この第２の例では、ＭＧＣ２００からＭＧ３００へリソース生成を要求してから、リソース状態の変更を要求するまでの間に、ＭＧ３００が再開した場合を例に挙げて説明する。
【０１０６】
まず、ＭＧ３００にて再開が発生すると（ステップＳ２１）、再開が発生した旨を示す起動通知（Ｓｅｒｖｉｃｅ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ）がＭＧ３００からＭＧＣ２００へ送信される（ステップＳ２２）。
【０１０７】
すると、起動回数カウント部２０３が示すカウント値が、１つカウントアップされる（ステップＳ２３）。
【０１０８】
その後、リソースの生成を要求する場合、当該生成要求するために、セッション情報がセッション情報管理部２０５にて生成される（ステップＳ２４）。このセッション情報には固有の識別情報であるセッションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。このとき、起動回数カウント部２０３が示しているカウント値が接続回数として当該セッション情報に含まれる。そして、当該セッション情報がセッション情報管理部２０５によって記憶部２０６に記憶される（ステップＳ２５）。
【０１０９】
そして、リソースの生成を要求する生成要求（Ａｄｄ  Ｒｅｑｕｅｓｔ）が、要求信号送信部２０４からＭＧ通信部２０２を介してＭＧ３００へ送信される（ステップＳ２６）。
【０１１０】
ＭＧＣ２００から送信されてきた生成要求がＭＧ３００にて受信されると、ＭＧ３００にてリソースが生成される（ステップＳ２７）。このとき、当該リソースを識別するためのリソース識別情報であるＣｏｎｔｅｘｔ  ＩＤが当該リソースに付与される。
【０１１１】
そして、生成要求に対する生成応答（Ａｄｄ  Ｒｅｐｌｙ）に当該Ｃｏｎｔｅｘｔ  ＩＤが付与されてＭＧ３００からＭＧＣ２００へ送信される（ステップＳ２８）。
【０１１２】
ＭＧ３００から送信されてきた生成応答がＭＧ通信部２０２にて受信されると、当該生成応答に含まれるＣｏｎｔｅｘｔ  ＩＤが、ＭＧ通信部２０２からセッション情報管理部２０５へ出力される。
【０１１３】
すると、セッション情報管理部２０５によって、ステップＳ２５にて記憶されたセッション情報に当該Ｃｏｎｔｅｘｔ  ＩＤが書き込まれる（追加される）。
【０１１４】
その後、ＭＧ３００にて再開が発生すると（ステップＳ２９）、再開が発生した旨を示す起動通知（Ｓｅｒｖｉｃｅ  Ｃｈａｎｇｅ  Ｒｅｑｕｅｓｔ）がＭＧ３００からＭＧＣ２００へ送信される（ステップＳ３０）。
【０１１５】
すると、起動回数カウント部２０３が示すカウント値が、１つカウントアップされる（ステップＳ３１）。
【０１１６】
その後、当該Ｃｏｎｔｅｘｔ  ＩＤのリソース状態の変更を要求する場合、当該変更要求するために、トランザクション情報管理部２０８にてトランザクション情報が生成される（ステップＳ３２）。このトランザクション情報には固有の識別情報であるトランザクションＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が付与される。また、変更を要求するリソースのＣｏｎｔｅｘｔ  ＩＤが当該トランザクション情報に含まれる。
【０１１７】
ここで、トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報に含まれる接続回数であるカウント値（第１のカウント値）と、このときの起動回数カウント部２０３が示しているカウント値（第２のカウント値）とが比較部２０７にて比較される（ステップＳ３３）。
【０１１８】
ここでは、トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報に含まれる接続回数であるカウント値（第１のカウント値）と、このときの起動回数カウント部２０３が示しているカウント値（第２のカウント値）とが異なる。そのため、要求信号送信部２０４から送信しようとした変更要求は送信されない。また、ステップＳ３２にて生成されたトランザクション情報が解放される（ステップＳ３４）。このとき、当該トランザクション情報に含まれるＣｏｎｔｅｘｔ  ＩＤが含まれているセッション情報も記憶部２０６から削除（解放）される。
【０１１９】
なお、ステップＳ３２にて生成されるトランザクション情報が変更要求のためのものではなく、削除要求のためのものである場合も、ステップＳ３２〜Ｓ３４と同様の処理が行われる。
【０１２０】
以上説明したように、ＭＧＣ２００内で管理（認識）しているリソース情報のうち、ＭＧ３００の再開前に送信した生成要求に対してＭＧ３００再開後に送信しようとする変更要求または削除要求に係るリソースのリソース情報のみを削除するため、集中的なサービス停止期間の発生を防ぐことができる。
【０１２１】
なお、上述したＭＧＣ２００の処理は、目的に応じて作製された論理回路で行うようにしても良い。また、処理内容を記述したプログラムをＭＧＣ２００にて読取可能な記録媒体に記録し、この記録媒体に記録されたプログラムをＭＧＣ２００に読み込ませ、実行するものであっても良い。ＭＧＣ２００にて読取可能な記録媒体とは、フロッピーディスク（登録商標）、光磁気ディスク、ＤＶＤ、ＣＤなどの移設可能な記録媒体の他、ＭＧＣ２００に内蔵されたＲＯＭ、ＲＡＭ等のメモリやＨＤＤ等を指す。この記録媒体に記録されたプログラムは、ＭＧＣ２００内のＣＰＵにて読み込まれ、ＣＰＵの制御によって、上述したものと同様の処理が行われる。ここで、ＣＰＵは、プログラムが記録された記録媒体から読み込まれたプログラムを実行するコンピュータとして動作するものである。
【符号の説明】
【０１２２】
１００    ＳＩＰサーバ
２００    ＭＧＣ
２０１    ＳＩＰサーバ通信部
２０２    ＭＧ通信部
２０３    起動回数カウント部
２０４    要求信号送信部
２０５    セッション情報管理部
２０６    記憶部
２０７    比較部
２０８    トランザクション情報管理部
３００    ＭＧ
４００，５００    端末
【図１】
2010166496.tif 000003
【図２】
2010166496.tif 000004
【図３】
2010166496.tif 000005
【図４】
2010166496.tif 000006
【図５】
2010166496.tif 000007
【図６】
2010166496.tif 000008
【図７】
2010166496.tif 000009
【図８】
2010166496.tif 000010
【図９】
2010166496.tif 000011
【図１０】
2010166496.tif 000012