JP2006165879A - 呼制御システム、呼制御方法および呼制御プログラム - Google Patents

Abstract

【課題】 利便性および可用性を高め、資源の実質的な利用効率を高める。
【解決手段】 複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御システムにおいて、前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、副呼制御サーバは、応答要求部と、応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定するサーバ側正常性判定部と、受付制御部とを備え、前記通信端末は、端末側正常性判定部と、依頼先決定部とを備える。
【選択図】 図１

Description

本発明は呼制御システム、呼制御方法および呼制御プログラムに関し、例えば、ＩＰ−ＰＢＸの機能をＩＰ網経由で提供するＩＰセントレックスなどに適用して好適なものである。

ＩＰセントレックス方式では、センタ拠点にＩＰ−ＰＢＸ（メインサーバ）を設置しておき、センタ拠点以外の拠点に設置されたＩＰ電話端末が、ＩＰ網経由で当該メインサーバを利用して、他のＩＰ電話端末への発呼などを行う。

ただしこの構成を取る場合、センタ拠点に設置されたメインサーバに障害が発生したり、ＩＰ網の障害でセンタ拠点との通信が行えなくなった場合などには、各拠点内のＩＰ電話端末すべてを利用することができなくなってしまうため、各拠点に前記メインサーバの代替手段となるサーバ（サバイバルサーバ）を設置し、メインサーバに障害が発生したりＩＰ網の障害でセンタ拠点との通信が行えなくなった場合でも、自拠点内のＩＰ電話端末相互間では、自拠点内のサバイバルサーバを利用して通信を行うことが可能となる。

この場合、ＩＰ電話端末は、メインサーバの障害を検出すると、アクセスするサーバをメインサーバからサバイバルサーバに切り替える。

ＩＰ−ＰＢＸに関連する技術として、下記の特許文献１に記載されたものがある。
特開２００１−８６１６６号公報

しかしながら上述した構成の場合、極めて短時間で復旧する一時的な障害や、ＩＰ網上で一時的な輻輳が発生したケースなどでも、ＩＰ電話端末がアクセスするサーバを切り替えてしまうが、このような障害や輻輳は極めて短時間で復旧するため、アクセスするサーバの切り替えは不要なものである可能性が高い。

例えば、ＩＰ電話端末のアクセス先のサーバ（メインサーバ、サバイバルサーバ）に関して不要な切り替えが発生すると、ＩＰ電話端末のユーザにとっては発呼できるＩＰ電話端末が制限される点で利便性が低下する。発呼できるＩＰ電話端末が制限される理由は、サバイバルサーバの管理範囲がその拠点内に限られているからである。

また、具体的なシステムの仕様にも依存するが、例えば、アクセスするサーバを切り替える際、メインサーバが自身の再起動を実行し、再起動後にも正常な処理を行えないか否かを確認する手順なども含まれる場合には、長時間（例えば、５分程度）、ＩＰ電話端末はいずれのサーバも利用することができない状態となるため、可用性が低下し、資源の実質的な利用効率が低下する。さらに、例えば、サバイバルサーバを利用中、サバイバルサーバに蓄積された様々な管理情報（例えば、各ＩＰ電話端末に割り当てるＩＰアドレスと電話番号の対応関係など）の変更を認める場合には、ＩＰ電話端末のアクセス先のサーバに関して不要な切り替えが発生すると、サバイバルサーバが蓄積する管理情報とメインサーバが蓄積する管理情報の内容を整合させる処理（同期処理）の頻度が高くなって、サバイバルサーバやメインサーバの処理能力およびネットワークの伝送帯域が消費され、その他の処理や伝送を困難にする可能性が高まるため、資源の実質的な利用効率が低下する。

上述した特許文献１の技術も、このような問題を解決できるものではない。

かかる課題を解決するために、第１の本発明では、複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、前記通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御システムにおいて、前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、（１）当該副呼制御サーバは、前記主呼制御サーバに宛てて、正常性確認のための応答を要求する応答要求信号を所定時間ごとに所定数以上、送信する応答要求部と、（２）当該応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定するサーバ側正常性判定部と、（３）当該サーバ側正常性判定部が、正常であるとの判定結果を出した場合、当該副呼制御サーバの管理範囲内の通信端末から到来した呼制御メッセージの受け付けを拒否する受付制御部とを備え、（４）前記通信端末は、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定する端末側正常性判定部と、（５）当該端末側正常性判定部が、正常でないとの判定結果を出した場合、呼制御メッセージの中継処理依頼先を前記主呼制御サーバから副呼制御サーバに切り替えるものの、当該呼制御メッセージの受け付けが前記受付制御部によって拒否されると、前記中継処理依頼先を主呼制御サーバに戻す依頼先決定部とを備えたことを特徴とする。

