JP4433309B2 - 負荷分散装置 - Google Patents

Description

本発明は、負荷分散装置、方法、及び、プログラムに関し、更に詳しくは、SIP（session initiation protocol）を使用してシグナリングを行う通信網に好適に利用され、サーバの負荷を分散させる負荷分散装置、負荷分散方法、及び、プログラムに関する。

近年、VoIP（voice over IP）に見られるように、IP網を使用したリアルタイム・コミュニケーションが普及している。例えば、電話端末やパソコンなどの、リアルタイム・コミュニケーションを行う両端の端末間接続を確立する国際標準プロトコルとしてSIP（session initiation protocol）を採用する状況が多くなっている。なお、本明細書では、SIPを使用してシグナリングを行う通信網をSIPネットワークと呼ぶ。

SIPネットワークの一般的な構成は、非特許文献１に記載されている。SIPネットワークは、ロケーション・サーバと、SIPサーバと、ユーザ・エージェント（UA： user agent）とから構成されている。UAは、非特許文献１のP.76に、「SIPは、エンド・システム間のクライアント-サーバ・モデルに基づいています。このエンド・システムに相当するのが、ユーザ・エージェント（UA: User Agent）です。ユーザ・エージェントとは、具体的には電話機やパソコンなどのエンド・システムのことですが、これらのエンド・システム間でリクエスト（要求）とレスポンス（応答）をやり取りすることによって、サービスを実現します」と説明されている。本明細書では、上記説明文記載のリクエストをSIP要求、レスポンスをSIP応答と呼ぶ。

SIPサーバは、非特許文献１のP.77に記載されているように、(1) SIP要求やSIP応答を中継するプロキシ・サーバ機能と、(2) SIP要求の宛先の問合せに利用するリダイレクト・サーバ機能と、(3) SIPネットワーク上のUAの位置情報の登録を受け付ける登録サーバ機能とを有する。

ロケーション・サーバは、非特許文献１のP.81に、「登録サーバで維持されるUAの情報を蓄積し、プロキシ・サーバ機能やリダイレクト・サーバ機能によって利用される、データベース・サービスを提供します」と記載されている。具体的には、非特許文献１のP.112に記載されているように、SIP要求のREGISTGERリクエストを使用して、UAの位置情報を蓄積する。なお、以降では、このREGISTERリクエストにより、ロケーション・サービスに登録されるUAの位置情報をRegisterエントリと呼ぶ。

更に、非特許文献１の P.81に、「SIPではロケーション・サーバへのアクセスの方法を規定していません」との記述があるように、SIPサーバとロケーション・サーバの対応は規定されていない。例えば、非特許文献２に記載のSIPサーバ製品では、同ホームページの参考図に示されているように、ロケーション・サーバを外に括りだすことで、SIPサーバのプロキシ・サーバ機能とロケーション・サーバとがN対1の組み合わせになっている。このように、1つのロケーション・サーバを複数のプロキシ・サーバ機能で共有するモデルを、以降では、共有モデルと呼ぶ。

また一方、例えば、非特許文献３に記載のSIPサーバ製品では、同ホームページに記載されているように、SIPサーバにロケーション・サービスを配備させることで、SIPサーバのプロキシ・サーバ機能とロケーション・サーバとが1対1の組み合わせになっている。このように、1つのSIPサーバにロケーション・サーバ機能を配備させるモデルを、以降では、専有モデルと呼ぶ。

上記のような特徴を持つSIPサーバ（特に、プロキシ・サーバ機能）を負荷分散する従来技術としては、一般的に、非特許文献４に記載された方式がある。このホームページのP.8に記載されている構成のように、この方式では、負荷分散装置に、SIP要求に格納されているCall-IDヘッダの値（呼識別子、以降、単にCall-IDと呼ぶ）とSIP要求の振分先となるSIPサーバ（特に、プロキシ・サーバ機能）との対応表を持たせている。この場合の処理は以下のようになる。

まず、SIP要求に格納されているCall-IDを抽出し、このCall-IDを検索キーとして上述した対応表を検索する。この検索の結果、検出されたSIPサーバ（特に、プロキシ・サーバ機能）にSIP要求を転送する。
「改訂版 SIP教科書」P.78の図3-2「ユーザ・エージェントとSIPサーバの関係」 （HYPERLINK "http://www.oki.com/jp/Home/JIS/New/OKI-News/2002/09/z02061.html"http://www.oki.com/jp/Home/JIS/New/OKI-News/2002/09/z02061.html） （HYPERLINK "http://www.sw.nec.co.jp/netsoft/cx6820-ss/pdf/cx6820cassmcmd6800gk.pdf"http://www.sw.nec.co.jp/netsoft/cx6820-ss/pdf/cx6820cassmcmd6800gk.pdf） （HYPERLINK "http://www.f5networks.co.jp/ja/solution/application/ap11a#01.html"http://www.f5networks.co.jp/ja/solution/application/ap11a#01.html）

従来技術の第１の問題は、従来技術を専有モデルに適用した場合、負荷分散装置とSIPサーバ間でSIP要求のピンポン現象が発生することである。具体的には図18に示す処理となる。いま、負荷分散装置LB6が、Call-IDと振分先SIPサーバの識別子との組を格納した対応表を持ち、UA T2のRegisterエントリ（端末位置情報登録）がSIPサーバSS2のロケーション・サーバに格納されているとする。この状態で、UA T1がUA T2との通信路を確立するために、Call-IDが「a」となるINVITEリクエスト（呼接続要求メッセージ）を発行したとする（図18の矢印(1)）。このINVITEリクエストのCall-IDは「a」であるため、負荷分散装置LB1は、対応表を参照して、受信したINVITEリクエストをSIPサーバSS1に転送する（図18の矢印(2)）。

SIPサーバSS1では、INVITEリクエストの転送対象となる受信側UA T2のRegisterエントリが存在しないので、UA T2の位置情報が分からず、UA T2に直接INVITEリクエストを転送できない。このため、負荷分散装置LB6にINVITEリクエストを転送する（図18の矢印(3)）。なお、この時、INVITEリクエストのCall-IDはSIPサーバSS1では変更されない。SIPサーバSS1からのINVITEリクエストを受信した負荷分散装置LB6は、再度自身が保持する対応表を確認し、Call-IDが「a」のINVITEリクエストを再びSIPサーバSS1に転送してしまう（図18の矢印(4)）。このような負荷分散装置LB6とSIPサーバSS1間でピンポン現象が発生する原因は、専有モデルでは、Registerエントリが分散配置されているにも係らず、負荷分散装置LB6が、着信側UAのRegisterエントリの存在場所を把握しないで、Call-IDのみを指標として、SIP要求の転送先となるSIPサーバを決定していることである。

本発明は、上記ネットワークに関する従来技術の問題に鑑み、ユーザ端末の位置情報を示すRegisterエントリが分散配置された環境においても、ユーザ端末のRegisterエントリの存在するサーバを迅速に特定し、該当するサーバからRegisterエントリを取得し、振分先サーバに格納することで、呼接続要求の転送先サーバにおいて呼接続要求の処理を可能にさせる、負荷分散装置を提供することにある。

上記目的を達成するために、本発明は、その第１の視点において、ネットワークを介して通信を行う複数のユーザ端末と、それぞれが前記通信を仲介する機能及びユーザ端末の位置情報登録機能を有する複数のサーバとにネットワークを介して接続され、少なくとも通信の仲介を処理すべきサーバを選定することによってサーバの負荷を分散させる負荷分散装置において、
ネットワークから受信したメッセージを検査して、発信側のユーザ端末が発行した呼接続要求メッセージを検出するメッセージ解析部と、
前記検出した呼接続要求メッセージを処理すべきサーバを所定のアルゴリズムに従って選定し、該選定したサーバに前記呼接続要求メッセージを転送するサーバ振分部と、
前記呼接続要求メッセージの着信側ユーザ端末のアドレスを検索キーとして、ユーザ端末のアドレスとユーザ端末の位置情報登録を有するサーバとを対応付けて記憶する記憶装置を検索し、前記着信側ユーザ端末の位置情報登録を有するサーバを特定する登録情報取得部とを備えることを特徴とする負荷分散装置を提供する。

また、本発明は、その第２の視点において、ネットワークを介して通信を行う複数のユーザ端末と、それぞれが前記通信を仲介する機能及びユーザ端末の位置情報登録機能を有する複数のサーバとにネットワークを介して接続されるコンピュータを利用して、少なくとも通信の仲介を処理すべきサーバを選定することによってサーバの負荷を分散させる負荷分散方法において、
コンピュータが、ネットワークから受信したメッセージを検査して、発信側のユーザ端末が発行した呼接続要求メッセージを検出するステップと、
コンピュータが、前記検出した呼接続要求メッセージを処理すべきサーバを所定のアルゴリズムに従って選定し、該選定したサーバに前記呼接続要求メッセージを転送するステップと、
コンピュータが、前記呼接続要求メッセージの着信側ユーザ端末のアドレスを検索キーとして、ユーザ端末のアドレスとユーザ端末の位置情報登録を有するサーバとを対応付けて記憶する記憶装置を検索し、前記着信側ユーザ端末の位置情報登録を有するサーバを特定するステップとを備えることを特徴とする負荷分散方法を提供する。

