JP4924124B2

JP4924124B2 - Ｓｉｐサーバ

Info

Publication number: JP4924124B2
Application number: JP2007068692A
Authority: JP
Inventors: 龍二小田; 淳司田金
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2007-03-16
Filing date: 2007-03-16
Publication date: 2012-04-25
Anticipated expiration: 2027-03-16
Also published as: US20080225835A1; JP2008236003A

Description

この発明は、複数のサーバで構成されるＩＰ（Internet Protocol）ネットワーク上で、マルチメディアセッションを開始／変更／終了するためのプロトコルとしてセッション開始プロトコル（Session Initiation Protocol：以下、ＳＩＰと称す）を使用するＳＩＰサーバに関し、特に、セッション通信中の状態で通信を中継するサーバに障害が発生し、このセッション通信中の状態で（このセッション通信が終了する前に）セッションリソースの開放（クリア）を伴う当該サーバの復旧がなされた場合に、発信端末と着信端末との間のこのセッション通信を継続させることができるＳＩＰサーバに関するものである。

従来のＳＩＰサーバは、ＳＩＰを搭載した複数のＳＩＰサーバが相互に接続されているＩＰ網において、１つのＳＩＰサーバから対向するＳＩＰサーバに送出されるＳＩＰにおけるＩＮＶＩＴＥメッセージに対する応答信号が返送されない時に、この１つのＳＩＰサーバが対向するサーバの呼制御機能の障害であることを検出する（例えば、特許文献１参照）。

しかしながら、この従来のＳＩＰサーバでは、ＩＮＶＩＴＥメッセージに対する応答に基づいて障害を判定しているため、すでにセッション通信が開始している状態でＳＩＰサーバに障害が発生した場合には、そのＳＩＰサーバに障害が発生していることを検知することができない。

そこで、本願発明者は、すでにセッション通信が開始している状態でＳＩＰサーバに障害が発生した場合に、そのＳＩＰサーバに障害が発生していることを検知すると共に、セッション通信中の状態で、通信を中継するサーバに障害が発生した場合でも、発信側の端末（以下、ＵＡＣ（User Agent Client）と称す）と着信側の端末（以下、ＵＡＳ（User Agent Server）と称す）との間のセッション通信を継続させることができる送信経路設定装置に係る発明を出願した（特許文献２参照）。

例えば、図９に示すＩＰ電話ネットワークにおいては、ＵＡＣとＵＡＳとの間の通信が、ＳＩＰサーバＢ、ＳＩＰサーバＭ及びＳＩＰサーバＹを経由して行われていたとする。なお、ＳＩＰヘッダ名である、Request-URIはRURI、Record-RouteはRR、ContactはC、RouteはRとして、それぞれ略称で示している。図９は従来の送信経路設定装置の問題点を説明する説明図である。

このようなネットワークにおいて、ＵＡＣとＵＡＳとの間のセッション通信中の状態で、例えば障害などの原因によりＳＩＰサーバＭがダウンした場合には、ＵＡＣから送信されたＳＩＰメッセージ及びＵＡＳから送信されたＳＩＰメッセージは、ＵＡＳ及びＵＡＣにそれぞれ到達しなくなる。

そこで、従来の送信経路設定装置によれば、ＳＩＰサーバＹが、ＳＩＰサーバＭとの間の通信状態を判定し、ＳＩＰサーバＭとの間の通信状態が異常であると判定した場合に、リクエストメッセージ（図９ではｒｅ−ＩＮＶＩＴＥリクエスト）のヘッダ情報に設定されたＳＩＰサーバの中継順序に係る情報に基づいて、通信状態が異常であると判定したＳＩＰサーバＭの次のＳＩＰサーバＢをリクエストメッセージの送信先として設定することで、ＵＡＣから送信されたＳＩＰメッセージ及びＵＡＳから送信されたＳＩＰメッセージを、ＳＩＰサーバＭをスキップして、ＵＡＳ及びＵＡＣにそれぞれ到達させることができる。

また、ＳＩＰサーバＭが復旧した場合には、ＳＩＰサーバＹは、ＳＩＰサーバＭとの間の通信状態が正常であると判定し、リクエストメッセージ（図９ではｒｅ−ＩＮＶＩＴＥリクエスト）のヘッダ情報に設定されたＳＩＰサーバの中継順序に係る情報に基づいて、ＳＩＰサーバＭをリクエストメッセージの送信先として設定する。
特開２００４−１７９７６４号公報特願２００６−２８６８５６号

しかしながら、従来の送信経路設定装置は、セッション通信中の状態で通信を中継するサーバに障害が発生し、このセッション通信中の状態で当該サーバの復旧がなされた場合であっても、復旧の程度によって以下のような問題点があった。すなわち、セッションリソースの開放を伴う当該サーバの復旧がなされた場合にあっては、この復旧したサーバは、障害が発生する前にやり取りしていたセッション通信の情報を保持しておらず、リソースが開放されたセッション通信におけるリクエストを受信した場合に、受信したリクエストを存在しないセッション通信に対する異常リクエストと判断してしまう。このため、復旧したサーバにリクエストを送信したサーバに対して、準正常レスポンスを応答してしまい、復旧したサーバの次の送信先に設定されているサーバに対してリクエストを送信することができないという問題点があった。

特に、復旧したサーバが、リソースが開放されたセッション通信におけるリクエストとして、ＢＹＥリクエスト（終了リクエスト）を受信した場合には、復旧したサーバの次の送信先以降のサーバにおいて、正常な切断処理が行なえず、ＵＡＣに対する課金処理を行っているＳＩＰサーバにおいて、実際はセッション通信が不可能な状態になっているにもかかわらず、課金処理が継続して行われてしまうという問題点があった。

ここで、ＩＥＴＦ（Internet Engineering Task Force）により規定されたＳＩＰの拡張仕様（ＲＦＣ４０２８）には、セッション通信の状態を確認するためのセッションタイマ（Session Timers）機能の仕様が定義されている。このセッションタイマ機能を備えていた場合、ＵＡＣ、ＵＡＳ及びＳＩＰサーバは、セッション通信の開始時（呼設定時）に通信相手の端末（ＵＡＣ，ＵＡＳ）との間で任意の生存時間（セッションタイマ）を決定し、セッション通信中は、常にタイマで時間を計数して、生存時間の半分の時間（リフレッシュタイマ）が過ぎた時点で、通信相手の端末（ＵＡＣ又はＵＡＳ）に対してｒｅ−ＩＮＶＩＴＥリクエスト（セッション生存確認リクエスト）を送信する。

そして、ＵＡＣ、ＵＡＳ及びＳＩＰサーバは、送信したリクエストに対してレスポンスが応答された場合には、その時点では通信が可能であると判定してタイマをリセットし、ｒｅ−ＩＮＶＩＴＥリクエストの送信とレスポンスの有無の確認（リフレッシュ動作）を繰り返し、一方、生存時間が過ぎてもレスポンスが応答されなかった場合には、通信が不可能であると判定してセッション通信を終了する。

このため、図９に示すように、復旧したサーバ（図９においてはＳＩＰサーバＭ）が、リソースが開放されたセッション通信におけるリクエストとして、ｒｅ−ＩＮＶＩＴＥリクエストを受信した場合には、復旧したサーバは、該当セッション通信が存在しないことを示す応答コード（例えば、「481 Call/Transaction Does Not Exist」など）が設定されたレスポンスメッセージを、送信元のＳＩＰサーバ（図９においてはＳＩＰサーバＹ）に対して送信することで、復旧したサーバにおける次の送信先以降のサーバ（図９においてはＳＩＰサーバＢ）において、セッションタイマの更新に失敗し、通信者の意思に反してセッション通信を終了するという問題点があった。

