JP4241760B2

JP4241760B2 - 負荷分散システム

Info

Publication number: JP4241760B2
Application number: JP2006138431A
Authority: JP
Inventors: 一磨湯本; 恵理川井; 政洋吉澤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-05-18
Filing date: 2006-05-18
Publication date: 2009-03-18
Anticipated expiration: 2025-04-25
Also published as: JP2006309777A

Description

本発明は、セッション制御および管理を行う装置が、受信したメッセージの中継先を決
定する技術に係わり、特に、複数のセッション制御装置に負荷を分散して通信処理を行う
技術に関する。

従来、負荷分散装置は、Webサーバに対するトラフィックを、同じ機能を持った複数台
のWebサーバで分担することにより、膨大なトラフィックに対応させることを目的として
発展してきた。現在では、Webサーバ以外にも、ルータ、メールサーバ、VPNゲートウェイ
など、多様な機器やプロトコルを対象として広げつつ発展してきている。

その中には、SIPサーバを対象とした負荷分散を実現する装置も含まれており、SIP（Se
ssion Initiation Protocol）（非特許文献１参照）固有の仕様を考慮して、同一ダイア
ログのトラフィックを同じサーバに振り分ける機能を備えている。同一ダイアログのトラ
フィックを同じサーバに振り分ける機能（パーシステンス機能）の典型的な方式としては
、SIPヘッダに含まれるCall-Idの値を参照し、この値が同一であるメッセージは同じサー
バに振り分けるという方式が採られている。

また、暗号化通信への対応に関しても、SSL（Secure Socket Layer）を使ったHTTPS（H
ypertext Transfer Protocol Security）による暗号化通信をサポートした装置なども存
在する。
負荷分散装置の実現方法としては、負荷分散装置が振り分け先サーバのアドレスを端末に
通知し、負荷分散装置が指定した振り分け先サーバに端末が再接続することを促す方法が
ある（例えば、特許文献１参照）。

特開2002−334012 RFC 3261

従来の負荷分散装置では、IPパケットのペイロード部分に含まれる情報（例えばSIPメ
ッセージのようなレイヤ７の情報、アプリケーション層の情報）を参照して振分け先を決
定する場合には、一旦負荷分散装置において暗号化通信を終端し、復号化処理を行う必要
がある。
本発明の第一の課題及び目的は、この復号化処理のために、負荷分散装置の処理負荷が増
大して負荷分散の効果が薄れてしまったり、転送遅延が起きてしまうのを防ぐことである
。

従来のリダイレクト通知を利用した負荷分散装置では、振り分け先を端末に通知するス
テップまでしか考慮されていないため、一旦通知した振り分け先を、端末が永久に使い続
けてしまう場合がある。
本発明の第二の課題及び目的は、このように特定の振り分け先に対して長い間処理負荷が
集中し、負荷分散という効果が薄れてしまうことを防ぐことである。

従来のリダイレクト通知を利用した負荷分散装置では、接続または処理のリクエストは
リダイレクト通知に応対する機能を有する端末から送信されることを前提としていたため
、リダイレクト通知に応対する機能を有さないサーバなど（例えば、一般的なSIPプロキ
シサーバ）からのリクエストには対応できない。
本発明の第三の課題及び目的は、このようにリダイレクト通知に応対する機能を有さない
サーバからの接続または処理のリクエストに対応することである。

従来の負荷分散装置では、負荷分散装置によって振り分けられた振り分け先と端末が継
続的なコネクションを確立している最中に、別の端末またはサーバからこの端末への接続
要求があった場合、前記の継続的なコネクションを確立している振分け先とは異なる振分
け先にこの接続要求を振り分けてしまう場合がある。
本発明の第四の課題及び目的は、一つの端末に応対するために複数の振分け先のリソース
が消費されてしまうことを防ぐことである。

従来の負荷分散装置では、端末やサーバが接続要求を負荷分散装置に送信することなく
振分け先の一つに直接送信してしまった場合には、負荷分散装置がこの接続要求を検知す
ることができず、その結果負荷分散装置が指示した通りに負荷が分散されない場合がある
。
本発明の第五の課題及び目的は、負荷分散装置が割当てていない振分け先への接続を防ぐ
ことである。

上記第一の課題に対する解決手段として、本発明の負荷分散装置は、受信したIPパケッ
トの上位レイヤでの直前の送信元が端末か否かを判定し、直前の送信元が端末である場合
には該端末に応対する振分け先を決定し、該端末に振分け先のアドレスを通知する（リダ
イレクト）。また、このとき端末はリダイレクトによって通知された振分け先へ上記IPパ
ケットを再送信する。

上記第二の課題に対する解決手段として、本発明では、端末に応対する振分け先に有効
期限を設け、この有効期限を過ぎた場合は、振分け先への上記端末の接続を拒否する。

上記第三の課題に対する解決手段として、本発明の負荷分散装置は、受信したIPパケッ
トの上位レイヤでの直前の送信元がサーバか否かを判定し、直前の送信元がサーバである
場合には、該IPパケットの送信先の端末に応対する振分け先に該IPパケットを送信する。

上記第四の課題に対する解決手段として、本発明の負荷分散装置は、振り分け先と端末
が継続的なコネクションを確立している最中に、別の端末またはサーバからこの端末への
別の接続要求があった場合、この別の接続要求を前記の継続的なコネクションを確立して
いる振分け先へ送信する。

上記第五の課題に対する解決手段として、本発明では、負荷分散装置が割当てていない
振分け先に端末やサーバが直接接続要求を送信した場合には、この接続要求を拒否する。

上記第一の課題に対する解決手段により、負荷分散装置は暗号化通信の終端、つまり復
号化処理を行う必要がなくなる。これにより、負荷分散装置の処理を軽減でき、負荷分散
装置本来の負荷分散が達成でき、負荷分散装置での復号化処理による転送遅延も防ぐこと
ができる。

上記第二の課題に対する解決手段により、端末が一つの振分け先を永久に使い続けるこ
とがなくなる。これにより、特定の振分け先に長い間処理が集中することを防ぐことがで
き、負荷分散装置本来の負荷分散が達成できる。

上記第三の課題に対する解決手段により、リダイレクト通知に応対する機能を有しない
送信元からの接続または処理の要求も各々の振分け先に振り分けることができる。これに
より、リダイレクト通知に応対する機能を有しない送信元からの接続または処理の要求に
関しても負荷分散を実現できる。

上記第四の課題に対する解決手段により、端末が継続的なコネクションを確立している
振分け先のリソースを有効に利用でき、かつ一つの端末に応対するために複数の振分け先
のリソースが消費されるのを防ぐことができる。

上記第五の課題に対する解決手段により、端末またはサーバが負荷分散装置が割当てて
いない振分け先へ勝手に接続するのを防ぐことができる。これにより、負荷分散装置本来
の負荷分散が達成できる。

