JP4470934B2 - プロキシ・サーバ、通信システム、通信方法及びプログラム - Google Patents

Description

本発明は、ＳＩＰ（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ）を使用してシグナリングを行う通信網に好適に利用されるプロキシ・サーバ、通信システム、通信方法及びプログラムに関する。

近年、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ＩＰ）に見られるように、ＩＰ網を使用したリアルタイム・コミュニケーションが普及している。例えば、電話端末やパソコンなどの、リアルタイム・コミュニケーションを行う両端の端末間接続を確立する国際標準プロトコルとしてＳＩＰ（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ）を採用する状況が多くなっている。なお、本明細書では、ＳＩＰを使用してシグナリングを行う通信網をＳＩＰネットワークと呼ぶ。

ＳＩＰネットワークの一般的な構成は、非特許文献１に記載されている。ＳＩＰネットワークは、ロケーション・サーバと、ＳＩＰサーバと、ユーザ・エージェント（ＵＡ： ｕｓｅｒ ａｇｅｎｔ）とから構成されている。ユーザ・エージェントは、非特許文献１（後述）のＰ．７６に、「ＳＩＰは、エンド・システム間のクライアント−サーバ・モデルに基づいています。このエンド・システムに相当するのが、ユーザ・エージェント（ＵＡ： Ｕｓｅｒ Ａｇｅｎｔ）です。ユーザ・エージェントとは、具体的には電話機やパソコンなどのエンド・システムのことですが、これらのエンド・システム間でリクエスト（要求）とレスポンス（応答）をやり取りすることによって、サービスを実現します」と説明されている。本明細書では、上記説明文記載のリクエストをＳＩＰ要求、レスポンスをＳＩＰ応答と呼ぶ。

ＳＩＰサーバは、非特許文献１のＰ．７７に記載されているように、（１） ＳＩＰ要求やＳＩＰ応答を中継するプロキシ・サーバ機能と、（２） ＳＩＰ要求の宛先の問合せに利用するリダイレクト・サーバ機能と、（３） ＳＩＰネットワーク上のユーザ・エージェント情報の登録を受け付ける登録サーバ機能とを有する。ここで、ユーザ・エージェント情報とは、例えば、ユーザ・エージェントにアクセスするための識別子であるＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）やユーザ・エージェントが使用するＩＰアドレスである。なお、本明細書では、ユーザ・エージェントによってＳＩＰサーバに登録されたユーザ・エージェント情報を登録情報と呼ぶ。この登録情報は、ＳＩＰ要求のＲＥＧＩＳＴＥＲリクエストを用いて更新される。

一般的なＳＩＰネットワークにおいて、ユーザ・エージェント間で通信する場合の動作シーケンスを図１２に示す。この図では、非特許文献２（後述）に記載されているように、一般的な情報通信事業者がＳＩＰネットワークを構築する場合に採用するユーザ・エージェントの認証方式（ダイジェスト認証）を含んだものである。

まず、ユーザ・エージェント（発呼側）がＳＩＰサーバに対してＩＮＶＩＴＥリクエストを送信する。本明細書では、このユーザ・エージェント（発呼側）が最初にＳＩＰサーバに送信するＩＮＶＩＴＥリクエストをｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストと呼ぶ。

ユーザ・エージェント（発呼側）からのｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを受信したＳＩＰサーバは、ダイジェスト認証で使用するｎｏｎｃｅを算出し、そのｎｏｎｃｅ値をＳＩＰ応答（４０７ ｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｉｒｅｄ）に付加してユーザ・エージェント（発呼側）に返信する。ユーザ・エージェント（発呼側）では、受信したｎｏｎｃｅを鍵にシークレット（ユーザ識別子とパスワード）をハッシュする。この結果をＩＮＶＩＴＥリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに格納し、ＳＩＰサーバに転送する。本明細書では、このＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを付加したＩＮＶＩＴＥリクエストを認証ＩＮＶＩＴＥリクエストと呼ぶ。

認証ＩＮＶＩＴＥリクエストを受信したＳＩＰサーバは、ユーザ・エージェント（発呼側）の認証処理を行う。具体的には、（１） ユーザ・エージェント（発呼側）と同様、自身が生成したｎｏｎｃｅ値を使用して、ユーザ・エージェント（発呼側）のユーザ識別子とパスワードをハッシュする。（２） ユーザ・エージェント（発呼側）からの認証ＩＮＶＩＴＥリクエストに格納されたＡｕｔｈｏｒｉｚａｔｉｏｎヘッダ値と比較し、同一の場合には、正当なユーザ・エージェントからの認証ＩＮＶＩＴＥリクエストであると判断する。

ＳＩＰサーバは、この認証処理の結果、正当なユーザ・エージェントからの認証ＩＮＶＩＴＥリクエストと判断した場合は、認証ＩＮＶＩＴＥリクエストをＴｏフィールドで指定された着呼側のユーザ・エージェント（図１２でのユーザ・エージェント（着呼側））へ転送する。

その後、ユーザ・エージェント（着呼側）では、認証ＩＮＶＩＴＥリクエスト受信後、その認証ＩＮＶＩＴＥリクエストの処理を継続中であることを示す暫定応答（図１２での１００ ｔｒｙｉｎｇと１８０ Ｒｉｎｇｉｎｇ）をＳＩＰサーバに返し、通話者を呼び出す。

通話者が応答した場合に、ユーザ・エージェント（着呼側）はＳＩＰサーバに、認証ＩＮＶＩＴＥリクエストの処理が完了した旨を示すＳＩＰ応答（２００ ＯＫ）を返す。ユーザ・エージェント（発呼側）は、認証ＩＮＶＩＴＥリクエストの最終応答であるＳＩＰ応答（２００ ＯＫ）を受信した旨をユーザ・エージェント（着呼側）に伝達するためにＡＣＫリクエストを発信する。これにより、ユーザ・エージェント（発呼側）とユーザ・エージェント（着呼側）での通話のためのセッションが確立される。通話終了時には、通話終了を希望するユーザ・エージェント（図１２ではユーザ・エージェント（発呼側））から、セッションを終了するＢＹＥリクエストが発行される。ＳＩＰサーバ経由でＢＹＥリクエストを受信したユーザ・エージェント（着呼側）では、ＢＹＥリクエスト処理後、ＳＩＰ応答（２００ ＯＫ）を返答することで、セッションの終了処理が完了したことを伝達する。この結果、ユーザ・エージェント（発呼側）とユーザ・エージェント（着呼側）の通話が終了する。

なお、この図１２に示した、ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストからＢＹＥリクエストの処理完了を示すＳＩＰ応答（２００ ＯＫ）までの一連の流れは、一般的に「コールフロー（呼び出しの流れ）」と呼ばれ、ＳＩＰ要求およびＳＩＰ応答に格納されるＣａｌｌ−ＩＤヘッダの値で識別される。つまり、図１２で示した全てのＳＩＰ要求とＳＩＰ応答は同一のＣａｌｌ−ＩＤヘッダ値を保持することになる。さらに、一般的な情報通信事業者では、通話の課金のために、誰と誰が話中なのかを管理する必要がある。そのため、ＳＩＰサーバは、発生した呼がコールフローにおけるどの状態かを管理するコール・ステートフル・プロキシとして実現される。この結果、図１２に示すように、コールフロー中のＳＩＰ要求およびＳＩＰ応答は全て同一のＳＩＰサーバを経由する形態となる。

上述したＳＩＰサーバにおける呼の状態など、クライアントから送信される一連のリクエストの処理状態を管理するサーバの高可用性を実現するために、サーバでの処理内容を、サーバの障害時に他サーバで引き継ぐ手段としては、特開２００４−２８０７３８（特許文献１）で示される手段がある。以降では、この従来技術の１例である特許文献１に関して図表を参照して詳細に説明する。なお、従来技術を示す図に記載された各構成要素を指す符号は、本願明細書に示す各構成要素を指す符号とは異なるものである。

図１３は、特許文献１で示される代理応答装置の構成を示す図である。図１３において、特許文献１で示される代理応答装置は、複数サーバの障害発生を監視し、あるサーバに障害が発生した場合には、他のサーバに、障害が発生したサーバの処理を引き継ぐ機能を提供している。この機能を実現するために、代理応答装置は以下に示す手段を有すると説明されている。

「本発明の代理応答装置は、障害発生を監視する監視対象サーバと上記監視対象サーバの代りに応答できる予備サーバのアドレスを保持し、上記監視対象サーバが送受信するメッセージを通信ネットワークから取得する手段と、上記監視対象サーバの障害を検知する手段と、上記監視対象サーバの障害を検知した際には、上記取得したクライアントからの要求のメッセージのうち応答していないメッセージについて、送信元アドレスを上記代理応答装置のアドレスに書き換え、上記予備サーバに送信する手段を有し、上記予備サーバからの応答メッセージの送信元アドレスを上記監視対象サーバのアドレスに書き換えクライアントに中継する手段を有する。」（特許文献１の段落００１２を引用）。

このような代理応答装置を実現する情報処理装置のハードウェア構成を図１４に示す。図１４において、この構成は下記のように説明されている。

