JP2014007617A - 呼制御サーバ、通信システム、および呼制御方法 - Google Patents

Abstract

【課題】 呼制御サーバが故障しても、呼制御ログを一次保存する記憶装置などを必要とせずに呼接続を継続し、システム停止となる可能性が低く、信頼性の高い呼制御サーバ、および通信システムを得ることを目的とする。
【解決手段】 通常動作時に、他の呼制御サーバから他の呼制御サーバが制御する第２のＩＰ端末の第２の端末情報が転送されることにより、例えば、他の呼制御サーバと第２のＩＰ端末との通信に障害が発生した場合に、第２のＩＰ端末から発信先である第１のＩＰ端末の電話番号を受信し、第１のＩＰ端末から送信されて記憶している第１のＩＰ端末の電話番号に対応するアドレス情報を検索して第２のＩＰ端末に送信するので、外部記憶装置を必要とすることなく、他の呼制御サーバに障害が発生した場合にも、第１のＩＰ端末と第２のＩＰ端末の通信を可能にすることができる。
【選択図】 図１

Description

本発明は、電話通信システムのＩＰ端末を制御する呼制御サーバに関するものである。

近年、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークの発展により、音声信号をＩＰパケット化して伝送するＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）技術の普及が進んでいる。ＶｏＩＰによる電話通信システムは、音声パケットを送受信して音声通話を行うＩＰ電話端末（以降、単にＩＰ端末という）と、ＩＰ端末の電話番号と電話番号に対応するアドレス情報などを管理してＩＰ端末どうしの通信を制御する呼制御サーバから構成される。

呼制御サーバは、通常ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）と呼ばれる呼制御プロトコルを用いてＩＰ端末とメッセージを交換し、各種呼制御を行う。
ＶｏＩＰによる電話通信システムでは、従来の公衆電話網のように電話番号とＩＰ端末が接続されるアクセス回線とが対応付けられていない。そのため、各ＩＰ端末を特定するアドレス情報として、そのＩＰアドレスやＵＲＩ(Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ)等のネットワークアドレスが用いられる。

そこで、ＳＩＰでは、例えばＩＰ端末が所定の呼制御サーバへ、自身のＩＰアドレスや電話番号を含む各種端末情報を起動時や端末情報変更時に登録する。そして、ＩＰ端末が他のＩＰ端末に発信する場合、端末情報を登録した呼制御サーバに発信先のＩＰ端末の電話番号を伝える。
呼制御サーバは、ＩＰ端末から発信先の他のＩＰ端末の電話番号を受信すると、発信先の他のＩＰ端末の電話番号に対応したＩＰアドレスを登録されている端末情報から検索して特定し、特定した発信先の電話番号に対応したＩＰアドレスを発信元のＩＰ端末（発信先の他のＩＰ端末の電話番号を送信してきたＩＰ端末）に送信する。呼制御サーバのこのような機能により、発信元のＩＰ端末が発信先の他のＩＰ端末のＩＰアドレスがわからなくても、ＩＰ端末どうしの通信が行える。

このような電話通信システムにおいて呼制御サーバが故障すると、全ての音声通信が出来なくなる。そこで、呼制御サーバを二重化してシステムの信頼性を上げる方法が各種検討されている。
例えば、呼制御サーバを二重化するシステムとして、運用中の呼制御サーバ、待機中の呼制御サーバ、および呼制御ログを一時保存する外部記憶装置を備え、運用中の呼制御サーバは常に呼制御ログを外部記憶装置に書き出すというものがある。このシステムでは、運用中の呼制御サーバが故障すると待機中の呼制御サーバに切り替えられる。この切替えにおいて、待機中の呼制御サーバは外部記憶装置に書き込まれた呼制御ログから運用に必要な情報を得るため、運用中の呼制御サーバが故障しても、待機中の呼制御サーバによりＩＰ端末どうしの通信が可能となる（特許文献１）。

特許第４４２５８４１号

従来の呼制御サーバの技術では、外部記憶装置の設置が必要である。また、外部記憶装置に障害が発生した場合には、待機中の呼制御サーバは外部記憶装置に書き込まれた呼制御ログから必要な情報を得ることができずにＩＰ端末どうしの通信ができなくなるという課題があった。

この発明に係る呼制御サーバは、複数のＩＰ端末を制御する呼制御サーバにおいて、第１の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第１の端末情報を前記第１のＩＰ端末から受信すると共に、他の呼制御サーバが制御する第２の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第２の端末情報を前記他の呼制御サーバから転送されて受信する受信部、該受信部で受信した前記第１の端末情報と前記第２の端末情報を記憶する記憶部、前記第２のＩＰ端末から前記第１のＩＰ端末の電話番号を前記受信部で受信すると、前記第１のＩＰ端末の電話番号に対応したアドレス情報を前記記憶部から検索し、前記第１のＩＰ端末から前記第２のＩＰ端末の電話番号を前記受信部で受信すると、前記第２のＩＰ端末の電話番号に対応したアドレス情報を前記記憶部から検索する検索部、該検索部で検索した前記第１のＩＰ端末のアドレス情報を前記第２のＩＰ端末に送信し、前記検索部で検索した前記第２のＩＰ端末のアドレス情報を前記第１のＩＰ端末に送信する送信部、を備えたものである。

この発明は、通常動作時に、他の呼制御サーバから他の呼制御サーバが制御する第２のＩＰ端末の第２の端末情報が転送されることにより、例えば、他の呼制御サーバと第２のＩＰ端末との通信に障害が発生した場合に、第２のＩＰ端末から発信先である第１のＩＰ端末の電話番号を受信し、第１のＩＰ端末から送信されて記憶している第１のＩＰ端末の電話番号に対応するアドレス情報を検索して第２のＩＰ端末に送信するので、外部記憶装置を必要とすることなく、他の呼制御サーバに障害が発生した場合にも、第１のＩＰ端末と第２のＩＰ端末の通信を可能にすることができる。

この発明の実施の形態１における通信システム１の構成図である。 この発明の実施の形態１における呼制御サーバ２の内部構成図である。 この発明の実施の形態１における通信システム１のＳＩＰメッセージシーケンスである。 この発明の実施の形態１におけるＳＩＰ端末が呼制御サーバ２に対して送信するＲＥＧＩＳＴＥＲリクエストの内容である。 この発明の実施の形態１における呼制御サーバ２が故障した場合のＳＩＰメッセージシーケンスである。 この発明の実施の形態２における通信システム１のＳＩＰメッセージシーケンスである。 この発明の実施の形態２における呼制御サーバ２が故障した場合のＳＩＰメッセージシーケンスである。 この発明の実施の形態３における通信システム１のＳＩＰメッセージシーケンスである。 この発明の実施の形態３におけるＳＩＰ端末４が呼制御サーバ２に対して送信する通常のＩＮＶＩＴＥリクエストの内容である。 この発明の実施の形態３における呼制御サーバ２が故障した場合に、ＳＩＰ端末４が呼制御サーバ２に対して送信するＩＮＶＩＴＥリクエストの内容である。 この発明の実施の形態３における呼制御サーバ２の内部構成図である。 この発明の実施の形態３における故障していない呼制御サーバ２がＳIＰ端末４に送信する故障サーバ情報を含むＩＮＦＯリクエストの内容である。 この発明の実施の形態３におけるＳＩＰ端末４がサーバの故障を検出した場合のＳＩＰメッセージシーケンスである。 この発明の実施の形態４における呼制御サーバ２の内部構成図である。 この発明の実施の形態４における呼制御サーバ２が他の故障した呼制御サーバ２を検出してＳＩＰ端末４に通知する場合のＳＩＰメッセージシーケンスである。 この発明の実施の形態５におけるＳＩＰ端末４が呼制御サーバ２に対して優先呼制御サーバであることを通知するＲＥＧＩＳＴＥＲリクエストの内容である。

実施の形態１．
図１は、この発明の実施の形態１おける通信システム１の構成図である。
通信システム１は、ＳＩＰ端末の電話番号と電話番号に対応するＩＰアドレスを管理して、ＳＩＰ端末４ａ〜４ｎの呼接続を制御する呼制御サーバ２ａ及び２ｂ、ＳＩＰメッセージや音声パケットなどのＩＰパケットを伝送するＩＰ網３、音声通信を行うＳＩＰ端末４ａ、４ｂ、〜４ｎで構成される。

また、図２は、この発明の実施の形態１における通信システム１の呼制御サーバ２（２ａ，２ｂ）の内部構成図である。
図２において、呼制御サーバ２は、ＳＩＰメッセージのリクエスト及び応答の送受信の制御を行うＳＩＰメッセージ送受信部２１、ＳＩＰ端末４の電話番号と電話番号に対応したＩＰアドレスを含む端末情報を保存する端末情報保存部２２、ＳＩＰメッセージを転送するかどうかを判定する転送判定部２３、ＳＩＰ端末４の電話番号に対応するＩＰアドレスを検索するアドレス検索部２４から構成される。