図１は、本実施形態に係わるSIP負荷分散装置の一構成例を示す図である。本実施例で
は、SIPを例に挙げているが、その他のアプリケーションレイヤのプロトコル（他のセッ
ション制御プロトコルなど）に適用してもよい。SIP負荷分散装置1は、CPU（10）、メモ
リ（16）、記憶装置（14）、ネットワークインターフェース（12）を備え、以降に詳しく
説明する制御用プログラムが格納されている。SIP負荷分散装置が動作する際には、筐体
内に設けられたメモリ上に制御プログラムが展開され、CPUで制御プログラムが実行され
る。記憶装置は筐体内部に実装される形態でも、外部記憶装置として別筐体で設置される
形態でも、ネットワークで接続される形態でも構わない。

また、図１に示した負荷分散装置は、装置管理権限を持つユーザなどが負荷分散装置を
操作するためのユーザインタフェースを備えていてもよい。ユーザインタフェースとして
は、例えば、コマンド入力のためのキーボードや、ＧＵＩ入力のためのマウス、表示画面
などを備えているとよい。

上記制御用プログラムの詳細を、図１の20から27に示すブロック構成図を用いて説明す
る。SIP負荷分散装置は、パケットの送受信を行うネットワークインターフェース12と、
ＣＰＵ10とＨＤＤ(Hard Disc Drive)14と、メモリ16とからなる。メモリ16には、通信制
御プログラム20、SIPスタックプログラム21、送信元判定プログラム22、リダイレクトプ
ログラム23、ステートレスプロキシプログラム24、負荷分散管理プログラム25、負荷分散
管理テーブル26、ロケーション制御プログラム27が格納されている。

通信制御プログラム20は、ネットワークインターフェース12を介して受信したパケット
の解析と、パケットの送信を行う際に必要となるヘッダ情報の整形操作および送信を行う
。SIPスタックプログラムは、受信パケットの内容がSIPメッセージだった場合にはメッセ
ージ解析を行い、送信パケットの内容がSIPメッセージの場合にはSIPヘッダ情報の整形操
作と通信制御プログラム20を通じた送信処理を行う。送信元判定プログラム22は、SIPメ
ッセージを受信した際に直前のホップの送信元が自身が責任を負うドメイン内の端末7か
らであるか否かの判定を行う。リダイレクトプログラム25は、直前ホップの送信元が自身
が責任を負うドメイン内の端末からであった場合に、負荷分散管理テーブル26から負荷分
散管理プログラム25を通じてこの送信元端末に応対するSIPサーバ2のアドレスを取得し、
取得したSIPサーバのアドレスを端末7に通知する。ロケーション制御プログラム27は、負
荷分散管理プログラム25が端末7に対して応対するSIPサーバを新たに割り当て、負荷分散
管理テーブル26に新規登録した際に、端末7と応対するSIPサーバ2の対応関係をロケーシ
ョンDB(Data Base)3に通知して登録を促す。

ステートレスプロキシプログラム24は、直前ホップの送信元が自身が責任を負うドメイ
ン内の端末以外からであった場合に、宛先端末7がオンライン時にどのSIPサーバ2に振り
分けられているかを、負荷分散管理テーブル26から負荷分散管理プログラム25を通じて取
得し、取得したSIPサーバにメッセージをステートレスプロキシとして中継する。

ここでステートレスプロキシとは、ダイアログの管理もトランザクションの管理も行わ
ず、宛先解決した結果に従って単純に受信したメッセージを中継するプロキシのことをい
う。従ってステートレスプロキシの場合、例えばあるリクエストメッセージの中継を行っ
たとしても、これに対するレスポンスメッセージの通信経路には含まれないことがある。
これに対してトランザクションステートフルプロキシとは、リクエストとレスポンスの対
を管理し、必要に応じて再送制御などを行うプロキシをいう。更に、IP電話における発信
時のリクエストから切断時のレスポンスまでのダイアログを管理し、状態遷移モデルに合
致しないトラフィックを排除したり、通信ログを課金管理に活用したりするトランザクシ
ョンステートフルプロキシをコールステートフルプロキシという。

負荷分散管理テーブル26は、端末7と応対するSIPサーバ2との対応関係を記憶して管理
する。負荷分散管理プログラム25は、負荷分散管理テーブル26の情報を参照・更新する。
ここで、負荷分散管理テーブル26はＨＤＤ14内に格納されていてもよい。
本実施例では、図１の20から27に示した各機能ブロックが、全てソフトウェア処理により
実現するものと仮定しているが、機能ブロックそれぞれに対応するプロセッサや信号処理
回路などを用いて、ハードウェア的に図１の構成を実現しても構わない。

図２は、本実施形態に係わるSIP負荷分散システムの一構成例を示す図である。SIP負荷
分散システムは、ユーザA1およびユーザA1が所有する端末7aと、ユーザA1もしくはユーザ
A1とは別のユーザAnが所有する端末7nなど、複数の端末7が属するドメインA30と、ユーザ
BおよびユーザBが所有する端末8が属するドメインB35で構成される。ドメインBは、ドメ
インAと異なるドメインの存在を一例として示しているものであり、更に異なる複数のド
メインを加えてネットワークシステムを構成してもよい。また、ドメインB内には端末8と
、端末8を収容し、端末8のセッションを制御するSIPサーバb4とがネットワーク6で接続さ
れた構成を図示しているが、ドメインB内の構成もドメインA内の構成と同様に、複数台の
端末と複数台のSIPサーバで構成される形態でも構わない。

本実施形態に係わるSIP負荷分散システムの特徴の一つは、ドメインA内の構成のように
、複数台の端末7a〜7nとの通信を複数台のSIPサーバ2a〜2nで分担して対応させる際に、S
IP負荷分散装置1が端末7からの問合せに対して、応対するSIPサーバ2のアドレスを通知す
る機能を有することにある。この時、当該ドメインに属するユーザおよび端末の情報を管
理するロケーションDB3は、各SIPサーバ2a〜2nが共通に利用する。また、SIP負荷分散装
置1、SIPサーバ2a〜2n、ロケーションDB3と、端末7a〜7nはネットワーク5で接続されてい
る。更に、ドメインAとドメインBも相互にネットワークで接続されているものとする。図
２では、ロケーションDB3に対するアクセスが端末7や他ドメインの装置からも可能である
かのようにみえるかもしれないが、SIP負荷分散装置1およびSIPサーバ2a〜2nのみからア
クセスが可能なようにネットワークを分けてもよい。この場合、よりセキュリティが確保
される。

図３は、本実施形態に係わるSIP負荷分散システムにおいて、端末7からのメッセージが
SIP負荷分散装置1を通じてSIPサーバ2に振り分けられるまでのシーケンスの一例を示した
図である。

本実施形態における端末7は、暗号化通信を行う場合には、事前にRFC3329で規定されて
いるセキュリティ方式のネゴシエーションを行うものとする。よって、図３から図６では
セキュリティ方式のネゴシエーションが完了するまでは非暗号化（平文）通信を行うとい
う前提でシーケンスおよびメッセージの例を示している。但し、本発明の効果を奏する限
り、他の暗号化通信方式を適用してもよい。