更に、本発明は、その第３の視点において、ネットワークを介して通信を行う複数のユーザ端末と、それぞれが前記通信を仲介する機能及びユーザ端末の位置情報登録機能を有する複数のサーバとにネットワークを介して接続され、少なくとも通信の仲介を処理すべきサーバを選定することによってサーバの負荷を分散させるコンピュータのためのプログラムであって、前記コンピュータに、
ネットワークから受信したメッセージを検査して、発信側のユーザ端末が発行した呼接続要求メッセージを検出する処理と、
前記検出した呼接続要求メッセージを処理すべきサーバを所定のアルゴリズムに従って選定し、該選定したサーバに前記呼接続要求メッセージを転送する処理と、
前記呼接続要求メッセージの着信側ユーザ端末のアドレスを検索キーとして、ユーザ端末と該ユーザ端末の位置情報登録を有するサーバとを対応付けて記憶する記憶装置を検索し、前記着信側ユーザ端末の位置情報登録を有するサーバを取得する処理とを実行させることを特徴とするプログラムを提供する。

本発明の負荷分散装置、負荷分散方法、及び、プログラムによると、新たに呼接続要求が発生した場合に、負荷分散装置で呼接続要求の処理に振り分けられた振分先サーバは、自身が呼接続要求の宛先である着信側ユーザ端末の位置情報登録を有しない場合には、呼接続要求メッセージのアドレスから位置情報登録を有するサーバが検索され、そのサーバを経由して呼接続要求が転送されるので、従来技術で振分先サーバと負荷分散装置との間で発生したような、呼接続要求のピンポン現象が発生することがない。

なお、本発明で使用する用語“ユーザ端末のアドレス”には、ユーザ端末を一意に識別が可能なものであれば全て含まれ、例えば、ＩＰアドレスなどの通常のアドレスに限定されない。また、ネットワークは、SIPネットワークに限らず、各サーバがそれぞれ通信の仲介機能（プロキシ機能）及び位置情報登録機能を有すればよく、そのようなサーバを有する他の種々のネットワークも含まれる。

負荷分散装置は、種々の記憶装置、プロセッサ、通信インタフェースなどを含むコンピュータシステムで構成され、各構成部分は、一般に１つのプログラム、または、プログラムの各部分によってその機能が得られる。

次に、本発明の実施形態について、図面を参照して詳細に説明する。図1を参照すると、本発明の第１の実施形態に係る負荷分散装置LB1を有するSIPネットワークが示されている。負荷分散装置LB1は、ネットワークを介して複数のUA（ユーザ端末）T1、T2と、複数のSIPサーバSS1、SS2とに接続している。なお、図1では、UAおよびSIPサーバを共に2台ずつ示しているが、3台以上のUAおよびSIPサーバでも良い。

負荷分散装置LB1は、SIPサーバ振分先決定部（振分決定部）101と、Registerエントリ格納部（位置情報登録部）102と、メッセージ解析部103と、メッセージ送受信部（通信インターフェイス）104とから構成される。振分先決定部101は、UAまたはSIPサーバから送信されてきた、例えば、REGISTERリクエストやINVITEリクエストなどのSIP要求を振り分けてSIPサーバを選定する機能と、着信側UAのRegisterエントリを振り分け対象となるSIPサーバに格納するよう、Registerエントリ格納部102に依頼する機能と、SIP要求を振り分け対象となるSIPサーバに転送するよう、メッセージ送受信部104に依頼する機能と、SIP要求の振り分け対象となるSIPサーバを選定する場合に参照する情報（以降、振分情報と呼ぶ）を管理する機能とを有する。なお、振分情報の例については、動作説明で詳述する。

Registerエントリ格納部102は、振分先決定部101が選定したSIPサーバに対して、着信側UAのRegisterエントリ（位置情報登録）を格納しているか否かを問い合わせる機能と、着信側UAのRegisterエントリを格納するSIPサーバを特定する機能と、着信側UAのRegisterエントリを取得し、振分先決定部101が選定したSIPサーバに、該当Registerエントリを格納する機能とを有する。

メッセージ解析部103は、メッセージ送受信部104から転送されたSIP要求、または、例えば、180 Ringingや200 OKなどのSIP応答が格納されたメッセージの種類を解析する機能と、SIP要求を振分先決定部101に、また、負荷分散装置LB1から送信されたSIP要求に対するSIP応答をRegisterエントリ格納部102に、SIP要求に対するSIP応答であるが、負荷分散装置LB１が発行したSIP要求以外のSIP要求に対するSIP応答をメッセージ送受信部104に、それぞれ送信する機能とを有する。

メッセージ送受信部104は、UAまたはSIPサーバから送信されたSIP要求またはSIP応答であるメッセージを受信する機能と、振分先決定部101により指定されたUAまたはSIPサーバに、SIP要求またはSIP応答であるメッセージを送信する機能と、UAまたはSIPサーバから送信されてきた、SIP要求またはSIP応答であるメッセージを受信し、SIPメッセージ解析部103に送信する機能とを有する。

図1の負荷分散装置LB1の動作を説明する。図2は、負荷分散装置LB1における、メッセージ解析部103の処理を示すフローチャートである。いま、メッセージ解析部103が、メッセージ送受信部104から、UAまたはSIPサーバから送信されたメッセージを受信したとする。この時、メッセージ解析部103は、受信したメッセージの種類を検査する（ステップS201）。ステップ201の検査で、受信したメッセージが、例えば、INVITEリクエスト（呼接続要求）やREGISTERリクエスト（位置情報登録要求）などのSIP要求であると判定した場合には、受信メッセージを振分先決定部101に転送する（ステップS205）。

一方、ステップS201の検査で、受信したメッセージが、例えば、180 Ringingや200 OKなどの、SIP応答であると判定した場合には、更に、そのSIP応答が、負荷分散装置LB1から発行したSIP要求に対するSIP応答か否かを判定する（ステップS202）。例えば、この判定処理は下記の手段で実現できる。

例えばRegisterエントリ格納部102が、REGISTERリクエストを発行する場合に付加する識別子（Call-ID）をメッセージ解析部103に予め転送しておく。なお、この識別子は任意の文字列でよい。例えば、INVITEリクエストの識別子と同じ、或いは、これに何らかの符号を付加したものであってもよい。メッセージ解析部103は、メッセージ送受信部104から受信したメッセージに含まれるCall-IDを調査し、それが予めRegisterエントリ格納部102から通知されていたCall-IDと一致する場合には、負荷分散装置LB1から発行したSIP要求に対するSIP応答と判断する。

ステップS202で、受信したSIP応答が、負荷分散装置LB1から発行したSIP要求に対するSIP応答であると判定した場合には、受信メッセージをRegisterエントリ格納部102に転送する（ステップS204）。ステップS202で、受信したSIP応答が、負荷分散装置LB1から発行したSIP要求に対するSIP応答でないと判定した場合には、受信メッセージをメッセージ送受信部104に転送する（ステップS203）。

図3は、負荷分散装置LB1における、振分先決定部101の処理を示すフローチャートである。いま、振分先決定部101がメッセージ解析部103からSIP要求を受信したとする。この時、振分先決定部101は、SIP要求の種別を検査する（ステップS301）。ステップS301の検査で、振分先決定部101が取得したSIP要求がREGISTERリクエストであると判定した場合には、REGISTERリクエストの振り分け先となるSIPサーバを決定する（ステップS302）。なお、以降では、負荷分散装置LB1からSIP要求を転送する先となるSIPサーバを、振分先SIPサーバと呼ぶ。ステップS302の処理は、例えば、下記の手段で実現できる。

例えばREGISTERリクエストのToヘッダに含まれるAoR（address of record）や、contactヘッダに含まれるSIP URI（Uniform Resource Identifier）中の電話番号（電話番号を含むSIP URIは、一般的に「sip:電話番号@ドメイン名」として表現される）などの、検索キーを取り出す。振り分け対象となるSIPサーバの識別子を、振り分け対象となるSIPサーバの数未満の正の整数とする場合には、前記検索キーを正の整数に変換し、振り分け対象となるSIPサーバの数で除した余りで表現されるSIPサーバを振り分け対象とする。

ステップS301の検査で、SIP要求がINVITEリクエストであると判定された場合には、INVITEリクエストの振分先SIPサーバを決定する（ステップS303）。この処理は、例えば、以下の手段で実現できる。例えばINVITEリクエストのFromヘッダに含まれるAoRや、Call-IDなどを、検索キーとして取り出す。この後の処理は前述したREGISTERリクエストでの振分先SIPサーバの決定処理と同様である。また、ステップS303の処理は、例えば下記に示す手段により、最少負荷量のSIPサーバを検出し、そのSIPサーバを振分先SIPサーバとすることも可能である。

図4は、最少負荷量のSIPサーバを検出する際に使用する情報（以降、「最少負荷SIPサーバ検索情報」と呼ぶ）を示している。この情報は、特に、通話などのために暫くの間続くUA間の関係を示したダイアログの処理数を負荷量としており、処理数配列と振分順リストとから構成されている。処理数配列は、SIPサーバが現在処理しているダイアログの数（以降では「処理数」と記載）を格納したものである。この処理数を格納した配列は、前述したREGISTERリクエストの振り分け先決定処理で使用したSIPサーバの識別子（連続した正の整数）を添え字としている。更に、この処理数配列には、処理数に加えて、振分順リストの構成要素へのポインタを保持している。

