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

Description

本発明は、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プロキシ・サーバ機能
１２：メッセージ判別機能
１３：一時格納機能
１４：リクエスト生成機能
１５：有効期限更新機能
１６：宛先決定機能
１７：再送応答生成機能
１８：メッセージ解析機能
１９：有効期限変更依頼応答生成機能
２０：ユーザ・エージェント
３０：現用ＳＩＰサーバ
３１：登録情報
４０：予備ＳＩＰサーバ
４１：登録情報
５０：ネットワーク
６１：宛先変更応答生成機能
６２：複製判断機能
３０１：ＣＰＵ
３０２：主記憶部
３０３：通信制御部
３０４：提示部
３０５：入力部
３０６：インタフェース部
３０７：補助記憶部
３０８：システムバス

Claims (18)

1. 外部とメッセージを送受信するＳＩＰプロキシ・サーバ機能と、
   前記ＳＩＰプロキシ・サーバ機能により受信したメッセージの種類および送信元を識別するメッセージ判別機能と、
   自身を介してユーザ端末から現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを受信した際、ユーザ端末にＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先を予備ＳＩＰサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能と、
   ユーザ端末と前記ユーザ端末から自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報と、
   前記現用ＳＩＰサーバ又は前記予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新する機能とを備え、
   前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる場合に、前記宛先変更依頼応答を生成し、
   前記送信先対応情報を更新する機能は、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とするプロキシ・サーバ。
2. 前記宛先変更依頼応答生成機能は、自身を介して現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを複数回受信した内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１に記載のプロキシ・サーバ。
3. 前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１又は請求項２に記載のプロキシ・サーバ。
4. 受信したメッセージの有効期限の変更を前記ユーザ端末に依頼する有効期限変更依頼応答を生成する有効期限変更依頼応答生成機能を備え、
   前記有効期限変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの有効期限と所定の閾値との比較結果に基づいて、前記有効期限変更依頼応答を生成することを特徴とする請求項１に記載のプロキシ・サーバ。
5. 前記所定の閾値は、前記現用ＳＩＰサーバ及び前記予備ＳＩＰサーバの総数に応じて定められることを特徴とする請求項４に記載のプロキシ・サーバ。
6. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
   前記プロキシ・サーバに、
   外部とメッセージを送受信するＳＩＰプロキシ・サーバ機能と、
   前記ＳＩＰプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、
   前記プロキシ・サーバ自身を介してユーザ端末から現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを受信した際、前記ユーザ端末にＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先を予備ＳＩＰサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能と、
   前記ユーザ端末と前記ユーザ端末から前記プロキシ・サーバ自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報と、
   前記現用ＳＩＰサーバ又は前記予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新する機能を備え、
   前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる場合に、前記宛先変更依頼応答を生成し、
   前記送信先対応情報を更新する機能は、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とする通信システム。
7. 前記宛先変更依頼応答生成機能は、前記プロキシ・サーバを介して前記現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを複数回受信した内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項６に記載の通信システム。
8. 前記宛先変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項６又は請求項７に記載の通信システム。
9. 受信したメッセージの有効期限の変更を前記ユーザ端末に依頼する有効期限変更依頼応答を生成する有効期限変更依頼応答生成機能を備え、
   前記有効期限変更依頼応答生成機能は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの有効期限と所定の閾値との比較結果に基づいて、前記有効期限変更依頼応答を生成することを特徴とする請求項６に記載の通信システム。
10. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバと、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
    前記プロキシ・サーバに、
    外部とメッセージを送受信するＳＩＰプロキシ・サーバ機能と、
    前記ＳＩＰプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、
    自身を介して現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを複数回受信した内の１回において、ユーザ端末に対して前記Ｉｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先を予備ＳＩＰサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能とを備え、
    前記ユーザ端末と前記予備ＳＩＰサーバ間で、前記Ｉｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストによる前記ユーザ端末の認証を可能としたことを特徴とする通信システム。
11. 外部のユーザ端末との間でＳＩＰメッセージの送受信を行う現用及び予備のＳＩＰサーバに対し、前記ＳＩＰメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
    外部とメッセージを送受信する仲介ステップと、
    前記仲介ステップにより受信したメッセージの種類を識別するメッセージ判別ステップと、
    前記プロキシ・サーバ自身を介してユーザ端末から現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを受信した際、前記ユーザ端末にＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先を予備ＳＩＰサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成ステップと、
    前記現用ＳＩＰサーバ又は前記予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新するステップとを備え、
    前記宛先変更依頼応答生成ステップにおいて、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が、前記ユーザ端末と前記ユーザ端末から前記プロキシ・サーバ自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報で示される送信先と異なる場合に、前記宛先変更依頼応答を生成し、
    前記送信先対応情報を更新するステップにおいて、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とする通信方法。
12. 前記宛先変更依頼応答生成ステップは、前記プロキシ・サーバを介して前記現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを複数回受信した内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１１に記載の通信方法。
13. 前記宛先変更依頼応答生成ステップは、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１１又は請求項１２のいずれか１項に記載の通信方法。
14. 受信したメッセージの有効期限の変更を前記ユーザ端末に依頼する有効期限変更依頼応答を生成する有効期限変更依頼応答生成ステップを備え、
    前記有効期限変更依頼応答生成ステップは、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの有効期限と所定の閾値との比較結果に基づいて、前記有効期限変更依頼応答を生成することを特徴とする請求項１１に記載の通信方法。
15. 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
    外部とメッセージを送受信するＳＩＰプロキシ・サーバ処理と、
    前記ＳＩＰプロキシ・サーバ処理により受信したメッセージの種類を識別するメッセージ判別処理と、
    前記プロキシ・サーバ自身を介してユーザ端末から現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを受信した際、前記ユーザ端末にＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先を予備ＳＩＰサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成処理と、
    前記現用ＳＩＰサーバ又は前記予備ＳＩＰサーバから受信したメッセージが認証可を示すＳＩＰ応答である場合に、前記送信先対応情報を更新する処理とを前記プロキシ・サーバに実行させ、
    前記宛先変更依頼応答生成処理において、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が、前記ユーザ端末と前記ユーザ端末から前記プロキシ・サーバ自身を介して送信されるＲＥＧＩＳＴＥＲリクエストの転送先との対応関係を示す送信先対応情報で示される送信先と異なる場合に、前記宛先変更依頼応答を生成し、
    前記送信先対応情報を更新する処理において、前記認証可を示すＳＩＰ応答のメッセージを、前記予備ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記現用ＳＩＰサーバに対応付け、前記現用ＳＩＰサーバから受信した場合には、該当ＲＥＧＩＳＴＥＲリクエストの送信先を前記予備ＳＩＰサーバに対応付けることを特徴とするプログラム。
16. 前記宛先変更依頼応答生成処理は、前記プロキシ・サーバを介して前記現用ＳＩＰサーバに送信されるＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストを複数回受信した内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１５に記載のプログラム。
17. 前記宛先変更依頼応答生成処理は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の１回において、前記宛先変更依頼応答を生成することを特徴とする請求項１５又は請求項１６のいずれか１項に記載のプログラム。
18. 受信したメッセージの有効期限の変更を前記ユーザ端末に依頼する有効期限変更依頼応答を生成する有効期限変更依頼応答生成処理を前記プロキシ・サーバに実行させ、
    前記有効期限変更依頼応答生成処理は、受信したＩｎｉｔｉａｌ ＲＥＧＩＳＴＥＲリクエストの有効期限と所定の閾値との比較結果に基づいて、前記有効期限変更依頼応答を生成することを特徴とする請求項１５に記載のプログラム。

Images