呼制御システム、呼制御方法及びサーバ
【課題】主呼処理手段及び又は主呼処理手段までの伝送経路上に障害が発生したときに、通話中の呼に影響与えずに通話を維持することができるようにする。
【解決手段】本発明の呼制御システムは、複数の通信端末を含む拠点を複数有するネットワークにおいて、通信端末間の呼処理を行なう主呼処理手段と、障害検出部により障害が検出されたとき、各拠点内に位置する通信端末の呼を主呼処理手段に代わって呼処理を行なう副呼処理手段と、主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを備え、副呼処理手段が、呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持部と、主呼処理手段に障害が検出されたときに、呼制御情報保持部に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済部とを有することを特徴とする。
【解決手段】本発明の呼制御システムは、複数の通信端末を含む拠点を複数有するネットワークにおいて、通信端末間の呼処理を行なう主呼処理手段と、障害検出部により障害が検出されたとき、各拠点内に位置する通信端末の呼を主呼処理手段に代わって呼処理を行なう副呼処理手段と、主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを備え、副呼処理手段が、呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持部と、主呼処理手段に障害が検出されたときに、呼制御情報保持部に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済部とを有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼制御システム、呼制御方法及びサーバに関し、例えば、ＩＰ（インタネットプロトコル）網を利用して音声通信を実現する音声通信システムに適用し得る。
【背景技術】
【０００２】
例えば、ＩＰ網を利用して音声通信を実現する音声通信システムにおいては、企業等のセンタ拠点にＩＰ−ＰＢＸ機能を有するサーバ（メインサーバ）を設置して、拠点内又は拠点間の電話サービスを提供するＩＰセントレックスシステムがある。
【０００３】
このＩＰセントレックスシステムによる企業内音声通信ネットワークでは、メインサーバが、ＩＰ網を経由して、ＩＰ電話端末（例えば、ソフトフォン、ハードフォン等）から発呼要求を受けると、メインサーバは、要求先の他のＩＰ電話端末との間で呼接続を制御し、要求元のＩＰ電話端末と要求先のＩＰ電話端末との間の呼を確立している（特許文献１参照）。
【０００４】
ところで、このようなＩＰセントレックスシステムによる企業内音声通信ネットワークにおいて、センタ拠点に設置されたメインサーバに障害が発生したり、ＩＰ網の障害でセンタ拠点との通信が行なえなくなった場合などには、各拠点内のすべてのＩＰ電話端末の利用ができなくなり、音声通信サービスが停止してしまう。
【０００５】
このため、従来は、各拠点にメインサーバの代替手段となるサーバ（サバイバルサーバ）を設置し、メインサーバに障害が発生したり、ＩＰ網の障害でセンタ拠点との通信が行なえなくなった場合、ＩＰ電話端末に関する管理をメインサーバからサバイバルサーバに切り替え、拠点内の音声通信を継続するようにしている。
【０００６】
従来、この場合のサバイバルサーバヘの切り替え方法として、例えば、ＩＰ電話端末にメインサーバと各拠点のサバイバルサーバとのネットワーク情報（例えば、ＩＰアドレス等）を設定しておき、ＩＰ電話端末がメインサーバとの間の通信障害を検出すると、ＩＰ電話端末側で端末ソフトウェアの再起動を行ない、接続先をサバイバルサーバに変更し、サバイバルサーバ側では端末の障害復旧という形でＩＰ電話端末を組み込む、という方法がある（特願２００４−３５２９８４号明細書参照）。
【０００７】
【特許文献１】特開２００１−８６１６６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述したように、従来のＩＰセントレックスによる企業内音声通信ネットワークにおいては、ＩＰ電話端末がＩＰ電話端末とメインサーバとの間の通信障害発生を検出すると、ＩＰ電話端末は、接続先サーバを変更するために、端末内の呼制御プログラムにリセットをかけて、新たな接続先とした呼制御プログラムを再起動させることとしているため、その再起動に伴う通話中呼の切断が発生してしまうという問題がある。
【０００９】
また、ＩＰセントレックスによる企業内音声通信ネットワークは、各拠点間の距離が離れているのでメインサーバと各サバイバルサーバとの間も距離が離れて設けられており呼制御情報を単に共有することは困難であり、またリアルタイム性も要求される。
【００１０】
そのため、主呼処理手段及び又は主呼処理手段までの伝送経路上に障害が発生したときに、通話中の呼に影響与えずに通話を維持することができる呼制御システム、呼制御方法及びサーバが求められている。
【課題を解決するための手段】
【００１１】
かかる課題を解決するため、第１の本発明の呼制御システムは、（１）複数の通信端末を含む拠点を複数有するネットワークにおいて、通信端末間の呼処理を行なう主呼処理手段と、（２）障害検出部により主呼処理手段及び又は呼処理手段までの伝送経路上に障害が検出されたとき、各拠点内に位置する通信端末の呼を主呼処理手段に代わって呼処理を行なう副呼処理手段と、（３）主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを備え、副呼処理手段が、（２−１）呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持部と、（２−２）主呼処理手段に障害が検出されたときに、呼制御情報保持部に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済部とを有することを特徴とする。
【００１２】
第２の本発明のサーバは、複数の通信端末を含む拠点を複数有するネットワークで、通信端末間の呼処理を行なう主呼処理手段を有するサーバと、主呼処理手段及び又は呼処理手段までの伝送経路上に障害が発生したときに、主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの主呼制御手段を有するサーバにおいて、（１）主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段を備えることを特徴とする。
【００１３】
第３の本発明のサーバは、複数の通信端末を含む拠点を複数有するネットワークで、通信端末間の呼処理を行なう主呼処理手段と、主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを有するサーバと、主呼処理手段及び又は呼処理手段までの伝送経路上に障害が発生したときに、主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの副呼制御手段を有するサーバにおいて、（１）呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持手段と、（２）主呼処理手段に障害が検出されたときに、呼制御情報保持手段に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済手段とを有することを特徴とする。
【００１４】
第４の本発明の呼制御方法は、（１）主呼処理手段が、複数の通信端末を含む拠点を複数有するネットワークにおいて、通信端末間の呼処理を行なう主呼処理工程と、（２）副呼処理手段が、障害検出部により主呼処理手段及び又は呼処理手段までの伝送経路上に障害が検出されたとき、各拠点内に位置する通信端末の呼を主呼処理手段に代わって管理する副呼処理工程と、（３）呼制御情報転送手段が、主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送工程とを備え、副呼処理手段が、（２−１）呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持工程と、（２−２）主呼処理手段に障害が検出されたときに、呼制御情報保持手段に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済工程とを有することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、主呼処理手段及び又は主呼処理手段までの伝送経路上に障害が発生したときに、通話中の呼に影響与えずに通話を維持することができる。
【発明を実施するための最良の形態】
【００１６】
（Ａ）第１の実施形態
以下、本発明の呼制御システム、呼制御方法及びサーバの第１の実施形態を、図面を参照しながら詳細に説明する。
【００１７】
本実施形態は、本発明の呼制御システム、呼制御方法及びサーバを利用して、ＩＰセントレックスによる企業内音声通信ネットワークを実現する形態を説明する。
【００１８】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係る音声通信ネットワークの全体構成を示す図である。図１において、本実施形態の音声通信ネットワーク１は、ＩＰ網ＮＴと、ＩＰ網ＮＴに接続するＩＰセントレックスセンタ拠点ＳＴ１と、拠点ＳＴ２とを有して構成される。
【００１９】
ここで、ＩＰ網ＮＴは、ＯＳＩ参照モデルのネットワーク層の通信プロトコルとしてＩＰプロトコルが用いられる通信網であり、本実施形態では、例えば、通信事業者が運営するＩＰ網を想定するが、例えば、インターネットなどに代表される公衆のＩＰ網としてもよい。
【００２０】
ＩＰセントレックスセンタ拠点ＳＴ１（以下、単に拠点ＳＴ１と呼ぶ）は、例えば企業の本社等に構築されているネットワーク（例えば、ＬＡＮ等）が該当し、また拠点ＳＴは、例えばその企業の支社等で構築されるネットワーク（例えば、ＬＡＮ等）が該当する。なお、図１では、拠点として拠点ＳＴ１及びＳＴ２の２拠点のみを示しているが、拠点ＳＴ２と同様の機能をもつ拠点を複数備えるようにしてもよい。例えば、企業内音声通信ネットワークの規模については様々であるが、大規模なものであれば、メインサーバ１０が管理可能なＩＰ電話端末数として例えば５０００台程度のものがある。
【００２１】
拠点ＳＴ１には、図１に示すように、メインサーバ１０が設置されている。なお、図１では、図示していないが、拠点ＳＴ１は、メインサーバ１０以外のネットワーク装置（例えば、ルータやスイッチ等）やＩＰ電話端末等を備えていてもよい。
【００２２】
拠点ＳＴ２は、図１に示すように、サバイバルサーバ１２と、複数のＩＰ電話端末１１−１〜１１−Ｎ（図１ではＮ（Ｎは正の整数））とを有して構成されている。なお、拠点ＳＴ２においても、これら以外のネットワーク装置（例えば、ルータやスイッチ等）を備えていてもよい。また、サバイバルサーバ１２の設置台数は、特に限定されるものではなく、複数台であってもよい。
【００２３】
メインサーバ１０は、拠点ＳＴ１内に設置されているものであって、図１に示す音声通信ネットワーク１の全体を管理範囲として、呼制御機能や端末制御機能等を備えるサーバであり、例えば、ＩＰ−ＰＢＸ（あるいは、コールエージェント）等としての機能を有するものである。
【００２４】
ここで、音声通信ネットワーク１内で用いられる呼制御プロトコルは、特に限定されるものではなく種々のプロトコルを適用することができるが、例えばＩＴＵ−Ｔ勧告Ｈ．３２３やＳＩＰ（セッション・イニシエーション・プロトコル）などを適用できる。そして、例えばＩＴＵ−Ｔ勧告Ｈ．３２３を適用する場合には、メインサーバ１０のＩＰ−ＰＢＸにはゲートキーパの機能を搭載する必要があり、例えばＳＩＰを適用する場合には、メインサーバ１０はロケーションサーバなども含むＳＩＰサーバの機能を搭載する必要がある。
【００２５】
また、メインサーバ１０は、呼制御機能として、拠点ＳＴ２内の任意のＩＰ電話端末（例えば、１４）が他のＩＰ電話端末に対して発呼しようとする場合、アドレス解決（電話番号に対応するＩＰアドレスの取得）などのためにＩＰ−ＰＢＸの機能を用いる。また、具体的な呼制御の手順にも依存するが、通常、ＩＰ電話端末が送信する呼制御メッセージの多くは、ＩＰ−ＰＢＸであるメインサーバ１０を経由し、その着信先とするＩＰ電話端末に対して、呼制御メッセージを中継することで、ＩＰ電話端末間の呼を確立する。
【００２６】
また、呼の確立後でも、ＩＰ−ＰＢＸであるメインサーバ１０は、音声通信ネットワーク１内の各ＩＰ電話端末の状態（例えば、通話中か否か等の状態）を示す呼制御情報を管理する。メインサーバ１０は、呼確立した各ＩＰ電話端末の呼制御情報を、サバイバルサーバ１２に転送するものである。これにより、メインサーバ１０が、管理しているＩＰ電話端末の呼制御情報をサバイバルサーバ１２においても管理させることができる。さらに、メインサーバ１０は、ＩＰ電話端末から切断信号を受け取ると、そのＩＰ電話端末間の呼の切断を行なうと共に、サバイバルサーバ１２に対して当該ＩＰ電話端末間の呼の終了を知らせる切断情報を転送する。
【００２７】
さらに、メインサーバ１０は、端末制御機能として、ＩＰ電話端末における、転送、ボタンの割り付け、ＶＬＡＮ、優先制御などに関連する動作を制御するものである。例えば、ＩＰ電話端末１１−１〜１１−Ｎが多機能電話機に相当するものである場合、着信転送など転送の際に必要な情報、ボタンの割付けに関する情報、ＶＬＡＮ、ＴｏＳ（タイプ・オブ・サービス）などに関する情報を、メインサーバ１０はＩＰ電話端末１４に送信して記憶させるものである。ここで、ＶＬＡＮに関する情報は音声通信ネットワーク１内でＶＬＡＮを用いる場合に必要であり、ＴｏＳに関する情報は、音声通信ネットワーク１内の図示しない中継装置（例えば、ルータ）で優先制御を行なう場合、この優先制御のために、ＩＰ電話端末が送信するＩＰパケットについて、そのヘッダのＴｏＳフィールドに記述させる情報である。
【００２８】
サバイバルサーバ１２は、拠点ＳＴ２内に設置されているものであって、拠点２の内部を管理範囲として、呼制御機能や端末制御機能等を備えるサーバであり、基本的にはメインサーバ１０と同様の機能を有するものである。サバイバルサーバ１２は、メインサーバ１０やメインサーバ１０までの伝送経路に障害が発生した場合に、メインサーバ１０に代わってＩＰ電話端末間の呼処理を行なうサーバとして機能する。そして、障害が解消されてメインサーバ１０が回復すると、再度、メインサーバ１０が主導的にＩＰ電話端末の呼処理を行なうように切り戻しされ、サバイバルサーバ１２はその後の障害発生に備えるものである。
【００２９】
サバイバルサーバ１２は、その詳細は後述するが、所定の周期で、メインサーバ１０との間の伝送経路が正常であるか否かを検査するヘルスチェックを行ない、メインサーバ１０及び又はメインサーバ１０までの伝送経路におけるＩＰ網ＮＴ回線上に障害が発生したか否かを判断するものである。そして、メインサーバ１０及び又はメインサーバ１０までの間の伝送経路におけるＩＰ網ＮＴ回線に障害が発生したと判定した場合、サバイバルサーバ１２は、それまでメインサーバ1１０が行なっていた呼処理を、メインサーバ１０に代わって行なうようにする切り替え処理を行なうものである。
【００３０】
ＩＰ電話端末１１−１〜１１−Ｎは、ＶｏＩＰ対応機能を有するものであり、例えば、ハードフォン（携帯ＩＰ電話端末を含む概念）や、ソフトフォンや、アダプタを用いてＶｏＩＰ対応機能を持たない一般電話機をＩＰ網ＮＴに接続可能とした電話端末等が該当する。
【００３１】
また、ＩＰ電話端末１１−１〜１１−Ｎは、自身でメインサーバ１０及びＩＰ電話端末１１−１〜１１−Ｎからメインサーバ１０に至る伝送経路が正常であると判定する機能を備えている。
【００３２】
（Ａ−１−１）メインサーバ１０及びサバイバルサーバ１２の内部機能構成
図２は、メインサーバ１０及びサバイバルサーバ１２の内部構成を示す機能ブロック図である。
【００３３】
上述したように、メインサーバ１０とサバイバルサーバ１２の基本的な機能は同じであるので、メインサーバ１０とサバイバルサーバ１２とに共通する機能を説明すると共に、それぞれの特有の機能についても説明する。
【００３４】
図２において、本実施形態のメインサーバ１０及びサバイバルサーバ１２は、端末収容機能部２０と、装置管理機能部２１と、呼処理機能部２２と、データベース部２３とを備えている。
【００３５】
呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎ間でやり取りされる呼制御メッセージの中継などを行ない、ＩＰ電話端末１１−１〜１１−Ｎ間の呼を確立する機能部である。
【００３６】
メインサーバ１０における呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎ間の呼接続の進行状況などを示す情報を収集するものである。また、メインサーバ１０における呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎ間の呼が確立すると、呼が確立したＩＰ電話端末１１−１〜１１−Ｎに関する呼制御情報を、当該ＩＰ電話端末１１−１〜１１−Ｎを管理しているサバイバルサーバ１２に送信させるものである。これにより、メインサーバ１０が管理している呼制御情報をサバイバルサーバ１２にも管理させることができる。また、メインサーバ１０は、ＩＰ電話端末から切断信号を受信すると、当該ＩＰ電話端末の呼の切断処理を行なうと共に、当該ＩＰ電話端末についての切断情報を、サバイバルサーバ１２に送信させるものである。
【００３７】
サバイバルサーバ１２における呼処理機能部２２は、メインサーバ１０から呼制御情報を受信すると、その受信した呼制御情報をデータベース部２３に保持させるものである。これにより、メインサーバ１０が管理する呼制御情報と同じ呼制御情報をサバイバルサーバ１２においても管理することができる。また、サバイバルサーバ１２における呼処理機能部２２は、メインサーバ１０から切断情報を受信すると、対応するＩＰ電話端末について呼の切断処理を行なうものである
また、サバイバルサーバ１２において、後述する装置管理機能部２１がメインサーバ１０及び又はメインサーバ１０までの間の伝送経路におけるＩＰ網ＮＴの回線上の障害発生を検出すると、呼処理機能部２２は、管理している呼制御情報に基づいて、呼を確立しているＩＰ電話端末に対してリセットをかけない呼救済再開処理を行なうものである。すなわち、呼処理機能部２２は、接続先サーバ情報としてサバイバルサーバ１２を指定した再開要求メッセージを、すべてのＩＰ電話端末１１−１〜１１−Ｎに対して送信する。これにより、ＩＰ電話端末１１−１〜１１−Ｎが呼処理サーバとしてアクセスする接続先サーバを、メインサーバ１０からサバイバルサーバ１２に変更させることができ、その接続先サーバの変更のみで呼救済させることができる。つまり、呼確立中のＩＰ電話端末については、呼処理に関するプログラムを再起動しなくても、接続先サーバを変えるだけで呼救済することができる。
【００３８】
また、サバイバルサーバ１２において、障害が解消してメインサーバ１０が回復すると、呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎへリセットをかける非救済再開処理を行なうものである。すなわち、呼処理機能部２２は、接続先サーバ情報としてメインサーバ１０を指定した再開要求メッセージを、すべてのＩＰ電話端末１１−１〜１１−Ｎに対して送信する。
【００３９】
データベース部２３は、管理範囲内の各ＩＰ電話端末１１−１〜１１−Ｎに関する情報を蓄積するものである。データベース部２３は、例えば、各ＩＰ電話端末１１−１〜１１−Ｎに割り当てられているＩＰアドレスと電話番号の対応関係などの情報や、呼処理機能部２２により収集されたＩＰ電話端末１１−１〜１１−Ｎの状態を示す情報なども蓄積するものである。
【００４０】
メインサーバ１０におけるデータベース部２３は、その管理範囲が音声通信ネットワーク１全体であるから、拠点ＳＴ１だけでなく、拠点ＳＴ２のＩＰ電話端末に関するこれらの情報も蓄積する。
【００４１】
サバイバルサーバ１２におけるデータベース部２３は、その管理範囲が拠点ＳＴ２内に限られるため、拠点ＳＴ２内に設置されたＩＰ電話端末１１−１〜１１−Ｎに関するこれらの情報のみを蓄積する。また、サバイバルサーバ１２において、データベース部２３は、メインサーバ１０から送信された呼制御情報を管理するものである。
【００４２】
装置管理機能部２１は、対象とする装置を管理する機能部である。メインサーバ１０における装置管理機能部２１は、呼を確立したＩＰ電話端末１１−１〜１１−Ｎの管理機能や、サバイバルサーバ１２からのヘルスチェックに対する応答機能を有する。このサバイバルサーバ１２からのヘルスチェックに対する応答処理とは、サバイバルサーバ１２からヘルスチェック要求信号を受信すると、それに応答するヘルスチェック応答信号をサバイバルサーバ１２に返信するものである。
【００４３】
サバイバルサーバ１２における装置管理機能部２１は、メインサーバ１０との間の伝送経路が正常であるか否かを管理するヘルスチェック機能を有する。
【００４４】
ここで、本実施形態のサバイバルサーバ１２における装置管理機能部２１のヘルスチェックは、所定の周期で、ヘルスチェック要求信号をメインサーバ１０に送信し、所定の返信期間内に、メインサーバ１０からヘルスチェック応答信号の返信があると、メインサーバ１０との間の伝送経路は正常であることとする。
【００４５】
なお、本実施形態では、サバイバルサーバ１２の装置管理機能部２１が、６０秒毎にヘルスチェック要求信号をメインサーバ１０に送信し、６回連続してタイムアウトした場合、メインサーバ１０及び又はＩＰ網ＮＴ回線に障害が生じたと判断するものとする。
【００４６】
端末収容機能部２０は、管理範囲内の任意のＩＰ電話端末から呼制御メッセージの受付けなどを行なうためのポートを有する機能部である。メインサーバ１０においては、端末収容機能部２０は、常時、ポートの受付けを許可する状態である。サバイバルサーバ１２においては、端末収容機能部２０は、装置管理機能部２１によるヘルスチェックの結果が、受付けを許可するのは、メインサーバ１０及び又は伝送経路の少なくともいずれかが正常でないと判定した場合であり、拒否するのは、前記メインサーバ１０及び伝送経路の双方が正常であると判定した場合である。
【００４７】
（Ａ−１−２）ＩＰ電話端末の内部機能構成
図３は、ＩＰ電話端末１１−１〜１１−Ｎは、通信部３０と、制御部３１と、操作部３２と、記憶部３３と、ヘルスチェック部３４と、接続サーバ切替部３５と、呼制御部３６と、表示部３７とを備えている。
【００４８】
制御部３１は、ＩＰ電話端末１１−１〜１１−Ｎの機能を司るものであり、ハードウェア的にはＩＰ電話端末１１−１〜１１−ＮのＣＰＵ（中央処理装置）が該当し、ソフトウェア的にはＯＳ（オペレーティングシステム）などの制御プログラムが該当する。
【００４９】
記憶部３３は、揮発性又は不揮発性の記憶資源である。記憶部３３には、ＩＰ電話端末１１−１〜１１−Ｎの機能を実現させる処理プログラムを格納するものである。そして、制御部３１が、記憶部３３に格納されている処理プログラムを読み出して実行することにより、ＩＰ電話端末１１−１〜１１−Ｎとしての機能を実現することができる。
【００５０】
呼制御部３６は、制御部３１の制御下で、他のＩＰ電話端末１１−１〜１１−Ｎと通話をするために、メインサーバ１０との間で呼制御メッセージの生成や授受などを実行するものである。呼制御部３６は、呼制御を実行するための所定の呼制御ソフトウェア（プロセス）を記憶部３３に保持しており、通常時に呼接続するための接続先サーバをメインサーバ１０としている。
【００５１】
ヘルスチェック部３４は、アクセスするサーバ（例えば、メインサーバ１０、サバイバルサーバ１２）及び当該サーバまでの伝送経路の正常性を検査する部分である。ヘルスチェック部３４は、呼が確立すると、メインサーバ１０から周期的に受信したヘルスチェック要求信号に対してヘルスチェック応答信号を返信する。
【００５２】
ヘルスチェック部３４は、メインサーバ１０からの周期的なヘルスチェック要求信号の受信がなされないことを検出すると、直前のヘルスチェック応答信号の返信時刻から所定時間（例えば、２分）連続して届かなかった場合、正常でないことを判定する。この所定時間の間のヘルスチェック期間をヘルスチェックタイミング期間という。
【００５３】
ここで、ヘルスチェック部３４による検査方式は、特に限定されるものではなく広く適用することができる。上述したヘルスチェック方法のほかに、例えば、常時メインサーバ１０とＩＰ電話端末１１−１〜１１−Ｎとの間でＴＣＰコネクションを確立することで伝送経路の正常性を判断する方法を適用する場合、このＴＣＰコネクションが切断されたことを、ヘルスチェック部３４が検出することで、メインサーバ１０との間の伝送経路までが正常でないと判定するようにしてもよい。また、別な方法として、ＩＰ電話端末１１−１〜１１−Ｎが例えば呼制御メッセージの中継を依頼する際などにメインサーバ１０にアクセスしたとき、正常な応答がなければ、正常でないと判定するようにしてもよい。
【００５４】
ヘルスチェック要求信号やヘルスチェック応答信号の送受に際し、ＯＳＩ参照モデルのトランスポート層では、ＴＣＰ等のコネクション型の通信プロトコルを用いてもよいが、ここでは、ＵＤＰ等のコネクションレス型の通信プロトコルを用いるものとする。
【００５５】
通信部３０は、ＩＰ電話端末１１−１〜１１−Ｎが拠点ＳＴ２内のネットワークやＩＰ網ＮＴを経由して通信を行なうものである。すなわち、通信部３０は、制御や管理のために行なわれるメインサーバ１０又はサバイバルサーバ１２との通信と、通話相手のＩＰ電話端末との間で行なわれるリアルタイムな音声通信を行なうものである。
【００５６】
また、通信部３０は、制御部３１の制御下で、ヘルスチェックタイミング期間経過後から所定時間の間（本実施形態では、例えば３分とし、この期間を再接続待ちタイミング期間という）までは、前回接続していたサーバのみからの再開要求メッセージを受信するようにする。このように、再開要求メッセージを受け取る先を前回接続していたサーバ（例えばメインサーバ１０）のみとすることにより、直ぐに復旧できる軽度の障害が一時的に発生した場合には、メインサーバ１０が送信した再開要求メッセージを優先的に受信することができる。
【００５７】
さらに、通信部３０は、制御部３１の制御下で、再接続待ちタイミング期間経過後から所定時間（本実施形態では、例えば５分とし、この期間をサバイバル再開受付タイミング期間という）までは、メインサーバ１０だけでなくサバイバルサーバ１２からの再開要求メッセージを受信するようにする。これにより、再接続待ち来ミング経過後に、サバイバルサーバ１２が送信した再開要求メッセージをも受信することができる。
【００５８】
接続サーバ切替部３５は、制御部３１の制御下で、当該ＩＰ電話端末１１−１〜１１−Ｎが呼制御やアドレス解決のために、呼制御部３６がアクセスする接続先のサーバ１０又は１２を切り替え制御するものであり、通常の場合、呼制御部３６の接続先をメインサーバ１０としている。
【００５９】
また、接続サーバ切替部３５は、制御部３１の制御下で、受信した再開要求メッセージに含まれている接続先サーバ情報に従って、呼制御のためにアクセスする接続先サーバを変更し、接続するサーバを切り替えるものとする。これにより、障害発生時に、接続先サーバをサバイバルサーバ１２と指定されている再開要求メッセージを受信すると、呼制御部３６は、呼制御に係るサーバの接続先をメインサーバ１０からサバイバルサーバ１２に変更することができる。これにより、呼制御ソフトウェアを再起動することなく、呼救済がされる。
【００６０】
操作部３２は、ＩＰ電話端末１１−１〜１１−ＮのユーザＵ１が操作するユーザインタフェースである。操作部３２は、少なくとも通話相手の電話番号等を指定するための入力ボタン等が該当し、また多機能電話として機能する場合、それら機能を実行させるために必要なボタンが該当する。
【００６１】
表示部３７は、制御部３１からユーザＵ１に情報を伝えるための部分である。具体的には、例えば、液晶表示装置や、発光ＬＥＤ素子等によって当該表示部３７を構成することができる。
【００６２】
（Ａ−２）第１の実施形態の動作
次に、本実施形態の音声通信ネットワーク１における呼制御処理の動作を図面を参照しながら説明する。
【００６３】
図４は、メインサーバ１０とサバイバルサーバ１２との間で同じ呼制御情報を保持する処理を示すシーケンスである。
【００６４】
図４では、メインサーバ１０がＩＰ電話端末１１−１とＩＰ電話端末１１−２との間の呼制御を行なう場合を例に挙げて説明する。
【００６５】
まず、ＩＰ電話端末１１−１は、着信先をＩＰ電話端末１１−２とする呼設定要求をメインサーバ１０に送信する。ＩＰ電話端末１１−１から呼設定要求を受け取ると、メインサーバ１０においては呼制御部３６により、所定の呼制御プロトコルに従って着信先のＩＰ電話端末１１−２との間で呼制御を行なう（Ｓ１０１）。なお、メインサーバ１０による呼制御シーケンスについては特徴がないのでここでの詳細な説明は省略する。
【００６６】
メインサーバ１０において、ＩＰ電話端末１１−１とＩＰ電話端末１１−２との間の呼制御処理がなされ、呼が確立すると（Ｓ１０２）、メインサーバ１０において、ＩＰ電話端末１１−１とＩＰ電話端末１１−２との呼状態に係る呼制御情報がデータベース部２３に保持される（Ｓ１０３）。この呼制御情報は、呼確立後、例えば、ＩＰ電話端末１１−１及び１１−２が通話状態である等のような情報であり、メインサーバ１０は、この呼制御情報を保持し、その後の切断処理や保留処理や転送処理等の電話サービスを提供する際に、呼制御情報を利用している。
【００６７】
メインサーバ１０により、ＩＰ電話端末１１−１及び１１−２間の呼が確立し、それに係る呼制御情報が保持されると、当該保持された呼制御情報が、メインサーバ１０からサバイバルサーバ１２に転送される（Ｓ１０４）。
【００６８】
メインサーバ１０から呼制御情報が与えられると、サバイバルサーバ１２において、受信した呼制御情報はデータベース部２３に保持される（Ｓ１０５）。
【００６９】
これにより、サバイバルサーバ１２においても呼制御情報を保持することができ、メインサーバ１０に障害が生じ、サバイバルサーバ１２に切り替わった場合でも、呼を切断せずにメインサーバ１０と同等のサービスを継続して提供することができる。
【００７０】
その後、ＩＰ電話端末１１−１からの切断信号がメインサーバ１０に与えられると（Ｓ１０６）、メインサーバ１０は、ＩＰ電話端末１１−２に対して切断を示すメッセージを中継し、ＩＰ電話端末１１−１とＩＰ電話端末１１−２との間の呼について切断処理が行なわれる（Ｓ１０７）。
【００７１】
メインサーバ１０において、切断処理が終了すると、メインサーバ１０は、ＩＰ電話端末１１−１及び１１−２間の呼が切断したことを示す切断情報をサバイバルサーバ１２に与える（Ｓ１０８）。
【００７２】
このとき、メインサーバ１０において保持されているＩＰ電話端末１１−１とＩＰ電話端末１１−２とに関する呼制御情報は破棄され（Ｓ１０９）、またサバイバルサーバ１２において保持されているＩＰ電話端末１１−１とＩＰ電話端末１１−２とに関する呼制御情報は破棄される（Ｓ１１０）。
【００７３】
このようにして、メインサーバ１０とサバイバルサーバ１２との間で同じ呼制御情報を保持することができる。
【００７４】
続いて、メインサーバ１０自体又はメインサーバ１０までの間の伝送経路におけるＩＰ網ＮＴ回線上に障害が生じた場合のサバイバルサーバ１２への切り替え処理について図５を参照して説明する。図５は、サバイバルサーバ１２への切り替え処理を示すシーケンスである。
【００７５】
図５において、ＩＰ電話端末１１−１〜１１−Ｎでは、メインサーバ１０との間の伝送経路についてヘルスチェックを行なう（Ｓ２０１）。
【００７６】
例えば、図５における本実施形態では、メインサーバ１０が、所定周期でＩＰ電話端末１１−１〜１１−Ｎに対してヘルスチェック要求信号を送信し、ＩＰ電話端末１１−１〜１１−Ｎが、メインサーバ１０からのヘルスチェック要求信号を受信すると、これに対してヘルスチェック応答信号を返信する。そして、ＩＰ電話端末１１−１〜１１−Ｎにおいては、ヘルスチェックタイミング期間の期間内に、メインサーバ１０から所定周期毎に送信されるヘルスチェック要求信号が与えられない場合、メインサーバ１０との間の伝送経路が正常でないと判断する。
【００７７】
図５においては、Ｓ２０３において、メインサーバ１０自体又はメインサーバ１０までの間の伝送経路に障害が発生したものとする。そうすると、ＩＰ電話端末１１−１〜１１−Ｎは、直前にメインサーバ１０に返信したヘルスチェック応答信号の送信した時点から所定時間（例えば、２分間）のヘルスチェックタイミング期間が経過しても、メインサーバ１０から次のヘルスチェック要求信号が与えられない場合、メインサーバ１０との間の伝送経路において異常が生じたと判定する（Ｓ２０４）。
【００７８】
ＩＰ電話端末１１−１〜１１−Ｎにおいて、ヘルスチェックタイミング期間の期間メインサーバ１０からヘルスチェック要求信号の受信がなく、メインサーバ１０までの間の伝送経路において異常が生じたと判定すると、ＩＰ電話端末１１−１〜１１−Ｎでは、ヘルスチェックタイミング期間に続けて、メインサーバ１０からのみの再開要求メッセージの受信を待つ再接続待ちタイミング期間（例えば、ヘルスチェックタイミング期間経過後３分）を計時する（Ｓ２０５）。
【００７９】
そして、メインサーバ１０からの再開要求メッセージの受信がなく、再接続待ちタイミング期間が経過すると、ＩＰ電話端末１１−１〜１１−Ｎでは、再接続待ちタイミング期間に続けて、サバイバル再開受付タイミング期間（例えば、再接続待ちタイミング期間経過後５分）を計時する（Ｓ２０６）。この期間においては、メインサーバ１０とサバイバルサーバ１２のどちらかからでも再開要求メッセージを受け取る状態である。
【００８０】
一方、サバイバルサーバ１２も、メインサーバ１０との間の伝送経路についてヘルスチェックを行なっている（Ｓ２０２）。
【００８１】
例えば、図５に示す本実施形態では、サバイバルサーバ１２が、所定周期毎（例えば６０秒毎）にヘルスチェック要求信号をメインサーバ１０に対して送信し、メインサーバ１０からヘルスチェック応答信号を受け取ると、サバイバルサーバ１２はメインサーバ１０との間の伝送経路は正常であると判定する。そして、ヘルスチェック要求信号を送信したにも拘わらず、ヘルスチェック応答信号の受信が所定回数（例えば、６回）連続してない場合（すなわち、この間を時間で示すとヘルスチェック応答信号の直前の受信時点からおよそ６分経過後である）、サバイバルサーバ１２は異常が生じたと判定する。
【００８２】
Ｓ２０３において、メインサーバ１０自体又はメインサーバ１０との間の伝送経路上に障害が生じ、サバイバルサーバ１２におけるヘルスチェックによりメインサーバ１０までの伝送経路上に異常が生じたと検出されると、サバイバルサーバ１２は呼救済の再開のためのサバイバルサーバ１２への切り替え処理を行なう（Ｓ２０８）。
【００８３】
このサバイバルサーバ１２への切り替え処理については、ＩＰ電話端末１１−１〜１１−Ｎにおけるサバイバル再開受付タイミング期間に行なわれることが望ましい。従って、サバイバルサーバ１２においてヘルスチェックタイムアウトとする回数や期間等は、ＩＰ電話端末１１−１〜１１−Ｎにおけるヘルスチェックタイミング期間、再接続待ちタイミング期間及びサバイバル再開受付タイミング期間、との関係において設定することができる。逆に、ＩＰ電話端末１１−１〜１１−Ｎにおけるヘルスチェックタイミング期間、再接続町タイミング期間及びサバイバル再開受付タイミング期間をどれだけの長さにするかを、サバイバルサーバ１２においてヘルスチェックタイムアウトの期間等、との関係において設定することができる。
【００８４】
Ｓ２０８では、サバイバルサーバ１２は、ＩＰ電話端末１１−１〜１１−Ｎに対して、所定の呼制御プログラムのリセットをかけない呼救済再開を行なう。また、サバイバルサーバ１２は、接続先サーバ情報をサバイバルサーバ１２とする再開要求メッセージを作成し、その再開要求メッセージをＩＰ電話端末１１に送信する（Ｓ２０９）。
【００８５】
ＩＰ電話端末１１においては、サバイバル再開受付タイミング期間内に、サバイバルサーバ１２から再開要求メッセージを受信すると、接続先サーバ情報がサバイバルサーバ１２となっているから、接続先サーバをサバイバルサーバ１２とした接続要求を送信する（Ｓ２１０）。
【００８６】
このようにして、ＩＰ電話端末１１は、端末内の呼制御プログラムにリセットをかけずに、呼処理の接続先サーバをメインサーバ１０からサバイバルサーバ１２に切り替えることができる。
【００８７】
このとき、サバイバルサーバ１２においては、管理範囲内のＩＰ電話端末１１−１〜１１−Ｎについての呼制御情報を保持しているから、その管理範囲内のＩＰ電話端末１１−１〜１１−Ｎから接続要求を受けた場合にも、そのまま継続して管理することができる。
【００８８】
そのため、ＩＰ電話端末１１−１〜１１−Ｎにおける呼接続ソフトウェアを再起動させることなく、通話中呼に影響を及ぼさない。
【００８９】
続いて、メインサーバ１０の復旧後、接続先をサバイバルサーバ１０からメインサーバ１２に切り戻す処理を図面を参照しながら説明する。図６は、メインサーバ１０への切り戻し処理を示すシーケンスである。
【００９０】
図６において、サバイバルサーバ１２では、メインサーバ１０との間の伝送経路に異常と判定した後も、メインサーバ１０との間の伝送経路についてヘルスチェックをしている。
【００９１】
サバイバルサーバ１２におけるヘルスチェックにより、メインサーバ１０の復旧が検出されると（Ｓ３０１）、手動又は自動で切り戻し処理が行なわれる（Ｓ３０２）。
【００９２】
このとき、サバイバルサーバ１２は、ＩＰ電話端末１１−１〜１１−Ｎへリセットをかける非救済再開を行なう。また、サバイバルサーバ１２は、接続先サーバ情報をメインサーバ１０とした再開要求メッセージをＩＰ電話端末１１−１〜１１−Ｎに送信する（Ｓ３０３）。
【００９３】
このように、メインサーバ１０の復旧後、サバイバルサーバ１２が、ＩＰ電話端末１１−１〜１１−Ｎに対してリセットをかけることとしたのは、メインサーバ１０が障害発生から復旧するまでの間の呼制御情報を保持していないので、本実施形態では、一度、ＩＰ電話端末１１−１〜１１−Ｎにおいて端末内ソフトウェアをリセットすることとした。
【００９４】
サバイバルサーバ１２から再開要求メッセージを受けると、ＩＰ電話端末１１−１〜１１−Ｎにおいては、接続先をメインサーバ１０とした接続要求をメインサーバ１０に送信する（Ｓ３０４）。
【００９５】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、メインサーバ１０が、確立した呼に係るＩＰ電話端末を管理するサバイバルサーバ１２に対して、当該呼に関する呼制御情報を送信することで、サバイバルサーバ１２もメインサーバ１０と同じ呼制御情報を管理することができる。
【００９６】
また、本実施形態によれば、サバイバルサーバ１２が、メインサーバ１０自体又はメインサーバ１０までの伝送経路における回線上に障害が生じたと判定した場合、接続先をサバイバルサーバとするリセットをかけない再開要求メッセージを管理範囲のＩＰ電話端末に送信することで、通話中呼を切断することなく、サバイバルサーバ１２への切り替え処理を行なうことができる。
【００９７】
（Ｂ）他の実施形態
（Ｂ−１）上述した第１の実施形態では、メインサーバ自体及び又はメインサーバまでの伝送経路における回線上に障害が生じたとき、サバイバルサーバが、リセットをかけず、接続先をサバイバルサーバとする再開要求メッセージを、ＩＰ電話端末に送信することとした。そして、この再開要求メッセージを受信したＩＰ電話端末は、起動中の端末内の呼制御プログラムをリセットせずに、接続先を変更することとした。
【００９８】
しかし、ＩＰ電話端末内で、呼制御プログラムにリセットをかけずに、サーバの接続先を変更することができれば、他の方法も広く適用することができる。
【００９９】
例えば、ＩＰ電話端末内に、障害発生時に接続するサバイバルサーバのアドレスを予め登録しておき、障害を検出した場合に、端末内の呼制御プログラムをリセットせず、接続先だけを変更するようにしてもよい。
【０１００】
（Ｂ−２）図６のＳ３０３では、サバイバルサーバ１２がリセットをかける再会要求メッセージを送信することとしたが、再開要求メッセージを送信する前に、サバイバルサーバ１２が保持している呼制御情報を、メインサーバ１０に送信し、その後、サバイバルサーバ１２が、リセットをかけず、接続先をメインサーバ１０とする再開要求メッセージを、ＩＰ電話端末１１−１〜１１−Ｎに送信するようにしてもよい。
【０１０１】
これにより、復旧後に、メインサーバ１０に切り戻す際にも、ＩＰ電話端末１１−１〜１１−Ｎの通話中呼を切断することなく行なうことが期待できる。
【０１０２】
（Ｂ−３）ヘルスチェック機能は、上述した第１の実施形態で説明した方法に限定されず、他の方法を広く適用することができる。例えば、メインサーバ１０の一部に障害が発生していることを検出する機能（自己管理機能）をメインサーバ１０が備え、自己管理機能がメインサーバ１０の障害発生を検出している場合には、その旨を記述した信号をサバイバルサーバ１２及び又はＩＰ電話端末に送信する方法も適用できる。
【０１０３】
（Ｂ−４）上述した第１の実施形態において説明したメインサーバ１０とサバイバルサーバとが実現する機能は、物理的に同一のサーバが実現するようにしてもよいし、また、同様の機能を奏することができるように、それぞれの機能を実現する装置（サーバ）が拠点内又はネットワーク内に分散配置されるようにしてもよい。
【図面の簡単な説明】
【０１０４】
【図１】第１の実施形態の音声通信システムの全体構成を示す図である。
【図２】第１の実施形態のサーバ（メインサーバ又はサバイバルサーバ）の内部構成を示す機能ブロック図である。
【図３】第１の実施形態のＩＰ電話端末の内部構成を示す機能ブロック図である。
【図４】第１の実施形態のメインサーバとサバイバルサーバとの間で同じ呼制御情報を保持する処理を示すシーケンスである。
【図５】第１の実施形態のサバイバルサーバへの切り替え処理を示すシーケンスである。
【図６】第１の実施形態のメインサーバへの切り戻し処理を示すシーケンスである。
【符号の説明】
【０１０５】
１…音声通信ネットワーク、１０…メインサーバ、１１−１〜１１−Ｎ…ＩＰ電話端末、１２…サバイバルサーバ、２０…端末収容機能部、２１…装置管理機能部、２２…呼処理機能部、２３…データベース部、３０…通信部、３１…制御部、３２…操作部、３３…記憶部、３４…ヘルスチェック部、３５…接続サーバ切替部、３６…呼制御部、３７…表示部。
【技術分野】
【０００１】
本発明は、呼制御システム、呼制御方法及びサーバに関し、例えば、ＩＰ（インタネットプロトコル）網を利用して音声通信を実現する音声通信システムに適用し得る。
【背景技術】
【０００２】
例えば、ＩＰ網を利用して音声通信を実現する音声通信システムにおいては、企業等のセンタ拠点にＩＰ−ＰＢＸ機能を有するサーバ（メインサーバ）を設置して、拠点内又は拠点間の電話サービスを提供するＩＰセントレックスシステムがある。
【０００３】
このＩＰセントレックスシステムによる企業内音声通信ネットワークでは、メインサーバが、ＩＰ網を経由して、ＩＰ電話端末（例えば、ソフトフォン、ハードフォン等）から発呼要求を受けると、メインサーバは、要求先の他のＩＰ電話端末との間で呼接続を制御し、要求元のＩＰ電話端末と要求先のＩＰ電話端末との間の呼を確立している（特許文献１参照）。
【０００４】
ところで、このようなＩＰセントレックスシステムによる企業内音声通信ネットワークにおいて、センタ拠点に設置されたメインサーバに障害が発生したり、ＩＰ網の障害でセンタ拠点との通信が行なえなくなった場合などには、各拠点内のすべてのＩＰ電話端末の利用ができなくなり、音声通信サービスが停止してしまう。
【０００５】
このため、従来は、各拠点にメインサーバの代替手段となるサーバ（サバイバルサーバ）を設置し、メインサーバに障害が発生したり、ＩＰ網の障害でセンタ拠点との通信が行なえなくなった場合、ＩＰ電話端末に関する管理をメインサーバからサバイバルサーバに切り替え、拠点内の音声通信を継続するようにしている。
【０００６】
従来、この場合のサバイバルサーバヘの切り替え方法として、例えば、ＩＰ電話端末にメインサーバと各拠点のサバイバルサーバとのネットワーク情報（例えば、ＩＰアドレス等）を設定しておき、ＩＰ電話端末がメインサーバとの間の通信障害を検出すると、ＩＰ電話端末側で端末ソフトウェアの再起動を行ない、接続先をサバイバルサーバに変更し、サバイバルサーバ側では端末の障害復旧という形でＩＰ電話端末を組み込む、という方法がある（特願２００４−３５２９８４号明細書参照）。
【０００７】
【特許文献１】特開２００１−８６１６６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述したように、従来のＩＰセントレックスによる企業内音声通信ネットワークにおいては、ＩＰ電話端末がＩＰ電話端末とメインサーバとの間の通信障害発生を検出すると、ＩＰ電話端末は、接続先サーバを変更するために、端末内の呼制御プログラムにリセットをかけて、新たな接続先とした呼制御プログラムを再起動させることとしているため、その再起動に伴う通話中呼の切断が発生してしまうという問題がある。
【０００９】
また、ＩＰセントレックスによる企業内音声通信ネットワークは、各拠点間の距離が離れているのでメインサーバと各サバイバルサーバとの間も距離が離れて設けられており呼制御情報を単に共有することは困難であり、またリアルタイム性も要求される。
【００１０】
そのため、主呼処理手段及び又は主呼処理手段までの伝送経路上に障害が発生したときに、通話中の呼に影響与えずに通話を維持することができる呼制御システム、呼制御方法及びサーバが求められている。
【課題を解決するための手段】
【００１１】
かかる課題を解決するため、第１の本発明の呼制御システムは、（１）複数の通信端末を含む拠点を複数有するネットワークにおいて、通信端末間の呼処理を行なう主呼処理手段と、（２）障害検出部により主呼処理手段及び又は呼処理手段までの伝送経路上に障害が検出されたとき、各拠点内に位置する通信端末の呼を主呼処理手段に代わって呼処理を行なう副呼処理手段と、（３）主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを備え、副呼処理手段が、（２−１）呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持部と、（２−２）主呼処理手段に障害が検出されたときに、呼制御情報保持部に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済部とを有することを特徴とする。
【００１２】
第２の本発明のサーバは、複数の通信端末を含む拠点を複数有するネットワークで、通信端末間の呼処理を行なう主呼処理手段を有するサーバと、主呼処理手段及び又は呼処理手段までの伝送経路上に障害が発生したときに、主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの主呼制御手段を有するサーバにおいて、（１）主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段を備えることを特徴とする。
【００１３】
第３の本発明のサーバは、複数の通信端末を含む拠点を複数有するネットワークで、通信端末間の呼処理を行なう主呼処理手段と、主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを有するサーバと、主呼処理手段及び又は呼処理手段までの伝送経路上に障害が発生したときに、主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの副呼制御手段を有するサーバにおいて、（１）呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持手段と、（２）主呼処理手段に障害が検出されたときに、呼制御情報保持手段に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済手段とを有することを特徴とする。
【００１４】
第４の本発明の呼制御方法は、（１）主呼処理手段が、複数の通信端末を含む拠点を複数有するネットワークにおいて、通信端末間の呼処理を行なう主呼処理工程と、（２）副呼処理手段が、障害検出部により主呼処理手段及び又は呼処理手段までの伝送経路上に障害が検出されたとき、各拠点内に位置する通信端末の呼を主呼処理手段に代わって管理する副呼処理工程と、（３）呼制御情報転送手段が、主呼処理手段による通信端末間の呼確立後、当該通信端末が位置する拠点の副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送工程とを備え、副呼処理手段が、（２−１）呼制御情報転送手段から受け取った呼制御情報を保持する呼制御情報保持工程と、（２−２）主呼処理手段に障害が検出されたときに、呼制御情報保持手段に保持されている呼制御情報を用いて、通信端末の呼を救済する呼救済工程とを有することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、主呼処理手段及び又は主呼処理手段までの伝送経路上に障害が発生したときに、通話中の呼に影響与えずに通話を維持することができる。
【発明を実施するための最良の形態】
【００１６】
（Ａ）第１の実施形態
以下、本発明の呼制御システム、呼制御方法及びサーバの第１の実施形態を、図面を参照しながら詳細に説明する。
【００１７】
本実施形態は、本発明の呼制御システム、呼制御方法及びサーバを利用して、ＩＰセントレックスによる企業内音声通信ネットワークを実現する形態を説明する。
【００１８】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係る音声通信ネットワークの全体構成を示す図である。図１において、本実施形態の音声通信ネットワーク１は、ＩＰ網ＮＴと、ＩＰ網ＮＴに接続するＩＰセントレックスセンタ拠点ＳＴ１と、拠点ＳＴ２とを有して構成される。
【００１９】
ここで、ＩＰ網ＮＴは、ＯＳＩ参照モデルのネットワーク層の通信プロトコルとしてＩＰプロトコルが用いられる通信網であり、本実施形態では、例えば、通信事業者が運営するＩＰ網を想定するが、例えば、インターネットなどに代表される公衆のＩＰ網としてもよい。
【００２０】
ＩＰセントレックスセンタ拠点ＳＴ１（以下、単に拠点ＳＴ１と呼ぶ）は、例えば企業の本社等に構築されているネットワーク（例えば、ＬＡＮ等）が該当し、また拠点ＳＴは、例えばその企業の支社等で構築されるネットワーク（例えば、ＬＡＮ等）が該当する。なお、図１では、拠点として拠点ＳＴ１及びＳＴ２の２拠点のみを示しているが、拠点ＳＴ２と同様の機能をもつ拠点を複数備えるようにしてもよい。例えば、企業内音声通信ネットワークの規模については様々であるが、大規模なものであれば、メインサーバ１０が管理可能なＩＰ電話端末数として例えば５０００台程度のものがある。
【００２１】
拠点ＳＴ１には、図１に示すように、メインサーバ１０が設置されている。なお、図１では、図示していないが、拠点ＳＴ１は、メインサーバ１０以外のネットワーク装置（例えば、ルータやスイッチ等）やＩＰ電話端末等を備えていてもよい。
【００２２】
拠点ＳＴ２は、図１に示すように、サバイバルサーバ１２と、複数のＩＰ電話端末１１−１〜１１−Ｎ（図１ではＮ（Ｎは正の整数））とを有して構成されている。なお、拠点ＳＴ２においても、これら以外のネットワーク装置（例えば、ルータやスイッチ等）を備えていてもよい。また、サバイバルサーバ１２の設置台数は、特に限定されるものではなく、複数台であってもよい。
【００２３】
メインサーバ１０は、拠点ＳＴ１内に設置されているものであって、図１に示す音声通信ネットワーク１の全体を管理範囲として、呼制御機能や端末制御機能等を備えるサーバであり、例えば、ＩＰ−ＰＢＸ（あるいは、コールエージェント）等としての機能を有するものである。
【００２４】
ここで、音声通信ネットワーク１内で用いられる呼制御プロトコルは、特に限定されるものではなく種々のプロトコルを適用することができるが、例えばＩＴＵ−Ｔ勧告Ｈ．３２３やＳＩＰ（セッション・イニシエーション・プロトコル）などを適用できる。そして、例えばＩＴＵ−Ｔ勧告Ｈ．３２３を適用する場合には、メインサーバ１０のＩＰ−ＰＢＸにはゲートキーパの機能を搭載する必要があり、例えばＳＩＰを適用する場合には、メインサーバ１０はロケーションサーバなども含むＳＩＰサーバの機能を搭載する必要がある。
【００２５】
また、メインサーバ１０は、呼制御機能として、拠点ＳＴ２内の任意のＩＰ電話端末（例えば、１４）が他のＩＰ電話端末に対して発呼しようとする場合、アドレス解決（電話番号に対応するＩＰアドレスの取得）などのためにＩＰ−ＰＢＸの機能を用いる。また、具体的な呼制御の手順にも依存するが、通常、ＩＰ電話端末が送信する呼制御メッセージの多くは、ＩＰ−ＰＢＸであるメインサーバ１０を経由し、その着信先とするＩＰ電話端末に対して、呼制御メッセージを中継することで、ＩＰ電話端末間の呼を確立する。
【００２６】
また、呼の確立後でも、ＩＰ−ＰＢＸであるメインサーバ１０は、音声通信ネットワーク１内の各ＩＰ電話端末の状態（例えば、通話中か否か等の状態）を示す呼制御情報を管理する。メインサーバ１０は、呼確立した各ＩＰ電話端末の呼制御情報を、サバイバルサーバ１２に転送するものである。これにより、メインサーバ１０が、管理しているＩＰ電話端末の呼制御情報をサバイバルサーバ１２においても管理させることができる。さらに、メインサーバ１０は、ＩＰ電話端末から切断信号を受け取ると、そのＩＰ電話端末間の呼の切断を行なうと共に、サバイバルサーバ１２に対して当該ＩＰ電話端末間の呼の終了を知らせる切断情報を転送する。
【００２７】
さらに、メインサーバ１０は、端末制御機能として、ＩＰ電話端末における、転送、ボタンの割り付け、ＶＬＡＮ、優先制御などに関連する動作を制御するものである。例えば、ＩＰ電話端末１１−１〜１１−Ｎが多機能電話機に相当するものである場合、着信転送など転送の際に必要な情報、ボタンの割付けに関する情報、ＶＬＡＮ、ＴｏＳ（タイプ・オブ・サービス）などに関する情報を、メインサーバ１０はＩＰ電話端末１４に送信して記憶させるものである。ここで、ＶＬＡＮに関する情報は音声通信ネットワーク１内でＶＬＡＮを用いる場合に必要であり、ＴｏＳに関する情報は、音声通信ネットワーク１内の図示しない中継装置（例えば、ルータ）で優先制御を行なう場合、この優先制御のために、ＩＰ電話端末が送信するＩＰパケットについて、そのヘッダのＴｏＳフィールドに記述させる情報である。
【００２８】
サバイバルサーバ１２は、拠点ＳＴ２内に設置されているものであって、拠点２の内部を管理範囲として、呼制御機能や端末制御機能等を備えるサーバであり、基本的にはメインサーバ１０と同様の機能を有するものである。サバイバルサーバ１２は、メインサーバ１０やメインサーバ１０までの伝送経路に障害が発生した場合に、メインサーバ１０に代わってＩＰ電話端末間の呼処理を行なうサーバとして機能する。そして、障害が解消されてメインサーバ１０が回復すると、再度、メインサーバ１０が主導的にＩＰ電話端末の呼処理を行なうように切り戻しされ、サバイバルサーバ１２はその後の障害発生に備えるものである。
【００２９】
サバイバルサーバ１２は、その詳細は後述するが、所定の周期で、メインサーバ１０との間の伝送経路が正常であるか否かを検査するヘルスチェックを行ない、メインサーバ１０及び又はメインサーバ１０までの伝送経路におけるＩＰ網ＮＴ回線上に障害が発生したか否かを判断するものである。そして、メインサーバ１０及び又はメインサーバ１０までの間の伝送経路におけるＩＰ網ＮＴ回線に障害が発生したと判定した場合、サバイバルサーバ１２は、それまでメインサーバ1１０が行なっていた呼処理を、メインサーバ１０に代わって行なうようにする切り替え処理を行なうものである。
【００３０】
ＩＰ電話端末１１−１〜１１−Ｎは、ＶｏＩＰ対応機能を有するものであり、例えば、ハードフォン（携帯ＩＰ電話端末を含む概念）や、ソフトフォンや、アダプタを用いてＶｏＩＰ対応機能を持たない一般電話機をＩＰ網ＮＴに接続可能とした電話端末等が該当する。
【００３１】
また、ＩＰ電話端末１１−１〜１１−Ｎは、自身でメインサーバ１０及びＩＰ電話端末１１−１〜１１−Ｎからメインサーバ１０に至る伝送経路が正常であると判定する機能を備えている。
【００３２】
（Ａ−１−１）メインサーバ１０及びサバイバルサーバ１２の内部機能構成
図２は、メインサーバ１０及びサバイバルサーバ１２の内部構成を示す機能ブロック図である。
【００３３】
上述したように、メインサーバ１０とサバイバルサーバ１２の基本的な機能は同じであるので、メインサーバ１０とサバイバルサーバ１２とに共通する機能を説明すると共に、それぞれの特有の機能についても説明する。
【００３４】
図２において、本実施形態のメインサーバ１０及びサバイバルサーバ１２は、端末収容機能部２０と、装置管理機能部２１と、呼処理機能部２２と、データベース部２３とを備えている。
【００３５】
呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎ間でやり取りされる呼制御メッセージの中継などを行ない、ＩＰ電話端末１１−１〜１１−Ｎ間の呼を確立する機能部である。
【００３６】
メインサーバ１０における呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎ間の呼接続の進行状況などを示す情報を収集するものである。また、メインサーバ１０における呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎ間の呼が確立すると、呼が確立したＩＰ電話端末１１−１〜１１−Ｎに関する呼制御情報を、当該ＩＰ電話端末１１−１〜１１−Ｎを管理しているサバイバルサーバ１２に送信させるものである。これにより、メインサーバ１０が管理している呼制御情報をサバイバルサーバ１２にも管理させることができる。また、メインサーバ１０は、ＩＰ電話端末から切断信号を受信すると、当該ＩＰ電話端末の呼の切断処理を行なうと共に、当該ＩＰ電話端末についての切断情報を、サバイバルサーバ１２に送信させるものである。
【００３７】
サバイバルサーバ１２における呼処理機能部２２は、メインサーバ１０から呼制御情報を受信すると、その受信した呼制御情報をデータベース部２３に保持させるものである。これにより、メインサーバ１０が管理する呼制御情報と同じ呼制御情報をサバイバルサーバ１２においても管理することができる。また、サバイバルサーバ１２における呼処理機能部２２は、メインサーバ１０から切断情報を受信すると、対応するＩＰ電話端末について呼の切断処理を行なうものである
また、サバイバルサーバ１２において、後述する装置管理機能部２１がメインサーバ１０及び又はメインサーバ１０までの間の伝送経路におけるＩＰ網ＮＴの回線上の障害発生を検出すると、呼処理機能部２２は、管理している呼制御情報に基づいて、呼を確立しているＩＰ電話端末に対してリセットをかけない呼救済再開処理を行なうものである。すなわち、呼処理機能部２２は、接続先サーバ情報としてサバイバルサーバ１２を指定した再開要求メッセージを、すべてのＩＰ電話端末１１−１〜１１−Ｎに対して送信する。これにより、ＩＰ電話端末１１−１〜１１−Ｎが呼処理サーバとしてアクセスする接続先サーバを、メインサーバ１０からサバイバルサーバ１２に変更させることができ、その接続先サーバの変更のみで呼救済させることができる。つまり、呼確立中のＩＰ電話端末については、呼処理に関するプログラムを再起動しなくても、接続先サーバを変えるだけで呼救済することができる。
【００３８】
また、サバイバルサーバ１２において、障害が解消してメインサーバ１０が回復すると、呼処理機能部２２は、ＩＰ電話端末１１−１〜１１−Ｎへリセットをかける非救済再開処理を行なうものである。すなわち、呼処理機能部２２は、接続先サーバ情報としてメインサーバ１０を指定した再開要求メッセージを、すべてのＩＰ電話端末１１−１〜１１−Ｎに対して送信する。
【００３９】
データベース部２３は、管理範囲内の各ＩＰ電話端末１１−１〜１１−Ｎに関する情報を蓄積するものである。データベース部２３は、例えば、各ＩＰ電話端末１１−１〜１１−Ｎに割り当てられているＩＰアドレスと電話番号の対応関係などの情報や、呼処理機能部２２により収集されたＩＰ電話端末１１−１〜１１−Ｎの状態を示す情報なども蓄積するものである。
【００４０】
メインサーバ１０におけるデータベース部２３は、その管理範囲が音声通信ネットワーク１全体であるから、拠点ＳＴ１だけでなく、拠点ＳＴ２のＩＰ電話端末に関するこれらの情報も蓄積する。
【００４１】
サバイバルサーバ１２におけるデータベース部２３は、その管理範囲が拠点ＳＴ２内に限られるため、拠点ＳＴ２内に設置されたＩＰ電話端末１１−１〜１１−Ｎに関するこれらの情報のみを蓄積する。また、サバイバルサーバ１２において、データベース部２３は、メインサーバ１０から送信された呼制御情報を管理するものである。
【００４２】
装置管理機能部２１は、対象とする装置を管理する機能部である。メインサーバ１０における装置管理機能部２１は、呼を確立したＩＰ電話端末１１−１〜１１−Ｎの管理機能や、サバイバルサーバ１２からのヘルスチェックに対する応答機能を有する。このサバイバルサーバ１２からのヘルスチェックに対する応答処理とは、サバイバルサーバ１２からヘルスチェック要求信号を受信すると、それに応答するヘルスチェック応答信号をサバイバルサーバ１２に返信するものである。
【００４３】
サバイバルサーバ１２における装置管理機能部２１は、メインサーバ１０との間の伝送経路が正常であるか否かを管理するヘルスチェック機能を有する。
【００４４】
ここで、本実施形態のサバイバルサーバ１２における装置管理機能部２１のヘルスチェックは、所定の周期で、ヘルスチェック要求信号をメインサーバ１０に送信し、所定の返信期間内に、メインサーバ１０からヘルスチェック応答信号の返信があると、メインサーバ１０との間の伝送経路は正常であることとする。
【００４５】
なお、本実施形態では、サバイバルサーバ１２の装置管理機能部２１が、６０秒毎にヘルスチェック要求信号をメインサーバ１０に送信し、６回連続してタイムアウトした場合、メインサーバ１０及び又はＩＰ網ＮＴ回線に障害が生じたと判断するものとする。
【００４６】
端末収容機能部２０は、管理範囲内の任意のＩＰ電話端末から呼制御メッセージの受付けなどを行なうためのポートを有する機能部である。メインサーバ１０においては、端末収容機能部２０は、常時、ポートの受付けを許可する状態である。サバイバルサーバ１２においては、端末収容機能部２０は、装置管理機能部２１によるヘルスチェックの結果が、受付けを許可するのは、メインサーバ１０及び又は伝送経路の少なくともいずれかが正常でないと判定した場合であり、拒否するのは、前記メインサーバ１０及び伝送経路の双方が正常であると判定した場合である。
【００４７】
（Ａ−１−２）ＩＰ電話端末の内部機能構成
図３は、ＩＰ電話端末１１−１〜１１−Ｎは、通信部３０と、制御部３１と、操作部３２と、記憶部３３と、ヘルスチェック部３４と、接続サーバ切替部３５と、呼制御部３６と、表示部３７とを備えている。
【００４８】
制御部３１は、ＩＰ電話端末１１−１〜１１−Ｎの機能を司るものであり、ハードウェア的にはＩＰ電話端末１１−１〜１１−ＮのＣＰＵ（中央処理装置）が該当し、ソフトウェア的にはＯＳ（オペレーティングシステム）などの制御プログラムが該当する。
【００４９】
記憶部３３は、揮発性又は不揮発性の記憶資源である。記憶部３３には、ＩＰ電話端末１１−１〜１１−Ｎの機能を実現させる処理プログラムを格納するものである。そして、制御部３１が、記憶部３３に格納されている処理プログラムを読み出して実行することにより、ＩＰ電話端末１１−１〜１１−Ｎとしての機能を実現することができる。
【００５０】
呼制御部３６は、制御部３１の制御下で、他のＩＰ電話端末１１−１〜１１−Ｎと通話をするために、メインサーバ１０との間で呼制御メッセージの生成や授受などを実行するものである。呼制御部３６は、呼制御を実行するための所定の呼制御ソフトウェア（プロセス）を記憶部３３に保持しており、通常時に呼接続するための接続先サーバをメインサーバ１０としている。
【００５１】
ヘルスチェック部３４は、アクセスするサーバ（例えば、メインサーバ１０、サバイバルサーバ１２）及び当該サーバまでの伝送経路の正常性を検査する部分である。ヘルスチェック部３４は、呼が確立すると、メインサーバ１０から周期的に受信したヘルスチェック要求信号に対してヘルスチェック応答信号を返信する。
【００５２】
ヘルスチェック部３４は、メインサーバ１０からの周期的なヘルスチェック要求信号の受信がなされないことを検出すると、直前のヘルスチェック応答信号の返信時刻から所定時間（例えば、２分）連続して届かなかった場合、正常でないことを判定する。この所定時間の間のヘルスチェック期間をヘルスチェックタイミング期間という。
【００５３】
ここで、ヘルスチェック部３４による検査方式は、特に限定されるものではなく広く適用することができる。上述したヘルスチェック方法のほかに、例えば、常時メインサーバ１０とＩＰ電話端末１１−１〜１１−Ｎとの間でＴＣＰコネクションを確立することで伝送経路の正常性を判断する方法を適用する場合、このＴＣＰコネクションが切断されたことを、ヘルスチェック部３４が検出することで、メインサーバ１０との間の伝送経路までが正常でないと判定するようにしてもよい。また、別な方法として、ＩＰ電話端末１１−１〜１１−Ｎが例えば呼制御メッセージの中継を依頼する際などにメインサーバ１０にアクセスしたとき、正常な応答がなければ、正常でないと判定するようにしてもよい。
【００５４】
ヘルスチェック要求信号やヘルスチェック応答信号の送受に際し、ＯＳＩ参照モデルのトランスポート層では、ＴＣＰ等のコネクション型の通信プロトコルを用いてもよいが、ここでは、ＵＤＰ等のコネクションレス型の通信プロトコルを用いるものとする。
【００５５】
通信部３０は、ＩＰ電話端末１１−１〜１１−Ｎが拠点ＳＴ２内のネットワークやＩＰ網ＮＴを経由して通信を行なうものである。すなわち、通信部３０は、制御や管理のために行なわれるメインサーバ１０又はサバイバルサーバ１２との通信と、通話相手のＩＰ電話端末との間で行なわれるリアルタイムな音声通信を行なうものである。
【００５６】
また、通信部３０は、制御部３１の制御下で、ヘルスチェックタイミング期間経過後から所定時間の間（本実施形態では、例えば３分とし、この期間を再接続待ちタイミング期間という）までは、前回接続していたサーバのみからの再開要求メッセージを受信するようにする。このように、再開要求メッセージを受け取る先を前回接続していたサーバ（例えばメインサーバ１０）のみとすることにより、直ぐに復旧できる軽度の障害が一時的に発生した場合には、メインサーバ１０が送信した再開要求メッセージを優先的に受信することができる。
【００５７】
さらに、通信部３０は、制御部３１の制御下で、再接続待ちタイミング期間経過後から所定時間（本実施形態では、例えば５分とし、この期間をサバイバル再開受付タイミング期間という）までは、メインサーバ１０だけでなくサバイバルサーバ１２からの再開要求メッセージを受信するようにする。これにより、再接続待ち来ミング経過後に、サバイバルサーバ１２が送信した再開要求メッセージをも受信することができる。
【００５８】
接続サーバ切替部３５は、制御部３１の制御下で、当該ＩＰ電話端末１１−１〜１１−Ｎが呼制御やアドレス解決のために、呼制御部３６がアクセスする接続先のサーバ１０又は１２を切り替え制御するものであり、通常の場合、呼制御部３６の接続先をメインサーバ１０としている。
【００５９】
また、接続サーバ切替部３５は、制御部３１の制御下で、受信した再開要求メッセージに含まれている接続先サーバ情報に従って、呼制御のためにアクセスする接続先サーバを変更し、接続するサーバを切り替えるものとする。これにより、障害発生時に、接続先サーバをサバイバルサーバ１２と指定されている再開要求メッセージを受信すると、呼制御部３６は、呼制御に係るサーバの接続先をメインサーバ１０からサバイバルサーバ１２に変更することができる。これにより、呼制御ソフトウェアを再起動することなく、呼救済がされる。
【００６０】
操作部３２は、ＩＰ電話端末１１−１〜１１−ＮのユーザＵ１が操作するユーザインタフェースである。操作部３２は、少なくとも通話相手の電話番号等を指定するための入力ボタン等が該当し、また多機能電話として機能する場合、それら機能を実行させるために必要なボタンが該当する。
【００６１】
表示部３７は、制御部３１からユーザＵ１に情報を伝えるための部分である。具体的には、例えば、液晶表示装置や、発光ＬＥＤ素子等によって当該表示部３７を構成することができる。
【００６２】
（Ａ−２）第１の実施形態の動作
次に、本実施形態の音声通信ネットワーク１における呼制御処理の動作を図面を参照しながら説明する。
【００６３】
図４は、メインサーバ１０とサバイバルサーバ１２との間で同じ呼制御情報を保持する処理を示すシーケンスである。
【００６４】
図４では、メインサーバ１０がＩＰ電話端末１１−１とＩＰ電話端末１１−２との間の呼制御を行なう場合を例に挙げて説明する。
【００６５】
まず、ＩＰ電話端末１１−１は、着信先をＩＰ電話端末１１−２とする呼設定要求をメインサーバ１０に送信する。ＩＰ電話端末１１−１から呼設定要求を受け取ると、メインサーバ１０においては呼制御部３６により、所定の呼制御プロトコルに従って着信先のＩＰ電話端末１１−２との間で呼制御を行なう（Ｓ１０１）。なお、メインサーバ１０による呼制御シーケンスについては特徴がないのでここでの詳細な説明は省略する。
【００６６】
メインサーバ１０において、ＩＰ電話端末１１−１とＩＰ電話端末１１−２との間の呼制御処理がなされ、呼が確立すると（Ｓ１０２）、メインサーバ１０において、ＩＰ電話端末１１−１とＩＰ電話端末１１−２との呼状態に係る呼制御情報がデータベース部２３に保持される（Ｓ１０３）。この呼制御情報は、呼確立後、例えば、ＩＰ電話端末１１−１及び１１−２が通話状態である等のような情報であり、メインサーバ１０は、この呼制御情報を保持し、その後の切断処理や保留処理や転送処理等の電話サービスを提供する際に、呼制御情報を利用している。
【００６７】
メインサーバ１０により、ＩＰ電話端末１１−１及び１１−２間の呼が確立し、それに係る呼制御情報が保持されると、当該保持された呼制御情報が、メインサーバ１０からサバイバルサーバ１２に転送される（Ｓ１０４）。
【００６８】
メインサーバ１０から呼制御情報が与えられると、サバイバルサーバ１２において、受信した呼制御情報はデータベース部２３に保持される（Ｓ１０５）。
【００６９】
これにより、サバイバルサーバ１２においても呼制御情報を保持することができ、メインサーバ１０に障害が生じ、サバイバルサーバ１２に切り替わった場合でも、呼を切断せずにメインサーバ１０と同等のサービスを継続して提供することができる。
【００７０】
その後、ＩＰ電話端末１１−１からの切断信号がメインサーバ１０に与えられると（Ｓ１０６）、メインサーバ１０は、ＩＰ電話端末１１−２に対して切断を示すメッセージを中継し、ＩＰ電話端末１１−１とＩＰ電話端末１１−２との間の呼について切断処理が行なわれる（Ｓ１０７）。
【００７１】
メインサーバ１０において、切断処理が終了すると、メインサーバ１０は、ＩＰ電話端末１１−１及び１１−２間の呼が切断したことを示す切断情報をサバイバルサーバ１２に与える（Ｓ１０８）。
【００７２】
このとき、メインサーバ１０において保持されているＩＰ電話端末１１−１とＩＰ電話端末１１−２とに関する呼制御情報は破棄され（Ｓ１０９）、またサバイバルサーバ１２において保持されているＩＰ電話端末１１−１とＩＰ電話端末１１−２とに関する呼制御情報は破棄される（Ｓ１１０）。
【００７３】
このようにして、メインサーバ１０とサバイバルサーバ１２との間で同じ呼制御情報を保持することができる。
【００７４】
続いて、メインサーバ１０自体又はメインサーバ１０までの間の伝送経路におけるＩＰ網ＮＴ回線上に障害が生じた場合のサバイバルサーバ１２への切り替え処理について図５を参照して説明する。図５は、サバイバルサーバ１２への切り替え処理を示すシーケンスである。
【００７５】
図５において、ＩＰ電話端末１１−１〜１１−Ｎでは、メインサーバ１０との間の伝送経路についてヘルスチェックを行なう（Ｓ２０１）。
【００７６】
例えば、図５における本実施形態では、メインサーバ１０が、所定周期でＩＰ電話端末１１−１〜１１−Ｎに対してヘルスチェック要求信号を送信し、ＩＰ電話端末１１−１〜１１−Ｎが、メインサーバ１０からのヘルスチェック要求信号を受信すると、これに対してヘルスチェック応答信号を返信する。そして、ＩＰ電話端末１１−１〜１１−Ｎにおいては、ヘルスチェックタイミング期間の期間内に、メインサーバ１０から所定周期毎に送信されるヘルスチェック要求信号が与えられない場合、メインサーバ１０との間の伝送経路が正常でないと判断する。
【００７７】
図５においては、Ｓ２０３において、メインサーバ１０自体又はメインサーバ１０までの間の伝送経路に障害が発生したものとする。そうすると、ＩＰ電話端末１１−１〜１１−Ｎは、直前にメインサーバ１０に返信したヘルスチェック応答信号の送信した時点から所定時間（例えば、２分間）のヘルスチェックタイミング期間が経過しても、メインサーバ１０から次のヘルスチェック要求信号が与えられない場合、メインサーバ１０との間の伝送経路において異常が生じたと判定する（Ｓ２０４）。
【００７８】
ＩＰ電話端末１１−１〜１１−Ｎにおいて、ヘルスチェックタイミング期間の期間メインサーバ１０からヘルスチェック要求信号の受信がなく、メインサーバ１０までの間の伝送経路において異常が生じたと判定すると、ＩＰ電話端末１１−１〜１１−Ｎでは、ヘルスチェックタイミング期間に続けて、メインサーバ１０からのみの再開要求メッセージの受信を待つ再接続待ちタイミング期間（例えば、ヘルスチェックタイミング期間経過後３分）を計時する（Ｓ２０５）。
【００７９】
そして、メインサーバ１０からの再開要求メッセージの受信がなく、再接続待ちタイミング期間が経過すると、ＩＰ電話端末１１−１〜１１−Ｎでは、再接続待ちタイミング期間に続けて、サバイバル再開受付タイミング期間（例えば、再接続待ちタイミング期間経過後５分）を計時する（Ｓ２０６）。この期間においては、メインサーバ１０とサバイバルサーバ１２のどちらかからでも再開要求メッセージを受け取る状態である。
【００８０】
一方、サバイバルサーバ１２も、メインサーバ１０との間の伝送経路についてヘルスチェックを行なっている（Ｓ２０２）。
【００８１】
例えば、図５に示す本実施形態では、サバイバルサーバ１２が、所定周期毎（例えば６０秒毎）にヘルスチェック要求信号をメインサーバ１０に対して送信し、メインサーバ１０からヘルスチェック応答信号を受け取ると、サバイバルサーバ１２はメインサーバ１０との間の伝送経路は正常であると判定する。そして、ヘルスチェック要求信号を送信したにも拘わらず、ヘルスチェック応答信号の受信が所定回数（例えば、６回）連続してない場合（すなわち、この間を時間で示すとヘルスチェック応答信号の直前の受信時点からおよそ６分経過後である）、サバイバルサーバ１２は異常が生じたと判定する。
【００８２】
Ｓ２０３において、メインサーバ１０自体又はメインサーバ１０との間の伝送経路上に障害が生じ、サバイバルサーバ１２におけるヘルスチェックによりメインサーバ１０までの伝送経路上に異常が生じたと検出されると、サバイバルサーバ１２は呼救済の再開のためのサバイバルサーバ１２への切り替え処理を行なう（Ｓ２０８）。
【００８３】
このサバイバルサーバ１２への切り替え処理については、ＩＰ電話端末１１−１〜１１−Ｎにおけるサバイバル再開受付タイミング期間に行なわれることが望ましい。従って、サバイバルサーバ１２においてヘルスチェックタイムアウトとする回数や期間等は、ＩＰ電話端末１１−１〜１１−Ｎにおけるヘルスチェックタイミング期間、再接続待ちタイミング期間及びサバイバル再開受付タイミング期間、との関係において設定することができる。逆に、ＩＰ電話端末１１−１〜１１−Ｎにおけるヘルスチェックタイミング期間、再接続町タイミング期間及びサバイバル再開受付タイミング期間をどれだけの長さにするかを、サバイバルサーバ１２においてヘルスチェックタイムアウトの期間等、との関係において設定することができる。
【００８４】
Ｓ２０８では、サバイバルサーバ１２は、ＩＰ電話端末１１−１〜１１−Ｎに対して、所定の呼制御プログラムのリセットをかけない呼救済再開を行なう。また、サバイバルサーバ１２は、接続先サーバ情報をサバイバルサーバ１２とする再開要求メッセージを作成し、その再開要求メッセージをＩＰ電話端末１１に送信する（Ｓ２０９）。
【００８５】
ＩＰ電話端末１１においては、サバイバル再開受付タイミング期間内に、サバイバルサーバ１２から再開要求メッセージを受信すると、接続先サーバ情報がサバイバルサーバ１２となっているから、接続先サーバをサバイバルサーバ１２とした接続要求を送信する（Ｓ２１０）。
【００８６】
このようにして、ＩＰ電話端末１１は、端末内の呼制御プログラムにリセットをかけずに、呼処理の接続先サーバをメインサーバ１０からサバイバルサーバ１２に切り替えることができる。
【００８７】
このとき、サバイバルサーバ１２においては、管理範囲内のＩＰ電話端末１１−１〜１１−Ｎについての呼制御情報を保持しているから、その管理範囲内のＩＰ電話端末１１−１〜１１−Ｎから接続要求を受けた場合にも、そのまま継続して管理することができる。
【００８８】
そのため、ＩＰ電話端末１１−１〜１１−Ｎにおける呼接続ソフトウェアを再起動させることなく、通話中呼に影響を及ぼさない。
【００８９】
続いて、メインサーバ１０の復旧後、接続先をサバイバルサーバ１０からメインサーバ１２に切り戻す処理を図面を参照しながら説明する。図６は、メインサーバ１０への切り戻し処理を示すシーケンスである。
【００９０】
図６において、サバイバルサーバ１２では、メインサーバ１０との間の伝送経路に異常と判定した後も、メインサーバ１０との間の伝送経路についてヘルスチェックをしている。
【００９１】
サバイバルサーバ１２におけるヘルスチェックにより、メインサーバ１０の復旧が検出されると（Ｓ３０１）、手動又は自動で切り戻し処理が行なわれる（Ｓ３０２）。
【００９２】
このとき、サバイバルサーバ１２は、ＩＰ電話端末１１−１〜１１−Ｎへリセットをかける非救済再開を行なう。また、サバイバルサーバ１２は、接続先サーバ情報をメインサーバ１０とした再開要求メッセージをＩＰ電話端末１１−１〜１１−Ｎに送信する（Ｓ３０３）。
【００９３】
このように、メインサーバ１０の復旧後、サバイバルサーバ１２が、ＩＰ電話端末１１−１〜１１−Ｎに対してリセットをかけることとしたのは、メインサーバ１０が障害発生から復旧するまでの間の呼制御情報を保持していないので、本実施形態では、一度、ＩＰ電話端末１１−１〜１１−Ｎにおいて端末内ソフトウェアをリセットすることとした。
【００９４】
サバイバルサーバ１２から再開要求メッセージを受けると、ＩＰ電話端末１１−１〜１１−Ｎにおいては、接続先をメインサーバ１０とした接続要求をメインサーバ１０に送信する（Ｓ３０４）。
【００９５】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、メインサーバ１０が、確立した呼に係るＩＰ電話端末を管理するサバイバルサーバ１２に対して、当該呼に関する呼制御情報を送信することで、サバイバルサーバ１２もメインサーバ１０と同じ呼制御情報を管理することができる。
【００９６】
また、本実施形態によれば、サバイバルサーバ１２が、メインサーバ１０自体又はメインサーバ１０までの伝送経路における回線上に障害が生じたと判定した場合、接続先をサバイバルサーバとするリセットをかけない再開要求メッセージを管理範囲のＩＰ電話端末に送信することで、通話中呼を切断することなく、サバイバルサーバ１２への切り替え処理を行なうことができる。
【００９７】
（Ｂ）他の実施形態
（Ｂ−１）上述した第１の実施形態では、メインサーバ自体及び又はメインサーバまでの伝送経路における回線上に障害が生じたとき、サバイバルサーバが、リセットをかけず、接続先をサバイバルサーバとする再開要求メッセージを、ＩＰ電話端末に送信することとした。そして、この再開要求メッセージを受信したＩＰ電話端末は、起動中の端末内の呼制御プログラムをリセットせずに、接続先を変更することとした。
【００９８】
しかし、ＩＰ電話端末内で、呼制御プログラムにリセットをかけずに、サーバの接続先を変更することができれば、他の方法も広く適用することができる。
【００９９】
例えば、ＩＰ電話端末内に、障害発生時に接続するサバイバルサーバのアドレスを予め登録しておき、障害を検出した場合に、端末内の呼制御プログラムをリセットせず、接続先だけを変更するようにしてもよい。
【０１００】
（Ｂ−２）図６のＳ３０３では、サバイバルサーバ１２がリセットをかける再会要求メッセージを送信することとしたが、再開要求メッセージを送信する前に、サバイバルサーバ１２が保持している呼制御情報を、メインサーバ１０に送信し、その後、サバイバルサーバ１２が、リセットをかけず、接続先をメインサーバ１０とする再開要求メッセージを、ＩＰ電話端末１１−１〜１１−Ｎに送信するようにしてもよい。
【０１０１】
これにより、復旧後に、メインサーバ１０に切り戻す際にも、ＩＰ電話端末１１−１〜１１−Ｎの通話中呼を切断することなく行なうことが期待できる。
【０１０２】
（Ｂ−３）ヘルスチェック機能は、上述した第１の実施形態で説明した方法に限定されず、他の方法を広く適用することができる。例えば、メインサーバ１０の一部に障害が発生していることを検出する機能（自己管理機能）をメインサーバ１０が備え、自己管理機能がメインサーバ１０の障害発生を検出している場合には、その旨を記述した信号をサバイバルサーバ１２及び又はＩＰ電話端末に送信する方法も適用できる。
【０１０３】
（Ｂ−４）上述した第１の実施形態において説明したメインサーバ１０とサバイバルサーバとが実現する機能は、物理的に同一のサーバが実現するようにしてもよいし、また、同様の機能を奏することができるように、それぞれの機能を実現する装置（サーバ）が拠点内又はネットワーク内に分散配置されるようにしてもよい。
【図面の簡単な説明】
【０１０４】
【図１】第１の実施形態の音声通信システムの全体構成を示す図である。
【図２】第１の実施形態のサーバ（メインサーバ又はサバイバルサーバ）の内部構成を示す機能ブロック図である。
【図３】第１の実施形態のＩＰ電話端末の内部構成を示す機能ブロック図である。
【図４】第１の実施形態のメインサーバとサバイバルサーバとの間で同じ呼制御情報を保持する処理を示すシーケンスである。
【図５】第１の実施形態のサバイバルサーバへの切り替え処理を示すシーケンスである。
【図６】第１の実施形態のメインサーバへの切り戻し処理を示すシーケンスである。
【符号の説明】
【０１０５】
１…音声通信ネットワーク、１０…メインサーバ、１１−１〜１１−Ｎ…ＩＰ電話端末、１２…サバイバルサーバ、２０…端末収容機能部、２１…装置管理機能部、２２…呼処理機能部、２３…データベース部、３０…通信部、３１…制御部、３２…操作部、３３…記憶部、３４…ヘルスチェック部、３５…接続サーバ切替部、３６…呼制御部、３７…表示部。
【特許請求の範囲】
【請求項１】
複数の通信端末を含む拠点を複数有するネットワークにおいて、上記通信端末間の呼処理を行なう主呼処理手段と、
障害検出部により上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が検出されたとき、上記各拠点内に位置する上記通信端末の呼を上記主呼処理手段に代わって呼処理を行なう副呼処理手段と、
上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段と
を備え、
上記副呼処理手段が、
上記呼制御情報転送手段から受け取った上記呼制御情報を保持する呼制御情報保持部と、
上記主呼処理手段に障害が検出されたときに、上記呼制御情報保持部に保持されている上記呼制御情報を用いて、上記通信端末の呼を救済する呼救済部と
を有することを特徴とする呼制御システム。
【請求項２】
上記呼救済部が、上記通信端末に対して、呼処理に係る接続先をそれぞれの拠点内の上記副呼処理手段に切替指示をすることを特徴とする請求項１に記載の呼制御システム。
【請求項３】
上記呼救済部が、上記通信端末上で起動中の処理にリセットをかけずに、呼処理に係る接続先を変更することを指示する再開要求を、上記通信端末にすることを特徴とする請求項２に記載の呼制御システム。
【請求項４】
複数の通信端末を含む拠点を複数有するネットワークで、上記通信端末間の呼処理を行なう主呼処理手段を有するサーバと、上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が発生したときに、上記主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの上記主呼制御手段を有するサーバにおいて、
上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段を備えることを特徴とするサーバ。
【請求項５】
複数の通信端末を含む拠点を複数有するネットワークで、上記通信端末間の呼処理を行なう主呼処理手段と、上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを有するサーバと、上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が発生したときに、上記主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの上記副呼制御手段を有するサーバにおいて、
上記呼制御情報転送手段から受け取った上記呼制御情報を保持する呼制御情報保持手段と、
上記主呼処理手段に障害が検出されたときに、上記呼制御情報保持手段に保持されている上記呼制御情報を用いて、上記通信端末の呼を救済する呼救済手段と
を有することを特徴とするサーバ。
【請求項６】
主呼処理手段が、複数の通信端末を含む拠点を複数有するネットワークにおいて、上記通信端末間の呼処理を行なう主呼処理工程と、
副呼処理手段が、障害検出部により上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が検出されたとき、上記各拠点内に位置する上記通信端末の呼を上記主呼処理手段に代わって管理する副呼処理工程と、
呼制御情報転送手段が、上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送工程と
を備え、
上記副呼処理手段が、
呼制御情報保持部が、上記呼制御情報転送手段から受け取った上記呼制御情報を保持する呼制御情報保持工程と、
呼救済部が、上記主呼処理手段に障害が検出されたときに、上記呼制御情報保持手段に保持されている上記呼制御情報を用いて、上記通信端末の呼を救済する呼救済工程と
を有することを特徴とする呼制御方法。
【請求項１】
複数の通信端末を含む拠点を複数有するネットワークにおいて、上記通信端末間の呼処理を行なう主呼処理手段と、
障害検出部により上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が検出されたとき、上記各拠点内に位置する上記通信端末の呼を上記主呼処理手段に代わって呼処理を行なう副呼処理手段と、
上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段と
を備え、
上記副呼処理手段が、
上記呼制御情報転送手段から受け取った上記呼制御情報を保持する呼制御情報保持部と、
上記主呼処理手段に障害が検出されたときに、上記呼制御情報保持部に保持されている上記呼制御情報を用いて、上記通信端末の呼を救済する呼救済部と
を有することを特徴とする呼制御システム。
【請求項２】
上記呼救済部が、上記通信端末に対して、呼処理に係る接続先をそれぞれの拠点内の上記副呼処理手段に切替指示をすることを特徴とする請求項１に記載の呼制御システム。
【請求項３】
上記呼救済部が、上記通信端末上で起動中の処理にリセットをかけずに、呼処理に係る接続先を変更することを指示する再開要求を、上記通信端末にすることを特徴とする請求項２に記載の呼制御システム。
【請求項４】
複数の通信端末を含む拠点を複数有するネットワークで、上記通信端末間の呼処理を行なう主呼処理手段を有するサーバと、上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が発生したときに、上記主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの上記主呼制御手段を有するサーバにおいて、
上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段を備えることを特徴とするサーバ。
【請求項５】
複数の通信端末を含む拠点を複数有するネットワークで、上記通信端末間の呼処理を行なう主呼処理手段と、上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送手段とを有するサーバと、上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が発生したときに、上記主呼処理手段に代わって呼処理を行なう副呼処理手段を有するサーバとを備える呼制御システムの上記副呼制御手段を有するサーバにおいて、
上記呼制御情報転送手段から受け取った上記呼制御情報を保持する呼制御情報保持手段と、
上記主呼処理手段に障害が検出されたときに、上記呼制御情報保持手段に保持されている上記呼制御情報を用いて、上記通信端末の呼を救済する呼救済手段と
を有することを特徴とするサーバ。
【請求項６】
主呼処理手段が、複数の通信端末を含む拠点を複数有するネットワークにおいて、上記通信端末間の呼処理を行なう主呼処理工程と、
副呼処理手段が、障害検出部により上記主呼処理手段及び又は上記呼処理手段までの伝送経路上に障害が検出されたとき、上記各拠点内に位置する上記通信端末の呼を上記主呼処理手段に代わって管理する副呼処理工程と、
呼制御情報転送手段が、上記主呼処理手段による上記通信端末間の呼確立後、当該通信端末が位置する上記拠点の上記副呼処理手段に、当該通信端末の呼制御情報を転送する呼制御情報転送工程と
を備え、
上記副呼処理手段が、
呼制御情報保持部が、上記呼制御情報転送手段から受け取った上記呼制御情報を保持する呼制御情報保持工程と、
呼救済部が、上記主呼処理手段に障害が検出されたときに、上記呼制御情報保持手段に保持されている上記呼制御情報を用いて、上記通信端末の呼を救済する呼救済工程と
を有することを特徴とする呼制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００７−２６６７３７（Ｐ２００７−２６６７３７Ａ）
【公開日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願番号】特願２００６−８６０４５（Ｐ２００６−８６０４５）
【出願日】平成１８年３月２７日（２００６．３．２７）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【出願人】（５９５１２５４２１）沖通信システム株式会社 (131)
【Ｆターム（参考）】
【公開日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願日】平成１８年３月２７日（２００６．３．２７）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【出願人】（５９５１２５４２１）沖通信システム株式会社 (131)
【Ｆターム（参考）】
[ Back to top ]