ＳＩＰメッセージ送受信部２１のＳＩＰメッセージを受信する部分が受信部に相当し、ＳＩＰメッセージを送信する部分が送信部に相当する。また、端末情報保存部２２が記憶部に相当し、アドレス検索部２４が検索部に相当する。

また、図３は、この発明の実施の形態１における通信システム１のＳＩＰメッセージシーケンスである。
以下、図３に示すメッセージシーケンスを、図２を参照しながら説明する。
尚、以下の説明において、図３に示したＳＩＰ端末４ａとＳＩＰ端末４ｂには、呼制御サーバ２ａと呼制御サーバ２ｂのＩＰアドレスが予め設定などにより与えられているものとする。
また、呼制御サーバ２ａと呼制御サーバ２ｂには、互いのＩＰアドレスが予め設定などにより与えられているものとする。

ＳＩＰ端末４ａとＳＩＰ端末４ｂが起動すると、呼制御サーバ２ａまたは呼制御サーバ２ｂのどちらかに自端末の電話番号とＩＰアドレスを含むＲＥＧＩＳＴＥＲリクエスト（ＳＩＰ端末４が自端末の端末情報の登録を呼制御サーバ２に要求する登録要求）を送信する。
ここでは、ＳＩＰ端末４が起動し、呼制御サーバ２にＲＥＧＩＳＴＥＲリクエストを送信するのは、ＳＩＰ端末４に電源が投入され、初期設定時にＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２に送信する場合であるとして説明する。

例えば、ＳＩＰ端末４ａは、自端末を制御する呼制御サーバ２を呼制御サーバ２ａと決め、ＲＥＧＩＳＴＥＲリクエストを送信する。
ＳＩＰ端末４ａが自端末を制御する呼制御サーバ２を呼制御サーバ２ａと決めるのは、予め設定されているとして説明する。呼制御サーバ２の決め方は、他に、呼制御サーバ２の優先順位のリストを持っていて、リスト順で呼制御サーバ２ａを決定するとしてもよい。

ＳＩＰ端末４ａが自端末を制御する呼制御サーバ２を呼制御サーバ２ａと決め、ＲＥＧＩＳＴＥＲリクエストを送信する際には、ＲＥＧＩＳＴＥＲリクエストの宛先に自端末を制御する呼制御サーバ２ａのＩＰアドレスを指定する。

以上の様に、ここでは、ＳＩＰ端末４ａが起動すると、自端末を制御する呼制御サーバ２を呼制御サーバ２ａに決定して呼制御サーバ２ａにＲＥＧＩＳＴＥＲリクエストを送信し、ＳＩＰ端末４ｂが起動すると、自端末を管理する呼制御サーバ２を呼制御サーバ２ｂに決定して呼制御サーバ２ｂにＲＥＧＩＳＴＥＲリクエストを送信するものとして説明する。

図３は、ＳＩＰ端末４ａ、４ｂが起動してから、通話開始・完了までのＳＩＰメッセージシーケンスである。
図３に示す通り、ＳＩＰ端末４ａが起動すると、ＳＩＰ端末４ａは、宛先に呼制御サーバ２ａのＩＰアドレスを指定し、自端末の電話番号とＩＰアドレスを含むＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ａに送信する。

また、ＳＩＰ端末４ｂが起動すると、ＳＩＰ端末４ｂは、宛先に呼制御サーバ２ｂのＩＰアドレスを指定し、自端末の電話番号とＩＰアドレスを含むＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ｂに送信する。

ここで、ＳＩＰ端末４ａ、４ｂが起動して、ＳＩＰ端末４ａ、４ｂが呼制御サーバ２ａ、及び呼制御サーバ２ｂにＲＥＧＩＳＴＥＲリクエストを送信し、呼制御サーバ２ａ、及び呼制御サーバ２ｂがＲＥＧＩＳＴＥＲリクエストを受信した場合の呼制御サーバ２の内部の動作について、図２を用いて説明する。

まず、ＳＩＰメッセージ送受信部２１が、ＳＩＰ端末４から受信したリクエストがＲＥＧＩＳＴＥＲリクエストか否かを判定する。ＲＥＧＩＳＴＥＲリクエストであれば、ＳＩＰ端末４の電話番号とＩＰアドレスの端末情報を保存（記憶）するために端末情報保存部（記憶部）２２に出力し、同時に転送判定部２３に出力する。

次に、端末情報保存部２２が、ＲＥＧＩＳＴＥＲリクエストからＳＩＰ端末４の電話番号とＩＰアドレスを抜き出して、ＳＩＰ端末４の電話番号と電話番号に対応するＩＰアドレスの端末情報を保存し、応答指示をＳＩＰメッセージ送受信部２１に出力する。

次に、ＳＩＰメッセージ送受信部２１がこの応答指示を受けると、ＳＩＰ端末４から受信したＲＥＧＩＳＴＥＲリクエストに対して成功応答（２００ＯＫ）を生成して、ＲＥＧＩＳＴＥＲリクエストの送信元のＳＩＰ端末４に生成した成功応答を送信する。

次に、転送判定部２３が、ＲＥＧＩＳＴＥＲリクエストのリクエストライン（例えば、ＲＥＧＩＳＴＥＲリクエストの１行目）を参照して自装置宛のＲＥＧＩＳＴＥＲリクエストか否かを判定する。

自装置宛のＲＥＧＩＳＴＥＲリクエストであれば、転送指示をＳＩＰメッセージ送受信部２１に出力する。
自装置宛のＲＥＧＩＳＴＥＲリクエストではなく、他の呼制御サーバから転送されたＲＥＧＩＳＴＥＲリクエストであれば転送指示は出力しない（何もしない）。
ＳＩＰメッセージ送受信部２１は、転送判定部２３から転送指示を受けると、自装置以外の呼制御サーバ２にＲＥＧＩＳＴＥＲリクエストを転送する。

本実施の形態１では、図３に示すように、ＳＩＰ端末４ａから呼制御サーバ２ａにＲＥＧＩＳＴＥＲリクエストを送信し（リクエストラインの宛先に呼制御サーバ２ａのＩＰアドレスを指定し）、呼制御サーバ２ａが呼制御サーバ２ｂにＳＩＰ端末４ａの端末情報を転送する。また、ＳＩＰ端末４ｂから呼制御サーバ４ｂにＲＥＧＩＳＴＥＲリクエストを送信し（リクエストラインの宛先に呼制御サーバ２ｂのＩＰアドレスを指定し）、呼制御サーバ２ｂが呼制御サーバ２ａにＳＩＰ端末４ｂの端末情報を転送する。

ここで、転送判定部２３がＲＥＧＩＳＴＥＲリクエストを参照して、どのようにＲＥＧＩＳＴＥＲリクエストが自装置宛であるか否かを判定するか、について説明する。
転送判定部２３が自装置宛のＲＥＧＩＳＴＥＲリクエストか否かを判定するのは、リクエストラインの情報による。
図４は、ＳＩＰ端末４ａが呼制御サーバ２ａに対して送信するＲＥＧＩＳＴＥＲリクエストの内容の例である。

このリクエストラインの宛先に、自分自身（自装置、ここでは呼制御サーバ２ａ）のＩＰアドレスまたはＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ）が示されていれば、自装置宛てであると判定する。
また、他の呼制御サーバ（呼制御サーバ２ｂ）のＩＰアドレスが示されていれば、他の呼制御サーバから転送されてきたＲＥＧＩＳＴＥＲリクエストであると判定する。

例えば、呼制御サーバ２ａのＩＰアドレスが「１９２．１６８．０．１」であって、図４の１行目に示すように、ＲＥＧＩＳＴＥＲ ｓｉｐ：１９２．１６８．０．１の記述があれば、ＳＩＰ端末４ａから自装置に送信されたＲＥＧＩＳＴＥＲリクエストであると判定する。
このように、転送判定部２３は、ＲＥＧＩＳＴＥＲリクエストを参照してＲＥＧＩＳＴＥＲリクエストが自装置宛であるか否かを判定する。

次に、転送判定部２３でＲＥＧＩＳＴＥＲリクエストが自装置宛に送信されたと判定されると、ＳＩＰメッセージ送受信部２１が、そのＲＥＧＩＳＴＥＲリクエストを他の呼制御サーバである呼制御サーバ２ｂに転送する。

ここで、ＲＥＧＩＳＴＥＲリクエストを転送する処理について説明する。
ＲＥＧＩＳＴＥＲリクエストの転送指示が、転送判定部２３からＳＩＰメッセージ送受信部２１に入力されると、ＳＩＰメッセージ送受信部２１は、ＳＩＰ端末４ａから受け取ったＲＥＧＩＳＴＥＲリクエストに、転送先である呼制御サーバ２ｂのＩＰアドレスをパケットのＩＰヘッダの宛先として付加して呼制御サーバ２ｂに転送する。

ＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ａから転送された呼制御サーバ２ｂは、ＲＥＧＩＳＴＥＲリクエストのリクエストラインの宛先は自装置（呼制御サーバ２ｂ）宛ではないため、呼制御サーバ２ｂは受け取りＲＥＧＩＳＴＥＲリクエストに含まれるＩＰ端末の端末情報を端末情報保存部に記憶し、転送指示は出さない。
このように、転送判定部２３は、ＲＥＧＩＳＴＥＲリクエストのリクエストラインの宛先が自装置のＩＰアドレスであるか否かにより、ＲＥＧＩＳＴＥＲリクエストが自装置宛であるか否かを判定する。

ＲＥＧＩＳＴＥＲリクエストが自装置宛であれば、そのＲＥＧＩＳＴＥＲリクエストを他の制御サーバ２ｂに転送する転送指示をＳＩＰメッセージ送受信部２１に出力する。
一方、ＲＥＧＩＳＴＥＲリクエストが自装置宛でなければ（他の呼制御サーバ２から転送されたものであれば）、ＲＥＧＩＳＴＥＲリクエストの転送指示は出力せず何もしない。
ここまでが、自装置宛に送信されたＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２aが受信した場合の呼制御サーバ２aの内部の動作の説明である。

次に、図３を用いて、呼制御サーバ２がＳＩＰ端末４からＲＥＧＩＳＴＥＲリクエストを受信した時の呼制御サーバ２とＩＰ端末４の動作について説明する。
呼制御サーバ２ａがＳＩＰ端末４ａからＲＥＧＩＳＴＥＲリクエストを受信すると、呼制御サーバ２ａはその成功応答（２００ ＯＫ）をＳＩＰ端末４ａに送信すると共に、このＲＥＧＩＳＴＥＲリクエスト（ＳＩＰ端末４ａの端末情報を含む）を呼制御サーバ２ｂに転送する。
この時、呼制御サーバ２ａの内部の処理では、ＳＩＰ端末４ａの端末情報を図２の端末情報保存部２２に保存する。

そして、呼制御サーバ２ｂは、呼制御サーバ２ａから転送されたＳＩＰ端末４ａのＲＥＧＩＳＴＥＲリクエストに対して成功応答（２００ ＯＫ）を呼制御サーバ２ａに返す。
この時、呼制御サーバ２ｂの内部の処理では、呼制御サーバ２ａから転送されたＳＩＰ端末４ａの端末情報を図２の端末情報保存部２２に保存する。

同様に、呼制御サーバ２ｂがＳＩＰ端４ｂからＲＥＧＩＳＴＥＲリクエストを受信すると、呼制御サーバ２ｂはその成功応答（２００ ＯＫ）をＳＩＰ端末４ｂに送信すると共に、このＲＥＧＩＳＴＥＲリクエスト（ＳＩＰ端末４ｂの端末情報を含む）を呼制御サーバ２ａに転送する。
この時、呼制御サーバ２ｂの内部の処理では、ＳＩＰ端末４ｂの端末情報を図２の端末情報保存部２２に保存する。

そして、呼制御サーバ２ａは、呼制御サーバ２ｂから転送されたＳＩＰ端末４ｂからのＲＥＧＩＳＴＥＲリクエストに対して成功応答（２００ ＯＫ）を呼制御サーバ２ｂに返す。
この時、呼制御サーバ２ａの内部の処理では、呼制御サーバ２ｂから転送されたＳＩＰ端末４ｂの端末情報を端末情報保存部２２に保存する。

このように呼制御サーバ２ａと呼制御サーバ２ｂが、ＳＩＰ端末４ａとＳＩＰ端末４ｂから受信した端末情報をお互いに転送することで、呼制御サーバ２ａ及び呼制御サーバ２ｂは、ＳＩＰ端末４ａとＳＩＰ端末４ｂの両方のアドレス情報（端末情報）を保持（記憶）することになる。

次に、図３で、ＳＩＰ端末４ａからＳＩＰ端末４ｂに対して発信する場合について説明する。
ＳＩＰ端末４ａは、発信先であるＳＩＰ端末４ｂのＩＰアドレスを得るため、図３に示す通りＩＮＶＩＴＥリクエスト（ＳＩＰ端末４が他のＳＩＰ端末４との通信を要求する通信要求）を呼制御サーバ２ａに送信する。
尚、このＩＮＶＩＴＥリクエスト（通信要求）のリクエストライン（１行目）には発信先（通信要求先）の電話番号が含まれる。

ここで、呼制御サーバ２ａがＳＩＰ端末４ａからＩＮＶＩＴＥリクエストを受信した場合の呼制御サーバ２の内部の動作について、図２を用いて説明する。
ＳＩＰメッセージ送受信部２１は、ＳＩＰ端末４ａから受信したリクエストがＩＮＶＩＴＥリクエストか否かを判定する。ＩＮＶＩＴＥリクエストであれば、これをアドレス検索部２４に出力する。

アドレス検索部２４は、ＩＮＶＩＴＥリクエストから発信先の電話番号を抜き出し（抽出し）、端末情報保存部２２に保存（記憶）されたアドレス情報（端末情報）を参照して、発信先の電話番号に対応したＩＰアドレスを検索する。

前述したように、端末情報保存部２２には、ＳＩＰ端末４ａとＳＩＰ端末４ｂの端末情報が保存されている。そのため、アドレス検索部２４は、端末情報保存部２２に保存されているアドレス情報から発信先のＳＩＰ端末４ｂの電番号に対応するＩＰアドレス（発信先ＩＰアドレス）を検索してＳＩＰメッセージ送受信部２１に出力する。

ＳＩＰメッセージ送受信部２１は、アドレス検索部２４から入力された発信先ＩＰアドレスを用いてリダイレクト応答（３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ）を生成し、ＳＩＰ端末４ａに送信する。
尚、発信先ＩＰアドレスは、この「３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ」応答のＣｏｎｔａｃｔヘッダに含めて、ＳＩＰ端末４ａに送信される。

呼制御サーバ２ａが上記の通り動作すると、図３に示す通り、ＳＩＰ端末４ａからＩＮＶＩＴＥリクエストを受信した呼制御サーバ２ａは、発信先ＩＰアドレス（ＳＩＰ端末４ｂのＩＰアドレス）を含めた応答（３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ）をＳＩＰ端末４ａに送信する。

このような、呼制御サーバ２ａの内部の動作の概略を説明すると、以下のようになる。
（１）ＩＮＶＩＴＥリクエストが、図２のＳＩＰメッセージ送受信部２１からアドレス検索部２４に入力される。
（２）アドレス検索部２４が、ＩＮＶＩＴＥリクエストから発信先のＳＩＰ端末４ｂの電話番号を抽出する。

（３）アドレス検索部２４が、発信先のＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスを検索する。検索する際には、呼制御サーバ２ｂから転送されて端末情報保存部２２に保存されているＳＩＰ端末４ｂの端末情報を参照する。
（４）アドレス検索部２４が、検索した発信先のＳＩＰ端末４ｂのＩＰアドレスをＳＩＰメッセージ送受信部２１に出力する。

（５）ＳＩＰメッセージ送受信部２１が、Ｃｏｎｔａｃｔヘッダに発信先ＩＰアドレス（ＳＩＰ端末４ｂのＩＰアドレス）を含めた応答（３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ）をＳＩＰ端末４ａに送信する

この様に、呼制御サーバ２ａは、呼制御サーバ２ｂから転送されて記憶している発信先のＳＩＰ端末４ｂの端末情報を参照して、発信先のＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスをＳＩＰ端末４ａへの応答に含めて送信する。

すると、ＳＩＰ端末４ａは、呼制御サーバ２ａからの応答（３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ）を受信したことを通知するＡＣＫリクエストを呼制御サーバ２ａに送信する。

次に、ＳＩＰ端末４ａは、呼制御サーバ２ａから受信した応答の中のＣｏｎｔａｃｔヘッダに含まれるＩＰアドレスに対して（つまりＳＩＰ端末４ｂに対して）、新たなＩＮＶＩＴＥリクエストを送信する。

以降は、ＳＩＰの規定に従い、ＳＩＰ端末４ｂが応答（２００ ＯＫ）を返し、これに対してＳＩＰ端末４ａがＡＣＫリクエストをＳＩＰ端末４ｂに送信することで、呼接続が完了する。このように、呼接続が完了することで、通話が開始される（音声パケットの送受信が開始される（セッションの確立））。
ここまでが、呼制御サーバ２が通常に機能している場合のＳＩＰ端末４と呼制御サーバ２との動作である。