ちなみに、あるセッション通信を開始する前に対向サーバにすでに障害が発生しており、このセッション通信を開始する前に当該対向サーバがまだ復旧していない場合であれば、当該対向サーバはこのセッション通信の送信経路に設定されることはないために、従来技術による問題点は生じることはない。

また、あるセッション通信を開始する前に対向サーバにすでに障害が発生しており、当該対向サーバが復旧した後にこのセッション通信が開始された場合であれば、当然ながら、このセッション通信中の状態で当該対向サーバに障害が発生しない限りこのセッション通信は問題なく行なわれる。

また、あるセッション通信中の状態で対向サーバに障害が発生し、このセッション通信が終了した後に当該対向サーバが復旧した場合であれば、従来技術による問題点は生じることはない。

すなわち、あるセッション通信中の状態で対向サーバに障害が発生し、このセッション通信中の状態で当該対向サーバが復旧した場合（以下、「特定セッション通信中の状態で障害を経験した場合」と称す）に、従来技術による問題点が生じるものである。

この発明は、上述のような課題を解決するためになされたものであり、セッション通信中の状態で通信を中継する対向サーバに障害が発生し、このセッション通信中の状態でセッションリソースの開放を伴う当該サーバの復旧がなされた場合であっても、発信端末（ＵＡＣ）と着信端末（ＵＡＳ）との間のセッション通信を継続させることができるＳＩＰサーバを提供することを目的とする。

この発明に係るＳＩＰサーバにおいては、ＳＩＰに準拠したＳＩＰメッセージの送受信を制御するＳＩＰ通信制御部と、前記ＳＩＰを用いた呼制御を行なうＳＩＰ呼制御部と、対向サーバとの間の通信状態の結果である通信状態情報、及び対向サーバの復旧状態の結果から当該対向サーバをスキップする必要性をセッション通信毎に判定した結果である迂回要否情報を管理するコールデータ管理部と、次の送信先に設定されている対向サーバの前記通信状態情報及び迂回要否情報に基づき、当該対向サーバに対してセッション通信毎に前記ＳＩＰメッセージをスキップさせるか否かを判定する迂回制御部と、前記迂回制御部による判定に基づき、前記ＳＩＰメッセージのルートヘッダの編集を行なうＳＩＰヘッダ制御部と、を備え、前記迂回制御部は、前記通信状態情報が次の送信先に設定されている対向サーバが通信不可能である旨の情報である場合に、当該対向サーバに対して前記ＳＩＰメッセージをスキップさせるように判定すると共に、前記迂回要否情報が次の送信先に設定されている対向サーバが復旧して通信可能であるが当該対向サーバにセッション通信のセッションリソースが存在しないため当該対向サーバをスキップする必要がある旨の情報である場合に、当該対向サーバに対して当該セッション通信における前記ＳＩＰメッセージをスキップさせるように判定するものである。

本発明は、ＳＩＰに準拠したＳＩＰメッセージの送受信を制御するＳＩＰ通信制御部と、前記ＳＩＰを用いた呼制御を行なうＳＩＰ呼制御部と、対向サーバとの間の通信状態の結果である通信状態情報、及び対向サーバの復旧状態の結果から当該対向サーバをスキップする必要性をセッション通信毎に判定した結果である迂回要否情報を管理するコールデータ管理部と、次の送信先に設定されている対向サーバの前記通信状態情報及び迂回要否情報に基づき、当該対向サーバに対してセッション通信毎に前記ＳＩＰメッセージをスキップさせるか否かを判定する迂回制御部と、前記迂回制御部による判定に基づき、前記ＳＩＰメッセージのルートヘッダの編集を行なうＳＩＰヘッダ制御部と、を備え、前記迂回制御部は、前記通信状態情報が次の送信先に設定されている対向サーバが通信不可能である旨の情報である場合に、当該対向サーバに対して前記ＳＩＰメッセージをスキップさせるように判定すると共に、前記迂回要否情報が次の送信先に設定されている対向サーバが復旧して通信可能であるが当該対向サーバにセッション通信のセッションリソースが存在しないため当該対向サーバをスキップする必要がある旨の情報である場合に、当該対向サーバに対して当該セッション通信における前記ＳＩＰメッセージをスキップさせるように判定することにより、セッション通信中の状態で通信を中継する対向サーバに障害が発生し、このセッション通信中の状態で当該対向サーバのセッションリソースが開放されて当該対向サーバが復旧した場合であっても、当該対向サーバをスキップしてＳＩＰメッセージを送信することが可能となり、発信端末と着信端末との間のセッション通信を継続させることができる。

（本発明の第１の実施形態）
図１はこの第１の実施形態に係るＳＩＰサーバの概念を説明するための説明図、図２はＳＩＰによるメッセージの送信経路設定を説明するための説明図、図３はこの第１の実施形態に係るＳＩＰサーバの構成を示す機能ブロック図、図４はＳＩＰサーバが障害の復旧を検知していた場合のこの第１の実施形態に係るＳＩＰサーバの処理手順を示すシーケンス図、図５は図１に示すＳＩＰサーバの迂回制御手順を説明するための機能ブロック図、図６はＳＩＰサーバが障害及び復旧を検知していなかった場合のこの第１の実施形態に係るＳＩＰサーバの処理手順を示すシーケンス図である。

まず、この第１の実施形態に係るＳＩＰサーバ２００の概念について説明する。図１において、この第１の実施形態に係るＳＩＰサーバＡ（ＳＩＰサーバ２００Ａ）、ＳＩＰサーバＢ（ＳＩＰサーバ２００Ｂ）、ＳＩＰサーバＭ（ＳＩＰサーバ２００Ｍ）、ＳＩＰサーバＮ（ＳＩＰサーバ２００Ｎ）、ＳＩＰサーバＸ（ＳＩＰサーバ２００Ｘ）及びＳＩＰサーバＹ（ＳＩＰサーバ２００Ｙ）により構成されたＩＰ電話のネットワークを示しており、同図に示すように、ＳＩＰサーバＢとＳＩＰサーバＭとがＩＰネットワーク１を介して、ＳＩＰサーバＭとＳＩＰサーバＹとがＩＰネットワーク２を介して、ＳＩＰサーバＢとＳＩＰサーバＹとがＩＰネットワーク３を介して、それぞれ接続されている。

また、図１において、ＵＡＣ（発端末３００ａ）は、発信者の端末（ＩＰ電話機）を示しており、ＵＡＳ（着端末３００ｂ）は、着信者の端末（ＩＰ電話機）を示しており、同図に示すように、ＵＡＣとＵＡＳとは、ＳＩＰサーバＢ、ＳＩＰサーバＭ及びＳＩＰサーバＹを介して、通話に関する通信を行なう。