また、第２の本発明では、複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、前記通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御方法において、前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、（１）当該副呼制御サーバでは、応答要求部が、前記主呼制御サーバに宛てて、正常性確認のための応答を要求する応答要求信号を所定時間ごとに所定数以上、送信し、（２）サーバ側正常性判定部が、当該応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定し、（３）当該サーバ側正常性判定部が、正常であるとの判定結果を出した場合、受付制御部が、当該副呼制御サーバの管理範囲内の通信端末から到来した呼制御メッセージの受け付けを拒否し、（４）前記通信端末では、端末側正常性判定部が、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定し、（５）当該端末側正常性判定部が、正常でないとの判定結果を出した場合、依頼先決定部が、呼制御メッセージの中継処理依頼先を前記主呼制御サーバから副呼制御サーバに切り替えるものの、当該呼制御メッセージの受け付けが前記受付制御部によって拒否されると、前記中継処理依頼先を主呼制御サーバに戻すことを特徴とする。

さらに、第３の本発明では、複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、前記通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御プログラムにおいて、前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、（１）当該副呼制御サーバでは、コンピュータに、前記主呼制御サーバに宛てて、正常性確認のための応答を要求する応答要求信号を所定時間ごとに所定数以上、送信する応答要求機能と、（２）当該応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定するサーバ側正常性判定機能と、（３）当該サーバ側正常性判定機能が、正常であるとの判定結果を出した場合、当該副呼制御サーバの管理範囲内の通信端末から到来した呼制御メッセージの受け付けを拒否する受付制御機能とを実現させ、（４）前記通信端末では、コンピュータに、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定する端末側正常性判定機能と、（５）当該端末側正常性判定機能が、正常でないとの判定結果を出した場合、呼制御メッセージの中継処理依頼先を前記主呼制御サーバから副呼制御サーバに切り替えるものの、当該呼制御メッセージの受け付けが前記受付制御機能によって拒否されると、前記中継処理依頼先を主呼制御サーバに戻す依頼先決定機能とを実現させたことを特徴とする。

本発明によれば、利便性および可用性を高め、資源の実質的な利用効率を高めることができる。

（Ａ）実施形態
以下、本発明にかかる呼制御システム、呼制御方法および呼制御プログラムをＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。

（Ａ−１）実施形態の構成
本実施形態にかかるＶｏＩＰ通信システム１０の全体構成例を図１に示す。

図１において、当該ＶｏＩＰ通信システム１０は、ＷＡＮ（ワイド・エリア・ネットワーク）を構成するＩＰ網１１と、当該ＩＰ網１１によって相互に接続された拠点ＳＴ１〜ＳＴ４とを備えている。

このうちＩＰ網１１はインターネットなどにも置換可能であるが、ここでは、特定の通信事業者が運営するＩＰ網を想定する。ＩＰ網１１上では、ＯＳＩ参照モデルのネットワーク層の通信プロトコルとしてＩＰプロトコルが用いられる。

個々の拠点ＳＴ１〜ＳＴ４はそれぞれＬＡＮ（ローカル・エリア・ネットワーク）を構成しているが、拠点ＳＴ１はある企業の本社に構成されたＬＡＮに対応し、拠点ＳＴ２〜ＳＴ４はその企業の各支社に構成されたＬＡＮに対応するものであってよい。各拠点ＳＴ１〜ＳＴ４内には図示しないルータやスイッチなどが設置されていてもよいことは当然である。

拠点ＳＴ１内には、図１に示すように、メインサーバ１２が設置されており、拠点ＳＴ２内には、サバイバルサーバ１３と、ＩＰ電話端末１４〜１６が設置されている。

図１では、拠点ＳＴ１内にはメインサーバ１２のみが設置されているが、拠点ＳＴ１内にも、ＩＰ電話端末１４〜１６などと同様なＩＰ電話端末が設置されていてもよいことは当然である。また、他の拠点ＳＴ３，ＳＴ４内の構成も、拠点ＳＴ２と同じであるものとする。ＶｏＩＰ通信システム１０全体（すなわち、メインサーバ１２の管理範囲内）に含まれるＩＰ電話端末の数には様々なものがあり得るが、例えば、５０００台程度におよぶ大規模なシステムであってもよい。

メインサーバ１２は、ＩＰ−ＰＢＸ（あるいは、コールエージェント）で、呼制御や端末制御の機能を備えている。ＶｏＩＰ通信システム１０内で用いられる呼制御プロトコルには様々なものがあり得るが、例えば、ＩＴＵ−Ｔ勧告Ｈ．３２３やＳＩＰ（セッション・イニシエーション・プロトコル）などを用いることも可能である。

例えば、ＩＴＵ−Ｔ勧告Ｈ．３２３を用いた場合、当該ＩＰ−ＰＢＸにはゲートキーパの機能が搭載されることになるし、ＳＩＰを用いた場合には、ロケーションサーバなども含むＳＩＰサーバの機能が搭載されることになる。ＩＰ−ＰＢＸとしての当該メインサーバ１２の管理範囲はＶｏＩＰ通信システム１０全体である。したがって、拠点ＳＴ２〜ＳＴ４内の任意のＩＰ電話端末（例えば、１４）が他のＩＰ電話端末に対して発呼しようとする場合、アドレス解決（電話番号に対応するＩＰアドレスの取得）などのためにＩＰ−ＰＢＸの機能を用いることが必要である。また、具体的な呼制御の手順にも依存するが、通常、ＩＰ電話端末が送信する呼制御メッセージの多くは、ＩＰ−ＰＢＸを経由して着信先のＩＰ電話端末に届けられることになる。これにより、ＩＰ−ＰＢＸであるメインサーバ１２は、ＶｏＩＰ通信システム１０内の各ＩＰ電話端末の状態（例えば、通話中か否かなど）も管理することができる。