また、図４に例示した端末からSIP負荷分散装置に送るメッセージ（F40）には、セキュ
リティ方式のネゴシエーション情報（Security-Clientヘッダ）を含まない一般的なREGIS
TER登録のリクエストメッセージを示しているが、F40のメッセージにセキュリティ方式の
ネゴシエーション情報が含まれていても構わない。

一方、図５に示したSIP負荷分散装置1から端末7へ応対するSIPサーバのアドレスを通知
するレスポンスメッセージ（F41）にはセキュリティ方式のネゴシェーション応答情報（S
ecurity-Serverヘッダ）を含まない302応答を使う。
これは、例えF40にセキュリティ方式のネゴシェーション情報が含まれていたとしても、
負荷分散装置自体はこのネゴシェーションを行わないので、F41のメッセージにセキュリ
ティ方式のネゴシエーション情報（Security-Serverヘッダ）は通常含めないからである
。
但し、F41のメッセージでセキュリティ方式のネゴシエーション情報を含めてもよい。こ
のとき、RFC3329の規定には反するが、302応答をF41として使ってもよい。あるいは、RFC
3329の規定に従って、セキュリティ方式のネゴシェーション応答情報を指定可能な423応
答もしくは429応答をF41として使ってもよい。

更に、本実施形態ではリダイレクト通知のメッセージとして302応答（F41）を用いる例
を示しているが、端末との間のネットワークインターフェース仕様を統一すれば、300番
台の他のレスポンスコードや、予約されていない独自のレスポンスコードを用いても構わ
ない。

SIP負荷分散装置1には、管轄するドメインを代表するアドレスとして、バーチャルドメ
イン的なドメイン名（例：domainA.co.jp）を割り当てる。バーチャルドメイン的とは、
実際に各メッセージを処理する各SIPサーバのアドレスの代わりにSIP負荷分散装置1のア
ドレスを公開するという意味である。端末7は利用開始時のREGISTERメッセージ（F40）を
、このアドレス（すなわちSIP負荷分散装置）宛（50）に送信する。SIP負荷分散装置1は
、送信元判定プログラム22により、受信したメッセージの直前ホップの送信元が端末7で
あると判定した場合、負荷分散管理プログラム25によって端末7に応対するSIPサーバ2を
決定し、決定したSIPサーバのアドレスを302応答で端末7に通知する（F41）。この時のSI
Pサーバ2のアドレス通知方法としては、図５に示すように、Contactヘッダ（54）を利用
する。

302応答（F41）を受信した端末は、302応答のContactヘッダで通知されたアドレス宛に
メッセージを送りなおす（F42）。具体的なメッセージ内容は、図６に示すように、Reque
st-Lineに302応答のContactヘッダで通知されたアドレスを指定する（56）。この時、ユ
ーザもしくは端末に割り振られたSIP-URI（52、56）やコンタクトアドレス（53、59）の
内容は、オリジナルのものと同一のままである。

図７は、本実施形態に係わるSIP負荷分散装置1の負荷分散管理テーブル26の一構成例を
示した図である。
図７に示すように、負荷分散管理テーブル26では、例えば端末オンライン時のREGISTER登
録（F40）を契機に割り当てたSIPサーバと端末の対応関係を記憶して管理する。具体的に
は、SIPサーバの割り当てを契機にリクエストメッセージのFromヘッダに指定されたユー
ザまたは端末のSIP-URIのエントリ（62）を追加し、当該SIP-URIに割り当てたSIPサーバ
のカラムにビットを立てる（60）。

一方、負荷分散管理プログラム25は、端末7に応対するSIPサーバを決定する際に、各SI
Pサーバの応対総数（64）を参照して、例えば応対数の少ないSIPサーバを新たに割り当て
る。応対総数（64）からSIPサーバの負荷を推測できるので、応対総数（64）を参照してS
IPサーバを割当てることによって、SIPサーバの負荷を反映した割り当てが実行でき、よ
りきめ細かな負荷分散が実現できる。

応対総数を簡便に集計する方法としては、割り当てたSIPサーバのカラムへの登録に数
値カウントの「１」を用い、この数値カウントの総和を応対総数とすると良い。また、振
り分け先（割り当て先）のSIPサーバを決定する際に、各SIPサーバ毎の性能を加味した重
み付けを行っても良い。各SIPサーバ毎の性能を加味した重み付けを行うことによって、
それぞれのSIPサーバのスペック（例えば、CPU性能、メモリ容量など）に差がある場合に
は、そのスペックの差を反映した割当てが実行でき、よりきめ細かな負荷分散が実現でき
る。

F40のリクエストで端末7が希望する暗号化通信の方式が（例えばセキュリティネゴシエ
ーションの情報として）示されている場合は、SIPサーバとの間で利用する暗号化通信の
方式ごとに重み付けを行っても良い。暗号のエンコード／デコード処理にかかる負荷は暗
号化通信の方式ごとに異なるため、暗号化通信の方式ごとに重み付けを行うことによって
、暗号化通信の方式ごとの負荷の差を反映したSIPサーバの割り当てが実行でき、よりき
め細かな負荷分散が実現できる。
重み付けを行う場合は、重みによって決まる数値カウントをカラムへ登録すればよい。ま
た、暗号化通信方式ごとに割り当てるSIPサーバを決めておいてもよい。暗号化の有無や
暗号化通信方式の違いによってサービスや契約形態を分ける場合に、設備投資や管理が単
純化できる。

図８は、本実施形態に係わるSIP負荷分散装置で割り当てたSIPサーバの利用有効期限を
制御する方法の一例を示したシーケンス図である。
本実施形態に係わるSIP負荷分散装置では、端末7に割り当てたSIPサーバのアドレスを端
末7に通知するのと同時に、この割り当てたSIPサーバの利用有効期限も端末7に通知する
。例えば302応答のContactヘッダにexpiresパラメータ（図５、54）を含めて通知する。
この時に通知する有効期限の値としては、システムとして許容する最長利用時間を通知す
る。この最長利用時間は、システムの置かれている場所、システムの使い方などに合わせ
て設定することができる。

このように有効期限を定めることによって、実質的にセッションが終了しているにも関
わらず障害などの原因で端末からのセッション終了通知が送られてこない場合に、リソー
スを解放することができる。これにより、SIPサーバのリソースを無駄に使い続けるのを
防ぐことができる。