かかるＩＰ電話のネットワークにおいて、各ＳＩＰサーバは、自サーバに接続されているＳＩＰサーバ（以下、「対向サーバ」と称す）との間の通信状態（通信が可能であるか否か）を常時確認し、確認した結果を通信状態情報として管理している。また、各ＳＩＰサーバは、対向サーバの復旧状態（特定セッション通信中の状態で障害を経験した場合における、セッションリソースが開放されて当該対向サーバが復旧したか否か（当該対向サーバに特定セッション通信のセッションリソースが存在するか否か））を常時確認し、確認した結果から対向サーバをスキップする必要性をセッション通信毎に判定した結果を迂回要否情報として管理している。例えば、ＳＩＰサーバＢはＳＩＰサーバＭとの間の通信状態及びＳＩＰサーバＭの復旧状態を、ＳＩＰサーバＭはＳＩＰサーバＢとの間の通信状態及びＳＩＰサーバＢの復旧状態並びにＳＩＰサーバＹとの間の通信状態及びＳＩＰサーバＹの復旧状態を、ＳＩＰサーバＹはＳＩＰサーバＭとの間の通信状態及びＳＩＰサーバＭの復旧状態を、通信状態情報及び迂回要否情報としてそれぞれ管理している。

なお、対向サーバをスキップする必要性を判定するにあたり、次の送信先である対向サーバを送信経路とするセッション通信のうち、当該対向サーバにおいてセッションリソースが存在しないセッション通信については、当該対向サーバをスキップさせる必要がある（復旧状態が異常）と判定し、そのセッション通信が終了（終話）するまで当該対向サーバをスキップさせる。また、次の送信先である対向サーバを送信経路とするセッション通信のうち、当該対向サーバにおいてセッションリソースが存在するセッション通信については、当該対向サーバをスキップさせる必要はない（復旧状態が正常）と判定する。

ここで、ＵＡＣとＵＡＳとの間では、ＳＩＰによるＩＮＶＩＴＥリクエストなどのメッセージのやり取りの末に、すでにあるセッション通信が開始されていたとし、その状態で、ＵＡＳから、このセッション通信の終了を要求するＢＹＥリクエストが発信されたとする（図１の矢印１）。このＢＹＥリクエストのヘッダ情報には、当該ＢＹＥリクエストの送信経路が設定されており、ここでは、ＳＩＰサーバＹ、ＳＩＰサーバＭ、ＳＩＰサーバＢの順で送信されるように送信経路が設定されていたとする。

ＳＩＰサーバＹは、ＢＹＥリクエストを受信すると、当該ＢＹＥリクエストのヘッダ情報を参照して次の送信先がＳＩＰサーバＭであることを確認し、さらに、管理している通信状態情報に基づいて、ＳＩＰサーバＭが通信可能であるか否かを確認する。また、ＳＩＰサーバＭが特定セッション通信中の状態で障害を経験した場合であれば、管理している迂回要否情報に基づいて、ＳＩＰサーバＭをスキップする必要があるか否かを確認する。

ここで、障害などの原因により、ＳＩＰサーバＭが通信不可能な状態、又はＳＩＰサーバＭが通信可能な状態であるが特定セッション通信中の状態で障害を経験した場合でありＳＩＰサーバＭに特定セッション通信のセッションリソースが存在しない状態であったとする。その場合、ＳＩＰサーバＹは、ＳＩＰサーバＭを経由せずに、その次の送信先に設定されているＳＩＰサーバＢに対して、当該ＢＹＥリクエストを送信する（図１の矢印２）。この時、ＳＩＰサーバＹは、ＢＹＥリクエストのヘッダ情報に設定され送信経路からＳＩＰサーバＭを示す情報を削除したうえで、当該ＢＹＥリクエストを送信する。

ＳＩＰサーバＢは、ＢＹＥリクエストを受信すると、当該ＢＹＥリクエストによるセッション通信の終了の要求先であるＵＡＣに対して、当該ＢＹＥリクエストを送信する（図１の矢印３）。

このように、この第１の実施形態に係るＳＩＰサーバは、リクエストメッセージを次に送信すべきＳＩＰサーバとの間の通信状態を判定し、次に送信すべきＳＩＰサーバとの間の通信状態が異常であると判定した場合に、リクエストメッセージのヘッダ情報に設定されたＳＩＰサーバの中継順序に係る情報に基づいて、通信状態が異常であると判定したＳＩＰサーバの次のＳＩＰサーバをリクエストメッセージの送信先として設定することを特徴とするものである。

また、この第１の実施形態に係るＳＩＰサーバは、リクエストメッセージを次に送信すべきＳＩＰサーバとの間の通信状態を判定し、次に送信すべきＳＩＰサーバとの間の通信状態が正常であると判定した場合には、さらに、次に送信すべきＳＩＰサーバをスキップする必要性を判定し、次に送信すべきＳＩＰサーバのスキップが必要であると判定した場合に、リクエストメッセージのヘッダ情報に設定されたＳＩＰサーバの中継順序に係る情報に基づいて、スキップが必要であると判定したＳＩＰサーバの次のＳＩＰサーバをリクエストメッセージの送信先として設定することを特徴とするものである。

ここで、この第１の実施形態に係るＳＩＰサーバの詳細な説明に先立ち、ＳＩＰによるメッセージの送信経路設定について図２を用いて説明する。図２は図１に示したＳＩＰサーバＢ、ＳＩＰサーバＭ及びＳＩＰサーバＹにおいて行われる送信経路設定を示している。

各ＳＩＰサーバは、ＵＡＣ若しくはＵＡＳ又は他のＳＩＰサーバからＳＩＰメッセージを受信すると、その度に次の送信先を特定して、当該ＳＩＰメッセージを転送する。この送信先の特定は、セッション通信の開始時にＵＡＣ及びＵＡＳにおいて生成されるルートセットに基づいて行われる。このルートセットは、ＩＮＶＩＴＥリクエスト及びＩＮＶＩＴＥリクエストに対するレスポンスメッセージのヘッダ情報に含まれるRecord-Routeヘッダ及びContactヘッダに基づいて生成される。

ここで、Record-Routeヘッダは、ＩＮＶＩＴＥリクエストの送信経路が設定されるヘッダであり、具体的には、ＩＮＶＩＴＥリクエストの送信経路において経由されたＳＩＰサーバを示す情報が順番に設定される。Contactヘッダは、ＩＮＶＩＴＥリクエストやレスポンスメッセージを送信した送信元の端末を示す情報が設定されるヘッダである。

例えば、図２に示すように、ＵＡＳに対するＩＮＶＩＴＥリクエストがＵＡＣから発信され（ステップＳ１０１）、ＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹの順に転送されて、ＵＡＳに到達したとする（ステップＳ１０２〜Ｓ１０４）。このＩＮＶＩＴＥリクエストのRecord-Routeヘッダには、それまでに経由したＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹを示す情報が順番に設定され（図２に示す「ＲＲ：Ｙ，Ｍ，Ｂ」）、Contactヘッダには、当該ＩＮＶＩＴＥリクエストの送信元であるＵＡＣを示す情報が設定されている（図２に示す「Ｃ：ＵＡＣ」）。

ＵＡＳは、ＩＮＶＩＴＥリクエストを受信すると、当該ＩＮＶＩＴＥリクエストのRecord-Routeヘッダ及びContactヘッダに基づいて、ルートセットを生成する（図２に示す「Ｙ，Ｍ，Ｂ，ＵＡＣ」）。そして、ＵＡＳは、ＩＮＶＩＴＥリクエストによるセッション開始要求を受け付けたことを示す２００ＯＫレスポンス（応答コード「200 OK」が設定されたレスポンスメッセージ）をＵＡＣに対して送信する（ステップＳ１０５）。