「代理応答装置１を実現する情報処理装置は、プロセッサ１００と、記憶装置１０８と、ＩＰ網６ｂに接続するための入力回路インタフェイス１０５および出力回路インタフェイス１０７と、入力回路インタフェイス１０５で受信されたＩＰパケットを一時的に蓄積するための受信バッファ１０４と、出力回路インタフェイス１０７で送信すべきＩＰパケットを一時的に蓄積するための送信バッファ１０６と、これらを接続するバスなどの内部通信線からなる。記憶装置１０８は、プログラムメモリ１０１と、パケットバッファ１０２と、サーバ管理表１０３を格納している。プログラムメモリ１０１には、プロセッサ１００が実行し、代理応答装置１を実現する各種制御プログラムが記録され、パケットバッファ１０２には、クライアント３とサーバ２ａ、２ｂがやりとりするＩＰパケットが蓄積される。記憶装置１０８は、半導体記憶装置、または、ハードディスクなどの外部記憶装置で構成する。」（特許文献１の段落００１９を引用）。

また、このような構成の代理応答装置は、障害が発生したサーバの処理内容を他サーバに引き継がせるために、下記のパケットバッファの管理機能を導入することによってサーバの処理状況を把握しており、以下のように説明されている。

「代理応答装置１は、クライアント３とサーバ２ａ、２ｂでやりとりされるメッセージを管理するためのパケットバッファ１０２を備え、クライアント３が送信した要求のメッセージとそれに対応するサーバ２ａ、２ｂの応答のメッセージをまとめて一つの単位（以下、セッションと呼ぶ）として管理する。セッションは、パケットバッファ１０２のセッション管理エントリ１１０−１、１１０−２、・・・に登録される。」（特許文献１の段落００２２を引用）。

このパケットバッファの構成例は、図１５のようになっており、下記のように説明されている。

「パケットバッファ１０２の各エントリは、セッション識別子１１１、クライアントアドレス１１２、サーバアドレス１１３、クライアント送信パケットバッファ１１４、サーバ送信パケットバッファ１１５とからなる。セッション識別子１１１には、各エントリを識別するために、一意な識別子を与えられる。クライアントアドレス１１２には、要求を送信したクライアント３のＩＰアドレスが設定される。サーバアドレス１１３には、上記要求を受信したサーバ２ａのＩＰアドレスが設定される。クライアント送信パケットバッファ１１４には、クライアント３がサーバ２ａに送信したすべてのＩＰパケットがそのまま格納される。サーバ送信パケットバッファ１１５には、サーバ２ａがクライアント３に送信したすべてのＩＰパケットがそのまま格納される。」（特許文献１の段落００２４、００２５を引用）

次に、代理応答装置の動作を図表を参照して詳細に説明する。

図１６は、代理応答装置の動作を示すフローチャートである。この動作は、以下のように説明されている。

「代理応答装置１が接続するＩＰ網６ｂに流れるすべてのＩＰパケットが、入力回路インタフェイス１０５により取得され、受信バッファ１０４に格納される。プロセッサ１００は、受信バッファ１０４に上記ＩＰパケットがあれば、一つ取得し（ステップ１７０）、取得したＩＰパケットが監視対象のサーバ２ａに関係するか否かを、上記ＩＰパケットの送信元アドレス１５０または送信先アドレス１５１が、サーバ管理表１０３の監視対象サーバアドレス１２１に一致しているかで判定する。もし、ステップ１７０で受信バッファ１０４からＩＰパケットを取得しなかった場合は、ステップ１７５に進む（ステップ１７１）。一致している場合プロセッサ１００は、上記ＩＰパケットのパケット種別１５３が切断要求か判定し（ステップ１７２）、切断要求でないなら上記ＩＰパケットをパケットバッファ１０２の該当するエントリに格納する（ステップ１７３）。該当するエントリは、上記ＩＰパケットの送信元アドレス１５０と送信先アドレス１５１の組が、クライアントアドレス１１２とサーバアドレス１１３の組と一致するか（順不同でも一致と見なす）で判定する。格納先は、上記ＩＰパケットの送信先がサーバならクライアント送信パケットバッファ１１４に、上記ＩＰパケットの送信元がサーバならサーバ送信パケットバッファ１１５となる。この際、該当するエントリが無い場合には、新しくエントリを作成する。ステップ１７２にてパケット種別１５３が切断要求の場合には、該当するエントリを削除する（ステップ１７４）。プロセッサ１００は、サーバ管理表１０３の各エントリの監視対象サーバアドレス１２１を持つサーバの障害の有無を判定し（ステップ１７５）、障害が発生している場合には、代理応答処理を実行する（ステップ１７７）。サーバの障害の有無の判定方法は、特に限定されないが、一例としては、パケットバッファ１０２に格納されたすべてのセッションを監視し、サーバから一定時間応答が無いセッションを見つけたら上記サーバに障害が発生したと判定する。他の例としては、サーバで、代理応答装置１に障害がないことを意味するメッセージを送信し続けるプログラムを実行させ、代理応答装置１が上記メッセージを受信できなくなったときに、上記サーバに障害が発生したと判定する。あるセッションにおいて、最初に代理応答処理を行う場合は、受信している全てのＩＰパケットを用いて、障害発生までの処理を実行し、同じ状態を再現する。また、ステップ１７７は一つのＩＰパケット毎に実行され、実行後は、ステップ１７０に戻る。」（特許文献１の段落００３６〜００４２を引用）

このように、従来技術の１例である特許文献１で示される代理応答装置の特徴は、クライアントおよびサーバから送信されるＩＰパケットを全て格納しておき、サーバでの障害発生時には、代理応答装置がクライアントの代わりに、障害発生までのＩＰパケットを、全て、かつ、順番に他サーバに対して送信することで、サーバでの障害発生時と同様の状態を他サーバに再現することである。この手段により、サーバで未完了であったクライアントからのリクエストの処理を、他サーバに引き継ぐのである。

次に、本願発明の技術範囲と同様の電話システムにおいて、サーバの障害発生時に電話の不通状態を回避する従来の方式が特開２００５−２２９２７３（特許文献２）に記載されている。

図１７は、特許文献２に記載のサーババックアップ装置の原理構成を示す図である。このサーババックアップ装置の構成は下記のように説明されている。なお、下記説明における「図１」は、本明細書での「図１７」に相当する。

「図１は本発明のサーババックアップ装置の原理構成ブロック図である。同図はネットワークに接続された複数の電話端末、例えばＩＰ電話端末と、そのネットワークの内部の端末相互間の通話、および外部との通話の切換接続を行うサーバとの間に位置し、そのサーバのバックアップを行うサーババックアップ装置の原理構成を示し、サーババックアップ装置１は、少なくともサーバ障害検出手段２、およびメッセージ転送手段３を備える。サーバ障害検出手段２はサーバの障害を検出するものであり、例えば後述する呼状態管理部とＳＩＰメッセージ読取部に相当する。メッセージ転送手段３は障害の発生期間中にネットワーク内での端末間の通信のために端末側から送られる所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、そのメッセージをサーバを経由することなく相手側端末に直接に転送するものであり、例えばＳＩＰメッセージ書き換え部に相当する。発明の実施の形態においては、バックアップ装置１が複数のＩＰ電話端末のそれぞれに対応して、端末の識別子としてのエンド・ポイント名称とＩＰアドレスとを記憶するエンド・ポイント記憶手段、例えばエンド・ポイント・テーブルをさらに備え、メッセージ転送手段３がエンド・ポイント記憶手段の記憶内容に基いてメッセージの転送を行うこともできる。また所定のメッセージは、相手端末側に呼の確立を要求するために送られるインバイトメッセージであることもできる。また本発明のサーババックアップ装置は、サーバ障害検出手段と、サーバ障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメッセージに対応して該メッセージに対する応答メッセージを生成し、該応答メッセージを前記所定のメッセージの送信元端末に送信するメッセージ生成手段、例えばＳＩＰメッセージ生成部とを備える。実施の形態においては、所定のメッセージは端末側から自端末の登録のために送信されるレジスタメッセージであることもできる。また実施の形態においては、サーババックアップ装置が、同一端末からの前記所定のメッセージの受信回数を記憶する所定メッセージ受信回数記憶手段、例えばアクティブ・コール・テーブルをさらに備え、前記サーバ障害検出手段が、該記憶されたメッセージの受信回数があらかじめ定められた数を超えたとき、前記サーバの障害を検出することもできる。」（特許文献２の段落００１０〜００１４を引用）。

さらに、特許文献２に記載のサーババックアップ装置を含むシステム全体の構成図を図１８に示す。なお、これまで記載してきたサーバは、図１８におけるＩＰセントレックスサーバ（ＩＰ Ｃｅｎｔｒｅｘ Ｓｅｒｖｅｒ）に相当する。図１８に示すように、ＩＰセントレックスサーバの予備系は明示されておらず、ＩＰセントレックスサーバの障害発生時には、サーババックアップ装置がユーザ・エージェントからのシグナリングを全て賄う形態となっている。つまり、サーババックアップ装置が、発呼側ユーザ・エージェントからのＳＩＰ要求を着呼側ユーザ・エージェントへ転送するのである。そこで、サーババックアップ装置での実施の形態では、電話番号などの着呼側ユーザ・エージェントの識別子からＩＰアドレスを決定するために、複数のユーザ・エージェントの各々に対応して、ユーザ・エージェントの識別子であるエンド・ポイント名称とユーザ・エージェントのＩＰアドレスとを記憶するエンド・ポイント記憶手段を保持する形態が採用されている。

次に、特許文献２に記載のサーババックアップ装置の動作を図表を参照して説明する。図１９は、ＩＰセントレックスサーバ正常動作時の動作を、図２０は、ＩＰセントレックスサーバ障害発生時の動作を示す図である。

これらの動作は、特許文献２にて下記のように説明されている。なお、下記引用中の「図４」が本明細書での「図１９」に、「図５」が本明細書での「図２０」に相当する。