次に、呼制御サーバ２が故障した場合のＳＩＰ端末４と他の呼制御サーバ２（呼制御サーバ２ｂ）との動作について説明する。
図５は、ＳＩＰ端末４ａがＳＩＰ端末４ｂに対して発信する前に、呼制御サーバ２ａが故障した場合のＳＩＰメッセージシーケンスである。
ＳＩＰ端末４ａは、発信先であるＳＩＰ端末４ｂのＩＰアドレスを得るため、発信先のＳＩＰ端末４ｂの電話番号を含めたＩＮＶＩＴＥリクエストを呼制御サーバ２ａに送信する。

しかし、呼制御サーバ２ａが故障したため応答が得られず、ＩＮＶＩＴＥリクエストを再送するが、呼制御サーバ２ａからの応答がない状態で最終的にタイムアウトになる（呼制御サーバ２ａから所定の時間応答がない状態となる）。ＳＩＰの規定では標準的に３２秒経つとタイムアウトとするため、ＳＩＰ端末４ａが呼制御サーバ２ａを故障と判定する。

ＳＩＰ端末４ａは、呼制御サーバ２ａへのＩＮＶＩＴＥリクエストの送信に対する応答のない状態でタイムアウトになると、呼制御サーバ２ｂにＩＮＶＩＴＥリクエストを送信する。
即ち、呼制御サーバ２ｂが、呼制御サーバ２ａに制御されているＳＩＰ端末４ａからＩＮＶＩＴＥリクエストを受信するのは、ＳＩＰ端末４ａが呼制御サーバ２ａを故障と判定した場合となる。

ＳＩＰ端末４ａからＩＮＶＩＴＥリクエストを受信した呼制御サーバ２ｂにも、呼制御サーバ２ａと同じアドレス情報が保存されている（呼制御サーバ２ａからＳＩＰ端末４ａの端末情報が転送され、保存されている）。そのため、呼制御サーバ２ｂは、ＳＩＰ端末４ａから受信した発信先（ＳＩＰ端末４ｂ）の電話番号に対応するＩＰアドレス情報を検索し、検索した発信先のＳＩＰ端末４ｂのＩＰアドレスを含む応答（３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ）をＳＩＰ端末４ａに返す。

この応答を受けることで、ＳＩＰ端末４ａは発信先（ＳＩＰ端末４ｂ）のＩＰアドレスを得る。
以降は、図３と同様なＳＩＰメッセージシーケンスによりＳＩＰ端末４ａとＳＩＰ端末４ｂとの呼接続が行われる。（ＳＩＰ端末４ａとＳＩＰ端末４ｂとのセッションが確立され音声パケットの送受信が可能になる。）

この様な動作をまとめると、ＳＩＰ端末４ａが自端末の端末情報を含めたＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ａに送信することにより、ＳＩＰ端末４ａは呼制御サーバ２ａに制御される。
また、ＳＩＰ端末４ｂが自端末の端末情報を含めたＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ａに送信すると、ＳＩＰ端末４ｂは呼制御サーバ４ｂに制御される。
このような状況で、ＳＩＰ端末４ａがＳＩＰ端末４ｂとの通信を要求する場合、呼制御サーバ２ａが正常に動作していれば、ＳＩＰ端末４ａは、発信先のＳＩＰ端末４ｂの電話番号を含めたＩＮＶＩＴＥリクエストを呼制御サーバ２ａに送信する。

すると、呼制御サーバ２ａは、呼制御サーバ２ｂから転送されて記憶しているＳＩＰ端末４ｂの電話番号に対するＩＰアドレスを検索して、発信先のＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスを含めた応答をＳＩＰ端末４ａに送信する。

もし、呼制御サーバ２ａに障害が発生、または呼制御サーバ２ａとＳＩＰ端末４ａとの通信に障害が発生して、ＳＩＰ端末４ａがＩＮＶＩＴＥリクエストに対する応答を呼制御サーバ２ａから受け取ることができなければ、ＳＩＰ端末４ａは発信先のＳＩＰ端末４ｂの電話番号を含むＩＮＶＩＴＥリクエストを呼制御サーバ２ｂに送信する。

呼制御サーバ２ｂ側から説明すると、呼制御サーバ２ｂは、他の呼制御サーバである呼制御サーバ２ａに制御されているＳＩＰ端末４ａから発信先の電話番号（自装置が制御しているＳＩＰ端末４ｂの電話番号）を含むＩＮＶＩＴＥリクエストを受信する。

すると、呼制御サーバ２ｂは、自装置が制御するＳＩＰ端末４ｂから受け取り、記憶している端末情報に基づいて、ＳＩＰ端末４ｂの電話番号に対応したＩＰアドレスを検索して、発信先のＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスを含めた応答をＳＩＰ端末４ａに送信する。

そのため、例えば、呼制御サーバ４ａに故障などの障害が発生、または呼制御サーバ２ａとＳＩＰ端末４ａとの通信に障害が発生しても、ＳＩＰ端末４ａは発信先のＳＩＰ端末４ｂと呼接続を継続することができる。

以上のように、本実施の形態によれば、呼制御サーバ２ａ、２ｂはＳＩＰ端末４ａ、４ｂから受信したＲＥＧＩＳＴＥＲリクエストを他の呼制御サーバに転送するため、呼制御サーバが全てのＳＩＰ端末４のアドレス情報（端末情報）を保存（記憶）することができる。

更に、ＳＩＰ端末４ａは、発信先であるＳＩＰ端末４ｂとの通信を要求する際に、ＩＮＶＩＴＥリクエストを呼制御サーバ２ａに送信して、呼制御サーバ２ａから応答がない場合に、呼制御サーバ２ｂにＩＮＶＩＴＥリクエスト（発信先のＳＩＰ端末４ｂの電話番号を含む）を送信する。そして、呼制御サーバ２ｂから発信先のＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスを受け取り、呼接続を継続することが出来る。

そのため、例えば、呼制御サーバ２ａが故障、あるは呼制御サーバ２ａとの通信に障害が発生しても、外部記憶装置や故障を監視する装置等を必要とせずに、呼制御サーバ２ｂが呼制御サーバ２ａの代わり呼制御を継続することができる。
また、ＳＩＰ端末４ａから呼制御サーバ２ａに送信したＩＮＶＩＴＥリクエストに対して所定の時間応答がない場合に、他の呼制御サーバである呼制御サーバ２ｂにＩＮＶＩＴＥリクエストを送信するため、例えば、ＳＩＰ端末４ａと呼制御サーバ２ａとの間に通信の障害が発生した場合にも、呼制御を継続することができる。
このように、呼制御サーバ２ａが故障、あるは呼制御サーバ２ａとの通信に障害が発生しても、呼接続を継続することができるため、システム停止となる可能性が低く、信頼性の高い通信システム及び呼制御サーバを得ることが出来る。

尚、ＳＩＰ端末４がＲＥＧＩＳＴＥＲリクエストを送信する呼制御サーバ２は、例えば優先順位で呼制御サーバ２のＩＰアドレスをリストとして保持しており、そのリスト順に従って呼制御サーバ２のＩＰアドレスにＲＥＧＩＳＴＥＲリクエストを送信するとしてもよい。もし、ＲＥＧＩＳＴＥＲリクエストの送信が上手くいかなければ、リストの次の呼制御サーバ２のＩＰアドレスにＲＥＧＩＳＴＥＲリクエストを送信することになる。

また、呼制御サーバ２ａが制御するＳＩＰ端末４ａ１とＳＩＰ端末４ａ２があり、例えば呼制御サーバ２ａにＳＩＰ端末４ａ２との通信を要求するＩＮＶＩＴＥリクエストを送信して、所定の時間応答がない場合に、ＳＩＰ端末４ａ１が呼制御サーバ２ａを故障と判定する。そして、ＳＩＰ端末４ａ１がＳＩＰ端末４ａ２との通信を要求するＩＮＶＩＴＥリクエストを呼制御サーバ２ｂに送信してきた場合にも、呼制御サーバ２ａから転送されてＳＩＰ端末４ａ２の端末情報を記憶している呼制御サーバ２ｂは、ＳＩＰ端末４ａ２の電話番号に対応したＩＰアドレスをＳＩＰ端末４ａ１に送信する。そのため呼制御サーバ２ａが故障と判定されても、その呼制御サーバ２ａが制御するＳＩＰ端末４ａどうしの通信を制御することができる。

実施の形態２．
実施の形態１では、ＳＩＰ端末４が呼制御サーバ２にＩＮＶＩＴＥリクエストを送信し、その応答から発信先ＳＩＰ端末４のＩＰアドレスを得て、発信先ＳＩＰ端末４に新たなＩＮＶＩＴＥリクエストを送信したが、サーバ側にＩＮＶＩＴＥリクエストを転送する機能があっても良い。
その場合、図３に示したシーケンスは図６に示すように変わり、図５に示したシーケンスは図７に示すように変わる。