一方、負荷分散管理テーブル26からのエントリの削除を行う際のシーケンスを、図８の
後半に示す。端末がオフライン時に投げるREGISTER削除のメッセージ（F75）を契機に、S
IPサーバ2がロケーション情報の削除を行う通常の処理（F76）に加え、SIP負荷分散装置2
に対して負荷分散管理テーブル26の該当ユーザ（または端末）のエントリ削除を要求する
命令を送る（F77）。SIP負荷分散装置2内部では、この命令を受けた負荷分散管理プログ
ラム25が負荷分散管理テーブル26の該当エントリを削除する。このような処理を行うこと
により、オンライン時に端末に対して割り当てたSIPサーバが、オフライン時には開放さ
れることを負荷分散テーブル26で管理できるようになる。端末がオフライン時にREGISTER
削除メッセージ（F76）を送らない場合は、REGISTERの有効期限が切れた時に、SIPサーバ
2がエントリ削除要求を発行する。この有効期限切れの処理により、端末が一つの振分け
先を永久に使い続けることがなくなる。これにより、特定の振分け先に長い間処理が集中
することを防ぐことができ、負荷分散装置本来の負荷分散が達成できる。

上記の方法は、SIP負荷分散装置で有効期限のタイマ管理を行わない方法であるが、別
の方法としては、SIP負荷分散装置で有効期限のタイマ管理を行っても良い。この時に、
端末が割り当てられたSIPサーバを利用可能な期間を、REGISTER有効期限と一致させる必
要がある。この際、REGISTER有効期限が延長される場合も考慮しなけらばならない。先ず
、F41のリダイレクト通知で端末7に通知するSIPサーバの有効期限の値と同じ値を、REGIS
TER登録に対する成功応答（200ＯＫ（F45））で当該REGISTERの有効期限として端末7に通
知する。また、負荷分散管理テーブル26には、図７の構成に加えて端末に対して割り当て
たSIPサーバの利用有効期限を管理するためのカラム（行）を追加する。

有効期限の設定の仕方としては、有効期限の時間（長さ）が一意に決まっている場合は
、開始時刻の絶対時間を記録しておく形でも良いし、あらかじめ終了時刻を計算して記録
しておく形でもよい。この場合、記録時に終了時刻を計算しておいて、検査時は現在時刻
と比較するだけにするとより処理負荷が軽減される。さらに、有効期限を接続毎に可変と
する場合は、終了時刻を記録しておいた方がよい。こうすることにより、有効期限が可変
であっても検査処理の手順を統一化できる。さらに、SIPサーバ2側は、REGISTER削除（F7
5）の時だけでなく、REGISTER更新（F70）の際にも、SIP負荷分散装置に対して負荷分散
管理テーブルの更新要求を発行する（F72）。この場合は、図８のF70からF73のシーケン
スと同様のシーケンスとなる。

この方法では、SIP負荷分散装置でも有効期限のタイマ管理を行っているため、REGISTE
Rの有効期限が切れた時に、SIPサーバ2からSIP負荷分散装置1へエントリ削除要求を送信
する必要がなくなる。SIP負荷分散装置（負荷分散管理プログラム25と負荷分散管理テー
ブル26）で管理する有効期限が切れた時には、負荷分散管理プログラム25が負荷分散管理
テーブル26の該当するエントリを削除する。

図９は、本実施形態に係わるSIP負荷分散システムにおいて、端末7がSIP負荷分散装置1
に許可されていないSIPサーバ2を利用することを防止する方法の一例を示したシーケンス
図である。
本実施形態のSIP負荷分散システムでは、全てのトラフィックをSIP負荷分散装置1が中継
するモデルでは無く、端末に対して応対するSIPサーバ2を通知して誘導するモデルである
ため、SIP負荷分散装置1が割り当てていないSIPサーバ2を端末7が勝手に利用してしまう
と負荷分散の管理が成り立たなくなり、上手く負荷が分散されなくなる。本実施形態のSI
P負荷分散システムでは、各SIPサーバ2のアドレスは原則公開せず、SIP負荷分散装置1の
アドレスを公開する運用形態をとるが、一度SIP負荷分散装置1からリダイレクト通知（F4
1）を受けると、割り当てられたSIPサーバのアドレスはContactヘッダで通知（54）され
るため、このSIPサーバのアドレスは端末の知る所となる。ここでアドレスが判明したSIP
サーバを、一旦利用を終えた端末が、別の機会に、SIP負荷分散装置1を介さずに直接再利
用してしまうと、上記のような問題が発生する。
そこで、本実施形態のSIP負荷分散システムでは、以下に説明するような直接通信防止方
法を導入する。

図３に示したのと同様の手順で端末7がSIP負荷分散装置1にリクエストを送信してきた
時（F40）に、SIP負荷分散装置1は応対するSIPサーバ2を決定し、割り当てたSIPサーバ2
のアドレスを端末7に通知する（F41）が、この際SIP負荷分散装置1は各SIPサーバ2a〜2n
が共通で利用するロケーションDB3に端末7（またはユーザ）に割り当てたSIPサーバ2のア
ドレスを登録する（F80）。

ロケーション情報は、通常、ユーザまたは端末に付与するSIP-URI（92）と、端末7のコ
ンタクトアドレス（94）としてFQDN（Fully Qualified Domain Name）またはIPアドレス
などの情報を登録管理する。これらの情報を固定設定して運用してもよいが、SIPシステ
ムではREGISTER登録を契機に、ユーザまたは端末に付与するSIP-URI（いわゆるユーザネ
ーム（U-Name））と、当該SIP-URIに割当てられたSIPサーバのコンタクトアドレスなどの
情報を登録してもよい。本実施形態のSIP負荷分散システムでは、ロケーションDB3で管理
するロケーションテーブル90を図10に示すような形で拡張する。従来のユーザアドレス単
位で管理する情報に、新たに、振分け先の（応対する）SIPサーバ2のアドレスを追加する
（96）。

この拡張ロケーションテーブル90の情報は、F80のステップの命令を受けた際に、SIP負
荷分散装置1にリクエストを送ってきた端末（またはユーザ）のユーザネームと、振分け
先のSIPサーバ2のアドレス情報を対にして登録する。一方、コンタクト情報などは、端末
7からのREGISTER登録（F82）を振分け先のSIPサーバ2が受信し、受付処理する段階で追加
登録する（F85）。

本実施形態のSIP負荷分散システムでは、図８のSIPサーバの利用有効期限に関する説明
で述べたように、例えば、オンライン時のREGISTER登録からオフライン時のREGISTER削除
までの期間を、割り当てたSIPサーバの利用有効期限とする場合、オンライン時に応対す
るSIPサーバを割り当てられた後は、利用有効期限内であればSIP負荷分散装置1を介さず
に直接割り当てられたSIPサーバと通信することを想定している。この時に、各SIPサーバ
2は端末1からのメッセージを直接受け取ることになるが、端末1からのメッセージを受け
た時、例えば最初のREGISTER登録メッセージを受けた時（F80）などに、自身が応対して
も良い端末か否かは、F85とF86のステップで拡張ロケーションテーブル90の情報を参照し
、REGISTER登録メッセージを送ってきた端末に割り当てられているSIPサーバが自身か否
かを確認する。ここでREGISTER登録メッセージを送ってきた端末に割り当てられているSI
Pサーバが自身であった場合には、コンタクトアドレスなどREGISTER登録メッセージから
取得した情報を拡張ロケーションテーブル90に追加登録し（F87）、端末に応答を返す（F
89）。一方、F85とF86のステップで拡張ロケーションテーブル90の情報を参照した際に、
REGISTER登録メッセージを送ってきた端末に割り当てられているSIPサーバが無い、また
は割り当てられているSIPサーバが自身では無い場合には、F87のコンタクトアドレスの登
録などは行わず、F89のステップでは端末にエラー応答（例えば、403 Forbiddenなど）を
返す。このような手順を踏むことにより、本実施形態のSIP負荷分散システムでは、SIP負
荷分散装置1が割り当てていないSIPサーバと端末との間の直接通信を防止する。