「図４は、セントレックスサーバ正常動作時のシステム内動作のさらに詳細な説明図である。ここでは端末１２１からの発呼によって端末１２２との間で通話が行われるものとする。なおここでバックアップ装置１０のＩＰアドレスは１１１．１．１．１０、端末１２１のＩＰアドレスは１１１．１．１．１、端末１２２のＩＰアドレスは１１１．１．１．２、またＩＰセントレックスサーバ１６のＩＰアドレスは１３３．１．１．１とする。図４において、端末１２１から送られる、セッションの確立、維持、終了を行うためのセッション・イニシエーション・プロトコル（ＳＩＰ）メッセージ、例えば後述するレジスタメッセージ、インバイトメッセージなどは、（１）でＬＡＮ１３を介してバックアップ装置１０に至り、バックアップ装置１０からＬＡＮ１３、ルータ１４、ＩＰネットワーク１５を経由してＩＰセントレックスサーバ１６に至る経路によって（２）で転送され、その後（３）でＩＰセントレックスサーバ１６からＩＰネットワーク１５、ルータ１４、ＬＡＮ１３を介してバックアップ装置１０に至る経路によってバックアップ装置１０に転送され、さらにバックアップ装置１０からＬＡＮ１３を介して端末１２２に転送される。なお端末間で呼の接続が完了した後の実際の音声信号、すなわちリアルタイム・トランスポート・プロトコル（ＲＴＰ）によるメディアストリームのやりとりは、バックアップ装置１０を介することなく、ＬＡＮ１３を介して直接に端末間で行われる。ＩＰセントレックスサーバ１６の正常動作時にも、実際の音声信号は同様に端末間で直接にやり取りされる。図５はセントレックスサーバ障害発生時の動作の詳細説明図である。図４におけると同様に、端末１２１からＬＡＮ１３を介して（１）でバックアップ装置１０に対して呼確立のための、例えばインバイトメッセージが転送されると、バックアップ装置１０は後述するようにＩＰセントレックスサーバ１６の障害発生を検出しており、そのためバックアップ装置１０はそのメッセージをＩＰセントレックスサーバ１６側に転送することなく直接に相手側のＩＰ電話端末１２２に（２）で転送し、２つの端末間の通話が可能となる。なお端末間で呼の接続が完了した後の実際の音声信号、すなわちリアルタイム・トランスポート・プロトコルによるメディアストリームのやりとりは、バックアップ装置１０を介することなく、ＬＡＮ１３を介して直接に端末間で行われる。ＩＰセントレックスサーバ１６の正常動作時にも、実際の音声信号は同様に端末間で直接にやり取りされる。」（特許文献２の段落００２２〜００２４を引用）。

このように、特許文献２に記載のサーババックアップ装置では、ＩＰセントレックスサーバでの障害発生時には、エンド・ポイント名称とＩＰアドレスとの情報を参照して、受信したＳＩＰ要求の宛先を変更し、サーババックアップ装置がＳＩＰ要求をユーザ・エージェントに直接転送することで、ＩＰセントレックスサーバの障害による電話の不通状態を回避している。
特開２００４−２８０７３８号公報 特開２００５−２２９２７３号公報 千村保文・村田利文 監修 「改訂版 ＳＩＰ教科書」Ｐ．７７、Ｐ．７８特許出版 ２００４年 社団法人情報通信技術委員会 策定 仕様書番号 ＴＳ−１００６ 「事業者ＳＩＰ網に接続するＳＩＰ端末基本接続インタフェース技術仕様」２００４年

特許文献１に記載の技術を１例とする従来技術における課題は、現用ＳＩＰサーバの障害に遭遇したコールフローを正常に終了できないことである。

その理由は、現用ＳＩＰサーバの障害発生時点の状態を予備ＳＩＰサーバに再現できないためである。

この予備ＳＩＰサーバに現用ＳＩＰサーバの障害発生時点の状態を再現できない従来の場合を具体的に例示する。図２１は、ＳＩＰネットワークに代理応答装置を適用した場合に、予備ＳＩＰサーバで現用ＳＩＰサーバの状態を再現できない従来例を示すシーケンス図である。

この図では、ユーザ・エージェント（着呼側）での認証ＩＮＶＩＴＥリクエスト処理完了を示すＳＩＰ応答（２００ ＯＫ）を、現用ＳＩＰサーバ経由でユーザ・エージェント（発呼側）へ転送した後に、現用ＳＩＰサーバに障害が発生した場合を示している。

この場合、代理応答装置は、予備ＳＩＰサーバに、現用ＳＩＰサーバの状態を再現すべく、ユーザ・エージェント（発呼側）から送信されたｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを予備ＳＩＰサーバに送信する。

すると、予備ＳＩＰサーバでは、新規にｎｏｎｃｅ値を計算し、このｎｏｎｃｅ値を含んだＳＩＰ応答（４０７ ｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｉｒｅｄ）を代理応答装置に送信する。代理応答装置は、ユーザ・エージェント（発呼側）から受信した認証ＩＮＶＩＴＥリクエストを予備ＳＩＰサーバに送信する。

しかし、この認証ＩＮＶＩＴＥリクエストのＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダに格納された値は、現用ＳＩＰサーバが生成したｎｏｎｃｅ値を使用してハッシュされたものであり、予備ＳＩＰサーバが生成したｎｏｎｃｅ値を使用してハッシュしたものとは異なるため、予備ＳＩＰサーバでの認証処理で失敗する。

ユーザ・エージェント（発呼側）のユーザ識別子とパスワードを保持しない代理応答装置が、この状況を回避するためには、ユーザ・エージェント（発呼側）から受信した認証ＩＮＶＩＴＥリクエストのＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダ値を解析し、ユーザ・エージェント（発呼側）のユーザ識別子とパスワードを抽出する必要がある。しかし、これは、ダイジェスト認証を破ることを意味しており、不可能である。

以上の結果、予備ＳＩＰサーバでは、実際には、ユーザ・エージェント（発呼側）とユーザ・エージェント（着呼側）間で通話中であるにも係らず、ユーザ・エージェント（発呼側）とユーザ・エージェント（着呼側）の通話のセッションは確立されていないと認識される。この状態でユーザ・エージェント（発呼側）が通話を終了するＢＹＥリクエストを送信しても、予備ＳＩＰサーバは、終了対象のセッションが存在しないため、ＢＹＥリクエストは実行されない。このように、現用ＳＩＰサーバの障害に遭遇したコールフローは、正常に終了されないのである。

また、特許文献２に記載の技術を１例とする従来技術における第１の課題は、ＩＰセントレックスサーバ障害発生時において、ユーザ・エージェントが発呼した場合、ダイジェスト認証が実施できないことである。

この理由は、図１２に示したように、ダイジェスト認証では、ユーザ・エージェント（発呼側）からのｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストに対し、ＳＩＰサーバでｎｏｎｃｅ値を算出し、その結果を付加したＳＩＰ応答（４０７ ｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｉｒｅｄ）をユーザ・エージェントに返答しなければならないにも係らず、特許文献２に記載のサーババックアップ装置では、ｎｏｎｃｅ値を算出する機能もユーザ・エージェントのユーザ識別子とパスワードを保持する機能も保持していないため、ＳＩＰ応答（４０７ ｐｒｏｘｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｉｒｅｄ）が生成できないためである。

また、特許文献２に記載の技術を１例とする従来技術における第２の課題は、ユーザ・エージェント数増加に対するサーババックアップ装置の対応性が乏しいことである。

この理由は、従来技術は、ユーザ・エージェント（着呼側）のＩＰアドレスを決定するために、サーババックアップ装置自身がユーザ・エージェントの識別子とＩＰアドレスとの情報を保持する形態だからである。この結果、サーババックアップ装置が管理すべきユーザ・エージェント数の増加につれ、この情報を格納しておくためのディスクやメモリ容量の拡張が必要となるのである。

また、特許文献２に記載の技術を１例とする従来技術における第３の課題は、サーババックアップ装置が保持するユーザ・エージェントの識別子とＩＰアドレスとの情報に記載されたユーザ・エージェント以外のユーザ・エージェントに、ＳＩＰ要求を転送できないことである。

この理由は、従来技術は、サーババックアップ装置が保持する情報に基づいて、ＳＩＰ要求の転送先のＩＰアドレスを解決しているためである。なお、この課題は、特許文献２に、「これに対してエンド・ポイント・テーブル２３内のエンド・ポイント・ネームの値と一致しなかった場合には、Ｓｅｒｖｅｒ Ｋｅｅｐ Ａｌｉｖｅの値を参照し、その値が６以上であれば、例えば外部との通話ができないことを示す４０４Ｎｏｔ Ｆｏｕｎｄというコードを生成し、ＳＩＰメッセージの送信元アドレスを送信先アドレスとしてセットし、ＳＩＰメッセージ生成部２６にその送信先アドレス、コード、およびＳＩＰメッセージを渡す。ＳＩＰメッセージ生成部２６により、ＳＩＰメッセージの送信元の端末に、通信相手側端末との接続ができないことを示すメッセージが生成されて送信される。」（特許文献２の段落００５４を引用）と記載がある通り、サーババックアップ装置での解決は図られておらず、ＳＩＰ要求が転送できないことをユーザ・エージェントに通知する方式を採用している。

本発明の目的は、ダイジェスト認証を伴うコールフローが終了前に現用ＳＩＰサーバの障害に遭遇した場合でも、該当コールフローを正常に終了し、かつ、現用ＳＩＰサーバ障害時でも新規発生呼のダイジェスト認証を実施し、かつ、ユーザ・エージェント数の増加に柔軟に対応でき、かつ、ＳＩＰ要求の転送先に制限がない、ＳＩＰネットワークにおけるプロキシ・サーバを提供することである。

