JP4336904B2 - プロキシ・サーバ、通信システム、通信方法及びプログラム - Google Patents
プロキシ・サーバ、通信システム、通信方法及びプログラム Download PDFInfo
- Publication number
- JP4336904B2 JP4336904B2 JP2008506836A JP2008506836A JP4336904B2 JP 4336904 B2 JP4336904 B2 JP 4336904B2 JP 2008506836 A JP2008506836 A JP 2008506836A JP 2008506836 A JP2008506836 A JP 2008506836A JP 4336904 B2 JP4336904 B2 JP 4336904B2
- Authority
- JP
- Japan
- Prior art keywords
- sip
- proxy server
- message
- server
- register request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1073—Registration or de-registration
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
SIPネットワークの一般的な構成は、後述する非特許文献1に記載されている。SIPネットワークは、ロケーション・サーバと、SIPサーバと、ユーザ・エージェント(UA:user agent)とから構成されている。ユーザ・エージェントは、非特許文献1のP.76に、「SIPは、エンド・システム間のクライアント−サーバ・モデルに基づいています。このエンド・システムに相当するのが、ユーザ・エージェント(UA:User Agent)です。ユーザ・エージェントとは、具体的には電話機やパソコンなどのエンド・システムのことですが、これらのエンド・システム間でリクエスト(要求)とレスポンス(応答)をやり取りすることによって、サービスを実現します」と説明されている。本明細書では、上記説明文記載のリクエストをSIP要求、レスポンスをSIP応答と呼ぶ。
SIPサーバは、非特許文献1のP.77に記載されているように、(1)SIP要求やSIP応答を中継するプロキシ・サーバ機能と、(2)SIP要求の宛先の問合せに利用するリダイレクト・サーバ機能と、(3)SIPネットワーク上のユーザ・エージェント情報の登録を受け付ける登録サーバ機能とを有する。ここで、ユーザ・エージェント情報とは、例えば、ユーザ・エージェントにアクセスするための識別子であるURI(uniform resource identifier)やユーザ・エージェントが使用するIPアドレスである。なお、本明細書では、このユーザ・エージェントにより登録されるユーザ・エージェント情報を登録情報と呼ぶ。
ロケーション・サーバは、非特許文献1のP.81に、「登録サーバで維持されるユーザ・エージェントの情報を蓄積し、プロキシ・サーバ機能やリダイレクト・サーバ機能によって利用される、データベース・サービスを提供します」と記載されている。具体的には、非特許文献1のP.112に記載されているように、SIP要求のREGISTERリクエストを使用して、ユーザ・エージェントの登録情報を更新する。
この登録情報の更新は、ある一つのSIPサーバに対してユーザ・エージェントがREGISTERリクエストを送信することが前提となっている。これは、図56に示す、SIPで採用されているユーザ・エージェントの認証方式(Digest認証)において顕著である。
図56は、SIPで採用されているDigest認証の流れを示すシーケンス図である。まず、ユーザ・エージェント2000がSIPサーバ2500に対してREGISTERリクエストを送信する。本明細書では、このユーザ・エージェント2000が最初にSIPサーバ2500に送信するREGISTERリクエストをinitial REGISTERリクエストと呼ぶ。ユーザ・エージェント2000からのinitial REGISTERリクエストを受信したSIPサーバ2500は、Digest認証で使用するnonceを生成し、そのnonce値をSIP応答(401)に付加してユーザ・エージェント2000に返信する。ユーザ・エージェント2000では、受信したnonceを鍵にユーザ識別子とパスワードをハッシュし、結果をAuthorizationヘッダに格納したREGISTERリクエストをSIPサーバ2500に転送する。本明細書では、このAuthorizationヘッダを付加したREGISTERリクエストを認証REGISTERリクエストと呼ぶ。認証REGISTERリクエストを受信したSIPサーバ2500は、ユーザ・エージェント2000と同様、自身が生成したnonce値を使用して、ユーザ・エージェント2000のユーザ識別子とパスワードをハッシュする。その後、ユーザ・エージェント2000からの認証REGISTERリクエストに格納されたAuthorizationヘッダ値と比較し、同一の場合には、正当なユーザ・エージェントからのREGISTERリクエストであると判断し、REGISTERリクエストのデータを使用して登録情報を更新後、SIP応答(200 OK)を返信する。
この図56から、まず、initial REGISTERリクエストは、ユーザ・エージェント2000のユーザ識別子とパスワードを参照可能なSIPサーバ2500に送信される必要がある。SIPサーバ2500で参照不可能な場合には、ユーザ識別子とパスワードを使用したハッシュが計算できないため、認証に失敗するからである。更に、initial REGISTERリクエストと認証REGISTERリクエストとは同一のSIPサーバ2500に転送される必要があることが分かる。転送されるSIPサーバ2500が異なる場合には、nonce値がSIPサーバ2500間で引き継がれないため、正当なユーザ・エージェント2000からの認証REGISTERリクエストであっても、SIPサーバ2500側でのハッシュが計算できず、認証に失敗するためである。
以上から、REGISTERリクエストは、ユーザ識別子とパスワードを参照可能なSIPサーバ2500に対し、REGISTERリクエスト処理が完了するまで送信し続ける必要があることが分かる。
このような特徴を持つREGISTERリクエストのSIPサーバ2500での処理を考慮すると、登録情報を他のSIPサーバ2500に複製する場合には例えば以下の2つの形態が考えられる。なお、本明細書では、複製対象の登録情報を管理するSIPサーバ2500を現用SIPサーバ3000、複製された登録情報を管理するSIPサーバを予備SIPサーバ4000と呼ぶ。更に、以下の3形態を示す図では、SIPサーバ2500が2つのみ記載されているが、登録情報の複製先となるSIPサーバ2500は何台でも構わない。
第1の形態は、ユーザ・エージェント2000自身が複数のSIPサーバ2500にREGISTERリクエストを転送する形態である。すなわち、第1の形態は、図57に示すように、現用および予備SIPサーバ全てにユーザ・エージェント2000のユーザ識別子とパスワードを保持させ、ユーザ・エージェント2000が各SIPサーバと個別にDigest認証を行い、登録情報を更新していくのである。
第2の形態は、現用SIPサーバ3000が予備SIPサーバ4000にREGISTERリクエストを転送する形態である。すなわち、第2の形態は、図58に示すように、ユーザ・エージェント2000と現用SIPサーバ3000がDigest認証を行い、登録情報の更新を完了した後、現用SIPサーバ3000から予備SIPサーバ4000にREGISTERリクエストを送信することによって、予備SIPサーバ4000の登録情報を更新するのである。
[非特許文献1]「改訂版 SIP教科書」「ユーザ・エージェントとSIPサーバの関係」(P.78の図5−2)
しかし、上記の2形態のうち、第1の形態では、電話機等の簡易なユーザ・エージェント2000に対しても複数SIPサーバへ2500のREGISTERリクエスト転送機能を搭載する必要があり、ユーザ・エージェント2000側にコストが掛かるという課題がある。更に、ユーザ・エージェント2000とSIPサーバ2500間での登録情報更新に掛かるトラフィックが、予備SIPサーバ4000の数に比例して数倍程度に増加してしまうという課題もある。
更に、第2の形態では、既存SIPサーバ2500において、REGISTERリクエストの受信・処理機能は有していても、他SIPサーバ2500への発信機能は有していない可能性がある。そのため、このようなSIPサーバ2500への機能拡張が必要となり、SIPサーバ2500間での登録情報複製の実現にコストが掛かるという課題がある。
上記実施形態の課題を解決するために、図59に示すように、ユーザ・エージェント2000とSIPサーバ2500との中間にプロキシ・サーバ1000を配備する形態を想定し、このプロキシ・サーバ1000のSIP要求とSIP応答を仲介する機能に着目すると、関連技術としてSIPプロキシ・サーバが挙げられる。SIPプロキシ・サーバが保持する機能は、非特許文献1において、ユーザ・エージェント2000からのSIP要求を解釈し、必要な処理を行ってから、次の宛先にSIP要求を送信すると記載されている。
しかし、関連技術のSIPプロキシ・サーバを活用し、既存のユーザ・エージェント2000およびSIPサーバ2500への適用容易性と、ユーザ・エージェント2000とSIPサーバ2500間のトラフィックの抑制に配慮して、登録情報を現用SIPサーバ3000と予備SIPサーバ4000間で複製する場合には下記の課題がある。
第1の課題は、SIPプロキシ・サーバでは登録情報の複製が実現できないことが挙げられる。これは、前記非特許文献1に記載されているように、SIPプロキシ・サーバはSIP要求を生成しないためである。つまり、SIPプロキシ・サーバは、予備SIPサーバ4000へ送信するREGISTERリクエストを生成できないのである。
また、仮に、SIPプロキシ・サーバがREGISTERリクエストの生成を行えたとしても更に以下の課題が存在する。
第2の課題は、Digest認証を要求する予備SIPサーバ4000に対し、ユーザ・エージェント2000のユーザ識別子とパスワードを使用したDigest認証でREGISTERリクエストを送信することは不可能なことである。これは、ユーザ・エージェント2000のユーザ識別子とパスワードを保持しないSIPプロキシ・サーバがユーザ・エージェント2000のユーザ識別子とパスワードを獲得するためには、ユーザ・エージェント2000と現用SIPサーバ3000でのDigest認証を破るしか手段がないためである。
第3の課題は、ユーザ・エージェント2000から現用SIPサーバ3000宛に送信されたREGISTERリクエストの正当性を確認する手段を設けなければならないことである。これは、例えば、SIPネットワークに対してDoS(denial of service)攻撃を仕掛ける場合、ユーザ・エージェント2000からのinitial REGISTERリクエストには無意味なデータが格納され、大量に送信されることが想定される。この場合に、SIPプロキシ・サーバが、現用SIPサーバ3000での処理結果を参照しないで、予備SIPサーバ4000に対し、initial REGISTERリクエストを複製・送信してしまうと、予備SIPサーバ4000までもDoS攻撃を受けることになる。このように、プロキシ・サーバ1000はユーザ・エージェント2000から現用SIPサーバ3000宛に送信されたREGISTERリクエストの正当性を確認する必要があるのである。
本発明の目的は、Digest認証を要求するサーバに対してアクセス者及び通信の正当性を示した上で、複数サーバ間で登録情報を複製することを可能とするSIPネットワークにおけるプロキシ・サーバを提供することである。
(発明の効果)
本発明によれば、以下に説明する効果を達成することができる。
第1の効果は、登録情報の複製を実現できることである。これは、プロキシ・サーバが、プロキシ・サーバが本来有する機能に加え、予備SIPサーバに送信するREGISTERリクエスト(メッセージ)の生成機能を保持するためである。
第2の効果は、登録情報の複製に際し、予備SIPサーバへのアクセス者の正当性を予備SIPサーバに示すことが可能なことである。これは、プロキシ・サーバのユーザ識別子とパスワードをプロキシ・サーバに保持させ、プロキシ・サーバと予備SIPサーバ間でDigest認証を行うためである。
図2は、第1の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図3は、第1の実施の形態に係る一時格納機能でのREGISTERリクエストの格納形態の一例を示す図である。
図4は、第1の実施の形態に係るプロキシ・サーバのハードウェア構成を示すブロック図である。
図5は、第1の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図6は、第1の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図7は、第1の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図8は、本発明の第2の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図9は、第2の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図10は、第2の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図11は、第2の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図12は、本発明の第3の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図13は、第3の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図14は、第3の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図15は、第3の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図16は、本発明の第4の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図17は、第4の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図18は、第4の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図19は、第4の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図20は、本発明の第5の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図21は、第5の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図22は、第5の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図23は、第5の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図24は、本発明の第6の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図25は、第6の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図26は、第6の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図27は、第6の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図28は、本発明の第7の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図29は、第7の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図30は、第7の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図31は、第7の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図32は、本発明の第8の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図33は、第8の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図34は、第8の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図35は、第8の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図36は、本発明の第9の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図37は、第9の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図38は、第9の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図39は、第9の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図40は、本発明の第10の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図41は、第10の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図42は、第10の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図43は、第10の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図44は、本発明の第11の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図45は、第11の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図46は、第11の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図47は、第11の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図48は、本発明の第12の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図49は、第12の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図50は、第12の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図51は、第12の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図52は、本発明の第13の実施の形態に係るプロキシ・サーバの構成を示すブロック図である。
図53は、第13の実施の形態に係るプロキシ・サーバの動作を示すフローチャートである。
図54は、第13の実施の形態に係るプロキシ・サーバを含むシステム全体でのデータの流れを示す図である。
図55は、第13の実施の形態に係るプロキシ・サーバを含む、システム全体の動作を示すシーケンス図である。
図56は、関連技術としてのSIPにおけるDigest認証の動作を示すシーケンス図である。
図57は、関連技術における登録情報の複製に際し、ユーザ・エージェントが現用および予備SIPサーバへREGISTERリクエストを送信する形態を示す図である。
図58は、関連技術における登録情報の複製に際し、現用SIPサーバが予備SIPサーバへREGISTERリクエストを送信する形態を示す図である。
図59は、関連技術におけるユーザ・エージェントとSIPサーバの間にプロキシ・サーバを配備する形態を示す図である。
次に、本発明の第1の実施の形態について、図表を参照して詳細に説明する。
(第1の実施の形態の構成)
図1に、本発明の第1の実施の形態に係る通信システムのブロック図を示す。
図1に示すように、本発明の第1の実施の形態に係る通信システムは、登録情報31を有する現用SIPサーバ30及びホットスタンバイしており登録情報41を有する予備SIPサーバ40と接続されるプロキシ・サーバ10が、ネットワーク50を介してユーザ・エージェント20との通信を行う。ここで、SIPシステム1は、プロキシ・サーバ10と、現用SIPサーバ30と、予備SIPサーバ40とを備え、ネットワーク50に接続する。
次いで、図2に、本発明の第1の実施の形態に係るプロキシ・サーバ10のブロック図を示す。
図2に示すように、本発明の第1の実施の形態に係るプロキシ・サーバ10は、SIPプロキシ・サーバ機能11に加え、SIPプロキシ・サーバ機能11が受信したメッセージに関して、メッセージの種類と送信元を判別するメッセージ判別機能12と、SIPプロキシ・サーバ機能11が受信したREGISTERリクエストを一時的に格納する一時格納機能13と、予備SIPサーバに転送するinitialおよび認証REGISTERリクエストを生成するリクエスト生成機能14とを備える。
なお、一時格納機能13は、例えば、以下のような形態でREGISTERリクエストを格納する。図3は、一時格納機能13でのREGISTERリクエストの格納形態の一例を示す図である。この図に示すように、REGISTERリクエストは表形式で格納され、REGISTERリクエストの検索時に使用するCSeq、REGISTERリクエストのFromヘッダに格納される送信元を識別するユーザ・エージェント識別子、REGISTERリクエスト(プロキシ・サーバ10が受信したREGISTERリクエスト)から構成される。
なお、プロキシ・サーバ10が予備SIPサーバとの間で実施するDigest認証に使用する、プロキシ・サーバのユーザ識別子とパスワードは、認証REGISTERリクエスト生成時に必要となるため、リクエスト生成機能14が保持する。
従って、本実施の形態の特徴として、プロキシ・サーバ10は、プロキシ・サーバ10自身のユーザ識別子とパスワードを用いてDigest認証によって、REGISTERリクエストの送受信を予備SIPサーバ40と行う。
ここで、プロキシ・サーバ10のハードウェア構成の説明をする。
図4は、本実施の形態による通信システムのプロキシ・サーバ10のハードウェア構成を示すブロック図である。
図4を参照すると、本発明によるプロキシ・サーバ10は、一般的なコンピュータ装置と同様のハードウェア構成によって実現することができ、CPU(Central Processing Unit)301、RAM(Random Access Memory)等のメインメモリであり、データの作業領域やデータの一時退避領域に用いられる主記憶部302、ネットワーク50を介してデータの送受信を行う通信制御部303、液晶ディスプレイ、プリンタやスピーカ等の提示部304、キーボードやマウス等の入力部305、周辺機器と接続してデータの送受信を行うインタフェース部306、ROM(Read Only Memory)、磁気ディスク、半導体メモリ等の不揮発性メモリから構成されるハードディスク装置である補助記憶部307、本情報処理装置の上記各構成要素を相互に接続するシステムバス308等を備えている。
本発明によるプロキシ・サーバ10は、その動作を、プロキシ・サーバ10内部にそのような機能を実現するプログラムを組み込んだ、LSI(Large Scale Integration)等のハードウェア部品からなる回路部品を実装してハードウェア的に実現することは勿論として、上記した各構成要素の各機能を提供するプログラムを、コンピュータ処理装置上のCPU301で実行することにより、ソフトウェア的に実現することができる。
すなわち、CPU301は、補助記憶部307に格納されているプログラムを、主記憶部302にロードして実行し、プロキシ・サーバ10の動作を制御することにより、上述した各機能をソフトウェア的に実現する。
(第1の実施の形態の動作)
次に、本発明の第1の実施の形態に係るプロキシ・サーバ10の動作について図表を参照して詳細に説明する。
図5に、本発明の第1の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートを示す。
いま、SIPプロキシ・サーバ機能11が外部からメッセージを受信したとする(ステップS401)。次に、メッセージ判別機能12が、SIPプロキシ・サーバ機能11によって受信したメッセージの種類を判別する(ステップS402)。
ステップS402の結果、受信したメッセージがSIP応答(200 OK)の場合には、更に、メッセージ判別機能12が上記受信したメッセージの送信元を判別する(ステップS403)。
ステップS403の結果、送信元が現用SIPサーバの場合には、リクエスト生成機能14が、予備SIPサーバに送信するinitial REGISTERリクエストを生成する(ステップS405)。
例えば、この生成処理は下記のようになる。まず、リクエスト生成機能14は、一時格納機能13に格納されているREGISTERリクエストのうち、ステップS401で受信したSIP応答(200 OK)に対応するREGISTERリクエストを選定する。この選定処理は、SIP応答(200 OK)でのCSeqヘッダとFromヘッダの値と同一の値を持つREGISTERリクエストを検索することによって実現できる。
次に、リクエスト生成機能14は、選定したREGISTERリクエストのヘッダ値を複製し、必要に応じて変更することによって、予備SIPサーバ40に送信する上記initial REGISTERリクエストを生成する。この変更対象となるヘッダには、例えば、ToヘッダやFromヘッダに格納されるURIやCall−IDヘッダおよびCSeqヘッダなどがある。
従って、ステップS405の結果、プロキシ・サーバ10は、プロキシ・サーバ10自身で生成したinitial REGISTERリクエストについて、予備SIPサーバ40と送受信を行う。
ステップS402の結果、受信したメッセージがREGISTERリクエストの場合には、一時格納機能13が、受信した当該REGISTERリクエストを複製し、格納する(ステップS406)。
この複製処理で格納されたREGISTERリクエストが前述したステップS405で活用されるのである。なお、このステップS402およびステップS406の処理において、例えばDoS攻撃等、ユーザ・エージェントからの不当なREGISTERリクエストの複製・格納を極力排除するには、ステップS402で識別するREGISTERリクエストを認証REGISTERリクエストとし、ステップS406でこの認証REGISTERリクエストを格納することになる。
ステップS402の結果、ステップS401で受信したメッセージがSIP応答(401 Unauthorized)の場合には、更に、メッセージ判別機能12が、メッセージの送信元を判別する(ステップS407)。
ステップS407の結果、SIP応答(401 Unauthorized)の送信元が予備SIPサーバであった場合には、予備SIPサーバとのDigest認証を完了すべく、リクエスト生成機能14が、予備SIPサーバに転送する認証REGISTERリクエストを生成する(ステップS408)。
この生成処理は、図56で示した、一般的なDigest認証の処理に従う。具体的には、リクエスト生成機能14が、SIP応答(401 Unauthorized)に格納されているnonce値を鍵に、プロキシ・サーバ10自身のユーザ識別子とパスワードの組を、認証やデジタル署名などに使われるハッシュ関数の一つであるMD5(message digest 5)でハッシュし、その後、ステップS405でのinitial REGISTERメッセージ生成と同様の処理で認証REGISTERリクエストを生成する。ここで、ステップS405との差異は、Authorizationヘッダを設け、そのヘッダに計算したハッシュ値を格納することである。
従って、ステップS408の結果、プロキシ・サーバ10は、プロキシ・サーバ10自身のユーザ識別子とパスワードを用いてDigest認証によって、認証REGISTERリクエストの送受信を予備SIPサーバ40と行う。
ステップS402の結果、受信したメッセージがSIP応答(200 OK)またはREGISTERリクエストまたはSIP応答(401 Unauthrized)でない場合には、更に、メッセージ判別機能12が、メッセージの送信元を判別する(ステップS409)。
ステップS409の結果、送信元が現用SIPサーバであった場合、または、ステップS405の結果、予備SIPサーバに送信するinitial REGISTERリクエストを生成した場合、または、ステップS406の結果、ユーザ・エージェントから送信されたREGISTERリクエストを複製・格納した場合、または、ステップS408の結果、予備SIPサーバに送信する認証REGISTERを生成した場合、または、ステップS407の結果、SIP応答(401 Unauthorized)の送信元が現用SIPサーバの場合には、SIPプロキシ・サーバ機能11が、ステップS401で受信したメッセージをメッセージに指定された宛先に、または、initialおよび認証REGISTERリクエストを予備SIPサーバに送信する(ステップS410)。
ステップS403の結果、SIP応答(200 OK)の送信元が予備SIPサーバの場合、または、ステップS409の結果、その他のSIP応答の送信元が予備SIPサーバの場合には、一時格納機能13によって格納されているREGISTERリクエストを削除する(ステップS404)。
この削除処理は、例えば、ステップS401で受信したSIP応答のCSeqヘッダとFromヘッダの値と同一の値を持つREGISTERリクエストを検索することで実現可能である。
ステップS404の結果、該当REGISTERリクエストを削除した場合、または、ステップS410の結果、SIPプロキシ・サーバ機能11がメッセージを送信した場合には処理を終了する。
次に、本発明の第1の実施の形態に係るプロキシ・サーバ10を含むシステム全体の動作について図表を参照して詳細に説明する。
まず、図6に本発明の第1の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示す。
図6に示すように、このシステムでは、ユーザ・エージェント20から送信されるREGISTERリクエストは常に現用SIPサーバ30に転送される(図6のa)。同時に、このREGISTERリクエストをプロキシ・サーバ10が複製し、保持する。
プロキシ・サーバ10は、現用SIPサーバ30からのSIP応答(200 OK)受信後(図6のb)、複製したREGISTERリクエストに基づいて予備SIPサーバ40へ送信するREGISTERリクエストを生成し、予備SIPサーバ40へ転送する(図6のc)。
また、本発明の第1の実施の形態に係るプロキシ・サーバ10を含めたシステム全体での動作シーケンスを図7に示す。なお、この図は、ユーザ・エージェント20からの認証REGISTERリクエストをプロキシ・サーバ10で複製する場合を示している。
図7に示すように、プロキシ・サーバ10は、ユーザ・エージェント20から現用SIPサーバ30へ宛てたREGISTERリクエストの処理完了を確認後(200 OK受信後)、プロキシ・サーバ10自身のユーザ識別子とパスワードと、ユーザ・エージェント20から受信したREGISTERリクエストとに基づいて生成したREGISTERリクエストを予備SIPサーバ40に送信し、予備SIPサーバ40との間でDigest認証を行う。
(第1の実施の形態の効果)
このように、本実施の形態よれば、予備SIPサーバ40にアクセス者(プロキシ・サーバ10)と送信するREGISTERリクエストの正当性を示すことができる。
その理由は、プロキシ・サーバ10のユーザ識別子とパスワードを保持するプロキシ・サーバ10を含めたシステムが、ユーザ・エージェント20から送信されたREGISTERリクエストの正常処理完了を確認した後、予備SIPサーバ40とDigest認証を行い、当該正常処理が完了したREGISTERリクエストに基づいて生成したREGISTERリクエスト(現用SIPサーバ30で処理されたものの複製)を予備SIPサーバ40に送信するからである。
また、本実施の形態よれば、既存ユーザ・エージェントおよび既存SIPサーバへの適用が技術的・経済的に容易であり、また、現用SIPサーバ30と予備SIPサーバ40間で登録情報をアクティブかつ相互にバックアップできる。
その理由は、REGISTERリクエストの複製・送信をプロキシ・サーバ10が担当することで、ユーザ・エージェント20はSIPで規定された登録情報更新手順に則ってREGISTERリクエストをプロキシ・サーバ10に送信するだけでよく、かつ、各SIPサーバは保持する機能に基づき、一般的なDigest認証に従い認証されたREGISTERリクエストを処理するだけでよいからである。この結果、ユーザ・エージェント20がREGISTERリクエストを送信したタイミングで現用SIPサーバ30および予備SIPサーバ40登録情報が共に更新される。更に、各SIPサーバは、登録情報複製のためにプロキシ・サーバ10が生成したREGISTERリクエストと、ユーザ・エージェント20が送信したREGISTERリクエストとが同様に処理されるため、SIPシステム1は、ユーザ・エージェント20が送信したREGISTERリクエストとプロキシ・サーバ10が生成したREGISTERリクエストとを混合して各SIPサーバに送信することが可能である。これらの特徴により、登録情報をアクティブかつ相互にバックアップできるのである。
さらに、本実施の形態よれば、ユーザ・エージェント20とSIPサーバ間の登録情報更新に掛かるトラフィック量を抑制できる。
その理由は、予備SIPサーバ40へのREGISTERリクエストの送信を、現用SIPサーバ30とユーザ・エージェント20の中間に位置するプロキシ・サーバ10が行うためである。すなわち、一般的に、ユーザ・エージェント20が存在するパーソナルコンピュータや携帯電話は、接続するアクセス網の帯域が、SIPサーバが存在するコア・ネットワークの帯域よりも格段に狭いところ、プロキシ・サーバ10がREGISTERリクエストの複製・送信を実現することで、ユーザ・エージェント20から送信されるREGISTERリクエストを削減でき、結果、アクセス網での使用帯域を抑制することができるからである。
(第2の実施の形態)
次に、本発明の第2の実施の形態に係るプロキシ・サーバ10について図表を参照しながら詳細に説明する。
(第2の実施の形態の構成)
図8に、本発明の第2の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図を示す。
図8に示すように、本発明の第2の実施の形態に係るプロキシ・サーバ10は、一般的なSIPプロキシ・サーバ機能11に加えて、SIPプロキシ・サーバ機能11が受信したメッセージの種類を識別するメッセージ判別機能12と、SIPプロキシ・サーバ機能11が受信したメッセージに含まれるExpiresヘッダの値を変更(増加・減少)する有効期限更新機能15と、REGISTERリクエストの宛先を決定する際に参照する情報(宛先情報)に基づき、REGISTERリクエストの送信先を決定する宛先決定機能16とを備える。
なお、宛先情報は、例えば、ユーザ・エージェント20とREGISTERリクエストの転送先との組として実現でき、宛先決定機能16に保持される。
(第2の実施の形態の動作)
次に、本発明の第2の実施の形態に係るプロキシ・サーバ10の動作について図表を参照して詳細に説明する。
図9は、本発明の第2の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
いま、SIPプロキシ・サーバ機能11が外部からメッセージを受信したとする(ステップS701)。次に、メッセージ判別機能12が、SIPプロキシ・サーバ機能11によって受信したメッセージの種別を判別する(ステップS702)。
ステップS702の結果、受信したメッセージがREGISTERリクエストである場合には、有効期限更新機能15が、REGISTERリクエストのExpiresヘッダの値を増加させる(ステップS703)。
この更新処理は、例えば、1台の予備SIPサーバ40が存在する場合には2倍、2台の予備SIPサーバ40が存在する場合には3倍など、予備SIPサーバ数に応じて当該Expiresヘッダの値を増加させる。
次に、宛先決定機能16が、REGISTERリクエストの送信先を決定する(ステップS704)。
この決定処理は、例えば、以下のように実現できる。すなわち、宛先決定機能16は、REGISTERリクエストのFromヘッダに記載されたユーザ・エージェント20の識別子を参照して、宛先情報から該当ユーザ・エージェント20からのREGISTERリクエストの転送先を取得する。この転送先には、現用SIPサーバ30または予備SIPサーバ40が記載されている。
ステップS704において、宛先決定機能16は、REGISTERリクエストがinitial REGISTERリクエストの場合には、該当転送先に記載されていない転送先(現用SIPサーバ30と記載されていれば「予備SIPサーバ40」)をREGISTERリクエストの送信先とし、一方、REGISTERリクエストが認証REGISTERリクエストの場合には、該当転送先をREGISTERリクエストの転送先とする。
その後、宛先決定機能16は、ステップS704で決定した宛先を宛先情報に反映させる(ステップS705)。
ステップS702の結果、SIPプロキシ・サーバ機能11が受信したメッセージがSIP応答(200 OK)の場合には、有効期限更新機能15が該当SIP応答のExpiresヘッダの値を減少させる(ステップS706)。
この更新処理は、ステップS703の更新処理で増加した分を減少させる。すなわち、例えば、有効期限更新機能15は、ステップS703においてREGISTERリクエストのExpiresヘッダ値を2倍した場合には、ステップS705において当該Expiresヘッダ値を1/2とするのである。
ステップS702の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類がREGISTERリクエストおよびSIP応答(200 OK)でない場合、または、ステップS705の結果、宛先情報の更新が完了した場合、または、ステップS706の結果、SIP応答(200 OK)のExpiresヘッダの値を減少した場合には、SIPプロキシ・サーバ機能11が、指定された宛先にメッセージを送信する(ステップS707)。指定される宛先は、REGISTERリクエストの場合にはステップS704で決定された宛先であり、それ以外はSIPプロキシ・サーバ機能11が受信したメッセージに記載された宛先である。
次に、本発明の第2の実施の形態に係るプロキシ・サーバ10を含むシステム全体の動作について図表を参照して詳細に説明する。
まず、図10に本発明の第2の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示す。
図10に示すように、このシステムでは、ユーザ・エージェント20から送信されるREGISTERリクエストは全て現用SIPサーバ30に送信される訳ではない。プロキシ・サーバ10は、例えば、現用SIPサーバ30へ転送した次は、予備SIPサーバ40へ転送、という具合に、現用SIPサーバ30および予備SIPサーバ40へREGISTERリクエストを順番に転送する(図10のaとb)。つまり、現用SIPサーバ30および予備SIPサーバ40へは各々数回に一度しかREGISTERリクエストが転送されないことになる。この状況でも、ユーザ・エージェント20に関する登録情報が無効とならないように、プロキシ・サーバ10は、ユーザ・エージェント20から受信したREGISTERリクエストの有効期限を変更して現用SIPサーバ30および予備SIPサーバ40へREGISTERリクエストを転送する。
また、第2の実施の形態に係るプロキシ・サーバ10を含めたシステム全体の動作シーケンスを図11に示す。
図11に示すように、プロキシ・サーバ10は、ユーザ・エージェント20からinitial REGISTERリクエストを受信した場合には、現用SIPサーバ30と予備SIPサーバ40のいずれに当該initial REGISTERリクエストを送信するかを決定する一方、ユーザ・エージェント20から認証REGISTERリクエストを受信した場合には、Digest認証を完了するために、initial REGISTERリクエストを送信した先に当該認証REGISTERリクエストを転送している。
(第2の実施の形態の効果)
本実施の形態によれば、ユーザ・エージェント20の保持している、ユーザ・エージェント20を識別するユーザID(ユーザ・エージェント識別子)およびパスワードのみを用いて各SIPサーバの登録情報の複製が可能となる。
その理由は、宛先決定機能16を備えることによって、ユーザ・エージェント20と現用SIPサーバ30間で行われたDigest認証が、ユーザ・エージェント20と予備SIPサーバ40間においても行われるからである。
また、本実施の形態によれば、各SIPサーバへは数回に一度しか到着しないREGISTERリクエストでも登録情報の有効期限が切れないようになっている。
その理由は、有効期限更新機能15が、認証REGISTERリクエストのExpiresヘッダの値を増加させるからである。
また、本実施の形態によれば、既存ユーザ・エージェントおよび既存SIPサーバへの適用が技術的・経済的に容易であり、また、現用SIPサーバ30と予備SIPサーバ40間で登録情報をアクティブかつ相互にバックアップできる。この結果、ユーザ・エージェント20が発行するREGISTERリクエストを現用または予備SIPサーバ40へ順に転送するため、このExpiresヘッダ値程度の間隔で登録情報が随時更新される。更に、各SIPサーバは、登録情報複製のためにプロキシ・サーバ10が宛先を変更したREGISTERリクエストと、ユーザ・エージェント20が送信したREGISTERリクエストとが同様に処理されるため、SIPシステム1は、ユーザ・エージェント20が送信したREGISTERリクエストと、プロキシ・サーバ10が宛先を変更したREGISTERリクエストとを混合して各SIPサーバに送信することが可能である。これらの特徴により、登録情報をアクティブかつ相互にバックアップできるのである。
その理由は、プロキシ・サーバ10が、REGISTERリクエストの送信先の変更およびExpiresヘッダの値の調整を行うからであるため、第1の実施の形態と同様に、ユーザ・エージェント20および各SIPサーバからすれば、通常のREGISTERリクエストの処理として実現されているからである。
また、本実施の形態によれば、第1の実施の形態と異なり、プロキシ・サーバ10が、自身のユーザ識別子とパスワードを保持する必要がない。
その理由は、宛先決定機能16を備えることによって、ユーザ・エージェント20と予備SIPサーバ40間でDigest認証が行われるため、プロキシ・サーバ10と予備SIPサーバ40間でのDigest認証が不要だからであり、プロキシ・サーバ10でのメッセージの生成が不要だからである。
(第3の実施の形態)
次に、本発明の第3の実施の形態に係るプロキシ・サーバ10について、図面を参照して詳細に説明する。
(第3の実施の形態の構成)
図12に、本発明の第3の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図を示す。
図12に示すように、本発明の第3の実施の形態に係るプロキシ・サーバ10は、SIPプロキシ・サーバ機能11に加えて、メッセージの種類および送信元を識別するメッセージ判別機能12と、ユーザ・エージェントにinitial REGISTERリクエストの再送を促すSIP応答(再送応答)を生成する再送応答生成機能17と、宛先情報を参照してREGISTERリクエストの転送先を決定する宛先決定機能16とを備える。
なお、宛先情報は、本発明の第2の実施の形態に係るプロキシ・サーバ10と同様に、例えば、ユーザ・エージェント20とREGISTERリクエストの送信先との組であり、宛先決定機能16に保持される。
(第3の実施の形態の動作)
次に、本発明の第3の実施の形態に係るプロキシ・サーバ10の動作について図表を参照して詳細に説明する。
図13は、本発明の第3の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
いま、SIPプロキシ・サーバ機能11が外部からメッセージを受信したとする(ステップS1001)。次に、メッセージ判別機能12が、SIPプロキシ・サーバ機能11によって受信したメッセージの種類を判定する(ステップS1002)。
ステップS1002の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類がREGISTERリクエストの場合には、宛先決定機能16がREGISTERリクエストの送信先を決定する(ステップS1003)。
この決定処理は、例えば、以下のようにして実現できる。宛先決定機能16が、受信したREGISTERリクエストのFromヘッダに記載されているユーザ・エージェント20の識別子に基づいて宛先情報を検索する。宛先決定機能16は、この検索の結果、宛先情報に記載されている送信先をREGISTERリクエストの送信先とするのである。
また、ステップS1002の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類がSIP応答(200 OK)の場合には、更に、メッセージ判別機能12が、メッセージの送信元を判別する(ステップS1004)。
ステップS1004の結果、送信元が現用SIPサーバ30の場合には、再送応答生成機能17が、ユーザ・エージェント20にinitial REGISTERリクエストを再送させるための再送応答を生成する(ステップS1005)。
この生成処理は、例えば、SIPプロキシ・サーバ機能11が、SIPで「サービスを利用できない」ことを示すSIP応答(503 Service Unavailable)に、「Retry−Afterヘッダ」を付加することによって、これを受信したユーザ・エージェント20はRetry−Afterヘッダ値経過後に再度initial REGISTERリクエストをプロキシ・サーバ10に転送することになる。なお、その他のヘッダは現用SIPサーバ30からのSIP応答(200 OK)を使用する。また、この生成処理の他の方法としては、例えば、SIPプロキシ・サーバ機能11が、SIP応答(408 Request Timeout)をユーザ・エージェント20に送信することによって、ユーザ・エージェント20は該当SIP応答受信後いつでもSIP要求の修正なしでプロキシ・サーバ10に再送信することになる。
ステップS1004の結果、SIP応答(200 OK)の送信元が予備SIPサーバ40であった場合、または、ステップS1005の結果、ユーザ・エージェントへの再送応答の生成が完了した場合には、宛先決定機能16が、宛先情報を更新する(ステップS1006)。
この更新処理は、例えば、以下のようになる。まず、宛先決定機能16が、SIP応答(200 OK)のToヘッダに記載されているユーザ・エージェント20を参照して、宛先情報を検索しておく。SIP応答(200 OK)が現用SIPサーバ30から送信された場合には、宛先決定機能16は、該当宛先情報のREGISTERリクエストの転送先を「予備SIPサーバ40」に変更する。一方、SIP応答(200 OK)が予備SIPサーバ40から送信された場合には、宛先決定機能16は、該当宛先情報のREGISTERリクエストの転送先を「現用SIPサーバ30」と変更する。
ステップS1002の結果、SIPプロキシ・サーバ機能11が受信したメッセージがREGISTERリクエストおよびSIP応答(200 OK)でない場合、または、ステップS1003の結果、REGISTERリクエストの送信先が決定された場合、または、ステップS1006の結果、宛先情報が更新された場合には、SIPプロキシ・サーバ機能11が、指定された宛先にメッセージを送信する(ステップS1007)。
この時、REGISTERリクエストはステップS1003で決定された宛先に送信され、現用SIPサーバ30からのSIP応答(200 OK)以外のSIP応答と、ステップS1005で生成された再送応答はユーザ・エージェント20へ送信される。
次に、本発明の第3の実施の形態に係るプロキシ・サーバ10を含むシステム全体の動作について図表を参照して詳細に説明する。
まず、図14に本発明の第3の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示す。
図14に示すように、ユーザ・エージェント20から送信されたREGISTERリクエスト(図14のa)の処理完了を示すSIP応答(200 OK)(図14のb)を受信したプロキシ・サーバ10は、ユーザ・エージェント20にREGISTERリクエストの再送応答(図14のc)を送信する。
再送応答を受信したユーザ・エージェント20は、SIPのプロトコル規約で規定されている処理に従って再度REGISTERリクエストをプロキシ・サーバ10に送信し、プロキシ・サーバ10は、この再送されたREGISTERリクエストを予備SIPサーバ40に転送する(図14のd)。
次に、本発明の第3の実施の形態に係るプロキシ・サーバ10を含むシステム全体の動作シーケンスを図15に示す。
図15に示すように、本実施の形態に係るプロキシ・サーバ10を含むシステムは、現用SIPサーバ30でのREGISTERリクエストの処理が完了した場合(SIP応答(200 OK)受信)には、ユーザ・エージェント20に対し、initial REGISTERリクエストの再送応答を送信し、それに基づき、ユーザ・エージェント20が送信したinitial REGISTERリクエストを予備SIPサーバ40に転送することで、現用・予備SIPサーバの登録情報を、Digest認証を行いながら更新することができる。ユーザ・エージェント20からすれば、最初のREGISTERリクエスト処理は失敗するが、SIPの規定に従った再送処理により登録情報の更新が完了したと認識される。一方、現用SIPサーバ30では通常のREGISTERリクエストの処理として認識される。
(第3の実施の形態の効果)
本実施の形態によれば、ユーザ・エージェント20の保持している、ユーザ・エージェント20を識別するユーザID(ユーザ・エージェント識別子)およびパスワードのみを用いて各SIPサーバの登録情報の複製が可能となる。
その理由は、再送応答変更機能17および宛先決定機能16を備えることによって、現用SIPサーバ30での登録情報の更新が成功したにもかかわらず、ユーザ・エージェント10へは登録情報の処理の失敗を伝達して、ユーザ・エージェント20での登録情報の処理を再度誘発し、ユーザ・エージェント20から再送されたREGISTERリクエストを予備SIPサーバ40へ転送してユーザ・エージェント20と予備SIPサーバ40間でのDigest認証を実行させるからである。
また、本実施の形態によれば、現用SIPサーバ30および予備SIPサーバ40の登録情報を、プロキシ・サーバ10で予備SIPサーバ40宛のメッセージを生成することなく、Digest認証を行いながら更新することができる。
その理由は、本実施の形態に係るプロキシ・サーバ10を含むシステムが、現用SIPサーバ30でのREGISTERリクエストの処理が完了した場合(SIP応答(200 OK)受信)には、ユーザ・エージェント20に対してinitial REGISTERリクエストの再送応答を送信し、当該再送応答に基づいてユーザ・エージェント20が送信したinitial REGISTERリクエストを受信して予備SIPサーバ40に転送するからである。
(第4の実施の形態)
次に、本発明の第4の実施の形態に係るプロキシ・サーバ10に関して、図表を参照して詳細に説明する。
(第4の実施の形態の構成)
図16は、本発明の第4の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図16に示すように、本発明の第4の実施の形態に係るプロキシ・サーバ10は、SIPプロキシ・サーバ機能11に加えて、SIPプロキシ・サーバ機能11が受信したメッセージの種類を解析し、かつ受信したメッセージがinitial REGISTERリクエストの場合にExpiresヘッダをさらに解析するメッセージ解析機能18と、initial REGISTERリクエストのExpiresヘッダの値がある閾値未満の場合にExpiresヘッダの値を変更する旨をユーザ・エージェント20に伝えるSIP応答を生成する有効期限変更依頼応答生成機能19と、宛先情報を参照してREGISTERリクエストの転送先を決定する宛先決定機能16とを備える。
なお、宛先情報は、本発明の第2ないし第3の実施の形態に係るプロキシ・サーバ10と同様に、例えば、ユーザ・エージェント20とREGISTERリクエストの送信先との組であり、宛先決定機能16に保持される。
(第4の実施の形態の動作)
次に、本発明の第4の実施の形態に係るプロキシ・サーバ10の動作について図表を参照して詳細に説明する。
図17は、本発明の第4の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
いま、SIPプロキシ・サーバ機能11が外部からメッセージを受信したとする(ステップS1301)。次に、メッセージ解析機能18が、SIPプロキシ・サーバ機能11によって受信したメッセージの種類を識別する(ステップS1302)。
ステップS1302の結果、受信したメッセージがinitial REGISTERリクエストの場合には、更に、メッセージ解析機能18がinitial REGISTERリクエストのExpiresヘッダを参照する(ステップS1303)。
ステップS1303の結果、Expiresヘッダの値がある閾値未満の場合には、有効期限変更依頼応答生成機能19が有効期限変更依頼応答を生成する(ステップS1304)。
ここで、この閾値としては、例えば、本発明の第2の実施の形態に係るプロキシ・サーバ10と同様に、1台の予備SIPサーバ40が存在する場合には標準的なExpiresヘッダ値(3600秒)の2倍、2台の予備SIPサーバ40が存在する場合には3倍など、予備SIPサーバ数に応じて決定しておく。
更に、ステップS1304の有効期限変更依頼応答生成機能19が生成するSIP応答としては、例えば、423(Interval Too Brief)が挙げられる。
このSIP応答は、REGISTERリクエストによりリフレッシュされる登録情報の有効期限時間が短すぎる場合にユーザ・エージェント20に送信されるものである。このSIP応答(423 Interval Too Brief)ではMin−Expiresヘッダに希望する有効期限を指定できるため、例えば、前述の閾値を使用する。
ステップS1303の結果、Expiresヘッダ値が閾値以上の場合、または、ステップS1302の結果、受信したメッセージが認証REGISTERリクエストの場合には、宛先決定機能16が宛先情報を参照してREGISTERリクエストの宛先を決定する(ステップS1305)。
例えば、この決定処理は下記のようにして実現できる。initialおよび認証REGISTERリクエストのFromヘッダに記載されているユーザ・エージェント20の識別子に基づいて宛先情報を検索する。この検索の結果、宛先情報に記載されている送信先をinitialおよび認証REGISTERリクエストの送信先とするのである。
ステップS1302の結果、受信したメッセージがSIP応答(200 OK)の場合には、宛先決定機能16が保持する宛先情報を更新する(ステップS1306)。
例えば、この更新処理は以下のようにして実現できる。宛先決定機能16が、受信したSIP応答(200 OK)のFromヘッダに記載されているユーザ・エージェント20の識別子に基づいて宛先情報を検索しておく。次に、宛先決定機能16は、受信したSIP応答(200 OK)の送信元を調査し、送信元が現用SIPサーバ30の場合には検索結果の送信先を「予備SIPサーバ40」と、送信元が予備SIPサーバ40の場合には検索結果の送信先を「現用SIPサーバ30」とする。
ステップS1302の結果、受信したメッセージがinitialないし認証REGISTERリクエストまたはSIP応答(200 OK)以外の場合、または、ステップS1304の結果、有効期限変更依頼応答機能19がユーザ・エージェント20に対して有効期限変更依頼応答を生成した場合、または、ステップS1305の結果、initialないし認証REGISTERリクエストの宛先が決定した場合、または、ステップS1306の結果、宛先情報の更新が完了した場合には、SIPプロキシ・サーバ機能11が、指定された宛先にメッセージを送信する(ステップS1307)。具体的には、initialないし認証REGISTERリクエストはステップS1306で決定されたSIPサーバに送信し、または、それ以外はユーザ・エージェント20に送信する。
次に、本発明の第4の実施の形態に係るプロキシ・サーバ10を含むシステム全体の動作について図表を参照して詳細に説明する。
まず、図18に、本発明の第4の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示す。
図18に示すように、ユーザ・エージェント20から送信されたREGISTERリクエスト(図18のa)を受信したプロキシ・サーバ10は、REGISTERリクエストのExpiresヘッダの値を調査し、ある閾値以下の場合には、Expiresヘッダ値を変更するようにユーザ・エージェント20に要請する有効期限変更依頼応答(図18のb)を転送する。
有効期限変更依頼応答を受信したユーザ・エージェント20は、SIPのプロトコル規約で規定されている処理に従って、Expiresヘッダ値を変更したREGISTERリクエストを送信する(図18のc)。
更に、この一連の流れは、本発明の第2の実施の形態に係るプロキシ・サーバ10と同様に、現用SIPサーバ30と予備SIPサーバ40で順番に実行される。つまり、現用SIPサーバ30および予備SIPサーバ40へは数回に一度しかREGISTERリクエストが各々転送されない。
次いで、図19に、システム全体の動作を示すシーケンス図を示す。図19に示すように、プロキシ・サーバ10は、受信したinitial REGISTERリクエストのExpiresヘッダを調査し、閾値以上の場合には、送信先のSIPサーバを決定した後initial REGISTERリクエストを該当SIPサーバに送信する(図19のシーケンス(1))。
一方で、initial REGISTERリクエストのExpiresヘッダが閾値未満の場合には、プロキシ・サーバ10は、Expiresヘッダ値の更新依頼を示すSIP応答(423 Interval too Brief)をユーザ・エージェント20に返答することで、Expiresヘッダ値を変更したinitial REGISTERリクエストを受信する(図19のシーケンス(2))。
更に、どちらの場合でも、認証REGISTERリクエストはinitial REGISTERリクエストの送信先と同一のSIPサーバに送信される。ユーザ・エージェント20からすれば、最初REGISTERリクエストの処理が失敗するが、SIPの規定に従った再送処理により登録情報の更新が完了したと認識される。
一方、SIPサーバにおいて登録情報の有効期限を延長するため、数回に一度しかREGISTERリクエストを受信しないにも係らず、登録情報の有効期限が切れないようになっている。
(第4の実施の形態の効果)
本実施の形態によれば、ユーザ・エージェント20の保持している、ユーザ・エージェント20を識別するユーザID(ユーザ・エージェント識別子)およびパスワードのみを用いて各SIPサーバの登録情報の複製が可能となる。
その理由は、宛先決定機能16を備えることによって、ユーザ・エージェント20と現用SIPサーバ30間で行われたDigest認証が、ユーザ・エージェント20と予備SIPサーバ40間においても行われるからである。
また、本実施の形態によれば、各SIPサーバは数回に一度しかREGISTERリクエストを受信しないにも係らず、登録情報の有効期限が切れない。
その理由は、SIPプロキシ・サーバ機能11が外部から受信したメッセージをメッセージ解析機能18が識別し、受信したメッセージがinitial REGISTERリクエストの場合には、更に、メッセージ解析機能18がinitial REGISTERリクエストのExpiresヘッダを参照し、Expiresヘッダの値がある閾値未満の場合には、有効期限変更依頼応答生成機能19が有効期限変更依頼応答を生成してユーザ・エージェント20からExpiresヘッダ値を変更したinitial REGISTERリクエストをプロキシ・サーバ10が受信することにより、SIPサーバにおいて登録情報の有効期限を延長できるからである。
また、本実施の形態によれば、プロキシ・サーバ10は、有効期限変更依頼応答生成機能19によって、Expiresヘッダの拡張処理をユーザ・エージェント20に行わせているため、プロキシ・サーバ10自身でExpiresヘッダの拡張機能を備える必要がない。
(第5の実施の形態)
次に、本発明の第5の実施の形態に係るプロキシ・サーバ10に関して、図表を参照して詳細に説明する。
(第5の実施の形態の構成)
本発明の第5の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図20は、本発明の第5の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図20に示すように、本発明の第5の実施の形態に係るプロキシ・サーバ10は、一般的なSIPプロキシ・サーバ機能11に加えて、SIPプロキシ・サーバ機能11が受信したメッセージの種類を識別するメッセージ判別機能12と、SIPのプロトコル規約で規定されている、ユーザ・エージェント20がSIP要求の送信先を変更する機能を動作させる宛先変更応答(宛先変更依頼応答)を生成する宛先変更応答生成機能61とから構成される。
この宛先変更応答としては、例えば、SIPのプロトコル規約で規定されているSIP応答305(use proxy)において、このSIP応答のcontactヘッダに予備SIPサーバ40のIPアドレスを挿入したものとなる。
(第5の実施の形態の動作)
次に、本発明の第5の実施の形態に係るプロキシ・サーバ10の動作を図表を参照して詳細に説明する。図21は、本発明の第5の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
いま、SIPプロキシ・サーバ機能11がメッセージを受信したとする(ステップS10601)。次に、メッセージ判別機能12が受信したメッセージの種類を調査する(ステップS10602)。
ステップS10602の結果、SIPプロキシ・サーバ機能11が受信したメッセージがSIP応答(200 OK)の場合には、更に、メッセージ判別機能12が該当SIP応答(200 OK)の送信元を調査する(ステップS10603)。
ステップS10603の結果、SIP応答(200 OK)の送信元が現用SIPサーバ30の場合には、宛先変更応答生成機能61がユーザ・エージェント20へ送信する宛先変更を示すSIP応答を生成する(ステップS10604)。この処理は、例えば、前述したように、SIPのプロトコル規約で規定されているSIP応答305(use proxy)において、このSIP応答のcontactヘッダに予備SIPサーバ40のIPアドレスを挿入したものとなる。
ステップS10602の結果、プロキシ・サーバ10が受信したメッセージがSIP応答(200 OK)以外の場合、または、ステップS10603の結果、SIP応答(200 OK)の送信元が予備SIPサーバ40であった場合、または、ステップS10604の結果、ユーザ・エージェント20へ転送する宛先変更応答が生成された場合には、SIPプロキシ・サーバ機能11が、ステップS10601で受信したメッセージをメッセージに記載された宛先に、または、ステップS10604で生成された宛先変更応答をユーザ・エージェント20に転送する(ステップS10605)。
次に、以上述べたような構成および動作となる、本発明の第5の実施の形態に係るプロキシ・サーバ10を含むシステム全体での動作を図表を参照して詳細に説明する。
まず、システム全体でのデータの流れを図22に示す。この図に示すように、ユーザ・エージェント20から送信されたREGISTERリクエスト(図22のa)の処理完了を示すSIP応答(200 OK)(図22のb)を受信したプロキシ・サーバ10は、ユーザ・エージェント20にREGISTERリクエストの宛先変更を促すSIP応答(宛先変更応答)(図22のc)を送信する。
宛先変更応答を受信したユーザ・エージェント20は、SIPのプロトコル規約で規定されている処理に従って、REGISTERリクエストの送信先を宛先変更応答に記載された宛先に変更し、REGISTERリクエストを再度転送する。プロキシ・サーバ10は、この再送されたREGISTERリクエストを予備SIPサーバ40に転送する(図22のd)。
更に、このデータの流れを動作シーケンスとしたものが図23である。この図に示すように、現用SIPサーバ30から送信されたSIP応答(200 OK)を受信したプロキシ・サーバ10は、ユーザ・エージェント20に宛先変更応答を送信することで、宛先を予備SIPサーバ40に変更したinitial REGISTERリクエストをユーザ・エージェント20に送信させている。このinitial REGISTERリクエストを受信したプロキシ・サーバ10は、initial REGISTERリクエストに記載されている宛先(予備SIPサーバ40)に送信するのみで、現用SIPサーバ30と予備SIPサーバ40間で登録情報の複製が可能となるのである。
(第5の実施の形態の効果)
本実施の形態によれば、プロキシ・サーバ10は、ユーザ・エージェント20からのinitial REGISTERリクエストに記載されている宛先(予備SIPサーバ40)に送信するのみで、現用SIPサーバ30と予備SIPサーバ40間で登録情報の複製が可能となるのである。
その理由は、現用SIPサーバ30から送信されたSIP応答(200 OK)を受信したプロキシ・サーバ10は、宛先変更応答生成機能61によって生成した宛先変更応答をユーザ・エージェント20に送信することで、宛先を予備SIPサーバ40に変更したinitial REGISTERリクエストをユーザ・エージェント20からプロキシ・サーバ10に対して送信させているからである。
(第6の実施の形態)
次に、本発明の第6の実施の形態に係るプロキシ・サーバ10について、図表を参照して詳細に説明する。
(第6の実施の形態の構成)
本発明の第6の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図24は、本発明の第6の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図24に示すように、本発明の第6の実施の形態に係るプロキシ・サーバ10は、一般的なSIPプロキシ・サーバ機能11に加えて、SIPプロキシ・サーバ機能11が受信したメッセージを識別するメッセージ判別機能12と、SIPのプロトコル規約で規定されている、ユーザ・エージェント20がSIP応答に応じてSIP要求の送信先を変更する機能を動作させる宛先変更応答(宛先変更依頼応答)を生成する宛先変更応答生成機能61と、SIPプロキシ・サーバ機能11が受信したメッセージに含まれるExpiresヘッダの値を変更(増加・減少)する有効期限更新機能15とから構成される。
ここで、宛先変更応答生成機能61が生成する宛先変更応答は、例えば、前述した、本発明の第5の実施の形態に係るプロキシ・サーバ10で生成される宛先変更応答と同様である。
更に、メッセージ判別機能12は、宛先変更応答を生成するか否かを判定する際に使用する、REGISTERリクエストの宛先を決定する際に参照する情報(宛先情報)を保存する。この宛先情報は、例えば、ユーザ・エージェント20とREGISTERリクエストの転送先との組として実現できる。
(第6の実施の形態の動作)
次に、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作を図表を参照して詳細に説明する。図25は、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
いま、SIPプロキシ・サーバ機能11が外部からメッセージを受信したとする(ステップS11001)。すると、メッセージ判別機能12がメッセージの種類を調査する(ステップS11002)。
ステップS11002の結果、SIPプロキシ・サーバ機能11が受信したメッセージがinitial REGISTERリクエストの場合には、更に、initial REGISTERリクエストの送信先(宛先)をメッセージ判別機能12が調査する(ステップS11003)。
この処理は、例えば、以下のようにして実現できる。まず、メッセージ判別機能12が、受信したinitial REGISTERリクエストを送信したユーザ・エージェント20を検索キーとして、宛先情報からREGISTERリクエストの転送先を抽出する。その後、ステップS1101で受信したinitial REGISTERリクエストの送信先が、抽出した転送先と同一であるかを比較するのである。
ステップS11003の結果、initial REGISTERリクエストの宛先が宛先情報と異なる場合には、宛先変更応答生成機能61が、宛先変更応答を生成する(ステップS11004)。
この処理は、前述したように、例えば、SIPのプロトコル規約で規定されているSIP応答305(use proxy)において、このSIP応答のcontactヘッダに予備SIPサーバ40のIPアドレスを挿入するという処理となる。
ステップS11002の結果、受信したメッセージが認証REGISTERリクエストである場合には、認証REGISTERリクエストのExpiresヘッダの値を変更する(ステップS11005)。
この処理は、例えば、1台の予備SIPサーバ40が存在する場合には2倍、2台の予備SIPサーバ40が存在する場合には3倍など、予備SIPサーバ数に応じて増加させる。
ステップS11002の結果、受信したメッセージがSIP応答(200 OK)である場合には、メッセージ判別機能12が保持する宛先情報を変更する(ステップS11006)。
この処理は、例えば、以下のようにして実現できる。まず、SIP応答(200 OK)の送信先となるユーザ・エージェント20のREGISTERリクエストの転送先を宛先情報から抽出する。その後、ステップS11001で受信したSIP応答(200 OK)が現用SIPサーバ30から送信された場合には、該当リクエスト転送先を予備SIPサーバ40とする。一方、SIP応答(200 OK)が、予備SIPサーバ40から送信された場合には、該当リクエスト転送先を現用SIPサーバ30とする。
次に、SIP応答(200 OK)のExpiresヘッダの値を変更する(ステップS11005)。これは、認証REGISTERリクエストでのExpiresヘッダ値の変更とは逆に、例えば、1台の予備SIPサーバ40が存在する場合には1/2倍、2台の予備SIPサーバ40が存在する場合には1/3倍など、予備SIPサーバ数に応じて減少させる。
ステップS11004の結果、ユーザ・エージェント20へ転送する宛先変更応答の生成が完了した場合、または、ステップS11003の結果、initial REGISTERリクエストの宛先が宛先情報の同一であった場合、または、ステップS11005の結果、認証REGISTERリクエストおよびSIP応答(200 OK)のExpiresヘッダ値の変更が完了した場合、または、ステップS11002の結果、受信したメッセージがinitial/認証REGISTERリクエストおよびSIP応答(200 OK)以外であった場合には、SIPプロキシ・サーバ機能11が、宛先変更応答はユーザ・エージェント20に、それ以外はメッセージに記載されている宛先に転送する(ステップS11007)。
次に、本発明の第6の実施の形態に係るプロキシ・サーバ10を含むシステム全体での動作を図表を参照して詳細に説明する。
まず、システム全体でのデータの流れを図26に示す。この図に示すように、ユーザ・エージェント20からinitial REGISTERリクエスト(図26のa)を受信したプロキシ・サーバ10はinitial REGISTERリクエストの宛先を調査し、initial REGISTERリクエストに記載された宛先の転送順番でない場合には、宛先変更応答(図26のb)をユーザ・エージェント20に転送する。その後、ユーザ・エージェント20により宛先が修正されたinitial REGISTERを、記載された宛先に転送し、当該宛先から受信したSIP応答をユーザ・エージェント20に転送する(図26のc)。この結果、initial REGISTERリクエストは、現用SIPサーバ30および予備SIPサーバ40に順番に転送されることになる。
更に、このデータの流れを動作シーケンスとしたものが図27である。この図に示しているように、initial REGISTERリクエストでの宛先調査と、認証REGISTERリクエストでのExpiresヘッダ値の変更により、各々のSIPサーバに格納された登録情報を無効とすることなく、現用SIPサーバ30および予備SIPサーバ40の登録情報を順番に更新していくのである。
(第6の実施の形態の効果)
本実施の形態によれば、各々のSIPサーバに格納された登録情報を無効とすることなく、現用SIPサーバ30および予備SIPサーバ40の登録情報の更新が可能となる。
その理由は、initial REGISTERリクエストでの宛先調査と、Expiresヘッダの値を変更(増加・減少)する有効期限更新機能15によって認証REGISTERリクエストでのExpiresヘッダ値を変更し、SIP要求の送信先を変更する機能を動作させる宛先変更応答を宛先変更応答生成機能61によって生成することにより、現用SIPサーバ30および予備SIPサーバ40の登録情報を順番に更新していくからである。
(第7の実施の形態)
次に、本発明の第7の実施の形態に係るプロキシ・サーバ10について、図表を参照して詳細に説明する。
(第7の実施の形態の構成)
本発明の第7の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図28は、本発明の第7の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図28に示すように、本発明の第7の実施の形態に係るプロキシ・サーバ10は、本発明の第1の実施の形態に係るプロキシ・サーバ10の構成に、予備SIPサーバ40への複製を実施するか否かを判断する複製判断機能62が追加された形態となっている。
この複製判断機能62の導入により、本発明の第1の実施の形態に係るプロキシ・サーバ10では、ユーザ・エージェント20から送信されたREGISTERリクエストを全て複製する形態であったが、本発明の第7の実施の形態に係るプロキシ・サーバ10では、予備SIPサーバ40に数回に一度REGISTERリクエストを送信する形態となる。
更に、リクエスト生成機能14では、本発明の第1の実施の形態に係るプロキシ・サーバ10でのリクエスト生成機能14が保持する機能が、予備SIPサーバ40へ転送するREGISTERリクエストの生成時にExpiresヘッダ値を増加する機能へと拡張されている。この結果、予備SIPサーバ40に対し、ユーザ・エージェント20からのREGISTERリクエストが数回に一度しか到着しない状況でも予備SIPサーバ40の登録情報が無効とならないのである。
(第7の実施の形態の動作)
次に、本発明の第7の実施の形態に係るプロキシ・サーバ10の動作について図表を参照して詳細に説明する。図29は、本発明の第7の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
このフローチャートは、本発明の第1の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートに、複製判断機能62による複製判断処理(ステップS11404およびステップS11406)が付加された形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS11401は第1の実施の形態の図5に示すステップS401と、ステップS11402はステップS402と、ステップS11403はステップS403と、ステップS11412はステップS404と、ステップS11405はステップS405と、ステップS11407はステップS406と、ステップS11408はステップS407と、ステップS11409はステップS408と、ステップS11410はステップS409と、ステップS11411はステップS410と同様の処理内容であるので、説明を省略する。
この複製判断機能62による複製判断処理(ステップS11404およびステップS11406)は、例えば、以下の処理で実現できる。ステップ11401で受信したメッセージ(REGISTERリクエストまたはSIP応答(200 OK))のCSeqヘッダ値を参照して、2回に1回複製する場合には奇数番号の時に複製し、偶数番号の時には複製しないと判断するものである(ステップS11404)。
ステップS11404の結果、複製すると判断した場合には、リクエスト生成機能14がinitial REGISTERリクエストを生成する(ステップ11405)。この処理は、前述したように、本発明の第1の実施の形態に係るプロキシ・サーバ10でのリクエスト生成機能14の処理に加えて、Expiresヘッダ値の増加処理が追加される。
ステップS11404の結果、複製しないと判断した場合には、ステップS11401で受信したメッセージをSIPプロキシ・サーバ機能11が、メッセージに記載された宛先に転送する。
また、ステップS11402の結果受信したメッセージがREGISTERリクエストの場合におけるステップS11406の処理も、ステップS11404と同様の処理で複製判断を行う。ステップ11406の結果、複製すると判断された場合には、受信したREGISTERリクエストを一時格納機能13が複製する(ステップS11407)。この一時格納機能13の動作は、本発明の第1の実施の形態に係るプロキシ・サーバ10における一時格納機能13の動作と同様である。
ステップS11406の結果、複製しないと判断した場合には、ステップS11401の結果受信したメッセージをSIPプロキシ・サーバ機能11が、メッセージに記載された宛先に転送する。
次に、本発明の第7の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図30は、本発明の第7の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示している。
この図に示すように、データの流れとしては、本発明の第1の実施の形態に係るプロキシ・サーバ10と基本的に同様である。ユーザ・エージェント20からのREGISTERリクエストが予備SIPサーバ40に数回に一度転送されていることが、本実施の形態の特徴となっている。
更に、このデータの流れを動作シーケンスとして示したものが図31である。この図に示しているように、ユーザ・エージェント20から現用SIPサーバ30に宛てられたREGISTERリクエストが数回に一度複製対象として一時格納され、予備SIPサーバ40へ転送するREGISTERリクエストとしてExpiresヘッダ値が更新され、転送されている。
(第7の実施の形態の効果)
本実施の形態によれば、第1の実施の形態と比較し、予備SIPサーバ40の登録情報の更新負担の減少およびプロキシ・サーバ10と予備SIPサーバ40間のトラフィックの減少を図ることができる。
その理由は、複製判断機能62の導入により、プロキシ・サーバ10が、予備SIPサーバ40に数回に一度REGISTERリクエストを送信するからである。
(第8の実施の形態)
次に、本発明の第8の実施の形態に係るプロキシ・サーバ10について、図表を参照して詳細に説明する。
(第8の実施の形態の構成)
本発明の第8の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図32は、本発明の第8の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図32に示すように、本発明の第8の実施の形態に係るプロキシ・サーバ10は、本発明の第3の実施の形態に係るプロキシ・サーバ10の構成に、複製判断機能62および有効期限更新機能15を追加した形態となっている。
この複製判断機能62は、前述した、本発明の第7の実施の形態に係るプロキシ・サーバ10における複製判断機能62と同様である。更に、有効期限更新機能15は、本発明の第2の実施の形態に係るプロキシ・サーバ10における有効期限更新機能15と同様である。
これらの機能を追加することで、本発明の第3の実施の形態におけるプロキシ・サーバ10では、ユーザ・エージェント20から送信されたREGISTERリクエストを毎回必ずユーザ・エージェント20に再送させ、予備SIPサーバ40に転送していた形態が、ユーザ・エージェント20から送信されたREGISTERリクエストのうちの数回に一度のREGISTERリクエストが予備SIPサーバ40に転送される形態となる。
(第8の実施の形態の動作)
次に、本発明の第8の実施の形態に係るプロキシ・サーバ10の動作を図表を参照して詳細に説明する。
図33は、本発明の第8の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。この図に示すように、本発明の第8の実施の形態に係るプロキシ・サーバ10の動作は、本発明の第3の実施の形態に係るプロキシ・サーバ10の動作に、複製判断機能62による複製判断処理(ステップS11803およびステップS11807)と、有効期限更新機能15によるREGISTERリクエストおよびSIP応答(200 OK)のExpiresヘッダ値の変更処理(ステップS11805およびステップS11809)が追加されたものとなっている。なお、本実施の形態の複製判断処理及びExpiresヘッダ値の変更処理以外のステップである、ステップS11801は第3の実施の形態の図13に示すステップS1001と、ステップS11802はステップS1002と、ステップS11804はステップS1003と、ステップS11806はステップS1004と、ステップS11808はステップS1005と、ステップS11810はステップS1006と、ステップS11811はステップS1007と同様の処理内容であるので、説明を省略する。
この複製判断処理(ステップS11803およびステップS11807)は、本発明の第7の実施の形態に係るプロキシ・サーバ10における動作での複製判断処理(ステップS11404およびステップS11406)と同様である。更に、有効期限変更処理(ステップS11805およびステップS11809)は、本発明の第2の実施の形態に係るプロキシ・サーバ10における動作での有効期限増加処理(ステップS703)および有効期限減少処理(ステップS706)と同様である。
すなわち、ステップS11802の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類がREGISTERリクエストの場合には、複製判断機能62が、予備SIPサーバ40への複製を実施するか否かを判断する(ステップS11803)。
ステップS11803の結果、複製すると判断した場合には、宛先決定機能16が宛先を決定し(ステップS11804)、有効期限更新機能15がExpiresヘッダ値の変更処理を行う(ステップS11805)。
また、ステップS11802の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類がSIP応答(200 OK)の場合には、メッセージ判別機能12が、メッセージの送信元を判別し(ステップS11806)、ステップS11806の結果、送信元が現用SIPサーバ30の場合には、複製判断機能62が、予備SIPサーバ40への複製を実施するか否かを判断する(ステップS11807)。
ステップS11807の結果、複製すると判断した場合には、再送応答生成機能17が、ユーザ・エージェント20にinitial REGISTERリクエストを再送させるための再送応答を生成し(ステップS11808)、有効期限更新機能15がExpiresヘッダ値の変更処理を行い(ステップS11809)、宛先決定機能16が、宛先情報を更新する(ステップS11810)。
ステップS11802の結果、SIPプロキシ・サーバ機能11が受信したメッセージがREGISTERリクエストおよびSIP応答(200 OK)でない場合、ステップS11803またはステップS11807の結果、複製しないと判断した場合、ステップS11805の結果、Expiresヘッダ値の変更処理が行われた場合、ステップS11810の結果、宛先情報が更新された場合には、SIPプロキシ・サーバ機能11が、指定された宛先にメッセージを送信する(ステップS11811)。
次に、本発明の第8の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図34は、本発明の第8の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れを示す図である。
この図に示すように、本発明の第8の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れは、本発明の第3の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れと基本的に同様である(図14参照)。しかし、本実施の形態は、ユーザ・エージェント20からのREGISTERリクエストに対し、プロキシ・サーバ10から数回に一度ユーザ・エージェント20へ再送応答が返送され、その応答に対するユーザ・エージェント20からのinitial REGISTERリクエストが予備SIPサーバ40へ転送されることが特徴となっている。
更に、このデータの流れを動作シーケンスとして示したものが図35である。この図に示すように、ユーザ・エージェント20から送信されるREGISTERリクエストに対して数回に一度再送応答が返送され、この応答に対してユーザ・エージェント20が送信したinitial REGISTERリクエストのExpiresヘッダが、プロキシ・サーバ10で変更された後、予備SIPサーバ40に転送されている。
(第8の実施の形態の効果)
本実施の形態によれば、第3の実施の形態と比較し、予備SIPサーバ40の登録情報の更新負担の減少、プロキシ・サーバ10とユーザ・エージェント20間のトラフィックの減少およびプロキシ・サーバ10と予備SIPサーバ40間のトラフィックの減少を図ることができる。
その理由は、有効期限更新機能15によって認証REGISTERリクエストでのExpiresヘッダ値を変更し、再送応答生成機能17および複製判断機能62によって、ユーザ・エージェント20からのREGISTERリクエストに対し、プロキシ・サーバ10から数回に一度ユーザ・エージェント20に対して再送応答を返送し、その応答に対するユーザ・エージェント20からのinitial REGISTERリクエストを予備SIPサーバ40に対して転送するからである。
(第9の実施の形態)
次に、本発明の第9の実施の形態に係るプロキシ・サーバ10について図表を参照して詳細に説明する。
(第9の実施の形態の構成)
図36は、本発明の第9の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。この図に示すように、本発明の第9の実施の形態に係るプロキシ・サーバ10は、本発明の第4の実施の形態に係るプロキシ・サーバ10の構成における宛先決定機能16の代わりに、SIPのプロトコル規約で規定されている、ユーザ・エージェント20がSIP要求の送信先を変更する機能を動作させる宛先変更応答(宛先変更依頼応答)を生成する宛先変更応答生成機能61を追加した構成となっている。
この変更に伴い、メッセージ解析機能18には、本発明の第6の実施の形態に係るプロキシ・サーバ10における、メッセージ判別機能12と同様、宛先変更応答を生成するか否かを判定する際に使用する宛先情報を保存する。なお、宛先情報は、本発明の第6の実施の形態に係るプロキシ・サーバ10と同様のものである。
(第9の実施の形態の動作)
次に、本発明の第9の実施の形態に係るプロキシ・サーバ10の動作について図表を参照して詳細に説明する。図37は、本発明の第9の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。
いま、SIPプロキシ・サーバ機能11が外部からメッセージを受信したとする(ステップS12201)。すると、メッセージ解析機能18がメッセージの種類を調査する(ステップS12202)。
ステップS12202の結果、SIPプロキシ・サーバ機能11が受信したメッセージがinitial REGISTERリクエストである場合には、更に、メッセージ解析機能18がExpiresヘッダに格納された値を調査する(ステップS12203)。
ステップS12203の結果、受信したinitial REGISTERリクエストのExpiresヘッダ値がある閾値未満であった場合には、有効期限変更依頼応答生成機能19が、有効期限変更依頼応答を生成する(ステップS12206)。
ここで、ステップS12203の処理は、本発明の第4の実施の形態に係るプロキシ・サーバ10の動作におけるステップS1303の処理と、また、ステップS12206の有効期限変更依頼応答の生成処理は、本発明の第4の実施の形態に係るプロキシ・サーバ10の動作におけるステップS1304と同様の処理である。
ステップS12203の結果、受信したinitial REGISTERリクエストのExpiresヘッダ値がある閾値以上である場合には、更に、メッセージ解析機能18が、受信したinitial REGISTERリクエストの送信先(宛先)を調査する(ステップS12204)。この処理は、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作におけるステップS1103と同様である。
ステップS12204の結果、initial REGISTERリクエストの送信先が宛先情報と異なる場合には、宛先変更応答生成機能61が、宛先変更応答を生成する(ステップS12205)。この処理は、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作におけるステップS11004と同様である。
ステップS12202の結果、SIPプロキシ・サーバ機能11が受信したメッセージがSIP応答(200 OK)の場合には、メッセージ解析機能18が宛先情報を更新する(ステップS12207)。この処理は、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作におけるステップS11006と同様である。
ステップS12204の結果、initial REGISTERリクエストの送信先が宛先情報と同一の場合、または、ステップS12207の結果、メッセージ解析機能18が宛先情報の変更が完了した場合、または、ステップS12202の結果、SIPプロキシ・サーバ機能11が受信したメッセージがinitial REGISTERリクエストおよびSIP応答(200 OK)以外である場合には、ステップS12201で受信したメッセージをメッセージに記載された宛先に、また、ステップS12206の結果、ユーザ・エージェント20に送信する有効期限変更依頼応答が生成完了した場合、または、ステップS12205の結果、ユーザ・エージェント20に送信する宛先変更応答の生成が完了した場合には、ステップS12205およびステップS12206で生成したSIP応答をユーザ・エージェント20へ、SIPプロキシ・サーバ機能11が送信する(ステップS12208)。
次に、本発明の第9の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図38は、本発明の第9の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れを示す図である。
この図に示すように、ユーザ・エージェント20からのinitial REGISTERリクエスト(図38のa)を受信したプロキシ・サーバ10は、initial REGISTERリクエストのExpiresヘッダ値を調査し、ある閾値未満の場合には有効期限変更依頼応答(図38のb)を返送する。更に、この応答に対してユーザ・エージェント20から返送された、Expiresヘッダ値が修正されたinitial REGISTERリクエスト(図38のc)の宛先を調査し、initial REGISTERリクエストに記載された宛先の転送順番でない場合には、宛先変更応答(図38のd)をユーザ・エージェント20に転送する。以上により、Expiresヘッダと宛先が適切に変更されたinitial REGISTERリクエストを現用/予備SIPサーバへ順番に転送することになる(図38のe)。更に、このデータの流れは現用SIPサーバ30と予備SIPサーバ40で順番に実行される。
更に、このデータの流れを動作シーケンスとして示したものが図39である。この図に示すように、プロキシ・サーバ10は、SIPのプロトコル規約で規定されているSIP応答(宛先変更依頼応答と有効期限変更依頼応答)に対する処理をユーザ・エージェント20で動作させて、REGISTERリクエストのExpiresヘッダ値および宛先をユーザ・エージェント20に変更させている。この結果、現用SIPサーバ30と予備SIPサーバ40へ順番にREGISTERリクエストを転送する形態でも、各SIPサーバが保持する登録情報を無効としないで、両SIPサーバ間で登録情報を複製できるのである。
(第9の実施の形態の効果)
本実施の形態によれば、プロキシ・サーバ10は、現用SIPサーバ30と予備SIPサーバ40へ順番にREGISTERリクエストを転送する形態でも、各SIPサーバが保持する登録情報を無効としないで、両SIPサーバ間で登録情報を複製できる。
その理由は、プロキシ・サーバ10が、有効期限変更依頼応答生成機能19および宛先変更応答生成機能61を備えることによって、SIPのプロトコル規約で規定されているSIP応答(宛先変更依頼応答と有効期限変更依頼応答)に対する処理をユーザ・エージェント20で動作させて、REGISTERリクエストのExpiresヘッダ値および宛先をユーザ・エージェント20に変更させているからである。
(第10の実施の形態)
次に、本発明の第10の実施の形態に係るプロキシ・サーバ10について図表を参照して詳細に説明する。
(第10の実施の形態の構成)
図40は、本発明の第10の実施の形態に係るプロキシ・サーバ10における構成を示すブロック図である。
この図に示すように、本発明の第10の実施の形態に係るプロキシ・サーバ10は、本発明の第9の実施の形態に係るプロキシ・サーバ10における構成に、複製判断機能62を追加した形態となっている。なお、この複製判断機能62は、本発明の第7の実施の形態に係るプロキシ・サーバ10における、複製判断機能62と同様の機能を有する。
(第10の実施の形態の動作)
次に、本発明の第10の実施の形態に係るプロキシ・サーバ10における動作を図表を参照して詳細に説明する。
図41は、本発明の第10の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。図41に示すように、本発明の第10の実施の形態に係るプロキシ・サーバ10の動作は、本発明の第9の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートに、複製判断機能62の複製判断動作(ステップS12605)が追加された形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS12601は第9の実施の形態の図37に示すステップS12201と、ステップS12602はステップS12202と、ステップS12603はステップS12203と、ステップS12604はステップS12204と、ステップS12606はステップS12205と、ステップS12607はステップS12206と、ステップS12608はステップS12207と、ステップS12609はステップS12208と同様の処理内容であるので、説明を省略する。
この複製判断動作処理(ステップS12605)は、本発明の第7の実施の形態に係るプロキシ・サーバ10の動作におけるステップS11404と同様に、例えば、以下のように実現できる。すなわち、ステップS12601で受信したメッセージ(REGISTERリクエスト)のCSeqヘッダ値を参照して、2回に1度複製する場合、奇数番号で複製と判断し、偶数番号で複製しないと判断するのである。
ステップS12605の結果、複製する場合には、宛先変更応答生成機能61が、宛先変更応答を生成する(ステップS12606)。この処理は、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作におけるステップS11004と同様である。
次に、本発明の第10の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図42は、本発明の第10の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示している。
この図に示すように、データの流れは、本発明の第9の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れと基本的に同様である。しかし、本実施の形態は、ユーザ・エージェント20から転送されるinitial REGISTERリクエストの数回に一度が予備SIPサーバ40へ転送される点が、本発明の第9の実施の形態に係るプロキシ・サーバ10と異なる。
更に、このデータの流れを動作シーケンスとして示したものが図43である。この図に示すように、数回に一度予備SIPサーバ40の登録情報が更新される場合でも、登録情報が無効とならないように、Expiresヘッダ値を変更するようユーザ・エージェント20に依頼し、更に、予備SIPサーバ40へREGISTERリクエストを転送するために、REGISTERリクエストの宛先を変更するようユーザ・エージェント20に数回に一度依頼している。この結果、REGISTERリクエストが予備SIPサーバ40へ数回に一度しか転送されないにも係らず、登録情報を無効としないで現用/予備SIPサーバ間で登録情報の複製が可能となる。
(第10の実施の形態の効果)
本実施の形態によれば、プロキシ・サーバ10は、第9の実施の形態と比較し、予備SIPサーバ40の登録情報の更新負担の減少、プロキシ・サーバ10とユーザ・エージェント20間のトラフィックの減少およびプロキシ・サーバ10と予備SIPサーバ40間のトラフィックの減少を図ることができる。
その理由は、プロキシ・サーバ10が、宛先変更応答生成機能61および複製判断機能62を備えることによって、ユーザ・エージェント20からのREGISTERリクエストに対し、予備SIPサーバ40へREGISTERリクエストを転送するために、REGISTERリクエストの宛先を変更するようユーザ・エージェント20に数回に一度依頼しているからである。
(第11の実施の形態)
次に、本発明の第11の実施の形態に係るプロキシ・サーバ10について、図表を参照して詳細に説明する。
(第11の実施の形態の構成)
本発明の第11の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図44は、本発明の第11の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図44に示すように、本発明の第11の実施の形態に係るプロキシ・サーバ10は、本発明の第6の実施の形態に係るプロキシ・サーバ10の構成に、複製判断機能62を追加した形態となっている。この複製判断機能62は、前述した、本発明の第7の実施の形態に係るプロキシ・サーバ10における複製判断機能62と同様の機能を有する。
(第11の実施の形態の動作)
次に、本発明の第11の実施の形態に係るプロキシ・サーバ10の動作を図表を参照して詳細に説明する。
図45は、本発明の第11の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。図45に示すように、本発明の第11の実施の形態に係るプロキシ・サーバ10の動作は、本発明の第6の実施の形態に係るプロキシ・サーバ10の動作に、複製判断機能62による複製判断処理(ステップS13004とステップS13006)を追加した形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS13001は第6の実施の形態の図25に示すステップS11001と、ステップS13002はステップS11002と、ステップS13003はステップS11003と、ステップS13005はステップS11004と、ステップS13007はステップS11005と、ステップS13008はステップS11006と、ステップS13009はステップS11007と同様の処理内容であるので、説明を省略する。
この複製判断処理(ステップS13004とステップS13006)は、本発明の第7の実施の形態に係るプロキシ・サーバ10の動作における複製判断処理(ステップS11404およびステップS11406)と同様である。
すなわち、ステップS13002の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類がinitial REGISTERリクエストの場合であって、当該initial REGISTERリクエストの宛先が宛先情報と異なる場合には、複製判断機能62が、予備SIPサーバ40への複製を実施するか否かを判断する(ステップS13004)。
ステップS13004の結果、複製を実施する場合には、宛先変更応答生成機能61が、宛先変更応答を生成する(ステップS13005)。
また、ステップS13002の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類が認証REGISTERリクエストの場合には、複製判断機能62が、予備SIPサーバ40への複製を実施するか否かを判断する(ステップS13006)。
ステップS13006の結果、複製を実施する場合には、有効期限更新機能15が、認証REGISTERリクエストのExpiresヘッダの値を変更する(ステップS13007)。
ステップS13002の結果、SIPプロキシ・サーバ機能11が受信したメッセージがinitial REGISTERリクエストおよび認証REGISTERリクエストでない場合、ステップS13004またはステップS13006の結果、複製しないと判断した場合、ステップS13005の結果、宛先変更応答が生成された場合、ステップS13007の結果、Expiresヘッダ値の変更処理が行われた場合には、SIPプロキシ・サーバ機能11が、宛先変更応答はユーザ・エージェント20に、それ以外は指定された宛先にメッセージを送信する(ステップS13008)。
次に、本発明の第11の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図46は、本発明の第11の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示している。
この図に示すように、データの流れは、本発明の第6の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れと基本的に同様である。しかし、本実施の形態は、ユーザ・エージェント20から転送されるinitial REGISTERリクエストが予備SIPサーバ40へ数回に一度転送される点が、本発明の第6の実施の形態に係るプロキシ・サーバ10と異なる。
更に、このデータの流れを動作シーケンスとして示したものが図47である。この図に示すように、予備SIPサーバ40の登録情報が数回に一度しか更新されない場合でも、登録情報が無効とならないように、Expiresヘッダ値を変更し、更に、予備SIPサーバ40へREGISTERリクエストを転送するために、REGISTERリクエストの宛先を変更するようユーザ・エージェント20に数回に一度依頼している。この結果、REGISTERリクエストを予備SIPサーバ40に数回に一度しか転送しないにも係らず、登録情報を無効としないで現用/予備SIPサーバ間で登録情報の複製が可能となる。
(第11の実施の形態の効果)
本実施の形態によれば、第6の実施の形態と比較し、予備SIPサーバ40の登録情報の更新負担の減少、プロキシ・サーバ10とユーザ・エージェント20間のトラフィックの減少およびプロキシ・サーバ10と予備SIPサーバ40間のトラフィックの減少を図ることができる。
その理由は、有効期限更新機能15によって認証REGISTERリクエストでのExpiresヘッダ値を変更し、複製判断機能62によって、ユーザ・エージェント20からのREGISTERリクエストに対し、プロキシ・サーバ10から数回に一度ユーザ・エージェント20に対して宛先変更応答を返送し、その応答に対するユーザ・エージェント20からのinitial REGISTERリクエストを予備SIPサーバ40に対して転送するからである。
(第12の実施の形態)
次に、本発明の第12の実施の形態に係るプロキシ・サーバ10について図表を参照して詳細に説明する。
(第12の実施の形態の構成)
本発明の第12の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図48は、本発明の第12の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図48に示すように、本発明の第12の実施の形態に係るプロキシ・サーバ10は、本発明の第4の実施の形態に係るプロキシ・サーバ10の構成に、複製判断機能62を追加した形態となっている。なお、この複製判断機能62は、前述した、本発明の第7の実施の形態に係るプロキシ・サーバ10における複製判断機能62と同様の機能を有する。
(第12の実施の形態の動作)
次に、本発明の第12の実施の形態に係るプロキシ・サーバ10の動作を図表を参照して詳細に説明する。
図49は、本発明の第12の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。図49に示すように、本発明の第12の実施の形態に係るプロキシ・サーバ10の動作は、本発明の第4の実施の形態に係るプロキシ・サーバ10の動作に、複製判断機能62の複製判断処理(ステップS13405)を追加した形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS13401は第4の実施の形態の図17に示すステップS1301と、ステップS13402はステップS1302と、ステップS13403はステップS1303と、ステップS13404はステップS1304と、ステップS13406はステップS1305と、ステップS13407はステップS1306と、ステップS13408はステップS1307と同様の処理内容であるので、説明を省略する。
この複製判断処理(ステップS13405)は、本発明の第7の実施の形態に係るプロキシ・サーバ10の動作での複製判断処理(ステップS11404およびステップS11406)と同様である。
すなわち、ステップS13403の結果、Expiresヘッダ値が閾値以上の場合、または、ステップS13402の結果、SIPプロキシ・サーバ機能11が受信したメッセージの種類が認証REGISTERリクエストの場合には、複製判断機能62が、予備SIPサーバ40への複製を実施するか否かを判断する(ステップS13405)。
ステップS13405の結果、複製を実施する場合には、宛先決定機能16が宛先情報を参照してREGISTERリクエストの宛先を決定する(ステップS13406)。
次に、本発明の第12の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図50は、本発明の第12の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示している。
この図に示すように、データの流れは、本発明の第4の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れと基本的に同様である。しかし、本実施の形態は、ユーザ・エージェント20から転送されるinitial REGISTERリクエストが予備SIPサーバ40へ数回に一度転送される点が、本発明の第4の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れと異なる。
更に、このデータの流れを動作シーケンスとして示したものが図51である。この図に示すように、数回に一度しか予備SIPサーバ40の登録情報が更新されない場合でも、登録情報が無効とならないように、Expiresヘッダ値の変更をユーザ・エージェント20に依頼している。更に、予備SIPサーバ40へREGISTERリクエストを転送するために、REGISTERリクエストの宛先をプロキシ・サーバ10が数回に一度変更している。この結果、REGISTERリクエストを予備SIPサーバ40に数回に一度しか転送しないにも係らず、登録情報を無効としないで現用/予備SIPサーバ間で登録情報の複製が可能となる。
(第12の実施の形態の効果)
本実施の形態によれば、第4の実施の形態と比較し、予備SIPサーバ40の登録情報の更新負担の減少、プロキシ・サーバ10とユーザ・エージェント20間のトラフィックの減少およびプロキシ・サーバ10と予備SIPサーバ40間のトラフィックの減少を図ることができる。
その理由は、プロキシ・サーバ10が、宛先決定機能16および複製判断機能62によって、ユーザ・エージェント20からのREGISTERリクエストの宛先を数回に一度変更し、受信したREGISTERリクエストの複製を予備SIPサーバ40に転送するからである。
(第13の実施の形態)
次に、本発明の第13の実施の形態に係るプロキシ・サーバ10について図表を参照して詳細に説明する。
(第13の実施の形態の構成)
本発明の第13の実施の形態に係るプロキシ・サーバ10の構成を図表を参照して詳細に説明する。図52は、本発明の第13の実施の形態に係るプロキシ・サーバ10の構成を示すブロック図である。
図52に示すように、本発明の第13の実施の形態に係るプロキシ・サーバ10は、本発明の第2の実施の形態に係るプロキシ・サーバ10の構成に、複製判断機能62を追加した形態となっている。なお、この複製判断機能62は、前述した、本発明の第7の実施の形態に係るプロキシ・サーバ10における複製判断機能62と同様の機能を有する。
(第13の実施の形態の動作)
次に、本発明の第13の実施の形態に係るプロキシ・サーバ10の動作を図表を参照して詳細に説明する。
図53は、本発明の第13の実施の形態に係るプロキシ・サーバ10の動作を示すフローチャートである。図53に示すように、本発明の第13の実施の形態に係るプロキシ・サーバ10の動作は、本発明の第2の実施の形態に係るプロキシ・サーバ10の動作に、複製判断機能62の複製判断処理(ステップS13804)を追加した形態となっている。なお、本実施の形態の複製判断処理以外のステップである、ステップS13801は第2の実施の形態の図9に示すステップS701と、ステップS13802はステップS702と、ステップS13803はステップS703と、ステップS13805はステップS704と、ステップS13806はステップS705と、ステップS13807はステップS706と、ステップS13808はステップS707と同様の処理内容であるので、説明を省略する。
この複製判断処理(ステップS13804)は、本発明の第7の実施の形態に係るプロキシ・サーバ10の動作での複製判断処理(ステップS11404およびステップS11406)と同様である。
すなわち、このステップS13804の追加により、ステップS13806が以下のように変更となる。ステップS13802の結果受信したメッセージがREGISTERリクエストの場合においてExpiresヘッダ値の変更処理(ステップS13803)後のステップS13804の結果、複製しないと判断された場合には、ステップS13805の処理が実行されないため、受信したメッセージに記載された宛先(現用SIPサーバ30)を宛先情報に反映する。一方、ステップS13804の結果、複製すると判断された場合には、ステップS13805の処理が実行されるため、ステップS13805の結果決定された宛先を宛先情報に反映する。
次に、本発明の第13の実施の形態に係るプロキシ・サーバ10を含むシステム全体のデータの流れおよび動作について図表を参照して詳細に説明する。
図54は、本発明の第13の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れを示している。
この図に示すように、データの流れは、本発明の第2の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れと基本的に同様である。ユーザ・エージェント20から転送されるinitial REGISTERリクエストが予備SIPサーバ40へ数回に一度転送される点が、本発明の第2の実施の形態に係るプロキシ・サーバ10を含むシステム全体でのデータの流れと異なる。
更に、このデータの流れを動作シーケンスとして示したものが図55である。この図に示すように、予備SIPサーバ40の登録情報が数回に一度しか更新されない場合でも、登録情報が無効とならないように、Expiresヘッダ値をプロキシ・サーバ10が変更している。
更に、予備SIPサーバへREGISTERリクエストを転送するために、REGISTERリクエストの宛先もプロキシ・サーバ10が数回に一度変更している。この結果、REGISTERリクエストを予備SIPサーバ40に数回に一度しか転送しないにも係らず、登録情報を無効としないで現用/予備SIPサーバ間で登録情報の複製が可能となる。
(第13の実施の形態の効果)
本実施の形態によれば、プロキシ・サーバ10は、第2の実施の形態と比較し、予備SIPサーバ40の登録情報の更新負担の減少、プロキシ・サーバ10と予備SIPサーバ40間のトラフィックの減少を図ることができる。
その理由は、プロキシ・サーバ10が、宛先決定機能16および複製判断機能62を備えることによって、ユーザ・エージェント20から受信したREGISTERリクエストを数回に一度複製して宛先を変更し、予備SIPサーバ40へ転送するからである。
以上好ましい実施の形態をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。
例えば、上記実施の形態では、SIP(session initiation protocol)を用いて外部の端末の登録情報をサーバ間で複製する形態について説明しているが、使用するプロトコルはSIPに限定されず、例えば、WEBサーバ及びクライアントを備えるWEBシステムにおいて、HTTP(HyperText Transfer Protocol)を用いてダイジェスト認証によってクライアントの情報を複数のサーバ間で複製してもよい。
第1の課題を解決するために、本発明のプロキシ・サーバに、前述したSIPプロキシ・サーバが保持する機能に加え、一時的に記録したユーザ端末からのREGISTERリクエストの内容に基づいてREGISTERリクエストを生成する機能を保持させる。具体的には、本発明のプロキシ・サーバが、ユーザ・エージェントとSIPサーバの中間地点で予備SIPサーバ向けのREGISTERリクエストを生成し、予備SIPサーバに送信することで、登録情報の複製を実現する。
第2の課題を解決するために、本発明のプロキシ・サーバのユーザ識別子とパスワードをプロキシ・サーバに保持させ、プロキシ・サーバと予備SIPサーバ間でDigest認証を行う形態とする。これにより、予備SIPサーバへのアクセス者の正当性を保証する。
第3の課題を解決するために、本発明のプロキシ・サーバは、現用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サーバへ複製することを可能とする。
本発明によれば、以下に説明する効果を達成することができる。
第1の効果は、登録情報の複製を実現できることである。これは、プロキシ・サーバが、プロキシ・サーバが本来有する機能に加え、予備SIPサーバに送信するREGISTERリクエスト(メッセージ)の生成機能を保持するためである。
第2の効果は、登録情報の複製に際し、予備SIPサーバへのアクセス者の正当性を予備SIPサーバに示すことが可能なことである。これは、プロキシ・サーバのユーザ識別子とパスワードをプロキシ・サーバに保持させ、プロキシ・サーバと予備SIPサーバ間でDigest認証を行うためである。
この出願は、2006年8月18日に出願された日本出願特願2006−223363を基礎とする優先権を主張し、その開示の全てをここに取り込む。
Claims (39)
- 外部のユーザ端末と外部の現用通信制御装置と外部の予備通信制御装置との間でメッセージを仲介するプロキシ・サーバ機能と、
前記プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ判別機能と、
メッセージ判別機能により、前記メッセージが前記現用通信制御装置内に保持される前記ユーザ端末に関する情報の処理を要求するメッセージであると判断した場合に一時的に当該メッセージの内容を記録する一時格納機能と、
前記メッセージが前記現用通信制御装置に受け入れられた場合に前記予備通信制御装置に認証のために前記メッセージと同内容のメッセージを複製するリクエスト生成機能とを備えることを特徴とするプロキシ・サーバ。 - ユーザ端末と現用SIPサーバ及び予備SIPサーバとの間で送受信されるSIPメッセージを仲介するSIPプロキシ・サーバ機能と、
前記SIPプロキシ・サーバ機能が受信したSIPメッセージの種類と送信元を判別するメッセージ判別機能と、
前記SIPプロキシ・サーバ機能が受信した前記ユーザ端末のREGISTERリクエストの複製を一時的に格納する一時格納機能と、
前記現用SIPサーバでの処理が正常に完了したREGISTERリクエストに対応する前記REGISTERリクエストの複製に基づいて、前記予備SIPサーバによる認証のためのREGISTERリクエストを生成するリクエスト生成機能とを備えることを特徴とするプロキシ・サーバ。 - 前記リクエスト生成機能は、
前記ユーザ端末の登録情報の複製先となる予備SIPサーバとのDigest認証で使用するプロキシ・サーバ自身のユーザ識別子とパスワードを使用し、前記予備SIPサーバに送信するREGISTERリクエストを生成することを特徴とする請求項2に記載のプロキシ・サーバ。 - プロキシ・サーバ自身を介して前記ユーザ端末から前記現用SIPサーバに送信されるREGISTERリクエストの複製を生成し、前記現用SIPサーバに送信された前記REGISTERリクエストの正常処理完了を確認した後、当該複製したREGISTERリクエスト及び予め保持するプロキシ・サーバ自身を識別するユーザ識別子とパスワードとに基づいて生成した新たなREGISTERリクエストを予備SIPサーバに送信する機能を備えることを特徴とする請求項2に記載のプロキシ・サーバ。
- 受信したメッセージがREGISTERリクエストの場合に、当該REGISTERリクエストの複製を生成する複製手段と、
受信したメッセージがREGISTERリクエスト以外の場合に、当該メッセージの送信元を判別する送信元判別手段と、
受信したメッセージが認証可を示すSIP応答でありかつ送信元が現用SIPサーバの場合に、前記複製のREGISTERリクエスト及び前記プロキシ・サーバ自身を識別するユーザ識別子とパスワードに基づいて第1の認証REGISTERリクエストを生成する第1のリクエスト生成手段と、
受信したメッセージが未許可を示しかつ送信元が予備SIPサーバの場合に、前記プロキシ・サーバ自身を識別するユーザ識別子とパスワードに基づいて前記受信したメッセージに応答する第2の認証REGISTERリクエストを生成する第2のREGISTERリクエスト生成手段と、
受信したメッセージが未許可を示しかつ送信元が現用SIPサーバの場合に、受信したメッセージを前記ユーザ端末に送信する送信手段とを備えることを特徴とする請求項2から請求項4の何れか1項に記載のプロキシ・サーバ。 - 外部とメッセージを送受信するSIPプロキシ・サーバ機能と、
前記SIPプロキシ・サーバ機能により受信したメッセージの種類および送信元を識別するメッセージ判別機能と、
送信先となる複数の外部のSIPサーバの中から前記REGISTERリクエストの送信先を決定する送信先決定機能と、
前記現用SIPサーバがREGISTERリクエストを受け入れた場合、受け入れ完了通知をユーザ端末に送ることなくREGISTERリクエストの再送を促すSIP応答を生成する再送依頼応答生成機能とを備えることを特徴とするプロキシ・サーバ。 - 外部とメッセージを送受信するSIPプロキシ・サーバ機能と、
前記SIPプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、
自身を介して現用SIPサーバに送信された前記REGISTERリクエストの正常処理完了を確認した後、ユーザ端末にSIP要求の送信先を予備SIPサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成機能とを備えることを特徴とするプロキシ・サーバ。 - 前記宛先変更依頼応答生成機能は、受信したメッセージが認証可を示すSIP応答でありかつ送信元が現用SIPサーバの場合に、前記宛先変更依頼応答を生成することを特徴とする請求項7に記載のプロキシ・サーバ。
- 前記REGISTERリクエストの複製の生成を、前記送信された回数の数回に1度行うことを特徴とする請求項1から請求項5のいずれか1項に記載のプロキシ・サーバ。
- 予備SIPサーバへ送信するREGISTERリクエストの生成時に当該REGISTERリクエストの有効期限を延長する有効期限更新機能を備えることを特徴とする請求項1から請求項5、請求項9のいずれか1項に記載のプロキシ・サーバ。
- 前記再送依頼応答生成機能は、前記現用SIPサーバから複数回受信した認証可を示すSIP応答の内の1回において、前記再送依頼応答を生成することを特徴とする請求項6に記載のプロキシ・サーバ。
- 前記再送依頼応答生成機能は、前記ユーザ端末からInitial REGISTERリクエストを受信した際に前記再送依頼応答を生成するか否かを判定し、
前記プロキシ・サーバは、前記再送依頼応答を生成すると判定した場合に、受信したメッセージの有効期限を更新する有効期限更新機能を備えることを特徴とする請求項11に記載のプロキシ・サーバ。 - 前記有効期限更新機能は、前記現用SIPサーバ及び前記予備SIPサーバの総数に応じて前記有効期限を更新することを特徴とする請求項12に記載のプロキシ・サーバ。
- 前記有効期限更新機能は、前記再送依頼応答を生成すると判定された場合に、前記ユーザ端末から受信した認証REGISTERリクエストの有効期限を延長し、受信したメッセージが認証可を示すSIP応答である場合に、当該有効期限を短縮することを特徴とする請求項12又は請求項13に記載のプロキシ・サーバ。
- 前記宛先変更依頼応答生成機能は、受信したInitial REGISTERリクエストの送信先が前記送信先対応情報で示される送信先と異なる複数回の場合の内の1回において、前記宛先変更依頼応答を生成することを特徴とする請求項13に記載のプロキシ・サーバ。
- 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置と、前記メッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
前記プロキシ・サーバに、
前記メッセージの送受信を仲介するプロキシ・サーバ機能と、
前記プロキシ・サーバ機能が受信したメッセージの種類を判別するメッセージ判別機能と、
前記メッセージ判別機能により、前記メッセージが前記現用通信制御装置内に保持される前記ユーザ端末に関する情報の処理を要求するメッセージであると判断した場合に一時的に当該メッセージの内容を記録する一時格納機能と、
前記メッセージが前記現用通信制御装置に受け入れられた場合に前記予備通信制御装置に認証のために前記メッセージと同内容のメッセージを複製するリクエスト生成機能とを備え、
前記プロキシ・サーバと前記予備通信制御装置間で、複製して生成された前記REGISTERリクエストによる前記ユーザ端末の認証を可能としたことを特徴とする通信システム。 - 外部のユーザ端末との間でSIPメッセージの送受信を行う現用及び予備のSIPサーバと、前記SIPメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
前記プロキシ・サーバに、
SIPメッセージの送受信を仲介するSIPプロキシ・サーバ機能と、
前記SIPプロキシ・サーバ機能が受信したSIPメッセージの種類と送信元を判別するメッセージ判別機能と、
前記SIPプロキシ・サーバ機能が受信した前記ユーザ端末のREGISTERリクエストの複製を一時的に格納する一時格納機能と、
前記現用SIPサーバでの処理が正常に完了したREGISTERリクエストに対応する前記REGISTERリクエストの複製、前記ユーザ端末の登録情報の複製先となる予備SIPサーバとのDigest認証で使用する前記プロキシ・サーバのユーザ識別子及びパスワードに基づいて、前記予備SIPサーバによる認証のためのREGISTERリクエストを生成するリクエスト生成機能とを備え、
前記プロキシ・サーバと前記予備SIPサーバ間で、複製して生成された前記REGISTERリクエストによる前記ユーザ端末の認証を可能としたことを特徴とする通信システム。 - 外部のユーザ端末との間でSIPメッセージの送受信を行う現用及び予備のSIPサーバと、前記SIPメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
前記プロキシ・サーバに、
外部とメッセージを送受信するSIPプロキシ・サーバ機能と、
前記SIPプロキシ・サーバ機能により受信したメッセージの種類および送信元を識別するメッセージ判別機能と、
送信先となる複数の外部のSIPサーバの中から前記REGISTERリクエストの送信先を決定する送信先決定機能と、
前記現用SIPサーバがREGISTERリクエストを受け入れた場合、受け入れ完了通知をユーザ端末に送ることなくREGISTERリクエストの再送を促すSIP応答を生成する再送応答生成機能とを備え、
前記送信先決定機能は、前記ユーザ端末から再送されたREGISTERリクエストの送信先を前記予備SIPサーバとし、
前記ユーザ端末と前記予備SIPサーバ間で、前記REGISTERリクエストによる前記ユーザ端末の認証を可能としたことを特徴とする通信システム。 - 外部のユーザ端末との間でSIPメッセージの送受信を行う現用及び予備のSIPサーバと、前記SIPメッセージの送受信を仲介するプロキシ・サーバとを含む通信システムであって、
前記プロキシ・サーバに、
外部とメッセージを送受信するSIPプロキシ・サーバ機能と、
前記SIPプロキシ・サーバ機能により受信したメッセージの種類を識別するメッセージ判別機能と、
前記プロキシ・サーバ自身を介して現用SIPサーバに送信された前記REGISTERリクエストの正常処理完了を確認した後、前記ユーザ端末にSIP要求の送信先を予備SIPサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成手段とを備え、
前記ユーザ端末と前記予備SIPサーバ間で、前記REGISTERリクエストによる前記ユーザ端末の認証を可能としたことを特徴とする通信システム。 - 前記プロキシ・サーバは、前記REGISTERリクエストの複製の生成を、前記送信された回数の数回に1度行うことを特徴とする請求項16又は請求項17に記載の通信システム。
- 予備SIPサーバへ送信するREGISTERリクエストの生成時に当該REGISTERリクエストの有効期限を延長する有効期限更新機能を備えることを特徴とする請求項16、請求項17、請求項20のいずれか1項に記載の通信システム。
- 前記再送依頼応答生成機能は、前記現用SIPサーバから複数回受信した認証可を示すSIP応答の内の1回において、前記再送依頼応答を生成することを特徴とする請求項18に記載の通信システム。
- 前記再送依頼応答生成機能は、前記ユーザ端末からInitial REGISTERリクエストを受信した際に前記再送依頼応答を生成するか否かを判定し、
前記プロキシ・サーバは、前記再送依頼応答を生成すると判定した場合に、受信したメッセージの有効期限を更新する有効期限更新機能を備えることを特徴とする請求項22に記載の通信システム。 - 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
前記メッセージの送受信を仲介する仲介ステップと、
前記仲介ステップで受信したメッセージの種類を判別するメッセージ判別ステップと、
前記メッセージ判別ステップにより、前記メッセージが前記現用通信制御装置内に保持される前記ユーザ端末に関する情報の処理を要求するメッセージであると判断した場合に一時的に当該メッセージの内容を記録する一時格納ステップと、
前記メッセージが前記現用通信制御装置に受け入れられた場合に前記予備通信制御装置に認証のために前記メッセージと同内容のメッセージを複製するリクエスト生成ステップとを備えることを特徴とする通信方法。 - 外部のユーザ端末との間でSIPメッセージの送受信を行う現用及び予備のSIPサーバに対し、前記SIPメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
SIPメッセージを仲介する仲介ステップと、
前記仲介ステップで受信したSIPメッセージの種類と送信元を判別するメッセージ判別ステップと、
前記仲介ステップで受信した前記ユーザ端末のREGISTERリクエストの複製を一時的に格納する一時格納ステップと、
前記現用SIPサーバでの処理が正常に完了したREGISTERリクエストに対応する前記REGISTERリクエストの複製、前記ユーザ端末の登録情報の複製先となる予備SIPサーバとのDigest認証で使用する前記プロキシ・サーバのユーザ識別子及びパスワードに基づいて、前記予備SIPサーバによる認証のためのREGISTERリクエストを生成するリクエスト生成ステップとを備えることを特徴とする通信方法。 - 外部のユーザ端末との間でSIPメッセージの送受信を行う現用及び予備のSIPサーバに対し、前記SIPメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
外部とメッセージを送受信する仲介ステップと、
前記仲介ステップにより受信したメッセージの種類および送信元を識別するメッセージ判別ステップと、
送信先となる複数の外部のSIPサーバの中から前記REGISTERリクエストの送信先を決定する送信先決定ステップと、
前記現用SIPサーバがREGISTERリクエストを受け入れた場合、受け入れ完了通知をユーザ端末に送ることなくREGISTERリクエストの再送を促すSIP応答を生成する再送応答生成ステップとを備え、
前記送信先決定ステップにおいて、前記ユーザ端末から再送されたREGISTERリクエストの送信先を前記予備SIPサーバとすることを特徴とする通信方法。 - 外部のユーザ端末との間でSIPメッセージの送受信を行う現用及び予備のSIPサーバに対し、前記SIPメッセージの送受信を仲介するプロキシ・サーバにおける通信方法であって、
外部とメッセージを送受信する仲介ステップと、
前記仲介ステップにより受信したメッセージの種類を識別するメッセージ判別ステップと、
前記プロキシ・サーバ自身を介して現用SIPサーバに送信された前記REGISTERリクエストの正常処理完了を確認した後、前記ユーザ端末にSIP要求の送信先を予備SIPサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成ステップとを備えることを特徴とする通信方法。 - 前記REGISTERリクエストの複製の生成を、前記送信された回数の数回に1度行うことを特徴とする請求項24又は請求項25に記載の通信方法。
- 予備SIPサーバへ送信するREGISTERリクエストの生成時に当該REGISTERリクエストの有効期限を延長する有効期限更新ステップを備えることを特徴とする請求項24、請求項25、請求項28のいずれか1項に記載の通信方法。
- 前記再送依頼応答生成ステップは、前記現用SIPサーバから複数回受信した認証可を示すSIP応答の内の1回において、前記再送依頼応答を生成することを特徴とする請求項26に記載の通信方法。
- 前記再送依頼応答生成ステップは、前記ユーザ端末からInitial REGISTERリクエストを受信した際に前記再送依頼応答を生成するか否かを判定し、
前記再送依頼応答を生成すると判定した場合に、受信したメッセージの有効期限を更新する有効期限更新ステップを備えることを特徴とする請求項30に記載の通信方法。 - 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
前記メッセージの送受信を仲介するプロキシ・サーバ処理と、
前記プロキシ・サーバ処理で受信したメッセージの種類を判別するメッセージ判別処理と、
前記メッセージ判別処理により、前記メッセージが前記現用通信制御装置内に保持される前記ユーザ端末に関する情報の処理を要求するメッセージであると判断した場合に一時的に当該メッセージの内容を記録する一時格納処理と、
前記メッセージが前記現用通信制御装置に受け入れられた場合に前記予備通信制御装置に認証のために前記メッセージと同内容のメッセージを複製するリクエスト生成処理とを前記プロキシ・サーバに実行させることを特徴とするプログラム。 - 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
SIPメッセージを仲介するSIPプロキシ・サーバ処理と、
前記SIPプロキシ・サーバ処理で受信したSIPメッセージの種類と送信元を判別するメッセージ判別処理と、
前記SIPプロキシ・サーバ処理で受信した前記ユーザ端末のREGISTERリクエストの複製を一時的に格納する一時格納処理と、
前記現用SIPサーバでの処理が正常に完了したREGISTERリクエストに対応する前記REGISTERリクエストの複製、前記ユーザ端末の登録情報の複製先となる予備SIPサーバとのDigest認証で使用する前記プロキシ・サーバのユーザ識別子及びパスワードに基づいて、前記予備SIPサーバによる認証のためのREGISTERリクエストを生成するリクエスト生成処理とを前記プロキシ・サーバに実行させることを特徴とするプログラム。 - 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
外部とメッセージを送受信するSIPプロキシ・サーバ処理と、
前記SIPプロキシ・サーバ処理により受信したメッセージの種類および送信元を識別するメッセージ判別処理と、
送信先となる複数の外部のSIPサーバの中から前記REGISTERリクエストの送信先を決定する送信先決定処理と、
前記現用SIPサーバがREGISTERリクエストを受け入れた場合、受け入れ完了通知をユーザ端末に送ることなくREGISTERリクエストの再送を促すSIP応答を生成する再送応答生成処理とを前記プロキシ・サーバに実行させ、
前記送信先決定処理において、前記ユーザ端末から再送されたREGISTERリクエストの送信先を前記予備SIPサーバとすることを特徴とするプログラム。 - 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装置に対し、前記メッセージの送受信を仲介するプロキシ・サーバに実行させるためのプログラムであって、
外部とメッセージを送受信するSIPプロキシ・サーバ処理と、
前記SIPプロキシ・サーバ処理により受信したメッセージの種類を識別するメッセージ判別処理と、
前記プロキシ・サーバ自身を介して現用SIPサーバに送信された前記REGISTERリクエストの正常処理完了を確認した後、前記ユーザ端末にSIP要求の送信先を予備SIPサーバに変更させる宛先変更依頼応答を生成する宛先変更依頼応答生成処理とを前記プロキシ・サーバに実行させることを特徴とするプログラム。 - 前記REGISTERリクエストの複製の生成を、前記送信された回数の数回に1度行うことを特徴とする請求項32又は請求項33に記載のプログラム。
- 予備SIPサーバへ送信するREGISTERリクエストの生成時に当該REGISTERリクエストの有効期限を延長する有効期限更新処理を前記プロキシ・サーバに実行させることを特徴とする請求項32、請求項33、請求項36のいずれか1項に記載のプログラム。
- 前記再送依頼応答生成処理は、前記現用SIPサーバから複数回受信した認証可を示すSIP応答の内の1回において、前記再送依頼応答を生成することを特徴とする請求項34に記載のプログラム。
- 前記再送依頼応答生成処理は、前記ユーザ端末からInitial REGISTERリクエストを受信した際に前記再送依頼応答を生成するか否かを判定し、
前記再送依頼応答を生成すると判定した場合に、受信したメッセージの有効期限を更新する有効期限更新処理を前記プロキシ・サーバに実行させることを特徴とする請求項38に記載のプログラム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006223363 | 2006-08-18 | ||
JP2006223363 | 2006-08-18 | ||
PCT/JP2007/066079 WO2008020644A1 (fr) | 2006-08-18 | 2007-08-14 | Serveur mandataire, système de communication, procédé de communication et programme |
Related Child Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009090995A Division JP4465639B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090974A Division JP4465637B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090986A Division JP4465638B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP4336904B2 true JP4336904B2 (ja) | 2009-09-30 |
JPWO2008020644A1 JPWO2008020644A1 (ja) | 2010-01-07 |
Family
ID=39082164
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008506836A Expired - Fee Related JP4336904B2 (ja) | 2006-08-18 | 2007-08-14 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090986A Expired - Fee Related JP4465638B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090974A Expired - Fee Related JP4465637B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090995A Expired - Fee Related JP4465639B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009090986A Expired - Fee Related JP4465638B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090974A Expired - Fee Related JP4465637B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
JP2009090995A Expired - Fee Related JP4465639B2 (ja) | 2006-08-18 | 2009-04-03 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US20090262724A1 (ja) |
JP (4) | JP4336904B2 (ja) |
WO (1) | WO2008020644A1 (ja) |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101127766B (zh) * | 2007-09-24 | 2010-06-09 | 中兴通讯股份有限公司 | 基于sip协议的消息处理方法、装置及ip通信*** |
JP5182701B2 (ja) * | 2008-09-16 | 2013-04-17 | Necエンジニアリング株式会社 | Sipシステム |
US8601139B2 (en) * | 2008-11-26 | 2013-12-03 | Cavium, Inc. | Multiple core session initiation protocol (SIP) |
EP3754942A1 (en) | 2009-04-13 | 2020-12-23 | BlackBerry Limited | System and method for determing trust for sip messages |
JP5309350B2 (ja) * | 2009-08-10 | 2013-10-09 | 株式会社日立製作所 | 移動体通信ゲートウェイ装置及び移動体通信ゲートウェイ制御方法 |
US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
KR101566926B1 (ko) | 2009-12-03 | 2015-11-06 | 삼성에스디에스 주식회사 | 홈네트워크 시스템의 통화 이중화 방법 |
JP5693065B2 (ja) * | 2010-07-06 | 2015-04-01 | キヤノン株式会社 | 通信端末、通信端末の制御方法及びプログラム |
JP5044710B1 (ja) * | 2011-05-31 | 2012-10-10 | 株式会社東芝 | 電話システム、サーバ装置及び電話システムで使用される制御方法 |
EP2587774B1 (en) * | 2011-10-24 | 2015-03-04 | Alcatel Lucent | A method for sip proxy failover |
JP2014010554A (ja) * | 2012-06-28 | 2014-01-20 | Kotobuki Solution Co Ltd | ユーザ認証システム |
US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
JP2015177489A (ja) * | 2014-03-18 | 2015-10-05 | 日本電気株式会社 | 情報通信制御システム及び情報通信制御方法、ならびに、この情報通信制御システムにおける複製装置 |
US9749146B2 (en) * | 2014-10-21 | 2017-08-29 | Electronics And Telecommunications Research Institute | Apparatus and methods for providing home network service |
US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
CN107018159B (zh) * | 2016-01-27 | 2020-09-11 | 五八同城信息技术有限公司 | 业务请求处理方法及装置、和业务请求方法及装置 |
US9990260B2 (en) * | 2016-04-29 | 2018-06-05 | Netapp Inc. | Cross-platform replication |
US10735540B1 (en) * | 2017-04-22 | 2020-08-04 | EMC IP Holding Company LLC | Automated proxy selection and switchover |
EP3439272A1 (en) * | 2017-08-03 | 2019-02-06 | Unify Patente GmbH & Co. KG | Method of providing backup for an openscapevoice register configuration |
US11190374B2 (en) | 2017-08-28 | 2021-11-30 | Bright Data Ltd. | System and method for improving content fetching by selecting tunnel devices |
EP3754520B1 (en) | 2017-08-28 | 2022-02-02 | Bright Data Ltd | Method for improving content fetching by selecting tunnel devices |
CN108924142B (zh) * | 2018-07-13 | 2021-01-19 | 江苏中利电子信息科技有限公司 | 一种基于sip协议的安全语音对讲通讯方法 |
JP7032652B2 (ja) * | 2018-08-03 | 2022-03-09 | 日本電信電話株式会社 | 仮想世界構築システム及び方法 |
EP4236263A3 (en) | 2019-02-25 | 2023-09-06 | Bright Data Ltd. | System and method for url fetching retry mechanism |
KR102256867B1 (ko) | 2019-11-06 | 2021-05-27 | 금호미쓰이화학 주식회사 | 폴리이소시아네이트의 품질 개선 방법 및 이를 통해 품질이 개선된 폴리이소시아네이트 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4087271B2 (ja) * | 2003-03-19 | 2008-05-21 | 株式会社日立製作所 | 代理応答装置およびネットワークシステム |
JP4276568B2 (ja) * | 2004-03-26 | 2009-06-10 | 株式会社日立コミュニケーションテクノロジー | ルータ及びsipサーバ |
CN1716953B (zh) * | 2004-06-28 | 2010-09-15 | 华为技术有限公司 | 会话初始协议认证的方法 |
US20060036747A1 (en) * | 2004-07-28 | 2006-02-16 | Galvin James P Jr | System and method for resource handling of SIP messaging |
US8055778B2 (en) * | 2004-09-30 | 2011-11-08 | Siemens Enterprise Communications, Inc. | SIP user agent with simultaneous multiple registrations |
US20060271812A1 (en) * | 2005-05-26 | 2006-11-30 | David Horton | Systems and methods for providing redundant application servers |
JP4329747B2 (ja) * | 2005-08-30 | 2009-09-09 | ヤマハ株式会社 | VoIPサーバ、VoIPサーバの冗長システム及びそのメンテナンス方法 |
-
2007
- 2007-08-14 JP JP2008506836A patent/JP4336904B2/ja not_active Expired - Fee Related
- 2007-08-14 WO PCT/JP2007/066079 patent/WO2008020644A1/ja active Application Filing
- 2007-08-14 US US12/092,034 patent/US20090262724A1/en not_active Abandoned
-
2009
- 2009-04-03 JP JP2009090986A patent/JP4465638B2/ja not_active Expired - Fee Related
- 2009-04-03 JP JP2009090974A patent/JP4465637B2/ja not_active Expired - Fee Related
- 2009-04-03 JP JP2009090995A patent/JP4465639B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US20090262724A1 (en) | 2009-10-22 |
JP2009189037A (ja) | 2009-08-20 |
JP2009159627A (ja) | 2009-07-16 |
JPWO2008020644A1 (ja) | 2010-01-07 |
JP4465638B2 (ja) | 2010-05-19 |
JP4465639B2 (ja) | 2010-05-19 |
WO2008020644A1 (fr) | 2008-02-21 |
JP4465637B2 (ja) | 2010-05-19 |
JP2009159626A (ja) | 2009-07-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4336904B2 (ja) | プロキシ・サーバ、通信システム、通信方法及びプログラム | |
JP4690461B2 (ja) | ブランチオフィスdns格納及び解決 | |
US8171171B2 (en) | Data synchronization method and system between devices | |
KR100945972B1 (ko) | 코어 기반 노드를 사용하여 상태를 전송하기 위한 향상된 기술들 | |
US7437479B2 (en) | Position identifier management apparatus and method, mobile computer, and position identifier processing method | |
US9424325B2 (en) | Recording medium, distribution controlling method, and information processing device | |
JP4268969B2 (ja) | 無線通信網を介したメディアメッセージアップロード制御方法 | |
JP2004532443A (ja) | 状態転送動作のための分散型キャッシュ | |
TW200835265A (en) | Address resolution request mirroring | |
JP6191159B2 (ja) | サーバ、バックアップシステム、バックアップ方法、および、コンピュータ・プログラム | |
CN101547210A (zh) | 一种tcp连接的处理方法和装置 | |
WO2006072222A1 (fr) | Procede permettant de mettre en oeuvre la synchronisation de donnees du serveur et du cote client dans le mecanisme du systeme de nom de domaine | |
CN112671554A (zh) | 一种节点故障处理方法及相关装置 | |
WO2008089692A1 (fr) | Procédé et système de synchronisation de données | |
JPH10112740A (ja) | 情報処理装置、通信方法および記憶媒体 | |
US20050187959A1 (en) | Method for transferring a message file between a client and a server | |
JP5039975B2 (ja) | ゲートウェイ装置 | |
CN111066339B (zh) | 用于分布式移动网络的***和方法 | |
US8051129B2 (en) | Arrangement and method for reducing required memory usage between communication servers | |
KR20230124099A (ko) | 클라우드 저하 모드에서 지속적인 디바이스 동작 안정성을보장하기 위한 방법 및 장치 | |
KR100583177B1 (ko) | 중복 과금을 방지하기 위한 과금 메시지 처리 방법 및 그과금 서버 | |
JP4261395B2 (ja) | サーバ装置 | |
CN114979237B (zh) | 一种长连接验证方法、装置、设备及可读存储介质 | |
WO2016187805A1 (zh) | 一种数据处理方法及装置 | |
KR100612443B1 (ko) | 네트워크를 통한 에이알피 정보 처리장치 및 그 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090602 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090615 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120710 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120710 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130710 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |