JP2010183480A - リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム - Google Patents

Abstract

【課題】着信側のホーム網に属するＳＩＰサーバの障害によって着信側ＩＭＳ端末が切断されている状態でも、発信側ＩＭＳ端末から着信側ＩＭＳ端末宛の接続要求があると、強制的に着信側ＩＭＳ端末を再登録し、切断することなくセッションを確立することができる、リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラムを提供することを目的とする。
【解決手段】ＩＰ網内のノード１３２において、発信側端末１１１から着信側端末１１２宛のリクエストを処理する方法であって、発信側端末１１１から着信側端末１１２宛のリクエストを受信する受信ステップと、着信側端末１１１側に接続された下流ノード１２３が障害状況にあるか否かを判定する判定ステップと、判定ステップにおいて障害状況であると判定された場合、発信側端末１１１に対し、リクエストに対応するための暫定レスポンスを返信する返信ステップとを備える。
【選択図】図１

Description

本発明は、リクエストの送信を制御するリクエスト送信制御装置及びリクエスト送信制御方法、リクエスト送信制御装置を含むシステム、及びリクエスト送信制御装置用のプログラムに関する。

ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）には様々なエンティティがある。その中で中核を担う機能がセッション管理機能（ＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ））である。端末から発信されたＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージは、端末が存在するネットワークにあるＰ−ＣＳＣＦ（Ｐｒｏｘｙ ＣＳＣＦ）から、ホーム網のＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ ＣＳＣＦ）に送られ、ホーム網のＳ−ＣＳＣＦでメッセージの分析を行う。その結果、Ｓ−ＣＳＣＦは着信側のＳ−ＣＳＣＦにＳＩＰメッセージを送信し、通信サービスを提供する。また、Ｓ−ＣＳＣＦはユーザ登録時に加入者プロファイルをＨＳＳからダウンロードすることにより柔軟な呼制御を可能とする。

しかし、着信側のＰ−ＣＳＣＦに障害が発生した場合、同じく着信側のＳ−ＣＳＣＦは、発信側ＩＭＳ端末から着信側ＩＭＳ端末宛のＳＩＰメッセージを受信しても、当該ＳＩＰメッセージを着信側Ｐ−ＣＳＣＦに送信することができないため、発信側ＩＭＳ端末からのリクエストはエラーとなる。同様に、着信側のＳ−ＣＳＣＦに障害が発生した場合にも、発信側のＳ−ＣＳＣＦは、発信側ＩＭＳ端末から着信側ＩＭＳ端末宛のＳＩＰメッセージを受信しても、当該ＳＩＰメッセージを着信側Ｓ−ＣＳＣＦに送信することができないため、発信側ＩＭＳ端末のリクエストはエラーとなる。

特開２００５−５１２４２１号公報 特開２００７−３１８６２９号公報 特開２００７−３２５１９１号公報 特開２００７−５１０３２８号公報

上記のように、ＩＭＳにおける発信側ＩＭＳ端末は、着信側のホーム網に属するＳＩＰサーバに障害が生じると、着信側ＩＭＳ端末への接続要求を切断されてしまうため、再度、接続要求をやり直さなければならないという問題がある。その場合、発信側ＩＭＳ端末のユーザは、再度、ＩＭＳネットワークに着信側ＩＭＳ端末が登録されるのを待たなければならないことになるが、着信側ＩＭＳ端末が再登録されたことを発信側ＩＭＳ端末に知らしめる方法がないという問題がある。

本発明は、このような事情に鑑みてなされたものであって、着信側のホーム網に属するＳＩＰサーバの障害によって着信側ＩＭＳ端末が切断されている状態でも、発信側ＩＭＳ端末から着信側ＩＭＳ端末宛の接続要求があると、強制的に着信側ＩＭＳ端末を再登録し、切断することなくセッションを確立することができる、リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラムを提供することを目的とする。

上記課題を解決するための本発明に係るリクエスト送信制御装置は、ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置であって、前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部とを備える。