図６は、呼制御サーバ２にＩＮＶＩＴＥリクエストを転送する機能がある場合に、ＳＩＰ端末４ａと４ｂが起動してから、発信元のＳＩＰ端末４ａと発信先のＳＩＰ端末４ｂの通話を開始して完了するまでのＳＩＰメッセージシーケンスである。
また、図７は、呼制御サーバ２にＩＮＶＩＴＥリクエストを転送する機能がある場合であって、ＳＩＰ端末４ａがＳＩＰ端末４ｂに対して発信する前に、呼制御サーバ２ａが故障した場合のＳＩＰメッセージシーケンスである。
図６において、ＳＩＰ端末４ａが発信先であるＳＩＰ端末４ｂのＩＰアドレスを得るために、ＩＮＶＩＴＥリクエストを呼制御サーバ２ａに送信するところまでは、実施の形態１の図３と同様である。

この時の呼制御サーバ２ａの内部の動作について図２を用いて説明する。
（１）ＳＩＰ端末４ａから送信されたＩＮＶＩＴＥリクエストをＳＩＰメッセージ送受信部２１で受信し、ＳＩＰメッセージ送受信部２１から入力されたＩＮＶＩＴＥリクエストに含まれる発信先のＳＩＰ端末４ｂの電話番号をアドレス検索部２４が抽出する。
（２）抽出したＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスを端末情報保存部２２から取得する。呼制御サーバ２ａは、呼制御サーバ２ｂから転送されてＳＩＰ端末４ｂの端末情報を端末情報保存部２２に保存している。そのため、ＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスを端末情報保存部２２から検索して取得することができる。

（３）取得したＳＩＰ端末４ｂの電話番号に対応するＩＰアドレスに従って、ＳＩＰ端末４ｂにＩＮＶＩＴＥリクエストをＳＩＰメッセージ送受信部２１から送信し、ＳＩＰ端末４ｂから応答（２００ ＯＫ）をＳＩＰメッセージ送受信部２１が受信する。この応答には、ＳＩＰ端末４ｂのＩＰアドレスが含まれている。
（４）更に、ＳＩＰ端末４ａに応答（２００ ＯＫ）をＳＩＰメッセージ送受信部２１から送信。この応答に、ＳＩＰ端末４ｂのＩＰアドレスが含まれている。
ここまでが、呼制御サーバ２ａの内部の動作である。

このように、呼制御サーバ２ａからＳＩＰ端末４ａにＳＩＰ端末４ｂのＩＰアドレスが含まれる応答（２００ ＯＫ）が送信されると、ＳＩＰ端末４ａは、応答を受信したことを通知するＡＣＫリクエストを呼制御サーバ２ａに送信する。
そして、更に、呼制御サーバ４ａは、ＳＩＰ端末４ａからの応答を受信したことを通知するＡＣＫリクエストをＳＩＰ端末４ｂに送信することで、呼接続が完了し、ＳＩＰ端末４ａとＳＩＰ端末４ｂとの通話が開始される（セッションが確立され、音声パケットの送受信が開始される）。

本実施の形態によっても、呼制御サーバ２ａと２ｂは、ＳＩＰ端末４ａとＳＩＰ端末４ｂから受信したＲＥＧＩＳＴＥＲリクエストを他の呼制御サーバに転送する。そのため、呼制御サーバ２ａと呼制御サーバ２ｂのそれぞれが制御している全てのＳＩＰ端末４（図１のＳＩＰ端末４ａ〜４ｎ）のアドレス情報を保存することが可能となる。

そして、ＳＩＰ端末４ａがＳＩＰ端末４ｂへの発信時に、例えば、図７のように、呼制御サーバ２ａにＳＩＰ端末４ａがＩＮＶＩＴＥリクエストを送信しても呼制御サーバ２ａからの応答がなく、呼制御サーバ２ａが故障であると判定した場合に、他の呼制御サーバである呼制御サーバ２ｂにＩＮＶＩＴＥリクエストを送信する。そうすることにより、呼接続を継続することが出来る。従って、呼制御サーバが故障してもシステム停止となる可能性が低く、信頼性の高い通信システムおよび呼制御サーバを得ることが出来る。

実施の形態３．
上記実施の形態１では、呼制御サーバ２ａが故障した場合、ＳＩＰ端末４ａが呼制御サーバ２ａにＩＮＶＩＴＥリクエストを送信して、その応答を呼制御サーバ２ａから受信しようとして、受信できない状態でタイムアウトになると、ＳＩＰ端末４ａは呼制御サーバ２ａを故障と判定して、呼制御サーバ２ｂへのＩＮＶＩＴＥリクエスト送信に切替える。そのため、タイムアウトになるまでの呼接続時間が長くなる。
本実施の形態においては、呼制御サーバ２ａが故障した時の呼接続時間を短くする実施形態を示す。

図８は、この発明の実施の形態３における通信システム１のＳＩＰメッセージシーケンスである。
この図は、ＳＩＰ端末４ａからＳＩＰ端末４ｂに発信する際に、ＳＩＰ端末４ａが呼制御サーバ２ａを故障と判定して、呼制御サーバ２ｂにＩＮＶＩＴＥリクエストを送信することで、ＳＩＰ端末４ａとＳＩＰ端末４ｂとの呼接続及び呼切断が完了するまでのシーケンスである。
ＳＩＰ端末４ａがＳＩＰ端末４ｂにＩＮＶＩＴＥリクエストを送信して応答を受信し、ＡＣＫリクエストを送信するまでは、図５に示したシーケンスと同様である。
但し、ＳＩＰ端末４ａが、呼制御サーバ２ｂに送信するＩＮＶＩＴＥリクエスト内に、呼制御サーバ２ａが故障したことを通知する情報を含める点が図５の場合と異なる。

図９は、ＳＩＰ端末４ａがＳＩＰ端末４ｂに発信する場合に、ＳＩＰ端末４ａが呼制御サーバ２ｂに対して送信するＩＮＶＩＴＥリクエストの内容を示している。
これに対して、図１０は、図９で示したＩＮＶＩＴＥリクエストに、呼制御サーバ２ａが故障したことを通知する故障サーバ情報を含めた内容を示している。

これらの図は、呼制御サーバ２ａのＩＰアドレスが「１９２．１６８．０．１」、呼制御サーバ２ｂのＩＰアドレスが「１９２．１６８．０．２」、ＳＩＰ端末４ａのＩＰアドレスが「１９２．１６８．０．３１」、ＳＩＰ端末４ｂのＩＰアドレスが「１９２．１６８．０．３２」である場合の例である。
図１０の９行目には、図９に示した内容にＯｒｇａｎｉｚａｔｉｏｎヘッダが追加されている。Ｏｒｇａｎｉｚａｔｉｏｎヘッダには故障サーバ情報「ｓｅｒｖｅｒ ｆａｕｌｔ １９２．１６８．０．１」（１９２．１６８．０．１が故障した呼制御サーバ２ａのＩＰアドレス）が含まれている。

このヘッダは、ＩＮＶＩＴＥリクエストに含めることが出来るオプションのヘッダであり、通常はリクエストを送信する端末が所属する組織名などを提供するために用いられるが、ＳＩＰ規定において呼制御に直接関わるヘッダではなく、任意の文章や文字列を含むことが出来る。
そこで、このＩＮＩＶＩＴＥリクエストでは、Ｏｒｇａｎｉｚａｔｉｏｎヘッダによって、サーバが故障したことと、故障したサーバのＩＰアドレスを通知する。

次に、図１０に示した故障サーバ情報を含むＩＮＶＩＴＥリクエストを呼制御サーバ２が受けた場合の動作について、図１１に示す呼制御サーバ２の内部構成図を用いて説明する。
図１１は、実施の形態３における呼制御サーバ２の内部構成図である。
図１１の呼制御サーバ２の内部構成は、実施の形態１で示した図２の内部構成に故障サーバ情報抽出部２５が追加されたものである。また、図１１のＳＩＰメッセージ送受信部２１の動作は、図２に示したＳＩＰメッセージ送受信部２１と異なる。
図１１の端末情報保存部２２、転送判定部２３、アドレス検索部２４の動作については、図２に示した呼制御サーバ２の内部構成の場合と同様である。

ＳＩＰメッセージ送受信部２１は、受信したリクエストがＩＮＶＩＴＥリクエストか否かを判定し、ＩＮＶＩＴＥリクエストであればこれをアドレス検索部２４に出力すると共に、故障サーバ情報抽出部２５にも出力する。
または、受信したリクエストがＲＥＧＩＳＴＥＲリクエストか否かを判定し、ＲＥＧＩＳＴＥＲリクエストであればこれを端末情報保存部２２と転送判定部２３に出力すると共に、故障サーバ情報抽出部２５にも出力する。
故障サーバ情報抽出部２５は、ＳＩＰメッセージ送受信部２１で受信した受信リクエストの中から故障したサーバの情報を抽出する。