なお、端末制御では、ＩＰ電話端末における、転送、ボタンの割り付け、ＶＬＡＮ、優先制御などに関連する動作を制御する。例えば、前記ＩＰ電話端末１４が多機能電話機に相当するものである場合、着信転送など転送の際に必要な情報、ボタンの割付けに関する情報、ＶＬＡＮ、ＴｏＳ（タイプ・オブ・サービス）などに関する情報を、ＩＰ電話端末１４に送信して記憶させる。ここで、ＶＬＡＮに関する情報はＶｏＩＰ通信システム１０内でＶＬＡＮを用いる場合に必要であり、ＴｏＳに関する情報は、ＶｏＩＰ通信システム１０内の図示しない中継装置（例えば、ルータ）で優先制御を行う場合、当該優先制御のために、ＩＰ電話端末が送信するＩＰパケットについて、そのヘッダのＴｏＳフィールドに記述させる情報である。

拠点ＳＴ２内に設置されているサバイバルサーバ１３は、基本的に前記メインサーバ１２と同じ機能を持つＩＰ−ＰＢＸであるが、管理範囲が拠点ＳＴ２の内部に限られている点が異なる。例えば、ＩＰ網１１上の障害発生などに応じてメインサーバ１２の機能が利用できなくなった場合でも、拠点ＳＴ２内における任意のＩＰ電話端末間の通話は行えるようにするために当該サバイバルサーバ１３が用意されている。

ＩＰ電話端末１４〜１６はＶｏＩＰ対応機能を有する電話端末である。ＶｏＩＰ対応機能を持たない一般電話機をＶｏＩＰゲートウエイ経由で拠点ＳＴ２のネットワークに接続したものを、ＩＰ電話端末の代わりに用いてもよいことは当然である。ＩＰ電話端末１４はユーザＵ１によって利用され、…、ＩＰ電話端末１５はユーザＵ２によって利用され、ＩＰ電話端末１６はユーザＵ３によって利用される。

ＩＰ電話端末（例えば、１４）は自身でメインサーバ１２およびＩＰ電話端末１４からメインサーバ１２にいたる伝送経路が正常であると判定する機能を備えている。ＩＰ電話端末１４の内部構成は例えば図５に示す通りであってよい。他のＩＰ電話端末１５，１６などの内部構成もこれと同じである。

（Ａ−１−１）ＩＰ電話端末の内部構成例
図５において、当該ＩＰ電話端末１４は、通信部３０と、制御部３１と、操作部３２と、記憶部３３と、ヘルスチェック部３４と、接続サーバ切替部３５と、呼制御部３６と、表示部３７とを備えている。

このうち通信部３０は、ＩＰ電話端末１４が拠点ＳＴ２内のネットワークや前記ＩＰ網１１を経由して通信を行うために機能する部分である。この通信には、制御や管理のために行われるメインサーバ１２またはサバイバルサーバ１３との通信と、通話相手のＩＰ電話端末とのあいだで行われるリアルタイムな音声通信が含まれる。

制御部３１はハードウエア的には当該ＩＰ電話端末１４のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）などの制御プログラムに相当し得る部分である。

操作部３２は、当該ＩＰ電話端末１４のユーザＵ１が制御部３１に指示を伝えるためのユーザインタフェースである。電話端末である以上、当該操作部３２には少なくとも通話相手の電話番号などを指定するためのボタンなどが含まれるが、多機能電話に相当する多種多様な機能を持つＩＰ電話端末の場合には、そのほかに、様々な機能に対応する多くのボタンが含まれる。

記憶部３３は、揮発性または不揮発性の記憶資源である。

表示部３７は、制御部３１からユーザＵ１に情報を伝えるための部分である。具体的には、例えば、液晶表示装置や、ランプなどによって当該表示部３７を構成することができる。

ヘルスチェック部３４は、アクセスするサーバ（例えば、メインサーバ１２，サバイバルサーバ１３）および当該サーバまでの伝送経路の正常性を検査する部分である。例えば、常時、メインサーバ１２とのあいだでＩＰ電話端末１４がＴＣＰコネクションを確立しておく仕様のシステムの場合、ＴＣＰコネクションが切断されたことを検知することによって、メインサーバ１２またはメインサーバ１２までの伝送経路が正常でないと判定することができる。

また、メインサーバ１２側から定期的に（例えば、４０秒間隔）ヘルスチェック要求信号をＩＰ電話端末（例えば、１４）に送信し、それに応えてＩＰ電話端末１４がメインサーバ１２へヘルスチェック応答信号を返送する仕様のシステムの場合には、ヘルスチェック要求信号が所定時間（例えば、２分４０秒（＝４０秒×４回））以上連続して届かなければ、正常でないと判定することができる。

これは、メインサーバ１２が、ＩＰ電話端末１４から返送されてくるはずのヘルスチェック応答信号が所定時間以内に返送されてこなければ、４０秒後に再度、ヘルスチェック要求信号を送信する操作を最大で４回まで繰り返し、４回目に送信したヘルスチェック要求信号に対してもヘルスチェック応答信号が返送されてこないときに、そのＩＰ電話端末１４に障害が発生していると判定することに対応したものである。