特許文献１に記載の技術を１例とする従来技術における第１の課題を解決するために本発明は、ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介するプロキシ・サーバ機能と、プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ種別判定機能と、現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出機能と、転送先障害検出機能からの通知を受信し、プロキシ・サーバ機能が受信したメッセージが、現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定機能と、転送先障害検出機能からの通知を受信し、現用ＳＩＰサーバの障害発生状況に応じて、プロキシ・サーバ機能で受信したメッセージの種類が、ＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、応じてメッセージの転送先を設定する宛先設定機能とを備えることを特徴とする。
すなわち、本発明は、一般的なＳＩＰプロキシ・サーバ機能と、プロキシ・サーバが受信したＳＩＰ要求とＳＩＰ応答が現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判断する機能と、障害に遭遇したコールフローに属すると判断された場合に、受信したＳＩＰ要求とＳＩＰ応答のメッセージ内容を参照して、該当ＳＩＰ要求とＳＩＰ応答が次に送信されるべき宛先を特定する機能とをプロキシ・サーバに保持させる。

これらの機能により、予備ＳＩＰサーバに、現用ＳＩＰサーバの状態を再現せずとも現用ＳＩＰサーバの障害に遭遇したコールフローの処理を継続・終了することが可能となる。これは、通話を行う両端のユーザ・エージェントにＳＩＰ要求およびＳＩＰ応答が規約通りに到着すれば、コールフローの処理が継続可能という、ＳＩＰのプロトコル規約の特性に着目したものである。

特許文献２に記載の技術を１例とする従来技術における第１の課題解決するために本発明は、プロキシ・サーバを含むシステム全体の構成を図１に示す形態とする。すなわち、予備系のＳＩＰサーバ（予備ＳＩＰサーバ４０）を導入し、本願発明のプロキシ・サーバ１０が、現用ＳＩＰサーバ３０の障害時には、ＳＩＰ要求のメッセージの転送先を予備ＳＩＰサーバ４０へ切り替えるのである。さらに、この現用ＳＩＰサーバ３０から予備ＳＩＰサーバ４０へのＳＩＰ要求のメッセージの転送先切り替えを実現するために、プロキシ・サーバ１０に、現用ＳＩＰサーバ３０の障害発生状況に合わせて、ＳＩＰリクエストのメッセージの転送先を決定する機能を導入する。なお、この予備ＳＩＰサーバには新規追加機能は必要なく、従来までのＳＩＰサーバと同様の機能を有する。

この機能により、コールフロー開始のＳＩＰ要求（ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストまたはｉｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエスト）のメッセージが現用ＳＩＰサーバ３０または予備ＳＩＰサーバ４０に転送されるため、図１２に示した、コールフローのシーケンスに沿った通話が実現できるのである。

特許文献２に記載の技術を１例とする従来技術における第２及び第３の課題解決するために本発明は、前述した、受信したＳＩＰ要求とＳＩＰ応答のメッセージの内容を参照し、該当ＳＩＰ要求とＳＩＰ応答のメッセージが次に送信されるべき宛先を特定する機能を備える。

これは、ＳＩＰのプロトコル規約に記載されているように、プロキシ・サーバが受信したＳＩＰ要求とＳＩＰ応答のメッセージに記載されているヘッダ（例えば、ＶｉａヘッダやＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ）には、経由地点のＩＰアドレスが記載されるため、現用ＳＩＰサーバのＩＰアドレスの次のＩＰアドレスを次に転送すべき宛先と見なすことが可能となるのである。

この機能により、例えば、特許文献２に記載のサーババックアップ装置のように、ＳＩＰ要求のメッセージを転送するユーザ・エージェントのＩＰアドレスを解決する情報を、プロキシ・サーバ内に保持する必要がない。これは、ユーザ・エージェント数の増加につれて、情報を格納するディスクやメモリ容量を追加する必要がないことを意味しており、ユーザ・エージェント数の増加に柔軟に対応可能となるのである。さらに、プロキシ・サーバが、ＳＩＰ要求を転送するユーザ・エージェントのＩＰアドレスを解決する情報を保持しないため、例えば、特許文献２に記載のサーババックアップ装置のような「ＳＩＰ要求の転送可能先は情報記載内」という制限はそもそも存在しないのである。

本発明によれば、以下の効果を達成することができる。

第１の効果は、現用ＳＩＰサーバの障害に遭遇したコールフローの処理を正常に終了できることである。

これは、通話を行う両端のユーザ・エージェントにＳＩＰ要求およびＳＩＰ応答が規約通りに到着すれば、コールフローの処理が継続可能というＳＩＰのプロトコル規約の特性に着目し、プロキシ・サーバが、現用ＳＩＰサーバの障害に遭遇したコールフローに属するＳＩＰ要求とＳＩＰ応答のメッセージを受信した場合に、当該ＳＩＰ要求とＳＩＰ応答の中身を参照し、現用ＳＩＰサーバに代わって、該当ＳＩＰ要求とＳＩＰ応答のメッセージが次に送信されるべき宛先を特定し、転送するためである。

第２の効果は、現用ＳＩＰサーバの障害時でもダイジェスト認証を伴った発呼が可能なことである。

これは、プロキシ・サーバが、現用ＳＩＰサーバの障害発生を検知し、現用ＳＩＰサーバの障害発生状況に合わせてＳＩＰ要求のメッセージの転送先を変更するためである。この結果、現用ＳＩＰサーバでの障害発生時に、ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストやｉｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストなど、ダイジェスト認証を伴うＳＩＰ要求のメッセージをプロキシ・サーバが受信した場合には、予備ＳＩＰサーバへ転送することで、ダイジェスト認証が実行可能となるのである。

第３の効果は、ユーザ・エージェントの数の増加に柔軟に対応可能なことである。

これは、現用ＳＩＰサーバの障害に遭遇したコールフローに属するメッセージの次の転送先を、受信したメッセージの種類に基づいて決定するためである。この結果、ＳＩＰ要求のメッセージの転送先となるユーザ・エージェントのＩＰアドレスを解決する情報を格納するディスクやメモリが不要となる。このように、ユーザ・エージェントなどのＳＩＰ要求のメッセージの転送先数の増加と、転送先のＩＰアドレスの解決処理とが無関係となるのである。

第４の効果は、メッセージの転送先に制限がないことである。

これは、前述したように、現用ＳＩＰサーバの障害に遭遇したコールフローに属するメッセージの次の転送先を、受信したメッセージの種類に基づいて決定しているためである。この結果、プロキシ・サーバ内に転送先のＩＰアドレスを解決するための情報を保持する必要がなくなるため、その情報記載の転送先以外には転送できないといった事態がそもそも発生しないのである。

（第１の実施の形態）
本発明の第１の実施の形態について、図表を参照して詳細に説明する。

（第１の実施の形態の構成）
図１に、本発明の第１の実施の形態に係る通信システムのブロック図を示す。

図１に示すように、本発明の第１の実施の形態に係る通信システムは、登録情報３１を有する現用ＳＩＰサーバ３０及びホットスタンバイしており登録情報４１を有する予備ＳＩＰサーバ４０と接続されるプロキシ・サーバ１０が、ネットワーク５０を介してユーザ・エージェント２０との通信を行う。ここで、ＳＩＰシステム１は、プロキシ・サーバ１０と、現用ＳＩＰサーバ３０と、予備ＳＩＰサーバ４０とを備え、ネットワーク５０に接続する。

図２に、本発明の第１の実施の形態に係るプロキシ・サーバ１０のブロック図を示す。

図２に示すように、本発明の第１の実施の形態に係るプロキシ・サーバ１０１は、前述した、一般的なＳＩＰプロキシ・サーバが有する機能（図２でのＳＩＰプロキシ・サーバ機能１１）に加え、ＳＩＰプロキシ・サーバ機能１１が受信したメッセージの種類を判別するメッセージ種別判定機能１２と、ＳＩＰプロキシ・サーバ機能１１が受信したメッセージが、現用ＳＩＰサーバ３０の障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定機能１３と、ＳＩＰサーバの障害発生状況やＳＩＰプロキシ・サーバ機能１１で受信したメッセージの種類に応じてメッセージの転送先を設定する宛先設定機能１４と、現用ＳＩＰサーバ３０の障害が発生したことを検知し、宛先設定機能１４及び呼障害遭遇判定機能１３にその旨を通知する転送先障害検出機能１５とを備える。

なお、宛先設定機能１４は、特段の指定がない場合に転送する標準的な転送先（以下、標準転送先と呼ぶ）を情報として保持している。例えば、この標準転送先としては、現用ＳＩＰサーバ３０が動作している場合には「現用ＳＩＰサーバ３０」、現用ＳＩＰサーバ３０に障害が発生した場合には「予備ＳＩＰサーバ４０」と設定されている。

さらに、この標準転送先の変更は、転送先障害検出機能１５が宛先設定機能１４に対して現用ＳＩＰサーバ３０の障害発生を通知することにより実行される。