ＵＡＳにより送信された２００ＯＫレスポンスは、ＩＮＶＩＴＥリクエストが転送された経路を逆にたどり、ＳＩＰサーバＹ、ＳＩＰサーバＭ、ＳＩＰサーバＢの順に転送されて、ＵＡＣに到達する（ステップＳ１０６〜Ｓ１０８）。この２００ＯＫレスポンスのRecord-Routeヘッダには、ＵＡＳにより受信されたＩＮＶＩＴＥリクエストのRecord-Routeヘッダと同じ情報が設定され（図２に示す「ＲＲ：Ｙ，Ｍ，Ｂ」）、Contactヘッダには、当該２００ＯＫレスポンスの送信元であるＵＡＳを示す情報が設定されている（図２に示す「Ｃ：ＵＡＳ」）。

ＵＡＣは、２００ＯＫレスポンスを受信すると、当該２００ＯＫレスポンスのRecord-Routeヘッダ及びContactヘッダに基づいて、ルートセットを生成する（図２に示す「Ｙ，Ｍ，Ｂ，ＵＡＳ」）。そして、ＵＡＣは、ＩＮＶＩＴＥリクエストに対する２００ＯＫレスポンスを受け付けたことを示すＡＣＫメッセージをＵＡＳに対して送信する（ステップＳ１０９）。ＵＡＣにより送信されたＡＣＫメッセージは、ＩＮＶＩＴＥリクエストと同じ経路をたどり、ＳＩＰサーバＢ、ＳＩＰサーバＭ、ＳＩＰサーバＹの順に転送されて、ＵＡＳに到達する（ステップＳ１１０〜Ｓ１１２）。

以上の手続きにより、ＵＡＣとＵＡＳとの間で、セッション通信が開始される（セッション通信中状態）。そして、これ以降、ＵＡＣ又はＵＡＳから送信されるリクエストメッセージのヘッダには、それぞれの端末において生成されたルートセットに基づいて送信経路が設定され、この送信経路に基づいて、各ＳＩＰサーバは、リクエストメッセージの次の送信先を特定する。

例えば、図２に示すように、セッション通信の終了要求を示すＢＹＥリクエストがＵＡＣからＵＡＳに対して送信される場合には（ステップＳ１１３）、ＵＡＣにおいて、ルートセットに基づいて当該ＢＹＥリクエストのRequest-URIヘッダ及びRouteヘッダが設定される（図２に示す「ＲＵＲＩ：ＵＡＳ」及び「Ｒ：Ｂ，Ｍ，Ｙ」）。

ここで、Request-URIヘッダは、リクエストメッセージの送信先（リクエストの要求先）を示す情報が設定されるヘッダであり、Routeヘッダは、リクエストメッセージを送信する際の送信経路（ＳＩＰサーバの経由順）を示す情報が設定されるヘッダである。

ＵＡＣにより送信されたＢＹＥリクエストは、Request-URIヘッダ及びRouteヘッダに設定された情報に基づいて、ＳＩＰサーバＢからＳＩＰサーバＭに、ＳＩＰサーバＭからＳＩＰサーバＹに転送され、さらにＳＩＰサーバＹからＵＡＳに転送される（ステップＳ１１４〜Ｓ１１６）。

同様に、ＵＡＳからＵＡＣに対してＢＹＥリクエストが送信される場合には（ステップＳ１１７）、ＵＡＳにおいて、ルートセットに基づいて当該ＢＹＥリクエストのRequest-URIヘッダ及びRouteヘッダが設定され（図２に示す「ＲＵＲＩ：ＵＡＣ，Ｒ：Ｙ，Ｍ，Ｂ」）、このＢＹＥリクエストは、ヘッダ情報に基づいて、ＳＩＰサーバＹからＳＩＰサーバＭに、ＳＩＰサーバＭからＳＩＰサーバＢに転送され、さらにＳＩＰサーバＢからＵＡＣに転送される（ステップＳ１１８〜Ｓ１２０）。

このように、ＳＩＰを用いたネットワークでは、ＵＡＣとＵＡＳとの間でセッション通信が開始された以降は、ＵＡＣ又はＵＡＳから送信されるリクエストメッセージのRouteヘッダには、それぞれの端末において生成されたルートセットに基づいて送信経路が設定され、この送信経路に基づいて、各ＳＩＰサーバは、リクエストメッセージの次の送信先を特定する。

次に、この第１の実施形態に係るＳＩＰサーバの構成について図３を用いて説明する。ＳＩＰサーバ２００は、代表的な機能として呼処理を制御する機能と通信を制御する機能とから構成される呼処理の交換を行なうためのシステムとしてのソフトスイッチである。図３に示すように、ＳＩＰサーバ２００は、ＳＩＰ通信制御部１０と、ＳＩＰ呼制御部２０と、ＳＩＰヘッダ制御部３０と、コールデータ管理部４０と、迂回制御部５０とを備える。なお、図３に示すＳＩＰサーバ２００の構成は、本発明に直接的に関係のない構成部位については省略しており、保守管理機能などの様々な機能を有する構成部位を備えてもよい。

ＳＩＰ通信制御部１０は、ＳＩＰに準拠したＳＩＰメッセージの送受信を制御する処理部である。例えば、このＳＩＰ通信制御部１０は、ＩＮＶＩＴＥリクエスト、ＢＹＥリクエスト又はｒｅ−ＩＮＶＩＴＥリクエストなどのリクエストメッセージや、「200 OK」又は「100 Trying」などの応答コードが設定されたレスポンスメッセージを、対向サーバとの間で送受信する。

ＳＩＰ呼制御部２０は、ＳＩＰを用いた呼制御を行なう処理部である。このＳＩＰ呼制御部２０は、本発明に関連する機能としては、リクエストメッセージを送信する際に、次の送信先に指定されているＳＩＰサーバをスキップするか否かを迂回制御部５０に問い合わせる。そして、ＳＩＰ呼制御部２０は、迂回制御部５０から当該ＳＩＰサーバをスキップするように指示された場合には、ＳＩＰヘッダ制御部３０に指示することによって、リクエストメッセージのヘッダ情報に設定されている送信経路から、次の送信先のＳＩＰサーバを示す情報を削除し、そのうえで、スキップするＳＩＰサーバの次の送信先に設定されているＳＩＰサーバに対して当該リクエストメッセージを送信する。

一方、ＳＩＰ呼制御部２０は、迂回制御部５０から次の送信先のＳＩＰサーバをスキップしないように指示された場合には、リクエストメッセージのヘッダ情報に設定されている送信経路に従って、次の送信先に指定されているＳＩＰサーバに対して当該リクエストメッセージを送信する。ここで、送信先のＳＩＰサーバが正常（通信状態が正常かつ復旧状態が正常）に稼動していた場合には、リクエストメッセージを正常に受け付けたことを示すレスポンスメッセージが返送される。しかし、送信先のＳＩＰサーバに何らかの異常（通信状態が異常、又は通信状態が正常かつ復旧状態が異常）が発生していた場合には、リクエストメッセージを正常に受け付けることができなかったことを示すレスポンスメッセージが返送されるか、又はレスポンスメッセージ自体が返送されない。