別な方法として、ＩＰ電話端末１４が例えば呼制御メッセージの中継を依頼する際などにメインサーバ１２にアクセスしたとき、正常な応答がなければ、正常でないと判定するようにしてもよい。

ヘルスチェック要求信号ＲＱ１やヘルスチェック応答信号ＲＳ１の送受に際し、ＯＳＩ参照モデルのトランスポート層では、ＴＣＰ等のコネクション型の通信プロトコルを用いてもよいが、ここでは、ＵＤＰ等のコネクションレス型の通信プロトコルを用いるものとする。

呼制御部３６は、呼制御メッセージの生成や送受などを実行する部分である。

接続サーバ切替部３５は、当該ＩＰ電話端末１４が呼制御やアドレス解決のために呼制御部３６がアクセスするサーバ（１２または１３）の切り替えを制御する部分である。当該接続サーバ切替部３５は、通常、呼制御部３６にはメインサーバ１２にアクセスさせるが、前記ヘルスチェック部３４が、メインサーバ１２またはメインサーバ１２にいたる伝送経路が正常でないと判定した場合には、アクセスするサーバをメインサーバ１２からサバイバルサーバ１３に切り替えさせ、サバイバルサーバ１３に正常なアクセスが行えない場合には、再度、アクセスするサーバをメインサーバ１３に戻す。

サバイバルサーバ１３に対して正常なアクセスが行えるか否かは、上述したメインサーバ１２のヘルスチェックと同様な方法で判定することもできるが、例えば、呼制御メッセージの送信のためにサバイバルサーバ１３とＩＰ電話端末１４のあいだにＴＣＰコネクションを確立することが必要な場合には、ＴＣＰコネクションを確立できないときに正常でないと判定するようにしてもよい。

サバイバルサーバ１３に対してＩＰ電話端末１４から正常なアクセスが行えない現象は、ほとんどの場合、サバイバルサーバ１３がそのアクセスを受け付けるためのポートを、後述するように閉塞しているときに起きる。

前記サバイバルサーバ１３の内部構成は例えば図２に示す通りであってよい。前記メインサーバ１２の内部構成も基本的にこれと同じである。ただしサバイバルサーバ１３は、後述するヘルスチェック要求信号ＲＱ１をメインサーバ１２に送信する機能などを備え、メインサーバ１２はこのヘルスチェック要求信号ＲＱ１に応えてヘルスチェック応答信号ＲＳ１を返送する機能などを備える点が相違する。

（Ａ−１−２）サバイバルサーバの内部構成例
図２において、当該サバイバルサーバ１３は、端末収容部２０と、装置管理部２１と、呼処理部２２と、データベース部２３とを備えている。

このうち装置管理部２１は対象となる装置を管理する部分である。ただし、図２にメインサーバ１２を示したものとみる場合、管理の対象となる装置は、前記ＩＰ電話端末（例えば、１４）であり、サバイバルサーバ１３を示したものとみる場合には、メインサーバ１２である。すなわち、サバイバルサーバ１３の装置管理部２１は、メインサーバ１２の正常性を確認するためのヘルスチェック要求信号ＲＱ１を周期的にメインサーバ１２に送信し、メインサーバ１２は、当該ヘルスチェック要求信号ＲＱ１を受信するたび、自身の正常性を示すヘルスチェック応答信号ＲＳ１を返送する。

メインサーバ１２の一部に障害が発生していることを検出する機能（自己管理機能）をメインサーバ１２が備え、当該自己管理機能がメインサーバ１２の障害発生を検出している場合には、ヘルスチェック応答信号ＲＳ１にその旨を記述するようにしてもよいが、メインサーバ１２の装置管理部２１がそのような自己管理機能を持つことは必ずしも必須ではない。サバイバルサーバ１３側からすると、送信したヘルスチェック要求信号ＲＱ１に応えて、ヘルスチェック応答信号ＲＳ１が返送されてくる限り、メインサーバ１２および、サバイバルサーバ１３からメインサーバ１２にいたる伝送経路が正常であると判定することができるからである。

上述したように、メインサーバ１２の管理範囲内に５０００台ものＩＰ電話端末が存在する場合、ＩＰ網１２などの通信帯域やメインサーバ１２自身の処理能力などを節約する観点から、それほど高い時間頻度でヘルスチェック要求信号を送信することは難しく、例えば、 秒程度の時間間隔で送信することになる。

サバイバルサーバ１３がメインサーバ１２に送信するヘルスチェック要求信号ＲＱ１とそれに応えてメインサーバ１２から返送されるヘルスチェック応答信号ＲＳ１に関してはこのようなことはないが、実際には、負荷が集中しやすいメインサーバ１２の処理能力にかかる負荷を軽減するため、それほど短い時間間隔でヘルスチェック要求信号ＲＱ１を送信することは難しい。このため、例えば、３０秒程度の時間間隔でヘルスチェック要求信号ＲＱ１を送信する操作を繰り返す。これらのヘルスチェック要求信号ＲＱ１を受信するメインサーバ１２のほうでは、各ヘルスチェック要求信号ＲＱ１に対して１つずつヘルスチェック応答信号ＲＳ１を返送することになる。したがって、何も問題が無ければ、３０秒程度の時間を置いて、ヘルスチェック応答信号ＲＳ１がサバイバルサーバ１３まで返送されてくることになる。