また、この転送先障害検出機能１５における現用ＳＩＰサーバ３０についての障害発生検出は、例えば、下記の手段により実現可能である。例えば、ＳＩＰでは、一般的に、ＲＥＧＩＳＴＥＲリクエストにより更新され、かつ、ＳＩＰサーバで管理される登録情報の有効期限が切れないように、ユーザ・エージェント２０が定期的にＳＩＰサーバに対してＲＥＧＩＳＴＥＲリクエストを送信する。このため、一台のＳＩＰサーバが管理する登録情報の数が数千〜数万となる状況では、一秒間にＳＩＰサーバに到着するＲＥＩＳＴＥＲリクエストは平均数百程度となる。さらに、ＳＩＰサーバは、これらのＲＥＧＩＳＴＥＲリクエストを例えば毎秒処理し、処理結果をＳＩＰ応答としてユーザ・エージェント２０に返す。そこで、転送先障害検出機能１５は、この毎秒当たりにＳＩＰサーバとユーザ・エージェント２０とで送受信されるＲＥＧＩＳＴＥＲリクエストとＳＩＰ応答を監視することで、ＳＩＰサーバからのＳＩＰ応答を検出できない場合には、ＳＩＰサーバ（またはネットワーク５０）に障害が発生したと判断することが可能となる。

呼障害遭遇判定機能１３は、ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストの呼識別子（Ｃａｌｌ−ＩＤヘッダ値）１３１を保持する。この呼識別子１３１は、メッセージ種別判定機能１２が外部から受信したｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストの呼識別子（Ｃａｌｌ−ＩＤヘッダ値）であって、呼障害遭遇判定機能１３がメッセージ種別判定機能１２から通知されたものである。

呼障害遭遇判定機能１３に保存された呼識別子１３１の実現形態の１例を図３に示す。なお、本明細書では、この保存された呼識別子１３１の一覧を「呼識別子一覧１３２」と呼ぶ。

ここで、プロキシ・サーバ１０のハードウェア構成の説明をする。

図４は、本実施の形態による通信システムのプロキシ・サーバ１０のハードウェア構成を示すブロック図である。

図４を参照すると、本発明によるプロキシ・サーバ１０は、一般的なコンピュータ装置と同様のハードウェア構成によって実現することができ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメインメモリであり、データの作業領域やデータの一時退避領域に用いられる主記憶部４０２、ネットワーク５０を介してデータの送受信を行う通信制御部４０３、液晶ディスプレイ、プリンタやスピーカ等の提示部４０４、キーボードやマウス等の入力部４０５、周辺機器と接続してデータの送受信を行うインタフェース部４０６、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気ディスク、半導体メモリ等の不揮発性メモリから構成されるハードディスク装置である補助記憶部４０７、本情報処理装置の上記各構成要素を相互に接続するシステムバス４０８等を備えている。

本発明によるプロキシ・サーバ１０は、その動作を、プロキシ・サーバ１０内部にそのような機能を実現するプログラムを組み込んだ、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等のハードウェア部品からなる回路部品を実装してハードウェア的に実現することは勿論として、上記した各構成要素の各機能を提供するプログラムを、コンピュータ処理装置上のＣＰＵ４０１で実行することにより、ソフトウェア的に実現することができる。

すなわち、ＣＰＵ４０１は、補助記憶部４０７に格納されているプログラムを、主記憶部４０２にロードして実行し、プロキシ・サーバ１０の動作を制御することにより、上述した各機能をソフトウェア的に実現する。

（第１の実施の形態の動作）
次に、本発明の第１の実施の形態に係るプロキシ・サーバの動作について図表を参照して詳細に説明する。

図５は、本発明の第１の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。

いま、ＳＩＰプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップＳ５０１）。次に、メッセージ種別判定機能１２が、ＳＩＰプロキシ・サーバ機能１１によって受信したメッセージの種類を調査する（ステップＳ５０２）。

ステップＳ５０２の結果、受信したメッセージがＳＩＰ要求（ＡＣＫまたはＢＹＥ）の場合には、さらに、呼障害遭遇判定機能１３が、上記受信したメッセージが現用ＳＩＰサーバ３０の障害に遭遇したコールフローに属するかを調査する（ステップＳ５０３）。

このステップＳ５０３の処理は、例えば、以下に示す手段により実現できる。まず、メッセージ種別判定機能１２が、外部から受信したｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストの呼識別子（Ｃａｌｌ−ＩＤヘッダ値）１３１を呼障害遭遇判定機能１３に対して通知し、呼障害遭遇判定機能１３は、受信した呼識別子１３１を保持する。

呼障害遭遇判定機能１３は、図３に示すような呼識別子一覧１３２を保存する。この呼識別子一覧１３２の内容は、転送先障害検出機能１５が現用ＳＩＰサーバ３０の障害発生を検出した際に、その旨を転送先障害検出機能１５から受信した呼障害遭遇判定機能１３により全て一旦消去される。この動作により、この呼識別子一覧１３２には、現用または予備ＳＩＰサーバの動作時に新規に生成されたコールフローの呼識別子（Ｃａｌｌ−ＩＤヘッダ値）１３１のみが記載されることになる。つまり、呼障害遭遇判定機能１３は、この呼識別子一覧１３２に記載のない呼識別子１３１を保持するＳＩＰ要求（ＡＣＫまたはＢＹＥ）またはＳＩＰ応答をメッセージ種別判定機能１２から受信した場合、当該呼識別子１３１で識別されるコールフローは現用ＳＩＰサーバ３０の障害に遭遇したと判別できるのである。

ステップＳ５０３の結果、ステップＳ５０１で受信したメッセージが現用ＳＩＰサーバ３０の障害発生に遭遇していない場合には、宛先設定機能１４がステップＳ５０１の結果受信したメッセージの送信先を標準転送先に設定する（ステップＳ５０４）。

ステップＳ５０３の結果、ステップＳ５０１で受信したメッセージが現用ＳＩＰサーバ３０の障害に遭遇したコールフローに属すると判別された場合には、メッセージの転送先を新規に決定する（ステップＳ５０５）。

この処理は、例えば、以下に示す手段により実現可能である。ＳＩＰ要求（ＡＣＫまたはＢＹＥ）およびＳＩＰ応答には、メッセージの転送経路を格納するヘッダ（ＶｉａヘッダまたはＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ）が存在する。現用ＳＩＰサーバ３０の障害発生に遭遇したＳＩＰ要求およびＳＩＰ応答の場合、このヘッダに、現用ＳＩＰサーバ３０のアドレスが記載されている。そこで、このヘッダから、現用ＳＩＰサーバ３０の次に記載されているアドレス（例えば、着呼側のユーザ・エージェント２０のアドレス）を抽出し、当該アドレスへメッセージを直接転送すべく、当該アドレスを次転送先とするのである。

また、このステップＳ５０５は、例えば、以下の処理によっても実現可能である。ＳＩＰ要求およびＳＩＰ応答の宛先ヘッダ（Ｔｏヘッダ）が完全修飾ドメイン名（ＦＱＤＮ：Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）で記載されている場合、宛先決定機能が、転送経路を格納するヘッダ値を無視して、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）等の外部システムから再度Ｔｏヘッダのアドレス解決を実行することで、次転送先を決定するのである。

ステップＳ５０２の結果、ステップＳ５０１で受信したメッセージがＳＩＰ応答の場合には、さらに、呼障害遭遇判定機能１３が、上記受信したメッセージが障害に遭遇したコールフローに属するかを調査する（ステップＳ５０６）。なお、このステップＳ５０６の処理は、ステップＳ５０３の処理と同様であるため説明を省略する。

ステップＳ５０６の結果、ステップＳ５０１で受信したメッセージが現用ＳＩＰサーバ３０の障害に遭遇したコールフローに属すると判別された場合には、メッセージの転送先を新規に決定する（ステップＳ５０５）。このステップＳ５０５の処理は前述した通りである。

ステップＳ５０６の結果、ステップＳ５０１で受信したメッセージが現用ＳＩＰサーバ３０の障害発生に遭遇していない場合には、宛先設定機能１４が、ステップＳ５０１の結果受信したメッセージの送信先を当該メッセージに記載された送信先に決定する（ステップＳ５０７）。

ステップＳ５０２の結果、ステップＳ５０１で受信したメッセージがＳＩＰ要求（ＡＣＫまたはＢＹＥ）またはＳＩＰ応答以外の場合には、宛先設定機能１４が、ステップＳ５０１の結果受信したメッセージの送信先を標準転送先に指定する（ステップＳ５０４）。

ステップＳ５０４、ステップＳ５０５およびステップＳ５０７において宛先決定機能が設定した送信先に対し、ＳＩＰプロキシ・サーバ機能１１が、ステップＳ５０１で受信したメッセージを転送する（ステップＳ５０８）。

次に、本発明の第１の実施の形態に係るプロキシ・サーバ１０を含むシステム全体の動作について図表を参照して詳細に説明する。

図６は、本発明の第１の実施の形態に係るプロキシ・サーバを含むシステム全体での動作を示す動作シーケンス図、図７は、同フローチャートである。図６及び図７に示すように、コールフローの途中（図６では呼設立後）で現用ＳＩＰサーバ３０に障害が発生した場合には（ステップＳ７０１）、プロキシ・サーバ１０が、予備ＳＩＰサーバ４０を標準転送先として設定し（ステップＳ７０２）、それ以後のＳＩＰ要求（ＡＣＫとＢＹＥ）を予備ＳＩＰサーバ４０に転送するのではなく、ＳＩＰ要求の次の転送先（図６ではユーザ・エージェント２０（着呼側））に直接転送する（ステップＳ７０３）。

（第１の実施の形態の効果）
このように、本実施の形態によれば、以下の効果を達成することができる。

第１の効果は、現用ＳＩＰサーバ３０の障害に遭遇したコールフローの処理を正常に終了できることである。