ちなみに、拡張ロケーションテーブル90の各エントリは、通常のロケーション情報を削
除するタイミングと同様に、REGISTER登録の有効期限が切れたとき、または端末がREGIST
ER削除メッセージを送ってきたときに、SIPサーバがロケーションDB3に削除命令を送って
クリアする。
また、図９に示した端末からSIPサーバへのREGISTER登録シーケンス（F82からF89）は、
セキュリティネゴシエーションを含まないREGISTER登録のシーケンスを例としているが、
図３に示したようなセキュリティネゴシエーションを含むREGISTER登録シーケンスの場合
には、F44のステップの後で、F85からF87のようなSIPサーバとロケーションDB3との間の
シーケンスが走る。

図１１は、本実施形態に係わるSIP負荷分散システムにおいて、他ドメインのSIPサーバ
4を経由して自ドメインの端末7宛に送られてきたリクエストメッセージを扱う方法の一例
を示した図である。

他ドメイン（ドメインB）35に属する端末8から、自ドメイン（ドメインA）に属する端
末7宛に送られるリクエストメッセージは、最初に端末8が属するSIPサーバb4に送られる
（F100）。SIPサーバb4は受信したリクエストメッセージを、宛先端末7が属するドメイン
のSIPサーバに中継するが、この時、本実施形態に係わるSIP負荷分散システムでは、ドメ
インAを管轄するSIPサーバの代表アドレス（例：domainA.co.jp）をSIP負荷分散装置1に
割り当てて運用するため、SIPサーバb4が中継するリクエストメッセージはSIP負荷分散装
置1に送られる（F101）。

他ドメインのSIPサーバb4から送られてきたリクエストメッセージを受信したSIP負荷分
散装置1では、送信元判定プログラム22において、受信したリクエストメッセージの直前
の送信元が自ドメインの端末でないと判定されるため、ここで負荷分散管理プログラム25
が負荷分散管理テーブル26を参照し、宛先端末の通信（セッション）管理を割り当てられ
ているSIPサーバを調べ、そのSIPサーバにメッセージをステートレスに中継する（F102）
。ここで述べている「ステートレスに」というのは、SIPについて規定しているRFC3261で
定義されているステートレスプロキシの動作と同様の動作を指す。すなわち、SIP負荷分
散装置1は以降の通信におけるセッションの状態遷移は管理せず、レスポンスメッセージ
を含め、以降のトランザクションがSIP負荷分散装置1を経由しなくても良いようにメッセ
ージを中継する。具体的には、ViaヘッダやRecord-Routeヘッダなど、メッセージの通信
経路が同じになるように、通常、SIPサーバがメッセージ中継時に付与するヘッダを付加
せずに、受信したメッセージを中継する。このようにすることで、一度適切なSIPサーバ
にメッセージを中継した後は、SIP負荷分散装置1は当該セッションに係わる通信に関与せ
ずに済むため、SIP負荷分散装置１は当該セッションの管理の処理負荷から開放される。

SIP負荷分散装置1からリクエストメッセージを中継されたSIPサーバa2（2b）は、ロケ
ーション情報を参照し、宛先に指定されたユーザアドレスに対応するコンタクトアドレス
を調べ、該コンタクトアドレス宛にメッセージを中継する（F103）。本実施形態に係わる
SIPサーバでは、自身が応対する端末に関するロケーション情報をサーバ内部で登録管理
することを想定しているため、ロケーション情報の参照に関わる装置間の通信はシーケン
スに含めていないが、ロケーションDB3で管理している拡張ロケーションテーブル90を参
照しても良い。ここで、自身が応対する端末に関するロケーション情報をサーバ内部で管
理すると、SIPサーバとロケーションDBとの間の通信時間を削減できる効果が得られる。

一方、レスポンスメッセージは、リクエストメッセージに付与されたViaヘッダの情報
に従い、F104、F105、F106の順に返信される。ここでリクエストメッセージの経路と違い
、レスポンスメッセージがSIP負荷分散装置1を経由しないのは、リクエスト中継時にSIP
負荷分散装置1がステートレスな中継を行ったため、ViaヘッダにSIP負荷分散装置1のアド
レスを付加しないためである。また、以降の端末8と端末7との間の通信は、各SIPサーバ
がリクエスト中継時に付加したRecord-Routeヘッダの情報に基づいて生成するRouteセッ
トの経路に従うため、その経路もレスポンスメッセージの通信経路と同様の通信経路とな
る（つまり、SIP負荷分散装置１は通過しない）。

図１２は、本実施形態に係わるSIP負荷分散装置1のパケット受信時の処理手順を示すフ
ローチャートである。
ネットワークインターフェース12を通じてパケットを受信した通信制御プログラム20は、
受信パケットがSIPメッセージか否かを調べる（ステップ110）。ここで受信パケットがSI
Pメッセージであった時は、SIPスタックプログラム21にてメッセージ解析を行い、送信元
判定プログラム22において、メッセージの直前の送信元が自ドメイン内の端末か否かを調
べる（ステップ111、ステップ112）。送信元が自ドメイン内の端末であった場合には、負
荷分散管理プログラム25が負荷分散管理テーブル26を参照し、端末との通信に応対する適
切なSIPサーバを決定する（ステップ113）。決定したSIPサーバの情報は、ロケーションD
B3の対応するユーザアドレスの項に設定した後（ステップ114）、端末にリダイレクト通
信プログラム23を用いて通知する（ステップ115）。

ステップ111、ステップ112の送信元処理において、メッセージの直前の送信元が自ドメ
イン内の端末以外、例えば、図１１に示したような他ドメインのSIPサーバであった場合
は、負荷分散管理プログラム25が負荷分散管理テーブル26を参照し（ステップ120）、宛
先端末との通信に応対しているSIPサーバを調べる（ステップ121）。ここで該当するSIP
サーバが存在する場合には、ステートレスプロキシプログラム24を用いてメッセージを当
該サーバに中継し（ステップ122）、該当するSIPサーバが無かった場合には、宛先端末が
オフライン状態であると判定してエラー応答（例えば404 Not Found）を送信元に返す（
ステップ123）。