上記課題を解決するための本発明に係るリクエスト送信制御方法は、ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御方法であって、前記発信側端末から前記着信側端末宛のリクエストを受信する受信ステップと、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定ステップと、前記判定ステップにおいて前記下流ノードが障害状況であると判定された場合、前記受信ステップにおいて受信された前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信ステップとを備える。

上記課題を解決するための本発明に係るシステムは、ＩＰ網においてリクエストを発信する発信側端末と、前記発信側端末からのリクエストを着信する着信側端末と、前記ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置とを備えるシステムであって、前記リクエスト送信制御装置は、前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部とを有する。

上記課題を解決するための本発明に係るプログラムは、ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置用のプログラムであって、前記リクエスト送信制御装置を、前記発信側端末から前記着信側端末宛のリクエストを受信する受信部、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部、前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部として機能させる。

本発明によれば、着信側のホーム網に属するＳＩＰサーバの障害によって着信側ＩＭＳ端末が切断されている状態でも、発信側ＩＭＳ端末から着信側ＩＭＳ端末宛の接続要求があると、強制的に着信側ＩＭＳ端末を再登録し、切断することなくセッションを確立することができる。

一実施形態に係るリクエスト送信システム１００の利用環境の一例を示す。 本発明に係るリクエスト送信制御装置を示す機能ブロック図である。 図１の実施形態におけるリクエスト処理手順を示すフローチャートである。 別の実施形態に係るリクエスト送信システム１００の利用環境の一例を示す。 図２の実施形態におけるリクエスト処理手順を示すフローチャートである。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、一実施形態に係るリクエスト送信システム１００の利用環境の一例を示す。リクエスト送信システム１００は、例えば、ＩＭＳをベースとする。本実施形態のリクエスト送信システム１００は、ＩＭＳ端末１１１、１１２と、Ｐ−ＣＳＣＦ１２１〜１２３と、Ｓ−ＣＳＣＦ１３１、１３２と、ＨＳＳ１４１とを備える。ＩＭＳ端末１１１、１１２は、ＩＭＳ端末１１１を発信側のＩＭＳ端末とし、ＩＭＳ端末１１２を発信側ＩＭＳ端末１１１から着信を受ける着信側ＩＭＳ端末とする。

Ｐ−ＣＳＣＦ１２１〜１２３は、発信側のホーム網に属する発信側Ｐ−ＣＳＣＦ１２１と、着信側のホーム網に属する着信側Ｐ−ＣＳＣＦ１２２、１２３とに分類される。同様に、Ｓ−ＣＳＣＦ１３１、１３２は、発信側のホーム網に属する発信側Ｓ−ＣＳＣＦ１３１と、着信側のホーム網に属する着信側Ｓ−ＣＳＣＦ１３２とに分類される。ＨＳＳ１４１は、ＩＭＳで用いるユーザＩＤの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各ＩＭＳサービス利用可否の管理、ユーザ移動管理のためのデータベースである。

発信側ＩＭＳ端末１１１は、アクセス・ネットワークを介して発信側Ｐ−ＣＳＣＦ１２１と接続される。発信側Ｐ−ＣＳＣＦ１２１は、同じ発信側のホーム網に属する発信側Ｓ−ＣＳＣＦ１３１と接続される。発信側Ｓ−ＣＳＣＦ１３１は、着信側のホーム網に属する着信側Ｓ−ＣＳＣＦ１３２と接続される。着信側Ｓ−ＣＳＣＦ１３２は、同じ着信側のホーム網に属する着信側Ｐ−ＣＳＣＦ１２２、１２３と接続される。着信側Ｐ−ＣＳＣＦ１２２、１２３は、共にアクセス・ネットワークを介して着信側ＩＭＳ端末１１２と接続することができる。なお、本実施形態では、着信側ＩＭＳ端末１１２は、元々、着信側Ｐ−ＣＳＣＦ１２３と接続されていたが、着信側Ｐ−ＣＳＣＦ１２３の障害発生により、当該着信側Ｐ−ＣＳＣＦ１２３との接続が途絶えている状況を想定する。