そこで、ＳＩＰ呼制御部２０は、送信したリクエストメッセージに対して、送信先のＳＩＰサーバからサービス停止状態を示す応答コード（例えば、「503 Service Unavailable」など）が設定されたレスポンスメッセージが返送された場合や、所定の時間が経過しても送信先のＳＩＰサーバからレスポンスメッセージが返送されなかった場合には、次の送信先のＳＩＰサーバが通信不可能であると判定し、ＳＩＰヘッダ制御部３０に指示することによって、リクエストメッセージのヘッダ情報に設定されている送信経路から当該ＳＩＰサーバを示す情報を削除し、そのうえで、当該ＳＩＰサーバの次の送信先に設定されているＳＩＰサーバに対して当該リクエストメッセージを送信する。

また、ＳＩＰ呼制御部２０は、送信したリクエストメッセージに対して、送信先のＳＩＰサーバから該当セッション通信が存在しないことを示す応答コード（例えば、「481 Call/Transaction Does Not Exist」など）が設定されたレスポンスメッセージが返送された場合には、このレスポンスメッセージが返送されたことを迂回制御部５０に伝える。これにより、迂回制御部５０は、送信先のＳＩＰサーバが通信可能な状態であるが、当該セッション通信中の状態で障害を経験しており、当該ＳＩＰサーバに当該セッション通信のセッションリソースが存在しない状態であると判断し、当該セッション通信については、当該セッション通信が終了するまで当該ＳＩＰサーバをスキップする必要があると判定する。この判定結果を迂回要否情報として、コールデータ管理部４０に記憶させると共に、ＳＩＰ呼制御部２０に対して、当該ＳＩＰサーバをスキップするように指示する。ＳＩＰ呼制御部２０は、当該ＳＩＰサーバをスキップするようにＳＩＰヘッダ制御部３０に指示することによって、リクエストメッセージのヘッダ情報に設定されている送信経路から当該ＳＩＰサーバを示す情報を削除し、そのうえで、当該ＳＩＰサーバの次の送信先に設定されているＳＩＰサーバに対して当該リクエストメッセージを送信する。

なお、ここでは、ＳＩＰ呼制御部２０は、次の送信先のＳＩＰサーバが通信不可能であると判定した場合に、通信不可能なＳＩＰサーバの次のＳＩＰサーバにリクエストメッセージを送信することとし、次の送信先から該当セッション通信が存在しないことを示す応答コードが設定されたレスポンスメッセージが返信された場合に、このレスポンスメッセージを返信したＳＩＰサーバの次のＳＩＰサーバにリクエストメッセージを送信することとしたが、そのＳＩＰサーバについても通信状態及び復旧状態を確認し、通信不可能であった場合又は該当セッション通信のセッションリソースが存在しない場合は、さらにその次のＳＩＰサーバにリクエストメッセージを送信するようにしてもよい。

また、ＳＩＰ呼制御部２０は、次の送信先のＳＩＰサーバが通信不可能であると判定した場合又は次の送信先のＳＩＰサーバに該当セッション通信のセッションリソースが存在しない場合に、通信不可能な又は該当セッション通信のセッションリソースが存在しないＳＩＰサーバ以降のＳＩＰサーバのうちいずれか一つを選択してリクエストメッセージを送信するようにしてもよい。

ＳＩＰヘッダ制御部３０は、ＳＩＰ呼制御部２０からの指示に基づいて、ＳＩＰメッセージのヘッダの生成や削除などの編集を行なうＳＩＰに対応したヘッダ制御を行なう処理部である。このＳＩＰヘッダ制御部３０は、本発明に関連する機能としては、ＳＩＰ呼制御部２０からの指示に基づいて、リクエストメッセージのRouteヘッダに設定されている送信経路から、次の送信先のＳＩＰサーバを示す情報を削除する。

このように、ＳＩＰ呼制御部２０が、次の送信先のＳＩＰサーバが通信不可能であると判定した場合又は次の送信先のＳＩＰサーバに該当セッション通信のセッションリソースが存在しない場合に、ＳＩＰヘッダ制御部３０に指示して、リクエストメッセージのRouteヘッダに設定されている送信経路から、当該ＳＩＰサーバを示す情報を削除することによって、障害が発生している又は該当セッション通信のセッションリソースが存在しないＳＩＰサーバを経由しない迂回経路を設定して、リクエストメッセージを送信することができる。

コールデータ管理部４０は、対向サーバとの間の通信状態及び対向サーバのセッション通信毎の迂回要否情報を管理する処理部である。このコールデータ管理部４０は、常時、対向サーバとの間で通信が可能であるか否か及び対向サーバが特定セッション通信中の状態で障害を経験した場合における特定セッション通信のセッションリソースが存在するか否かを確認し、確認した結果に基づいて生成した通信状態情報及び迂回要否情報を、例えば、図３には図示していないメモリなどに格納する。なお、対向サーバにおけるセッションリソースが存在しないことが確認されたセッション通信については、当該セッション通信が終了するまで、当該対向サーバをスキップの対象とする情報を迂回要否情報として格納する。また、コールデータ管理部４０は、後述する迂回制御部５０から対向サーバの通信状態及び迂回要否を確認するための問い合わせを受け付けた場合には、通信状態情報及び迂回要否情報を参照して、指定された対向サーバの通信状態及び迂回要否を確認し、確認結果を迂回制御部５０に対して通知する。

迂回制御部５０は、リクエストメッセージが送信される際に、次の送信先に指定されているＳＩＰサーバをスキップするか否かを判定する処理部である。具体的には、この迂回制御部５０は、ＳＩＰ信号のルーチング時に、ＳＩＰ呼制御部２０からの問い合わせに応じて、コールデータ管理部４０に問い合わせることにより、リクエストメッセージの次の送信先のＳＩＰサーバが通信可能な状態であるか否かを確認し、通信が可能な状態でなかった場合には、ＳＩＰ呼制御部２０に対して、当該ＳＩＰサーバをスキップするように指示する。また、次の送信先のＳＩＰサーバの通信が可能な状態であれば、この迂回制御部５０は、ＳＩＰ信号のルーチング時に、ＳＩＰ呼制御部２０からの問い合わせに応じて、コールデータ管理部４０に問い合わせることにより、対向サーバをスキップする必要があるか否かを確認し、スキップが必要であった場合には、ＳＩＰ呼制御部２０に対して、当該セッション通信については、当該ＳＩＰサーバをスキップするように指示し、スキップが必要でなかった場合には、ＳＩＰ呼制御部２０に対して、当該セッション通信については、当該ＳＩＰサーバをスキップしないように指示する。

次に、本実施例に係るＳＩＰサーバの処理手順について説明する。以下では、図２に示した手順でＵＡＣとＵＡＳとの間でセッション通信が開始された後に、ＳＩＰサーバＭに障害が発生した場合に、その後において想定されるいくつかの状態を例にあげて説明する。

まず、ＳＩＰサーバＭに障害が発生した後に、その障害がセッションリソースの開放を伴い復旧し、その復旧をＳＩＰサーバＹが検知していた場合について図４及び図５を用いて説明する。図４に示すように、ＵＡＣとＵＡＳとがセッション通信中の状態でＳＩＰサーバＭに障害が発生し（ステップＳ２０１）、その後に障害がセッションリソースの開放を伴い復旧し、この障害のセッションリソースの開放を伴う復旧をＳＩＰサーバＹが検知していたとする（ステップＳ２０２）。