これは、通話を行う両端のユーザ・エージェント２０にＳＩＰ要求およびＳＩＰ応答が規約通りに到着すれば、コールフローの処理が継続可能というＳＩＰのプロトコル規約の特性に着目し、プロキシ・サーバ１０が、現用ＳＩＰサーバ３０の障害に遭遇したコールフローに属するＳＩＰ要求とＳＩＰ応答を受信した場合に、当該ＳＩＰ要求とＳＩＰ応答の中身を参照し、現用ＳＩＰサーバ３０に代わって、該当ＳＩＰ要求とＳＩＰ応答が次に送信されるべき宛先を特定し、転送するためである。

第２の効果は、現用ＳＩＰサーバ３０の障害時でもダイジェスト認証を伴った発呼が可能なことである。

これは、プロキシ・サーバ１０が、現用ＳＩＰサーバ３０の障害発生を検知し、現用ＳＩＰサーバ３０の障害発生状況に合わせてＳＩＰ要求の転送先を変更するためである。この結果、現用ＳＩＰサーバ３０での障害発生時に、ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストやｉｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストなど、ダイジェスト認証を伴うＳＩＰ要求をプロキシ・サーバ１０が受信した場合には、予備ＳＩＰサーバ４０へ転送することで、ダイジェスト認証が実行可能となるのである。

第３の効果は、ユーザ・エージェント２０の数の増加に柔軟に対応可能なことである。

これは、現用ＳＩＰサーバの障害に遭遇したコールフローに属するＳＩＰ要求とＳＩＰ応答の次の転送先を、受信したＳＩＰ要求とＳＩＰ応答に格納されたヘッダの内容から決定するためである。この結果、ＳＩＰ要求の転送先となるユーザ・エージェント２０のＩＰアドレスを解決する情報を格納するディスクやメモリが不要となる。このように、ユーザ・エージェント２０などのＳＩＰ要求の転送先数の増加と、転送先のＩＰアドレスの解決処理とが無関係となるのである。

第４の効果は、ＳＩＰ要求の転送先に制限がないことである。

これは、前述したように、現用ＳＩＰサーバ３０の障害に遭遇したコールフローに属するＳＩＰ要求とＳＩＰ応答の次の転送先を、受信したＳＩＰ要求とＳＩＰ応答に格納されたヘッダの内容から決定しているためである。この結果、プロキシ・サーバ１０内に転送先のＩＰアドレスを解決するための情報を保持する必要がなくなるため、その情報記載の転送先以外には転送できないといった事態がそもそも発生しないのである。

（第２の実施の形態）
次に、本発明の第２の実施の形態に係るプロキシ・サーバに関して図表を参照して詳細に説明する。

（第２の実施の形態の構成）
図８は、本発明の第２の実施の形態に係るプロキシ・サーバ１０のブロック図を示す。

図８に示すように、本発明の第２の実施の形態に係るプロキシ・サーバ１０は、本発明の第１の実施の形態に係るプロキシ・サーバ１０の構成に再送要求生成機能１６が追加された構成となっている。

この再送要求生成機能１６は、認証ＩＮＶＩＴＥリクエスト到達時において現用ＳＩＰサーバ３０に障害が発生していた場合に、ユーザ・エージェント２０に対してｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストの再転送を促すために、ユーザ・エージェント２０へ転送する再送要求を生成する。例えば、この再送要求には、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダを挿入したＳＩＰ応答（５００ Ｓｅｒｖｅｒ Ｉｎｅｒｎａｌ Ｅｒｒｏｒ）が使用される。このＳＩＰ応答を受信した結果、ユーザ・エージェント２０は一般的なＳＩＰ応答受信時の処理に従い、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダ記載の期間後、再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを送信することになる。

（第２の実施の形態の動作）
次に、本発明の第２の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。

図９は、本発明の第２の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。

図９に示すように、本発明の第２の実施の形態に係るプロキシ・サーバ１０の動作は、本発明の第１の実施の形態に係るプロキシ・サーバ１０の動作に、再送要求生成機能１６の再送要求生成処理を含むステップＳ９０３からステップＳ９０５が追加された形態となっている。なお、本実施の形態の再送要求生成処理を含むステップ以外のステップである、ステップＳ９０１は第１の実施の形態の図５に示すステップＳ５０１と、ステップＳ９０２はステップＳ５０２と、ステップＳ９０６はステップＳ５０３と、ステップＳ９０７はステップＳ５０４と、ステップＳ９０８はステップＳ５０５と、ステップＳ９０９はステップＳ５０６と、ステップＳ９１０はステップＳ５０７と、ステップＳ９１１はステップＳ５０８と同様の処理内容であるので説明を省略し、ステップＳ９０３からステップＳ９０５の動作を中心に説明する。

ステップＳ９０２の結果、ステップＳ９０１で受信したメッセージが認証ＩＮＶＩＴＥリクエストであった場合、呼障害遭遇判定機能１３は、受信したメッセージが障害に遭遇したコールフローに属するかを調査する（ステップＳ９０３）。なお、ステップＳ９０３の処理は、本発明の第１の実施の形態に係るプロキシ・サーバ１０における動作ステップＳ５０３と同様であるため、説明を省略する。

ステップＳ９０３の結果、ステップＳ９０１で受信したメッセージが障害に遭遇したコールフローに属する場合には、再送要求生成機能１６が、ユーザ・エージェント２０に送信する再送要求を生成する（ステップＳ９０４）。この処理は、例えば、以下のようにして実行される。生成する再送要求が、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダを挿入したＳＩＰ応答（５００ Ｓｅｒｖｅｒ Ｉｎｅｒｎａｌ Ｅｒｒｏｒ）の場合、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダ以外のヘッダにはステップＳ９０１で受信したメッセージの値を使用し、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダには「３０秒」等の値を使用する。その後、宛先設定機能１４が再送要求の転送先をユーザ・エージェント２０と設定する（ステップＳ９０５）。その後、ＳＩＰプロキシ・サーバ機能１１が、ステップＳ９０４で生成された再送要求をユーザ・エージェント２０に転送する（ステップＳ９１１）。

次に、本発明の第２の実施の形態に係るプロキシ・サーバを含むシステム全体の動作について図表を参照して詳細に説明する。

図１０は、本発明の第２の実施の形態に係るプロキシ・サーバを含むシステム全体の動作を示すシーケンス図、図１１は、同フローチャートである。図１０及び図１１に示すように、プロキシ・サーバ１０が認証ＩＮＶＩＴＥリクエストを受信した際に現用ＳＩＰサーバ３０において障害が発生している場合、本発明の第１の実施の形態に係るプロキシ・サーバ１０と同様に、標準転送先を予備ＳＩＰサーバ４０に変更した後（ステップＳ１１０１、ステップＳ１１０２）、再送要求を生成し（ステップＳ１１０３）、ユーザ・エージェント２０に送信している（ステップＳ１１０４）。この結果、ユーザ・エージェント２０は、ＳＩＰのプロトコル規約に規定されているように、Ｒｅｔｒｙ−Ａｆｔｅｒ経過後に再度利用可能になると判断し、該当期間経過後、再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを発行する（ステップＳ１１０５）。

なお、上記の説明は、ＩＮＶＩＴＥリクエストに関して説明してあるが、プロキシ・サーバ１０の動作はＲＥＧＩＳＴＥＲリクエストに関しても同様の動作により、ユーザ・エージェント２０側に再度ｉｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを送信させることが可能である。

（第２の実施の形態の効果）
このように、本実施の形態によれば、第１の実施の形態での効果に加えて、ユーザ・エージェント２０側で、現用ＳＩＰサーバ３０の障害に遭遇したコールフローを正常な新規コールフローとして自動的に再生成することが可能という効果がある。

これは、プロキシ・サーバ１０がユーザ・エージェント２０の認証ＩＮＶＩＴＥリクエスト送信後に現用ＳＩＰサーバ３０の障害発生を検知した場合に、再送要求生成機能１６が、ユーザ・エージェント２０から受信した認証ＩＮＶＩＴＥリクエストを使用し、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダを挿入したＳＩＰ応答を生成してユーザ・エージェント２０に送信するためである。これにより、ユーザ・エージェント２０は、ＳＩＰのプロトコル規約に記載されたタイムアウト（通常３２秒）後に、通話者が不通状態と判断し、任意の時間後に人手で再度通話を試みるのではなく、一般的なＳＩＰ応答の処理に従い、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダ値後に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストをプロキシ・サーバ１０に向けて自動的に送信することが可能となるためである。

以上好ましい実施の形態をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。

本発明のプロキシ・サーバは、複数のユーザ端末及び複数のＳＩＰサーバを有するＳＩＰネットワークに利用できる。

本発明の第１の実施の形態に係る通信システムの構成を示すブロック図である。 第１の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。 第１の実施の形態に係るプロキシ・サーバにおける、呼障害遭遇判定機能が保持する呼識別子一覧表の実現形態の１例を示す図である。 第１の実施の形態に係る通信システムのプロキシ・サーバのハードウェア構成を示すブロック図である。 第１の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。 第１の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。 第１の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すフローチャートである。 本発明の第２の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。 第２の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。 第２の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。 第２の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すフローチャートである。 従来の一般的なＳＩＰネットワークにおいて、ユーザ・エージェント間で通信する場合の動作シーケンス図である。 従来の代理応答装置を含むシステム全体の構成を示すブロック図である。 従来技術の構成を示すブロック図である。 従来技術におけるパケットバッファの構成例を示す図である。 従来技術の動作を示すフローチャートである。 従来のサーババックアップ装置の原理構成を示す図である。 従来のサーババックアップ装置を含むシステム全体の構成を示す図である。 従来のサーババックアップ装置における、ＩＰセントレックスサーバ正常動作時の動作を示す図である。 従来のサーババックアップ装置における、ＩＰセントレックスサーバ障害発生時の動作を示す図である。 従来技術をＳＩＰネットワークに適用した場合に、予備ＳＩＰサーバへ現用ＳＩＰサーバの状態を再現できない例を示すシーケンス図である。