図２は、本発明に係るリクエスト送信制御装置を示す機能ブロック図である。リクエスト送信制御装置３００は、受信部３１０と、判定部３２０と、返信部３３０と、再登録要求部３４０と、送信部３５０とを備える。受信部３１０は、上流ノードから発信側ＩＭＳ端末１１１から着信側ＩＭＳ端末１１２宛のリクエストを受信する。判定部３２０は、着信側ＩＭＳ端末１１２側に接続された下流ノードが障害状況にあるか否かを判定する。返信部３３０は、判定部３２０が下流ノードを障害状況であると判定した場合、受信部３１０が受信したリクエストに対応するための暫定レスポンスを、発信側ＩＭＳ端末１１１に返信する。

再登録要求部３４０は、判定部３２０が障害状態の下流ノード以外の正常状態の下流ノードを確認した場合、当該正常状態の下流ノードを経由して、着信側ＩＭＳ端末１１２へＩＰ網への再登録を要求する。送信部３５０は、着信側ＩＭＳ端末１１２がＩＰ網に再登録された場合、受信部３１０が受信したリクエストを、正常状態の下流ノードを介して着信側ＩＭＳ端末宛１１２に送信する。

また、返信部３３０は、再登録要求部３４０が着信側端末１１２へＩＰ網への再登録を要求してから、所定時間内にセッションが確立されない場合、発信側端末１１１に対し、サーバ・タイムアウト・レスポンスを返信する。なお、本実施形態では、着信側Ｓ−ＣＳＣＦ１３２が本発明に係るリクエスト送信制御装置として機能する。

図３は、図１の実施形態におけるリクエスト処理手順を示すフローチャートである。以下、図３を参照して、本実施形態のＩＰ網内のノードにおけるリクエスト処理手順について説明する。着信側Ｓ−ＣＳＣＦ１３２は、着信側ＩＭＳ端末方向に接続された着信側Ｐ−ＣＳＣＦ１２２、１２３に対し、周期的にＳＩＰのＯＰＴＩＯＮＳリクエストを用いたヘルスチェック信号を送信し、これに対する応答の有無を基に着信側Ｐ−ＣＳＣＦ１２２、１２３の障害の有無を判定する（Ｓ１０１）。

より詳細には、着信側Ｓ−ＣＳＣＦ１３２は、着信側Ｐ−ＣＳＣＦからの応答があった場合には、そのステータスコードの内容により当該応答のあった着信側Ｐ−ＣＳＣＦの障害の有無を判定する。また、着信側Ｓ−ＣＳＣＦ１３２は、着信側Ｐ−ＣＳＣＦから応答がない場合には、ＯＰＴＩＯＮＳリクエストの再送タイムアウトを以て着信側Ｐ−ＣＳＣＦを障害状態とみなす。

なお、本実施形態の場合、着信側Ｓ−ＣＳＣＦ１３２は、着信側Ｐ−ＣＳＣＦ１２２を正常状態と判定し、着信側Ｐ−ＣＳＣＦ１２３を障害状態と判定したものとする。即ち、着信側ＩＭＳ端末１１２は、この時点でＩＭＳから切断されているものとする。そして、着信側Ｓ−ＣＳＣＦ１３２は、このように障害状態の有無を判定した着信側Ｐ−ＣＳＣＦ１２２、１２３の当該状態の内容について情報登録を行う（Ｓ１０２）。

発信側ＩＭＳ端末１１１のユーザが、上記のように、着信側ＩＭＳ端末１１２がＩＭＳから切断されていることを知らずに、当該発信側ＩＭＳ端末１１１を使用して着信側ＩＭＳ１１２端末宛に発信要求を行ったとする。着信側Ｓ−ＣＳＣＦ１３２は、発信側ＩＭＳ端末１１１から発信された発信要求を、発信側Ｐ−ＣＳＣＦ１２１、及び発信側Ｓ−ＣＳＣＦ１３１を順に経由して受信する（Ｓ１０３）。