この状態で、例えば、図４に示すように、ＵＡＳがｒｅ−ＩＮＶＩＴＥリクエストを送信した場合を考える。ＵＡＳは、ルートセットに基づいて、Request-URIヘッダ及びRouteヘッダに「ＲＵＲＩ：ＵＡＣ」及び「Ｒ：Ｙ，Ｍ，Ｂ（ＳＩＰサーバＹ、ＳＩＰサーバＭ、ＳＩＰサーバＢの順で転送することを示す送信経路）」をそれぞれ設定したうえで、Routeヘッダに設定した送信経路に基づいて、当該ｒｅ−ＩＮＶＩＴＥリクエストをＳＩＰサーバＹに送信する（ステップＳ２０３）。

ＳＩＰサーバＹでは、ＳＩＰ通信制御部１０が当該ｒｅ−ＩＮＶＩＴＥリクエストを受信し（図５の矢印１）、ＳＩＰ呼制御部２０が、Routeヘッダに基づいて当該ｒｅ−ＩＮＶＩＴＥリクエストの次の送信先を取得する（図５の矢印２）。ここでは、ＳＩＰ通信制御部１０は、次の送信先としてＳＩＰサーバＭを取得する。そして、ＳＩＰ呼制御部２０は、取得した送信先（ＳＩＰサーバＭ）をスキップするか否かを迂回制御部５０に問い合わせる（図５の矢印３）。

迂回制御部５０は、ＳＩＰサーバＭが通信可能か否か、ＳＩＰサーバＭをスキップする必要があるか否かをコールデータ管理部４０に問い合わせる（図５の矢印４）。ここでは、ＳＩＰサーバＭの障害がすでに復旧しているが、セッションリソースの開放を伴い復旧していることが検知されているため、コールデータ管理部４０からは、ＳＩＰサーバＭが通信可能であるが、ＳＩＰサーバＭをスキップする必要があることが通知される（図５の矢印５）。この通知を受け、迂回制御部５０は、ＳＩＰ呼制御部２０に対し、ＳＩＰサーバＭをスキップするように指示する（図５の矢印６）。

迂回制御部５０からの指示を受け、ＳＩＰ呼制御部２０は、ＳＩＰヘッダ制御部３０に指示して（図５の矢印７）、当該ｒｅ−ＩＮＶＩＴＥリクエストのRouteヘッダに設定されている送信経路からＳＩＰサーバＭを示す情報を削除する（図５の矢印８）。これにより、このｒｅ−ＩＮＶＩＴＥリクエストの次の送信先はＳＩＰサーバＢとなる。そして、ＳＩＰ呼制御部２０は、ＳＩＰ通信制御部１０を介して（図５の矢印９）、ＳＩＰサーバＢに対してRouteヘッダ編集後のｒｅ−ＩＮＶＩＴＥリクエストを送信する（図５の矢印１０、ステップＳ２０４）。

そして、ＳＩＰサーバＹから送信されたｒｅ−ＩＮＶＩＴＥリクエストは、Routeヘッダに設定された送信経路に従って、ＳＩＰサーバＢに転送され、さらに、ＳＩＰサーバＢからＵＡＣに転送される（ステップＳ２０５）。

このように、ＳＩＰサーバＭに障害が発生した後に、その障害がセッションリソースの開放を伴い復旧し、その復旧をＳＩＰサーバＹが検知していた場合には、ＳＩＰサーバＹにおいて、迂回制御部５０が、コールデータ管理部４０に問い合わせることによって、ＳＩＰサーバＭが通信可能であるが、ＳＩＰサーバＭをスキップする必要があることを確認し、ＳＩＰ呼制御部２０が、ＳＩＰサーバＭをスキップして、その次の送信先であるＳＩＰサーバＢに対してｒｅ−ＩＮＶＩＴＥリクエストを送信するので、ＵＡＣとＵＡＳとの間のセッション通信を継続させることができる。

次に、ＳＩＰサーバＭに障害が発生した後に、その障害が復旧し、その障害及び復旧をＳＩＰサーバＹが検知していなかった場合について図５及び図６を用いて説明する。図６に示すように、ＵＡＣとＵＡＳとがセッション通信中の状態でＳＩＰサーバＭに障害が発生した後に、その障害が復旧し、その障害及び復旧をＳＩＰサーバＹが検知していなかったとする。

この状態で、例えば、図６に示すように、ＵＡＳがｒｅ−ＩＮＶＩＴＥリクエストを送信した場合を考える。ＵＡＳは、ルートセットに基づいて、Request-URIヘッダ及びRouteヘッダに「ＲＵＲＩ：ＵＡＣ」及び「Ｒ：Ｙ，Ｍ，Ｂ（ＳＩＰサーバＹ、ＳＩＰサーバＭ、ＳＩＰサーバＢの順で転送することを示す送信経路）」をそれぞれ設定したうえで、Routeヘッダに設定した送信経路に基づいて、当該ｒｅ−ＩＮＶＩＴＥリクエストをＳＩＰサーバＹに送信する（ステップＳ３０１）。

迂回制御部５０は、ＳＩＰサーバＭが通信可能か否か、及びＳＩＰサーバＭをスキップする必要があるか否かをコールデータ管理部４０に問い合わせる（図５の矢印４）。ここでは、ＳＩＰサーバＭの障害及び復旧が検知されていないため、コールデータ管理部４０からは、ＳＩＰサーバＭが通信可能であり、ＳＩＰサーバＭをスキップする必要がないことが通知される（図５の矢印５）。この通知を受け、迂回制御部５０は、ＳＩＰ呼制御部２０に対し、ＳＩＰサーバＭをスキップしないように指示する（図５の矢印６）。

迂回制御部５０からの指示を受け、ＳＩＰ呼制御部２０は、Routeヘッダに設定されている送信経路は変えずに、当該ｒｅ−ＩＮＶＩＴＥリクエストを送信する。これにより、このｒｅ−ＩＮＶＩＴＥリクエストの次の送信先は受信した時と変わらず、ＳＩＰサーバＭとなる。そして、ＳＩＰ呼制御部２０は、ＳＩＰ通信制御部１０を介して（図５の矢印９）、ＳＩＰサーバＭに対してｒｅ−ＩＮＶＩＴＥリクエストを送信する（図５の矢印１０、ステップＳ３０２）。

ここで、実際には、障害によりＳＩＰサーバＭのサービスが停止した後に、その障害がセッションリソースの開放を伴い復旧しており、そのため、ＳＩＰサーバＭからＳＩＰサーバＹに対して該当セッション通信が存在しないことを示す応答コード（例えば、「481 Call/Transaction Does Not Exist」）を含むレスポンスメッセージが返送されたとする（ステップＳ３０３）。

この場合、ＳＩＰサーバＹでは、ＳＩＰ通信制御部１０が当該レスポンスメッセージを受信し（図５の矢印１）、ＳＩＰ呼制御部２０を介して（図５の矢印２）、そのレスポンスメッセージを迂回制御５０に送信する（図５の矢印３）。

迂回制御部５０は、そのレスポンスメッセージに基づいてサーバＭが通信可能であるが、ＳＩＰサーバＭにこのセッション通信のセッションリソースが存在しないと判断し、当該セッション通信については、当該セッション通信が終了するまで当該ＳＩＰサーバをスキップする必要があると判定する。この判定結果を迂回要否情報として、コールデータ管理部４０に記憶させる（図５の矢印４）と共に、ＳＩＰ呼制御部２０に対して、当該ＳＩＰサーバをスキップするように指示する（図５の矢印６）。