端末収容部２０は、管理範囲内の任意のＩＰ電話端末から呼制御メッセージの受付けなどを行うためのポートを有する部分である。図２にメインサーバ１２を示したものとみる場合、この端末収容部２０のポートは常時、受付けを許可する状態であってよいが、サバイバルサーバ１３を示したものとみる場合には、受付けを許可するときと拒否するときがある。

受付を許可するのは、前記信号ＲＱ１，ＲＳ１によるヘルスチェックの結果として、前記メインサーバ１２または伝送経路の少なくともいずれかが正常でないと判定した場合であり、拒否するのは、前記メインサーバ１２および伝送経路の双方が正常であると判定した場合である。

拠点ＳＴ２内の任意のＩＰ電話端末（例えば、１４）が呼制御メッセージの送信などのために前記メインサーバ１２にアクセスするときの伝送経路は、拠点ＳＴ２の内部における伝送経路を除けば、サバイバルサーバ１３が前記信号ＲＱ１，ＲＳ１をやり取りするときの伝送経路と同じであるため、両者は、ほぼ同一とみなすことができる。

メインサーバ１２および伝送経路の正常性に関し、サバイバルサーバ１３が出した判定結果の信頼性と、各ＩＰ電話端末（その１つが１４）が出した判定結果の信頼性の高さは同じ程度であってもよく、異なるものであってもよいが、いずれにしても、もしも判定結果が、極めて短時間で復旧する一時的な障害（ＩＰ網１１の一時的な輻輳なども含む）に基づいて正常でないと判定したものであった場合、サバイバルサーバ１３が出した判定結果と各ＩＰ電話端末が出した判定結果が偶然、一致することは確率的に希なものとなる。そしてこの点により、ＩＰ電話端末のアクセス先のサーバ１２，１３に関する不要な切り替えの発生確率を十分に低いものとすることが可能となる。

呼処理部２２は、ＩＰ電話端末間でやり取りされる呼制御メッセージの中継などの際に機能する部分である。呼処理部２２を通じて管理範囲内に存在する各ＩＰ電話端末の呼制御の進行状況などを示す情報を収集することもできるため、当該メインサーバ１２は、例えば、上述した各ＩＰ電話端末の状態などを検出することが可能となる。

データベース部２３には、管理範囲内の各ＩＰ電話端末に関する情報が蓄積されている。例えば、各ＩＰ電話端末に割り当てられているＩＰアドレスと電話番号の対応関係などの情報や、前記ＩＰ電話端末の状態を示す情報なども当該データベース部２３に蓄積される。

図２にメインサーバ１２を示したものとみた場合、メインサーバ１２の管理範囲はＶｏＩＰ通信システム１０全体であるため、メインサーバ１２のデータベース部２３には、拠点ＳＴ２だけでなく、他の拠点ＳＴ１，ＳＴ３，ＳＴ４に設置されているＩＰ電話端末に関するこれらの情報も蓄積されるが、サバイバルサーバ１３の管理範囲は拠点ＳＴ２内に限られるため、サバイバルサー１３のデータベース部２３には、拠点ＳＴ２内に設置されたＩＰ電話端末１４〜１６に関するこれらの情報のみを蓄積することになる。

以下、上記のような構成を有する本実施形態の動作について、図３、図４のフローチャートを参照しながら説明する。

図３は前記サバイバルサーバ１３の動作を示すフローチャートで、Ｓ１０〜Ｓ１８の各ステップを備えている。図４は前記メインサーバ１２の動作を示すフローチャートで、Ｓ２０〜Ｓ２２の各ステップを備えている。

（Ａ−２）実施形態の動作
通常、拠点ＳＴ２内のＩＰ電話端末１４〜１６を含め、各拠点ＳＴ１〜ＳＴ４内の任意のＩＰ電話端末は、他のＩＰ電話端末に発呼しようとする場合、他のＩＰ電話端末が自身と同じ拠点内に設置されているか、他の拠点内に設置されているかにかかわらず、アドレス解決、呼制御メッセージの送信などのためにメインサーバ１２にアクセスする。

そして、これらのアクセスに対してメインサーバ１２から正常な応答が返送されてこない場合や、常時、確立されているはずのＴＣＰコネクションが切断されたことが検知された場合など、上述したヘルスチェック部３４が、メインサーバ１２または伝送経路のいずれかに障害が発生したものと判定した場合、ＩＰ電話端末は、自身と同じ拠点内に設置されたサバイバルサーバにアクセスする。一例として、拠点ＳＴ２内のＩＰ電話端末１４に注目すると、ヘルスチェック部３４が、メインサーバ１２または伝送経路のいずれかに障害が発生したものと判定した場合、当該ＩＰ電話端末１４内の前記接続サーバ切替部３５は、アクセスするサーバをメインサーバ１２から当該ＩＰ電話端末１４と同じ拠点ＳＴ２内に設置されたサバイバルサーバ１３に切り替えさせる。この切り替えにともない、ＩＰ電話端末１４は、サバイバルサーバ１３とのあいだでＴＣＰコネクションを確立しようとする。