振分順リストは、前述した処理数を昇順に並べたリストである。このリストは、処理数増加時（INVITEリクエスト受信時）および処理数減少時（BYEリクエスト受信時）に順番が変更される。この動的な変更を実現するために、リストの各構成要素には、前エントリおよび次エントリへのポインタを格納している。更に、昇順にリストする際に参照する処理数を格納した処理数配列の該当エントリへのポインタを格納している。この振分順リストの先頭エントリが示す識別子で識別されるSIPサーバを選択することで、最少負荷量のSIPサーバを選択することが可能となる。

ステップS303の結果として取得した振分先SIPサーバの識別子と、受信したINVITEリクエストのToヘッダのAoRとを、Registerエントリ格納部102に通知し、着信側UAのRegisterエントリが振分先SIPサーバに格納されるよう、Registerエントリ格納部102に依頼する（ステップS304）。

ステップS301の検査で、メッセージ解析部103から受信したSIP要求の種別が、例えば、ACKリクエストやBYEリクエストなどであって、REGISTERリクエストおよびINVITEリクエスト以外の場合には、SIP要求に格納されているCall-IDを抽出する（ステップS307）。ステップS307の結果として取得されたCall-IDを検索キーとして、Call-IDと振分先SIPサーバの識別子の組が格納されたハッシュ表を検索する（ステップS308）。

その後、ステップS301で検査したSIP要求の種別がBYEリクエストであるか否かを判定し（ステップS309）、SIP要求がBYEリクエストである場合には、又は、ステップS304の結果Registerエントリの格納依頼が完了した場合には、振分情報を更新する（ステップS305）。この振分情報は、ステップS308で使用した、Call-IDと振分先SIPサーバとの組を格納したハッシュ表と、ステップS303での振分先SIPサーバの決定手段に最少負荷量のSIPサーバを選択する手段を使用している場合には、最少負荷SIPサーバ検索情報とである。

Call-IDと振分先SIPサーバとの組を格納したハッシュ表の更新は下記の手段による。ステップS301の結果、受信したSIP要求がINVITEリクエストと判明した場合には、INVITEリクエストに格納されているCall-IDとステップS303の結果決定した振分先SIPサーバとを組としてハッシュ表に格納する。ステップS309で、SIP要求がBYEリクエストであった場合には、BYEリクエストに格納されているCall-IDをキーとする組をハッシュ表から削除する。

最少負荷SIPサーバ検索情報の更新手順は以下の手段で実現できる。図5は、最少負荷SIPサーバ検索情報の更新手順に関して、特に、INVITEリクエストを受信した際の処理（処理数増加時処理）を示したものである。いま、ステップS303の結果、振分先SIPサーバの識別子が判明しているとする。処理数配列において、振分先SIPサーバの識別子で示されるエントリに格納されている処理数（これを「処理数1」と呼ぶ）を1加算する（ステップS501）。次に、処理数配列の該当エントリにおけるリストエントリで示された、振分順リストのエントリにおける次エントリで示されたエントリに格納された配列エントリで示された処理数配列に格納されている処理数（これを「処理数2」と呼ぶ）を取得する（ステップS502）。つまり、昇順リストで、ステップS501で１つ加算する前の処理数1よりも大きい次のエントリの処理数2を取得する。

ステップS501の結果取得した処理数1とステップS502の結果取得した処理数2とを比較する（ステップS503）。ステップS503の比較の結果、「処理数1≧処理数2」の場合には、処理数2を格納している、振分順リストのエントリの次エントリにおける、配列エントリで示された処理数配列のエントリの処理数を処理数2に代入し、次いでステップS503からの処理を繰り返す（ステップS504）。つまり、処理数１を更に次の処理数と比較して、その大小関係を調べる。ステップS503の比較の結果、「処理数1<処理数2」の場合には、処理数2を格納している、振分順リストのエントリの前に、処理数1を格納している振分順リストのエントリを挿入する（ステップS505）。つまり、以前の順序を変更しない。

図6は、最少負荷SIPサーバ検索情報の更新手順に関して、特に、BYEリクエスト（呼解放要求）を受信した際の処理（処理数減少時処理）を示したものである。いま、ステップS303の結果、振分先SIPサーバの識別子が判明しているとする。処理数配列において、振分先SIPサーバの識別子で示される、エントリに格納されている処理数（これを「処理数1」と呼ぶ）を1減少する（ステップS601）。次に、処理数配列の該当エントリにおけるリストエントリで示された、振分順リストのエントリにおける、前のエントリで示されたエントリに格納された、配列エントリで示された処理数配列に格納されている処理数（これを「処理数2」と呼ぶ）を取得する（ステップS602）。

ステップS601の結果として取得した処理数1とステップS602の結果として取得した処理数2とを比較する（ステップS603）。ステップS603の比較の結果、「処理数1≦処理数2」の場合には、処理数2を格納している、振分順リストのエントリの前エントリにおける、配列エントリで示された処理数配列のエントリの処理数を処理数2に代入し、ステップS603からの処理を繰り返す（ステップS604）。つまり、処理数１を更に前の処理数と比較して、その大小関係を調べる。ステップS603の比較の結果、「処理数1>処理数2」の場合には、処理数2を格納している、振分順リストのエントリの次に、処理数1を格納している振分順リストのエントリを挿入する（ステップS605）。つまり、以前の順序を変更しない。

図3に戻り、ステップS302の結果として振分先SIPサーバを決定した場合、または、ステップS305の結果として振分情報の更新が完了した場合、または、ステップS309の判定でSIP要求がBYEリクエスト以外であった場合には、ステップS302またはステップS303またはステップS308の結果として取得した振分先SIPサーバに受信メッセージを転送するよう、メッセージ送受信部104に通知する（ステップS306）。

図7は、Registerエントリ格納部102の処理を示すフローチャートである。いま、Registerエントリ格納部102が、振分先決定部101から、振分先SIPサーバの識別子と、INVITEリクエストのToヘッダに格納された、着信側UAを示すAoRを受け取ったとする。Registerエントリ格納部102は、指定されたSIPサーバに送信するREGISTERリクエストを生成する（ステップS701）。例えば、この処理は、FromヘッダとToヘッダには、振分先決定部101から送信されたAoRを挿入し、Call-IDは「ランダムとなる文字列@負荷分散装置LB1のIPアドレス」とし、CSeqヘッダは「1 REGISTER」とすることで実現できる。

ステップS701で生成されたREGISTERリクエストを、振分先決定部101から指定されたSIPサーバに送信するよう、メッセージ送受信部104に通知することで、振分先SIPサーバに着信側UAのRegisterエントリが存在するか否かを問い合わせる（ステップS702）。この時、更にメッセージ解析部103にステップS701で生成したCall-IDを通知する。ステップS702で、振分先SIPサーバに着信側UAのRegisterエントリが存在しないと判断された場合には、着信側UAのRegisterエントリを格納するSIPサーバを算出する（ステップS703）。なお、振分先SIPサーバに着信側UAのRegisterエントリが存在するか否かの判断は、例えば、下記の手段により実現できる。

ステップS702においてメッセージ解析部103に送信したCall-IDを持つ、メッセージ解析部103から送信されてきたSIP応答が200 OKである場合には、該当SIPサーバでのRegisterエントリの検索が成功しているため、振分先SIPサーバに着信側UAのRegisterエントリが存在すると判断できる。逆に、SIP応答が200 OK以外の場合には、振分先SIPサーバにRegisterエントリが存在しないと判断できる。

更に、着信側UAのRegisterエントリを格納したSIPサーバの算出は、前述したREGISTERリクエストの振分先SIPサーバの算出と同様の手段を使用し、この手段への入力を、振分先決定部101から渡されたAoRとすることで実現できる。

ステップS703で算出された、着信側UAのRegisterエントリを格納するSIPサーバから着信側UAのRegisterエントリを取得する（ステップS704）。なお、この処理は、例えば、以下の手段で実現できる。着信側UAを格納するSIPサーバに送信するREGISTERリクエストは、ステップ701でのREGISTERリクエスト生成と同様の手段で作成する。この生成したREGISTERリクエストと、ステップS703で算出した着信側UAのRegisterエントリを保持するSIPサーバの識別子を、メッセージ送受信部104に転送する。なお、このステップS704の場合も、ステップS702と同様に、メッセージ解析部103に対して、ステップS704で生成したCall-IDを通知しておく。

ステップS704で取得した、着信側UAのRegisterエントリを、振分先SIPサーバに登録する（ステップS705）。この処理は、例えば、以下の手段で実現可能である。ステップS701と同様に、REGISTERリクエストにおける、FromヘッダとToヘッダには、振分先決定部101から送信されたAoRを挿入し、Call-IDは「ランダムとなる文字列@負荷分散装置LB1のIPアドレス」とし、CSeqヘッダは「1 REGISTER」とする。更に、contactヘッダには、ステップS704で取得したRegisterエントリのcontactヘッダを挿入する。その後、このREGISTERリクエストを、振分先SIPサーバを送信先として、メッセージ送受信部104に送信する。