故障サーバ情報抽出部２５は、ＩＮＶＩＴＥリクエスト及びＲＥＧＩＳＴＥＲリクエスト中にＯｒｇａｎｉｚａｔｉｏｎヘッダがあるか否かを検索し、これが無ければ何もしない。
Ｏｒｇａｎｉｚａｔｉｏｎヘッダがある場合は、Ｏｒｇａｎｉｚａｔｉｏｎヘッダの内容を故障サーバ情報とし、更に、端末情報保存部２２に保存されている全てのアドレス情報の中からこのリクエストの発信元以外のＩＰアドレスを抜き出して、このＩＰアドレスを送信先のアドレス情報とし、これらの故障サーバ情報と送信先のアドレス情報をＳＩＰメッセージ送受信部２１に出力する。

ＳＩＰメッセージ送受信部２１は、故障サーバ情報抽出部２５から故障サーバ情報と送信先のアドレス情報を受けると、送信先のアドレス情報で指定される全てのＳＩＰ端末４に対して故障サーバ情報を含めたＩＮＦＯリクエストを送信する。
以上が呼制御サーバ２の内部の動作である。
呼制御サーバ２ｂが以上のように動作すると、図８に示すシーケンスにおいて、呼制御サーバ２ｂはＳＩＰ端末４ａからＩＮＶＩＴＥリクエストを受けた後、ＩＮＦＯリクエストをＳＩＰ端末４ｂに送信する。

図１２は、呼制御サーバ２ｂがＳＩＰ端末４ａからＩＮＶＩＴＥリクエストを受けて、呼制御サーバ２ａがＳＩＰ端末４ｂに送信する故障サーバ情報を含めたＩＮＦＯリクエストの内容を示している。
このＩＮＦＯリクエストにもＯｒｇａｎｉｚａｔｉｏｎヘッダが含まれており、ＳＩＰ端末４ｂは呼制御サーバ２ａの故障を知ることが出来る。

上述のように、ＳＩＰ端末４ａから呼制御サーバ２ａへ送信したＩＮＶＩＴＥリクエストに対して呼制御サーバ２ａからの応答がない状態でタイムアウトになれば、ＩＰ端末４ａは呼制御サーバ２ａが故障していると判定し、ＳＩＰ端末４ａは呼制御サーバ４ｂに故障サーバ情報を送信する。すると、故障サーバ情報を含むＩＮＦＯリクエストが呼制御サーバ２ｂからＳＩＰ端末４ｂに送信される。そのため、ＳＩＰ端末４ｂは呼制御サーバ２ａの故障を認識（検出）することが出来る。
以降、ＳＩＰ端末４ａおよびＳＩＰ端末４ｂは、ＳＩＰ端末４ａが故障と判定した呼制御サーバ２ａにＩＮＶＩＴＥリクエストを送信せず、呼制御サーバ２ｂに送信するので、呼接続時間が長くならない。

尚、ＳＩＰ端末４が呼制御サーバ２に送信するＲＥＧＩＳＴＥＲリクエストによるアドレス情報には、通常、有効期限があり、これが失効する前に再度ＲＥＧＩＳＴＥＲリクエストの送信が行われる。
従って、ＳＩＰ端末４がこのような有効期限の失効により再度ＲＥＧＩＳＴＥＲリクエストを送信する際に、呼制御サーバ２からの応答がない状態でタイムアウトになった場合にも、呼制御サーバ２の故障と認識（判定）する。そして、この故障サーバ情報を他の呼制御サーバ２に通知し、通知された呼制御サーバ２は、故障サーバ情報を送信してきたＳＩＰ端末４を除く全てのＳＩＰ端末４に故障サーバ情報を通知する。

図１３は、ＳＩＰ端末４ａがＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ａに再送信する際にサーバの故障を認識した場合のＳＩＰメッセージシーケンスである。
ＳＩＰ端末４ａはＲＥＧＩＳＴＥＲリクエストの再送信によって呼制御サーバ２ａの故障を認識し、呼制御サーバ２ｂにＲＥＧＩＳＴＥＲリクエストを送信する際、呼制御サーバ２ａの故障を通知する。

通知の方法は、上記ＩＮＶＩＴＥリクエスト送信の場合と同様であり、Ｏｒｇａｎｉｚａｔｉｏｎヘッダによって通知する。
呼制御サーバ２ｂは、このＲＥＧＩＳＴＥＲリクエストを受信することによって呼制御サーバ２ａの故障を認識し、ＳＩＰ端末４ｂに対してＩＮＦＯリクエストを送信することによってこの故障を通知する。

以上のように、本実施の形態によれば、ＳＩＰ端末４ａが呼制御サーバ２ａへ送信するＩＮＶＩＴＥリクエストまたはＲＥＧＩＳＴＥＲリクエストに対する応答がない状態でタイムアウトになると、ＳＩＰ端末４ａが呼制御サーバ２ａを故障と判定する。すると、故障と判定した呼制御サーバのＩＰアドレスを含む故障サーバ情報を他の呼制御サーバ２ｂに通知する。そして、この通知を受けた呼制御サーバ２ｂは、端末情報保存部２２に保存しているＳＩＰ端末４のＩＰアドレスのうち故障サーバ情報を送信してきたＳＩＰ端末４ａを除くＳＩＰ端末４に、故障サーバ情報を通知する。そのため、ＳＩＰ端末４ａを除く他のＳＩＰ端末４は、以降、ＩＮＶＩＴＥリクエストを故障したサーバに送信しなくて済む。

従って、実施の形態１と同様に、呼制御サーバ２が故障、あるは呼制御サーバ２ａとの通信に障害が発生しても、呼制御サーバ２の外部記憶装置や故障を監視する装置等を必要とせずに呼接続を継続することができる。そのため、システム停止となる可能性が低く、信頼性の高い通信システム１および呼制御サーバ２を得ることが出来る。
更に、ＳＩＰ端末４ａが呼制御サーバ２ａを故障と判定すると、故障と判定した呼制御サーバ２ａのＩＰアドレスを含む故障サーバ情報をＩＮＦＯリクエストとして故障していない呼制御サーバ２ｂに送信し、呼制御サーバ２ｂがＳＩＰ端末４ａを除く他のＳＩＰ端末４に故障サーバ情報を送信するため、他のＳＩＰ端末４から故障した呼制御サーバ２への呼接続時間が長くなることを防止することができる。

実施の形態４．
呼制御サーバ２ｂがＳＩＰ端末４ｂから受信したＲＥＧＩＳＴＥＲリクエストを他の呼制御サーバ２ａに転送する時、ＲＥＧＩＳＴＥＲリクエストの応答がない状態でタイムアウトになることにより、転送先の呼制御サーバ２ａの故障を認識（故障と判定）することが出来る。
本実施の形態においては、呼制御サーバ２ｂが他の呼制御サーバ２ａの故障を検出し、その故障を検出した呼制御サーバ２ａのＩＰアドレスを含む故障サーバ情報を実施の形態３の図１１で説明した故障サーバ情報抽出部２５が作成して、全てのＳＩＰ端末４に通知する実施の形態を示す。
ここでは、故障サーバ情報抽出部２５が故障サーバ情報を生成するとして説明するが、故障サーバ情報生成部が故障サーバ情報を生成するとしてもよい。

図１４は、この発明の実施の形態４による呼制御サーバ２の内部構成図である。
図１４の呼制御サーバ２の内部構成は、実施の形態３で示した図１１の呼制御サーバ２の内部構成と同様であり、この図において、転送判定部２３、端末情報保存部２２、アドレス検索部２４の動作については、実施の形態３の図１１に示した呼制御サーバ２の内部構成の場合と同様である。

そして、転送判定部２３からの指示によってＲＥＧＩＳＴＥＲリクエストを転送した場合、その転送に対して呼制御サーバ２ａから応答がない状態でタイムアウトになる。
この様に、転送に失敗すると、ＳＩＰメッセージ送受信部２１が故障サーバ情報抽出部２５に転送タイムアウト情報を通知し、故障サーバ情報抽出部２５が故障した呼制御サーバのＩＰアドレスを含む故障サーバ情報を作成する。この動作が追加となっている点が、図１１に示した故障サーバＳＩＰメッセージ送受信部２１との違いであり、その他は同様である。

故障サーバ情報抽出部２５は、呼制御サーバ２ｂから呼制御サーバ２ａへのＲＥＧＩＳＴＥＲリクエストの転送に対して、呼制御サーバ２ａから応答のない状態でタイムアウトとなった時、ＳＩＰメッセージ送受信部２１から転送タイムアウト情報が入力されて、転送先の呼制御サーバ２ｂが故障したものと判定する。
そして、図１０及び図１２のＯｒｇｎｉｚａｔｉｏｎヘッダと同様な故障サーバ情報「ｓｅｒｖｅｒ ｆａｕｌｔ １９２．１６８．０．１」を生成する。１９２．１６８．０．１が故障した呼制御サーバ２ａのＩＰアドレスである。