一方、サバイバルサーバ１３は図３に示すように、予め定めた周期タイミングがくるたびに、前記ヘルスチェック要求信号ＲＱ１をメインサーバ１２に宛てて送信する（Ｓ１１、Ｓ１２）。ここでは上述したように、サバイバルサーバ１３は、周期タイミングに応じて３０秒程度の時間を置いてヘルスチェック要求信号ＲＱ１を送信する動作を繰り返すものとする。

送信したヘルスチェック要求信号ＲＱ１に対して、ヘルスチェック応答信号ＲＳ１が返送されてくるまでの時間には、所定のＮＧ時間が設定されている。このＮＧ時間には様々な時間を用いることができるが、例えば、１０秒としてもよい。

そして、ヘルスチェックＮＧ（すなわち、ＮＧ時間以内に該当するヘルスチェック応答信号ＲＳ１が返送されてこないこと）が、所定回数（例えば、７回）連続して発生したときタイムアウトと判定する。

ヘルスチェックＮＧを検査するのが、前記ステップＳ１２につづくステップＳ１３である。前記ステップＳ１２で送信されたヘルスチェック要求信号ＲＱ１に対応するヘルスチェック応答信号ＲＳ１が前記ＮＧ時間以内にサバイバルサーバ１３まで返送されてきた場合には、ヘルスチェックＯＫとなってステップＳ１３はＯＫ側に分岐するが、そうでない場合には、ヘルスチェックＮＧとなってＮＧ側に分岐する。

ＮＧ側の分岐につづくステップＳ１４では、タイムアウトになったか否か、すなわち、この例では、７回連続してヘルスチェックＮＧが発生したか否か検査する。タイムアウトになっていなければ、処理は、ステップＳ１１に戻る。したがって、ステップＳ１１〜Ｓ１４によって構成されるループは、最大で、７回連続して繰り返し処理され、７回目には、ステップＳ１４がＹＥＳ側に分岐することになる。ステップＳ１４がＹＥＳ側に分岐することは、メインサーバ１２またはメインサーバ１２までの伝送経路が正常でないと判定することに等しい。

前記ループが最大で７回、連続して繰り返し処理されているあいだに、１個でもヘルスチェック応答信号ＲＳ１が返送されてくれば、ステップＳ１３はＯＫ側に分岐する。何も問題が無ければ、ヘルスチェック応答信号ＲＳ１は７個届くべきところを、１個でも届けばＯＫとすることは、一時的な障害や輻輳に起因してヘルスチェック応答信号ＲＳ１が届かなかったことを無視することになる。このことは、後述するステップＳ１７，Ｓ１８を経て、ＩＰ電話端末１４のアクセス先のサーバ１２，１３に関する不要な切り替えを生じにくくすることに寄与する。

この例では、実際に例えばメインサーバ１２に一時的でない障害が発生した場合、サバイバルサーバ１３がそれを検出するには、約３分半（＝３０秒×７）を要することになる。

ステップＳ１３のＯＫ側の分岐につづくステップＳ１７では、その時点におけるポート状態を確認して、ポートが閉塞されているクローズ状態（ＣＬＯＳＥ状態）であれば現状を維持し、開放されているオープン状態（ＯＰＥＮ状態）であればポートを閉塞する（Ｓ１８）。ここで、ポートの開放は、ポートが任意のＩＰ電話端末（例えば、１４）からのアクセスを受け付け可能な状態にあることを意味し、逆に、ポートの閉塞は、ポートが任意のＩＰ電話端末（例えば、１４）からのアクセスの受け付けを拒否する状態（あるいは、受け付け不能な状態）にあることを意味する。

前記ステップＳ１７，Ｓ１８により、前記ＩＰ電話端末１４が、アドレス解決および呼制御メッセージの送信やＴＣＰコネクションの確立などのためにサバイバルサーバ１３にアクセスしてきても、そのアクセスは拒否されるから、ＩＰ電話端末１４内の前記接続サーバ切替部３５により、ＩＰ電話端末１４のアクセス先は再度、メインサーバ１２側に戻される。

極めて短時間で復旧する一時的な障害（ＩＰ網１１の一時的な輻輳なども含む）に起因してＩＰ電話端末１４がサバイバルサーバ１３にアクセスしてきた場合、再度、当該ＩＰ電話端末１４がメインサーバ１２側にアクセスしたときにはすでにその障害は復旧していて、正常なアクセスが行える可能性が高い。

メインサーバ１２を利用した場合、他の拠点（例えば、ＳＴ３）内のＩＰ電話端末へも発呼できるのに対し、サバイバルサーバ１３を利用すると、発呼できるＩＰ電話端末が拠点ＳＴ２内のものに制限される点で不便であるから、アクセス先のサーバ１２，１３に関する不要な切り替えは防止できたほうがユーザＵ１にとっても便利である。