符号の説明

１：ＳＩＰシステム
１０：プロキシ・サーバ
１１：ＳＩＰプロキシ・サーバ機能
１２：メッセージ種別判定機能
１３：呼障害遭遇判定機能
１３１：呼識別子
１３２：呼識別子一覧
１４：宛先設定機能
１５：転送先障害検出機能
１６：再送要求生成機能
２０：ユーザ・エージェント
３０：現用ＳＩＰサーバ
３１：登録情報
４０：予備ＳＩＰサーバ
４１：登録情報
５０：ネットワーク
４０１：ＣＰＵ
４０２：主記憶部
４０３：通信制御部
４０４：提示部
４０５：入力部
４０６：インタフェース部
４０７：補助記憶部
４０８：システムバス

Claims (50)

1. ユーザ端末と現用ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介するプロキシ・サーバ機能と、
   前記プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ種別判定機能と、
   前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出機能と、
   前記転送先障害検出機能からの通知を受信し、前記プロキシ・サーバ機能が受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定機能と、
   前記転送先障害検出機能からの通知を受信し、前記現用ＳＩＰサーバの障害発生状況に応じて、前記プロキシ・サーバ機能で受信したメッセージの種類が、ＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を設定する宛先設定機能と
   を備えることを特徴とするプロキシ・サーバ。
2. ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介するプロキシ・サーバ機能と、
   前記プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ種別判定機能と、
   前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出機能と、
   前記転送先障害検出機能からの通知を受信し、前記プロキシ・サーバ機能が受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定機能と、
   前記転送先障害検出機能からの通知を受信し、前記現用ＳＩＰサーバの障害発生状況や前記プロキシ・サーバ機能で受信したメッセージの種類に応じてメッセージの転送先を設定する宛先設定機能と、
   前記ユーザ端末に対しｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために前記ユーザ端末へ転送する再送要求を生成する再送要求生成機能と
   を備えることを特徴とするプロキシ・サーバ。
3. 前記宛先設定機能は、
   前記転送先障害検出機能が通知する前記現用ＳＩＰサーバの障害発生通知により更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報として保持する機能を備えることを特徴とする請求項１又は請求項２に記載のプロキシ・サーバ。
4. 前記転送先障害検出機能は、
   前記現用ＳＩＰサーバと前記ユーザ端末とで送受信されるＲＥＧＩＳＴＥＲリクエストとＳＩＰ応答を監視し、前記現用ＳＩＰサーバからのＳＩＰ応答を検出できない場合には、前記現用ＳＩＰサーバに障害が発生したと判断する機能を備えることを特徴とする請求項１又は請求項２に記載のプロキシ・サーバ。
5. 前記呼障害遭遇判定機能は、
   外部から受信した前記ＳＩＰメッセージに格納された呼識別子を保持しており、かつ、前記現用ＳＩＰサーバの障害発生を検出した際に全て一旦消去される、呼識別子一覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは前記現用ＳＩＰサーバの障害に遭遇したと判別する機能を備えることを特徴とする請求項１又は請求項２に記載のプロキシ・サーバ。
6. 前記宛先決定機能は、
   前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用ＳＩＰサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接転送すべく、当該アドレスを次転送先とする機能を備えることを特徴とする、請求項１又は請求項２に記載のプロキシ・サーバ。
7. 前記宛先決定機能は、
   前記メッセージに格納されている、転送経路に関する情報を無視して、外部システムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する機能を備えることを特徴とする請求項１又は請求項２に記載のプロキシ・サーバ。
8. 前記再送要求生成機能は、
   前記ユーザ端末が、通常のＳＩＰ応答受信時の処理に従い、ある一定期間後、再度メッセージを送信するよう誘導するＳＩＰ応答を生成する機能を備えることを特徴とする請求項２に記載のプロキシ・サーバ。
9. 外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージがＳＩＰ要求である場合には、更に、受信したメッセージが現用ＳＩＰサーバの障害に遭遇したコールフローに属するかを調査し、受信したメッセージが前記現用ＳＩＰサーバの障害に遭遇したコールフローに属すると判別された場合には、メッセージの内容を参照してメッセージの転送先を新規に決定する機能を備えることを特徴とするプロキシ・サーバ。
10. 外部からメッセージを受信後、メッセージ種類を調査し、受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査し、障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送する機能を備えることを特徴とするプロキシ・サーバ。
11. 外部からメッセージを受信後、メッセージ種類を調査し、受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査し、障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送する機能を備えることを特徴とする請求項９に記載のプロキシ・サーバ。
12. ユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
    前記プロキシ・サーバに、
    ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介するプロキシ・サーバ機能と、
    前記プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ種別判定機能と、
    前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出機能と、
    前記転送先障害検出機能からの通知を受信し、前記プロキシ・サーバ機能が受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定機能と、
    前記転送先障害検出機能からの通知を受信し、前記現用ＳＩＰサーバの障害発生状況に応じて、前記プロキシ・サーバ機能で受信したメッセージの種類が、ＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を設定する宛先設定機能とを備える
    ことを特徴とする通信システム。
13. ユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
    前記プロキシ・サーバに、
    ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介するプロキシ・サーバ機能と、
    前記プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ種別判定機能と、
    前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出機能と、
    前記転送先障害検出機能からの通知を受信し、前記プロキシ・サーバ機能が受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定機能と、
    前記転送先障害検出機能からの通知を受信し、前記現用ＳＩＰサーバの障害発生状況や前記プロキシ・サーバ機能で受信したメッセージの種類に応じてメッセージの転送先を設定する宛先設定機能と、
    前記ユーザ端末に対しｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために前記ユーザ端末へ転送する再送要求を生成する再送要求生成機能とを備える
    ことを特徴とする通信システム。
14. 前記プロキシ・サーバの前記宛先設定機能は、
    前記転送先障害検出機能が通知する前記現用ＳＩＰサーバの障害発生通知により更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報として保持する機能を備えることを特徴とする請求項１２又は請求項１３に記載の通信システム。
15. 前記プロキシ・サーバの前記転送先障害検出機能は、
    前記現用ＳＩＰサーバと前記ユーザ端末とで送受信されるＲＥＧＩＳＴＥＲリクエストとＳＩＰ応答を監視し、前記現用ＳＩＰサーバからのＳＩＰ応答を検出できない場合には、前記現用ＳＩＰサーバに障害が発生したと判断する機能を備えることを特徴とする請求項１２又は請求項１３に記載の通信システム。
16. 前記プロキシ・サーバの前記呼障害遭遇判定機能は、
    外部から受信した前記ＳＩＰメッセージに格納された呼識別子を保持しており、かつ、前記現用ＳＩＰサーバの障害発生を検出した際に全て一旦消去される、呼識別子一覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは前記現用ＳＩＰサーバの障害に遭遇したと判別する機能を備えることを特徴とする請求項１２又は請求項１３に記載の通信システム。
17. 前記プロキシ・サーバの前記宛先決定機能は、
    前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用ＳＩＰサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接転送すべく、当該アドレスを次転送先とする機能を備えることを特徴とする、請求項１２又は請求項１３に記載の通信システム。
18. 前記プロキシ・サーバの前記宛先決定機能は、
    前記メッセージに格納されている、転送経路に関する情報を無視して、外部システムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する機能を備えることを特徴とする請求項１２又は請求項１３に記載の通信システム。
19. 前記プロキシ・サーバの前記再送要求生成機能は、
    前記ユーザ端末が、通常のＳＩＰ応答受信時の処理に従い、ある一定期間後、再度メッセージを送信するよう誘導するＳＩＰ応答を生成する機能を備えることを特徴とする請求項１３に記載の通信システム。
20. ユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
    前記プロキシ・サーバに、
    外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージがＳＩＰ要求である場合には、更に、受信したメッセージが現用ＳＩＰサーバの障害に遭遇したコールフローに属するかを調査し、受信したメッセージが前記現用ＳＩＰサーバの障害に遭遇したコールフローに属すると判別された場合、メッセージがＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を新規に決定する機能を備えることを特徴とする通信システム。
21. ユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
    前記プロキシ・サーバに、
    外部からメッセージを受信後、メッセージ種類を調査し、受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査し、障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送する機能を備えることを特徴とする通信システム。
22. 前記プロキシ・サーバに、
    外部からメッセージを受信後、メッセージ種類を調査し、受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査し、障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送する機能を備えることを特徴とする請求項２０に記載の通信システム。
23. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバに対し、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
    ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介する仲介ステップと、
    前記仲介ステップで受信したメッセージの種類を判別するメッセージ種別判定ステップと、
    前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出ステップと、
    前記転送先障害検出ステップからの通知を受信し、前記仲介ステップでが受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定ステップと、
    前記転送先障害検出ステップからの通知を受信し、前記現用ＳＩＰサーバの障害発生状況に応じて、前記仲介ステップで受信したメッセージの種類が、ＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を設定する宛先設定ステップと
    を含むことを特徴とする通信方法。
24. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバに対し、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
    ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介する仲介ステップと、
    前記仲介ステップで受信したメッセージの種類を判別するメッセージ種別判定機能と、
    前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出ステップと、
    前記転送先障害検出ステップからの通知を受信し、前記仲介ステップで受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定ステップと、
    前記転送先障害検出ステップからの通知を受信し、前記現用ＳＩＰサーバの障害発生状況や前記仲介ステップで受信したメッセージの種類に応じてメッセージの転送先を設定する宛先設定ステップと、
    前記ユーザ端末に対しｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために前記ユーザ端末へ転送する再送要求を生成する再送要求生成ステップと
    を含むことを特徴とする通信方法。
25. 前記宛先設定ステップは、
    前記転送先障害検出ステップが通知する前記現用ＳＩＰサーバの障害発生通知により更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報として保持するステップを含むことを特徴とする請求項２３又は請求項２４に記載の通信方法。
26. 前記転送先障害検出ステップは、
    前記現用ＳＩＰサーバと前記ユーザ端末とで送受信されるＲＥＧＩＳＴＥＲリクエストとＳＩＰ応答を監視し、前記現用ＳＩＰサーバからのＳＩＰ応答を検出できない場合には、前記現用ＳＩＰサーバに障害が発生したと判断するステップを含むことを特徴とする請求項２３又は請求項２４に記載の通信方法。
27. 前記呼障害遭遇判定ステップは、
    外部から受信した前記ＳＩＰメッセージに格納された呼識別子を保持しており、かつ、前記現用ＳＩＰサーバの障害発生を検出した際に全て一旦消去される、呼識別子一覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは前記現用ＳＩＰサーバの障害に遭遇したと判別するステップを含むことを特徴とする請求項２３又は請求項２４に記載の通信方法。
28. 前記宛先決定ステップは、
    前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用ＳＩＰサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接転送すべく、当該アドレスを次転送先とするステップを含むことを特徴とする請求項２３又は請求項２４に記載の通信方法。
29. 前記宛先決定ステップは、
    前記メッセージに格納されている、転送経路に関する情報を無視して、外部システムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する機能を備えることを特徴とする請求項２３又は請求項２４に記載の通信方法。
30. 前記再送要求生成ステップは、
    前記ユーザ端末が、通常のＳＩＰ応答受信時の処理に従い、ある一定期間後、再度メッセージを送信するよう誘導するＳＩＰ応答を生成する機能を備えることを特徴とする請求項２４に記載の通信方法。
31. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバに対し、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
    外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージがＳＩＰ要求である場合には、更に、受信したメッセージが現用ＳＩＰサーバの障害に遭遇したコールフローに属するかを調査するステップと、
    受信したメッセージが前記現用ＳＩＰサーバの障害に遭遇したコールフローに属すると判別された場合、メッセージがＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を新規に決定するステップを有することを特徴とする通信方法。
32. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバに対し、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
    外部からメッセージを受信後、メッセージ種類を調査するステップと、
    受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査するステップと、
    障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送するステップを有することを特徴とする通信方法。
33. 外部からメッセージを受信後、メッセージ種類を調査するステップと、
    受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査するステップと、
    障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送するステップを有することを特徴とする請求項３１に記載の通信方法。
34. 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
    ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介する仲介処理と、
    前記仲介処理で受信したメッセージの種類を判別するメッセージ種別判定処理と、
    前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出処理と、
    前記転送先障害検出処理からの通知を受信し、前記仲介処理でが受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定処理と、
    前記転送先障害検出処理からの通知を受信し、前記現用ＳＩＰサーバの障害発生状況に応じて、前記仲介処理で受信したメッセージの種類が、ＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を設定する宛先設定処理を、
    前記プロキシ・サーバに実行させることを特徴とするプログラム。
35. 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
    ユーザ端末と現用ＳＩＰサーバ及び予備ＳＩＰサーバとの間で送受信されるＳＩＰメッセージを仲介する仲介処理と、
    前記仲介処理で受信したメッセージの種類を判別するメッセージ種別判定処理と、
    前記現用ＳＩＰサーバの障害が発生したことを検知して通知する転送先障害検出処理と、
    前記転送先障害検出ステップからの通知を受信し、前記仲介処理で受信したメッセージが、前記現用ＳＩＰサーバの障害に遭遇したコールフローに属するものかを判定する呼障害遭遇判定処理と、
    前記転送先障害検出処理からの通知を受信し、前記現用ＳＩＰサーバの障害発生状況や前記仲介処理で受信したメッセージの種類に応じてメッセージの転送先を設定する宛先設定処理と、
    前記ユーザ端末に対しｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために前記ユーザ端末へ転送する再送要求を生成する再送要求生成処理を、
    前記プロキシ・サーバに実行させることを特徴とするプログラム。
36. 前記宛先設定処理は、
    前記転送先障害検出処理が通知する前記現用ＳＩＰサーバの障害発生通知により更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報として保持する処理を含むことを特徴とする請求項３４又は請求項３５に記載のプログラム。
37. 前記転送先障害検出処理は、
    前記現用ＳＩＰサーバと前記ユーザ端末とで送受信されるＲＥＧＩＳＴＥＲリクエストとＳＩＰ応答を監視し、前記現用ＳＩＰサーバからのＳＩＰ応答を検出できない場合には、前記現用ＳＩＰサーバに障害が発生したと判断する処理を含むことを特徴とする請求項３４又は請求項３５に記載のプログラム。
38. 前記呼障害遭遇判定処理は、
    外部から受信した前記ＳＩＰメッセージに格納された呼識別子を保持しており、かつ、前記現用ＳＩＰサーバの障害発生を検出した際に全て一旦消去される、呼識別子一覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは前記現用ＳＩＰサーバの障害に遭遇したと判別する処理を含むことを特徴とする請求項３４又は請求項３５に記載のプログラム。
39. 前記宛先決定処理は、
    前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用ＳＩＰサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接転送すべく、当該アドレスを次転送先とする処理を含むことを特徴とする請求項３４又は請求項３５に記載のプログラム。
40. 前記宛先決定処理は、
    前記メッセージに格納されている、転送経路に関する情報を無視して、外部システムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する処理を含むことを特徴とする請求項３４又は請求項３５に記載のプログラム。
41. 前記再送要求生成処理は、
    前記ユーザ端末が、通常のＳＩＰ応答受信時の処理に従い、ある一定期間後、再度メッセージを送信するよう誘導するＳＩＰ応答を生成する処理を含むことを特徴とする請求項３５に記載のプログラム。
42. 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
    外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージがＳＩＰ要求である場合には、更に、受信したメッセージが現用ＳＩＰサーバの障害に遭遇したコールフローに属するかを調査する処理と、
    受信したメッセージが前記現用ＳＩＰサーバの障害に遭遇したコールフローに属すると判別された場合、メッセージがＳＩＰ要求のＡＣＫもしくはＢＹＥ、またはＳＩＰ応答である場合に、メッセージの転送先を新規に決定する処理を、
    前記プロキシ・サーバに実行させることを特徴とするプログラム。
43. 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
    外部からメッセージを受信後、メッセージ種類を調査する処理と、
    受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査する処理と、
    障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送する処理を、
    前記プロキシ・サーバに実行させることを特徴とするプログラム。
44. 外部からメッセージを受信後、メッセージ種類を調査する処理と、
    受信したメッセージが認証ＩＮＶＩＴＥリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査する処理と、
    障害に遭遇したコールフローに属する場合には、ユーザ端末に再度ｉｎｉｔｉａｌ ＩＮＶＩＴＥリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求を生成し、前記ユーザ端末に転送する処理を、
    前記プロキシ・サーバに実行させることを特徴とする請求項４２に記載のプログラム。
45. 前記宛先設定機能は、前記ＳＩＰ要求のＡＣＫもしくはＢＹＥ、または前記ＳＩＰ応答に含まれるヘッダから着呼側の前記ユーザ端末のアドレスを抽出し、当該アドレスをメッセージの転送先として設定することを特徴とする請求項１に記載のプロキシ・サーバ。
46. 前記宛先設定機能は、前記ＳＩＰ要求のＡＣＫもしくはＢＹＥ、または前記ＳＩＰ応答に含まれるヘッダから着呼側の前記ユーザ端末のアドレスを抽出し、当該アドレスをメッセージの転送先として設定することを特徴とする請求項１２に記載の通信システム。
47. 前記宛先設定ステップで、前記ＳＩＰ要求のＡＣＫもしくはＢＹＥ、または前記ＳＩＰ応答に含まれるヘッダから着呼側の前記ユーザ端末のアドレスを抽出し、当該アドレスをメッセージの転送先として設定することを特徴とする請求項２３に記載の通信方法。
48. 前記転送先を新規に決定するステップで、前記ＳＩＰ要求のＡＣＫもしくはＢＹＥ、または前記ＳＩＰ応答に含まれるヘッダから着呼側の前記ユーザ端末のアドレスを抽出し、当該アドレスをメッセージの転送先として設定することを特徴とする請求項３１に記載の通信方法。
49. 前記宛先設定処理で、前記ＳＩＰ要求のＡＣＫもしくはＢＹＥ、または前記ＳＩＰ応答に含まれるヘッダから着呼側の前記ユーザ端末のアドレスを抽出し、当該アドレスをメッセージの転送先として設定することを特徴とする請求項３４に記載のプログラム。
50. 前記転送先を新規に決定する処理で、前記ＳＩＰ要求のＡＣＫもしくはＢＹＥ、または前記ＳＩＰ応答に含まれるヘッダから着呼側の前記ユーザ端末のアドレスを抽出し、当該アドレスをメッセージの転送先として設定することを特徴とする請求項４２に記載のプログラム。

Images