ＳＩＰ呼制御部２０は、ＳＩＰヘッダ制御部３０に指示して（図５の矢印７）、当該ｒｅ−ＩＮＶＩＴＥリクエストのRouteヘッダに設定されている送信経路からＳＩＰサーバＭを示す情報を削除する（図５の矢印８）。これにより、このｒｅ−ＩＮＶＩＴＥリクエストの次の送信先はＳＩＰサーバＢとなる。そして、ＳＩＰ呼制御部２０は、ＳＩＰ通信制御部１０を介して（図５の矢印９）、ＳＩＰサーバＢに対してRouteヘッダ編集後のｒｅ−ＩＮＶＩＴＥリクエストを送信する（図５の矢印１０、ステップＳ３０４）。

そして、ＳＩＰサーバＹから送信されたｒｅ−ＩＮＶＩＴＥリクエストは、Routeヘッダに設定された送信経路に従って、ＳＩＰサーバＢに転送され、さらに、ＳＩＰサーバＢからＵＡＣに転送される（ステップＳ３０５）。

このように、ＳＩＰサーバＭに障害が発生した後に、その障害及び復旧をＳＩＰサーバＹが検知していなかった場合には、ＳＩＰサーバＹにおいて、ＳＩＰ呼制御部２０が、ＳＩＰサーバＭに対してｒｅ−ＩＮＶＩＴＥリクエストを送信した後に、そのｒｅ−ＩＮＶＩＴＥリクエストに対するレスポンスメッセージの応答コードを確認して、ＳＩＰサーバＭが通信可能であるか否か、及びＳＩＰサーバＭをスキップする必要があるか否かを判定し、通信可能であるが、ＳＩＰサーバＭをスキップする必要があると判定した場合に、ＳＩＰサーバＭをスキップして、その次の送信先であるＳＩＰサーバＢに対してｒｅ−ＩＮＶＩＴＥリクエストを送信するので、ＵＡＣとＵＡＳとの間のセッション通信を継続させることができる。

上述してきたように、この第１の実施形態では、迂回制御部５０が、コールデータ管理部４０に問い合わせて、リクエストメッセージを次に送信すべきＳＩＰサーバとの間の通信状態及び復旧状態を判定し、次に送信すべきＳＩＰサーバとの間の通信状態又は復旧状態が異常であると判定した場合に、ＳＩＰ呼制御部２０が、リクエストメッセージのヘッダ情報に含まれるＳＩＰサーバの中継順序に係る情報に基づいて、通信状態又は復旧状態が異常であると判定したＳＩＰサーバ以降のＳＩＰサーバをＳＩＰメッセージの送信先として設定するので、セッション通信中の状態で、通信を中継するＳＩＰサーバに障害が発生した場合でも、そのＳＩＰサーバをスキップしてＳＩＰメッセージを送信することが可能になり、ＵＡＣとＵＡＳとの間のセッション通信を継続させることができる。

また、この第１の実施形態では、ＳＩＰ呼制御部２０が、次に送信すべきＳＩＰサーバに対してＳＩＰメッセージを送信し、送信したＳＩＰメッセージに応じて返送されるレスポンスメッセージに基づいて、次に送信すべきＳＩＰサーバとの間の通信状態及び復旧状態を判定するので、通信状態及び復旧状態の内容に応じて、より詳細な条件で通信状態を切り分けて、次に送信すべきＳＩＰサーバをスキップするか否かを判定することができる。

また、この第１の実施形態では、ＳＩＰ呼制御部２０が、レスポンスメッセージに含まれるＳＩＰサーバの状態を示す応答コードに基づいて、通信状態及び復旧状態を判定するので、輻輳などにより一時的にサービスが停止しているＳＩＰサーバがあった場合でも、そのＳＩＰサーバをスキップしてＳＩＰメッセージを送信することが可能になり、ＵＡＣとＵＡＳとの間のセッション通信を継続させることができる。

また、この第１の実施形態では、迂回制御部５０が、次に送信すべきＳＩＰサーバとの間の通信状態又は復旧状態が異常であると判定した場合に、ＳＩＰ呼制御部２０が、ＳＩＰヘッダ制御部３０に指示して、ＳＩＰメッセージに含まれるＲｏｕｔｅヘッダに設定された次に送信すべきＳＩＰサーバに係る情報を削除することにより、ＳＩＰメッセージの送信先を設定するので、ＳＩＰで定義されているヘッダ情報のデータ構造を変えずに、障害が発生している対向サーバをスキップしてＳＩＰメッセージを送信することが可能になり、ＵＡＣとＵＡＳとの間のセッション通信を継続させることができる。

なお、ここではｒｅ−ＩＮＶＩＴＥリクエストを例にとって説明したが、本発明はこれに限られず、ＢＹＥリクエストなど、セッション通信開始後に送信される他のリクエストメッセージについても同様に適用することができる。

（本発明の第２の実施形態）
図７はこの第２の実施形態に係るＳＩＰサーバの構成を示す機能ブロック図、図８は入力装置を使用して迂回要否情報を設定した場合のこの第２の実施形態に係るＳＩＰサーバの処理手順を示すシーケンス図である。図７及び図８において、図１〜図６と同じ符号は、同一または相当部分を示し、その説明を省略する。

迂回設定部６０は、キーボードやマウスなどの入力装置７０を使用して、コマンドなどの外部からの入力信号を受ける図示しない入力インタフェース部を有し、入力装置７０からの入力信号に基づく迂回要否情報をコールデータ管理部４０に設定する。

なお、この第２の実施形態におけるＳＩＰサーバにおいては、迂回設定部６０をさらに備えるところのみが第１の実施形態と異なるところであり、後述する迂回設定部６０による作用効果以外は、第１の実施形態と同様の作用効果を奏する。

この第２の実施形態においては、ＵＡＣとＵＡＳとの間で確立済みのセッション通信が存在しており、当該セッション通信中の状態で通信を中継するサーバに障害が発生し、当該セッション通信中の状態でセッションリソースの開放を伴う当該サーバの復旧を、保守者などの第三者が実施する場合に、図８に示すように、障害が発生したＳＩＰサーバＭの送信元であるＳＩＰサーバＹに対しても、保守者などの第三者が、入力装置７０を使用して、現時点におけるＵＡＣとＵＡＳとの間で通信中である当該セッション通信について当該セッション通信が終了するまでＳＩＰサーバＭをスキップさせる内容の迂回指令を外部から入力する（ステップＳ４０１）。

迂回設定部６０は迂回指令としての外部からの入力信号に基づく迂回要否情報をコールデータ管理部４０に設定し、コールデータ管理部４０は当該セッション通信について当該セッション通信を終了（終話）するまでＳＩＰサーバＭを迂回するように記憶する。

そして、ＳＩＰサーバＭがセッションリソースの開放を伴う復旧などがなされると、前述した第１の実施形態における図４に示したステップＳ２０３〜ステップＳ２０５と同様（図８においては、ステップＳ４０２〜ステップＳ４０４）に、コールデータ管理部４０に格納された迂回要否情報に基づき、当該セッション通信については、当該セッション通信が終了するまでＳＩＰサーバＭをスキップさせることができる。

なお、送信元のＳＩＰサーバＹから当該セッション通信におけるリクエストメッセージをＳＩＰサーバＭに対して送信する前に予め、入力装置７０からの入力信号に基づく迂回要否情報をコールデータ管理部４０に設定することで、前述した第１の実施形態における図６に示したステップＳ３０２及びステップＳ３０３である、送信元のＳＩＰサーバＹから送信したリクエストメッセージに対する送信先のＳＩＰサーバＭからのレスポンスメッセージに基づき、ＳＩＰサーバＭをスキップする必要があると判定していた処理を削除することができる。
付記上記実施形態に関し、更に以下の付記を開示する。