また、同じ拠点ＳＴ２内のＩＰ電話端末に発呼しようとする場合にはサバイバルサーバ１３を利用しても、ユーザＵ１がこのような制限を意識することはないが、その場合でも、上述したように、システムの仕様が、アクセスするサーバを切り替える際、メインサーバ１２が自身の再起動を実行し、再起動後にも正常な処理を行えないか否かを確認する手順なども含むものであるケースには、長時間（例えば、５分程度）、ＩＰ電話端末はいずれのサーバも利用することができない状態となるため、アクセスするサーバに関する不要な切り替えを防止できれば、可用性が高まり、ユーザＵ１が長時間待たされることもなくなる。

さらに、上述したように、システムの仕様が、サバイバルサーバ１３を利用中、サバイバルサーバ１３に蓄積された様々な管理情報（例えば、各ＩＰ電話端末１４に割り当てるＩＰアドレスと電話番号の対応関係など）の変更を認めるものである場合には、ＩＰ電話端末１４のアクセス先のサーバに関して不要な切り替えが発生すると、サバイバルサーバ１３が蓄積する管理情報とメインサーバ１２が蓄積する管理情報の内容を整合させる処理（同期処理）の頻度が高くなって資源の実質的な利用効率を低下させる可能性が高いが、アクセス先のサーバに関して不要な切り替えを防止できれば、この点で、資源の実質的な利用効率を高めることができる。

前記ステップＳ１４において、１個のヘルスチェック応答信号ＲＳ１さえ返送されてくることなく前記タイムアウト時間が経過し、当該ステップＳ１４がＹＥＳ側に分岐すると、サバイバルサーバ１３はその時点におけるポート状態を確認する（Ｓ１５）。このステップＳ１５は前記ステップＳ１７に対応する処理である。ただし、前記ステップＳ１７はポートを開放するものであったのに対し、当該ステップＳ１７はポートを閉塞するためのものである。したがって、その時点のポートがオープン状態である場合には現状を維持し、クローズ状態である場合には、ポートを開放する（Ｓ１６）。

サバイバルサーバ１３のポートが開放されている場合、前記ＩＰ電話端末１４が、アドレス解決や呼制御メッセージの送信などのためにアクセスしてくると、サバイバルサーバ１３がそれを受け付けることができる。このようにポートが開放されているときに、ＩＰ電話端末１４がそのポートを介してサバイバルサーバ１３にアクセスしてくるということは、ＩＰ電話端末１４とサバイバルサーバ１３の双方が、メインサーバ１２または伝送経路のいずれかに障害が発生したものと判定したことを意味するから、メインサーバ１２や伝送経路の障害が極めて短時間で復旧する一時的なものではなく、比較的長時間にわたって継続するものであるケースに該当する。

ただしこの場合、上述したようにサバイバルサーバ１３の管理範囲は拠点ＳＴ２内に限られているため、前記ＩＰ電話端末１４が例えば拠点ＳＴ３内のいずれかのＩＰ電話端末（図示せず）に発呼しようとしても、サバイバルサーバ１３単独では、そのためのアドレス解決や呼制御メッセージの送信を処理することができない。このような発呼は、前記メインサーバ１２または伝送経路が復旧するのを待って、メインサーバ１２にアクセスすることにより可能となる。

上述したステップＳ１５〜Ｓ１８につづいて、処理は前記ステップＳ１１に戻る。したがって、ポートを閉塞した場合も開放した場合も、サバイバルサーバ１３は、前記メインサーバ１２へヘルスチェック要求信号ＲＱ１を送信し、メインサーバ１２のヘルスチェックを繰り返すことになる。

当該サバイバルサーバ１３からＩＰ網１１経由で到来するヘルスチェック要求信号ＲＱ１を処理するため、メインサーバ１２は次の処理を実行する。

すなわち、図４に示すように、前記ヘルスチェック要求信号ＲＱ１を受信すると（ステップＳ２１のＹＥＳ側の分岐）、そのヘルスチェック要求信号ＲＱ１に応えるヘルスチェック応答信号ＲＳ１を返送する（Ｓ２２）操作を繰り返す。

拠点ＳＴ２以外の拠点であるＳＴ３，ＳＴ４のサバイバルサーバ（図示せず）から到来するヘルスチェック要求信号に対しても、メインサーバ１２は、図４と同様の処理を行い、前記ヘルスチェック応答信号ＲＳ１と同様なヘルスチェック応答信号を返送する。

（Ａ−３）実施形態の効果
本実施形態によれば、ＩＰ電話端末（例えば、１４）に関するアクセス先のサーバの不要な切り替えの発生頻度を低減することで、利便性および可用性を高め、資源の実質的な利用効率を高めることができる。

（Ｂ）他の実施形態
上記実施形態にかかわらず、ＶｏＩＰ通信システム１０内の拠点（ＳＴ１〜ＳＴ４）の数を４つに限定する必要はないことは当然である。

なお、上記実施形態では、各拠点内に１つのサバイバルサーバを設置したが、拠点内のサバイバルサーバの数は必ずしも１つに限定する必要はない。

また、サバイバルサーバの管理範囲は、必ずしも当該サバイバルサーバが設置されている拠点（例えば、ＳＴ２）の内部に限定する必要はない。ＩＰ網１１内における障害の発生箇所や障害の態様などによっては、拠点ＳＴ１との通信はできなくても、他の拠点（例えば、ＳＴ３）との通信は行える可能性があるため、拠点ＳＴ１との通信が行えないからといって、他のすべての拠点ＳＴ３およびＳＴ４との通信を諦める必要はないからである。