着信側Ｓ−ＣＳＣＦ１３２は、本来この発信要求を着信側Ｐ−ＣＳＣＦ１２３を経由して着信側ＩＭＳ端末１１２へ送信しなければならない。しかし、着信側Ｓ−ＣＳＣＦ１３２は、着信側Ｐ−ＣＳＣＦ１２３に障害が発生していると判定しているので、発信側ＩＭＳ端末１１１から着信側ＩＭＳ端末１１２宛の発信要求を送信せずに、一旦保持する（Ｓ１０４）。この時、着信側Ｓ−ＣＳＣＦ１３２は、発信側ＩＭＳ端末１１１がタイムアウトになってしまうのを防止するために、例えば、１００ Ｔｒｙｉｎｇ等の暫定応答を返信する。

次に、着信側Ｓ−ＣＳＣＦ１３２は、例えば、優先順位選択方式、ラウンドロビン分散方式、比率分散方式等の方法によって、正常状態の着信側Ｐ−ＣＳＣＦを選択し、当該正常状態の着信側Ｐ−ＣＳＣＦを経由して、強制的に着信側ＩＭＳ端末１１２の再登録要求を行う（Ｓ１０５）。本実施形態の場合、着信側Ｓ−ＣＳＣＦ１３２は、着信側Ｐ−ＣＳＣＦ１２２を正常状態の着信側Ｐ−ＣＳＣＦとして選択するものとする。

着信側Ｐ−ＣＳＣＦ１２２は、着信側Ｓ−ＣＳＣＦ１３２から再登録要求を受信すると、ＨＳＳ１４１から着信側ＩＭＳ端末１１２の加入者プロファイルをダウンロードする。そして、着信側Ｐ−ＣＳＣＦ１２２は、ダウンロードした着信側ＩＭＳ端末１１２の加入者プロファイルに登録されているＩＰアドレスかＳＩＰ−ＵＲＩを用いて、着信側ＩＭＳ端末１１２に対し、１ｓｔ−ＲＥＧＩＳＴＥＲ実施命令を行う（Ｓ１０６）。着信側ＩＭＳ端末１１２は、着信側Ｐ−ＣＳＣＦ１２２からの１ｓｔ−ＲＥＧＩＳＴＥＲ実施命令を受けて、着信側Ｐ−ＣＳＣＦ１２２経由で１ｓｔ−ＲＥＧＩＳＴＥＲを実施し、再登録される（Ｓ１０７）。

着信側Ｓ−ＣＳＣＦ１３２は、着信側ＩＭＳ端末１１２が再登録されると、保持していた発信側ＩＭＳ端末１１１から着信側ＩＭＳ端末１１２宛の発信要求を、着信側Ｐ−ＣＳＣＦ１２２経由で着信側ＩＭＳ端末１１２へ送信し、セッションを確立する（Ｓ１０８）。また、着信側Ｓ−ＣＳＣＦ１３２は、正常状態の着信側Ｐ−ＣＳＣＦが存在しない等の理由があり、再登録要求を行ってから所定時間経過してもセッションが確立できない場合には、発信側ＩＭＳ端末１１１に対し、サーバ・タイムアウト・レスポンスを返信する。

このように、着信側Ｓ−ＣＳＣＦ１３２が、従来の方法にないＣＳＣＦ機能を発揮することによって、発信側ＩＭＳ端末１１１、及び着信側ＩＭＳ端末１１２に何ら影響を与えることなくセッションを確立することができる。

図４は、別の実施形態に係るリクエスト送信システム１００の利用環境の一例を示す。リクエスト送信システム２００は、上記実施形態と同様にＩＭＳをベースとする。また、本実施形態における各ＣＳＣＦの構成は、上記実施形態の図２を参照して説明したものと同様の構成であるので、詳細な説明を省略する。

