(57)【要約】【課題】  可用性を高める。【解決手段】  クライアント装置が、サーバ装置を継続して利用し続けるための通信システムにおいて、前記クライアント装置は、当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用する。また、前記コネクションは、複数のプロトコル階層について同時に確保し、正常な通信が実行不能か否かは各プロトコル階層ごとに独立に検査して、いずれか１つのプロトコル階層で正常な通信が実行不能となったときには、前記系切替えを実行することも好ましい。【選択図】  図１
2006287417.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置が、サーバ装置を継続して利用し続けるための通信システムにおいて、
前記クライアント装置は、
当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用することを特徴とする通信システム。
【請求項２】
請求項１の通信システムにおいて、
前記コネクションは、複数のプロトコル階層について同時に確保し、正常な通信が実行不能か否かは各プロトコル階層ごとに独立に検査して、いずれか１つのプロトコル階層で正常な通信が実行不能となったときには、前記系切替えを実行することを特徴とする通信システム。
【請求項３】
請求項１の通信システムにおいて、
前記待機系サーバ装置は、前記クライアント装置以外のクライアント装置にとって、現在、利用している現用系サーバ装置であることを特徴とする通信システム。
【請求項４】
クライアント装置が、サーバ装置を継続して利用し続けるための通信方法において、
前記クライアント装置は、
当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用することを特徴とする通信方法。
【請求項５】
クライアント装置が、サーバ装置を継続して利用し続けるための通信プログラムにおいて、
前記クライアント装置およびサーバ装置では、コンピュータに、
当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用する機能を実現させることを特徴とする通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システム、通信方法、および通信プログラムに関し、例えば、呼制御エンド端末に対して呼制御サービスを提供する呼制御サーバが、クライアントとして、データベースサーバを利用する場合などに適用して好適なものである。
【背景技術】
【０００２】
従来、ＳＩＰサーバなどの呼制御サーバは、ＩＰ電話機などの呼制御エンド端末に対して、呼制御サービスを提供しているが、この呼制御サービスの提供のためにアドレス解決を行うには、データベースサーバが管理しているＩＰアドレスと電話番号の対応を記録した情報など検索する必要がある。この検索に関して、呼制御サーバは、データベースサーバに対するクライアントとして機能する。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、呼制御サーバが、２４時間３６５日、無停止で呼制御サービスを提供しつづけるためには、必要が生じたらいつでもデータベースサーバを利用可能な状態を維持することが不可欠であるが、実際には、例えば、データベースサーバと呼制御サーバを接続するネットワークの障害や、データベースサーバ自体の障害などによって、データベースサーバを利用可能な状態を維持できなくなることがある。
【０００４】
冗長構成を取り、現用系と待機系の複数のデータベースサーバを用意しておき、現用系のデータベースサーバとの通信が正常に行えなくなったら系切替えを実行して待機系のデータベースサーバを利用することことも考えられる。しかしながら、ＩＰ電話に用いられるデータベースサーバは１台で膨大な数および範囲の電話番号とＩＰアドレスの対応を蓄積しており、地理的にかなり離れた位置に配置される（例えば、日本全国を地理的に分散して配置された４台のデータベースサーバでカバーする）のが普通であるため呼制御サーバ（呼制御サーバは、例えば、地理的に分散配置された１３台で日本全国をカバーする）との物理的な伝送距離も長くなるし、基本的にネットワークに接続された全ての通信装置が対等な分散制御環境では、系切替えに伴うオーバーヘッドも多くなる傾向が強いため、このような系切替えを高速で行うのは難しい面がある。例えば、系切替えを行うため、それまで待機系であったデータベースサーバとのコネクションを設定する目的でパケットを送信しても、そのパケットは基本的に、同じネットワークに接続された他の通信装置が送信するパケットと対等に処理されるから、コネクションを設定するまでに相当な時間を要する可能性がある。
【０００５】
系切替えに要する時間、すなわち、呼制御サーバがそれまで待機系であったデータベースサーバに利用開始を要求してから実際に利用できるまでの時間が長くなると、常時、ＩＰ電話機から発生し得る呼制御サービス提供の要求に応じることができなくなって可用性が低下してしまう。
【課題を解決するための手段】
【０００６】
かかる課題を解決するために、第１の本発明では、クライアント装置が、サーバ装置を継続して利用し続けるための通信システムにおいて、前記クライアント装置は、当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用することを特徴とする。
【０００７】
また、第２の本発明では、クライアント装置が、サーバ装置を継続して利用し続けるための通信方法において、前記クライアント装置は、当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用することを特徴とする。
【０００８】
さらに、第３の本発明では、クライアント装置が、サーバ装置を継続して利用し続けるための通信プログラムにおいて、前記クライアント装置およびサーバ装置では、コンピュータに、当該クライアント装置が現在、利用している現用系サーバ装置および、現在、利用していない待機系サーバ装置に対するコネクションを予め確保しておき、前記現用系サーバ装置との正常な通信が実行不能となったことを検知した場合には、系切替えを実行して前記待機系サーバ装置を利用する機能を実現させることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、可用性を極めて高い水準にまで高めることができる。
【発明を実施するための最良の形態】
【００１０】
（Ａ）実施形態
以下、本発明にかかる通信システム、通信方法、および通信プログラムを、ＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。
【００１１】
（Ａ−１）実施形態の構成
本実施形態にかかるＶｏＩＰ通信システム２０の全体構成例を図５に示す。なお、当該ＶｏＩＰ通信システム２０中に、図示しないサーバ類（例えば、ＤＮＳサーバなど）が存在していてもよいことは当然である。
【００１２】
図５において、当該ＶｏＩＰ通信システム２０は、インターネット２１と、コールサーバ２２、２７と、データベースサーバ群２３，２４と、ＩＰ電話機２５，２６とを備えている。
【００１３】
このうちインターネット２１はその他のネットワークに置換可能であるが、本実施形態では、インターネットを想定する。
【００１４】
コールサーバ２２は、インターネット２１経由でＩＰ電話機に呼制御サービスなどの各種サービスを提供するサーバである。当該コールサーバ２２は、例えば、ＳＩＰサーバなどに該当する。当該コールサーバ２２は、上述したように、例えば、日本全国に１３台分散配置されているコールサーバのうちの１つであってよい。
【００１５】
コールサーバ２７も当該コールサーバ２２と同様な機能を持つ通信装置であるが、配置されている地域が異なる。ここでは一例として、コールサーバ２２は東京に配置され、コールサーバ２７は大阪に配置されているものとする。
【００１６】
データベースサーバ群２３は、アドレス解決のための情報やプレゼンス情報などを蓄積しているデータベースサーバのうち、同一の地域（例えば、東京）に配置されたものの集合体である。データベースサーバ群２３は、上述したように、例えば、日本全国に４台分散配置されているデータベースサーバの一部であってもよい。ただし本実施形態では、当該データベースサーバ群２３には、３台のデータベースサーバ２３Ａ〜２３Ｃが含まれているものとする。
【００１７】
これらのデータベースサーバ２３Ａ〜２３Ｃは、負荷分散によって、前記コールサーバ２２からの検索要求のレスポンス性能を高めるためのものなので、３台に蓄積されている情報は、基本的にすべて同じものである。負荷分散では、前記検索要求が発生したときに、３台のデータベースサーバ２３Ａ〜２３Ｃのうち、例えば、最も負荷の少ないデータベースサーバに当該検索要求を振り分けること等によりレスポンス性能を高めるものだからである。
【００１８】
データベースサーバ群２４は配置される地域（例えば、大阪に配置される）が異なるだけで、基本的に当該データベースサーバ群２３と同じものである。当該データベースサーバ群２４は３台のデータベースサーバ２４Ａ〜２４Ｃによって構成され、これらのデータベースサーバ２４Ａ〜２４Ｃにはすべて、前記データベースサーバ２３Ａ〜２３Ｃに蓄積されているものと同じ情報が蓄積されている。
【００１９】
コールサーバ２２は配置された地域が同じか、または、近いデータベースサーバ群を用いたほうが、インターネット２１上の伝送遅延によるレスポンス性能の低下を防止できるため、例えば、上述したようにコールサーバ２２が東京に配置されているものとすると、通常は、同じ東京に配置された前記データベースサーバ群２３を利用するが、当該データベースサーバ群２３を利用することができなくなったときには、データベースサーバ群２４を用いる。すなわち、コールサーバ２２にとって、通常、現用系のデータベースサーバ群は２３で、待機系のデータベースサーバ群は２４であるが、データベースサーバ群２３を利用することができなくなったときには、系切替えを実行し、データベースサーバ群２３を待機系、データベースサーバ群２４を現用系とする。
【００２０】
データベースサーバ群を利用することができなくなるのは、例えば、そのデータベースサーバ群（ここでは、２３）自体に障害が発生して利用不能となったケースや、データベースサーバ群を構成する一部のデータベースサーバ（例えば、２３Ａと２３Ｂ）に障害が発生して十分な負荷分散が実行できなくなり、レスポンス性能が所定値以下に低下したケースや、インターネット２１上などで、コールサーバ２２と当該データベースサーバ群をつなぐ伝送経路が障害発生によって正常に機能しなくなったケースなどである。
【００２１】
なお、この現用系と予備系の関係は、配置された地域が異なるコールサーバ２７では逆になる。すなわち、大阪に配置される前記コールサーバ２７にとっては、通常、データベースサーバ群２４が現用系であり、データベースサーバ群２３は予備系である。
【００２２】
前記ＩＰ電話機２５，２６は、前記コールサーバ２２が提供する呼制御サービスなどを利用する通信端末である。ＩＰ電話機２５はユーザＵ１によって利用され、ＩＰ電話機２６はユーザＵ２によって利用される。
【００２３】
例えば、ユーザＵ１が、ＩＰ電話機２５をオフフックしてＩＰ電話機２６の電話番号をダイヤルすると、ＩＰ電話機２５との呼設定を要求する呼設定メッセージ（ＩＰ電話機２５の電話番号が含まれている）がコールサーバ２２に送信され、コールサーバ２２は、当該電話番号を検索キーとする前記検索要求を送信することにより、データベースサーバ群２３からＩＰ電話機２６のＩＰアドレスを取得し、当該ＩＰアドレスを宛先ＩＰアドレスとするパケットに前記呼設定メッセージを収容して、インターネット２１に送出する。このパケットがインターネット２１上のルータによって転送され、呼設定メッセージがＩＰ電話機２６まで届く。
【００２４】
以下、上記のような構成を有する本実施形態の動作について図１〜図４を参照しながら説明する。
【００２５】
図４はコールサーバ２２がデータベースサーバ（例えば、２３Ａ〜２３Ｃおよび２４Ａ〜２４Ｃ）に対して行うヘルスチェックのための動作例を示すフローチャートで、Ｓ１０〜Ｓ３０の各ステップを備えている。
【００２６】
図１は、データベースサーバ群２３を構成する各データベースサーバとコールサーバ２２のあいだにおけるコネクションの設定に関連する動作を示す概略図で、Ｓ１〜Ｓ３の各ステップを備えている。図２は図１につづく動作を示し、Ｓ４、Ｓ５の各ステップを備えている。
【００２７】
図３は、データベースサーバ群２３および２４を構成する各データベースサーバとコールサーバ２２とのあいだにおけるコネクションの設定の様子を示す概略図である。
【００２８】
（Ａ−２）実施形態の動作
処理の大きな流れとして、前記コールサーバ２２は、図１に示すように、起動時に各データベースサーバ（例えば、２３Ａ〜２３Ｃ）とのコネクションを確保する（Ｓ１）。このコネクションは広義のＴＣＰ／ＩＰのコネクション（例えば、ＴＣＰコネクション）であるが、コールサーバ２２は、このコネクションの設定とともに、複数のプロトコル階層にわたるヘルスチェックを実行する。
【００２９】
前記ステップＳ１につづくステップＳ２では、各プロトコル階層ごとのヘルスチェックを開始する。このヘルスチェックの詳細については後で説明するが、コールサーバ２２が、データベースサーバ（例えば、２３Ａ）を利用するためには、そのデータベースサーバに関するすべてのプロトコル階層のヘルスチェック結果が正常なものであることが必要である。
【００３０】
いずれのデータベースサーバに対するいずれのプロトコル階層のヘルスチェックでも異常が検出されない場合には、前記負荷分散は、前記検索要求の負荷を３台のデータベースサーバ２３Ａ〜２３Ｃのあいだで分散することによって実現される。なお、例えば、図２に示すように、この３台のうち１台（図示の例では、２３Ｃ）についていずれかのプロトコル階層で異常が検出された場合（Ｓ４）、コールサーバ２２は、その１台とのコネクションを使用しないようにして（Ｓ５）、残りの２台（２３Ａ、２３Ｂ）で負荷分散を行うことも可能である。ただしこの場合、２台の負荷分散で十分なレスポンス性能が得られることが必要となる。
【００３１】
なお、図１、図２では、データベースサーバ群２３の各データベースサーバ２３Ａ〜２３Ｃについてのみ説明したが、同様な処理は、図３に示すように、データベースサーバ群２４内の各データベースサーバ２４Ａ〜２４Ｃについても実行され得る。
【００３２】
ただし、コールサーバ２２は同じ東京に配置されているデータベースサーバ群２３を優先的に利用し（Ｓ４）、大阪に配置されたデータベースサーバ群２４は、データベースサーバ群２３を利用することができないときにのみ利用する（Ｓ５）。
【００３３】
すなわち、上述したように、コールサーバ２２は、通常、データベースサーバ群２３を現用系とし、データベースサーバ群２４を待機系としている。ただし、本実施形態のコールサーバ２２は常時、図３に示すように、現用系のデータベースサーバ群２３に含まれる各データベースサーバ２３Ａ〜２３Ｃとともに、待機系のデータベースサーバ群２４に含まれる各データベースサーバ２４Ａ〜２４Ｃに対してもコネクションの設定を行っている。
【００３４】
これにより、系切替えを行い、それまで待機系であったデータベースサーバ群２４を現用系として利用するときには、すでに設定されているコネクションを利用することができる。この場合、新たにコネクションを設定する時間を必要としないから、２４時間３６５日、無停止で呼制御サービスを提供することが可能である。
【００３５】
なお、系切替えを実行したあとの動作は、現用系と待機系が入れ替わった以外、基本的に、系切替えの前と同じであってよい。ただし、コールサーバ２２は同じ東京に配置されたデータベースサーバ群２３を優先的に利用するため、今回の系切替えによって現用系となったデータベースサーバ群２４のヘルスチェックで特段、異常が検出されなくても、データベースサーバ群２３のヘルスチェック結果が正常なものとなれば、再度、系切替えを行って、データベースサーバ群２３を現用系とする。コールサーバ２２に対し地理的に近いデータベースサーバ群２３のほうが、伝送遅延も小さく、品質の高い呼制御サービスを提供できるからである。
【００３６】
前記ステップＳ２で実行されるヘルスチェックは、データベースサーバ群２３，２４内の全データベースサーバ２３Ａ〜２３Ｃおよび２４Ａ〜２４Ｃに対して実行されるもので、プロトコル階層ごとに、フェーズ４〜フェーズ１（ＰＨ４〜ＰＨ１）に分かれる。
【００３７】
このうちＰＨ４が最も下位の階層に対応し、ＰＨ１が最も上位の階層に対応する。
【００３８】
ＰＨ４はＯＳＩ参照モデルのネットワーク層に相当する階層である。この階層でのヘルスチェックは、ｐｉｎｇを用いて行われ、データベースサーバ（例えば、２３Ａ）内のＩＣＭＰプロセスからＩＣＭＰエコー応答メッセージが届くか否かを確認する。
【００３９】
ＰＨ３はＯＳＩ参照モデルのトランスポート層に相当する階層である。この階層でのヘルスチェックは、データベースサーバ（例えば、２３Ａ）内のＬｉｓｔｅｎポート（Ｌｉｓｔｅｎｅｒプロセス）からの応答の有無を確認する。
【００４０】
ＰＨ２はＯＳＩ参照モデルのセッション層などに相当し得る階層である。この階層でのヘルスチェックは、データベースサーバ側のデータベースプロセスが新規セッションの確立に応じるか否かを確認する。
【００４１】
ＰＨ１はＯＳＩ参照モデルのアプリケーション層などに相当し得る階層である。この階層でのヘルスチェックは、データベースサーバから情報を収集可能であるかを確認する。
【００４２】
これらＰＨ４〜ＰＨ１のヘルスチェックは例えば図４のフローチャートに示す手順で実行される。
【００４３】
図４において、コールサーバ２２内でプロセスが起動され、監視スレッドが生成されると（Ｓ１０）、ヘルスチェックは、下位のＰＨ４から上位のＰＨ１へ向かう順番で処理される。ただし、図４の例では、ネットワークや機器の特性がｐｉｎｇによるヘルスチェックに対するストレスが軽いケースを想定しているため、ｐｉｎｇによるヘルスチェックは、ＰＨ４以外の、ＰＨ２，ＰＨ１でも実行されている。
【００４４】
ＰＨ４のステップＳ１１におけるｐｉｎｇのヘルスチェックの結果が異常なケース（ＩＣＭＰエコー応答メッセージが届かないケース）では、復旧監視のため所定の待ち時間（例えば、１秒間）を経て（Ｓ１２）、ステップＳ１１が繰り返される。最下位の階層であるＰＨ４のヘルスチェックで異常な結果が出るということは、パケットの伝送自体が正常に行えず、上位のフェーズで有効なヘルスチェックを行うことができない状態であるから、上位のフェーズには移行しない。
【００４５】
なお、ステップＳ１２の待ち時間は、このように固定値とせず、乱数などを用いてランダムに変化する時間としてもよい。障害の発生状況によっては、日本全国の１３台のコールサーバからほぼ同時にｐｉｎｇのヘルスチェックが実行されて、データベースサーバ側に過大な負荷が発生すること等も起こり得るため、待ち時間をランダムに変化させることも望ましい。
【００４６】
ステップＳ１１のヘルスチェックの結果が正常となると、ステップＳ１３のトラップでステップＳ１１の処理を中断し、ＰＨ３のステップＳ１４を実行する。ステップＳ１４では、上述したデータベースサーバ（例えば、２３Ａ）内のＬｉｓｔｅｎポート（Ｌｉｓｔｅｎｅｒプロセス）からの応答の有無を確認する。ステップＳ１４によるヘルスチェックの結果が異常な場合には、所定の待ち時間を置いて（Ｓ１５）処理は前記ステップＳ１１に戻り、正常な場合には、再開中であるか否かを検査する（Ｓ１６）。再開中である場合、処理はステップＳ１８に進み、それ以外の場合には、ステップＳ１７に進む。ステップＳ１７では、前記ステップＳ１１と同様、ｐｉｎｇによるヘルスチェックが行われる。このヘルスチェックの結果が異常であると、処理は、前記ステップＳ１１に戻り、正常であるとステップＳ１８に進む。
【００４７】
ステップＳ１８では、上述したように、データベースサーバ側のデータベースプロセスが新規セッションの確立に応じるか否かを確認する。確認の結果、異常であれば、所定の待ち時間を置いて（Ｓ１９）処理はステップＳ１４に戻り、正常であれば再開中であるか否かを検査する（Ｓ２０）。再開中であれば、処理はステップＳ２２に進み、それ以外の場合には、ステップＳ２３に進む。
【００４８】
ステップＳ２２では、セッションプールを確立できるか否かを検査する。検査の結果、異常が生じて確立できなかった場合には、所定の待ち時間を置いて（Ｓ２１）、処理はステップＳ１６に戻るが、確立できた場合には、前記ステップＳ２３に進む。
【００４９】
ステップＳ２３では、再開中か否かを検査し、再開中である場合には、処理はステップＳ２６に進み、それ以外の場合には、ステップＳ２４に進む。
【００５０】
ステップＳ２４ではまた、ｐｉｎｇによるヘルスチェックを行い、ヘルスチェックの結果が異常である場合には、トラップで処理を中断して（Ｓ２５）ステップＳ１５に戻り、正常である場合には、セッションプールを利用してデータベースサーバから情報を収集可能であるか否かを確認する（Ｓ２６）。確認の結果、異常である場合（収集不能な場合）にはトラップでデータベースの処理を中断（Ｓ２７）したうえ待ち置換を置いて（Ｓ１９）ステップＳ１６に戻り、正常である場合には、所定の待ち時間を置いて通常運用時の監視を行う（Ｓ３０）。ここまで処理が進んだということは、ＰＨ４からＰＨ１までの全階層のヘルスチェックの結果が正常であったということなので、通常運用時の監視を実行することになる。
【００５１】
なお、前記コールサーバ２２がデータベースサーバ（例えば、２３Ｃ）を利用できるのは、そのデータベースサーバに対するヘルスチェックで、ＰＨ４からＰＨ１までの全階層のヘルスチェックの結果が正常であり、そのデータベースサーバに対して通常運用時の監視が行われているケースに限られる。
【００５２】
（Ａ−３）実施形態の効果
以上のように、本実施形態によれば、可用性を極めて高い水準にまで高めることができる。
【００５３】
（Ｂ）他の実施形態
上記実施形態では、１つのデータベースサーバ群内のデータベースサーバの数は３つであったが、この数は３つに限定する必要はない。
【００５４】
また、上記実施形態では、データベースサーバ群の数が２つの場合を例に説明したが、データベースサーバ群の数が３つ以上であってもよいことは当然である。例えば、データベースサーバ群が３つ以上ある場合には、待機系のデータベースサーバ群（例えば、２４）に異常が発生したことを検出したとき、コールサーバ２２は、第３のデータベースサーバ群とのコネクションを設定して、今後、発生し得る系切替えに備えるようにしてもよい。
【００５５】
さらに、図４のフローチャートは様々な変形が可能である。
【００５６】
例えば、ＰＨ４以外のフェーズ（ＰＨ１，ＰＨ２）で行っているステップＳ２４やＳ１７のｐｉｎｇを用いたヘルスチェックは省略してもかまわない。また、図４では、上位のフェーズのヘルスチェックの結果が異常となったときには、下位のフェーズへ処理を戻す構成となっているが、戻す先は様々に変更が可能である。例えば、ステップＳ１８のヘルスチェックの結果が異常となった場合、図４に示したようにステップＳ１４に戻すのではなく、ステップＳ１１へ戻すようにしてもよい。
【００５７】
上記実施形態では、ＶｏＩＰ通信システムを例に説明したが、本発明は、ＶｏＩＰ通信システム以外に適用できる可能性がある。
【００５８】
また、上記実施形態で例示した通信プロトコルは他の通信プロトコルに置換可能である。例えばＩＰプロトコルは、一例として、ＩＰＸプロトコルなどに置換できる可能性があり、ＳＩＰプロトコルも他の通信プロトコルに置換できる可能性がある。
【００５９】
以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんど全ては、ハードウエア的に実現することが可能である。
【図面の簡単な説明】
【００６０】
【図１】実施形態で使用するＶｏＩＰ通信システムの動作例を示す概略図である。
【図２】実施形態で使用するＶｏＩＰ通信システムの動作例を示す概略図である。
【図３】実施形態で使用するＶｏＩＰ通信システムの動作例を示す概略図である。
【図４】実施形態で使用するコールサーバの動作例を示す概略図である。
【図５】実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。
【符号の説明】
【００６１】
２０…ＶｏＩＰ通信システム、２１…インターネット、２２…コールサーバ、２３，２４…データベースサーバ群、２５，２６…ＩＰ電話機、２３Ａ〜２３Ｃ、２４Ａ〜２４Ｃ…データベースサーバ。
【図１】
2006287417.tif 000003
【図２】
2006287417.tif 000004
【図３】
2006287417.tif 000005
【図４】
2006287417.tif 000006
【図５】
2006287417.tif 000007