一方、ステップ110の受信パケット内容の判定において、受信パケットがSIPメッセージ
以外であった場合には、通信制御プログラム20において、図８のF77に示したような負荷
分散管理テーブル26のエントリ削除を要求する命令パケットであるか否かを判定し（ステ
ップ125）、エントリ削除命令であった場合には、負荷分散制御プログラム25が負荷分散
管理テーブル26の該当エントリを削除する（ステップ126）。

ステップ111の送信元判定には幾つかの方法が考えられる。一つの方法は、受信したリ
クエストメッセージのSIPヘッダ部に含まれるFromヘッダの情報52を参照する方法である
。「＠」マーク以降のドメイン部の内容が自ドメインと合致する場合には、自ドメイン内
の端末から送られたメッセージと判定する。この判定を行うことにより、負荷分散装置が
取るべき動作を決定することができる。例えば本実施例の場合は、メッセージの送信元が
自ドメインの端末である場合、負荷分散装置はメッセージ送信元である端末に対して応対
するSIPサーバのアドレスを通知し、一方、メッセージの送信元が他ドメインの端末・装
置である場合、本発明の負荷分散装置は宛先端末に応対しているSIPサーバにメッセージ
をステートレス中継する。

同じく、受信したリクエストメッセージのSIPヘッダ部に含まれるFromヘッダの情報52
を参照して判定する別の方法としては、Fromヘッダの情報52を同ドメインの加入者情報と
比較しても良い。ここで比較する加入者情報とは、ユーザまたは端末に付与したSIP-URI
、すなわちユーザアドレスを指す。この場合は、受信したリクエストメッセージのSIPヘ
ッダ部に含まれるFromヘッダに指定されたSIP-URIと合致するユーザアドレスが、加入者
情報に存在するか否かを検索する。検索した結果、合致すれば自ドメイン内の端末から送
られたメッセージと判定する。このように判定することにより、ドメイン指定は正しいが
、ユーザIDが不正な（例えば、無作為に設定された）アドレスであった場合、SIPサーバ
に振り分けを行う前にこれを検出して拒絶することが可能になる。つまり、不正なアドレ
スをもつメッセージによりSIPサーバに負荷がかかることを防止できる。

この加入者情報は、SIP負荷分散装置1内に持たせても良いし、ロケーションDBに持たせ
て参照しても良いし、加入者情報を管理する独立のDBサーバを設けて参照しても構わない
。
または、自ドメイン内の端末に付与するIPアドレスの範囲が特定できる場合には、受信し
たリクエストメッセージのIPヘッダのソースアドレスが、この範囲に含まれるか否かで判
定することもできる。この範囲は、例えば「133.144.0.1」から「133.144.0.255」までと
いうようにIPアドレスの番号の範囲で指定してもよい。

このように、IPアドレスの範囲によって判定することにより、ドメインアドレスを使っ
たリクエストを送信できない端末にも対応できる。また、IPアドレスに対応する加入者情
報とは関係なく割当てを行うことにより、加入者の登録／削除／サービス変更等に左右さ
れずに割当てられるので、割当ての処理が軽減される。

更に別の方法としては、相互に接続する他ドメインのSIPサーバなどのアドレスリスト
を持ち、これと受信したリクエストメッセージのIPヘッダのソースアドレスとを比較する
ことにより、他ドメインからの通信であるか否かを判定するという方法でも構わない。こ
の判定方法により、他ドメインと相互接続するSIPサーバを限定することができる。さら
に、その接続規制を負荷分散装置で行うことにより、SIPサーバに負担を掛けずに接続規
制を行うことができる。

図１３は、本実施形態に係わるSIP負荷分散システムにおいて、同一ドメイン内の端末
間で通信を行う方法の一例を示した図である。
端末a1（7a）と端末aN（7n）は、それぞれ、図３と同様の手順でSIP負荷分散装置1から通
知されたSIPサーバa1（2a）とSIPサーバaN（2n）との間で、継続的なコネクションを確立
している。このような状況で端末a1から端末aNに送られるリクエストメッセージの流れを
説明する。

端末a1が発行するリクエストメッセージは、先ず、端末a1との間で継続的なコネクショ
ンを確立しているSIPサーバa1に送られる（F130）。SIPサーバa1は、メッセージの宛先を
参照することで、宛先が同一ドメインに属する端末であることを判別する。ここで、自身
が応対している端末のロケーション情報を、メモリまたはローカルのハードディスク上で
キャッシュ管理している場合は、キャッシュ上のロケーション情報に宛先端末の情報が存
在するか調べる。キャッシュ上に宛先端末の情報が存在する場合は、そこに記録されてい
るコンタクトアドレス宛にメッセージを中継する。一方、キャッシュ上に宛先端末の情報
が存在しない場合には、ロケーションDB3で管理している拡張ロケーションテーブル90の
情報を参照する（F132、F134）。宛先端末aN（7n）がオンラインであれば、該当端末との
通信に応対し、セッションの管理を行っているSIPサーバの情報96が、該当端末のSIP-URI
情報92と対で登録されている。よって、該当端末のSIP-URIに対応するSIPサーバの情報96
を参照し、ここで得られたSIPサーバのアドレスにメッセージの中継を行う（F136）。最
後に、メッセージを受信したSIPサーバaN（2n）は、SIPサーバa1（2a）と同様の手順で宛
先の確認とロケーション情報の参照を行い、メッセージを端末aN（7n）に中継する。この
ように既存コネクションを利用することで、SIPサーバおよび端末のリソースの消費を抑
制できる。また、既存コネクションを利用することで、新たな暗号化通信路を確立するた
めの鍵交換や認証手順を省略でき、この場合さらにSIPサーバ、端末の負荷を削減できる
。
SIPサーバが、自身が応対している端末のロケーション情報をキャッシュ管理していない
場合は、最初からロケーションDB3で管理している拡張ロケーションテーブル90の情報を
参照する。

ちなみに、拡張ロケーションテーブル90では端末のコンタクトアドレス情報94も登録・
管理しているため、F132、F134の手順で拡張ロケーションテーブルを参照する際には宛先
端末aN（7n）のコンタクトアドレスも判明する。よって、SIPサーバa1（2a）はSIPサーバ
aN（2n）を介さず、直接、宛先端末aN（7n）にメッセージを中継することも可能である。

しかしながら、端末aN（7n）とSIPサーバaN（2n）との間の継続的なコネクションが、
認証手順を経て確立される通信路であって、また、送受信されるパケットが暗号化される
セキュアな通信路であるような場合、このコネクション上で送受信されるパケットは安全
が保障されるものとして許容するが、他のコネクション上で送られるパケット（例えば、
上記のようにSIPサーバa1から端末aNに直接中継されるパケット）は許容しないとしても
よい。このような場合には、安全が保障されている通信は、図１３で示したようにSIPサ
ーバaNを経由する通信経路でパケットを中継することが望ましい。このように、安全が保
障されていない他のコネクションのパケットを許容しないことで、安全が保障されている
パケットとそれ以外のパケットを混同せずに転送することができる。
図１３に示したような中継処理を行うSIPサーバの装置構成図と動作フローを、それぞれ
図１４と図１５で説明する。