（付記１）
複数の中継サーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルを使用するＳＩＰサーバにおいて、ＳＩＰに準拠したＳＩＰメッセージの送受信を制御するＳＩＰ通信制御部と、前記ＳＩＰを用いた呼制御を行なうＳＩＰ呼制御部と、対向サーバとの間の通信状態の結果である通信状態情報、及び対向サーバの復旧状態の結果から当該対向サーバをスキップする必要性をセッション通信毎に判定した結果である迂回要否情報を管理するコールデータ管理部と、次の送信先に設定されている対向サーバの前記通信状態情報及び迂回要否情報に基づき、当該対向サーバに対してセッション通信毎に前記ＳＩＰメッセージをスキップさせるか否かを判定する迂回制御部と、前記迂回制御部による判定に基づき、前記ＳＩＰメッセージのルートヘッダの編集を行なうＳＩＰヘッダ制御部と、を備えていることを特徴とするＳＩＰサーバ。

（付記２）
前記ＳＩＰヘッダ制御部は、セッション通信中の状態で対向サーバに障害が発生し、当該セッション通信中の状態で当該対向サーバのセッションリソースが開放されて当該対向サーバが復旧した場合に、当該セッション通信におけるＳＩＰメッセージのルートヘッダに設定されている送信経路から、当該セッションリソースが開放されて復旧した対向サーバを示す情報を削除することを特徴するＳＩＰサーバ。

（付記３）
前記迂回制御部は、セッションリソースが開放されて復旧した対向サーバから送信される、該当セッション通信が存在しないことを示す応答コードが設定されたレスポンスメッセージに基づき、当該対向サーバに対して当該セッション通信における前記ＳＩＰメッセージをスキップさせる必要があると判定すると共に、当該セッション通信について当該セッション通信が終了するまで当該対向サーバをスキップさせるように、前記迂回要否情報として前記コールデータ管理部に格納させることを特徴とするＳＩＰサーバ。

（付記４）
入力装置からの入力信号を受ける入力インタフェース部を有する迂回設定部を備え、前記迂回設定部は、前記入力装置からの入力信号に基づく前記迂回要否情報を前記コールデータ管理部に設定することを特徴とするＳＩＰサーバ。

この第１の実施形態に係るＳＩＰサーバの概念を説明するための説明図である。ＳＩＰによるメッセージの送信経路設定を説明するための説明図である。この第１の実施形態に係るＳＩＰサーバの構成を示す機能ブロック図である。ＳＩＰサーバが障害の復旧を検知していた場合のこの第１の実施形態に係るＳＩＰサーバの処理手順を示すシーケンス図である。図１に示すＳＩＰサーバの迂回制御手順を説明するための機能ブロック図である。ＳＩＰサーバが障害及び復旧を検知していなかった場合のこの第１の実施形態に係るＳＩＰサーバの処理手順を示すシーケンス図である。この第２の実施形態に係るＳＩＰサーバの構成を示す機能ブロック図である。入力装置を使用して迂回要否情報を設定した場合のこの第２の実施形態に係るＳＩＰサーバの処理手順を示すシーケンス図である。従来の送信経路設定装置の問題点を説明する説明図である。

符号の説明

１，２，３ＩＰネットワーク
１０ＳＩＰ通信制御部
２０ＳＩＰ呼制御部
３０ＳＩＰヘッダ制御部
４０コールデータ管理部
５０迂回制御部
６０迂回設定部
７０入力装置
２００ＳＩＰサーバ
２００ＡＳＩＰサーバＡ
２００ＢＳＩＰサーバＢ
２００ＭＳＩＰサーバＭ
２００ＮＳＩＰサーバＮ
２００ＸＳＩＰサーバＸ
２００ＹＳＩＰサーバＹ
３００ａ発端末
３００ｂ着端末

Claims

複数の中継サーバを経由するＩＰネットワーク上で端末間のマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルを使用するＳＩＰサーバにおいて、
ＳＩＰに準拠したＳＩＰメッセージの送受信を制御するＳＩＰ通信制御部と、
前記ＳＩＰを用いた呼制御を行なうＳＩＰ呼制御部と、
対向サーバとの間の通信状態の結果である通信状態情報、及び対向サーバの復旧状態の結果から当該対向サーバをスキップする必要性をセッション通信毎に判定した結果である迂回要否情報を管理するコールデータ管理部と、
次の送信先に設定されている対向サーバの前記通信状態情報及び迂回要否情報に基づき、当該対向サーバに対してセッション通信毎に前記ＳＩＰメッセージをスキップさせるか否かを判定する迂回制御部と、
前記迂回制御部による判定に基づき、前記ＳＩＰメッセージのルートヘッダの編集を行なうＳＩＰヘッダ制御部と、
を備え、
前記迂回制御部は、前記通信状態情報が次の送信先に設定されている対向サーバが通信不可能である旨の情報である場合に、当該対向サーバに対して前記ＳＩＰメッセージをスキップさせるように判定すると共に、前記迂回要否情報が次の送信先に設定されている対向サーバが復旧して通信可能であるが当該対向サーバにセッション通信のセッションリソースが存在しないため当該対向サーバをスキップする必要がある旨の情報である場合に、当該対向サーバに対して当該セッション通信における前記ＳＩＰメッセージをスキップさせるように判定することを特徴とするＳＩＰサーバ。
前記請求項１に記載のＳＩＰサーバにおいて、
前記端末により生成されたルートセットに基づいてセッション通信におけるＳＩＰメッセージのルートヘッダに設定されている送信経路は、当該セッション通信中の状態で対向サーバに障害が発生して当該対向サーバのセッションリソースが開放された際に、維持されており、
前記ＳＩＰヘッダ制御部は、セッション通信中の状態で対向サーバに障害が発生し、当該セッション通信中の状態で当該対向サーバのセッションリソースが開放されて当該対向サーバが復旧した場合に、前記端末により生成されたルートセットに基づいて当該セッション通信におけるＳＩＰメッセージのルートヘッダに設定されている送信経路から、当該セッションリソースが開放されて復旧した対向サーバを示す情報を削除することを特徴するＳＩＰサーバ。
前記請求項１又は２に記載のＳＩＰサーバにおいて、
前記端末により生成されたルートセットに基づいてセッション通信におけるＳＩＰメッセージのルートヘッダに設定されている送信経路は、当該セッション通信中の状態で対向サーバに障害が発生して当該対向サーバのセッションリソースが開放された際に、維持されており、
前記迂回制御部は、セッションリソースが開放されて復旧した対向サーバから送信される、該当セッション通信が存在しないことを示す応答コードが設定されたレスポンスメッセージに基づき、当該対向サーバに対して当該セッション通信における前記ＳＩＰメッセージをスキップさせる必要があると判定すると共に、当該セッション通信について当該セッション通信が終了するまで当該対向サーバをスキップさせるように、前記迂回要否情報として前記コールデータ管理部に格納させることを特徴とするＳＩＰサーバ。
前記請求項１又は２に記載のＳＩＰサーバにおいて、
入力装置からの入力信号を受ける入力インタフェース部を有する迂回設定部を備え、
前記迂回設定部は、前記入力装置からの入力信号に基づく前記迂回要否情報を前記コールデータ管理部に設定することを特徴とするＳＩＰサーバ。