更に、端末情報保存部２２に保存されている全てのアドレス情報を送信先のアドレス情報とし、これらの故障サーバ情報と送信先のアドレス情報をＳＩＰメッセージ送受信部２１に出力する。

図１５は、呼制御サーバ２ｂが呼制御サーバ２ａの故障を検出して、ＳＩＰ端末４ａとＳＩＰ端末４ｂに通知する場合のＳＩＰメッセージシーケンスである。
ここでは、呼制御サーバ２ｂは、ＳＩＰ端末４ｂからＲＧＩＳＴＥＲリクエストの再送信が行われる。

そして、呼制御サーバ２ｂが、ＳＩＰ端末４ｂからのＲＥＧＩＳＴＥＲリクエストを呼制御サーバ２ａに転送する。この時、呼制御サーバ２ａから、ＲＥＧＩＳＴＥＲリクエストの転送に対する呼制御サーバ２ｂへの応答がなくタイムアウトになると、呼制御サーバ２ｂは、呼制御サーバ２ａが故障したものと判定する。

すると、呼制御サーバ２ｂは、故障サーバ情報を含めたＩＮＦＯリクエストをＳＩＰ端末４ｂに送信する。
この時のＩＮＦＯリクエストの内容は、図１２と同様である。ＩＮＦＯリクエストのＯｒｇａｎｉｚａｔｉｏｎヘッダによって呼制御サーバ２ａが故障であるという故障サーバ情報を通知する。
呼制御サーバ２ｂからのＩＮＦＯリクエストをＳＩＰ端末４ｂが受信することにより、ＳＩＰ端末４ｂは呼制御サーバ４ａの故障を認識することができる。

同様に、呼制御サーバ２ｂは、ＳＩＰ端末４ａにもＩＮＦＯリクエストを送信し、呼制御サーバ２ａが故障であるという故障サーバ情報を通知する。
以降、ＳＩＰ端末４ａおよびＳＩＰ端末４ｂは、呼制御サーバ２ａが故障であると認識しているため、ＩＮＶＩＴＥリクエストを呼制御サーバ２ａに送信せず呼制御サーバ２ｂに送信するため、呼接続時間が長くなることがなくなる。

以上のように、本実施の形態によれば、呼制御サーバ２ｂがＲＥＧＩＳＴＥＲリクエストを転送する際に、転送に対する応答のない状態でタイムアウトとなり、転送先の呼制御サーバ２ａを故障と判定する。そして、その故障と判定した呼制御サーバ２ａの故障サーバ情報を、端末情報保存部２２に保存しているＩＰアドレスの全てのＳＩＰ端末４に通知する。そのため、ＳＩＰ端末４は、以降、故障した呼制御サーバ２ａにＩＮＶＩＴＥリクエストを送信しないため、故障した呼制御サーバ２ａに対しての呼接続時間が長くなることを防止することが出来る。

実施の形態５．
上記実施の形態３においては、呼制御サーバ２ｂがＳＩＰ端末４ａから呼制御サーバ２ａが故障であるという故障サーバ情報を受け、故障サーバを検出したＳＩＰ端末４ａを除く全てのＳＩＰ端末４ｂ〜４ｎに対して、呼制御サーバ２ｂから故障と判定した呼制御サーバ２の故障サーバ情報を送信すると説明した。
また、上記実施の形態４においては、故障サーバを検出した呼制御サーバ２が、全てのＳＩＰ端末４に対して故障サーバ情報を送信するとして説明した。が、本実施の形態においては、各ＳＩＰ端末がＩＮＶＩＴＥリクエストを優先して送信する優先呼制御サーバ２ｐを設定しておき、故障サーバ情報を一部のＳＩＰ端末に送信する場合について説明する。

ここで、優先呼制御サーバ２ｐとは、各ＳＩＰ端末がＩＮＶＩＴＥリクエストを優先して送信する呼制御サーバ２をいう。
即ち、故障した呼制御サーバ２ａを優先呼制御サーバ２ｐとしているＳＩＰ端末４に対してのみ、呼制御サーバ２ｂが、ＩＮＦＯリクエストによって故障サーバ情報を送信する場合について説明する。

故障した呼制御サーバ２ａを優先呼制御サーバ２ｐとしていないその他のＳＩＰ端末４（例えば、呼制御サーバ２ｂに制御されるＳＩＰ端末４ｂ）については、ＳＩＰ端末４ｂが呼制御サーバ２ｂにＲＥＧＩＳＴＥＲリクエストを受信したときにだけ、その応答にＯｒｇａｎｉｚａｔｉｏｎヘッダを付けて故障サーバ情報を通知する。

これにより、呼制御サーバ２が同時にＳＩＰ端末４に送信するＩＮＦＯリクエストの個数を減らすことができ、ネットワークの負荷を軽減することができる。
本実施の形態における呼制御サーバ２の内部構成図は、実施の形態１の図１または実施の形態３の図１１と同様である。

本実施の形態の動作についても、実施の形態１の通信システム１のＳＩＰメッセージシーケンサ、または実施の形態３の通信システム１のＳＩＰメッセージシーケンサと同様であるが、図１６に示す様に、ＳＩＰ端末４ａが呼制御サーバ２ａに対して送信するＲＥＧＩＳＴＥＲリクエストの内容が異なる。

図１６は、本実施の形態において、ＳＩＰ端末４ａが呼制御サーバ２ａに対して優先呼制御サーバ２ｐであることを通知するＲＥＧＩＳＴＥＲリクエストの内容を示している。
図１６のＲＥＧＩＳＴＥＲリクエストに示す通り、Ｏｒｇａｎｉｚａｔｉｏｎヘッダの記述「Ｏｒｇａｎｉｚａｔｉｏｎ：Ｐｒｉｏｒｉｔｙ ｓｅｒｖｅｒ １９２．１６８．０．１」により呼制御サーバ２ａ（ＩＰアドレス：１９２．１６８．０．１）が優先呼制御サーバ２ｐであることを通知する。

ＳＩＰ端末４ａ１〜ＳＩＰ端末４ａｎが優先呼制御サーバ２ｐである呼制御サーバ２ａにＲＥＧＩＳＴＥＲリクエストを送信し、呼制御サーバ２ａがＳＩＰ端末４ａ１〜ＳＩＰ端末４ａｎを制御するとする。
この時、ＳＩＰ端末４ａ１が呼制御サーバ２ａの故障を検出、または、呼制御サーバ２ｂが呼制御サーバ２ａの故障を検出したとする。すると、呼制御サーバ２ａを優先呼制御サーバ２ｐとするＳＩＰ端末４ａ１以外のＳＩＰ端末４ａ２〜ＳＩＰ端末４ａｎに、呼制御サーバ２ｂが故障サーバ情報を含めたＩＮＦＯリクエスト送信し、呼制御サーバ２ａの故障を通知する。

以上のように、本実施の形態によれば、各ＳＩＰ端末４ａ１〜４ａｎに優先呼制御サーバ２ｐを設定すると共にその優先呼制御サーバ２ｐに優先呼制御サーバであることを通知する。
そして、ＳＩＰ端末４ａ１が優先呼制御サーバ２ｐとして設定している呼制御サーバ２ａの故障を検出すると、その故障した呼制御サーバ２ａを優先呼制御サーバ２ｐとしているＳＩＰ端末４ａ２〜４ａｎにのみＩＮＦＯリクエストを用いてその故障を通知する。
または呼制御サーバ２ｂが、呼制御サーバ２ａの故障を検出すると、その故障した呼制御サーバ２ａを優先呼制御サーバ２ｐとしているＳＩＰ端末４ａ１〜４ａｎにのみＩＮＦＯリクエストを用いてその故障を通知する。
そのため、ＩＮＦＯリクエストの一斉送信によるネットワーク負荷を軽減することが出来る。

実施の形態６．
上記実施の形態１〜５においては、呼制御サーバ２を２個備えるシステム構成について説明したが、呼制御サーバ２は３個以上あってもよい。
本実施の形態においては、呼制御サーバ２が３個以上ある場合のシステム構成について説明する。
呼制御サーバ２が３個以上であっても、ＳＩＰ端末４が呼制御サーバ２の故障を検出し、故障していない他の呼制御サーバ２に通知する、または故障していない他の呼制御サーバ２が呼制御サーバ２の故障を検出して、故障していない他の呼制御サーバ２に故障サーバ情報を含めたＩＮＦＯリクエストを用いて故障サーバ情報を通知する。
この様に、故障していない他の呼制御サーバ２の制御によってＳＩＰ端末４が発信先のＳＩＰ端末４との通信が可能となり、システム停止となる可能性が低く、信頼性の高い通信システムを得ることが出来る。