ステップS702で、着信側UAのRegisterエントリを問い合わせた結果、振分先決定部101から送信されたSIPサーバに、着信側UAのRegisterエントリが存在する場合、または、ステップS705の結果、着信側SIPサーバにRegisterエントリを格納した場合には、処理を終了する。

図8は、メッセージ送受信部104の処理を示すフローチャートである。いま、メッセージ送受信部104がメッセージを受信したとする。メッセージ送受信部104は、メッセージの送信元を調査する（ステップS801）。この処理は、例えば、関数呼び出しでメッセージ送受信部104が呼び出された場合には、負荷分散装置内からのメッセージと判断し、SIPネットワークを介してメッセージ送受信部104が呼び出された場合には、負荷分散装置外からのメッセージとして判断することで実現できる。

ステップS801の調査で、負荷分散装置内からのメッセージ受信と判断した場合には、指定されたあて先に、受信したメッセージを送付する（ステップS802）。ステップS801の調査で、負荷分散装置外からのメッセージ受信と判断した場合には、メッセージ解析部103に、受信したメッセージを送付する（ステップS803）。

以上のように、本発明の第1の実施形態に係る負荷分散装置LB1では、負荷分散装置LB1が、INVITEリクエストを転送する前に、着信側UAのRegisterエントリが振分先SIPサーバに存在するか否かを確認し、存在しない場合には、着信側UAのRegisterエントリを振分先SIPサーバに格納した上で、振分先SIPサーバにINVITEリクエストを転送する。このため、従来技術とは異なり、負荷分散装置とSIPサーバ間でSIP要求のピンポン現象が発生することはない。

図9は、本発明の第2の実施形態に係る負荷分散装置LB2を示す。本実施形態に係る負荷分散装置LB2では、第1の実施形態に係る負荷分散装置LB1に、SIP要求再送部901が追加されている。SIP要求再送部901は、振分先決定部101が決定した振分先SIPサーバにINVITEリクエストを再送する機能と、振分先SIPサーバに、最初に転送したINVITEリクエストの処理を終了させるSIP応答を転送する機能と、Registerエントリ格納部102に、振分先決定部101が決定した振分先SIPサーバへ着信側UAのRegisterエントリを格納させる要求を送信する機能とを有する。

メッセージ解析部103は、第1の実施形態に係る負荷分散装置LB1のメッセージ解析部103が有する機能に加えて、INVITEリクエストの振り分け時に参照する、振分先決定部101から通知されたCall-IDを格納する機能と、格納されたCall-IDに該当するINVITEリクエストを受信した場合には、SIP要求再送部901に転送する機能と、振分先決定部101からのCall-IDの削除依頼に基づき、該当Call-IDを削除する機能とを有する。

振分先決定部101は、第1の実施形態に係る負荷分散装置LB1の振分先決定部101が有する機能に加えて、INVITEリクエストの振分先を決定した時点で、INVITEリクエストに格納されたCall-IDをメッセージ解析部103に通知する機能と、BYEリクエストの受信後、振分情報を更新する時点で、BYEリクエストに格納されているCall-IDを削除するよう、メッセージ解析部103に依頼する機能とを有する。その他の構成要素に関しては、第1の実施形態に係る負荷分散装置LB1における、対応する構成要素と同様の機能を有する。

次に、本実施形態に係る負荷分散装置LB2の処理を、フローチャートを参照して説明する。図10は、本実施形態に係る負荷分散装置LB2における、メッセージ解析部103の処理を示すフローチャートである。図10で示される処理は、図2で示された第1の実施形態に係る負荷分散装置LB1におけるメッセージ解析部103のステップS201〜S205と同様なステップS1001〜S1004、S1006に加えて、ステップS1005およびステップS1007およびステップS1008を有する。そのため、ここでは、主としてステップS1005およびステップS1007およびステップS1008についての説明を行う。

いま、メッセージ解析部103がメッセージ送受信部104からメッセージを受信し、かつ、ステップS1001において受信メッセージの種類を検査した結果、SIP要求であったとする。メッセージ解析部103は、受信したSIP要求が、着信側UAのRegisterエントリの存在するSIPサーバへINVITEリクエストを転送するために、振分先SIPサーバから転送されてきたINVITEリクエスト（以降、着信側INVITEリクエストと呼ぶ）か否かを調査する（ステップS1005）。この処理は、例えば、下記の手段により実現可能である。

振分先決定部101が振分先SIPサーバにINVITEリクエストを送付する際に、INVITEリクエストが持つCall-IDをメッセージ解析部103に通知しておく。メッセージ解析部103では、INVITEリクエストを受信した場合には、このCall-IDを参照して、Call-IDが存在する場合には、着信側INVITEリクエストと判断する。

ステップS1005で、着信側INVITEリクエストと判定された場合には、受信メッセージをSIP要求再送部901に転送する（ステップS1007）。ステップS1005で、着信側INVITEリクエストでないと判定された場合には、受信メッセージを振分先決定部101に転送する（ステップS1006）。ステップS1001の検査で、受信メッセージの種類が、振分先決定部101からのCall-ID更新依頼であると判定された場合には、メッセージ解析部103が保持するCall-IDを更新する（ステップS1008）。例えば、Call-IDがリスト形式で格納されている場合には、Call-IDの追加依頼であれば、該当Call-IDをリストに追加する。また、Call-IDの削除依頼の場合には、リストに格納されている該当するCall-IDを削除する。なお、その他のステップに関しては、図2において説明したフローチャートと同様である。

次に、SIP要求再送部901の処理を、フローチャートを参照して説明する。SIP要求再送部901の処理を示すフローチャートを図11に示す。いま、メッセージ解析部103から、着信側INVITEリクエストを受信したとする。SIP要求再送部901は、Registerエントリ格納部102に、振分先SIPサーバに着信側UAのRegisterエントリを格納するよう依頼する（ステップ1101）。この処理は、例えば、以下のように実現することができる。つまり、振分先SIPサーバは、着信側INVITEリクエストのViaヘッダのSIPサーバのIPアドレスを抽出し、着信側UAのAoRとしてはToヘッダに格納されているAoRを抽出する。これらをRegisterエントリ格納部102に通知することで実現できる。

次に、着信側INVITEリクエストを整形する（ステップS1102）。例えば、この処理には、着信側INVITEリクエストに格納されているViaヘッダを削除する、CSeqヘッダを初期化（例えば、「1 INVITE」を挿入）する、などが挙げられる。次に、振分先SIPサーバに最初に転送したINVITEリクエストの処理を終了するために、振分先SIPサーバに、例えば、200 OKなどのSIP応答を転送する（ステップS1103）。

その後、ステップS1102で整形した着信側INVITEリクエストを、振分先SIPサーバに転送するよう、メッセージ送受信部104に依頼する（ステップS1104）。同時に、メッセージ解析部103が格納していたCall-IDの削除を依頼する。

次に、振分先決定部101の処理をフローチャートを参照して説明する。図12は、振分先決定部101の処理を示すフローチャートである。この図12で示される処理と、図3で示した第1の実施形態に係る負荷分散装置LB1の振分先決定部101の処理との差異は、本実施形態では、図3におけるステップS303に相当するステップが省略されていること、ステップS1204においてCall-IDの追加をメッセージ解析部103に通知する処理と、ステップS1210においてCall-IDの削除をメッセージ解析部103に通知する処理とが追加されていることである。そのため、ここでは、新たに追加された処理（ステップS1204とステップS1210）について説明する。

いま、ステップS1203で、INVITEリクエストの振分先SIPサーバが決定されたとする。振分先決定部101は、INVITEリクエストが有するCall-IDを追加するよう、メッセージ解析部103に依頼する（ステップS1204）。また、ステップ1209で、受信したSIP要求がBYEリクエストであると判明した場合には、BYEリクエストが有するCall-IDを削除するよう、メッセージ解析部103に依頼する（ステップS1210）。

上記のように、第2の実施形態に係る負荷分散装置LB2では、着信側INVITEリクエストの受信を、着信側UAのRegisterエントリを振分先SIPサーバへ格納するトリガーとし、着信側INVITEリクエストを振分先SIPサーバから受信した場合にのみ、着信側UAのRegisterエントリを、該当Registerエントリが格納されているSIPサーバから取得し、振分先SIPサーバに格納し、再度INVITEリクエストを送信する。そのため、振分先SIPサーバに、着信側UAのRegisterエントリが存在する場合には、負荷分散装置LB2からの、着信側UAのRegisterエントリを確認するREGISTERリクエストの発行が不要となるため、第1の実施形態に係る負荷分散装置LB1と比較して、負荷分散装置LB2とSIPサーバ間の通信回数の削減が可能となる。

図13は、本発明の第3の実施形態に係る負荷分散装置LB3の構成を示すブロック図である。図13で示される本実施形態に係る負荷分散装置LB3の構成と、図9で示された第2の実施形態に係る負荷分散装置LB2の構成との差異は、本実施形態では、Registerエントリ格納部102が省略されていることである。