図１４は、本実施形態に係わるSIPサーバ2の一構成例を示す図である。CPU10、メモリ1
6、記憶装置14、ネットワークインターフェース12を備える点は、図１に示したSIP負荷分
散装置と同様である。記憶装置に格納されたSIPサーバの制御用プログラムは、動作時に
メモリ上に展開され、CPUで実行される。記憶装置は筐体内部に実装されても、外部記憶
装置として別筐体で設置されても、ネットワークで接続されていも構わない。
また、装置管理権限を持つユーザがSIPサーバを操作するためのユーザインタフェースを
備えていてもよい。ユーザインタフェースとしては、例えば、コマンド入力のためのキー
ボードや、ＧＵＩ入力のためのマウス、表示画面などを指す。

通信制御プログラム20とSIPスタックプログラム21も図１で示したプログラムと同様で
ある。一方、簡略化して示しているが、140から149までがSIPプロキシプログラムを含むS
IPサーバの主構成要素である。SIPプロキシプログラム140は中継先のアドレス解決プログ
ラム144を含む。この中継先アドレス解決プログラムの詳細については、後に、図１５の
フローチャートを用いて説明する。セッション管理テーブル142は、呼の状態遷移を管理
する。ローカルロケーションテーブル146は、当該SIPサーバが応対する端末のSIP-URIと
コンタクトアドレスなどのロケーション情報を管理する。セッション管理テーブル142と
、ローカルロケーションテーブル146は、図14ではメモリ16上のテーブルとして描いてい
るが、記憶装置14上に置かれるデータベーステーブルであっても構わない。また、ローカ
ルロケーションテーブルをSIPサーバ内で保持する代わりに、外部のロケーションDBにロ
ケーション情報を保持しておき、必要なときにこのDBにアクセスしてもよい。しかし、SI
Pメッセージの中継処理を高速に行うためには、自身が応対する端末のロケーション情報
は、ローカルロケーションテーブル146のような形で自サーバ内に情報を保持しておく方
が、常に外部のロケーションDB3を参照するよりも有利である。

アドレス解決プログラム144は、先ず、受信したメッセージの宛先情報を参照し、自身
が管轄するドメイン内の端末宛のメッセージであるか（自ドメイン宛であるか）否かを調
べる（ステップ150）。ここで宛先が自ドメインの端末であった場合は、アドレス解決プ
ログラム144において、ローカルロケーションテーブル146を参照し、現在、自身が応対し
ている端末であるか否か調べる（ステップ153）。ローカルロケーションテーブル146に情
報がある場合は（ステップ154）、SIPスタックプログラム21が判明したコンタクトアドレ
ス宛にメッセージを中継する（ステップ157）。一方、ローカルロケーションテーブル146
に情報が存在しない場合には（ステップ154）、ロケーションDB制御プログラム148が、外
部のロケーションDB3の情報を参照する（ステップ155）。他のSIPサーバが応対している
場合を含めて、宛先端末がオンライン状態の場合は、ロケーションDB3にコンタクトアド
レスが登録されていることとする。次に、ロケーションDB3検索の結果、コンタクトアド
レスが解決した場合には（ステップ156）、メッセージを該コンタクトアドレス宛に中継
する（ステップ157）。一方、ロケーションDB3にもコンタクトアドレスが登録されていな
い場合、または端末のアカウント（SIP-URI）自体が存在しない場合には、SIPスタックプ
ログラム21はエラー応答を送信元に返信する（ステップ158）。

アドレス解決プログラム144が宛先ドメイン判定を行った際に、他ドメイン宛のメッセ
ージであると判定した場合は（ステップ150）、DNSクライアントプログラム149がDNSサー
バに問い合せを行う（ステップ151）。次にSIPスタックプログラム21は、アドレス解決し
た場合はメッセージを中継し（ステップ157）、解決しなかった場合はエラー応答を返す
（ステップ158）。
ここではアドレス解決処理の手順に焦点を当てるため、アドレス解決とメッセージ中継ま
たはエラー応答との間を直結して説明を簡略化しているが、実際のSIPサーバの動作では
、認証処理や呼状態管理処理や固有のフィルタ処理などが、メッセージ中継またはエラー
応答前に実施されることもある。

図１６は、アプリケーションサーバを用いる場合におけるSIP負荷分散システムの一構
成例を示す図である。プレゼンスサーバや会議サーバなどのアプリケーションサーバの設
置例としては、SIP負荷分散装置1と同一ドメイン内に設置する例160と他ドメインに設置
する例162が考えられる。他ドメインに設置する場合162、アプリケーションサーバ発のSI
Pメッセージは、一旦、アプリケーションサーバ162と同一ドメイン内のSIPサーバ4に送ら
れる。そのメッセージの宛先がドメインA内に属する端末宛であった場合は、SIPサーバ4
経由でSIP負荷分散装置1に送られてくるので、この時のメッセージ送受信処理は図１１に
示した実施例と同様である。一方、SIP負荷分散装置1と同一ドメイン内に設置されたアプ
リケーションサーバ160の場合は、これを端点（End Point）の端末とみなして端末2と同
様に扱うか、それともサーバ2とは別のSIP負荷分散装置1配下のサーバとみなして、他ド
メインのSIPサーバ4経由のメッセージを受信する場合と同様に扱うかで、SIP負荷分散装
置1の動作が異なる。

端末2と同様に扱う場合、アプリケーションサーバ160には図３で説明した端末2と同様
の動作が求められる。このように、アプリケーションサーバを端末と同様に扱うことによ
って、アプリケーションサーバ発のリクエストも負荷分散の対象として扱うことができる
。

一方、他ドメインのSIPサーバ4と同様に扱う場合、SIP負荷分散装置1およびSIP負荷分
散装置配下の複数台のSIPサーバ2と相互に接続するサーバのアドレスをアドレスリストと
して保持し、SIP負荷分散装置1の送信元判定プログラム22がこのアドレスリストにアプリ
ケーションサーバ160のアドレスも加えて管理制御すると良い。このように、アプリケー
ションサーバを他ドメインのSIPサーバと同様に扱うことによって、リダイレクト応答に
対応する機能を有さないアプリケーションサーバ発のリクエストも負荷分散の対象として
扱うことができる。

また、これまで説明したシステム構成図では、SIP負荷分散装置1と複数台のSIPサーバ2
は、それぞれ独立した装置であるように描いているが、これらのサーバ装置をブレードサ
ーバのような、同一筐体の装置を構成する各サーバブレードで動作させても構わない。更
に、アプリケーションサーバ160のサーバモジュールもブレードサーバ内に同居させて、
同一のブレードサーバ装置で動かしても構わない。このように、ブレードサーバ内に同居
させることによって、統一的な監視制御を行える。また、サーバを一台一台並べる場合に
比べて、省スペース化が実現できる。