また、故障していない他の呼制御サーバ２にＩＮＦＯリクエストを用いて故障サーバ情報を通知する場合、呼制御サーバ２が故障していない他の呼制御サーバ２に対してＳＩＰ端末４からのＩＮＶＩＴＥリクエストを転送するので、故障した呼制御サーバ２へのＩＮＶＩＴＥリクエストの転送を回避することが可能となる。そのため、呼接続時間が長くなることを防止することができる。
このようにＳＩＰ端末４からの接続要求（ＩＮＶＩＴＥリクエスト）を他のＳＩＰ端末または他の呼制御サーバ２に転送することができるのは、呼制御サーバ２が、ＳＩＰプロキシ機能を持つ場合である。

更に、呼制御サーバ２がＳＩＰプロキシ機能を持つ場合には、各呼制御サーバ２に対してＩＮＶＩＴＥリクエストを優先的に転送する優先呼制御サーバ２ｐを設定しておき、故障した呼制御サーバ２を優先呼制御サーバ２ｐとしているＳＩＰ端末４に対してのみ、故障サーバ情報をＩＮＦＯリクエストによって送信するようにしても良い。
そして、その他の呼制御サーバ２については、ＲＥＧＩＳＴＥＲリクエストを転送するとき、そのＲＥＧＩＳＴＥＲリクエスト内にＯｒｇａｎｉｚａｔｉｏｎヘッダを付けて故障サーバ情報を通知する。これにより、呼制御サーバ２が同時に送信するＩＮＦＯリクエストの個数を減らすことができ、ネットワークの負荷を軽減することが出来る。

１ 通信システム、２ 呼制御サーバ、３ ＩＰ網、４ ＳＩＰ端末、２１ ＳＩＰメッセージ送受信部、２２ 端末情報保存部、２３ 転送判定部、２４ アドレス検索部、２５ 故障サーバ情報抽出部。

Claims (10)

1. 複数のＩＰ端末を制御する呼制御サーバにおいて、
   第１の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第１の端末情報を前記第１のＩＰ端末から受信すると共に、他の呼制御サーバが制御する第２の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第２の端末情報を前記他の呼制御サーバから転送されて受信する受信部、
   該受信部で受信した前記第１の端末情報と前記第２の端末情報を記憶する記憶部、
   前記第２のＩＰ端末から前記第１のＩＰ端末の電話番号を前記受信部で受信すると、前記第１のＩＰ端末の電話番号に対応したアドレス情報を前記記憶部から検索し、前記第１のＩＰ端末から前記第２のＩＰ端末の電話番号を前記受信部で受信すると、前記第２のＩＰ端末の電話番号に対応したアドレス情報を前記記憶部から検索する検索部、
   該検索部で検索した前記第１のＩＰ端末のアドレス情報を前記第２のＩＰ端末に送信し、前記検索部で検索した前記第２のＩＰ端末のアドレス情報を前記第１のＩＰ端末に送信する送信部、
   を備えたことを特徴とする呼制御サーバ。
2. 前記受信部で受信した端末情報を前記他の呼制御サーバに転送するか否かを判定する転送判定部を更に備え、
   該転送判定部は、前記第１のＩＰ端末から受信した前記端末情報の登録先が自己であれば、前記第１のＩＰ端末から受信した端末情報を前記他の呼制御サーバに転送する転送指示を前記送信部に出力し、
   該送信部は、前記転送判定部から転送指示が入力されると前記他の呼制御サーバに前記端末情報を転送することを特徴とする請求項１に記載の呼制御サーバ。
3. 前記受信部で前記第２のＩＰ端末から前記第１のＩＰ端末の電話番号を受信するのは、前記第２のＩＰ端末が前記他の呼制御サーバに前記第１のＩＰ端末との通信を要求する通信要求を送信して前記他の呼制御サーバから所定の時間応答がない場合であることを特徴とする請求項１または請求項２に記載の呼制御サーバ。
4. 前記受信部で前記第２のＩＰ端末から自端末の端末情報の登録を要求する登録要求、または前記第２のＩＰ端末から前記第１の端末との通信を要求する通信要求を受信すると、前記登録要求または前記通信要求から前記第２のＩＰ端末によって生成された前記他の呼制御サーバの故障情報である故障サーバ情報を抽出し、前記送信部に出力する故障サーバ情報抽出部を更に備え、
   前記送信部は、前記故障サーバ情報抽出部から入力された前記故障サーバ情報を前記記憶部に記憶されている端末情報のＩＰ端末に送信することを特徴とする請求項３記載に記載の呼制御サーバ。
5. 前記送信部は、前記故障サーバ情報抽出部から入力された前記故障サーバ情報を前記他の制御サーバが制御するＩＰ端末に送信することを特徴とする請求項４記載に記載の呼制御サーバ。
6. 前記転送判定部から入力された転送指示に従い前記送信部が前記他の呼制御サーバへ前記第１のＩＰ端末の端末情報を転送して、前記他の呼制御サーバから所定の時間応答がない場合に、前記他の呼制御サーバの故障情報である故障サーバ情報を生成し、この生成した故障サーバ情報を前記送信部に出力する故障サーバ情報生成部を更に備え、
   前記送信部は、前記故障サーバ情報生成部から入力された前記故障サーバ情報を前記記憶部に記憶されている端末情報のＩＰ端末に送信することを特徴とする請求項２に記載の呼制御サーバ。
7. 前記送信部は、前記故障サーバ情報生成部から入力された前記故障サーバ情報を前記他の制御サーバが制御するＩＰ端末に送信することを特徴とする請求項６に記載の呼制御サーバ。
8. 前記送信部は、故障していない他の呼制御サーバに前記故障サーバ情報を送信することを特徴とする請求項４〜７のいずれかに記載の呼制御サーバ。
9. 複数のＩＰ端末とそれを制御する複数の呼制御サーバから構成される通信システムであって、
   前記呼制御サーバは、
   第１の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第１の端末情報を前記第１のＩＰ端末から受信すると共に、他の呼制御サーバが制御する第２の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第２の端末情報を前記他の呼制御サーバから転送されて受信する受信部、
   該受信部で受信した前記第１の端末情報と前記第２の端末情報を記憶する記憶部、
   前記第２のＩＰ端末から前記第１のＩＰ端末の電話番号を前記受信部で受信すると、前記第１のＩＰ端末の電話番号に対応したアドレス情報を前記記憶部から検索し、前記第１のＩＰ端末から前記第２のＩＰ端末の電話番号を前記受信部で受信すると、前記第２のＩＰ端末の電話番号に対応したアドレス情報を前記記憶部から検索する検索部、
   該検索部で検索した前記第１のＩＰ端末のアドレス情報を前記第２のＩＰ端末に送信し、前記検索部で検索した前記第２のＩＰ端末のアドレス情報を前記第１のＩＰ端末に送信する送信部を備え、
   前記第２のＩＰ端末は、
   前記第１のＩＰ端末との通信を要求する通信要求を前記他の呼制御サーバに送信して、前記他の呼制御サーバから所定の時間応答がない場合、前記呼制御サーバに前記第１のＩＰ端末の電話番号を送信することを特徴とする通信システム。
10. 複数のＩＰ端末を制御する呼制御サーバの呼制御方法において、
    第１の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第１の端末情報を前記第１のＩＰ端末から受信すると共に、他の呼制御サーバが制御する第２の前記ＩＰ端末の電話番号と電話番号に対応したアドレス情報を含む第２の端末情報を前記他の呼制御サーバから転送されて受信する第１の受信ステップ、
    該第１の受信ステップで受信した前記第１の端末情報と前記第２の端末情報を前記呼制御サーバの記憶部で記憶する記憶ステップ、
    前記第２のＩＰ端末から前記第１のＩＰ端末の電話番号を受信する、または前記第１のＩＰ端末から前記第２のＩＰ端末の電話番号を受信する第２の受信ステップ、
    該第２の受信ステップで前記第２のＩＰ端末から前記第１のＩＰ端末の電話番号を受信すると、前記記憶ステップで記憶した記憶部から前記第１のＩＰ端末の電話番号に対応したアドレス情報を検索し、前記第１のＩＰ端末から前記第２のＩＰ端末の電話番号を受信すると、前記記憶ステップで記憶した記憶部から前記第２のＩＰ端末の電話番号に対応したアドレス情報を検索する検索ステップ、
    該検索ステップで前記第１のＩＰ端末のアドレス情報を検索すると前記第２のＩＰ端末に前記第１のＩＰ端末のアドレス情報を送信し、前記第２のＩＰ端末のアドレス情報を検索すると前記第１のＩＰ端末に前記第２のＩＰ端末のアドレス情報を送信する送信ステップ、
    を備えたことを特徴とする呼制御サーバの呼制御方法。

Images