SIP要求再送部901は、INVITEリクエストのToヘッダに格納されたAoRにより、着信側UAのRegisterエントリを格納するSIPサーバを特定する機能と、該当SIPサーバにINVITEリクエストを転送する機能とを有する。その他の構成要素は、第2の実施形態に係る負荷分散装置LB2の対応する構成要素と同様の機能を有する。

図14は、第3の実施形態に係る負荷分散装置LB3における、SIP要求再送部901の処理を示すフローチャートである。いま、メッセージ解析部103からINVITEリクエストを受信したとする。この時、SIP要求再送部901は、着信側UAのRegisterエントリが格納されているSIPサーバを特定する（ステップS1401）。この時の処理は、例えば、下記に示す手段で実現可能である。

INVITEリクエストのToヘッダに格納されているAoRを抽出し、このAoRを、第1の実施形態に係る負荷分散装置LB1の振分先決定部101の処理で説明した、SIP要求のToヘッダに格納されたAoRから、該当AoRに関するRegisterエントリが格納されたSIPサーバを特定する処理（ステップS303）に渡すことで実現できる。

ステップS1401で算出された、着信側UAのRegisterエントリが格納されたSIPサーバに対して、メッセージ解析部103から受信したINVITEリクエストを転送するよう、メッセージ送受信部104に通知する（ステップS1402）。第3の実施形態に係る負荷分散装置LB3における他の構成要素の処理は、第2の実施形態に係る負荷分散装置LB2における、対応する構成要素と同様の処理となる。

上記のように、第3の実施形態に係る負荷分散装置LB3では、着信側UAのRegisterエントリが、INVITEリクエストの振分先SIPサーバに存在しない場合には、着信側UAのRegisterエントリを格納するSIPサーバに着信側INVITEリクエストを、負荷分散装置LB3が転送する（仲介する）。このため、負荷分散装置LB3から、全くREGISTERリクエストを発行する必要がないため、第１又は第2の実施形態と比較して、負荷分散装置LB3とSIPサーバ間の通信回数の削減が可能となる。

図15は、本発明の第4の実施形態に係る負荷分散装置LB4の構成を示すブロック図である。第4の実施形態に係る負荷分散装置LB4の構成は、第3の実施形態に係る負荷分散装置LB3の構成における、SIP要求再送部901がSIPサーバに格納され、SIPサーバに着信側UAのRegisterエントリが存在しない場合には、SIP要求再送部901が、INVITEリクエストを、着信側UAのRegisterエントリを格納するSIPサーバに直接転送する形態となっている。

振分先決定部101は、第1の実施形態に係る負荷分散装置LB1における振分先決定部101が有する機能のうち、着信側UAのRegisterエントリを振り分け対象となるSIPサーバに格納するよう、Registerエントリ格納部102に依頼する機能を有せず、それ以外の機能を有する。メッセージ解析部103は、第1の実施形態に係る負荷分散装置LB1におけるメッセージ解析部103が有する機能のうち、負荷分散装置LB1から送信したSIP要求に対するSIP応答をRegisterエントリ格納部102に送信する機能は有せず、それ以外の機能を有する。なお、メッセージ送受信部104およびSIP要求再送部901は、第3の実施形態に係る負荷分散装置LB3における対応する構成要素と同様の機能を有する。

図16は、第4の実施形態に係る負荷分散装置LB4における、振分先決定部101の処理を示すフローチャートである。このフローチャートは、第3の実施形態に係る負荷分散装置LB3における、振分先決定部101の処理を示すフローチャート（図12）に示したステップS1204及びステップS1210に対応するステップとがない点で異なり、他のステップに関しては、図12で示した各ステップと同様である。

図17は、第4の実施形態に係る負荷分散装置LB4における、メッセージ解析部103の処理を示すフローチャートである。いま、メッセージ解析部103が、メッセージ送受信部104から、UAまたはSIPサーバから受信したメッセージを受信したとする。この時、メッセージ解析部103は、受信したメッセージの種類を検査する（ステップS1701）。ステップ1701の結果、受信したメッセージが、例えば、INVITEやREGISTERなどのSIP要求の場合には、受信メッセージを振分先決定部101に転送する（ステップS1702）。

一方、ステップS1701で受信したメッセージが、例えば、180 Ringingや200 OKの場合には、受信メッセージをメッセージ送受信部104に転送する（ステップS1703）。メッセージ送受信部104およびSIP要求再送部901の処理は、第3の実施形態に係る負荷分散装置LB3における、メッセージ送受信部104およびSIP要求再送部901と同様の処理である。なお、SIP要求再送部901によるINVITEリクエストは、SIPサーバが保持するネットワークインターフェイスを使用して、着信側UAのRegisterエントリを格納するSIPサーバに直接転送される。

上記のように、第4の実施形態に係る負荷分散装置LB4では、着信側UAのRegisterエントリが振分先SIPサーバに存在しない場合には、着信側UAのRegisterエントリを格納するSIPサーバに、振分先SIPサーバから着信側INVITEリクエストを直接転送する構成を採用する。このため、負荷分散装置LB4からは、振分先決定部101で選定した振分先SIPサーバにINVITEリクエストを最初に転送するのみで良い。この結果、第3の実施形態に係る負荷分散装置LB3と比較して、負荷分散装置LB4とSIPサーバ間の通信回数の削減が可能となる。

以降の本発明の実施形態に係る負荷分散装置は、現在通信キャリアが一般的に採用しているTTC（the telecommunication technology committee）仕様書に基づいて通信網を運用する場合に関するものである。このTTC仕様適用下での最大の特徴の一つは、TTC仕様書TS-1006（事業者SIP網に接続するSIP端末基本接続インターフェイス技術仕様）に記載があるように、UAの認証機能がSIPサーバでのREGISTERリクエストおよびINVITEリクエストの処理時に含まれるということである。

TTC仕様書に記載された事業者SIP網に存在するSIPサーバでは、本発明の第1〜第4の実施形態に係るSIPサーバが有する機能に加えて、UA認証機能と、UA認証に必要な情報を管理する機能とを有することになる。例えば、このUA認証に必要な情報には、ユーザ識別子とパスワードとの組であるシークレットと呼ばれるものがある。なお、このUA認証に必要な情報は、当該UAのRegisterエントリと同一のSIPサーバに格納される。

次に、上記UA認証機能について説明する。なお、ここでは、INVITEリクエストを例として説明する。図23は、INVITEリクエスト処理での認証処理を示す処理シーケンスである。まず、UAから、SIPサーバに対してINVITEリクエストが送信される（ステップS2301）。UAからのINVITEリクエストを受信したSIPサーバはnonceを算出する（ステップS2302）。ここで、nonceとは、SIPサーバが認証処理毎に一意に生成する文字列である。なお、この文字列は一般的に base64 あるいは 16 進データであることが推奨されている。

nonceの算出後、SIPサーバは、nonceが含まれたSIP応答をUAに返す（ステップS2303）。具体的には、SIP応答として407（proxy authentication required）が返される。ちなみに、REGISTERリクエストの場合には、SIP応答として401（unauthorized）が返される。

SIP応答を受信したUAは、SIP応答に格納されたnonceを鍵にシークレット（ユーザIDとパスワード）を暗号化する（ステップS2304）。一般的に、この暗号化アルゴリズムには、MD5が使用される。次に、UAは、暗号化されたシークレットを付加したINVITEリクエストを再度SIPサーバに転送する（ステップS2305）。ステップS2305で、暗号化されたシークレットを含んだINVITEリクエストを受信したSIPサーバはUAの認証処理に入る（ステップS2306）。具体的には、以下の2段階となる。まず、ステップS2302で算出したnonceと、SIPサーバが保持する当該UAのシークレットを使用して、当該UAでのステップS2304と同様に、シークレットを暗号化する。その後、ステップS2305で受信した、UAから送信された暗号化されたシークレットと比較する。この結果、暗号化された双方のシークレットが一致した場合には、第3者によるなりすましがなく、正当なUAから送信されたINVITEリクエストであると判別され（ステップＳ２３０６）、SIPサーバは、INVITEリクエスト処理後SIP応答（200 OK）を送信する（ステップS2307）。

上記の認証処理には、下記の2点の特徴がある。第１の特徴は、最初にUAから送信されるINVITEリクエスト（図23のステップS2301）には、アドレス以外には、UAを識別する情報を含める必要がないことである。これは、実際のUA認証は、ステップS2305で送信されるINVITEリクエストに含まれる、暗号化されたシークレットにより実施されるためである。例えば、TTC仕様書では、ステップ２３０１でのINVITEリクエストにおいて、特に、電話番号非通知時では、INVITEリクエストのFromヘッダには自由な文字列が挿入可能など、発信側UAを示す情報が通常格納されるヘッダに情報を埋める必要がないことが記載されている。

次に、第２の特徴は、最初にUAから送信されるINVITEリクエスト（ステップS2301）と2回目にUAから送信されるINVITEリクエスト（ステップS2305）とは、同一のSIPサーバに転送されなければならないことである。これは、ステップS2301で転送されたINVITEリクエストが引き金となり、nonceを計算し、それを使用して、2回目のINVITEリクエスト処理時に、UA認証を行うためである。