本実施形態のＩＭＳは、ＩＭＳ端末２１１、２１２と、Ｐ−ＣＳＣＦ２２１、２２２と、Ｓ−ＣＳＣＦ２３１〜２３３と、ＨＳＳ２４１とを備える。ＩＭＳ端末２１１、２１２は、ＩＭＳ端末２１１を発信側のＩＭＳ端末とし、ＩＭＳ端末２１２を発信側ＩＭＳ端末２１１から着信を受ける着信側ＩＭＳ端末とする。

Ｐ−ＣＳＣＦ２２１、２２２は、発信側のホーム網に属する発信側Ｐ−ＣＳＣＦ２２１と、着信側のホーム網に属する着信側Ｐ−ＣＳＣＦ２２２とに分類される。同様に、Ｓ−ＣＳＣＦ２３１〜２３３は、発信側のホーム網に属する発信側Ｓ−ＣＳＣＦ２３１と、着信側のホーム網に属する着信側Ｓ−ＣＳＣＦ２３２、２３３とに分類される。ＨＳＳ２４１は、ＩＭＳで用いるユーザＩＤの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各ＩＭＳサービス利用可否の管理、ユーザ移動管理のためのデータベースである。

発信側ＩＭＳ端末２１１は、アクセス・ネットワークを介して発信側Ｐ−ＣＳＣＦ２２１と接続される。発信側Ｐ−ＣＳＣＦ２２１は、同じ発信側のホーム網に属する発信側Ｓ−ＣＳＣＦ２３１と接続される。発信側Ｓ−ＣＳＣＦ２３１は、着信側のホーム網に属する着信側Ｓ−ＣＳＣＦ２３２又は着信側Ｓ−ＣＳＣＦ２３３と接続することができる。本実施形態は、発信側Ｓ−ＣＳＣＦ２３１は、元々、着信側Ｓ−ＣＳＣＦ２３２と接続されていたが、着信側Ｓ−ＣＳＣＦ２３２の障害発生により、当該着信側Ｐ−ＣＳＣＦ２２３との接続が途絶えてしまっているといった状況を想定したものである。着信側Ｓ−ＣＳＣＦ２３２、２３３は、共に同じ着信側のホーム網に属する着信側Ｐ−ＣＳＣＦ２２２と接続することができる。

本実施形態では、発信側Ｓ−ＣＳＣＦ２３１が本発明に係るリクエスト送信制御装置として機能する場合について説明する。また、着信側Ｓ−ＣＳＣＦ２３２と着信側Ｐ−ＣＳＣＦ２２２との接続が、着信側Ｓ−ＣＳＣＦ２３２の障害発生により途絶えている状況を想定する。着信側Ｐ−ＣＳＣＦ２２２は、アクセス・ネットワークを介して着信側ＩＭＳ端末２１２と接続される。

図５は、本発明の第２の実施形態におけるリクエスト処理手順を示すフローチャートである。以下、図５を参照して、本実施形態のＩＰ網内のノードにおけるリクエスト処理手順について説明する。発信側Ｓ−ＣＳＣＦ２３１は、着信側ＩＭＳ端末方向に接続された着信側Ｓ−ＣＳＣＦ２３２、２３３に対し、周期的にＳＩＰのＯＰＴＩＯＮＳリクエストを用いたヘルスチェック信号を送信し、これに対する応答の有無を基に着信側Ｓ−ＣＳＣＦ２３２、２３３の障害の有無を判定する（Ｓ２０１）。

より詳細には、発信側Ｓ−ＣＳＣＦ２３１は、着信側Ｓ−ＣＳＣＦからの応答があった場合には、そのステータスコードの内容により当該応答のあった着信側Ｓ−ＣＳＣＦの障害の有無を判定する。また、発信側Ｓ−ＣＳＣＦ２３１は、着信側Ｓ−ＣＳＣＦから応答がない場合には、ＯＰＴＩＯＮＳリクエストの再送タイムアウトを以て着信側Ｓ−ＣＳＣＦを障害状態とみなす。

なお、本実施形態の場合、発信側Ｓ−ＣＳＣＦ２３１は、着信側Ｓ−ＣＳＣＦ２３２を障害状態と判定し、着信側Ｓ−ＣＳＣＦ２３３を正常状態と判定したものとする。即ち、発信側ＩＭＳ端末２１１から着信側ＩＭＳ端末２１２宛の正常なルートは、着信側Ｓ−ＣＳＣＦ２３２の障害により途絶えてしまっているものとする。そして、発信側Ｓ−ＣＳＣＦ２３１は、このように障害状態の有無を判定した着信側Ｐ−ＣＳＣＦ２３２、２３３の当該状態の内容について情報登録を行う（Ｓ２０２）。

発信側ＩＭＳ端末２１１のユーザが、上記のように、着信側ＩＭＳ端末２１２宛の正常なルートが切断されていることを知らずに、当該発信側ＩＭＳ端末２１１を使用して着信側ＩＭＳ２１２端末宛に発信要求を行ったとする。発信側Ｓ−ＣＳＣＦ２３１は、発信側ＩＭＳ端末２１１から発信された発信要求を、発信側Ｐ−ＣＳＣＦ２２１を経由して受信する（Ｓ２０３）。

発信側Ｓ−ＣＳＣＦ２３１は、本来この発信要求を着信側Ｓ−ＣＳＣＦ２３２を経由して着信側ＩＭＳ端末２１２へ送信しなければならない。しかし、発信側Ｓ−ＣＳＣＦ２３１は、着信側Ｓ−ＣＳＣＦ２３２に障害が発生していると判定しているので、発信側ＩＭＳ端末２１１から着信側ＩＭＳ端末２１２宛の発信要求を送信せずに、一旦保持する（Ｓ２０４）。この時、発信側Ｓ−ＣＳＣＦ２３１は、発信側ＩＭＳ端末２１１がタイムアウトになってしまうのを防止するために、例えば、１００ Ｔｒｙｉｎｇ等の暫定応答を返信する。

次に、発信側Ｓ−ＣＳＣＦ２３１は、優先順位選択方式、ラウンドロビン分散方式、又は比率分散方式等の方法によって、正常状態の着信側Ｓ−ＣＳＣＦを選択し、当該正常状態の着信側Ｓ−ＣＳＣＦを経由して、強制的に着信側ＩＭＳ端末２１２の再登録要求を行う（Ｓ２０５）。本実施形態の場合、発信側Ｓ−ＣＳＣＦ２３１は、着信側Ｓ−ＣＳＣＦ２３３を正常状態の着信側Ｓ−ＣＳＣＦとして選択するものとする。

着信側Ｓ−ＣＳＣＦ２３３は、着信側Ｓ−ＣＳＣＦ２３２から再登録要求を受信すると、ＨＳＳ２４１から着信側ＩＭＳ端末２１２の加入者プロファイルをダウンロードする。そして、着信側Ｓ−ＣＳＣＦ２３３は、ダウンロードした着信側ＩＭＳ端末２１２の加入者プロファイルに登録されているＩＰアドレスかＳＩＰ−ＵＲＩを用いて、着信側ＩＭＳ端末２１２に対し、１ｓｔ−ＲＥＧＩＳＴＥＲ実施命令を行う（Ｓ２０６）。着信側ＩＭＳ端末２１２は、着信側Ｓ−ＣＳＣＦ２３３からの１ｓｔ−ＲＥＧＩＳＴＥＲ実施命令を受けて、着信側Ｐ−ＣＳＣＦ２２２経由で１ｓｔ−ＲＥＧＩＳＴＥＲを実施し、再登録される（Ｓ２０７）。

