(57)【要約】      （修正有）【課題】ＳＩＰサーバに掛かる処理そのものを下げることで、輻輳時にもより繋がり易い通信ネットワークを構成するＳＩＰサーバを提供する。【解決手段】ＳＩＰサーバは、ＳＩＰ通信ネットワークが輻輳状態である非常モード及びそれ以外の状態である通常モードに対応するＳＩＰ通信モード管理データを、保守通信ネットワークを介して入力される保守指示信号に基づき、管理するＳＩＰ通信モード管理部と、ＳＩＰを用いた呼制御を行ない、ＳＩＰメッセージのＩＮＶＩＴＥリクエストが入力され、ＳＩＰ通信モード管理データに基づき、非常モードであるか否かを判定するＳＩＰ呼制御部と、ＳＩＰ呼制御部が非常モードであると判定した場合に、ＳＩＰ呼制御部から入力されるＩＮＶＩＴＥリクエストのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダに自サーバを示す情報を設定しないと共に、既に設定されている前記ヘッダのヘッダ値を削除するＳＩＰヘッダ制御部と、を備えている。【選択図】図１
2009044325.tif 000002
【特許請求の範囲】
【請求項１】
複数の中継サーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルを使用するＳＩＰ通信ネットワークを構成するＳＩＰサーバにおいて、
前記ＳＩＰ通信ネットワークの通信状態が輻輳状態である非常モード及びそれ以外の状態である通常モードにそれぞれ対応するＳＩＰ通信モード管理データを、前記ＳＩＰ通信ネットワークと異なるネットワークである保守通信ネットワークを介して入力される保守指示信号に基づき、当該通常モードから非常モードに切り替えて、前記ＳＩＰ通信モード管理データを管理するＳＩＰ通信モード管理部と、
前記ＳＩＰを用いた呼制御を行ない、ＳＩＰメッセージのＩＮＶＩＴＥリクエストが入力され、当該ＩＮＶＩＴＥリクエスト及び前記ＳＩＰ通信モード管理データに基づき、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定するＳＩＰ呼制御部と、
前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰ呼制御部から入力されるＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、既に設定されているRecord-Routeヘッダのヘッダ値を削除するＳＩＰヘッダ制御部と、
を備えていることを特徴とするＳＩＰサーバ。
【請求項２】
前記請求項１に記載のＳＩＰサーバにおいて、
発端末及び着端末間における通話品質及び通話可能時間を当該発端末又は着端末が任意に指定できる前記通常モード並びに通話品質及び通話可能時間を保守指示信号により指定される前記非常モードにそれぞれ対応するＳＩＰ通信モード管理データを記憶するＳＩＰ通信モード管理データ格納部を備え、
前記ＳＩＰ通信モード管理部は、前記保守指示信号に基づき、前記通常モードから非常モードに切り替えて、前記非常モードにおけるＳＩＰ通信モード管理データを前記ＳＩＰ通信モード管理データ格納部に設定し、
前記ＳＩＰ呼制御部は、前記ＩＮＶＩＴＥリクエストに基づき、前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部に記憶されたＳＩＰ通信モード管理データを読み出し、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定することを特徴とするＳＩＰサーバ。
【請求項３】
前記請求項１又は２に記載のＳＩＰサーバにおいて、
前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに発端末を設定すると共に、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンス及び前記セッション管理データの動作モードに基づき当該動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定することを特徴とするＳＩＰサーバ。
【請求項４】
前記請求項３に記載のＳＩＰサーバにおいて、
前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、
前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスに基づき前記セッション管理データ格納部から読み出す動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定することを特徴とするＳＩＰサーバ。
【請求項５】
前記請求項３又は４に記載のＳＩＰサーバにおいて、
前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシュ時間値に前記通話可能時間を設定することを特徴とするＳＩＰサーバ。
【請求項６】
前記請求項１乃至５のいずれかに記載のＳＩＰサーバにおいて、
所定のセッションタイマの経過後に当該セッションタイマの満了を前記ＳＩＰ呼制御部に通知するＳＩＰタイマ制御部を備え、
前記ＳＩＰ呼制御部は、前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰタイマ制御部に所定のセションタイマを設定すると共に、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッションのリソースを開放することを特徴とするＳＩＰサーバ。
【請求項７】
前記請求項６に記載のＳＩＰサーバにおいて、
前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、
前記ＳＩＰ呼制御部は、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッション管理データ格納部に記憶された前記セッションのリソースを開放することを特徴とするＳＩＰサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のサーバで構成されるＩＰ（Internet Protocol）ネットワーク上で、マルチメディアセッションを開始／変更／終了するためのプロトコルとしてセッション開始プロトコル（Session Initiation Protocol：以下、ＳＩＰと称す）を使用する通信ネットワーク（ＳＩＰ通信ネットワーク）を構成するＳＩＰサーバに関するものである。
【背景技術】
【０００２】
ＳＩＰを用いた通信ネットワークにおいて、ＳＩＰサーバがセッション通信中状態を確立すると、セッション確立以降におけるＳＩＰメッセージのリクエスト・メッセージ及びレスポンス・メッセージの送信経路は、ＳＩＰを規定するＲＦＣ３２６１に基づいたルートセットの概念を用いて特定される。
【０００３】
このルートセットは、ＩＮＶＩＴＥリクエスト及びＩＮＶＩＴＥリクエストに対するレスポンス・メッセージのヘッダ情報に含まれるRecord-Routeヘッダ及びContactヘッダに基づいて生成される。
【０００４】
例えば、図８及び図９に示すように、ＩＮＶＩＴＥリクエストが、発信側の端末（以下、ＵＡＣ（User Agent Client）と称す）から、着信側の端末（以下、ＵＡＳ（User Agent Server）と称す）までの間に、ＳＩＰサーバＢ、ＳＩＰサーバＭ及びＳＩＰサーバＹを順に経由した経路（ＳＩＰサーバＢ→ＳＩＰサーバＭ→ＳＩＰサーバＹ）を辿り、送信経路が確立されたとする。
【０００５】
この場合に、セッション確立以降のリクエスト・メッセージ、例えば、ＵＡＳからＵＡＣに対する「セッションを終了」を意味するリクエスト・メッセージであるＢＹＥリクエストは、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダ及びContactヘッダに基づき、逆順の経路（ＵＡＳ→ＳＩＰサーバＹ→ＳＩＰサーバＭ→ＳＩＰサーバＢ→ＵＡＣ）を選択して送信される。図８はＳＩＰサーバの概念を説明するための説明図であり、図９はＳＩＰによるメッセージの送信経路設定を説明するための説明図である。なお、図９において、ＳＩＰヘッダ名である、Request-URIヘッダはRURI、Record-RouteヘッダはRR、ContactヘッダはC、RouteヘッダはRとして、それぞれ略称で示している。
【０００６】
このような信号ルーティング方式は、ネットワーク提供者が意図した経路を必ず通過するものである。これは、エンドユーザ（ＵＡＣ及びＵＡＳ）間の通信が、所定のサーバを経由せずに直接やり取りすることで、ネットワーク提供者による従量制課金ができないことや、通信時間を無制限に行なえる可能性があることから、ネットワーク提供者はこのようなＳＩＰ通信ネットワークを構築するのが一般的である。
【０００７】
また、ネットワーク提供者は、このようなＳＩＰ通信ネットワークの形態のもとで、例えば、激震災害時等のように、ＳＩＰサーバが輻輳する可能性がある場合に備え、輻輳制御メカニズムをＳＩＰサーバに持たせている。
【０００８】
この輻輳制御メカニズムは、ＳＩＰメッセージによる通信開始（ＩＮＶＩＴＥリクエスト）があることを単位時間内でカウントし、単位時間内でＩＮＶＩＴＥリクエストを受信せずに閾値越えとなった場合や、ＳＩＰサーバのリソース使用量、例えば、ＣＰＵの使用率を観測して閾値越えの場合には、ＩＮＶＩＴＥリクエストを一時的に拒否又は廃棄する方式が広く採用されている。
【０００９】
また、ＳＩＰには、既知の技術として、ＲＦＣで規定されたリダイレクトという方式がある。この方式は、ＵＡＳの位置情報のみをＵＡＣに提供し、セッション確立以降は、エンドユーザ間で直接通信させることで、ＳＩＰサーバにおける処理負荷を抑制することができるメカニズムが存在する。
【００１０】
なお、ＵＡＣを操作する発信者とＵＡＳを操作する着信者との意思により制限なく高品質な通信コーデックを用いた通信が行なわれることを制限する従来技術として、セッション制御信号を中継する信号中継サーバであって、ＩＮＶＩＴＥ信号をパーソナルコンピュータから受信する信号受信部と、ＩＮＶＩＴＥ信号中のＳＤＰメッセージからユーザデータのプロトコルの候補を示すプロトコル情報を抽出する情報抽出部と、ネットワークの混雑状態に応じてプロトコル情報の中から所定の帯域幅以上のものを選択し、選択されたプロトコル情報をＩＮＶＩＴＥ信号中のＳＤＰメッセージから削除するよう編集する信号編集部と、ＩＮＶＩＴＥ信号をパーソナルコンピュータに送信する送信部とを備える信号中継サーバがある（特許文献１参照）。
【特許文献１】特開２００５−３２８２９１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、前述したＩＮＶＩＴＥリクエストを一時的に拒否又は破棄する方式は、通信の開始から終了までに掛かるＳＩＰサーバに対する負荷を予測し、予め閾値を定めておくことで、閾値超えの場合に、通信そのものを実施させない方式であり、ＳＩＰサーバに対する負荷が高まったときに、一回線の通信に掛かる処理負荷を下げる効果はない。このため、輻輳時には人間の習性としての再通信を試みるという事象に対しては、再度の輻輳機能による通信規制のためのメカニズムを動作させることとなり、時として輻輳規制そのものでＳＩＰサーバのリソースを食い潰してしまい、ますます繋がり難くなるというスパイラルに陥ってしまう事象が発生し得るという問題点があった。
【００１２】
つまり、このような場合には、通信をできるだけ可能とする動的なＳＩＰサーバの負荷低減方式である、通信が可能なＳＩＰサーバ数を増やし、再通信の要求による輻輳制御に伴うスパイラルを防止することが必要である。しかしながら、前述したように、エンドユーザ間の通信においては、全サーバを必ず経由する送信経路を満たすようなルーティングを動作させるために、通信中及び終話時に掛かるＳＩＰサーバに対する負荷が、最低限として通話が出来ればよいというレベル以上に掛かることを想定せざるを得ないという問題点があった。
【００１３】
また、前述したリダイレクトは、発信者と着信者との意思により制限なく高品質な通信コーデックを用いた通信が可能となってしまう。このため、有限の回線に対して、少数の端末によって通話時間を無制限に使用されてしまい、回線使用者以外の多数のエンドユーザに対して通信を行なわせることができないという問題点があった。
【００１４】
特に、激震災害時などの被災者の安否を確認するような、多数のエンドユーザに対してより多くの回数の通信を行わせる必要がある場合には、安否確認に最低限で必要なコーデックである低品質及び短時間で通信を意図的に終わらせるメカニズムが必要であり、リダイレクトは、このようなメカニズムを構成しないという問題点があった。
【００１５】
また、エンドユーザの端末に通話規制信号を通知し、端末そのものに規制をさせるメカニズムも考え得るが、エンドユーザが既に所有する端末に新たな機能を埋め込む必要があり現実的ではないという問題点があった。
【００１６】
さらに、専用の携帯電話を端末にして電子メールの送受信や情報の閲覧などを可能にするサービスを用いた通信などのように、電話とは異なるメカニズムによる伝言形式でのやり取りは、公知の製品群で受容が可能であるが、一般の電話利用者は、災害時こそ、音声や画像による被災者の安否の確認を求めている。特に、電話を掛ける以外の端末の操作に不慣れな人や高齢者は、端末を容易に操作できるものではないという問題点があった。
【００１７】
この発明は、上述のような課題を解決するためになされたものであり、ＳＩＰサーバに掛かる処理そのものを下げることで、激震災害などを契機として発生し得るＳＩＰサーバの処理輻輳を極力防止し、できるだけ通信を確立させる可能性を上げることにより通信輻輳を低減し、輻輳時にもより繋がり易い通信ネットワークを構成するＳＩＰサーバを提供することを目的とする。
【課題を解決するための手段】
【００１８】
この発明に係るＳＩＰサーバにおいては、複数の中継サーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルを使用するＳＩＰ通信ネットワークを構成するＳＩＰサーバにおいて、前記ＳＩＰ通信ネットワークの通信状態が輻輳状態である非常モード及びそれ以外の状態である通常モードにそれぞれ対応するＳＩＰ通信モード管理データを、前記ＳＩＰ通信ネットワークと異なるネットワークである保守通信ネットワークを介して入力される保守指示信号に基づき、当該通常モードから非常モードに切り替えて、前記ＳＩＰ通信モード管理データを管理するＳＩＰ通信モード管理部と、前記ＳＩＰを用いた呼制御を行ない、ＳＩＰメッセージのＩＮＶＩＴＥリクエストが入力され、当該ＩＮＶＩＴＥリクエスト及び前記ＳＩＰ通信モード管理データに基づき、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定するＳＩＰ呼制御部と、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰ呼制御部から入力されるＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、既に設定されているRecord-Routeヘッダのヘッダ値を削除するＳＩＰヘッダ制御部と、を備えているものである。
【００１９】
この発明に係るＳＩＰサーバにおいては、必要に応じて、発端末及び着端末間における通話品質及び通話可能時間を当該発端末又は着端末が任意に指定できる前記通常モード並びに通話品質及び通話可能時間を保守指示信号により指定される前記非常モードにそれぞれ対応するＳＩＰ通信モード管理データを記憶するＳＩＰ通信モード管理データ格納部を備え、前記ＳＩＰ通信モード管理部は、前記保守指示信号に基づき、前記通常モードから非常モードに切り替えて、前記非常モードにおけるＳＩＰ通信モード管理データを前記ＳＩＰ通信モード管理データ格納部に設定し、前記ＳＩＰ呼制御部は、前記ＩＮＶＩＴＥリクエストに基づき、前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部に記憶されたＳＩＰ通信モード管理データを読み出し、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定するものである。
【００２０】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに発端末を設定すると共に、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンス及び前記セッション管理データの動作モードに基づき当該動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定するものである。
【００２１】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスに基づき前記セッション管理データ格納部から読み出す動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定するものである。
【００２２】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシュ時間値に前記通話可能時間を設定するものである。
【００２３】
この発明に係るＳＩＰサーバにおいては、必要に応じて、所定のセッションタイマの経過後に当該セッションタイマの満了を前記ＳＩＰ呼制御部に通知するＳＩＰタイマ制御部を備え、前記ＳＩＰ呼制御部は、前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰタイマ制御部に所定のセションタイマを設定すると共に、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッションのリソースを開放するものである。
【００２４】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、前記ＳＩＰ呼制御部は、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッション管理データ格納部に記憶された前記セッションのリソースを開放するものである。
【発明の効果】
【００２５】
この発明に係るＳＩＰサーバにおいては、複数の中継サーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルを使用するＳＩＰ通信ネットワークを構成するＳＩＰサーバにおいて、前記ＳＩＰ通信ネットワークの通信状態が輻輳状態である非常モード及びそれ以外の状態である通常モードにそれぞれ対応するＳＩＰ通信モード管理データを、前記ＳＩＰ通信ネットワークと異なるネットワークである保守通信ネットワークを介して入力される保守指示信号に基づき、当該通常モードから非常モードに切り替えて、前記ＳＩＰ通信モード管理データを管理するＳＩＰ通信モード管理部と、前記ＳＩＰを用いた呼制御を行ない、ＳＩＰメッセージのＩＮＶＩＴＥリクエストが入力され、当該ＩＮＶＩＴＥリクエスト及び前記ＳＩＰ通信モード管理データに基づき、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定するＳＩＰ呼制御部と、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰ呼制御部から入力されるＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、既に設定されているRecord-Routeヘッダのヘッダ値を削除するＳＩＰヘッダ制御部と、を備えていることにより、ＳＩＰサーバがネットワークオペレータによる保守指示信号を受信した後における、新規のセッション通信の要求に対して、ネットワーク提供者のＳＩＰサーバを経由することなく、直接、発端末及び着端末間において当該セッション通信を継続させることができ、ＳＩＰサーバに掛かる負荷を抑制することができる。
【００２６】
この発明に係るＳＩＰサーバにおいては、必要に応じて、発端末及び着端末間における通話品質及び通話可能時間を当該発端末又は着端末が任意に指定できる前記通常モード並びに通話品質及び通話可能時間を保守指示信号により指定される前記非常モードにそれぞれ対応するＳＩＰ通信モード管理データを記憶するＳＩＰ通信モード管理データ格納部を備え、前記ＳＩＰ通信モード管理部は、前記保守指示信号に基づき、前記通常モードから非常モードに切り替えて、前記非常モードにおけるＳＩＰ通信モード管理データを前記ＳＩＰ通信モード管理データ格納部に設定し、前記ＳＩＰ呼制御部は、前記ＩＮＶＩＴＥリクエストに基づき、前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部に記憶されたＳＩＰ通信モード管理データを読み出し、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定することにより、ＳＩＰ通信ネットワークの通信状態が輻輳状態の場合に、保守通信ネットワークを介して、常時、保守指示信号を入力する必要がなく、ＳＩＰサーバ内に記憶したＳＩＰ通信モード管理データを読み出して判定することができる。
【００２７】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに発端末を設定すると共に、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンス及び前記セッション管理データの動作モードに基づき当該動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定することにより、発端末及び着端末間においてセッションリフレッシュがなされず、発端末及び着端末は、セッションリフレッシュ時間が完了した時点で接続が異常と判断し、自律で切断処理を行ない、エンドユーザによる通話時間を制限することができる。
【００２８】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスに基づき前記セッション管理データ格納部から読み出す動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定することにより、ＳＩＰ通信ネットワークの通信状態が輻輳状態の場合に、保守通信ネットワークを介して、常時、保守指示信号を入力する必要がなく、ＳＩＰサーバ内に記憶した動作モードを読み出して判定することができる。
【００２９】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシュ時間値に前記通話可能時間を設定することにより、ネットワーク提供者が意図した時間内でセッション通信を終了させることができ、エンドユーザによる通話時間を制限することができる。
【００３０】
この発明に係るＳＩＰサーバにおいては、必要に応じて、所定のセッションタイマの経過後に当該セッションタイマの満了を前記ＳＩＰ呼制御部に通知するＳＩＰタイマ制御部を備え、前記ＳＩＰ呼制御部は、前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰタイマ制御部に所定のセションタイマを設定すると共に、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッションのリソースを開放することにより、スキップされた当該セッションに関してＳＩＰサーバが用いていたリソースを、無効又は保留することなく、速やかに開放することができ、新規のセッション通信の要求に対して、当該ＳＩＰサーバを使用することができる。
【００３１】
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、前記ＳＩＰ呼制御部は、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッション管理データ格納部に記憶された前記セッションのリソースを開放することにより、ＳＩＰ通信ネットワークの通信状態が輻輳状態の場合に、保守通信ネットワークを介して、常時、保守指示信号を入力する必要がなく、ＳＩＰサーバ内に記憶した動作モードを読み出して判定することができる。
【発明を実施するための最良の形態】
【００３２】
（本発明の第１の実施形態）
図１はこの第１の実施形態に係るＳＩＰサーバの概略構成を示す機能ブロック図、図２は図１に示すＳＩＰサーバを用いたＳＩＰによるメッセージの送信経路設定の一例を示すシーケンス図、図３は図１に示すＳＩＰサーバが保守指示信号を受信した場合における処理手順の一例を示すシーケンス図、図４は図１に示すＳＩＰサーバがＩＮＶＩＴＥリクエストを受信した場合における処理手順の一例を示すシーケンス図、図５は図１に示すＳＩＰサーバがＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスを受信した場合における処理手順の一例を示すシーケンス図、図６はこの第１の実施形態に係るＳＩＰサーバが保守指示信号を受信した場合におけるＳＩＰサーバの処理手順の他の例を示すシーケンス図、図７はこの第１の実施形態に係るＳＩＰサーバが保守指示信号を受信した場合におけるＳＩＰサーバの処理手順のさらに他の例を示すシーケンス図である。
【００３３】
この第１の実施形態に係るＳＩＰサーバの構成について図１を用いて説明する。ＳＩＰサーバ１０は、代表的な機能として呼処理を制御する機能と通信を制御する機能とから構成される呼処理の交換を行なうためのシステムとしてのソフトスイッチである。図１に示すように、ＳＩＰサーバ１０は、ＳＩＰ通信モード管理データ格納部１と、ＳＩＰ通信モード管理部２と、ＳＩＰ通信制御部３と、ＳＩＰ呼制御部４と、ＳＩＰヘッダ制御部５と、セッション管理データ格納部６と、ＳＩＰタイマ制御部７とを備える。なお、図１に示すＳＩＰサーバ１０の構成は、本発明に直接的に関係のない構成部位については省略しており、保守管理機能などの様々な機能を有する構成部位を備えてもよい。
【００３４】
ＳＩＰ通信モード管理データ格納部１は、ＳＩＰ通信ネットワーク１００の通信状態が輻輳状態であり、通話品質及び通話可能時間を保守指示信号により指定される通話モード（以下、非常モードと称す）、並びに、輻輳状態以外の状態であり、ＵＡＣ及びＵＡＳ間における通話品質及び通話可能時間をＵＡＣ又はＵＡＳが任意に指定できる通話モード（以下、通常モードと称す）にそれぞれ対応するＳＩＰ通信モード管理データを記憶する。ここで、保守指示信号とは、ＳＩＰ通信ネットワーク１００における輻輳状態に対応して、ＳＩＰ通信ネットワーク１００と異なるネットワークである保守通信ネットワーク２００を介して入力され、ＵＡＣ及びＵＡＳ間における通話品質及び通話可能時間を制限する有限値に設定する信号である。なお、非常モードにおけるＳＩＰ通信モード管理データとしては、激震災害時などの被災者の安否を確認するような、多数のエンドユーザに対してより多くの回数の通信を行なわせる必要がある場合に、安否確認に最低限で必要なコーデックである低品質及び短時間で通信を意図的に終わらせるように、通話品質及び通話可能時間を設定すればよく、例えば、通話品質を「最低音声のみ」とし、通話可能時間を「９０秒」とする設定にすることが考えられる。
【００３５】
ＳＩＰ通信モード管理部２は、通常モードにおけるＳＩＰ通信モード管理データ及び非常モードにおけるＳＩＰ通信モード管理データを管理する処理部である。このＳＩＰ通信モード管理部２は、保守通信ネットワーク２００を介して入力される保守指示信号を受信した場合に、通常モードから非常モードに切り替えて、非常モードにおけるＳＩＰ通信モード管理データをＳＩＰ通信モード管理データ格納部１に設定する。また、ＳＩＰ通信モード管理部２は、後述するＳＩＰ呼制御部４から通話モードを確認するための問い合わせを受け付けた場合には、ＳＩＰ通信モード管理データ格納部１からＳＩＰ通信モード管理データを読み出し、読み出した結果をＳＩＰ呼制御部４に対して通知する。
【００３６】
ＳＩＰ通信制御部３は、ＳＩＰに準拠したＳＩＰメッセージの送受信を制御する処理部である。例えば、このＳＩＰ通信制御部３は、ＩＮＶＩＴＥリクエスト、ＢＹＥリクエスト又はｒｅ−ＩＮＶＩＴＥリクエストなどのリクエスト・メッセージや、「200 OK」又は「100 Trying」などの応答コードが設定されたレスポンス・メッセージを、ＳＩＰ通信ネットワーク１００における、自サーバに接続されているＳＩＰサーバ（以下、「対向サーバ」と称す）との間で送受信する。
【００３７】
ＳＩＰ呼制御部４は、ＳＩＰを用いた呼制御を行なう処理部である。このＳＩＰ呼制御部４は、本発明に関連する機能としては、ＳＩＰ通信制御部３を介して入力されるＳＩＰメッセージのＩＮＶＩＴＥリクエストを受信すると、ＳＩＰ通信モード管理データ格納部１に記憶されたＳＩＰ通信モード管理データをＳＩＰ通信モード管理部２に問い合わせる。そして、ＳＩＰ呼制御部４は、ＳＩＰ通信モード管理部２を介してＳＩＰ通信モード管理データ格納部１から読み出したＳＩＰ通信モード管理データが非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定する。そして、非常モードにおけるＳＩＰ通信モード管理データであると判定した場合には、後述するＳＩＰヘッダ制御部５に指示することによって、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、ＩＮＶＩＴＥリクエストのヘッダ情報に既に設定されているRecord-Routeヘッダのヘッダ値を削除し、対向サーバ又はＵＡＳに対して当該ＩＮＶＩＴＥリクエストを送信する。
【００３８】
また、ＳＩＰ呼制御部４は、非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、後述するＳＩＰタイマ制御部７に所定のセションタイマを設定すると共に、ＳＩＰタイマ制御部７からのセッションタイマの満了の通知に基づき、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を対向サーバ、ＵＡＣ又はＵＡＳに対して送信することなく、後述するセッション管理データ格納部６に記憶された当該セッションのリソースを開放する。
【００３９】
ＳＩＰヘッダ制御部５は、ＳＩＰ呼制御部４からの指示に基づいて、ＳＩＰメッセージのヘッダの生成や削除などの編集を行なうＳＩＰに対応したヘッダ制御を行なう処理部である。このＳＩＰヘッダ制御部５は、本発明に関連する機能としては、ＳＩＰ呼制御部４が非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、ＳＩＰ呼制御部４からの指示に基づいて、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、ＩＮＶＩＴＥリクエストのヘッダ情報に設定されているRecord-Routeヘッダのヘッダ値を削除する。
【００４０】
また、ＳＩＰヘッダ制御部５は、ＳＩＰ呼制御部４が非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシャー指示パラメタにＵＡＣを設定する。また、ＳＩＰヘッダ制御部５は、ＳＩＰ呼制御部４が非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシュ時間値に通話可能時間を設定する。
【００４１】
また、ＳＩＰヘッダ制御部５は、ＳＩＰ呼制御部４がＳＩＰ通信制御部３を介して入力されるＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスに基づき後述するセッション管理データ格納部６から読み出す動作モードが非常モードであると判定した場合に、当該２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタにＵＡＳを設定する。
【００４２】
セッション管理データ格納部６は、ＳＩＰ呼制御部４がＳＩＰ通信モード管理部２を介してＳＩＰ通信モード管理データ格納部１から読み出したＳＩＰ通信モード管理データのうち、非常モード又は通常モードを示す動作モードを記憶する。
【００４３】
ＳＩＰタイマ制御部７は、ＳＩＰによるセッションリフレッシュのタイミングを指示する機能を提供する、ＳＩＰサーバとして既存の構成部位であり、所定のセッションタイマの経過後に当該セッションタイマの満了をＳＩＰ呼制御部４に通知する。
【００４４】
次に、この第１の実施形態に係るＳＩＰサーバの処理手順及びＳＩＰによるメッセージの送信経路設定について説明する。図２は図８に示したＳＩＰサーバＢ、ＳＩＰサーバＭ及びＳＩＰサーバＹにおいて行われる送信経路設定を示している。
【００４５】
ここで、ＳＩＰサーバＹは、図３に示すように、通常、通話品質及び通話可能時間を「任意」とする通常モードにおけるＳＩＰ通信モード管理データがＳＩＰ通信モード管理データ格納部６に記憶されている。
【００４６】
まず、ＳＩＰサーバＹでは、ＳＩＰ通信モード管理部２が、保守通信ネットワーク２００を介して保守指示信号を受信し（ステップＳ１）、ＳＩＰ通信モード管理データ格納部１に指示内容を設定する（ステップＳ２）。すなわち、保守指示信号に基づき、ＳＩＰ通信モード管理データ格納部１に格納した通常モードにおけるＳＩＰ通信モード管理データを、非常モードにおけるＳＩＰ通信モード管理データに切り替える。なお、この第１の実施形態においては、非常モードにおけるＳＩＰ通信モード管理データとして、通話品質を「最低音声のみ」とし、通話可能時間を「９０秒」としている。
【００４７】
各ＳＩＰサーバは、ＵＡＣ若しくはＵＡＳ又は他のＳＩＰサーバからＳＩＰメッセージを受信すると、その度に次の送信先を特定して、当該ＳＩＰメッセージを転送する。この送信先の特定は、セッション通信の開始時にＵＡＣ及びＵＡＳにおいて生成されるルートセットに基づいて行われる。このルートセットは、ＩＮＶＩＴＥリクエスト及びＩＮＶＩＴＥリクエストに対するレスポンス・メッセージのヘッダ情報に含まれるRecord-Routeヘッダ及びContactヘッダに基づいて生成される。
【００４８】
ここで、Record-Routeヘッダは、ＩＮＶＩＴＥリクエストの送信経路が設定されるヘッダであり、具体的には、ＩＮＶＩＴＥリクエストの送信経路において経由されたＳＩＰサーバを示す情報が順番に設定される。Contactヘッダは、ＩＮＶＩＴＥリクエストやレスポンス・メッセージを送信した送信元の端末を示す情報が設定されるヘッダである。
【００４９】
例えば、図２に示すように、ＵＡＳに対するＩＮＶＩＴＥリクエストがＵＡＣから発信され（ステップＳ１０１）、ＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹの順に転送されて、ＵＡＳに到達したとする（ステップＳ１０２〜Ｓ１０４）。このＩＮＶＩＴＥリクエストのRecord-Routeヘッダには、通常、図９に示すように、それまでに経由したＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹを示す情報が順番に設定され（「ＲＲ：Ｙ，Ｍ，Ｂ」）、Contactヘッダには、ＩＮＶＩＴＥリクエストの送信元であるＵＡＣを示す情報が設定される（「Ｃ：ＵＡＣ」）。しかしながら、この第１の実施形態においては、ＳＩＰサーバＹによって、それまでに経由したＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹを示す情報が全て削除され（図３に示す「ＲＲ：−」）、Contactヘッダには、ＩＮＶＩＴＥリクエストの送信元であるＵＡＣを示す情報が設定される（「Ｃ：ＵＡＣ」）。
すなわち、ＳＩＰサーバＹでは、ＩＮＶＩＴＥリクエストを受信する（ステップＳ１０３）と、図４に示すように、以下のような処理が行なわれる。
【００５０】
まず、ＳＩＰ通信制御部３がＩＮＶＩＴＥリクエストを受信し（ステップＳ３）、ＳＩＰ呼制御部４に送信する（ステップＳ４）。なお、ＩＮＶＩＴＥリクエストには、Record-RouteヘッダにＩＮＶＩＴＥリクエストが経由した「ＳＩＰサーバＢ」及び「ＳＩＰサーバＭ」を示す情報、ContactヘッダにＩＮＶＩＴＥリクエストの送信元である「ＵＡＣ」を示す情報、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に「１８０秒」を示す情報、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に「ＵＡＳ」を示す情報、ＳＤＰ（Session Description Protocol）における通信メディアに「最高音声と画像」を示す情報が設定されている。
【００５１】
ここで、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）及びリフレッシャー指示パラメタ（ＲＦ）について説明する。
ＩＥＴＦ（Internet Engineering Task Force）により規定されたＳＩＰの拡張仕様（ＲＦＣ４０２８）には、セッション通信の状態を確認するためのセッションタイマ（Session Timers）機能の仕様が定義されている。このセッションタイマ機能を備えていた場合、ＵＡＣ、ＵＡＳ及びＳＩＰサーバは、セッション通信の開始時（呼設定時）に通信相手の端末（ＵＡＣ，ＵＡＳ）との間で任意の生存時間（セッションタイマ）を決定し、セッション通信中は、常にタイマで時間を計数して、生存時間の半分の時間（リフレッシュタイマ）が過ぎた時点で、通信相手の端末（ＵＡＣ又はＵＡＳ）に対してリフレッシュ用のＩＮＶＩＴＥリクエストであるｒｅ−ＩＮＶＩＴＥリクエスト（セッション生存確認リクエスト）を送信する。
【００５２】
そして、ＵＡＣ、ＵＡＳ及びＳＩＰサーバは、送信したリクエストに対してレスポンスが応答された場合には、その時点では通信が可能であると判定してタイマをリセットし、ｒｅ−ＩＮＶＩＴＥリクエストの送信とレスポンスの有無の確認（リフレッシュ動作）を繰り返し、一方、生存時間が過ぎてもレスポンスが応答されなかった場合には、通信が不可能であると判定してセッション通信を終了する。
【００５３】
このように、通信相手の端末に対してｒｅ−ＩＮＶＩＴＥリクエストを送信する端末（以下、リフレッシャーと称す）を、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）で設定し、ｒｅ−ＩＮＶＩＴＥリクエストを送信するタイミングであるリフレッシュタイマの値を、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）で設定する。
【００５４】
例えば、図６に示すように、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）を「１８０秒」に設定し、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に「ＵＡＳ」に設定したＩＮＶＩＴＥリクエストがＵＡＣから送信された（ステップＳ１０１）とする。
【００５５】
当該ＩＮＶＩＴＥリクエストを受信したＵＡＳは、ＳＥ時間である１８０秒を基に、ＵＡＣに対してリフレッシュを行なうことを認識して、ＩＮＶＩＴＥリクエストに対して２００ＯＫレスポンスを応答する（ステップＳ１０５）。また、当該２００ＯＫレスポンスを受信したＵＡＣは、ＳＥ時間である１８０秒を基に、ＵＡＳからリフレッシュされることを認識して、２００ＯＫレスポンスに対してＡＣＫメッセージを応答する（ステップＳ１０９）。
【００５６】
これにより、セッション通信中は、常にタイマで時間を計数して、生存時間の半分の時間（リフレッシュタイマ）が過ぎた時点で、ＵＡＳは、ＵＡＣに対してｒｅ−ＩＮＶＩＴＥリクエストを送信する（ステップＳ１１３）。そして、ＵＡＣは、ｒｅ−ＩＮＶＩＴＥリクエストに対して２００ＯＫレスポンスを応答し（ステップＳ１１４）、ＵＡＳは、２００ＯＫレスポンスに対してＡＣＫメッセージを応答する（ステップＳ１１５）ことによるインタラクションが成功することを、ＵＡＣ及びＵＡＳで相互に確認しあうことにより、セッション通信の接続維持を確認し、通話を続けることになる。
【００５７】
ＳＩＰ呼制御部４は、ＳＩＰ通信モード管理データ格納部１に記憶されたＳＩＰ通信モード管理データをＳＩＰ通信モード管理部２に問い合わせる（ステップＳ５）。
ＳＩＰ通信モード管理部２は、ＳＩＰ通信モード管理データ格納部６からＳＩＰ通信モード管理データを読出し（ステップＳ６、ステップＳ７）、読出した結果をＳＩＰ呼制御部４に返却する（ステップＳ８）。なお、ここでは、ＳＩＰ通信モード管理データ格納部１には、保守指示信号により非常モードにおけるＳＩＰ通信モード管理データが設定されているために、非常モードにおけるＳＩＰ通信モード管理データとして、動作モードが「非常モード」であり、通話品質を「最低音声のみ」とし、通話可能時間を「９０秒」としたデータがＳＩＰ呼制御部４に返却されることになる。
【００５８】
ＳＩＰ呼制御部４は、返却されたＳＩＰ通信モード管理データの動作モードを判定し、動作モードが非常モードであると判定した場合には、ＳＩＰヘッダ制御部５に指示する（ステップＳ９、ステップＳ１０）。ＳＩＰヘッダ制御部５は、ＳＩＰ呼制御部４の指示に基づき、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、ＩＮＶＩＴＥリクエストのヘッダ情報に設定されているRecord-Routeヘッダのヘッダ値を削除する。また、返却されたＳＩＰ通信モード管理データに基づき、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に「９０秒」を設定し、ＳＤＰにおける通信メディアに「最低音声のみ」を設定する。さらに、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に送信先に対して逆側である「ＵＡＳ」を設定する。なお、ＳＩＰ呼制御部４は、返却されたＳＩＰ通信モード管理データの動作モードを判定し、動作モードが非常モードでない（通常モードである）と判定した場合には、これ以降の処理は従来のＳＩＰサーバと同様の処理を行なうことになる。
【００５９】
そして、ＳＩＰ呼制御部４は、ＳＩＰ通信制御部３を介して（ステップＳ１２）、ＵＡＳに対して編集後のＩＮＶＩＴＥリクエストを送信する（ステップＳ１３）。なお、編集後のＩＮＶＩＴＥリクエストには、Record-Routeヘッダは空白であり、ContactヘッダにＩＮＶＩＴＥリクエストの送信元である「ＵＡＣ」を示す情報、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に「９０秒」を示す情報、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に「ＵＡＣ」を示す情報、ＳＤＰにおける通信メディアに「最低音声のみ」を示す情報が設定されている。また、ステップ１２の前後は問わず、ＳＩＰ呼制御部４は、ＳＩＰ通信モード管理データのうち、「非常モード」又は「通常モード」を示す動作モード（ここでは、「非常モード」となる）をセッション管理データ格納部６に記憶する（ステップ１１）。
【００６０】
ＵＡＳは、ＩＮＶＩＴＥリクエストを受信すると、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダ及びContactヘッダに基づいて、ルートセットを生成して、記憶する（図２に示す「ＵＡＣ」）。また、ＵＡＳは、ＵＡＣをリフレッシャーとし、ＳＥ時間を基にリフレッシュされること（リフレッシュ時間内に、ＵＡＳに対してＵＡＣからｒｅ−ＩＮＶＩＴＥリクエストが送信されること）を認識する。
【００６１】
そして、ＵＡＳは、ＩＮＶＩＴＥリクエストによるセッション開始要求を受け付けたことを示す２００ＯＫレスポンス（応答コード「200 OK」が設定されたレスポンス・メッセージ）をＵＡＣに対して送信する（ステップＳ１０５）。
【００６２】
ＵＡＳにより送信された２００ＯＫレスポンスは、ＩＮＶＩＴＥリクエストが転送された経路を逆にたどり、ＳＩＰサーバＹ、ＳＩＰサーバＭ、ＳＩＰサーバＢの順に転送されて、ＵＡＣに到達する（ステップＳ１０６〜Ｓ１０８）。この２００ＯＫレスポンスのRecord-Routeヘッダには、ＵＡＳにより受信されたＩＮＶＩＴＥリクエストのRecord-Routeヘッダと同じ情報が設定され（図２に示す「ＲＲ：−」）、Contactヘッダには、当該２００ＯＫレスポンスの送信元であるＵＡＳを示す情報が設定されている（図２に示す「Ｃ：ＵＡＳ」）。
【００６３】
ここで、ＳＩＰサーバＹでは、２００ＯＫレスポンスを受信する（ステップＳ１０５）と、図５に示すように、以下のような処理が行なわれる。
【００６４】
まず、ＳＩＰ通信制御部３が２００ＯＫレスポンスを受信し（ステップＳ１４）、ＳＩＰ呼制御部４に送信する（ステップＳ１５）。なお、２００ＯＫレスポンスには、Record-Routeヘッダは空白であり、Contactヘッダに２００ＯＫレスポンスの送信元である「ＵＡＳ」を示す情報、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に「９０秒」を示す情報、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に「ＵＡＣ」を示す情報、ＳＤＰにおける通信メディアに「最低音声のみ」を示す情報が設定されている。そして、ＳＩＰ呼制御部４は、セッション管理データ格納部６に記憶された動作モードを読み出す（ステップＳ１６、ステップＳ１７）。なお、ここでは、セッション管理データ格納部６には、動作モードを「非常モード」として記憶されているために、動作モードを「非常モード」とするデータがＳＩＰ呼制御部４に読み出されることになる。
【００６５】
ＳＩＰ呼制御部４は、読み出した動作モードを判定し、動作モードが非常モードであると判定した場合には、ＳＩＰヘッダ制御部５に指示する（ステップＳ１８、ステップＳ１９）。ＳＩＰヘッダ制御部５は、ＳＩＰ呼制御部４の指示に基づき、２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に送信先に対して逆側である「ＵＡＳ」を設定する。なお、ＳＩＰ呼制御部４は、読み出した動作モードを判定し、動作モードが非常モードでない（通常モードである）と判定した場合には、これ以降の処理は従来のＳＩＰサーバと同様の処理を行なうことになる。
【００６６】
そして、ＳＩＰ呼制御部４は、ＳＩＰ通信制御部３を介して（ステップＳ２０）、ＳＩＰサーバＭに対して編集後の２００ＯＫレスポンスを送信する（ステップＳ２１）。なお、編集後の２００ＯＫレスポンスには、Record-Routeヘッダは空白であり、Contactヘッダに２００ＯＫレスポンスの送信元である「ＵＡＳ」を示す情報、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に「９０秒」を示す情報、Session-Expiresヘッダにおけるリフレッシャー指示パラメタ（ＲＦ）に「ＵＡＳ」を示す情報、ＳＤＰにおける通信メディアに「最低音声のみ」を示す情報が設定されている。
【００６７】
ここで、動作モードが非常モードであるならば、ＳＩＰ呼制御部４は、ＳＩＰサーバ自身のセッションタイマを非常モードとして、予めデータなどで定めた短い時間でＳＩＰサーバ自身のセッションタイマ（ここでは５秒）をＳＩＰタイマ制御部７にセットする（ステップＳ２２）。
【００６８】
そして、５秒経過後に、ＳＩＰタイマ制御部７は、タイマ満了をＳＩＰ呼制御部４に通知する（ステップＳ２３）。
そして、ＳＩＰ呼制御部４は、セッション管理データ格納部６に記憶された動作モードを読み出す（ステップＳ２４、ステップＳ２５）。なお、ここでは、セッション管理データ格納部６には、動作モードを「非常モード」として記憶されているために、動作モードを「非常モード」とするデータがＳＩＰ呼制御部４に読み出されることになる。
【００６９】
ＳＩＰ呼制御部４は、読み出した動作モードを判定し、動作モードが非常モードであると判定した場合には、切断信号を送信することなく、セッション管理データ格納部６に記憶された当該セッションを管理しているリソースの開放処理のみを行なう（ステップＳ２６）。なお、この第１の実施形態においては、セッションタイマを５秒にセットしているが、当該セッションを管理しているリソースの開放処理を行なうことができるのであれば５秒に限られるものではなく、当該セッションを管理しているリソースを速やかに開放することができるように、セッションタイマを短時間にセットすることが好ましい。
【００７０】
ＵＡＣは、２００ＯＫレスポンスを受信すると、当該２００ＯＫレスポンスのRecord-Routeヘッダ及びContactヘッダに基づいて、ルートセットを生成して、記憶する（図２に示す「ＵＡＳ」）。また、ＵＡＣは、ＵＡＳをリフレッシャーとし、ＳＥ時間を基にリフレッシュされること（リフレッシュ時間内に、ＵＡＣに対してＵＡＳからｒｅ−ＩＮＶＩＴＥリクエストが送信されること）を認識する。
【００７１】
そして、ＵＡＣは、ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスを受け付けたことを示すＡＣＫメッセージをＵＡＳに対して送信する（ステップＳ１０９）。ＵＡＣにより送信されたＡＣＫメッセージは、通常、図９に示すように、ＩＮＶＩＴＥリクエストと同じ経路をたどり、ＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹの順に転送されて、ＵＡＳに到達する（ステップＳ１１０〜Ｓ１１２）のであるが、この第１の実施形態においては、図２に示すように、ＵＡＣにより送信されたＡＣＫメッセージは、直接、ＵＡＳに到達する（ステップＳ１０９）。
【００７２】
以上の手続きにより、ＵＡＣとＵＡＳとの間で、セッション通信が開始される（セッション通信中状態）。そして、これ以降、ＵＡＣ又はＵＡＳから送信されるリクエスト・メッセージのヘッダには、それぞれの端末において生成されたルートセットに基づいて送信経路が設定され、この送信経路に基づいて、ＵＡＣ及びＵＡＳは、リクエスト・メッセージの送信先を特定する。
【００７３】
例えば、図７に示すように、セッション通信の終了要求を示すＢＹＥリクエストがＵＡＣからＵＡＳに対して送信される場合には（ステップＳ１１６）、ＵＡＣにおいて、ルートセットに基づいて当該ＢＹＥリクエストのRequest-URIヘッダ及びRouteヘッダが設定される（図７に示す「ＲＵＲＩ：ＵＡＳ」及び「Ｒ：−」）。
【００７４】
ここで、Request-URIヘッダは、リクエスト・メッセージの送信先（リクエストの要求先）を示す情報が設定されるヘッダであり、Routeヘッダは、リクエスト・メッセージを送信する際の送信経路（ＳＩＰサーバの経由順）を示す情報が設定されるヘッダである。
【００７５】
ＵＡＣにより送信されたＢＹＥリクエストは、Request-URIヘッダ及びRouteヘッダに設定された情報に基づいて、直接、ＵＡＳに到達する（ステップＳ１１６）。
【００７６】
同様に、ＵＡＳからＵＡＣに対してＢＹＥリクエストが送信される場合には（ステップＳ１１７）、ＵＡＳにおいて、ルートセットに基づいて当該ＢＹＥリクエストのRequest-URIヘッダ及びRouteヘッダが設定され（図７に示す「ＲＵＲＩ：ＵＡＣ，Ｒ：−」）、このＢＹＥリクエストは、ヘッダ情報に基づいて、直接、ＵＡＣに到達する（ステップＳ１１７）。
【００７７】
このように、ＳＩＰを用いたネットワークでは、ＵＡＣとＵＡＳとの間でセッション通信が開始された以降は、ＵＡＣ又はＵＡＳから送信されるリクエスト・メッセージのRouteヘッダには、それぞれの端末において生成されたルートセットに基づいて送信経路が設定され、この送信経路に基づいて、ＲＦＣに違反することなく、直接、ＵＡＣ及びＵＡＳ間でリクエスト・メッセージのやり取りを行なうことになる。
【００７８】
また、セッションリフレッシュ規定のＲＦＣに従って通話中に遷移したＵＡＣ及びＵＡＳ間においては、セッションリフレッシュがなされず、Session-Expiresヘッダにおけるリフレッシュ時間値である９０秒経過後に、ＵＡＣ及びＵＡＳ側のいずれからもｒｅ−ＩＮＶＩＴＥリクエストが送信されないために、ＵＡＣ及びＵＡＳは、セッションリフレッシュ時間が満了した時点で、接続が異常と判断し、自律的に切断動作を行なうことになる。
【００７９】
また、ＳＩＰサーバ１０は、直接、ＵＡＣ及びＵＡＳ間でセッション通信が行なわれる状態に遷移した場合であっても、ＳＩＰタイマ制御部７にセットしたセッションタイマである５秒経過後に、切断信号を送信することなく、セッション管理データ格納部６に記憶された当該セッションを管理しているリソースを、無効又は保留することなく、速やかに開放し、新規のセッション通信の要求に対して当該ＳＩＰサーバ１０を使用することができることになる。
【００８０】
なお、この第１の実施形態においては、この第１の実施形態に係るＳＩＰサーバ１０をＳＩＰサーバＹにのみ適用した例を示して説明したが、ＵＡＣ及びＵＡＳ間におけるＩＮＶＩＴＥリクエストが経由する複数のＳＩＰサーバ（図２においては、ＳＩＰサーバＢ及びＳＩＰサーバＭ）に、この第１の実施形態に係るＳＩＰサーバ１０を適用してもよい。これにより、それぞれのＳＩＰサーバ１０において、ＳＩＰヘッダ制御部５が、ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しない処理を行なうことにより、セッション確立以降のセッション通信におけるＳＩＰメッセージのリクエスト・メッセージのやり取りを、直接、ＵＡＣ及びＵＡＳ間で行なわせることができる。
【００８１】
また、この第１の実施形態においては、セッション確立以降のセッション通信におけるＳＩＰメッセージのリクエスト・メッセージのやり取りを、直接、ＵＡＣ及びＵＡＳ間で行なわせているために、この第１の実施形態に係るＳＩＰサーバ１０を適用していないＳＩＰサーバ（図２においては、ＳＩＰサーバＢ及びＳＩＰサーバＭ）においては、ＵＡＣ及びＵＡＳ間の当該セッションが終了した場合であっても、当該セッションの管理用のリソースを開放することができず、新規のセッション通信の要求に対して当該ＳＩＰサーバを使用することができない。このため、ＵＡＣ及びＵＡＳ間におけるＩＮＶＩＴＥリクエストが経由する全てのＳＩＰサーバ（図２においては、ＳＩＰサーバＢ及びＳＩＰサーバＭ）に対して、それぞれのＳＩＰサーバにおける既存のＳＩＰタイマ制御部にセッションタイマを独自にセットするか、この第１の実施形態に係るＳＩＰサーバ１０を適用することが好ましい。
【００８２】
さらに、この第１の実施形態においては、ＳＩＰヘッダ制御部５が、ＳＩＰ通信モード管理データに基づき、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に「９０秒」を設定しているが、ＵＡＣから送信されるＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）に有限値（図２においては、「１８０秒」）が設定されているのであれば、設定された有限値の経過後にＵＡＣ及びＵＡＳに対して自動的に切断動作を行なわせることができる。このため、ＳＩＰヘッダ制御部５によって、Session-Expiresヘッダにおけるリフレッシュ時間値（ＳＥ）を新たに設定しなくてもよいが、激震災害時などの被災者の安否を確認するような、多数のエンドユーザに対してより多くの回数の通信を行わせる必要がある場合に、安否確認に最低限で必要なコーデックである低品質及び短時間で通信を意図的に終わらせるように、被災者の安否が確認できる程度の短時間の通話可能時間を設定することが好ましい。
【００８３】
また、この第１の実施形態においては、保守通信ネットワーク２００を介して入力される保守指示信号に基づき、通常モード又は非常モードにおけるＳＩＰ通信モード管理データをＳＩＰ通信モード管理データ格納部１に記憶し、ＳＩＰ通信モード管理データの動作モードをセッション管理データ格納部６に記憶しているが、ＳＩＰ通信モード管理データ格納部１及びセッション管理データ格納部６をＳＩＰサーバ１０に設けずに、ＳＩＰ通信ネットワーク１００の通信状態が輻輳状態の場合に、常時、保守指示信号をＳＩＰ通信モード管理部２に入力する構成でもよい。
【００８４】
以上のように、この第１の実施形態に係るＳＩＰサーバ１０を用いたＳＩＰ通信ネットワーク１００においては、通信トラヒックが多量に発生する時期において、通話中に遷移した後のＳＩＰ信号を、ＳＩＰサーバを経由せずに、直接、ＵＡＣ及びＵＡＳ間でやり取りさせることができると共に、ＵＡＣ及びＵＡＳ間で無制限に長時間の通話をさせないことを、端末の改造を行なうことなく、ＲＦＣに準拠した形で実現することができる。これにより、安否の確認などに必要な通信を極力多量に実施することを可能にし、サーバ輻輳規制そのものによる輻輳を招くことなく、エンドユーザに対してより多くの通信を一般のＩＰ電話で行なわせることができる。
【００８５】
［付記］  上記実施形態に関し、更に以下の付記を開示する。
（付記１）
この発明に係るＳＩＰサーバにおいては、複数の中継サーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルを使用するＳＩＰ通信ネットワークを構成するＳＩＰサーバにおいて、前記ＳＩＰ通信ネットワークの通信状態が輻輳状態である非常モード及びそれ以外の状態である通常モードにそれぞれ対応するＳＩＰ通信モード管理データを、前記ＳＩＰ通信ネットワークと異なるネットワークである保守通信ネットワークを介して入力される保守指示信号に基づき、当該通常モードから非常モードに切り替えて、前記ＳＩＰ通信モード管理データを管理するＳＩＰ通信モード管理部と、前記ＳＩＰを用いた呼制御を行ない、ＳＩＰメッセージのＩＮＶＩＴＥリクエストが入力され、当該ＩＮＶＩＴＥリクエスト及び前記ＳＩＰ通信モード管理データに基づき、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定するＳＩＰ呼制御部と、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰ呼制御部から入力されるＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定しないと共に、既に設定されているRecord-Routeヘッダのヘッダ値を削除するＳＩＰヘッダ制御部と、を備えているものである。
【００８６】
（付記２）
この発明に係るＳＩＰサーバにおいては、必要に応じて、発端末及び着端末間における通話品質及び通話可能時間を当該発端末又は着端末が任意に指定できる前記通常モード並びに通話品質及び通話可能時間を保守指示信号により指定される前記非常モードにそれぞれ対応するＳＩＰ通信モード管理データを記憶するＳＩＰ通信モード管理データ格納部を備え、前記ＳＩＰ通信モード管理部は、前記保守指示信号に基づき、前記通常モードから非常モードに切り替えて、前記非常モードにおけるＳＩＰ通信モード管理データを前記ＳＩＰ通信モード管理データ格納部に設定し、前記ＳＩＰ呼制御部は、前記ＩＮＶＩＴＥリクエストに基づき、前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部に記憶されたＳＩＰ通信モード管理データを読み出し、前記非常モードにおけるＳＩＰ通信モード管理データであるか否かを判定するものである。
【００８７】
（付記３）
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに発端末を設定すると共に、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンス及び前記セッション管理データの動作モードに基づき当該動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定するものである。
【００８８】
（付記４）
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスに基づき前記セッション管理データ格納部から読み出す動作モードが非常モードであると判定した場合に、前記２００ＯＫレスポンスのSession-Expiresヘッダにおけるリフレッシャー指示パラメタに着端末を設定するものである。
【００８９】
（付記５）
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰヘッダ制御部は、前記ＳＩＰ呼制御部が前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＩＮＶＩＴＥリクエストのSession-Expiresヘッダにおけるリフレッシュ時間値に前記通話可能時間を設定するものである。
【００９０】
（付記６）
この発明に係るＳＩＰサーバにおいては、必要に応じて、所定のセッションタイマの経過後に当該セッションタイマの満了を前記ＳＩＰ呼制御部に通知するＳＩＰタイマ制御部を備え、前記ＳＩＰ呼制御部は、前記非常モードにおけるＳＩＰ通信モード管理データであると判定した場合に、前記ＳＩＰタイマ制御部に所定のセションタイマを設定すると共に、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッションのリソースを開放するものである。
【００９１】
（付記７）
この発明に係るＳＩＰサーバにおいては、必要に応じて、前記ＳＩＰ呼制御部が前記ＳＩＰ通信モード管理部を介して前記ＳＩＰ通信モード管理データ格納部から読み出したＳＩＰ通信モード管理データのうち、前記非常モード又は通常モードを示す動作モードを記憶するセッション管理データ格納部を備え、前記ＳＩＰ呼制御部は、前記ＳＩＰタイマ制御部からのセッションタイマの満了の通知に基づき、前記ＩＮＶＩＴＥリクエストのRecord-Routeヘッダに自サーバを示す情報を設定せずに確立したセッションにおける当該セッションの切断信号を送信することなく、前記セッション管理データ格納部に記憶された前記セッションのリソースを開放するものである。
【図面の簡単な説明】
【００９２】
【図１】この第１の実施形態に係るＳＩＰサーバの概略構成を示す機能ブロック図である。
【図２】図１に示すＳＩＰサーバを用いたＳＩＰによるメッセージの送信経路設定の一例を示すシーケンス図である。
【図３】図１に示すＳＩＰサーバが保守指示信号を受信した場合における処理手順の一例を示すシーケンス図である。
【図４】図１に示すＳＩＰサーバがＩＮＶＩＴＥリクエストを受信した場合における処理手順の一例を示すシーケンス図である。
【図５】図１に示すＳＩＰサーバがＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスを受信した場合における処理手順の一例を示すシーケンス図である。
【図６】この第１の実施形態に係るＳＩＰサーバが保守指示信号を受信した場合におけるＳＩＰサーバの処理手順の他の例を示すシーケンス図である。
【図７】この第１の実施形態に係るＳＩＰサーバが保守指示信号を受信した場合におけるＳＩＰサーバの処理手順のさらに他の例を示すシーケンス図である。
【図８】ＳＩＰサーバの概念を説明するための説明図である。
【図９】ＳＩＰによるメッセージの送信経路設定を説明するための説明図である。
【符号の説明】
【００９３】
１      ＳＩＰ通信モード管理データ格納部
２      ＳＩＰ通信モード管理部
３      ＳＩＰ通信制御部
４      ＳＩＰ呼制御部
５      ＳＩＰヘッダ制御部
６      セッション管理データ格納部
７      ＳＩＰタイマ制御部
１０    ＳＩＰサーバ
１００  ＳＩＰ通信ネットワーク
２００  保守通信ネットワーク
【図１】
2009044325.tif 000003
【図２】
2009044325.tif 000004
【図３】
2009044325.tif 000005
【図４】
2009044325.tif 000006
【図５】
2009044325.tif 000007
【図６】
2009044325.tif 000008
【図７】
2009044325.tif 000009
【図８】
2009044325.tif 000010
【図９】
2009044325.tif 000011