しかしながら、本発明が想定している、Registerエントリが分散配置されたSIPサーバ群では、同一SIPサーバにRegisterエントリとシークレット（ユーザIDとパスワード）とが共に分散配置されている。そのため、発信側UAから送信されてくる最初のINVITEリクエストのヘッダには、上記第1の特徴で示したように、発信側UAを識別する情報がアドレス以外には格納されていないにも拘わらず、発信側UAのシークレットとRegisterエントリとが存在するSIPサーバに当該INVITEリクエストを転送する必要がある。つまり、上記第2の特徴で示したように、最初のINVITEリクエストを適切なSIPサーバに転送しなかった場合には、図23のシーケンスに則り2回目のINVITEリクエストも同一SIPサーバに転送されることになるため、発信側UAが正しく認証されない状況が発生するのである。TTC仕様適用下では、上記問題を解決する課題が、本発明の第1〜第4の実施形態で解決した課題に加えて、新たに発生する。

上記課題を解決するために、本発明の第5の実施形態に係る負荷分散装置LB5では以下の手段をとっている。つまり、REGISTERリクエストをSIPサーバに振り分ける際に、電話番号規則に基づいて、ＵＡのアドレスと振り分け先となるSIPサーバの識別子の組を格納しておく。この状態で、INVITEリクエストを当該UAが送信してきた場合には、上記のアドレスと識別子の組を使用して、REGISTERリクエストを転送したSIPサーバと同一のSIPサーバに転送する。例えば、上記UAのアドレスとSIPサーバの識別子の組はIPアドレスである。その結果、UAのRegisterエントリとシークレットが存在するSIPサーバにINVITEリクエストを適切に振り分けることが可能となるのである。

図19は、第5の実施形態に係る負荷分散装置LB5の構成を示すブロック図である。第5の実施形態に係る負荷分散装置LB5は、振分先決定部101と、メッセージ振分部1901と、メッセージ送受信部104とから構成されている。振分先決定部101は、電話番号規則によりSIP要求の転送先となるSIPサーバを決定する機能と、発信側ＵＡのアドレスにより振分情報からSIP要求の転送先となるSIPサーバを決定する機能と、SIP要求に格納されたCall-IDによりSIP要求の振分先となるSIPサーバを決定する機能と、メッセージ振分部1901から受信したSIP要求の種類と送信元を解析する機能と、発信側UAのアドレスと転送先SIPサーバの識別子、SIP要求に含まれるCall-IDとの対応表を管理する機能とを有する。

ここで、振分情報は、第1〜第4の実施形態に係る負荷分散装置LB1〜LB4における振分情報に相当し、内容としては、例えば、送信元ＵＡのアドレスと振分先SIPサーバの識別子、SIP要求に含まれるCall-IDとの対応情報である。更に、電話番号規則とは、例えば、電話番号の下1桁の番号ごとに格納するSIPサーバを決定する、または、第1の実施形態において、振分先決定部101がREGISTERリクエストの振り分けで使用するように、電話番号を正整数に変換し、振り分け対象となるSIPサーバの数で除した余りで表現されるSIPサーバを振り分け対象とする、である。

また、メッセージ振分部1901は、メッセージ送受信部104から受信したメッセージの種類と宛先を調査してメッセージ送受信部104または振分先決定部101にメッセージを転送する機能を有する。なお、第5の実施形態に係る負荷分散装置LB5を構成するメッセージ送受信部104に関しては、第1の実施形態に係る負荷分散装置LB1におけるメッセージ送受信部104と同様の機能を有する。

図20は、第5の実施形態に係る負荷分散装置LB1における、メッセージ振分部1901の処理を示すフローチャートである。いま、メッセージ振分部1901が、メッセージ送受信部104からメッセージを受信したとする。次に、メッセージ振分部1901は、受信メッセージの種類を検査する（ステップS2001）。ステップS2001で、受信メッセージの種類がSIP要求であると判定された場合には、更に、SIP要求が自分宛に送信されたものか否かを検査する（ステップS2002）。この処理は、例えば、下記の手段により実現可能である。

TTC仕様では、INVITEリクエストの引数として与えられるRequest-URIは、「"sip:"user"@"host[:port][uri-parameters]」との構成をとることが規定されている。更に、host部には、一般的にSIPプロキシ・サーバ名を用いることが想定されている。第5の実施形態に係る負荷分散装置LB5では、発信側UAがINVITEリクエストをSIPサーバに宛てて発行する場合と、振分先SIPサーバが着信側UAのRegisterエントリが格納されたSIPサーバにINVITEリクエストを転送する場合とがあり、このINVITEリクエストのhost部には、負荷分散装置LB5のIPアドレスが指定される。そのため、このhost部に格納された負荷分散装置のIPアドレスから、自身宛に送信されたINVITEリクエストと判別できる。

ステップS2002で、SIP要求が自分宛のものと判別された場合には、受信メッセージを振分先決定部101に転送する。ステップS2001で、受信メッセージがSIP応答であった場合、または、ステップS2002の結果、SIP要求が自分宛のものでないと判別された場合には、受信メッセージをメッセージ送受信部104に転送する（ステップS2004）。

図21に、振分先決定部101の処理を示すフローチャートを示す。いま、メッセージ振分部1901から、自身宛のSIP要求と判断されたメッセージを受信したとする。すると、振分先決定部101は、SIP要求種別を検査する（ステップS2101）。ステップS2101で、受信したSIP要求がREGISTERリクエストであると判定された場合には、電話番号規則に従って振分先SIPサーバを決定する（ステップS2102）。この処理は、例えば、以下の方式で実現できる。

電話番号規則が、電話番号の下1桁の番号ごとに格納するSIPサーバを決定している場合には、REGISTERリクエストのFromヘッダの値（「電話番号@SIPサーバのIPアドレス」）から、電話番号を抽出し、下1桁の番号に応じて、Registerエントリが格納されるSIPサーバを決定する。また、他の例として、電話番号規則が、電話番号を正整数に変換し、振り分け対象となるSIPサーバの数で除した余りで表現されるSIPサーバを振り分け対象とする場合には、上記例と同様にFromヘッダ値から電話番号を抽出し、その電話番号を上記処理の入力とすることで、Registerエントリが格納されるSIPサーバを決定する。

ステップS2101で、受信したSIP要求がINVITEリクエストであると判定された場合には、更に、INVITEリクエストの送信元を調査する（ステップS2103）。ステップS2103で、送信元がUAと判定された場合には、ＵＡのアドレスを基に振分情報から振分先SIPサーバを決定する（ステップS2104）。この処理は、例えば、以下の手段により実現できる。

振分情報は、例えば、図22に示すような表形式となる。この表では、発信側UAと振分先SIPサーバを表す識別子としてIPアドレスを使用している。振分情報が、図22に示した表形式の場合には、発信側IPアドレス列を発信側UAのIPアドレスをキーとして検索し、該当行の振分先SIPサーバのIPアドレスを検出する。

ステップS2101で、受信したSIP要求がREGISTERおよびINVITEリクエスト以外のものであった場合には、SIP要求に格納されたCall-IDヘッダの値を基に、振分情報から振分先SIPサーバを決定する（ステップS2105）。この処理は、例えば、以下の手段により実現できる。

振分情報が、例えば、図22に示した表形式の場合には、Call-ID列を、受信したSIP要求のCall-IDヘッダに格納された値をキーとして検索し、該当行の振分先SIPサーバのIPアドレスを検出するのである。

ステップS2105で、Call-IDを基に振分先SIPサーバが決定された場合には、更に、受信したSIP要求がBYEリクエストかを調査する（ステップS2106）。ステップS2102で、電話番号規則を元に振分先SIPサーバを決定した場合、または、ステップS2104で、発信側ＵＡのアドレスを元に振分先SIPサーバを決定した場合、または、ステップS2106で、受信したSIP要求がBYEリクエストである場合には、振分情報の更新を行う（ステップS2107）。この処理は、例えば、振分情報が、図22で示される形式の場合には、下記の手段により実現できる。

SIP要求がREGISTERリクエストである場合には、まず、振分情報に発信側UAのIPアドレスとステップS2102の結果決定した振分先SIPサーバのIPアドレスを含む行が存在するかを調査する。調査の結果、存在する場合には処理を行わない。一方、調査の結果、存在しない場合には、ステップS2102で決定した振分先SIPサーバのIPアドレスと発信側UAのIPアドレスを含む行を新規に挿入する。

SIP要求がINVITEリクエストである場合には、INVITEリクエストの発信側UAのIPアドレスをキーとして、振分情報の発信側UAのIPアドレスで示される行を検索する。次に、その行におけるCall-ID欄に、受信したINVITEリクエストのCall-IDヘッダに格納された値を格納する。また、SIP要求がBYEリクエストである場合には、BYEリクエストの発信側UAのIPアドレスをキーとして、振分情報の発信側UAのIPアドレスで示される行を検索する。次に、その行における、Call-ID欄に格納されている値を消去する。

ステップS2103で、INVITEリクエストの送信元がSIPサーバであった場合には、電話番号規則を基に、着信側UAのRegisterエントリを格納するSIPサーバを決定する（ステップS2108）。この処理は、例えば、下記の手段で実現できる。