さらに、上記実施形態にかかわらず、本発明は、ＩＰ電話以外の通信アプリケーションに適用できる可能性がある。

なお、上記実施形態で使用した通信プロトコルは他の通信プロトコルに置換可能である。

例えば、ＩＰプロトコルは、ＯＳＩ参照モデルのネットワーク層またはその他の階層に位置する他の通信プロトコルに置換可能である。一例として、ＩＰＸプロトコルなどを利用できる可能性もある。

以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんど全ては、ハードウエア的に実現することが可能である。

実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。 実施形態にかかるＶｏＩＰ通信システムで使用するサバイバルサーバ（または、メインサーバ）の内部構成例を示す概略図である。 実施形態におけるサバイバルサーバの動作例を示す概略図である。 実施形態におけるメインサーバの動作例を示す概略図である。 実施形態で使用するＩＰ電話端末の内部構成例を示す概略図である。

符号の説明

１０…ＶｏＩＰ通信システム、１１…ＩＰ網、１２…メインサーバ、１３…サバイバルサーバ、１４〜１６…ＩＰ電話端末、２０…端末収容部、２１…装置管理部、２２…呼処理部、２３…データベース部、３０…通信部、３１…制御部、３２…操作部、３３…記憶部、３４…ヘルスチェック部、３５…接続サーバ切替部、３６…呼制御部、３７…表示部、ＳＴ１〜ＳＴ４…拠点、ＲＱ１…ヘルスチェック要求信号、ＲＳ１…ヘルスチェック応答信号。

Claims (3)

1. 複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、前記通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御システムにおいて、
   前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、
   当該副呼制御サーバは、
   前記主呼制御サーバに宛てて、正常性確認のための応答を要求する応答要求信号を所定時間ごとに所定数以上、送信する応答要求部と、
   当該応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定するサーバ側正常性判定部と、
   当該サーバ側正常性判定部が、正常であるとの判定結果を出した場合、当該副呼制御サーバの管理範囲内の通信端末から到来した呼制御メッセージの受け付けを拒否する受付制御部とを備え、
   前記通信端末は、
   前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定する端末側正常性判定部と、
   当該端末側正常性判定部が、正常でないとの判定結果を出した場合、呼制御メッセージの中継処理依頼先を前記主呼制御サーバから副呼制御サーバに切り替えるものの、当該呼制御メッセージの受け付けが前記受付制御部によって拒否されると、前記中継処理依頼先を主呼制御サーバに戻す依頼先決定部とを備えたことを特徴とする呼制御システム。
2. 複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、前記通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御方法において、
   前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、当該副呼制御サーバでは、
   応答要求部が、前記主呼制御サーバに宛てて、正常性確認のための応答を要求する応答要求信号を所定時間ごとに所定数以上、送信し、
   サーバ側正常性判定部が、当該応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定し、
   当該サーバ側正常性判定部が、正常であるとの判定結果を出した場合、受付制御部が、当該副呼制御サーバの管理範囲内の通信端末から到来した呼制御メッセージの受け付けを拒否し、
   前記通信端末では、
   端末側正常性判定部が、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定し、
   当該端末側正常性判定部が、正常でないとの判定結果を出した場合、依頼先決定部が、呼制御メッセージの中継処理依頼先を前記主呼制御サーバから副呼制御サーバに切り替えるものの、当該呼制御メッセージの受け付けが前記受付制御部によって拒否されると、前記中継処理依頼先を主呼制御サーバに戻すことを特徴とする呼制御方法。
3. 複数の通信端末を含む拠点を複数有する所定の管理範囲のなかで、前記通信端末間の呼制御メッセージの中継処理を行うこと等により、少なくとも呼制御を管理する主呼制御サーバを用いる呼制御プログラムにおいて、
   前記各拠点には、少なくともその拠点のなかを管理範囲とする副呼制御サーバを設けておき、当該副呼制御サーバでは、コンピュータに、
   前記主呼制御サーバに宛てて、正常性確認のための応答を要求する応答要求信号を所定時間ごとに所定数以上、送信する応答要求機能と、
   当該応答要求信号に対する前記主呼制御サーバからの応答状況に応じて、前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定するサーバ側正常性判定機能と、
   当該サーバ側正常性判定機能が、正常であるとの判定結果を出した場合、当該副呼制御サーバの管理範囲内の通信端末から到来した呼制御メッセージの受け付けを拒否する受付制御機能とを実現させ、
   前記通信端末では、コンピュータに、
   前記主呼制御サーバまたは当該拠点から主呼制御サーバにいたる伝送経路が正常であるか否かを判定する端末側正常性判定機能と、
   当該端末側正常性判定機能が、正常でないとの判定結果を出した場合、呼制御メッセージの中継処理依頼先を前記主呼制御サーバから副呼制御サーバに切り替えるものの、当該呼制御メッセージの受け付けが前記受付制御機能によって拒否されると、前記中継処理依頼先を主呼制御サーバに戻す依頼先決定機能とを実現させたことを特徴とする呼制御プログラム。

Images