以上、本実施例のSIP負荷分散装置を用いることにより、受信したリクエストメッセー
ジの直前の送信元が自ドメインの端末だった場合には、負荷分散管理テーブルの情報に基
づき応対するSIPサーバを決定し、リダイレクト応答を使って応対するSIPサーバのアドレ
スを通知するため、以降の端末からの通信（暗号化通信を含む）ではSIP負荷分散装置を
介さず、且つ、適切なSIPサーバに負荷分散することができる。特に、応対するSIPサーバ
のアドレスを端末に通知した後は、SIP負荷分散装置は端末からの通信に介在する必要が
無いため、暗号化通信を行う際にSIP負荷分散装置で暗号化通信を終端しなければならな
いメッセージ数が減り、SIP負荷分散装置がボトルネックとならないようにすることがで
きる。

同様に、受信したリクエストメッセージの直前の送信元が自ドメインの端末以外だった
場合にも、負荷分散管理テーブルを参照して宛先端末が接続しているSIPサーバを調べ、
ステートレスプロキシとして当該SIPサーバにメッセージを中継するため、以降の通信で
はSIP負荷分散装置を介さず、端末が継続的なコネクションを確立しているSIPサーバにメ
ッセージを振り分けることができる。

本発明の通信方法は、非暗号化通信においても同様にSIPサーバの負荷分散が実現でき
るため、暗号化通信と非暗号化通信が混在するSIPシステムにも適用できる。

SIP負荷分散装置の一構成例を示す図。本発明の実施形態に係わるSIP負荷分散システムの一構成例を示す図。端末を応対するSIPサーバに誘導する手順の一例を示すシーケンス図。端末がSIP負荷分散装置に送るメッセージの一例を示す図。応対するSIPサーバのアドレスを通知するリダイレクト応答のメッセージの一例を示す図。端末が応対するSIPサーバに送るメッセージの一例を示す図。負荷分散管理テーブルの一例を示すテーブル図。 SIP負荷分散装置で割り当てたSIPサーバの利用有効期限を制御する方法の一例を示すシーケンス図。 SIP負荷分散装置に許可されていないSIPサーバを端末が利用することを防止する方法の一例を示すシーケンス図。拡張ロケーションテーブルの一例を示すテーブル図。 SIP負荷分散システムにおける、ドメインを跨るメッセージ送受信処理の一例を示す方式説明図。 SIP負荷分散装置のパケット受信時の処理手順の一例を示すフローチャート。同一ドメイン内の端末間通信の一例を示す方式説明図。 SIPサーバの一構成例を示す図。 SIPサーバにおける中継先アドレス解決処理の一例を示すフローチャート。アプリケーションサーバを用いる場合におけるSIP負荷分散システムの一構成例を示す図。

符号の説明

１０． CPU
１２．ネットワークインターフェース
１４．記憶装置
１６．メモリ
２０．通信制御部
２１． SIPスタック部
２２．送信元判定手段
２３．リダイレクト機能
２４．ステートレスプロキシ機能
２５．負荷分散管理手段
２６．負荷分散管理テーブル
２７．ロケーション制御手段。

Claims

自ドメイン内の複数の端末と複数のサーバと他ドメインのパケット送信元に接続された負荷分散装置であって、
ペイロードを含むパケットを受信する送受信部と、
記憶装置と、
受信したパケットの送信元を前記ペイロードに記述された情報に基づいて判定する制御部とを有し、
上記記憶装置は、自ドメイン内の端末と該端末に関するセッション制御を行うサーバとの対応関係を記憶しており、
上記制御部の上記判定の結果、送信元が上記自ドメイン内の端末であると判定された場合には、上記複数のサーバのうち該端末に関するセッション制御を行うサーバを上記対応関係に基づいて決定し、該決定されたサーバのアドレスを上記送受信部を介して該端末に通知し、
上記制御部の上記判定の結果、送信元が上記他ドメインのパケット送信元であると判定された場合には、前記ペイロードに記述される情報により特定される自ドメイン内の端末に関するセッション制御を行うサーバに上記パケットを上記送受信部を介して送信し、
さらに、上記対応関係には有効期限が設定されており、該有効期限を過ぎた場合には、上記自ドメイン内の端末からの接続及び上記自ドメイン内の端末への接続を拒否することを特徴とする負荷分散装置。
請求項１記載の負荷分散装置であって、
上記判定の結果、送信元が上記他ドメインのパケット送信元であると判定された場合には、上記対応関係を参照して前記ペイロードに記述される情報により特定される自ドメイン内の端末に関するセッション制御を行うサーバを検索し、検索された上記サーバに上記パケットを上記送受信部を介して送信することを特徴とする負荷分散装置。
請求項１記載の負荷分散装置であって、
上記判定の結果、送信元が上記自ドメイン内の端末であると判定された場合には、上記対応関係を参照し、利用端末数が最も少ないサーバを該端末に関するセッション制御を行うサーバと決定することを特徴とする負荷分散装置。
自ドメイン内の複数の端末と他ドメインのパケット送信元とに接続された負荷分散システムであって、
複数のサーバと負荷分散装置を備え、
該負荷分散装置は、
ペイロードを含むパケットを受信する送受信部と、
記憶装置と、
前記ペイロードに記述された情報に基づいて受信したパケットの送信元を判定する制御部を有し、
上記記憶装置は、上記自ドメイン内の複数の端末のアドレスと該端末に関するセッション制御を行うサーバの対応関係を記憶しており、
上記判定の結果、送信元が上記自ドメイン内の端末であると判定された場合には、上記複数のサーバのうち該端末に関するセッション制御を行うサーバを決定し、該決定されたサーバのアドレスを上記送受信部を介して該端末に通知し、
上記判定の結果、送信元が上記他ドメインのパケット送信元であると判定された場合には、前記ペイロードに記述される情報により特定される自ドメイン内の端末に関するセッション制御を行うサーバに上記パケットを上記送受信部を介して送信し、
さらに、上記対応関係には有効期限が設定されており、該有効期限を過ぎた場合には、上記負荷分散装置は上記自ドメイン内の端末からの接続及び上記自ドメイン内の端末への接続を拒否することを特徴とする負荷分散システム。
請求項４記載の負荷分散システムであって、上記負荷分散装置は、上記判定の結果、送信元が上記他ドメインのパケット送信元であると判定された場合には、上記対応関係を参照して前記ペイロードに記述される情報により特定される自ドメイン内の端末に関するセッション制御を行うサーバを検索し、検索された上記サーバに上記パケットを上記送受信部を介して送信することを特徴とする負荷分散システム。
請求項４記載の負荷分散システムであって、
上記負荷分散装置は、上記判定の結果、送信元が上記自ドメイン内の端末であると判定された場合には、上記対応関係を参照し、利用端末数が最も少ないサーバを該端末に関するセッション制御を行うサーバと決定することを特徴とする負荷分散システム。