TTC仕様では、INVITEリクエストのToヘッダには「着信側UAの電話番号@SIPサーバのIPアドレス」なる値が格納されている。このToヘッダから、着信側UAの電話番号を抽出し、電話番号規則に適用することで、該当電話番号のUAに関するRegisterエントリを格納するSIPサーバが決定できる。

ステップS2107で、振分情報の更新が完了した場合、または、ステップS2106で、受信したSIP要求がBYEリクエストでない場合、または、ステップS2108で、INVITEリクエストの転送先となるSIPサーバを決定した場合には、ステップS2102またはステップS2104またはステップS2105またはステップS2108で決定したSIPサーバに、受信したSIP要求を転送するよう、メッセージ送受信部104へ転送する（ステップS2109）。

なお、第5の実施形態に係る負荷分散装置LB5におけるメッセージ送受信部104の処理に関しては、第1の実施形態に係る負荷分散装置LB1におけるメッセージ送受信部104と同様の処理となる。

第5の実施形態に係る負荷分散装置LB5における効果は以下のようになる。TTC仕様適用下のように、複数のSIPサーバにRegisterエントリおよびシークレット（ユーザIDとパスワード）が分散配置され、かつ、認証処理がSIP要求処理時に実行される環境下においても、発信側UAに関するRegisterエントリおよびシークレットが存在するSIPサーバへSIP要求を適切に転送することが可能となることがあげられる。この理由は、REGISTERリクエストを電話番号規則に基づいて、SIPサーバに振り分ける際に、発信側ＵＡのアドレスと振り分けたSIPサーバの識別子の組を第5の実施形態に係る負荷分散装置LB1が格納しておき、該当UAがINVITEリクエストを送信してきた場合には、上記組を使用して、REGISTERリクエストを転送したSIPサーバと同一のSIPサーバに転送することで、Registerエントリおよびシークレットが存在するSIPサーバに適切に振り分けることができるためである。

上記実施形態に係る負荷分散装置は以下の効果を奏する。第1の効果は、Registerエントリが分散配置された環境（専有モデル）でも、INVITEリクエストを、負荷分散装置とSIPサーバ間でのピンポン現象を引き起こすことなく、振り分けられることである。これは、負荷分散装置LB1が、INVITEリクエストを転送する前に、着信側UAのRegisterエントリが振分先SIPサーバに存在するか確認し、存在しない場合には、着信側UAのRegisterエントリを振分先SIPサーバに格納することで、振分先SIPサーバには、INVITEリクエスト受信時には必ず着信側UAのRegisterエントリが存在するためである。

第2の効果は、常に最少負荷量のSIPサーバにINVITEリクエストを転送することが可能なことである。これは、SIPサーバごとのダイアログの処理数を負荷量として負荷分散装置が把握しており、負荷量の昇順にSIPサーバの識別子を並べているためである。この結果、常に先頭のSIPサーバの識別子を選択することで、常時最少負荷量のSIPサーバを選択することが可能となる。

第3の効果は、同一コールフロー内のSIP要求は、同一のSIPサーバに転送可能なことである。これは、INVITEリクエスト転送時に、INVITEリクエストに格納されているCall-IDと振分先SIPサーバの識別子を組みとしてハッシュ表に格納することで、同一Call-IDを持つSIP要求は同一SIPサーバに転送することが可能となるのである。

第4の効果は、Registerエントリを格納したSIPサーバの特定を高速に行えることである。これは、REGISTERリクエストを振り分けるSIPサーバの識別子を、REGISTERエントリのFromヘッダに格納されているAoRから算術演算により求める方法としたためである。この結果、同一のAoRに関しては、いつでも高速に同一結果（SIPサーバ識別子）を得ることが可能となるのである。

以上、本発明をその好適な実施態様に基づいて説明したが、本発明の負荷分散装置は、上記実施態様の構成にのみ限定されるものではなく、上記実施態様の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。また、本発明の好適な態様として記載した各構成や実施形態で記載した各構成については、本発明の必須の構成と共に用いることが好ましいが、単独であっても有益な効果を奏する構成については、必ずしも本発明の必須の構成として説明した全ての構成と共に用いる必要はない。

本発明の負荷分散装置は、複数のユーザ端末及び複数のＳＩＰサーバを有するＳＩＰネットワークに利用できる。

本発明の第1の実施形態に係る負荷分散装置の構成を示すブロック図である。 第1の実施形態に係る負荷分散装置における、メッセージ解析部の処理を示すフローチャートである。 第1の実施形態に係る負荷分散装置における、振分先決定部の処理を示すフローチャートである。 第1の実施形態に係る負荷分散装置における、振分先決定部が保持する、最少負荷SIPサーバ検索情報の例である。 最少負荷SIPサーバ検索情報の更新手順に関して、処理数増加時処理を示すフローチャートである。 最少負荷SIPサーバ検索情報の更新手順に関して、処理数減少時処理を示すフローチャートである。 第1の実施形態に係る負荷分散装置における、Registerエントリ格納部の処理を示すフローチャートである。 第1の実施形態に係る負荷分散装置における、メッセージ送受信部の処理を示すフローチャートである。 本発明の第2の実施形態に係る負荷分散装置の構成を示すブロック図である。 第2の実施形態に係る負荷分散装置における、メッセージ解析部の処理を示すフローチャートである。 第2の実施形態に係る負荷分散装置における、SIP要求再送部の処理を示すフローチャートである。 第2の実施形態に係る負荷分散装置における、振分先決定部の処理を示すフローチャートである。 本発明の第3の実施形態に係る負荷分散装置の構成を示すブロック図である。 第3の実施形態に係る負荷分散装置における、SIP要求再送信の処理を示すフローチャートである。 本発明の第4の実施形態に係る負荷分散装置の構成を示すブロック図である。 第4の実施形態に係る負荷分散装置における、振分先決定部の処理を示すフローチャートである。 第4の実施形態に係る負荷分散装置における、メッセージ解析部の処理を示すフローチャートである。 従来技術を分散モデルに適用した場合の処理を示す図である。 本発明の第5の実施形態に係る負荷分散装置の構成を表すブロック図である。 本発明の第5の実施形態に係る負荷分散装置における、メッセージ振分部の動作を示すフローチャートである。 本発明の第5の実施形態に係る負荷分散装置における、振分先決定部の動作を示すフローチャートである。 本発明の第5の実施形態に係る負荷分散装置における、振分情報の例である。 一般的なINVITEリクエスト発行時における、認証処理を示すシーケンスである。

符号の説明

LB1〜LB5 負荷分散装置
101：振分先決定部
102：Registerエントリ格納部
103：メッセージ解析部
104：メッセージ送受信部
901：SIP要求再送部
1901：メッセージ振分部
T1、T2：ユーザ・エージェント(UA)
SS1、SS2：SIPサーバ

Claims (25)

1. ネットワークを介して通信を行う複数のユーザ端末と、それぞれが前記通信を仲介する機能及びユーザ端末の位置情報登録機能を有する複数のサーバとにネットワークを介して接続され、少なくとも通信の仲介を処理すべきサーバを選定することによってサーバの負荷を分散させる負荷分散装置において、
   ネットワークから受信したメッセージを検査して、発信側のユーザ端末が発行した呼接続要求メッセージを検出するメッセージ解析部と、
   前記検出した呼接続要求メッセージを処理すべきサーバを所定のアルゴリズムに従って選定し、該選定したサーバに前記呼接続要求メッセージを転送するサーバ振分部と、
   前記呼接続要求メッセージの着信側ユーザ端末のアドレスを検索キーとして、ユーザ端末のアドレスとユーザ端末の位置情報登録を有するサーバとを対応付けて記憶する記憶装置を検索し、前記着信側ユーザ端末の位置情報登録を有するサーバを特定する登録情報取得部とを備えることを特徴とする負荷分散装置。
2. 前記所定のアルゴリズムは、前記呼接続要求メッセージに含まれる所定のヘッダ情報を検索キーとし、各サーバの識別子を選定対象となるサーバの数未満の正の整数として、前記検索キーを正の整数に変換し、前記選定対象となるサーバの数で該変換された正の整数を除した余りで識別されるサーバを前記選定されるサーバとする、請求項１に記載の負荷分散装置。
3. 前記所定のアルゴリズムは、
   処理数配列と、振分順リストとを利用して、接続中のダイアログの数が最小のサーバを選択するためのアルゴリズムであり、
   前記処理数配列は、各サーバの識別子と該各サーバが現在処理している処理数とを対応付けたエントリを持ち、各エントリが前記処理数配列の対応するエントリに向けたポインタを持ち、
   前記処理数配列は、前記処理数を昇順として前記サーバを配列したエントリを持ち、処理数の増加又は減少によってエントリの配列順が変更され、各エントリが配列内の前エントリ及び次エントリに向けたポインタを持ち、
   前記振分順リストの先頭エントリが示す識別子で識別されるサーバを選択する、請求項２に記載の負荷分散装置。