発信側Ｓ−ＣＳＣＦ２３１は、着信側ＩＭＳ端末２１２が再登録されると、保持していた発信側ＩＭＳ端末２１１から着信側ＩＭＳ端末２１２宛の発信要求を、着信側Ｓ−ＣＳＣＦ２３３経由で着信側ＩＭＳ端末２１２へ送信し、セッションを確立する（Ｓ２０８）。しかし、発信側Ｓ−ＣＳＣＦ２３１は、正常状態の着信側Ｐ−ＣＳＣＦが存在しない等の理由があり、再登録要求を行ってから所定時間経過してもセッションが確立できない場合には、発信側ＩＭＳ端末２１１に対し、サーバ・タイムアウト・レスポンスを返信する。

このように、本実施形態においても、発信側Ｓ−ＣＳＣＦ２３１が、従来の方法にないＣＳＣＦ機能を発揮することによって、発信側ＩＭＳ端末２１１、及び着信側ＩＭＳ端末２１２に何ら影響を与えることなくセッションを確立することができる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれることが、特許請求の範囲の記載から明らかである。

例えば、上記の各ＣＳＣＦは、内部にコンピュータシステムを有している。そして、上記の各ＣＳＣＦにおける処理の過程は、プログラムの形式でコンピュータ読み取り可能な電子媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な電子媒体とは、磁気テープ、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ等をいう。また、このプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしてもよい。

１００ リクエスト送信システム
１１１ 発信側ＩＭＳ端末
１１２ 着信側ＩＭＳ端末
１２１ 発信側Ｐ−ＣＳＣＦ
１２２ 着信側Ｐ−ＣＳＣＦ
１２３ 着信側Ｐ−ＣＳＣＦ
１３１ 発信側Ｓ−ＣＳＣＦ
１３２ 着信側Ｓ−ＣＳＣＦ
１４１ ＨＳＳ
２００ リクエスト送信システム
２１１ 発信側ＩＭＳ端末
２１２ 着信側ＩＭＳ端末
２２１ 発信側Ｐ−ＣＳＣＦ
２２２ 着信側Ｐ−ＣＳＣＦ
２３１ 発信側Ｓ−ＣＳＣＦ
２３２ 着信側Ｓ−ＣＳＣＦ
２３３ 着信側Ｓ−ＣＳＣＦ
２４１ ＨＳＳ

Claims (7)

1. ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置であって、
   前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、
   前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、
   前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部と
   を備えるリクエスト送信制御装置。
2. 前記判定部が前記障害状態の下流ノード以外の正常状態の下流ノードを確認した場合、
   当該正常状態の下流ノードを経由して、前記着信側端末へＩＰ網への再登録を要求する再登録要求部
   をさらに備える請求項１に記載のリクエスト送信制御装置。
3. 前記着信側端末がＩＰ網に再登録された場合、
   前記受信部が受信した前記リクエストを、前記正常状態の下流ノードを介して前記着信側端末宛に送信する送信部
   をさらに備える請求項２に記載のＩＰ網内のノードにおけるリクエスト送信制御装置。
4. 前記再登録要求部が前記着信側端末へＩＰ網への再登録を要求してから、所定時間内にセッションが確立されない場合、
   前記返信部は、前記発信側端末に対し、サーバ・タイムアウト・レスポンスを返信する
   請求項３に記載のＩＰ網内のノードにおけるリクエスト送信制御装置。
5. ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御方法であって、
   前記発信側端末から前記着信側端末宛のリクエストを受信する受信ステップと、
   前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定ステップと、
   前記判定ステップにおいて前記下流ノードが障害状況であると判定された場合、前記受信ステップにおいて受信された前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信ステップと
   を備えるリクエスト送信制御方法。
6. ＩＰ網においてリクエストを発信する発信側端末と、
   前記発信側端末からのリクエストを着信する着信側端末と、
   前記ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置と
   を備えるシステムであって、
   前記リクエスト送信制御装置は、
   前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、
   前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、
   前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部と
   を有するシステム。
7. ＩＰ網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置用のプログラムであって、前記リクエスト送信制御装置を、
   前記発信側端末から前記着信側端末宛のリクエストを受信する受信部、
   前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部、
   前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部
   として機能させるプログラム。

Images