(57)【特許請求の範囲】
【請求項１】
外部とメッセージを送受信するＳＩＰプロキシ・サーバ機能と、
前記ＳＩＰプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、
ユーザ端末と前記ユーザ端末から自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報と、
ユーザ端末にＳＩＰ要求の送信先を変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能と、
現用ＳＩＰサーバ又は予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新する機能とを備え、
前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる場合に、ユーザ端末にＳＩＰ要求の送信先を前記送信先対応情報で示される送信先に変更させる宛先変更依頼応答を生成し、
前記送信先対応情報を更新する機能は、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とするプロキシ・サーバ。
【請求項２】
受信したメッセージの有効期限を更新する有効期限更新機能を備え、
前記有効期限更新機能は、受信したメッセージが認証ＲＥＧＩＳＴＥＲリクエストである場合に、当該認証ＲＥＧＩＳＴＥＲリクエストの有効期限を延長し、受信したメッセージが認証可を示すＳＩＰ応答である場合に、当該有効期限を短縮することを特徴とする請求項１に記載のプロキシ・サーバ。
【請求項３】
前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１又は請求項２に記載のプロキシ・サーバ。
【請求項４】
外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
前記プロキシ・サーバに、
外部とメッセージを送受信するＳＩＰプロキシ・サーバ機能と、
前記ＳＩＰプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、
前記ユーザ端末と前記ユーザ端末から自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報と、
ユーザ端末にＳＩＰ要求の送信先を変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能と、
現用ＳＩＰサーバ又は予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新する機能とを備え、
前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる場合に、ユーザ端末にＳＩＰ要求の送信先を前記送信先対応情報で示される送信先に変更させる宛先変更依頼応答を生成し、
前記送信先対応情報を更新する機能は、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とする通信システム。
【請求項５】
前記プロキシ・サーバに、
受信したメッセージの有効期限を更新する有効期限更新機能を備え、
前記有効期限更新機能は、受信したメッセージが認証ＲＥＧＩＳＴＥＲリクエストである場合に、当該認証ＲＥＧＩＳＴＥＲリクエストの有効期限を延長し、受信したメッセージが認証可を示すＳＩＰ応答である場合に、当該有効期限を短縮することを特徴とする請求項４に記載の通信システム。
【請求項６】
前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項４又は請求項５に記載の通信システム。
【請求項７】
外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバに対し、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
外部とメッセージを送受信する仲介ステップと、
前記仲介ステップにより受信したメッセージの種類を識別するメッセージ判別ステップと、
ユーザ端末にＳＩＰ要求の送信先を変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成ステップと、
現用ＳＩＰサーバ又は予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新するステップとを備え、
前記宛先変更依頼応答生成ステップは、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる場合に、ユーザ端末にＳＩＰ要求の送信先を前記送信先対応情報で示される送信先に変更させる宛先変更依頼応答を生成し、
前記送信先対応情報を更新するステップは、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とする通信方法。
【請求項８】
受信したメッセージの有効期限を更新する有効期限更新ステップを備え、
前記有効期限更新ステップは、受信したメッセージが認証ＲＥＧＩＳＴＥＲリクエストである場合に、当該認証ＲＥＧＩＳＴＥＲリクエストの有効期限を延長し、受信したメッセージが認証可を示すＳＩＰ応答である場合に、当該有効期限を短縮することを特徴とする請求項７に記載の通信方法。
【請求項９】
前記宛先変更依頼応答生成ステップは、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項７又は請求項８に記載の通信方法。
【請求項１０】
外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
外部とメッセージを送受信するＳＩＰプロキシ・サーバ処理と、
前記ＳＩＰプロキシ・サーバ処理により受信したメッセージの種類を識別するメッセージ判別処理と、
ユーザ端末にＳＩＰ要求の送信先を変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成処理と、
現用ＳＩＰサーバ又は予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新する処理とを前記プロキシ・サーバに実行させ、
前記宛先変更依頼応答生成処理は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる場合に、ユーザ端末にＳＩＰ要求の送信先を前記送信先対応情報で示される送信先に変更させる宛先変更依頼応答を生成し、
前記送信先対応情報を更新する処理は、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とするプログラム。
【請求項１１】
受信したメッセージの有効期限を更新する有効期限更新処理を前記プロキシ・サーバに実行させ、
前記有効期限更新処理は、受信したメッセージが認証ＲＥＧＩＳＴＥＲリクエストである場合に、当該認証ＲＥＧＩＳＴＥＲリクエストの有効期限を延長し、受信したメッセージが認証可を示すＳＩＰ応答である場合に、当該有効期限を短縮することを特徴とする請求項１０に記載のプログラム。
【請求項１２】
前記宛先変更依頼応答生成処理は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１０又は請求項１１に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、SIP（session
initiation protocol）を使用してシグナリングを行うネットワーク（通信網）等に利用される、外部の端末の登録情報をサーバ間で複製するプロキシ・サーバ、通信システム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
近年、VoIP（voice
over IP）に見られるように、IP網を使用したリアルタイム・コミュニケーションが普及している。例えば、電話端末やパソコンなどの、リアルタイム・コミュニケーションを行う両端の端末間接続を確立する国際標準プロトコルとしてSIP（session
initiation protocol）を採用する状況が多くなっている。なお、本明細書では、SIPを使用してシグナリングを行う通信網をSIPネットワークと呼ぶ。
【０００３】
SIPネットワークの一般的な構成は、後述する非特許文献１に記載されている。SIPネットワークは、ロケーション・サーバと、SIPサーバと、ユーザ・エージェント（UA：
user agent）とから構成されている。ユーザ・エージェントは、非特許文献１のP.76に、「SIPは、エンド・システム間のクライアント-サーバ・モデルに基づいています。このエンド・システムに相当するのが、ユーザ・エージェント（UA:
User Agent）です。ユーザ・エージェントとは、具体的には電話機やパソコンなどのエンド・システムのことですが、これらのエンド・システム間でリクエスト（要求）とレスポンス（応答）をやり取りすることによって、サービスを実現します」と説明されている。本明細書では、上記説明文記載のリクエストをSIP要求、レスポンスをSIP応答と呼ぶ。
【０００４】
SIPサーバは、非特許文献１のP.77に記載されているように、(1)
SIP要求やSIP応答を中継するプロキシ・サーバ機能と、(2) SIP要求の宛先の問合せに利用するリダイレクト・サーバ機能と、(3) SIPネットワーク上のユーザ・エージェント情報の登録を受け付ける登録サーバ機能とを有する。ここで、ユーザ・エージェント情報とは、例えば、ユーザ・エージェントにアクセスするための識別子であるURI（uniform
resource identifier）やユーザ・エージェントが使用するIPアドレスである。なお、本明細書では、このユーザ・エージェントにより登録されるユーザ・エージェント情報を登録情報と呼ぶ。
【０００５】
ロケーション・サーバは、非特許文献１のP.81に、「登録サーバで維持されるユーザ・エージェントの情報を蓄積し、プロキシ・サーバ機能やリダイレクト・サーバ機能によって利用される、データベース・サービスを提供します」と記載されている。具体的には、非特許文献１のP.112に記載されているように、SIP要求のREGISTERリクエストを使用して、ユーザ・エージェントの登録情報を更新する。
【０００６】
この登録情報の更新は、ある一つのSIPサーバに対してユーザ・エージェントがREGISTERリクエストを送信することが前提となっている。これは、図５６に示す、SIPで採用されているユーザ・エージェントの認証方式（Digest認証）において顕著である。
【０００７】
図５６は、SIPで採用されているDigest認証の流れを示すシーケンス図である。まず、ユーザ・エージェント２０００がSIPサーバ２５００に対してREGISTERリクエストを送信する。本明細書では、このユーザ・エージェント２０００が最初にSIPサーバ２５００に送信するREGISTERリクエストをinitial  REGISTERリクエストと呼ぶ。ユーザ・エージェント２０００からのinitial  REGISTERリクエストを受信したSIPサーバ２５００は、Digest認証で使用するnonceを生成し、そのnonce値をSIP応答（401）に付加してユーザ・エージェント２０００に返信する。ユーザ・エージェント２０００では、受信したnonceを鍵にユーザ識別子とパスワードをハッシュし、結果をAuthorizationヘッダに格納したREGISTERリクエストをSIPサーバ２５００に転送する。本明細書では、このAuthorizationヘッダを付加したREGISTERリクエストを認証REGISTERリクエストと呼ぶ。認証REGISTERリクエストを受信したSIPサーバ２５００は、ユーザ・エージェント２０００と同様、自身が生成したnonce値を使用して、ユーザ・エージェント２０００のユーザ識別子とパスワードをハッシュする。その後、ユーザ・エージェント２０００からの認証REGISTERリクエストに格納されたAuthorizationヘッダ値と比較し、同一の場合には、正当なユーザ・エージェントからのREGISTERリクエストであると判断し、REGISTERリクエストのデータを使用して登録情報を更新後、SIP応答（200  OK）を返信する。
【０００８】
この図５６から、まず、initial  REGISTERリクエストは、ユーザ・エージェント２０００のユーザ識別子とパスワードを参照可能なSIPサーバ２５００に送信される必要がある。SIPサーバ２５００で参照不可能な場合には、ユーザ識別子とパスワードを使用したハッシュが計算できないため、認証に失敗するからである。更に、initial  REGISTERリクエストと認証REGISTERリクエストとは同一のSIPサーバ２５００に転送される必要があることが分かる。転送されるSIPサーバ２５００が異なる場合には、nonce値がSIPサーバ２５００間で引き継がれないため、正当なユーザ・エージェント２０００からの認証REGISTERリクエストであっても、SIPサーバ２５００側でのハッシュが計算できず、認証に失敗するためである。
【０００９】
以上から、REGISTERリクエストは、ユーザ識別子とパスワードを参照可能なSIPサーバ２５００に対し、REGISTERリクエスト処理が完了するまで送信し続ける必要があることが分かる。
【００１０】
このような特徴を持つREGISTERリクエストのSIPサーバ２５００での処理を考慮すると、登録情報を他のSIPサーバ２５００に複製する場合には例えば以下の２つの形態が考えられる。なお、本明細書では、複製対象の登録情報を管理するSIPサーバ２５００を現用SIPサーバ３０００、複製された登録情報を管理するSIPサーバを予備SIPサーバ４０００と呼ぶ。更に、以下の３形態を示す図では、SIPサーバ２５００が２つのみ記載されているが、登録情報の複製先となるSIPサーバ２５００は何台でも構わない。
【００１１】
第１の形態は、ユーザ・エージェント２０００自身が複数のSIPサーバ２５００にREGISTERリクエストを転送する形態である。すなわち、第１の形態は、図５７に示すように、現用および予備SIPサーバ全てにユーザ・エージェント２０００のユーザ識別子とパスワードを保持させ、ユーザ・エージェント２０００が各SIPサーバと個別にDigest認証を行い、登録情報を更新していくのである。
【００１２】
第２の形態は、現用SIPサーバ３０００が予備SIPサーバ４０００にREGISTERリクエストを転送する形態である。すなわち、第２の形態は、図５８に示すように、ユーザ・エージェント２０００と現用SIPサーバ３０００がDigest認証を行い、登録情報の更新を完了した後、現用SIPサーバ３０００から予備SIPサーバ４０００にREGISTERリクエストを送信することによって、予備SIPサーバ４０００の登録情報を更新するのである。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】「改訂版  ＳＩＰ教科書」「ユーザ・エージェントとＳＩＰサーバの関係」（Ｐ．７８の図５−２）
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかし、上記の２形態のうち、第１の形態では、電話機等の簡易なユーザ・エージェント２０００に対しても複数SIPサーバへ２５００のREGISTERリクエスト転送機能を搭載する必要があり、ユーザ・エージェント２０００側にコストが掛かるという課題がある。更に、ユーザ・エージェント２０００とSIPサーバ２５００間での登録情報更新に掛かるトラフィックが、予備SIPサーバ４０００の数に比例して数倍程度に増加してしまうという課題もある。
【００１５】
更に、第２の形態では、既存SIPサーバ２５００において、REGISTERリクエストの受信・処理機能は有していても、他SIPサーバ２５００への発信機能は有していない可能性がある。そのため、このようなSIPサーバ２５００への機能拡張が必要となり、SIPサーバ２５００間での登録情報複製の実現にコストが掛かるという課題がある。
【００１６】
上記実施形態の課題を解決するために、図５９に示すように、ユーザ・エージェント２０００とSIPサーバ２５００との中間にプロキシ・サーバ１０００を配備する形態を想定し、このプロキシ・サーバ１０００のSIP要求とSIP応答を仲介する機能に着目すると、従来技術としてSIPプロキシ・サーバが挙げられる。SIPプロキシ・サーバが保持する機能は、非特許文献1において、ユーザ・エージェント２０００からのSIP要求を解釈し、必要な処理を行ってから、次の宛先にSIP要求を送信すると記載されている。
【００１７】
しかし、従来までのSIPプロキシ・サーバを活用し、既存のユーザ・エージェント２０００およびSIPサーバ２５００への適用容易性と、ユーザ・エージェント２０００とSIPサーバ２５００間のトラフィックの抑制に配慮して、登録情報を現用SIPサーバ３０００と予備SIPサーバ４０００間で複製する場合には下記の課題がある。
【００１８】
第１の課題は、SIPプロキシ・サーバでは登録情報の複製が実現できないことが挙げられる。これは、前記非特許文献1に記載されているように、SIPプロキシ・サーバはSIP要求を生成しないためである。つまり、SIPプロキシ・サーバは、予備SIPサーバ４０００へ送信するREGISTERリクエストを生成できないのである。
【００１９】
また、仮に、SIPプロキシ・サーバがREGISTERリクエストの生成を行えたとしても更に以下の課題が存在する。
【００２０】
第２の課題は、Digest認証を要求する予備SIPサーバ４０００に対し、ユーザ・エージェント２０００のユーザ識別子とパスワードを使用したDigest認証でREGISTERリクエストを送信することは不可能なことである。これは、ユーザ・エージェント２０００のユーザ識別子とパスワードを保持しないSIPプロキシ・サーバがユーザ・エージェント２０００のユーザ識別子とパスワードを獲得するためには、ユーザ・エージェント２０００と現用SIPサーバ３０００でのDigest認証を破るしか手段がないためである。
【００２１】
第３の課題は、ユーザ・エージェント２０００から現用SIPサーバ３０００宛に送信されたREGISTERリクエストの正当性を確認する手段を設けなければならないことである。これは、例えば、SIPネットワークに対してDoS（denial  of  service）攻撃を仕掛ける場合、ユーザ・エージェント２０００からのinitial  REGISTERリクエストには無意味なデータが格納され、大量に送信されることが想定される。この場合に、SIPプロキシ・サーバが、現用SIPサーバ３０００での処理結果を参照しないで、予備SIPサーバ４０００に対し、initial  REGISTERリクエストを複製・送信してしまうと、予備SIPサーバ４０００までもDoS攻撃を受けることになる。このように、プロキシ・サーバ１０００はユーザ・エージェント２０００から現用SIPサーバ３０００宛に送信されたREGISTERリクエストの正当性を確認する必要があるのである。
【００２２】
本発明の目的は、Digest認証を要求するサーバに対してアクセス者及び通信の正当性を示した上で、複数サーバ間で登録情報を複製することを可能とするSIPネットワークにおけるプロキシ・サーバを提供することである。
【課題を解決するための手段】
【００２３】
本発明の第１のプロキシ・サーバは、外部とメッセージを送受信するＳＩＰプロキシ・サーバ機能と、ＳＩＰプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、ユーザ端末とユーザ端末から自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報と、ユーザ端末にＳＩＰ要求の送信先を変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能と、現用ＳＩＰサーバ又は予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、送信先対応情報を更新する機能とを備え、宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ  ＲＥＧＩＳＴＥＲリクエストの送信先が送信先対応情報で示される送信先と異なる場合に、ユーザ端末にＳＩＰ要求の送信先を送信先対応情報で示される送信先に変更させる宛先変更依頼応答を生成し、送信先対応情報を更新する機能は、認証可を示すＳＩＰ応答のメッセージを、予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を現用ＳＩＰサーバに対応付け、現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を予備ＳＩＰサーバに対応付けることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、以下に説明する効果を達成することができる。
【００２５】
第１の効果は、登録情報の複製を実現できることである。これは、プロキシ・サーバが、プロキシ・サーバが本来有する機能に加え、予備SIPサーバに送信するREGISTERリクエスト（メッセージ）の生成機能を保持するためである。
【００２６】
第２の効果は、登録情報の複製に際し、予備SIPサーバへのアクセス者の正当性を予備SIPサーバに示すことが可能なことである。これは、プロキシ・サーバのユーザ識別子とパスワードをプロキシ・サーバに保持させ、プロキシ・サーバと予備SIPサーバ間でDigest認証を行うためである。
【図面の簡単な説明】
【００２７】
【図１】本発明の第１の実施の形態に係る通信システムの構成を示すブロック図である。
【図２】第１の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図３】第１の実施の形態に係る一時格納機能でのREGISTERリクエストの格納形態の一例を示す図である。
【図４】第１の実施の形態に係るプロキシ・サーバのハードウェア構成を示すブロック図である。
【図５】第１の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図６】第１の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図７】第１の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図８】本発明の第２の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図９】第２の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図１０】第２の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図１１】第２の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図１２】本発明の第３の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図１３】第３の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図１４】第３の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図１５】第３の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図１６】本発明の第４の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図１７】第４の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図１８】第４の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図１９】第４の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図２０】本発明の第５の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図２１】第５の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図２２】第５の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図２３】第５の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図２４】本発明の第６の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図２５】第６の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図２６】第６の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図２７】第６の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図２８】本発明の第７の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図２９】第７の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図３０】第７の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図３１】第７の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図３２】本発明の第８の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図３３】第８の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図３４】第８の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図３５】第８の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図３６】本発明の第９の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図３７】第９の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図３８】第９の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図３９】第９の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図４０】本発明の第１０の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図４１】第１０の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図４２】第１０の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図４３】第１０の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図４４】本発明の第１１の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図４５】第１１の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図４６】第１１の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図４７】第１１の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図４８】本発明の第１２の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図４９】第１２の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図５０】第１２の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図５１】第１２の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図５２】本発明の第１３の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
【図５３】第１３の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
【図５４】第１３の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
【図５５】第１３の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
【図５６】従来のSIPにおけるDigest認証の動作を示すシーケンス図である。
【図５７】従来の登録情報の複製に際し、ユーザ・エージェントが現用および予備SIPサーバへREGISTERリクエストを送信する形態を示す図である。
【図５８】従来の登録情報の複製に際し、現用SIPサーバが予備SIPサーバへREGISTERリクエストを送信する形態を示す図である。
【図５９】従来のユーザ・エージェントとSIPサーバの間にプロキシ・サーバを配備する形態を示す図である。
【発明を実施するための形態】
【００２８】
（第１の実施の形態）
次に、本発明の第１の実施の形態について、図表を参照して詳細に説明する。
【００２９】
（第１の実施の形態の構成）
図１に、本発明の第１の実施の形態に係る通信システムのブロック図を示す。
【００３０】
図１に示すように、本発明の第１の実施の形態に係る通信システムは、登録情報３１を有する現用ＳＩＰサーバ３０及びホットスタンバイしており登録情報４１を有する予備ＳＩＰサーバ４０と接続されるプロキシ・サーバ１０が、ネットワーク５０を介してユーザ・エージェント２０との通信を行う。ここで、ＳＩＰシステム１は、プロキシ・サーバ１０と、現用ＳＩＰサーバ３０と、予備ＳＩＰサーバ４０とを備え、ネットワーク５０に接続する。
【００３１】
次いで、図２に、本発明の第１の実施の形態に係るプロキシ・サーバ１０のブロック図を示す。
【００３２】
図２に示すように、本発明の第１の実施の形態に係るプロキシ・サーバ１０は、SIPプロキシ・サーバ機能１１に加え、SIPプロキシ・サーバ機能１１が受信したメッセージに関して、メッセージの種類と送信元を判別するメッセージ判別機能１２と、SIPプロキシ・サーバ機能１１が受信したREGISTERリクエストを一時的に格納する一時格納機能１３と、予備SIPサーバに転送するinitialおよび認証REGISTERリクエストを生成するリクエスト生成機能１４とを備える。
【００３３】
なお、一時格納機能１３は、例えば、以下のような形態でREGISTERリクエストを格納する。図３は、一時格納機能１３でのREGISTERリクエストの格納形態の一例を示す図である。この図に示すように、REGISTERリクエストは表形式で格納され、REGISTERリクエストの検索時に使用するCSeq、REGISTERリクエストのFromヘッダに格納される送信元を識別するユーザ・エージェント識別子、REGISTERリクエスト（プロキシ・サーバ１０が受信したREGISTERリクエスト）から構成される。
【００３４】
なお、プロキシ・サーバ１０が予備SIPサーバとの間で実施するDigest認証に使用する、プロキシ・サーバのユーザ識別子とパスワードは、認証REGISTERリクエスト生成時に必要となるため、リクエスト生成機能１４が保持する。
【００３５】
従って、本実施の形態の特徴として、プロキシ・サーバ１０は、プロキシ・サーバ１０自身のユーザ識別子とパスワードを用いてDigest認証によって、REGISTERリクエストの送受信を予備SIPサーバ４０と行う。
【００３６】
ここで、プロキシ・サーバ１０のハードウェア構成の説明をする。
【００３７】
図４は、本実施の形態による通信システムのプロキシ・サーバ１０のハードウェア構成を示すブロック図である。
【００３８】
図４を参照すると、本発明によるプロキシ・サーバ１０は、一般的なコンピュータ装置と同様のハードウェア構成によって実現することができ、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）３０１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等のメインメモリであり、データの作業領域やデータの一時退避領域に用いられる主記憶部３０２、ネットワーク５０を介してデータの送受信を行う通信制御部３０３、液晶ディスプレイ、プリンタやスピーカ等の提示部３０４、キーボードやマウス等の入力部３０５、周辺機器と接続してデータの送受信を行うインタフェース部３０６、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気ディスク、半導体メモリ等の不揮発性メモリから構成されるハードディスク装置である補助記憶部３０７、本情報処理装置の上記各構成要素を相互に接続するシステムバス３０８等を備えている。
【００３９】
本発明によるプロキシ・サーバ１０は、その動作を、プロキシ・サーバ１０内部にそのような機能を実現するプログラムを組み込んだ、ＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）等のハードウェア部品からなる回路部品を実装してハードウェア的に実現することは勿論として、上記した各構成要素の各機能を提供するプログラムを、コンピュータ処理装置上のＣＰＵ３０１で実行することにより、ソフトウェア的に実現することができる。
【００４０】
すなわち、ＣＰＵ３０１は、補助記憶部３０７に格納されているプログラムを、主記憶部３０２にロードして実行し、プロキシ・サーバ１０の動作を制御することにより、上述した各機能をソフトウェア的に実現する。
【００４１】
（第１の実施の形態の動作）
次に、本発明の第１の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。
【００４２】
図５に、本発明の第１の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートを示す。
【００４３】
いま、SIPプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップＳ４０１）。次に、メッセージ判別機能１２が、SIPプロキシ・サーバ機能１１によって受信したメッセージの種類を判別する（ステップＳ４０２）。
【００４４】
ステップＳ４０２の結果、受信したメッセージがSIP応答（200  OK）の場合には、更に、メッセージ判別機能１２が上記受信したメッセージの送信元を判別する（ステップＳ４０３）。
【００４５】
ステップＳ４０３の結果、送信元が現用SIPサーバの場合には、リクエスト生成機能１４が、予備SIPサーバに送信するinitial  REGISTERリクエストを生成する（ステップＳ４０５）。
【００４６】
例えば、この生成処理は下記のようになる。まず、リクエスト生成機能１４は、一時格納機能１３に格納されているREGISTERリクエストのうち、ステップＳ４０１で受信したSIP応答（200  OK）に対応するREGISTERリクエストを選定する。この選定処理は、SIP応答（200  OK）でのCSeqヘッダとFromヘッダの値と同一の値を持つREGISTERリクエストを検索することによって実現できる。
【００４７】
次に、リクエスト生成機能１４は、選定したREGISTERリクエストのヘッダ値を複製し、必要に応じて変更することによって、予備SIPサーバ４０に送信する上記initial  REGISTERリクエストを生成する。この変更対象となるヘッダには、例えば、ToヘッダやFromヘッダに格納されるURIやCall-IDヘッダおよびCSeqヘッダなどがある。
【００４８】
従って、ステップＳ４０５の結果、プロキシ・サーバ１０は、プロキシ・サーバ１０自身で生成したinitial  REGISTERリクエストについて、予備SIPサーバ４０と送受信を行う。
【００４９】
ステップＳ４０２の結果、受信したメッセージがREGISTERリクエストの場合には、一時格納機能１３が、受信した当該REGISTERリクエストを複製し、格納する（ステップＳ４０６）。
【００５０】
この複製処理で格納されたREGISTERリクエストが前述したステップＳ４０５で活用されるのである。なお、このステップＳ４０２およびステップＳ４０６の処理において、例えばDoS攻撃等、ユーザ・エージェントからの不当なREGISTERリクエストの複製・格納を極力排除するには、ステップＳ４０２で識別するREGISTERリクエストを認証REGISTERリクエストとし、ステップＳ４０６でこの認証REGISTERリクエストを格納することになる。
【００５１】
ステップＳ４０２の結果、ステップＳ４０１で受信したメッセージがSIP応答（401  Unauthorized）の場合には、更に、メッセージ判別機能１２が、メッセージの送信元を判別する（ステップＳ４０７）。
【００５２】
ステップＳ４０７の結果、SIP応答（401  Unauthorized）の送信元が予備SIPサーバであった場合には、予備SIPサーバとのDigest認証を完了すべく、リクエスト生成機能１４が、予備SIPサーバに転送する認証REGISTERリクエストを生成する（ステップＳ４０８）。
【００５３】
この生成処理は、図５６で示した、一般的なDigest認証の処理に従う。具体的には、リクエスト生成機能１４が、SIP応答（401  Unauthorized）に格納されているnonce値を鍵に、プロキシ・サーバ１０自身のユーザ識別子とパスワードの組を、認証やデジタル署名などに使われるハッシュ関数の一つであるＭＤ５（ｍｅｓｓａｇｅ  ｄｉｇｅｓｔ  ５）でハッシュし、その後、ステップＳ４０５でのinitial  REGISTERメッセージ生成と同様の処理で認証REGISTERリクエストを生成する。ここで、ステップＳ４０５との差異は、Authorizationヘッダを設け、そのヘッダに計算したハッシュ値を格納することである。
【００５４】
従って、ステップＳ４０８の結果、プロキシ・サーバ１０は、プロキシ・サーバ１０自身のユーザ識別子とパスワードを用いてDigest認証によって、認証REGISTERリクエストの送受信を予備SIPサーバ４０と行う。
【００５５】
ステップＳ４０２の結果、受信したメッセージがSIP応答（200  OK）またはREGISTERリクエストまたはSIP応答（401  Unauthrized）でない場合には、更に、メッセージ判別機能１２が、メッセージの送信元を判別する（ステップＳ４０９）。
【００５６】
ステップＳ４０９の結果、送信元が現用SIPサーバであった場合、または、ステップＳ４０５の結果、予備SIPサーバに送信するinitial  REGISTERリクエストを生成した場合、または、ステップＳ４０６の結果、ユーザ・エージェントから送信されたREGISTERリクエストを複製・格納した場合、または、ステップＳ４０８の結果、予備SIPサーバに送信する認証REGISTERを生成した場合、または、ステップＳ４０７の結果、SIP応答（401  Unauthorized）の送信元が現用SIPサーバの場合には、SIPプロキシ・サーバ機能１１が、ステップＳ４０１で受信したメッセージをメッセージに指定された宛先に、または、initialおよび認証REGISTERリクエストを予備SIPサーバに送信する（ステップＳ４１０）。
【００５７】
ステップＳ４０３の結果、SIP応答（200  OK）の送信元が予備SIPサーバの場合、または、ステップＳ４０９の結果、その他のSIP応答の送信元が予備SIPサーバの場合には、一時格納機能１３によって格納されているREGISTERリクエストを削除する（ステップＳ４０４）。
【００５８】
この削除処理は、例えば、ステップＳ４０１で受信したSIP応答のCSeqヘッダとFromヘッダの値と同一の値を持つREGISTERリクエストを検索することで実現可能である。
【００５９】
ステップＳ４０４の結果、該当REGISTERリクエストを削除した場合、または、ステップＳ４１０の結果、SIPプロキシ・サーバ機能１１がメッセージを送信した場合には処理を終了する。
【００６０】
次に、本発明の第１の実施の形態に係るプロキシ・サーバ１０を含むシステム全体の動作について図表を参照して詳細に説明する。
【００６１】
まず、図６に本発明の第１の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示す。
【００６２】
図６に示すように、このシステムでは、ユーザ・エージェント２０から送信されるREGISTERリクエストは常に現用SIPサーバ３０に転送される（図６のａ）。同時に、このREGISTERリクエストをプロキシ・サーバ１０が複製し、保持する。
【００６３】
プロキシ・サーバ１０は、現用SIPサーバ３０からのSIP応答（200  OK）受信後（図６のｂ）、複製したREGISTERリクエストに基づいて予備SIPサーバ４０へ送信するREGISTERリクエストを生成し、予備SIPサーバ４０へ転送する（図６のｃ）。
【００６４】
また、本発明の第１の実施の形態に係るプロキシ・サーバ１０を含めたシステム全体での動作シーケンスを図７に示す。なお、この図は、ユーザ・エージェント２０からの認証REGISTERリクエストをプロキシ・サーバ１０で複製する場合を示している。
【００６５】
図７に示すように、プロキシ・サーバ１０は、ユーザ・エージェント２０から現用SIPサーバ３０へ宛てたREGISTERリクエストの処理完了を確認後（200  OK受信後）、プロキシ・サーバ１０自身のユーザ識別子とパスワードと、ユーザ・エージェント２０から受信したREGISTERリクエストとに基づいて生成したREGISTERリクエストを予備SIPサーバ４０に送信し、予備SIPサーバ４０との間でDigest認証を行う。
【００６６】
（第１の実施の形態の効果）
このように、本実施の形態よれば、予備SIPサーバ４０にアクセス者（プロキシ・サーバ１０）と送信するREGISTERリクエストの正当性を示すことができる。
【００６７】
その理由は、プロキシ・サーバ１０のユーザ識別子とパスワードを保持するプロキシ・サーバ１０を含めたシステムが、ユーザ・エージェント２０から送信されたREGISTERリクエストの正常処理完了を確認した後、予備SIPサーバ４０とDigest認証を行い、当該正常処理が完了したREGISTERリクエストに基づいて生成したREGISTERリクエスト（現用SIPサーバ３０で処理されたものの複製）を予備SIPサーバ４０に送信するからである。
【００６８】
また、本実施の形態よれば、既存ユーザ・エージェントおよび既存SIPサーバへの適用が技術的・経済的に容易であり、また、現用SIPサーバ３０と予備SIPサーバ４０間で登録情報をアクティブかつ相互にバックアップできる。
【００６９】
その理由は、REGISTERリクエストの複製・送信をプロキシ・サーバ１０が担当することで、ユーザ・エージェント２０はSIPで規定された登録情報更新手順に則ってREGISTERリクエストをプロキシ・サーバ１０に送信するだけでよく、かつ、各SIPサーバは従来から保持する機能に基づき、一般的なDigest認証に従い認証されたREGISTERリクエストを処理するだけでよいからである。この結果、ユーザ・エージェント２０がREGISTERリクエストを送信したタイミングで現用SIPサーバ３０および予備SIPサーバ４０登録情報が共に更新される。更に、各SIPサーバは、登録情報複製のためにプロキシ・サーバ１０が生成したREGISTERリクエストと、ユーザ・エージェント２０が送信したREGISTERリクエストとが同様に処理されるため、ＳＩＰシステム１は、ユーザ・エージェント２０が送信したREGISTERリクエストとプロキシ・サーバ１０が生成したREGISTERリクエストとを混合して各SIPサーバに送信することが可能である。これらの特徴により、登録情報をアクティブかつ相互にバックアップできるのである。
【００７０】
さらに、本実施の形態よれば、ユーザ・エージェント２０とSIPサーバ間の登録情報更新に掛かるトラフィック量を抑制できる。
【００７１】
その理由は、予備SIPサーバ４０へのREGISTERリクエストの送信を、現用SIPサーバ３０とユーザ・エージェント２０の中間に位置するプロキシ・サーバ１０が行うためである。すなわち、一般的に、ユーザ・エージェント２０が存在するパーソナルコンピュータや携帯電話は、接続するアクセス網の帯域が、SIPサーバが存在するコア・ネットワークの帯域よりも格段に狭いところ、プロキシ・サーバ１０がREGISTERリクエストの複製・送信を実現することで、ユーザ・エージェント２０から送信されるREGISTERリクエストを削減でき、結果、アクセス網での使用帯域を抑制することができるからである。
【００７２】
（第２の実施の形態）
次に、本発明の第２の実施の形態に係るプロキシ・サーバ１０について図表を参照しながら詳細に説明する。
【００７３】
（第２の実施の形態の構成）
図８に、本発明の第２の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図を示す。
【００７４】
図８に示すように、本発明の第２の実施の形態に係るプロキシ・サーバ１０は、一般的なSIPプロキシ・サーバ機能１１に加えて、SIPプロキシ・サーバ機能１１が受信したメッセージの種類を識別するメッセージ判別機能１２と、SIPプロキシ・サーバ機能１１が受信したメッセージに含まれるExpiresヘッダの値を変更（増加・減少）する有効期限更新機能１５と、REGISTERリクエストの宛先を決定する際に参照する情報（宛先情報）に基づき、REGISTERリクエストの送信先を決定する宛先決定機能１６とを備える。
【００７５】
なお、宛先情報は、例えば、ユーザ・エージェント２０とREGISTERリクエストの転送先との組として実現でき、宛先決定機能１６に保持される。
【００７６】
（第２の実施の形態の動作）
次に、本発明の第２の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。
【００７７】
図９は、本発明の第２の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【００７８】
いま、SIPプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップＳ７０１）。次に、メッセージ判別機能１２が、SIPプロキシ・サーバ機能１１によって受信したメッセージの種別を判別する（ステップＳ７０２）。
【００７９】
ステップＳ７０２の結果、受信したメッセージがREGISTERリクエストである場合には、有効期限更新機能１５が、REGISTERリクエストのExpiresヘッダの値を増加させる（ステップＳ７０３）。
【００８０】
この更新処理は、例えば、１台の予備SIPサーバ４０が存在する場合には２倍、２台の予備SIPサーバ４０が存在する場合には３倍など、予備SIPサーバ数に応じて当該Expiresヘッダの値を増加させる。
【００８１】
次に、宛先決定機能１６が、REGISTERリクエストの送信先を決定する（ステップＳ７０４）。
【００８２】
この決定処理は、例えば、以下のように実現できる。すなわち、宛先決定機能１６は、REGISTERリクエストのFromヘッダに記載されたユーザ・エージェント２０の識別子を参照して、宛先情報から該当ユーザ・エージェント２０からのREGISTERリクエストの転送先を取得する。この転送先には、現用SIPサーバ３０または予備SIPサーバ４０が記載されている。
【００８３】
ステップＳ７０４において、宛先決定機能１６は、REGISTERリクエストがinitial  REGISTERリクエストの場合には、該当転送先に記載されていない転送先（現用SIPサーバ３０と記載されていれば「予備SIPサーバ４０」）をREGISTERリクエストの送信先とし、一方、REGISTERリクエストが認証REGISTERリクエストの場合には、該当転送先をREGISTERリクエストの転送先とする。
【００８４】
その後、宛先決定機能１６は、ステップＳ７０４で決定した宛先を宛先情報に反映させる（ステップＳ７０５）。
【００８５】
ステップＳ７０２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがSIP応答（200  OK）の場合には、有効期限更新機能１５が該当SIP応答のExpiresヘッダの値を減少させる（ステップＳ７０６）。
【００８６】
この更新処理は、ステップＳ７０３の更新処理で増加した分を減少させる。すなわち、例えば、有効期限更新機能１５は、ステップＳ７０３においてREGISTERリクエストのExpiresヘッダ値を２倍した場合には、ステップＳ７０５において当該Expiresヘッダ値を１/２とするのである。
【００８７】
ステップＳ７０２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類がREGISTERリクエストおよびSIP応答（200  OK）でない場合、または、ステップＳ７０５の結果、宛先情報の更新が完了した場合、または、ステップＳ７０６の結果、SIP応答（200  OK）のExpiresヘッダの値を減少した場合には、SIPプロキシ・サーバ機能１１が、指定された宛先にメッセージを送信する（ステップＳ７０７）。指定される宛先は、REGISTERリクエストの場合にはステップＳ７０４で決定された宛先であり、それ以外はSIPプロキシ・サーバ機能１１が受信したメッセージに記載された宛先である。
【００８８】
次に、本発明の第２の実施の形態に係るプロキシ・サーバ１０を含むシステム全体の動作について図表を参照して詳細に説明する。
【００８９】
まず、図１０に本発明の第２の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示す。
【００９０】
図１０に示すように、このシステムでは、ユーザ・エージェント２０から送信されるREGISTERリクエストは全て現用SIPサーバ３０に送信される訳ではない。プロキシ・サーバ１０は、例えば、現用SIPサーバ３０へ転送した次は、予備SIPサーバ４０へ転送、という具合に、現用SIPサーバ３０および予備SIPサーバ４０へREGISTERリクエストを順番に転送する（図１０のａとｂ）。つまり、現用SIPサーバ３０および予備SIPサーバ４０へは各々数回に一度しかREGISTERリクエストが転送されないことになる。この状況でも、ユーザ・エージェント２０に関する登録情報が無効とならないように、プロキシ・サーバ１０は、ユーザ・エージェント２０から受信したREGISTERリクエストの有効期限を変更して現用SIPサーバ３０および予備SIPサーバ４０へREGISTERリクエストを転送する。
【００９１】
また、第２の実施の形態に係るプロキシ・サーバ１０を含めたシステム全体の動作シーケンスを図１１に示す。
【００９２】
図１１に示すように、プロキシ・サーバ１０は、ユーザ・エージェント２０からinitial  REGISTERリクエストを受信した場合には、現用SIPサーバ３０と予備SIPサーバ４０のいずれに当該initial  REGISTERリクエストを送信するかを決定する一方、ユーザ・エージェント２０から認証REGISTERリクエストを受信した場合には、Digest認証を完了するために、initial  REGISTERリクエストを送信した先に当該認証REGISTERリクエストを転送している。
【００９３】
（第２の実施の形態の効果）
本実施の形態によれば、ユーザ・エージェント２０の保持している、ユーザ・エージェント２０を識別するユーザＩＤ（ユーザ・エージェント識別子）およびパスワードのみを用いて各SIPサーバの登録情報の複製が可能となる。
【００９４】
その理由は、宛先決定機能１６を備えることによって、ユーザ・エージェント２０と現用SIPサーバ３０間で行われたDigest認証が、ユーザ・エージェント２０と予備SIPサーバ４０間においても行われるからである。
【００９５】
また、本実施の形態によれば、各SIPサーバへは数回に一度しか到着しないREGISTERリクエストでも登録情報の有効期限が切れないようになっている。
【００９６】
その理由は、有効期限更新機能１５が、認証REGISTERリクエストのExpiresヘッダの値を増加させるからである。
【００９７】
また、本実施の形態によれば、既存ユーザ・エージェントおよび既存SIPサーバへの適用が技術的・経済的に容易であり、また、現用SIPサーバ３０と予備SIPサーバ４０間で登録情報をアクティブかつ相互にバックアップできる。この結果、ユーザ・エージェント２０が発行するREGISTERリクエストを現用または予備SIPサーバ４０へ順に転送するため、このExpiresヘッダ値程度の間隔で登録情報が随時更新される。更に、各SIPサーバは、登録情報複製のためにプロキシ・サーバ１０が宛先を変更したREGISTERリクエストと、ユーザ・エージェント２０が送信したREGISTERリクエストとが同様に処理されるため、ＳＩＰシステム１は、ユーザ・エージェント２０が送信したREGISTERリクエストと、プロキシ・サーバ１０が宛先を変更したREGISTERリクエストとを混合して各SIPサーバに送信することが可能である。これらの特徴により、登録情報をアクティブかつ相互にバックアップできるのである。
【００９８】
その理由は、プロキシ・サーバ１０が、REGISTERリクエストの送信先の変更およびExpiresヘッダの値の調整を行うからであるため、第１の実施の形態と同様に、ユーザ・エージェント２０および各SIPサーバからすれば、通常のREGISTERリクエストの処理として実現されているからである。
【００９９】
また、本実施の形態によれば、第１の実施の形態と異なり、プロキシ・サーバ１０が、自身のユーザ識別子とパスワードを保持する必要がない。
【０１００】
その理由は、宛先決定機能１６を備えることによって、ユーザ・エージェント２０と予備SIPサーバ４０間でDigest認証が行われるため、プロキシ・サーバ１０と予備SIPサーバ４０間でのDigest認証が不要だからであり、プロキシ・サーバ１０でのメッセージの生成が不要だからである。
【０１０１】
（第３の実施の形態）
次に、本発明の第３の実施の形態に係るプロキシ・サーバ１０について、図面を参照して詳細に説明する。
【０１０２】
（第３の実施の形態の構成）
図１２に、本発明の第３の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図を示す。
【０１０３】
図１２に示すように、本発明の第３の実施の形態に係るプロキシ・サーバ１０は、SIPプロキシ・サーバ機能１１に加えて、メッセージの種類および送信元を識別するメッセージ判別機能１２と、ユーザ・エージェントにinitial  REGISTERリクエストの再送を促すSIP応答（再送応答）を生成する再送応答生成機能１７と、宛先情報を参照してREGISTERリクエストの転送先を決定する宛先決定機能１６とを備える。
【０１０４】
なお、宛先情報は、本発明の第２の実施の形態に係るプロキシ・サーバ１０と同様に、例えば、ユーザ・エージェント２０とREGISTERリクエストの送信先との組であり、宛先決定機能１６に保持される。
【０１０５】
（第３の実施の形態の動作）
次に、本発明の第３の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。
【０１０６】
図１３は、本発明の第３の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【０１０７】
いま、SIPプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップＳ１００１）。次に、メッセージ判別機能１２が、SIPプロキシ・サーバ機能１１によって受信したメッセージの種類を判定する（ステップＳ１００２）。
【０１０８】
ステップＳ１００２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類がREGISTERリクエストの場合には、宛先決定機能１６がREGISTERリクエストの送信先を決定する（ステップＳ１００３）。
【０１０９】
この決定処理は、例えば、以下のようにして実現できる。宛先決定機能１６が、受信したREGISTERリクエストのFromヘッダに記載されているユーザ・エージェント２０の識別子に基づいて宛先情報を検索する。宛先決定機能１６は、この検索の結果、宛先情報に記載されている送信先をREGISTERリクエストの送信先とするのである。
【０１１０】
また、ステップＳ１００２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類がSIP応答（200  OK）の場合には、更に、メッセージ判別機能１２が、メッセージの送信元を判別する（ステップＳ１００４）。
【０１１１】
ステップＳ１００４の結果、送信元が現用SIPサーバ３０の場合には、再送応答生成機能１７が、ユーザ・エージェント２０にinitial  REGISTERリクエストを再送させるための再送応答を生成する（ステップＳ１００５）。
【０１１２】
この生成処理は、例えば、SIPプロキシ・サーバ機能１１が、SIPで「サービスを利用できない」ことを示すSIP応答（503  Service  Unavailable）に、「Retry-Afterヘッダ」を付加することによって、これを受信したユーザ・エージェント２０はRetry-Afterヘッダ値経過後に再度initial  REGISTERリクエストをプロキシ・サーバ１０に転送することになる。なお、その他のヘッダは現用SIPサーバ３０からのSIP応答（200  OK）を使用する。また、この生成処理の他の方法としては、例えば、SIPプロキシ・サーバ機能１１が、SIP応答（408  Request  Timeout）をユーザ・エージェント２０に送信することによって、ユーザ・エージェント２０は該当SIP応答受信後いつでもSIP要求の修正なしでプロキシ・サーバ１０に再送信することになる。
【０１１３】
ステップＳ１００４の結果、SIP応答（200  OK）の送信元が予備SIPサーバ４０であった場合、または、ステップＳ１００５の結果、ユーザ・エージェントへの再送応答の生成が完了した場合には、宛先決定機能１６が、宛先情報を更新する（ステップＳ１００６）。
【０１１４】
この更新処理は、例えば、以下のようになる。まず、宛先決定機能１６が、SIP応答（200  OK）のToヘッダに記載されているユーザ・エージェント２０を参照して、宛先情報を検索しておく。SIP応答（200  OK）が現用SIPサーバ３０から送信された場合には、宛先決定機能１６は、該当宛先情報のREGISTERリクエストの転送先を「予備SIPサーバ４０」に変更する。一方、SIP応答（200  OK）が予備SIPサーバ４０から送信された場合には、宛先決定機能１６は、該当宛先情報のREGISTERリクエストの転送先を「現用SIPサーバ３０」と変更する。
【０１１５】
ステップＳ１００２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがREGISTERリクエストおよびSIP応答（200  OK）でない場合、または、ステップＳ１００３の結果、REGISTERリクエストの送信先が決定された場合、または、ステップＳ１００６の結果、宛先情報が更新された場合には、SIPプロキシ・サーバ機能１１が、指定された宛先にメッセージを送信する（ステップＳ１００７）。
【０１１６】
この時、REGISTERリクエストはステップＳ１００３で決定された宛先に送信され、現用SIPサーバ３０からのSIP応答（200  OK）以外のSIP応答と、ステップＳ１００５で生成された再送応答はユーザ・エージェント２０へ送信される。
【０１１７】
次に、本発明の第３の実施の形態に係るプロキシ・サーバ１０を含むシステム全体の動作について図表を参照して詳細に説明する。
【０１１８】
まず、図１４に本発明の第３の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示す。
【０１１９】
図１４に示すように、ユーザ・エージェント２０から送信されたREGISTERリクエスト（図１４のａ）の処理完了を示すSIP応答（200  OK）（図１４のｂ）を受信したプロキシ・サーバ１０は、ユーザ・エージェント２０にREGISTERリクエストの再送応答（図１４のｃ）を送信する。
【０１２０】
再送応答を受信したユーザ・エージェント２０は、SIPのプロトコル規約で規定されている処理に従って再度REGISTERリクエストをプロキシ・サーバ１０に送信し、プロキシ・サーバ１０は、この再送されたREGISTERリクエストを予備SIPサーバ４０に転送する（図１４のｄ）。
【０１２１】
次に、本発明の第３の実施の形態に係るプロキシ・サーバ１０を含むシステム全体の動作シーケンスを図１５に示す。
【０１２２】
図１５に示すように、本実施の形態に係るプロキシ・サーバ１０を含むシステムは、現用SIPサーバ３０でのREGISTERリクエストの処理が完了した場合（SIP応答（200  OK）受信）には、ユーザ・エージェント２０に対し、initial  REGISTERリクエストの再送応答を送信し、それに基づき、ユーザ・エージェント２０が送信したinitial  REGISTERリクエストを予備SIPサーバ４０に転送することで、現用・予備SIPサーバの登録情報を、Digest認証を行いながら更新することができる。ユーザ・エージェント２０からすれば、最初のREGISTERリクエスト処理は失敗するが、SIPの規定に従った再送処理により登録情報の更新が完了したと認識される。一方、現用SIPサーバ３０では通常のREGISTERリクエストの処理として認識される。
【０１２３】
（第３の実施の形態の効果）
本実施の形態によれば、ユーザ・エージェント２０の保持している、ユーザ・エージェント２０を識別するユーザＩＤ（ユーザ・エージェント識別子）およびパスワードのみを用いて各SIPサーバの登録情報の複製が可能となる。
【０１２４】
その理由は、再送応答変更機能１７および宛先決定機能１６を備えることによって、現用SIPサーバ３０での登録情報の更新が成功したにもかかわらず、ユーザ・エージェント１０へは登録情報の処理の失敗を伝達して、ユーザ・エージェント２０での登録情報の処理を再度誘発し、ユーザ・エージェント２０から再送されたREGISTERリクエストを予備SIPサーバ４０へ転送してユーザ・エージェント２０と予備SIPサーバ４０間でのDigest認証を実行させるからである。
【０１２５】
また、本実施の形態によれば、現用SIPサーバ３０および予備SIPサーバ４０の登録情報を、プロキシ・サーバ１０で予備SIPサーバ４０宛のメッセージを生成することなく、Digest認証を行いながら更新することができる。
【０１２６】
その理由は、本実施の形態に係るプロキシ・サーバ１０を含むシステムが、現用SIPサーバ３０でのREGISTERリクエストの処理が完了した場合（SIP応答（200  OK）受信）には、ユーザ・エージェント２０に対してinitial  REGISTERリクエストの再送応答を送信し、当該再送応答に基づいてユーザ・エージェント２０が送信したinitial  REGISTERリクエストを受信して予備SIPサーバ４０に転送するからである。
【０１２７】
（第４の実施の形態）
次に、本発明の第４の実施の形態に係るプロキシ・サーバ１０に関して、図表を参照して詳細に説明する。
【０１２８】
（第４の実施の形態の構成）
図１６は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０１２９】
図１６に示すように、本発明の第４の実施の形態に係るプロキシ・サーバ１０は、SIPプロキシ・サーバ機能１１に加えて、SIPプロキシ・サーバ機能１１が受信したメッセージの種類を解析し、かつ受信したメッセージがinitial  REGISTERリクエストの場合にExpiresヘッダをさらに解析するメッセージ解析機能１８と、initial  REGISTERリクエストのExpiresヘッダの値がある閾値未満の場合にExpiresヘッダの値を変更する旨をユーザ・エージェント２０に伝えるSIP応答を生成する有効期限変更依頼応答生成機能１９と、宛先情報を参照してREGISTERリクエストの転送先を決定する宛先決定機能１６とを備える。
【０１３０】
なお、宛先情報は、本発明の第２ないし第３の実施の形態に係るプロキシ・サーバ１０と同様に、例えば、ユーザ・エージェント２０とREGISTERリクエストの送信先との組であり、宛先決定機能１６に保持される。
【０１３１】
（第４の実施の形態の動作）
次に、本発明の第４の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。
【０１３２】
図１７は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【０１３３】
いま、SIPプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップＳ１３０１）。次に、メッセージ解析機能１８が、SIPプロキシ・サーバ機能１１によって受信したメッセージの種類を識別する（ステップＳ１３０２）。
【０１３４】
ステップＳ１３０２の結果、受信したメッセージがinitial  REGISTERリクエストの場合には、更に、メッセージ解析機能１８がinitial  REGISTERリクエストのExpiresヘッダを参照する（ステップＳ１３０３）。
【０１３５】
ステップＳ１３０３の結果、Expiresヘッダの値がある閾値未満の場合には、有効期限変更依頼応答生成機能１９が有効期限変更依頼応答を生成する（ステップＳ１３０４）。
【０１３６】
ここで、この閾値としては、例えば、本発明の第２の実施の形態に係るプロキシ・サーバ１０と同様に、１台の予備SIPサーバ４０が存在する場合には標準的なExpiresヘッダ値（3600秒）の２倍、２台の予備SIPサーバ４０が存在する場合には３倍など、予備SIPサーバ数に応じて決定しておく。
【０１３７】
更に、ステップＳ１３０４の有効期限変更依頼応答生成機能１９が生成するSIP応答としては、例えば、４２３（Interval  Too  Brief）が挙げられる。
【０１３８】
このSIP応答は、REGISTERリクエストによりリフレッシュされる登録情報の有効期限時間が短すぎる場合にユーザ・エージェント２０に送信されるものである。このSIP応答（423  Interval  Too  Brief）ではMin-Expiresヘッダに希望する有効期限を指定できるため、例えば、前述の閾値を使用する。
【０１３９】
ステップＳ１３０３の結果、Expiresヘッダ値が閾値以上の場合、または、ステップＳ１３０２の結果、受信したメッセージが認証REGISTERリクエストの場合には、宛先決定機能１６が宛先情報を参照してREGISTERリクエストの宛先を決定する（ステップＳ１３０５）。
【０１４０】
例えば、この決定処理は下記のようにして実現できる。initialおよび認証REGISTERリクエストのFromヘッダに記載されているユーザ・エージェント２０の識別子に基づいて宛先情報を検索する。この検索の結果、宛先情報に記載されている送信先をinitialおよび認証REGISTERリクエストの送信先とするのである。
【０１４１】
ステップＳ１３０２の結果、受信したメッセージがSIP応答（200  OK）の場合には、宛先決定機能１６が保持する宛先情報を更新する（ステップＳ１３０６）。
例えば、この更新処理は以下のようにして実現できる。宛先決定機能１６が、受信したSIP応答（200  OK）のFromヘッダに記載されているユーザ・エージェント２０の識別子に基づいて宛先情報を検索しておく。次に、宛先決定機能１６は、受信したSIP応答（200  OK）の送信元を調査し、送信元が現用SIPサーバ３０の場合には検索結果の送信先を「予備SIPサーバ４０」と、送信元が予備SIPサーバ４０の場合には検索結果の送信先を「現用SIPサーバ３０」とする。
【０１４２】
ステップＳ１３０２の結果、受信したメッセージがinitialないし認証REGISTERリクエストまたはSIP応答（200  OK）以外の場合、または、ステップＳ１３０４の結果、有効期限変更依頼応答機能１９がユーザ・エージェント２０に対して有効期限変更依頼応答を生成した場合、または、ステップＳ１３０５の結果、initialないし認証REGISTERリクエストの宛先が決定した場合、または、ステップＳ１３０６の結果、宛先情報の更新が完了した場合には、SIPプロキシ・サーバ機能１１が、指定された宛先にメッセージを送信する（ステップＳ１３０７）。具体的には、initialないし認証REGISTERリクエストはステップＳ１３０６で決定されたSIPサーバに送信し、または、それ以外はユーザ・エージェント２０に送信する。
【０１４３】
次に、本発明の第４の実施の形態に係るプロキシ・サーバ１０を含むシステム全体の動作について図表を参照して詳細に説明する。
【０１４４】
まず、図１８に、本発明の第４の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示す。
【０１４５】
図１８に示すように、ユーザ・エージェント２０から送信されたREGISTERリクエスト（図１８のａ）を受信したプロキシ・サーバ１０は、REGISTERリクエストのExpiresヘッダの値を調査し、ある閾値以下の場合には、Expiresヘッダ値を変更するようにユーザ・エージェント２０に要請する有効期限変更依頼応答（図１８のｂ）を転送する。
【０１４６】
有効期限変更依頼応答を受信したユーザ・エージェント２０は、SIPのプロトコル規約で規定されている処理に従って、Expiresヘッダ値を変更したREGISTERリクエストを送信する（図１８のｃ）。
【０１４７】
更に、この一連の流れは、本発明の第２の実施の形態に係るプロキシ・サーバ１０と同様に、現用SIPサーバ３０と予備SIPサーバ４０で順番に実行される。つまり、現用SIPサーバ３０および予備SIPサーバ４０へは数回に一度しかREGISTERリクエストが各々転送されない。
【０１４８】
次いで、図１９に、システム全体の動作を示すシーケンス図を示す。図１９に示すように、プロキシ・サーバ１０は、受信したinitial  REGISTERリクエストのExpiresヘッダを調査し、閾値以上の場合には、送信先のSIPサーバを決定した後initial  REGISTERリクエストを該当SIPサーバに送信する（図１９のシーケンス（１））。
【０１４９】
一方で、initial  REGISTERリクエストのExpiresヘッダが閾値未満の場合には、プロキシ・サーバ１０は、Expiresヘッダ値の更新依頼を示すSIP応答（423  Interval  too  Brief）をユーザ・エージェント２０に返答することで、Expiresヘッダ値を変更したinitial  REGISTERリクエストを受信する（図１９のシーケンス（２））。
【０１５０】
更に、どちらの場合でも、認証REGISTERリクエストはinitial  REGISTERリクエストの送信先と同一のSIPサーバに送信される。ユーザ・エージェント２０からすれば、最初REGISTERリクエストの処理が失敗するが、SIPの規定に従った再送処理により登録情報の更新が完了したと認識される。
【０１５１】
一方、SIPサーバにおいて登録情報の有効期限を延長するため、数回に一度しかREGISTERリクエストを受信しないにも係らず、登録情報の有効期限が切れないようになっている。
【０１５２】
（第４の実施の形態の効果）
本実施の形態によれば、ユーザ・エージェント２０の保持している、ユーザ・エージェント２０を識別するユーザＩＤ（ユーザ・エージェント識別子）およびパスワードのみを用いて各SIPサーバの登録情報の複製が可能となる。
【０１５３】
その理由は、宛先決定機能１６を備えることによって、ユーザ・エージェント２０と現用SIPサーバ３０間で行われたDigest認証が、ユーザ・エージェント２０と予備SIPサーバ４０間においても行われるからである。
【０１５４】
また、本実施の形態によれば、各SIPサーバは数回に一度しかREGISTERリクエストを受信しないにも係らず、登録情報の有効期限が切れない。
【０１５５】
その理由は、SIPプロキシ・サーバ機能１１が外部から受信したメッセージをメッセージ解析機能１８が識別し、受信したメッセージがinitial  REGISTERリクエストの場合には、更に、メッセージ解析機能１８がinitial  REGISTERリクエストのExpiresヘッダを参照し、Expiresヘッダの値がある閾値未満の場合には、有効期限変更依頼応答生成機能１９が有効期限変更依頼応答を生成してユーザ・エージェント２０からExpiresヘッダ値を変更したinitial  REGISTERリクエストをプロキシ・サーバ１０が受信することにより、SIPサーバにおいて登録情報の有効期限を延長できるからである。
【０１５６】
また、本実施の形態によれば、プロキシ・サーバ１０は、有効期限変更依頼応答生成機能１９によって、Expiresヘッダの拡張処理をユーザ・エージェント２０に行わせているため、プロキシ・サーバ１０自身でExpiresヘッダの拡張機能を備える必要がない。
【０１５７】
（第５の実施の形態）
次に、本発明の第５の実施の形態に係るプロキシ・サーバ１０に関して、図表を参照して詳細に説明する。
【０１５８】
（第５の実施の形態の構成）
本発明の第５の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図２０は、本発明の第５の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０１５９】
図２０に示すように、本発明の第５の実施の形態に係るプロキシ・サーバ１０は、一般的なSIPプロキシ・サーバ機能１１に加えて、SIPプロキシ・サーバ機能１１が受信したメッセージの種類を識別するメッセージ判別機能１２と、SIPのプロトコル規約で規定されている、ユーザ・エージェント２０がSIP要求の送信先を変更する機能を動作させる宛先変更応答（宛先変更依頼応答）を生成する宛先変更応答生成機能６１とから構成される。
【０１６０】
この宛先変更応答としては、例えば、SIPのプロトコル規約で規定されているSIP応答305（use  proxy）において、このSIP応答のcontactヘッダに予備SIPサーバ４０のIPアドレスを挿入したものとなる。
【０１６１】
（第５の実施の形態の動作）
次に、本発明の第５の実施の形態に係るプロキシ・サーバ１０の動作を図表を参照して詳細に説明する。図２１は、本発明の第５の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【０１６２】
いま、SIPプロキシ・サーバ機能１１がメッセージを受信したとする（ステップS10601）。次に、メッセージ判別機能１２が受信したメッセージの種類を調査する（ステップS10602）。
【０１６３】
ステップS10602の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがSIP応答（200  OK）の場合には、更に、メッセージ判別機能１２が該当SIP応答（200  OK）の送信元を調査する（ステップS10603）。
【０１６４】
ステップS10603の結果、SIP応答（200  OK）の送信元が現用SIPサーバ３０の場合には、宛先変更応答生成機能６１がユーザ・エージェント２０へ送信する宛先変更を示すSIP応答を生成する（ステップS10604）。この処理は、例えば、前述したように、SIPのプロトコル規約で規定されているSIP応答305（use  proxy）において、このSIP応答のcontactヘッダに予備SIPサーバ４０のIPアドレスを挿入したものとなる。
【０１６５】
ステップS10602の結果、プロキシ・サーバ１０が受信したメッセージがSIP応答（200  OK）以外の場合、または、ステップS10603の結果、SIP応答（200  OK）の送信元が予備SIPサーバ４０であった場合、または、ステップS10604の結果、ユーザ・エージェント２０へ転送する宛先変更応答が生成された場合には、SIPプロキシ・サーバ機能１１が、ステップS10601で受信したメッセージをメッセージに記載された宛先に、または、ステップS10604で生成された宛先変更応答をユーザ・エージェント２０に転送する（ステップS10605）。
【０１６６】
次に、以上述べたような構成および動作となる、本発明の第５の実施の形態に係るプロキシ・サーバ１０を含むシステム全体での動作を図表を参照して詳細に説明する。
【０１６７】
まず、システム全体でのデータの流れを図２２に示す。この図に示すように、ユーザ・エージェント２０から送信されたREGISTERリクエスト（図２２のａ）の処理完了を示すSIP応答（200  OK）（図２２のｂ）を受信したプロキシ・サーバ１０は、ユーザ・エージェント２０にREGISTERリクエストの宛先変更を促すSIP応答（宛先変更応答）（図２２のｃ）を送信する。
【０１６８】
宛先変更応答を受信したユーザ・エージェント２０は、SIPのプロトコル規約で規定されている処理に従って、REGISTERリクエストの送信先を宛先変更応答に記載された宛先に変更し、REGISTERリクエストを再度転送する。プロキシ・サーバ１０は、この再送されたREGISTERリクエストを予備SIPサーバ４０に転送する（図２２のｄ）。
【０１６９】
更に、このデータの流れを動作シーケンスとしたものが図２３である。この図に示すように、現用SIPサーバ３０から送信されたSIP応答（200  OK）を受信したプロキシ・サーバ１０は、ユーザ・エージェント２０に宛先変更応答を送信することで、宛先を予備SIPサーバ４０に変更したinitial  REGISTERリクエストをユーザ・エージェント２０に送信させている。このinitial  REGISTERリクエストを受信したプロキシ・サーバ１０は、initial  REGISTERリクエストに記載されている宛先（予備SIPサーバ４０）に送信するのみで、現用SIPサーバ３０と予備SIPサーバ４０間で登録情報の複製が可能となるのである。
【０１７０】
（第５の実施の形態の効果）
本実施の形態によれば、プロキシ・サーバ１０は、ユーザ・エージェント２０からのinitial  REGISTERリクエストに記載されている宛先（予備SIPサーバ４０）に送信するのみで、現用SIPサーバ３０と予備SIPサーバ４０間で登録情報の複製が可能となるのである。
【０１７１】
その理由は、現用SIPサーバ３０から送信されたSIP応答（200  OK）を受信したプロキシ・サーバ１０は、宛先変更応答生成機能６１によって生成した宛先変更応答をユーザ・エージェント２０に送信することで、宛先を予備SIPサーバ４０に変更したinitial  REGISTERリクエストをユーザ・エージェント２０からプロキシ・サーバ１０に対して送信させているからである。
【０１７２】
（第６の実施の形態）
次に、本発明の第６の実施の形態に係るプロキシ・サーバ１０について、図表を参照して詳細に説明する。
【０１７３】
（第６の実施の形態の構成）
本発明の第６の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図２４は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０１７４】
図２４に示すように、本発明の第６の実施の形態に係るプロキシ・サーバ１０は、一般的なSIPプロキシ・サーバ機能１１に加えて、SIPプロキシ・サーバ機能１１が受信したメッセージを識別するメッセージ判別機能１２と、SIPのプロトコル規約で規定されている、ユーザ・エージェント２０がSIP応答に応じてSIP要求の送信先を変更する機能を動作させる宛先変更応答（宛先変更依頼応答）を生成する宛先変更応答生成機能６１と、SIPプロキシ・サーバ機能１１が受信したメッセージに含まれるExpiresヘッダの値を変更（増加・減少）する有効期限更新機能１５とから構成される。
【０１７５】
ここで、宛先変更応答生成機能６１が生成する宛先変更応答は、例えば、前述した、本発明の第５の実施の形態に係るプロキシ・サーバ１０で生成される宛先変更応答と同様である。
【０１７６】
更に、メッセージ判別機能１２は、宛先変更応答を生成するか否かを判定する際に使用する、REGISTERリクエストの宛先を決定する際に参照する情報（宛先情報）を保存する。この宛先情報は、例えば、ユーザ・エージェント２０とREGISTERリクエストの転送先との組として実現できる。
【０１７７】
（第６の実施の形態の動作）
次に、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作を図表を参照して詳細に説明する。図２５は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【０１７８】
いま、SIPプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップS11001）。すると、メッセージ判別機能１２がメッセージの種類を調査する（ステップS11002）。
【０１７９】
ステップS11002の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがinitial  REGISTERリクエストの場合には、更に、initial  REGISTERリクエストの送信先（宛先）をメッセージ判別機能１２が調査する（ステップS11003）。
【０１８０】
この処理は、例えば、以下のようにして実現できる。まず、メッセージ判別機能１２が、受信したinitial  REGISTERリクエストを送信したユーザ・エージェント２０を検索キーとして、宛先情報からREGISTERリクエストの転送先を抽出する。その後、ステップS1101で受信したinitial  REGISTERリクエストの送信先が、抽出した転送先と同一であるかを比較するのである。
【０１８１】
ステップS11003の結果、initial  REGISTERリクエストの宛先が宛先情報と異なる場合には、宛先変更応答生成機能６１が、宛先変更応答を生成する（ステップS11004）。
【０１８２】
この処理は、前述したように、例えば、SIPのプロトコル規約で規定されているSIP応答305（use  proxy）において、このSIP応答のcontactヘッダに予備SIPサーバ４０のIPアドレスを挿入するという処理となる。
【０１８３】
ステップS11002の結果、受信したメッセージが認証REGISTERリクエストである場合には、認証REGISTERリクエストのExpiresヘッダの値を変更する（ステップS11005）。
【０１８４】
この処理は、例えば、1台の予備SIPサーバ４０が存在する場合には２倍、２台の予備SIPサーバ４０が存在する場合には３倍など、予備SIPサーバ数に応じて増加させる。
【０１８５】
ステップS11002の結果、受信したメッセージがSIP応答（200  OK）である場合には、メッセージ判別機能１２が保持する宛先情報を変更する（ステップS11006）。
【０１８６】
この処理は、例えば、以下のようにして実現できる。まず、SIP応答（200  OK）の送信先となるユーザ・エージェント２０のREGISTERリクエストの転送先を宛先情報から抽出する。その後、ステップS11001で受信したSIP応答（200  OK）が現用SIPサーバ３０から送信された場合には、該当リクエスト転送先を予備SIPサーバ４０とする。一方、SIP応答（200  OK）が、予備SIPサーバ４０から送信された場合には、該当リクエスト転送先を現用SIPサーバ３０とする。
【０１８７】
次に、SIP応答（200  OK）のExpiresヘッダの値を変更する（ステップS11005）。これは、認証REGISTERリクエストでのExpiresヘッダ値の変更とは逆に、例えば、1台の予備SIPサーバ４０が存在する場合には１/２倍、２台の予備SIPサーバ４０が存在する場合には１/３倍など、予備SIPサーバ数に応じて減少させる。
【０１８８】
ステップS11004の結果、ユーザ・エージェント２０へ転送する宛先変更応答の生成が完了した場合、または、ステップS11003の結果、initial  REGISTERリクエストの宛先が宛先情報の同一であった場合、または、ステップS11005の結果、認証REGISTERリクエストおよびSIP応答（200  OK）のExpiresヘッダ値の変更が完了した場合、または、ステップS11002の結果、受信したメッセージがinitial／認証REGISTERリクエストおよびSIP応答（200  OK）以外であった場合には、SIPプロキシ・サーバ機能１１が、宛先変更応答はユーザ・エージェント２０に、それ以外はメッセージに記載されている宛先に転送する（ステップS11007）。
【０１８９】
次に、本発明の第６の実施の形態に係るプロキシ・サーバ１０を含むシステム全体での動作を図表を参照して詳細に説明する。
【０１９０】
まず、システム全体でのデータの流れを図２６に示す。この図に示すように、ユーザ・エージェント２０からinitial  REGISTERリクエスト（図２６のａ）を受信したプロキシ・サーバ１０はinitial  REGISTERリクエストの宛先を調査し、initial  REGISTERリクエストに記載された宛先の転送順番でない場合には、宛先変更応答（図２６のｂ）をユーザ・エージェント２０に転送する。その後、ユーザ・エージェント２０により宛先が修正されたinitial  REGISTERを、記載された宛先に転送し、当該宛先から受信したSIP応答をユーザ・エージェント２０に転送する（図２６のｃ）。この結果、initial  REGISTERリクエストは、現用SIPサーバ３０および予備SIPサーバ４０に順番に転送されることになる。
【０１９１】
更に、このデータの流れを動作シーケンスとしたものが図２７である。この図に示しているように、initial  REGISTERリクエストでの宛先調査と、認証REGISTERリクエストでのExpiresヘッダ値の変更により、各々のSIPサーバに格納された登録情報を無効とすることなく、現用SIPサーバ３０および予備SIPサーバ４０の登録情報を順番に更新していくのである。
【０１９２】
（第６の実施の形態の効果）
本実施の形態によれば、各々のSIPサーバに格納された登録情報を無効とすることなく、現用SIPサーバ３０および予備SIPサーバ４０の登録情報の更新が可能となる。
【０１９３】
その理由は、initial  REGISTERリクエストでの宛先調査と、Expiresヘッダの値を変更（増加・減少）する有効期限更新機能１５によって認証REGISTERリクエストでのExpiresヘッダ値を変更し、SIP要求の送信先を変更する機能を動作させる宛先変更応答を宛先変更応答生成機能６１によって生成することにより、現用SIPサーバ３０および予備SIPサーバ４０の登録情報を順番に更新していくからである。
【０１９４】
（第７の実施の形態）
次に、本発明の第７の実施の形態に係るプロキシ・サーバ１０について、図表を参照して詳細に説明する。
【０１９５】
（第７の実施の形態の構成）
本発明の第７の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図２８は、本発明の第７の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０１９６】
図２８に示すように、本発明の第７の実施の形態に係るプロキシ・サーバ１０は、本発明の第１の実施の形態に係るプロキシ・サーバ１０の構成に、予備SIPサーバ４０への複製を実施するか否かを判断する複製判断機能６２が追加された形態となっている。
【０１９７】
この複製判断機能６２の導入により、本発明の第１の実施の形態に係るプロキシ・サーバ１０では、ユーザ・エージェント２０から送信されたREGISTERリクエストを全て複製する形態であったが、本発明の第7の実施の形態に係るプロキシ・サーバ１０では、予備SIPサーバ４０に数回に一度REGISTERリクエストを送信する形態となる。
【０１９８】
更に、リクエスト生成機能１４では、本発明の第１の実施の形態に係るプロキシ・サーバ１０でのリクエスト生成機能１４が保持する機能が、予備SIPサーバ４０へ転送するREGISTERリクエストの生成時にExpiresヘッダ値を増加する機能へと拡張されている。この結果、予備SIPサーバ４０に対し、ユーザ・エージェント２０からのREGISTERリクエストが数回に一度しか到着しない状況でも予備SIPサーバ４０の登録情報が無効とならないのである。
【０１９９】
（第７の実施の形態の動作）
次に、本発明の第７の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。図２９は、本発明の第７の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【０２００】
このフローチャートは、本発明の第１の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートに、複製判断機能６２による複製判断処理（ステップS11404およびステップS11406）が付加された形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS11401は第１の実施の形態の図５に示すステップS401と、ステップS11402はステップS402と、ステップS11403はステップS403と、ステップS11412はステップS404と、ステップS11405はステップS405と、ステップS11407はステップS406と、ステップS11408はステップS407と、ステップS11409はステップS408と、ステップS11410はステップS409と、ステップS11411はステップS410と同様の処理内容であるので、説明を省略する。
【０２０１】
この複製判断機能６２による複製判断処理（ステップS11404およびステップS11406）は、例えば、以下の処理で実現できる。ステップ11401で受信したメッセージ（REGISTERリクエストまたはSIP応答（200  OK））のCSeqヘッダ値を参照して、２回に１回複製する場合には奇数番号の時に複製し、偶数番号の時には複製しないと判断するものである（ステップS11404）。
【０２０２】
ステップS11404の結果、複製すると判断した場合には、リクエスト生成機能１４がinitial  REGISTERリクエストを生成する（ステップ11405）。この処理は、前述したように、本発明の第１の実施の形態に係るプロキシ・サーバ１０でのリクエスト生成機能１４の処理に加えて、Expiresヘッダ値の増加処理が追加される。
【０２０３】
ステップS11404の結果、複製しないと判断した場合には、ステップS11401で受信したメッセージをSIPプロキシ・サーバ機能１１が、メッセージに記載された宛先に転送する。
【０２０４】
また、ステップＳ１１４０２の結果受信したメッセージがREGISTERリクエストの場合におけるステップS11406の処理も、ステップS11404と同様の処理で複製判断を行う。ステップ11406の結果、複製すると判断された場合には、受信したREGISTERリクエストを一時格納機能１３が複製する（ステップS11407）。この一時格納機能１３の動作は、本発明の第１の実施の形態に係るプロキシ・サーバ１０における一時格納機能１３の動作と同様である。
【０２０５】
ステップS11406の結果、複製しないと判断した場合には、ステップS11401の結果受信したメッセージをSIPプロキシ・サーバ機能１１が、メッセージに記載された宛先に転送する。
【０２０６】
次に、本発明の第７の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０２０７】
図３０は、本発明の第７の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示している。
【０２０８】
この図に示すように、データの流れとしては、本発明の第１の実施の形態に係るプロキシ・サーバ１０と基本的に同様である。ユーザ・エージェント２０からのREGISTERリクエストが予備SIPサーバ４０に数回に一度転送されていることが、本実施の形態の特徴となっている。
【０２０９】
更に、このデータの流れを動作シーケンスとして示したものが図３１である。この図に示しているように、ユーザ・エージェント２０から現用SIPサーバ３０に宛てられたREGISTERリクエストが数回に一度複製対象として一時格納され、予備SIPサーバ４０へ転送するREGISTERリクエストとしてExpiresヘッダ値が更新され、転送されている。
【０２１０】
（第７の実施の形態の効果）
本実施の形態によれば、第１の実施の形態と比較し、予備SIPサーバ４０の登録情報の更新負担の減少およびプロキシ・サーバ１０と予備SIPサーバ４０間のトラフィックの減少を図ることができる。
【０２１１】
その理由は、複製判断機能６２の導入により、プロキシ・サーバ１０が、予備SIPサーバ４０に数回に一度REGISTERリクエストを送信するからである。
【０２１２】
（第８の実施の形態）
次に、本発明の第８の実施の形態に係るプロキシ・サーバ１０について、図表を参照して詳細に説明する。
【０２１３】
（第８の実施の形態の構成）
本発明の第８の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図３２は、本発明の第８の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０２１４】
図３２に示すように、本発明の第８の実施の形態に係るプロキシ・サーバ１０は、本発明の第３の実施の形態に係るプロキシ・サーバ１０の構成に、複製判断機能６２および有効期限更新機能１５を追加した形態となっている。
【０２１５】
この複製判断機能６２は、前述した、本発明の第７の実施の形態に係るプロキシ・サーバ１０における複製判断機能６２と同様である。更に、有効期限更新機能１５は、本発明の第２の実施の形態に係るプロキシ・サーバ１０における有効期限更新機能１５と同様である。
【０２１６】
これらの機能を追加することで、本発明の第３の実施の形態におけるプロキシ・サーバ１０では、ユーザ・エージェント２０から送信されたREGISTERリクエストを毎回必ずユーザ・エージェント２０に再送させ、予備SIPサーバ４０に転送していた形態が、ユーザ・エージェント２０から送信されたREGISTERリクエストのうちの数回に一度のREGISTERリクエストが予備SIPサーバ４０に転送される形態となる。
【０２１７】
（第８の実施の形態の動作）
次に、本発明の第８の実施の形態に係るプロキシ・サーバ１０の動作を図表を参照して詳細に説明する。
【０２１８】
図３３は、本発明の第8の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。この図に示すように、本発明の第８の実施の形態に係るプロキシ・サーバ１０の動作は、本発明の第３の実施の形態に係るプロキシ・サーバ１０の動作に、複製判断機能６２による複製判断処理（ステップS11803およびステップS11807）と、有効期限更新機能１５によるREGISTERリクエストおよびSIP応答（200  OK）のExpiresヘッダ値の変更処理（ステップS11805およびステップS11809）が追加されたものとなっている。なお、本実施の形態の複製判断処理及びExpiresヘッダ値の変更処理以外のステップである、ステップS11801は第３の実施の形態の図１３に示すステップS1001と、ステップS11802はステップS1002と、ステップS11804はステップS1003と、ステップS11806はステップS1004と、ステップS11808はステップS1005と、ステップS11810はステップS1006と、ステップS11811はステップS1007と同様の処理内容であるので、説明を省略する。
【０２１９】
この複製判断処理（ステップS11803およびステップS11807）は、本発明の第７の実施の形態に係るプロキシ・サーバ１０における動作での複製判断処理（ステップS11404およびステップS11406）と同様である。更に、有効期限変更処理（ステップS11805およびステップS11809）は、本発明の第２の実施の形態に係るプロキシ・サーバ１０における動作での有効期限増加処理（ステップS703）および有効期限減少処理（ステップS706）と同様である。
【０２２０】
すなわち、ステップＳ１１８０２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類がREGISTERリクエストの場合には、複製判断機能６２が、予備SIPサーバ４０への複製を実施するか否かを判断する（ステップＳ１１８０３）。
【０２２１】
ステップS１１８０３の結果、複製すると判断した場合には、宛先決定機能１６が宛先を決定し（ステップＳ１１８０４）、有効期限更新機能１５がExpiresヘッダ値の変更処理を行う（ステップＳ１１８０５）。
【０２２２】
また、ステップＳ１１８０２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類がSIP応答（200  OK）の場合には、メッセージ判別機能１２が、メッセージの送信元を判別し（ステップＳ１１８０６）、ステップＳ１１８０６の結果、送信元が現用SIPサーバ３０の場合には、複製判断機能６２が、予備SIPサーバ４０への複製を実施するか否かを判断する（ステップＳ１１８０７）。
【０２２３】
ステップＳ１１８０７の結果、複製すると判断した場合には、再送応答生成機能１７が、ユーザ・エージェント２０にinitial  REGISTERリクエストを再送させるための再送応答を生成し（ステップＳ１１８０８）、有効期限更新機能１５がExpiresヘッダ値の変更処理を行い（ステップＳ１１８０９）、宛先決定機能１６が、宛先情報を更新する（ステップＳ１１８１０）。
【０２２４】
ステップＳ１１８０２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがREGISTERリクエストおよびSIP応答（200  OK）でない場合、ステップS１１８０３またはステップＳ１１８０７の結果、複製しないと判断した場合、ステップＳ１１８０５の結果、Expiresヘッダ値の変更処理が行われた場合、ステップＳ１１８１０の結果、宛先情報が更新された場合には、SIPプロキシ・サーバ機能１１が、指定された宛先にメッセージを送信する（ステップＳ１１８１１）。
【０２２５】
次に、本発明の第８の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０２２６】
図３４は、本発明の第８の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れを示す図である。
【０２２７】
この図に示すように、本発明の第８の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れは、本発明の第３の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れと基本的に同様である（図１４参照）。しかし、本実施の形態は、ユーザ・エージェント２０からのREGISTERリクエストに対し、プロキシ・サーバ１０から数回に一度ユーザ・エージェント２０へ再送応答が返送され、その応答に対するユーザ・エージェント２０からのinitial  REGISTERリクエストが予備SIPサーバ４０へ転送されることが特徴となっている。
【０２２８】
更に、このデータの流れを動作シーケンスとして示したものが図３５である。この図に示すように、ユーザ・エージェント２０から送信されるREGISTERリクエストに対して数回に一度再送応答が返送され、この応答に対してユーザ・エージェント２０が送信したinitial  REGISTERリクエストのExpiresヘッダが、プロキシ・サーバ１０で変更された後、予備SIPサーバ４０に転送されている。
【０２２９】
（第８の実施の形態の効果）
本実施の形態によれば、第３の実施の形態と比較し、予備SIPサーバ４０の登録情報の更新負担の減少、プロキシ・サーバ１０とユーザ・エージェント２０間のトラフィックの減少およびプロキシ・サーバ１０と予備SIPサーバ４０間のトラフィックの減少を図ることができる。
【０２３０】
その理由は、有効期限更新機能１５によって認証REGISTERリクエストでのExpiresヘッダ値を変更し、再送応答生成機能１７および複製判断機能６２によって、ユーザ・エージェント２０からのREGISTERリクエストに対し、プロキシ・サーバ１０から数回に一度ユーザ・エージェント２０に対して再送応答を返送し、その応答に対するユーザ・エージェント２０からのinitial  REGISTERリクエストを予備SIPサーバ４０に対して転送するからである。
【０２３１】
（第９の実施の形態）
次に、本発明の第９の実施の形態に係るプロキシ・サーバ１０について図表を参照して詳細に説明する。
【０２３２】
（第９の実施の形態の構成）
図３６は、本発明の第９の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。この図に示すように、本発明の第９の実施の形態に係るプロキシ・サーバ１０は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の構成における宛先決定機能１６の代わりに、SIPのプロトコル規約で規定されている、ユーザ・エージェント２０がSIP要求の送信先を変更する機能を動作させる宛先変更応答（宛先変更依頼応答）を生成する宛先変更応答生成機能６１を追加した構成となっている。
【０２３３】
この変更に伴い、メッセージ解析機能１８には、本発明の第６の実施の形態に係るプロキシ・サーバ１０における、メッセージ判別機能１２と同様、宛先変更応答を生成するか否かを判定する際に使用する宛先情報を保存する。なお、宛先情報は、本発明の第６の実施の形態に係るプロキシ・サーバ１０と同様のものである。
【０２３４】
（第９の実施の形態の動作）
次に、本発明の第９の実施の形態に係るプロキシ・サーバ１０の動作について図表を参照して詳細に説明する。図３７は、本発明の第９の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。
【０２３５】
いま、SIPプロキシ・サーバ機能１１が外部からメッセージを受信したとする（ステップS12201）。すると、メッセージ解析機能１８がメッセージの種類を調査する（ステップS12202）。
【０２３６】
ステップS12202の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがinitial  REGISTERリクエストである場合には、更に、メッセージ解析機能１８がExpiresヘッダに格納された値を調査する（ステップS12203）。
【０２３７】
ステップS12203の結果、受信したinitial  REGISTERリクエストのExpiresヘッダ値がある閾値未満であった場合には、有効期限変更依頼応答生成機能１９が、有効期限変更依頼応答を生成する（ステップS12206）。
【０２３８】
ここで、ステップS12203の処理は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS1303の処理と、また、ステップS12206の有効期限変更依頼応答の生成処理は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS1304と同様の処理である。
【０２３９】
ステップS12203の結果、受信したinitial  REGISTERリクエストのExpiresヘッダ値がある閾値以上である場合には、更に、メッセージ解析機能１８が、受信したinitial  REGISTERリクエストの送信先（宛先）を調査する（ステップS12204）。この処理は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS1103と同様である。
【０２４０】
ステップS12204の結果、initial  REGISTERリクエストの送信先が宛先情報と異なる場合には、宛先変更応答生成機能６１が、宛先変更応答を生成する（ステップS12205）。この処理は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS11004と同様である。
【０２４１】
ステップS12202の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがSIP応答（200  OK）の場合には、メッセージ解析機能１８が宛先情報を更新する（ステップS12207）。この処理は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS11006と同様である。
【０２４２】
ステップS12204の結果、initial  REGISTERリクエストの送信先が宛先情報と同一の場合、または、ステップS12207の結果、メッセージ解析機能１８が宛先情報の変更が完了した場合、または、ステップS12202の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがinitial  REGISTERリクエストおよびSIP応答（200  OK）以外である場合には、ステップS12201で受信したメッセージをメッセージに記載された宛先に、また、ステップS12206の結果、ユーザ・エージェント２０に送信する有効期限変更依頼応答が生成完了した場合、または、ステップS12205の結果、ユーザ・エージェント２０に送信する宛先変更応答の生成が完了した場合には、ステップS12205およびステップS12206で生成したSIP応答をユーザ・エージェント２０へ、SIPプロキシ・サーバ機能１１が送信する（ステップS12208）。
【０２４３】
次に、本発明の第９の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０２４４】
図３８は、本発明の第９の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れを示す図である。
【０２４５】
この図に示すように、ユーザ・エージェント２０からのinitial  REGISTERリクエスト（図３８のａ）を受信したプロキシ・サーバ１０は、initial  REGISTERリクエストのExpiresヘッダ値を調査し、ある閾値未満の場合には有効期限変更依頼応答（図３８のｂ）を返送する。更に、この応答に対してユーザ・エージェント２０から返送された、Expiresヘッダ値が修正されたinitial  REGISTERリクエスト（図３８のｃ）の宛先を調査し、initial  REGISTERリクエストに記載された宛先の転送順番でない場合には、宛先変更応答（図３８のｄ）をユーザ・エージェント２０に転送する。以上により、Expiresヘッダと宛先が適切に変更されたinitial  REGISTERリクエストを現用／予備SIPサーバへ順番に転送することになる（図３８のｅ）。更に、このデータの流れは現用SIPサーバ３０と予備SIPサーバ４０で順番に実行される。
【０２４６】
更に、このデータの流れを動作シーケンスとして示したものが図３９である。この図に示すように、プロキシ・サーバ１０は、SIPのプロトコル規約で規定されているSIP応答（宛先変更依頼応答と有効期限変更依頼応答）に対する処理をユーザ・エージェント２０で動作させて、REGISTERリクエストのExpiresヘッダ値および宛先をユーザ・エージェント２０に変更させている。この結果、現用SIPサーバ３０と予備SIPサーバ４０へ順番にREGISTERリクエストを転送する形態でも、各SIPサーバが保持する登録情報を無効としないで、両SIPサーバ間で登録情報を複製できるのである。
【０２４７】
（第９の実施の形態の効果）
本実施の形態によれば、プロキシ・サーバ１０は、現用SIPサーバ３０と予備SIPサーバ４０へ順番にREGISTERリクエストを転送する形態でも、各SIPサーバが保持する登録情報を無効としないで、両SIPサーバ間で登録情報を複製できる。
【０２４８】
その理由は、プロキシ・サーバ１０が、有効期限変更依頼応答生成機能１９および宛先変更応答生成機能６１を備えることによって、SIPのプロトコル規約で規定されているSIP応答（宛先変更依頼応答と有効期限変更依頼応答）に対する処理をユーザ・エージェント２０で動作させて、REGISTERリクエストのExpiresヘッダ値および宛先をユーザ・エージェント２０に変更させているからである。
【０２４９】
（第１０の実施の形態）
次に、本発明の第１０の実施の形態に係るプロキシ・サーバ１０について図表を参照して詳細に説明する。
【０２５０】
（第１０の実施の形態の構成）
図４０は、本発明の第１０の実施の形態に係るプロキシ・サーバ１０における構成を示すブロック図である。
【０２５１】
この図に示すように、本発明の第１０の実施の形態に係るプロキシ・サーバ１０は、本発明の第９の実施の形態に係るプロキシ・サーバ１０における構成に、複製判断機能６２を追加した形態となっている。なお、この複製判断機能６２は、本発明の第７の実施の形態に係るプロキシ・サーバ１０における、複製判断機能６２と同様の機能を有する。
【０２５２】
（第１０の実施の形態の動作）
次に、本発明の第１０の実施の形態に係るプロキシ・サーバ１０における動作を図表を参照して詳細に説明する。
【０２５３】
図４１は、本発明の第１０の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。図４１に示すように、本発明の第１０の実施の形態に係るプロキシ・サーバ１０の動作は、本発明の第９の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートに、複製判断機能６２の複製判断動作（ステップS12605）が追加された形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS12601は第９の実施の形態の図３７に示すステップS12201と、ステップS12602はステップS12202と、ステップS12603はステップS12203と、ステップS12604はステップS12204と、ステップS12606はステップS12205と、ステップS12607はステップS12206と、ステップS12608はステップS12207と、ステップS12609はステップS12208と同様の処理内容であるので、説明を省略する。
【０２５４】
この複製判断動作処理（ステップS12605）は、本発明の第７の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS11404と同様に、例えば、以下のように実現できる。すなわち、ステップS12601で受信したメッセージ（REGISTERリクエスト）のCSeqヘッダ値を参照して、2回に1度複製する場合、奇数番号で複製と判断し、偶数番号で複製しないと判断するのである。
【０２５５】
ステップS12605の結果、複製する場合には、宛先変更応答生成機能６１が、宛先変更応答を生成する（ステップS12606）。この処理は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作におけるステップS11004と同様である。
【０２５６】
次に、本発明の第１０の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０２５７】
図４２は、本発明の第１０の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示している。
【０２５８】
この図に示すように、データの流れは、本発明の第９の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れと基本的に同様である。しかし、本実施の形態は、ユーザ・エージェント２０から転送されるinitial  REGISTERリクエストの数回に一度が予備SIPサーバ４０へ転送される点が、本発明の第９の実施の形態に係るプロキシ・サーバ１０と異なる。
【０２５９】
更に、このデータの流れを動作シーケンスとして示したものが図４３である。この図に示すように、数回に一度予備SIPサーバ４０の登録情報が更新される場合でも、登録情報が無効とならないように、Expiresヘッダ値を変更するようユーザ・エージェント２０に依頼し、更に、予備SIPサーバ４０へREGISTERリクエストを転送するために、REGISTERリクエストの宛先を変更するようユーザ・エージェント２０に数回に一度依頼している。この結果、REGISTERリクエストが予備SIPサーバ４０へ数回に一度しか転送されないにも係らず、登録情報を無効としないで現用／予備SIPサーバ間で登録情報の複製が可能となる。
【０２６０】
（第１０の実施の形態の効果）
本実施の形態によれば、プロキシ・サーバ１０は、第９の実施の形態と比較し、予備SIPサーバ４０の登録情報の更新負担の減少、プロキシ・サーバ１０とユーザ・エージェント２０間のトラフィックの減少およびプロキシ・サーバ１０と予備SIPサーバ４０間のトラフィックの減少を図ることができる。
【０２６１】
その理由は、プロキシ・サーバ１０が、宛先変更応答生成機能６１および複製判断機能６２を備えることによって、ユーザ・エージェント２０からのREGISTERリクエストに対し、予備SIPサーバ４０へREGISTERリクエストを転送するために、REGISTERリクエストの宛先を変更するようユーザ・エージェント２０に数回に一度依頼しているからである。
【０２６２】
（第１１の実施の形態）
次に、本発明の第１１の実施の形態に係るプロキシ・サーバ１０について、図表を参照して詳細に説明する。
【０２６３】
（第１１の実施の形態の構成）
本発明の第１１の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図４４は、本発明の第１１の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０２６４】
図４４に示すように、本発明の第１１の実施の形態に係るプロキシ・サーバ１０は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の構成に、複製判断機能６２を追加した形態となっている。この複製判断機能６２は、前述した、本発明の第７の実施の形態に係るプロキシ・サーバ１０における複製判断機能６２と同様の機能を有する。
【０２６５】
（第１１の実施の形態の動作）
次に、本発明の第１１の実施の形態に係るプロキシ・サーバ１０の動作を図表を参照して詳細に説明する。
【０２６６】
図４５は、本発明の第１１の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。図４５に示すように、本発明の第１１の実施の形態に係るプロキシ・サーバ１０の動作は、本発明の第６の実施の形態に係るプロキシ・サーバ１０の動作に、複製判断機能６２による複製判断処理（ステップS13004とステップS13006）を追加した形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS13001は第６の実施の形態の図２５に示すステップS11001と、ステップS13002はステップS11002と、ステップS13003はステップS11003と、ステップS13005はステップS11004と、ステップS13007はステップS11005と、ステップS13008はステップS11006と、ステップS13009はステップS11007と同様の処理内容であるので、説明を省略する。
【０２６７】
この複製判断処理（ステップS13004とステップS13006）は、本発明の第７の実施の形態に係るプロキシ・サーバ１０の動作における複製判断処理（ステップS11404およびステップS11406）と同様である。
【０２６８】
すなわち、ステップＳ１３００２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類がinitial  REGISTERリクエストの場合であって、当該initial  REGISTERリクエストの宛先が宛先情報と異なる場合には、複製判断機能６２が、予備SIPサーバ４０への複製を実施するか否かを判断する（ステップＳ１３００４）。
【０２６９】
ステップＳ１３００４の結果、複製を実施する場合には、宛先変更応答生成機能６１が、宛先変更応答を生成する（ステップＳ１３００５）。
【０２７０】
また、ステップＳ１３００２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類が認証REGISTERリクエストの場合には、複製判断機能６２が、予備SIPサーバ４０への複製を実施するか否かを判断する（ステップＳ１３００６）。
【０２７１】
ステップＳ１３００６の結果、複製を実施する場合には、有効期限更新機能１５が、認証REGISTERリクエストのExpiresヘッダの値を変更する（ステップＳ１３００７）。
【０２７２】
ステップＳ１３００２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージがinitial  REGISTERリクエストおよび認証REGISTERリクエストでない場合、ステップS１３００４またはステップＳ１３００６の結果、複製しないと判断した場合、ステップＳ１３００５の結果、宛先変更応答が生成された場合、ステップＳ１３００７の結果、Expiresヘッダ値の変更処理が行われた場合には、SIPプロキシ・サーバ機能１１が、宛先変更応答はユーザ・エージェント２０に、それ以外は指定された宛先にメッセージを送信する（ステップＳ１３００８）。
【０２７３】
次に、本発明の第１１の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０２７４】
図４６は、本発明の第１１の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示している。
【０２７５】
この図に示すように、データの流れは、本発明の第６の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れと基本的に同様である。しかし、本実施の形態は、ユーザ・エージェント２０から転送されるinitial  REGISTERリクエストが予備SIPサーバ４０へ数回に一度転送される点が、本発明の第６の実施の形態に係るプロキシ・サーバ１０と異なる。
【０２７６】
更に、このデータの流れを動作シーケンスとして示したものが図４７である。この図に示すように、予備SIPサーバ４０の登録情報が数回に一度しか更新されない場合でも、登録情報が無効とならないように、Expiresヘッダ値を変更し、更に、予備SIPサーバ４０へREGISTERリクエストを転送するために、REGISTERリクエストの宛先を変更するようユーザ・エージェント２０に数回に一度依頼している。この結果、REGISTERリクエストを予備SIPサーバ４０に数回に一度しか転送しないにも係らず、登録情報を無効としないで現用／予備SIPサーバ間で登録情報の複製が可能となる。
【０２７７】
（第１１の実施の形態の効果）
本実施の形態によれば、第６の実施の形態と比較し、予備SIPサーバ４０の登録情報の更新負担の減少、プロキシ・サーバ１０とユーザ・エージェント２０間のトラフィックの減少およびプロキシ・サーバ１０と予備SIPサーバ４０間のトラフィックの減少を図ることができる。
【０２７８】
その理由は、有効期限更新機能１５によって認証REGISTERリクエストでのExpiresヘッダ値を変更し、複製判断機能６２によって、ユーザ・エージェント２０からのREGISTERリクエストに対し、プロキシ・サーバ１０から数回に一度ユーザ・エージェント２０に対して宛先変更応答を返送し、その応答に対するユーザ・エージェント２０からのinitial  REGISTERリクエストを予備SIPサーバ４０に対して転送するからである。
【０２７９】
（第１２の実施の形態）
次に、本発明の第１２の実施の形態に係るプロキシ・サーバ１０について図表を参照して詳細に説明する。
【０２８０】
（第１２の実施の形態の構成）
本発明の第１２の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図４８は、本発明の第１２の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０２８１】
図４８に示すように、本発明の第１２の実施の形態に係るプロキシ・サーバ１０は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の構成に、複製判断機能６２を追加した形態となっている。なお、この複製判断機能６２は、前述した、本発明の第７の実施の形態に係るプロキシ・サーバ１０における複製判断機能６２と同様の機能を有する。
【０２８２】
（第１２の実施の形態の動作）
次に、本発明の第１２の実施の形態に係るプロキシ・サーバ１０の動作を図表を参照して詳細に説明する。
【０２８３】
図４９は、本発明の第１２の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。図４９に示すように、本発明の第１２の実施の形態に係るプロキシ・サーバ１０の動作は、本発明の第４の実施の形態に係るプロキシ・サーバ１０の動作に、複製判断機能６２の複製判断処理（ステップS13405）を追加した形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS13401は第４の実施の形態の図１７に示すステップS1301と、ステップS13402はステップS1302と、ステップS13403はステップS1303と、ステップS13404はステップS1304と、ステップS13406はステップS1305と、ステップS13407はステップS1306と、ステップS13408はステップS1307と同様の処理内容であるので、説明を省略する。
【０２８４】
この複製判断処理（ステップS13405）は、本発明の第７の実施の形態に係るプロキシ・サーバ１０の動作での複製判断処理（ステップS11404およびステップS11406）と同様である。
【０２８５】
すなわち、ステップＳ１３４０３の結果、Expiresヘッダ値が閾値以上の場合、または、ステップＳ１３４０２の結果、SIPプロキシ・サーバ機能１１が受信したメッセージの種類が認証REGISTERリクエストの場合には、複製判断機能６２が、予備SIPサーバ４０への複製を実施するか否かを判断する（ステップＳ１３４０５）。
【０２８６】
ステップＳ１３４０５の結果、複製を実施する場合には、宛先決定機能１６が宛先情報を参照してREGISTERリクエストの宛先を決定する（ステップＳ１３４０６）。
【０２８７】
次に、本発明の第１２の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０２８８】
図５０は、本発明の第１２の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示している。
【０２８９】
この図に示すように、データの流れは、本発明の第４の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れと基本的に同様である。しかし、本実施の形態は、ユーザ・エージェント２０から転送されるinitial  REGISTERリクエストが予備SIPサーバ４０へ数回に一度転送される点が、本発明の第４の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れと異なる。
【０２９０】
更に、このデータの流れを動作シーケンスとして示したものが図５１である。この図に示すように、数回に一度しか予備SIPサーバ４０の登録情報が更新されない場合でも、登録情報が無効とならないように、Expiresヘッダ値の変更をユーザ・エージェント２０に依頼している。更に、予備SIPサーバ４０へREGISTERリクエストを転送するために、REGISTERリクエストの宛先をプロキシ・サーバ１０が数回に一度変更している。この結果、REGISTERリクエストを予備SIPサーバ４０に数回に一度しか転送しないにも係らず、登録情報を無効としないで現用／予備SIPサーバ間で登録情報の複製が可能となる。
【０２９１】
（第１２の実施の形態の効果）
本実施の形態によれば、第４の実施の形態と比較し、予備SIPサーバ４０の登録情報の更新負担の減少、プロキシ・サーバ１０とユーザ・エージェント２０間のトラフィックの減少およびプロキシ・サーバ１０と予備SIPサーバ４０間のトラフィックの減少を図ることができる。
【０２９２】
その理由は、プロキシ・サーバ１０が、宛先決定機能１６および複製判断機能６２によって、ユーザ・エージェント２０からのREGISTERリクエストの宛先を数回に一度変更し、受信したREGISTERリクエストの複製を予備SIPサーバ４０に転送するからである。
【０２９３】
（第１３の実施の形態）
次に、本発明の第１３の実施の形態に係るプロキシ・サーバ１０について図表を参照して詳細に説明する。
【０２９４】
（第１３の実施の形態の構成）
本発明の第１３の実施の形態に係るプロキシ・サーバ１０の構成を図表を参照して詳細に説明する。図５２は、本発明の第１３の実施の形態に係るプロキシ・サーバ１０の構成を示すブロック図である。
【０２９５】
図５２に示すように、本発明の第１３の実施の形態に係るプロキシ・サーバ１０は、本発明の第２の実施の形態に係るプロキシ・サーバ１０の構成に、複製判断機能６２を追加した形態となっている。なお、この複製判断機能６２は、前述した、本発明の第７の実施の形態に係るプロキシ・サーバ１０における複製判断機能６２と同様の機能を有する。
【０２９６】
（第１３の実施の形態の動作）
次に、本発明の第１３の実施の形態に係るプロキシ・サーバ１０の動作を図表を参照して詳細に説明する。
【０２９７】
図５３は、本発明の第１３の実施の形態に係るプロキシ・サーバ１０の動作を示すフローチャートである。図５３に示すように、本発明の第１３の実施の形態に係るプロキシ・サーバ１０の動作は、本発明の第２の実施の形態に係るプロキシ・サーバ１０の動作に、複製判断機能６２の複製判断処理（ステップS13804）を追加した形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS13801は第２の実施の形態の図９に示すステップS701と、ステップS13802はステップS702と、ステップS13803はステップS703と、ステップS13805はステップS704と、ステップS13806はステップS705と、ステップS13807はステップS706と、ステップS13808はステップS707と同様の処理内容であるので、説明を省略する。
【０２９８】
この複製判断処理（ステップS13804）は、本発明の第７の実施の形態に係るプロキシ・サーバ１０の動作での複製判断処理（ステップS11404およびステップS11406）と同様である。
【０２９９】
すなわち、このステップS13804の追加により、ステップS13806が以下のように変更となる。ステップＳ１３８０２の結果受信したメッセージがREGISTERリクエストの場合においてExpiresヘッダ値の変更処理（ステップＳ１３８０３）後のステップS13804の結果、複製しないと判断された場合には、ステップS13805の処理が実行されないため、受信したメッセージに記載された宛先（現用SIPサーバ３０）を宛先情報に反映する。一方、ステップS13804の結果、複製すると判断された場合には、ステップS13805の処理が実行されるため、ステップS13805の結果決定された宛先を宛先情報に反映する。
【０３００】
次に、本発明の第１３の実施の形態に係るプロキシ・サーバ１０を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
【０３０１】
図５４は、本発明の第１３の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れを示している。
【０３０２】
この図に示すように、データの流れは、本発明の第２の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れと基本的に同様である。ユーザ・エージェント２０から転送されるinitial  REGISTERリクエストが予備SIPサーバ４０へ数回に一度転送される点が、本発明の第２の実施の形態に係るプロキシ・サーバ１０を含むシステム全体でのデータの流れと異なる。
【０３０３】
更に、このデータの流れを動作シーケンスとして示したものが図５５である。この図に示すように、予備SIPサーバ４０の登録情報が数回に一度しか更新されない場合でも、登録情報が無効とならないように、Expiresヘッダ値をプロキシ・サーバ１０が変更している。
【０３０４】
更に、予備SIPサーバへREGISTERリクエストを転送するために、REGISTERリクエストの宛先もプロキシ・サーバ１０が数回に一度変更している。この結果、REGISTERリクエストを予備SIPサーバ４０に数回に一度しか転送しないにも係らず、登録情報を無効としないで現用／予備SIPサーバ間で登録情報の複製が可能となる。
（第１３の実施の形態の効果）
本実施の形態によれば、プロキシ・サーバ１０は、第２の実施の形態と比較し、予備SIPサーバ４０の登録情報の更新負担の減少、プロキシ・サーバ１０と予備SIPサーバ４０間のトラフィックの減少を図ることができる。
【０３０５】
その理由は、プロキシ・サーバ１０が、宛先決定機能１６および複製判断機能６２を備えることによって、ユーザ・エージェント２０から受信したREGISTERリクエストを数回に一度複製して宛先を変更し、予備SIPサーバ４０へ転送するからである。
【０３０６】
以上好ましい実施の形態をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。
【０３０７】
例えば、上記実施の形態では、SIP（session initiation protocol）を用いて外部の端末の登録情報をサーバ間で複製する形態について説明しているが、使用するプロトコルはＳＩＰに限定されず、例えば、ＷＥＢサーバ及びクライアントを備えるＷＥＢシステムにおいて、ＨＴＴＰ（HyperText
Transfer Protocol）を用いてダイジェスト認証によってクライアントの情報を複数のサーバ間で複製してもよい。
【０３０８】
第１の課題を解決するために、本発明のプロキシ・サーバに、前述したSIPプロキシ・サーバが保持する機能に加え、一時的に記録したユーザ端末からのREGISTERリクエストの内容に基づいてREGISTERリクエストを生成する機能を保持させる。具体的には、本発明のプロキシ・サーバが、ユーザ・エージェントとSIPサーバの中間地点で予備SIPサーバ向けのREGISTERリクエストを生成し、予備SIPサーバに送信することで、登録情報の複製を実現する。
第２の課題を解決するために、本発明のプロキシ・サーバのユーザ識別子とパスワードをプロキシ・サーバに保持させ、プロキシ・サーバと予備SIPサーバ間でDigest認証を行う形態とする。これにより、予備SIPサーバへのアクセス者の正当性を保証する。
第３の課題を解決するために、本発明のプロキシ・サーバは、現用SIPサーバからのREGISTERリクエスト処理完了応答（200  OK）確認後、予備SIPサーバへ複製したREGISTERリクエストを送信する。現用SIPサーバからSIP応答（200  OK）が返送されることは、ユーザ・エージェントから送信されたREGISTERリクエストが正当なものであり、かつ、現用SIPサーバにおいて正常に処理が完了したことを意味している。つまり、予備SIPサーバへ送信予定のREGISTERリクエストの現用SIPサーバでの処理結果がSIP応答（200  OK）であることを確認することで、予備SIPサーバへ送信する当該REGISTERリクエストが正当なものであることを予備SIPサーバに示すことが可能なのである。
以上の手段により、予備SIPサーバへのアクセス者（プロキシ・サーバ）と送信REGISTERリクエストの正当性を担保した上で、現用SIPサーバの登録情報を予備SIPサーバへ複製することを可能とする。
本発明によれば、以下に説明する効果を達成することができる。
第１の効果は、登録情報の複製を実現できることである。これは、プロキシ・サーバが、プロキシ・サーバが本来有する機能に加え、予備SIPサーバに送信するREGISTERリクエスト（メッセージ）の生成機能を保持するためである。
第２の効果は、登録情報の複製に際し、予備SIPサーバへのアクセス者の正当性を予備SIPサーバに示すことが可能なことである。これは、プロキシ・サーバのユーザ識別子とパスワードをプロキシ・サーバに保持させ、プロキシ・サーバと予備SIPサーバ間でDigest認証を行うためである。
この出願は、２００６年８月１８日に出願された日本出願特願２００６−２２３３６３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０３０９】
本発明のプロキシ・サーバは、複数のユーザ端末及び複数のＳＩＰサーバを有するＳＩＰネットワークに利用できる。
【符号の説明】
【０３１０】
１：ＳＩＰシステム
１０：プロキシ・サーバ
１１：SIPプロキシ・サーバ機能
１２：メッセージ判別機能
１３：一時格納機能
１４：リクエスト生成機能
１５：有効期限更新機能
１６：宛先決定機能
１７：再送応答生成機能
１８：メッセージ解析機能
１９：有効期限変更依頼応答生成機能
２０：ユーザ・エージェント
３０：現用ＳＩＰサーバ
３１：登録情報
４０：予備ＳＩＰサーバ
４１：登録情報
５０：ネットワーク
６１：宛先変更応答生成機能
６２：複製判断機能
３０１：ＣＰＵ
３０２：主記憶部
３０３：通信制御部
３０４：提示部
３０５：入力部
３０６：インタフェース部
３０７：補助記憶部
３０８：システムバス
【図１】
0004465638.tif 000002
【図２】
0004465638.tif 000003
【図３】
0004465638.tif 000004
【図４】
0004465638.tif 000005
【図５】
0004465638.tif 000006
【図６】
0004465638.tif 000007
【図７】
0004465638.tif 000008
【図８】
0004465638.tif 000009
【図９】
0004465638.tif 000010
【図１０】
0004465638.tif 000011
【図１１】
0004465638.tif 000012
【図１２】
0004465638.tif 000013
【図１３】
0004465638.tif 000014
【図１４】
0004465638.tif 000015
【図１５】
0004465638.tif 000016
【図１６】
0004465638.tif 000017
【図１７】
0004465638.tif 000018
【図１８】
0004465638.tif 000019
【図１９】
0004465638.tif 000020
【図２０】
0004465638.tif 000021
【図２１】
0004465638.tif 000022
【図２２】
0004465638.tif 000023
【図２３】
0004465638.tif 000024
【図２４】
0004465638.tif 000025
【図２５】
0004465638.tif 000026
【図２６】
0004465638.tif 000027
【図２７】
0004465638.tif 000028
【図２８】
0004465638.tif 000029
【図２９】
0004465638.tif 000030
【図３０】
0004465638.tif 000031
【図３１】
0004465638.tif 000032
【図３２】
0004465638.tif 000033
【図３３】
0004465638.tif 000034
【図３４】
0004465638.tif 000035
【図３５】
0004465638.tif 000036
【図３６】
0004465638.tif 000037
【図３７】
0004465638.tif 000038
【図３８】
0004465638.tif 000039
【図３９】
0004465638.tif 000040
【図４０】
0004465638.tif 000041
【図４１】
0004465638.tif 000042
【図４２】
0004465638.tif 000043
【図４３】
0004465638.tif 000044
【図４４】
0004465638.tif 000045
【図４５】
0004465638.tif 000046
【図４６】
0004465638.tif 000047
【図４７】
0004465638.tif 000048
【図４８】
0004465638.tif 000049
【図４９】
0004465638.tif 000050
【図５０】
0004465638.tif 000051
【図５１】
0004465638.tif 000052
【図５２】
0004465638.tif 000053
【図５３】
0004465638.tif 000054
【図５４】
0004465638.tif 000055
【図５５】
0004465638.tif 000056
【図５６】
0004465638.tif 000057
【図５７】
0004465638.tif 000058
【図５８】
0004465638.tif 000059
【図５９】
0004465638.tif 000060