4. 前記登録情報取得部は、前記選定したサーバが、前記呼接続要求メッセージの宛先の着信側ユーザについて、当該着信側ユーザ端末の位置登録情報を記憶しているか否かを問い合わせ、記憶していない旨を確認した後に、前記着信側ユーザ端末の位置情報登録を有するサーバを検索する、請求項１〜３の何れか一に記載の負荷分散装置。
5. 前記登録情報取得部は、前記着信側ユーザ端末の位置情報登録を有するサーバから前記着信側ユーザ端末の位置情報を取得し、該取得した位置情報を前記選定されたサーバに向けて送信する、請求項１〜４の何れか一に記載の負荷分散装置。
6. 前記メッセージ解析部は、新たに発生した呼接続要求メッセージを検出すると、該検出した呼接続要求メッセージの識別子を記憶し、該識別子を有する呼接続要求メッセージを再び検出すると、該検出をトリガーとして、前記着信側ユーザ端末の位置情報登録を有するサーバから前記着信側ユーザ端末の位置情報を取得する、請求項５に記載の負荷分散装置。
7. 前記メッセージ解析部は、新たに発生した呼接続要求メッセージを検出すると、該検出した呼接続要求メッセージの識別子を記憶し、該識別子を有する呼接続要求メッセージを再び検出すると、該検出した呼接続要求を前記着信側ユーザ端末の位置情報登録を有するサーバに転送する、請求項５に記載の負荷分散装置。
8. 前記登録情報取得部は、前記選択されたサーバに、前記着信側ユーザ端末の位置情報登録を有するサーバの情報を送信し、前記選択されたサーバが該位置登録情報を有するサーバに向けて直接に前記呼接続要求を送信するように要求する、請求項１〜４の何れか一に記載の負荷分散装置。
9. 前記登録情報取得部は、登録を要求するユーザ端末から、少なくとも位置情報を含むユーザ情報の登録を要求するユーザ情報登録要求メッセージを受信すると、該ユーザ端末のアドレス情報から所定のアルゴリズムで前記ユーザ情報を登録するサーバを選択し、該選択したサーバに向けて前記ユーザ情報登録要求を転送し、該選択したサーバにユーザ情報を登録させると共に、該選択したサーバとユーザ端末のアドレスとを対応付けて振分情報として記憶する、請求項１〜８の何れか一に記載の負荷分散装置。
10. 前記サーバ振分部は、呼接続要求が発生すると、前記所定のアルゴリズムによる呼接続要求を処理すべきサーバの選定に先だって、該呼接続要求を発行したユーザ端末のアドレスを検索キーとして、前記振分情報を検索し、前記位置登録情報を有するサーバを特定して、前記呼接続要求を処理すべきサーバとして選定する、請求項９に記載の負荷分散装置。
11. 前記選択されたサーバは、ユーザ端末から呼接続要求を受信すると、該ユーザ端末についてユーザ認証を行う機能を有する、請求項９又は１０に記載の負荷分散装置。
12. 前記ネットワークがSIPネットワークである、請求項１〜１１の何れか一に記載の負荷分散装置。
13. ネットワークを介して通信を行う複数のユーザ端末と、それぞれが前記通信を仲介する機能及びユーザ端末の位置情報登録機能を有する複数のサーバとにネットワークを介して接続されるコンピュータを利用して、少なくとも通信の仲介を処理すべきサーバを選定することによってサーバの負荷を分散させる負荷分散方法において、
    コンピュータが、ネットワークから受信したメッセージを検査して、発信側のユーザ端末が発行した呼接続要求メッセージを検出するステップと、
    コンピュータが、前記検出した呼接続要求メッセージを処理すべきサーバを所定のアルゴリズムに従って選定し、該選定したサーバに前記呼接続要求メッセージを転送するステップと、
    コンピュータが、前記呼接続要求メッセージの着信側ユーザ端末のアドレスを検索キーとして、ユーザ端末のアドレスとユーザ端末の位置情報登録を有するサーバとを対応付けて記憶する記憶装置を検索し、前記着信側ユーザ端末の位置情報登録を有するサーバを特定するステップとを備えることを特徴とする負荷分散方法。
14. 前記所定のアルゴリズムは、前記呼接続要求メッセージに含まれる所定のヘッダ情報を検索キーとし、各サーバの識別子を選定対象となるサーバの数未満の正の整数として、前記検索キーを正の整数に変換し、前記選定対象となるサーバの数で該変換された正の整数を除した余りで識別されるサーバを前記選定されるサーバとする、請求項１３に記載の負荷分散方法。
15. 前記所定のアルゴリズムは、
    処理数配列と、振分順リストとを利用して、接続中のダイアログの数が最小のサーバを選択するためのアルゴリズムであり、
    前記処理数配列は、各サーバの識別子と該各サーバが現在処理している処理数とを対応付けたエントリを持ち、各エントリが前記処理数配列の対応するエントリに向けたポインタを持ち、
    前記処理数配列は、前記処理数を昇順として前記サーバを配列したエントリを持ち、処理数の増加又は減少によってエントリの配列順が変更され、各エントリが配列内の前エントリ及び次エントリに向けたポインタを持ち、
    前記振分順リストの先頭エントリが示す識別子で識別されるサーバを選択する、請求項１４に記載の負荷分散方法。
16. 前記サーバを特定するステップは、前記選定したサーバが、前記呼接続要求メッセージの宛先の着信側ユーザについて、当該着信側ユーザ端末の位置登録情報を記憶しているか否かを問い合わせ、記憶していない旨を確認した後に実行する、請求項１３〜１５の何れか一に記載の負荷分散方法。
17. 前記コンピュータが、前記特定したサーバから前記着信側ユーザ端末の位置情報を取得し、該取得した位置情報を前記選定されたサーバに向けて送信するステップを更に備える、請求項１３〜１６の何れか一に記載の負荷分散方法。
18. 前記コンピュータが、前記呼接続要求検出ステップで、新たに発生した呼接続要求メッセージを検出すると、該検出した呼接続要求メッセージの識別子を記憶するステップと、前記コンピュータが、前記呼接続要求検出ステップで、該識別子を有する呼接続要求メッセージを再び検出すると、該検出をトリガーとして、前記特定したサーバから前記着信側ユーザ端末の位置情報を取得するステップとを更に備える、請求項１７に記載の負荷分散方法。
19. 前記コンピュータが、前記呼接続要求検出ステップで、新たに発生した呼接続要求メッセージを検出すると、該検出した呼接続要求メッセージの識別子を記憶するステップと、前記コンピュータが、前記呼接続要求検出ステップで、該識別子を有する呼接続要求メッセージを再び検出すると、該検出した呼接続要求を前記着信側ユーザ端末の位置情報登録を有するサーバに転送するステップとを更に備える、請求項１７に記載の負荷分散方法。
20. 前記コンピュータが、前記選択されたサーバに、前記着信側ユーザ端末の位置情報登録を有するサーバの情報を送信し、前記選択されたサーバが該位置登録情報を有するサーバに向けて直接に前記呼接続要求を送信するように要求するステップを更に備える、請求項１３〜１６の何れか一に記載の負荷分散方法。
21. 前記コンピュータが、登録を要求するユーザ端末から、少なくとも位置情報を含むユーザ情報の登録を要求するユーザ情報登録要求メッセージを受信するステップと、前記コンピュータが、該ユーザ端末のアドレス情報から所定のアルゴリズムで前記ユーザ情報を登録するサーバを選択するステップと、前記コンピュータが、該選択したサーバに向けて前記ユーザ情報登録要求を転送し、該選択したサーバにユーザ情報を登録させるステップと、前記コンピュータが、該選択したサーバとユーザ端末のアドレスとを対応付けて振分情報として記憶するステップとを更に備える、請求項１３〜２０の何れか一に記載の負荷分散方法。
22. 前記コンピュータが、呼接続要求が発生すると、前記所定のアルゴリズムによる呼接続要求を処理すべきサーバの選定に先だって、該呼接続要求を発行したユーザ端末のアドレスを検索キーとして、前記振分情報を検索し、前記位置登録情報を有するサーバを特定して、前記呼接続要求を処理すべきサーバとして選定するステップを更に備える、請求項２１に記載の負荷分散装置。
23. 前記ネットワークがSIPネットワークである、請求項１３〜２２の何れか一に記載の負荷分散方法。
24. ネットワークを介して通信を行う複数のユーザ端末と、それぞれが前記通信を仲介する機能及びユーザ端末の位置情報登録機能を有する複数のサーバとにネットワークを介して接続され、少なくとも通信の仲介を処理すべきサーバを選定することによってサーバの負荷を分散させるコンピュータのためのプログラムであって、前記コンピュータに、
    ネットワークから受信したメッセージを検査して、発信側のユーザ端末が発行した呼接続要求メッセージを検出する処理と、
    前記検出した呼接続要求メッセージを処理すべきサーバを所定のアルゴリズムに従って選定し、該選定したサーバに前記呼接続要求メッセージを転送する処理と、
    前記呼接続要求メッセージの着信側ユーザ端末のアドレスを検索キーとして、ユーザ端末と該ユーザ端末の位置情報登録を有するサーバとを対応付けて記憶する記憶装置を検索し、前記着信側ユーザ端末の位置情報登録を有するサーバを取得する処理とを実行させることを特徴とするプログラム。
25. 前記ネットワークがSIPネットワークである、請求項２４に記載のプログラム。

Images