JP2004072256A - 呼制御装置、通信端末、これらを含む通信システム、及び呼制御障害の対策方法 - Google Patents
呼制御装置、通信端末、これらを含む通信システム、及び呼制御障害の対策方法 Download PDFInfo
- Publication number
- JP2004072256A JP2004072256A JP2002226306A JP2002226306A JP2004072256A JP 2004072256 A JP2004072256 A JP 2004072256A JP 2002226306 A JP2002226306 A JP 2002226306A JP 2002226306 A JP2002226306 A JP 2002226306A JP 2004072256 A JP2004072256 A JP 2004072256A
- Authority
- JP
- Japan
- Prior art keywords
- call control
- control device
- communication
- call
- communication terminals
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1046—Call controllers; Call servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Monitoring And Testing Of Exchanges (AREA)
- Exchange Systems With Centralized Control (AREA)
- Small-Scale Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Abstract
【課題】装置コストを抑えつつ、呼制御障害に対応する。
【解決手段】ＬＡＮ回線９を介して接続されている二つの呼制御装置１０ａ，１０ｂは、ＩＰパケット通信を行うための通信インタフェース１１ａ，１１ｂと、各端末２０，２８，２９相互の呼制御を行う呼制御部１２ａ，１２ｂと、自身の呼制御部１２ａ及び他方の呼制御装置の状態を監視する監視部１３ｂと、を備えている。第１の呼制御装置１０ａが運用系で、第２の呼制御装置１０ｂが予備系のときに、第１の呼制御装置１０ａに障害が発生して、第２の呼制御装置１０ｂの監視部１３ｂが、第１の呼制御装置１０ａからの動作可通知を受信できなくなると、第１の呼制御装置１０ａに障害が発生したと認識して、待機状態である呼制御部１２ｂを運用状態にして、第２の呼制御装置１０ｂを運用系にする。
【選択図】 図１
【解決手段】ＬＡＮ回線９を介して接続されている二つの呼制御装置１０ａ，１０ｂは、ＩＰパケット通信を行うための通信インタフェース１１ａ，１１ｂと、各端末２０，２８，２９相互の呼制御を行う呼制御部１２ａ，１２ｂと、自身の呼制御部１２ａ及び他方の呼制御装置の状態を監視する監視部１３ｂと、を備えている。第１の呼制御装置１０ａが運用系で、第２の呼制御装置１０ｂが予備系のときに、第１の呼制御装置１０ａに障害が発生して、第２の呼制御装置１０ｂの監視部１３ｂが、第１の呼制御装置１０ａからの動作可通知を受信できなくなると、第１の呼制御装置１０ａに障害が発生したと認識して、待機状態である呼制御部１２ｂを運用状態にして、第２の呼制御装置１０ｂを運用系にする。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＰパケット通信を行う複数の通信端末相互間の呼制御を行う呼制御装置、通信端末、これらを含む通信システム、及び呼制御障害の対策方法に関する。
【０００２】
【従来の技術】
従来、ＩＰパケット通信システムとしては、例えば、図８に示すようなものがある。
【０００３】
このＩＰパケット通信システムは、ＩＰパケット通信を行う複数の通信端末７，８と、複数の通信端末７，８相互間の呼制御を行う呼制御装置３と、を有している。複数の通信端末７，８や呼制御装置３の相互間は、ＬＡＮ回線９で接続されている。通信端末７，８としては、ＩＰ電話機や、ＩＰゲートウエイや、一般電話機が複数接続されるＩＰ・ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ Ｅｘｃｈａｎｇｅｒ）等があげられる。
【０００４】
呼制御装置３は、無停止呼サービスを行うために、第１の呼制御部５ａと、第２の呼制御部５ｂと、これらの呼制御部５ａ，５ｂを管理する呼制御管理部６と、ＩＰパケット通信を行うための通信インタフェース４と、を有している。この呼制御装置３は、仮に、第１の呼制御部５ａが運用状態である際には、第２の呼制御部５ｂは待機状態になっている。この際、呼制御管理部６は、運用状態にある第１の呼制御部５ａに障害が発生していないかを常時監視していると共に、第１の呼制御部５ｂが所有している呼サービス設定情報や呼制御状態情報をそのまま第２の呼制御部５ｂに与えている。言い換えると、第１の呼制御部５ａが呼サービス情報や呼制御状態情報を取得すると、これとほぼ同時にこれらの情報を第２の呼制御部５ｂにデッドコピーしている。なお、呼サービス設定情報とは、各端末が設定し得る呼サービスに関する情報で、例えば、端末自身への着信を他の端末へ転送する着信転送サービス等の各種サービスである。また、呼制御状態情報とは、いずれの端末が通話中であるか等、各端末の状態に関する情報である。
【０００５】
この呼制御装置３は、第１の呼制御部５ａに障害が生じた場合、呼制御管理部６が、この障害を直ちに検知して、第１の呼制御部５ａの全ての情報を所有している待機中の第２の呼制御部５ｂを起動させて、無停止呼サービスを実現している。
【０００６】
【発明が解決しようとする課題】
しかしながら、以上の従来技術では、第１の呼制御部５ａの他に、予備機としての第２の呼制御部５ｂを設けておくと共に、二つの呼制御部５ａ，５ｂから独立したハードウェアーとしての呼制御管理部６を設けておく必要があるため、装置コストがかさむという問題点がある。特に、呼制御管理部６は、前述したように、第１の呼制御部５ａが端末の呼サービス設定情報や呼制御状態情報を取得すると、ほぼ同時に、これらの情報を第２の呼制御部５ｂにデッドコピーするために、特殊なハードウェアーで構成され、非常に高価である。
【０００７】
本発明は、このような従来技術の問題点に着目してなされたもので、装置コストを抑えつつ、呼制御に障害が生じても対応することができる、装置、これを含む通信システム、及び呼制御障害の対策方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
前記目的を達成するため呼制御装置は、
複数の通信端末及び他の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記通信端末の呼制御を行う呼制御手段と、
前記通信手段を介して、前記他の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が一定時間以上受信できない場合、該他の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御手段を起動させて、運用状態にする監視手段と、
を備えていることを特徴とするものである。
【０００９】
ここで、前記呼制御装置は、
複数の前記端末の呼サービスに関する設定情報であって、前記呼制御手段が呼制御を行う際に用いる呼サービス設定情報を、前記待機状態において、前記通信手段を介して、前記他の呼制御装置から取得し管理する設定情報管理手段を備えていることが好ましい。
【００１０】
この場合、前記呼制御手段が運用状態になると、
前記設定情報管理手段は、前記通信手段を介して、該設定情報管理手段が管理している呼サービス設定情報を前記他の呼制御装置へ送り、
前記監視手段は、前記呼制御手段による呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に、前記一定時間毎に前記他の呼制御装置へ動作可通知を送り、前記呼制御手段による呼制御に障害が発生していることを認識すると、該他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手段を運用状態から待機状態にする、ことが好ましい。
【００１１】
また、前記目的を達成するための他の呼制御装置は、
複数の通信端末及び他の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記通信端末の呼制御を行う呼制御手段と、
前記呼制御手段による呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に前記他の呼制御装置へ動作可通知を送り、前記呼制御手段による呼制御に障害が発生していることを認識すると、前記他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手段を運用状態から待機状態にする監視手段と、
を備えていることを特徴とするものである。
【００１２】
ここで、前記呼制御装置は、
複数の前記端末の呼サービスに関する設定情報であって、前記呼制御手段が呼制御を行う際に用いる呼サービス設定情報を管理すると共に、前記運用状態において、前記通信手段を介して、一定時間毎に該呼サービス設定情報を前記他の呼制御装置へ送る設定情報管理手段を備えていることが好ましい。
【００１３】
また、以上の各呼制御装置は、
前記呼制御手段が運用状態である際には、前記監視手段は、前記通信手段を介して、複数の前記通信端末に対して、呼制御可能な状態である旨を通知することが好ましい。
【００１４】
さらに、以上の各呼制御装置は、
前記呼制御手段が運用状態である際、前記監視手段は、複数の前記通信端末のうちいずれかから、現時点で呼制御可能な運用状態である呼制御装置に対しての応答要求を、前記通信手段を介して受信すると、該応答要求を送信してきた前記通信端末に対して、呼制御装置のＩＰアドレスを送信することが好ましい。
【００１５】
前記目的を達成するための通信端末は、
他の通信端末及び複数の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記呼制御装置のうちの一の呼制御装置が呼制御可能な運用状態で、他の呼制御装置が待機状態であるときに、前記通信手段を介して、該一の呼制御装置から呼制御可能な運用状態である旨を一定時間毎に受信して、該運用状態の該一の呼制御装置を監視し、該呼制御可能な運用状態である旨を該一定時間以上受信できない場合には、該一の呼制御装置による呼制御に障害が発生していると認識して、該一の呼制御装置に対する呼制御接続を該通信手段に解放さる監視手段と、
を備えていることを特徴とするものである。
【００１６】
ここで、前記通信端末の前記監視手段は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できず、前記一の呼制御装置に対する呼制御接続を解放させた後、複数の前記呼制御装置のうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を、前記通信手段を介して、要求することが好ましい。
【００１７】
また、前記目的を達成するための呼制御装置の動作プログラムは、
複数の通信端末の呼制御を行う呼制御手順と、
他の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が一定時間以上受信できない場合、該他の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御手段を起動させて、運用状態にする監視手順と、
を演算装置に実行させることを特徴とするものである。
【００１８】
前記目的を達成するための他の呼制御装置の動作プログラムは、
複数の通信端末の呼制御を行う呼制御手順と、
前記呼制御手順での呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に他の呼制御装置へ動作可通知を送り、前記呼制御手順での呼制御に障害が発生していることを認識すると、前記他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手順を運用状態から待機状態にする監視手順と、
を演算装置に実行させることを特徴とするものである。
【００１９】
前記目的を達成するための通信端末の動作プログラムにおいて、
複数の呼制御装置のうちの一の呼制御装置が呼制御可能な運用状態で、他の呼制御装置が待機状態であるときに、該一の呼制御装置に対して、他の通信端末との通信のために呼制御を、通信手段を介して依頼する呼制御依頼手順と、
前記一の呼制御装置から呼制御可能な運用状態である旨を一定時間毎に受信して、該運用状態の該一の呼制御装置を監視し、該呼制御可能な運用状態である旨を該一定時間以上受信できない場合には、該一の呼制御装置による呼制御に障害が発生していると認識して、該一の呼制御装置に対する呼制御接続を前記通信手段に解放させ、前記一の呼制御装置に対する呼制御接続を解放させた後、複数の前記呼制御装置のうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を、前記通信手段を介して、要求する監視手順と、
を演算装置に実行させることを特徴とするのである。も
また、前記目的を達成するための呼制御障害の対策方法は、
複数の通信端末とＩＰパケット通信が可能な第１の呼制御装置及び第二の呼制御装置を設け、
前記第１の呼制御装置は、
複数の前記通信端末の呼制御を行う呼制御工程と、
前記呼制御工程での呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に前記第２の呼制御装置へ一定時間毎に動作可通知を送り、前記呼制御工程での呼制御に障害が発生していることを認識すると、該第２の呼制御装置への前記動作可通知の送信を中止して、前記呼制御工程を運用状態から待機状態にする監視工程と、
を実行し、
前記第２の呼制御装置は、
複数の前記通信端末の呼制御を行う呼制御工程と、
前記第１の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が前記一定時間以上受信できない場合、該第１の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御工程を起動させて、運用状態にする監視工程と、
を実行することを特徴とするものである。
【００２０】
ここで、以上の呼制御障害の対策方法において、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、前記呼制御工程が運用状態である呼制御装置の前記監視工程では、複数の前記通信端末に対して、呼制御可能な状態である旨を一定時間毎に通知し、
複数の前記通信端末は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できないときには、前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を要求し、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置の監視工程では、複数の前記通信端末からの前記応答要求に対して、該応答要求を送信してきた前記通信端末に対して、該呼制御装置のＩＰアドレスを送信することが好ましい。
【００２１】
【発明の実施の形態】
以下、本発明に係るＩＰパケット通信システムの各種実施形態について、図面を用いて説明する。
【００２２】
まず、図１〜図４を用いて、本発明に係る第１の実施形態としてのＩＰパケット通信システムについて説明する。
【００２３】
本実施形態のＩＰパケット通信システムは、図１に示すように、ＩＰパケット通信を行う複数の通信端末２０，２８，２９と、複数の通信端末相互間の呼制御を行う第１及び第２の呼制御装置１０ａ，１０ｂと、を有している。複数の通信端末２０，２８，２９や各呼制御装置１０ａ，１０ｂの相互間は、ＬＡＮ回線９で接続されている。この実施形態において、複数の通信端末２０，２８，２９のうち、一つはＩＰゲートウエイ２０で、残りはＩＰ電話機２８，２９である。
【００２４】
第１及び第２の呼制御装置１０ａ，１０ｂは、いずれも、ＩＰパケット通信を行うための通信インタフェース１１ａ，１１ｂと、各通信端末相互間の呼制御を実際に行う呼制御部１２ａ，１２ｂと、この呼制御部１２ａ，１２ｂ及び他方の呼制御装置１０ｂ，１０ａの状態を監視する監視部１３ａと、各端末２０，２８，２９の呼制御サービスに関する設定情報を管理する設定情報管理部１４ａと、呼サービス設定情報や各通信端末のＩＰアドレス等を記憶する記憶部１５ａ，１５ｂと、を備えている。
【００２５】
監視部１３ａ，１３ｂは、呼制御部１２ａ，１２ｂ及び通信インタフェース１１ａ，１１ｂを監視し、これらの障害がなければ、通信インタフェース１１ａ，１１ｂを介して、呼制御可能状態であることを示す動作可能通知を他方の呼制御装置に送信する。また、他方の呼制御装置からは、通信インタフェース１１ａ，１１ｂを介して、動作可能通知を受信する。監視部１３ａ，１３ｂは、呼制御部１２ａ，１２ｂ及び通信インタフェース１１ａ，１１ｂの監視結果、及び他方の呼制御装置からの動作可能通知に基づき、呼制御部１２ａ，１２ｂ及び設定情報管理部１４ａ，１４ｂを待機状態から運用状態へ、又は運用状態から待機状態へ切り替える。
【００２６】
設定情報管理部１４ａ，１４ｂは、運用状態の際、通信インタフェース１１ａ，１１ｂを介して、記憶部１５ａ，１５ｂに記憶されている呼サービス設定情報を他方の呼制御装置へ送信し、待機状態の際には、他方の呼制御装置から呼サービス設定情報を取得し、記憶部１５ａ，１５ｂに登録する。
【００２７】
各通信端末２０，２８，２９は、ＩＰパケット通信を行うための通信インタフェース２１と、この通信インタフェース２１で受信したＩＰパケットを音声信号等に変換する一方で、音声信号等をＩＰパケットに変換する符号化・復号化部２２と、符号化・復号化部２２で復号化された音声信号をアナログ信号に変換するＡ／Ｄ変換器２３と、二つの呼制御装置１０ａ，１０ｂの状態を監視する監視部２５と、を有している。なお、通信端末がＩＰゲートウエイ２０である場合には、Ａ／Ｄ変換器２３に、ＰＢＸ等との間で音声信号等を送受信するためのインタフェース２４が接続されることになる。また、通信端末がＩＰ電話機２８，２９である場合には、Ａ／Ｄ変換器に、ハンドセット等が接続されることになる。
【００２８】
次に、以上で説明した本実施形態の通信システムの動作について、図２を用いて説明する。なお、同図では、初期設定により、第１の呼制御装置１０ａの呼制御部１１ａが運用状態で、この第１の呼制御装置１０ａが運用系として働き、第２の呼制御装置１０ｂの呼制御部１１ｂが待機状態で、この第２の呼制御装置１０ｂが予備系として働くよう、設定されているものとする。また、通信端末２０は、運用系として働いている第１の呼制御装置１０ａに対して接続運用中であるとする。
【００２９】
運用系である第１の呼制御装置１０ａの監視部１３ａは、定期的に、自身の呼制御部１２ａ及び通信インタフェース１１ａを監視し、呼制御可能な状態であることを確かめて、通信インタフェース１１ａ及びＬＡＮ回線９を介して、動作可通知を第２の呼制御装置１０ｂへ送信する（ステップ１）。また、予備系である第２の呼制御装置１０ｂの監視部１３ｂも、以上と同様に、動作可通知を定期的に第１の呼制御装置１０ａへ送信する（ステップ２）。また、第１の呼制御装置１０ａの設定情報管理部１４ａは、定期的に、記憶部１５ａに記憶されている各通信端末の呼サービス設定情報を、通信インタフェース１１ａ及びＬＡＮ回線９を介して、第２の呼制御装置１０ｂへ送信する（ステップ３）。なお、各通信端末２０の呼サービス設定情報は、各通信端末２０において、ユーザ等による操作で設定され、この情報が、後述の呼制御通信（ステップ４）で、呼制御装置１０ａの設定情報管理部１４ａに渡される。
【００３０】
通信端末２０が他の通信端末と通話する場合には、この通信端末２０が運用系であると認識している呼制御装置１０ａとの間で呼制御通信が行われる、つまり、この通信端末２０と他の通信端末との間の呼制御が呼制御装置１０ａに依頼される（ステップ４）。この呼制御通信により、他の通信端末との通信回線が確立すると、他の通信端末との間で通話が可能になる。
【００３１】
運用系呼制御装置１０ａの監視部１３ａは、動作可通知を送信する際と同様、定期的に、自身の呼制御部１２ａ及び通信インタフェース１１ａの監視し、呼制御可能な状態であることを確かめて、通信インタフェース１１ａ及びＬＡＮ回線９を介して、呼制御可能な状態であることを示すと共に、その応答を要求する動作確認要求を各通信端末２０に送信する（ステップ５）。通信端末２０の監視部２５は、この動作確認要求を受け取ると、この動作確認要求元が運用系であると認識する。そして、この動作確認要求に対する返答として、動作確認応答を運用系呼制御装置１０ａへ送信する（ステップ６）
つまり、運用系呼制御装置１０ａは、定期的に、例えば、５秒毎に、動作可通知及び呼サービス設定情報を予備系呼制御装置１０ｂへ送信し（ステップ１，３）、予備系呼制御装置１０ｂは、定期的に、動作可通知を運用系呼制御装置１０ａへ送信する（ステップ２）。さらに、運用系呼制御装置１０ａは、定期的に、各通信端末２０に動作確認要求を送信する（ステップ５）。
【００３２】
以上のように、二つの呼制御装置１０ａ，１０ｂが互いに他方の呼制御装置１０ｂ，１０ａに対して動作可通知を送信し合うことで、他方の呼制御装置が呼制御可能な状態であるか否かを認識することができる。また、運用系呼制御装置１０ａが定期的に呼サービス設定情報を予備系呼制御装置２０ｂへ送信することで、この呼サービス設定情報の共有化を図ることができる。また、運用系呼制御装置１０ａが定期的に動作確認要求を送信することで、各端末１０はいずれの呼制御装置が現在運用系であるかを認識することができる。
【００３３】
運用系呼制御装置１０ａの呼制御部１２ａ又は通信インタフェース１１ａに障害が生じると（ステップ７）、運用系呼制御装置１０ａの監視部１３ａは、この障害を認識し、現在の予備系呼制御装置１０ｂへの動作可通知及び各通信端末への動作確認要求を停止し、呼制御部を待機状態にして、予備系に切り替える（ステップ８）。
【００３４】
予備系である第２の呼制御装置１０ｂの監視部１３ｂは、当初、運用系であった第１の呼制御装置１０ａから、一定期間、動作可通知が送信されてこないことから、この第１の呼制御装置１０ａに障害が発生したと認識して、待機状態であった呼制御部１２ｂを運用状態にして、当該第２の呼制御装置１０ｂを運用系に切り替える（ステップ９）。
【００３５】
また、各通信端末２０の監視部２５も、当初、運用系であった第１の呼制御装置１０ａから、一定期間、動作確認要求が送信されてこないことから、この第１の呼制御装置１０ａに障害が発生したと認識して、この第１の呼制御装置１０ａとの接続を解放する（ステップ１０）。
【００３６】
各通信端末２０の監視部２５は、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ１１）。この検索応答要求に対して、予備系に切り替わった第１の呼制御装置１０ｂは応答せず、運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、検索応答要求のあった通信端末２０に対して、検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを送信して、現在運用状態にある呼制御装置１０ｂを認識させると共に（ステップ１２）、検索応答要求のあった通信端末２０のＩＰアドレスを記憶する（ステップ１５）。検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを受信した通信端末２０の通信インタフェース２１は、このＩＰアドレスを記憶し（ステップ１３）、その後、この運用系になった第２の呼制御装置１０ｂとの間で、呼制御通信のための接続処理を行う（ステップ１４）。
【００３７】
運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、第１の呼制御装置１０ａが運用系であったときと同様に、定期的に、自身の呼制御部１２ｂ及び通信インタフェース１１ｂを監視し、呼制御可能な状態であることを確かめて、動作可通知を予備系である第１の呼制御装置１０ａへ送信すると共に（ステップ２１）、各通信端末に動作確認要求を送信する（ステップ２５）。この動作確認要求に対して、各通信端末２０は、現在運用系である第２の呼制御装置１０ｂに動作確認応答を返す（ステップ２６）。また、第２の呼制御装置１０ｂの設定情報管理部１４ｂは、呼サービス設定情報を第１の呼制御装置１０ａへ送信する（ステップ２３）。予備系である第１の呼制御装置１０ａの監視部１３ａは、自身の呼制御部１２ａ及び通信インタフェース１１ａを監視し、故障等の障害が復旧して呼制御可能な状態になると、第２の呼制御装置１０ｂに対して、動作可通知を定期的に送信し始める。
【００３８】
通信端末２０が他の通信端末と通話する場合には、ステップ４と同様に、この通信端末２０の監視部が運用系であると認識している呼制御装置、この場合は、第２の呼制御装置１０ｂとの間で呼制御通信が行われる（ステップ２４）。この呼制御通信により、他の通信端末との通信回線が確立すると、他の通信端末との間で通話が可能になる。
【００３９】
なお、以上で説明したステップ１１〜１４の処理は、各通信端末２０の立ち上げ時にも、各通信端末２０が運用系呼制御装置を認識等するために、初期処理として行われる。具体的は、図３のフローチャートに示すように、まず、通信端末２０の監視部２５が、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ１１）。続いて、監視部２５は、この検索応答要求に対する運用系呼制御装置からの検索応答の受信を待ち（ステップ１２）、この検索応答を受信すると、監視部２５は、検索応答と共に送られてきた運用系呼制御装置のＩＰアドレスを記憶部２６に登録する（ステップ１３）。さらに、監視部２５は、通信インタフェース２１に、運用系呼制御装置との間での呼制御通信を行うための接続処理を実行させる（ステップ１４）。
【００４０】
その後、この通信端末２０が他の通信端末と通話する場合には、この通信端末２０の記憶部２６に運用系として記憶されている呼制御装置との間で、呼制御通信が行われる（ステップ２４）。また、監視部２５は、運用系呼制御装置からの動作確認要求を定期的に受信しているか否かを判断し（ステップ２５）、動作確認要求を受信できない場合には、ステップ１１に戻り、動作確認要求を受信できた場合には、運用系呼制御装置へ動作確認応答を送る（ステップ２６）。
【００４１】
ここで、図４を用いて、各呼制御装置の動作について、まとめて説明する。
【００４２】
運用系呼制御装置は、障害がない場合、予備系呼制御装置に障害が在ろうが無かろうが、予備系呼制御装置に対して、動作可通知及び呼サービス設定情報を定期的に送信する。また、通信端末に対しては、動作確認要求を送信し、検索応答要求に対して検索応答を返し、呼制御接続時の呼サービス指示を与える。
【００４３】
運用系呼制御装置に障害が発生し、この運用系が予備系に移行し、予備系が運用系に移動した場合、予備系から運用系に移動した呼制御装置は、運用系から予備系に移行した呼制御装置に対して、この呼制御装置に障害が在ろうが無かろうが、動作可通知及び呼サービス設定情報を定期的に送信する。また、通信端末に対しては、動作確認要求を送信し、検索応答要求に対して検索応答を返し、呼制御接続時の呼サービス指示を与える。
【００４４】
予備系呼制御装置は、障害がない場合、運用系呼制御装置に対して、動作可通知を定期的に送信する。運用系呼制御装置に対する呼サービス設定情報の送信、通信端末に対する動作確認要求の送信、通信端末からの検索応答要求に対する検索応答、呼制御接続時の呼サービス指示は、いずれも、運用系呼制御装置が行い、予備系呼制御装置は行わない。
【００４５】
運用系呼制御装置に障害が発生し、この運用系が予備系に移行した場合、運用系から予備系に移行した呼制御装置は、運用系呼制御装置に対する動作可通知及び呼サービス設定情報の送信を行わない。さらに、通信端末に対する動作確認要求の送信、通信端末からの検索応答要求に対する検索応答、呼制御接続時の呼サービス指示も行わない。
【００４６】
以上のように、本実施形態では、２台の呼制御装置１０ａ，１０ｂのうち、運用系呼制御装置１０ａに障害が生じても、予備系呼制御装置１０ｂが運用系となって、各通信端末相互の呼制御を行うので、呼制御障害による被害を最小限に抑えることができる。また、２台の呼制御装置１０ａ，１０ｂ相互間で、呼制御可能な状態であるか否かを通信で確認しあっているので、２台の呼制御装置１０ａ，１０ｂの他に別途、これらを管理する呼制御管理装置が不要になり、装置コストを抑えることができる。
【００４７】
次に、図５〜図７を用いて、本発明に係る第２の実施形態としてのＩＰパケット通信システムについて説明する。
【００４８】
本実施形態のＩＰパケット通信システムは、図５に示すように、ＩＰ網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ ｎｅｔｗｏｒｋ）１及びルータ等の中継装置２ａ，２ｂを介して、二つの通信拠点Ａ，Ｂが接続されているものである。各通信拠点Ａ，Ｂには、呼制御装置１０ａ，１０ｂと、前述の中継装置２ａ，２ｂと、複数の通信端末２０ａ，２９ａ，２０ｂ，２９ｂとを備えている。呼制御装置１０ａ，１０ｂ、中継装置２ａ，２ｂ、複数の端末２０ａ，２９ａ，２０ｂ，２９ｂ相互は、ＬＡＮ回線９ａ，９ｂで接続されている。つまり、第１の実施形態は、ある拠点内に２台の呼制御装置と複数の通信端末とを設けたものであるが、本実施形態は、ＷＡＮ１を介して、二つの通信拠点にそれぞれ一台ずつの呼制御装置と複数の通信端末とを設けたものである。
【００４９】
各拠点Ａ，Ｂの呼制御装置１０ａ，１０ｂは、第１の実施形態と同様に、ＩＰパケット通信を行うための通信インタフェース１１ａ，１１ｂと、各通信端末相互間の呼制御を実際に行う呼制御部１２ａ，１２ｂと、この呼制御部１２ａ，１２ｂ及び他方の呼制御装置の状態を監視する監視部１３ａ，１３ｂと、各端末の呼制御サービスに関する設定情報を管理する設定情報管理部１４ａ，１４ｂと、呼サービス設定情報等を記憶する記憶部１５ａ，１５ｂと、を備えている。
【００５０】
また、各拠点Ａ，Ｂの通信端末２０ａ，２０ｂも、第１の実施形態と同様に、ＩＰパケット通信を行うための通信インタフェース２１と、この通信インタフェース２１で受信したＩＰパケットを音声信号等に変換する一方で、音声信号等をＩＰパケットに変換する符号化・復号化部２２と、符号化・復号化部２２で復号化された音声信号をアナログ信号に変換するＡ／Ｄ変換器２３と、二つの呼制御装置の状態を監視する監視部２５と、記憶部２６と、を備えている。
【００５１】
次に、以上で説明した本実施形態の通信システムの動作について、図６を用いて説明する。なお、同図では、初期設定により、拠点Ａの第１の呼制御装置１０ａが運用系として働き、拠点Ｂの第２の呼制御装置１０ｂが予備系として働くよう、設定されているものとする。また、各拠点Ａ，Ｂの通信端末２０ａ，２０ｂは、運用系として働いている第１の呼制御装置１０ａに対して接続運用中であるとする。
【００５２】
運用系である第１の呼制御装置１０ａの監視部１３ａは、第１の実施形態と同様に、通信インタフェース１１ａ、中継装置２ａ，２ｂ及びＷＡＮ１を介して、動作可通知及び各通信端末の呼サービス設定情報を予備系である第２の呼制御装置１０ｂへ送信する（ステップ３１，３３）。また、予備系である第２の呼制御装置１０ｂの監視部１３ｂも、以上と同様に、動作可通知を定期的に第１の呼制御装置１０ａへ送信する（ステップ３２）。
【００５３】
拠点Ａ，Ｂの通信端末２０ａ，２０ｂが他の通信端末２０ｂ，２０ａと通話する場合には、この通信端末２０ａ，２０ｂが運用系であると認識している呼制御装置１０ａとの間で呼制御通信が行われる（ステップ３４ａ，３４ｂ）。
【００５４】
拠点Ａの運用系呼制御装置１０ａの監視部１３ａは、動作確認要求を各拠点Ａ，Ｂの通信端末２０ａ，２０ｂに送信する（ステップ３５ａ，３５ｂ）。各拠点Ａ，Ｂの通信端末２０ａ，２０ｂの監視部１３ａ，１３ｂは、この動作確認要求を受け取ると、この動作確認要求元が運用系であると認識し、この動作確認要求に対する返答として、動作確認応答を運用系呼制御装置１０ａへ送信する（ステップ３６ａ，３６ｂ）。
【００５５】
つまり、以上のステップ３１〜３６ｂまでの処理は、第１の実施形態におけるステップ１〜６までの処理と同様の処理である。
【００５６】
拠点Ａ，Ｂ間の中継回線に障害が生じた場合（ステップ３７）、運用系呼制御装置１０ａの監視部１３ａは、自身の呼制御部１２ａの障害ではないため、この中継回線障害を認識せず、拠点Ｂの予備系呼制御装置１０ｂへ動作可通知を送信する共に（ステップ３８）、拠点Ａ，Ｂの各通信端末２０ａ，２０ｂへ動作確認要求を送信する（ステップ４０ａ，４０ｂ）。また、拠点Ｂの予備系呼制御装置１０ｂの監視部１３ｂも、拠点Ａの運用系呼制御装置１０ａへ動作確認要求を送信する（ステップ３９）。しかしながら、拠点Ａ，Ｂ間の中継回線に障害が生じているため、拠点Ａの運用系呼制御装置１０ａから拠点Ｂへの動作可通知及び動作確認要求は、拠点Ｂに到達せず（ステップ３８，ステップ４０ｂ）、また、拠点Ｂの予備系呼制御装置１０ｂから拠点Ａへの動作可通知も、拠点Ａに到達しない（ステップ３９）。
【００５７】
拠点Ａの運用系呼制御装置１０ａは、拠点Ｂの予備系呼制御装置からの動作可通知を受信できないため、拠点Ｂで障害が生じたと認識して、以降、拠点Ａの通信端末２０ａにのみ、動作確認要求を送信し（ステップ４０ａ）、この端末２０ａから動作確認応答を受信する（ステップ４１ａ）。さらに、拠点Ａの通信端末とのみ、呼制御通信を行う（ステップ４２ａ）。但し、拠点Ｂへの動作確認要求の送信は、以降も定期的に行う（ステップ３８，３８，…）。
【００５８】
一方、拠点Ｂの予備系呼制御装置１０ｂの監視部１３ｂは、拠点Ａの運用系呼制御装置１０ａから、一定期間、動作可通知が送信されてこないことから（ステップ３８）、拠点Ａの運用系呼制御装置１０ａに障害が発生したと認識して、待機状態であった呼制御部１２ｂを運用状態にして、予備系であった第２の呼制御装置１０ｂを運用系に切り替える（ステップ４３）。
【００５９】
また、拠点Ｂの各通信端末２０ｂの監視部２５も、当初、運用系であった第１の呼制御装置２０ａから、一定期間、動作確認要求が送信されてこないことから（ステップ４０ｂ）、拠点Ａの第１の呼制御装置１０ａに障害が発生したと認識して、この第１の呼制御装置１０ａとの接続を解放する（ステップ４１）。
【００６０】
そして、拠点Ｂの各通信端末２０ｂの監視部２５は、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ４４）。この検索応答要求に対して、運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、検索応答要求のあった拠点Ｂの通信端末２０ｂに対して、検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを送信して、現在運用状態にある呼制御装置１０ｂを認識させると共に（ステップ４５）、検索応答要求のあった通信端末２０ｂのＩＰアドレスを記憶する（ステップ４８）。検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを受信した通信端末２０ｂの通信インタフェース２１は、このＩＰアドレスを記憶部２５に記憶し（ステップ４６）、その後、この運用系になった第２の呼制御装置１０ｂとの間で、呼制御通信のための接続処理を行う（ステップ４７）。
【００６１】
運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、第１の呼制御装置１０ａが運用系であったときと同様に、定期的に、自身の呼制御部１２ｂ及び通信インタフェース１１ｂを監視し、呼制御可能な状態であることを確かめて、動作可通知を拠点Ａの第１の呼制御装置１０ａへ送信すると共に（ステップ５２）、拠点Ｂの各通信端末２０ｂに動作確認要求を送信する（ステップ５０ｂ）。この動作確認要求に対して、拠点Ｂの各通信端末２０ｂは、動作確認応答を返す（ステップ５１ｂ）。
【００６２】
以上のように、中継回線に障害が発生した場合には、拠点Ａの第１の呼制御装置１０ａは、運用系を維持するものの、拠点Ａの各通信端末２０ａに対してのみ呼制御装置として機能し、当初、予備系であった拠点Ｂの第２の呼制御装置１０ｂは、運用系に切り替わるものの、拠点Ｂの各通信端末２０ｂに対してのみ呼制御装置として機能する。つまり、中継回線に障害が発生している際中は、各拠点の呼制御装置が、それぞれの拠点の運用系呼制御装置となる。
【００６３】
次に、図７を用いて、中継回線の障害が復旧した場合の動作について、説明する。
【００６４】
中継回線の障害が復旧すると（ステップ５５）、拠点Ｂの第２の呼制御装置１０ｂからの動作可通知が拠点Ａの第１の呼制御装置１０ａへ到達するようになる（ステップ５６）。同様に、拠点Ａの第１の呼制御装置１０ａからの動作可通知が拠点Ｂの第２の呼制御装置１０ｂへ到達するようになる（ステップ５７）。
【００６５】
この結果、拠点Ｂの第２の呼制御装置１０ｂの監視部１３ｂは、当初、運用系であった拠点Ａの第１の呼制御装置１０ａの障害が復旧したと認識して、運用状態であった呼制御部１２ｂを待機状態にして、運用系であった第２の呼制御装置１０ｂを予備系に切り替える（ステップ５８）。そして、予備系として、拠点Ａの第１の呼制御装置１０ａに動作可通知を送信する（ステップ６０）。なお、拠点Ｂの第２の呼制御装置１０ｂの監視部１３ｂは、予備系に切り替わった時点から、拠点Ｂの各通信端末２０ｂへ動作確認要求を送信しなくなる。
【００６６】
また、拠点Ａの第１の呼制御装置１０ａの監視部１３ｂは、障害発生中も定期的に送っていた動作可通知を拠点Ｂの第２の呼制御装置１０ｂへ送信すると共に（ステップ５７）、拠点Ｂの第２の呼制御装置１０ｂからの動作可通知により（ステップ６０）、この第２の呼制御装置１０ｂが復旧したと認識して、第１の呼制御装置１０ａの設定情報管理部１４ａは、呼サービス設定情報を拠点Ｂの第２の呼制御装置１０ｂへ送信し始める（ステップ６１）。
【００６７】
一方、拠点Ｂの通信端末２０ｂの監視部２５は、今まで運用系であった第２の呼制御装置１０ｂから、一定期間、動作確認要求が送信されてこないことから（ステップ５０ｂ）、拠点Ｂの第２の呼制御装置１０ｂに障害が発生したと認識して、この第２の呼制御装置１０ｂとの接続を解放する（ステップ６２）。
【００６８】
そして、拠点Ｂの各通信端末２０ｂの監視部２５は、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ６３）。この検索応答要求に対して、再び、運用系になった第１の呼制御装置１０ａの監視部１３ａは、検索応答要求のあった拠点Ｂの通信端末２０ｂに対して、検索応答と共に第１の呼制御装置１０ａのＩＰアドレスを送信して、現在運用状態にある呼制御装置１０ａを認識させると共に（ステップ６４）、検索応答要求のあった通信端末２０ｂのＩＰアドレスを記憶する（ステップ６８）。検索応答と共に第１の呼制御装置１０ａのＩＰアドレスを受信した通信端末２０ｂの通信インタフェース２１は、このＩＰアドレスを記憶し（ステップ６５）、その後、この運用系になった第１の呼制御装置１０ａとの間で、呼制御通信のための接続処理を行う（ステップ６７）。
【００６９】
以降、図７に示す中継回線に障害が発生する前と同様に、拠点Ａの第１の呼制御装置１０ａは、拠点Ａ，Ｂの通信端末２０ａ，２０ｂに対して、動作確認要求を送信し（ステップ３５ａ，３５ｂ）、拠点Ａ，Ｂの通信端末２０ａ，２０ｂから動作確認応答を受信する（ステップ３６ａ，３６ｂ）。さらに、第１の呼制御装置１０ａは、再び予備系になった第２の呼制御装置１０ｂに動作可通知及び呼サービス設定情報を送信し（ステップ３１，３３）、この第２の呼制御装置１０ｂから動作可通知を受信する（ステップ３２）。
【００７０】
以上のように、本実施形態では、二つの拠点間の中継回線に障害が生じても、各拠点に設けられている呼制御装置が運用系になり、各拠点内での各通信端末相互の呼制御を行うので、中継回線障害による被害を最小限に抑えることができる。また、中継回線に障害が生じて、予備系であった呼制御装置が運用系に切り替わっても、当初から運用系であった呼制御装置から、呼サービス設定情報を取得しているので、各拠点で同じサービスを提供することができる。
【００７１】
なお、本実施形態で、当初、運用系である第１の呼制御装置１０ａに障害が発生した場合には、第１の実施形態と同様に、第２の呼制御装置１０ｂが運用系になり、この第２の呼制御装置１０ｂが各拠点Ａ，Ｂの各通信端末２０ａ，２０ｂの呼制御を行うことになる。従って、本実施形態でも、第１の実施形態と同様の効果を得ることができる。
【００７２】
また、本実施形態では、二つの拠点Ａ，Ｂにそれぞれ呼制御装置１０ａ，１０ｂを設けた例を示したが、本発明は、これに限定されるものではなく、三つ以上の拠点にそれぞれ呼制御装置を設けてもよい。この場合、複数の拠点の各予備系呼制御装置に関して、予め優先順位を定めておき、一つの拠点の運用系呼制御装置に障害が発生すると、この優先順位に従って、複数の予備系のうちの一つが運用系になるようにするとよい。
【００７３】
【発明の効果】
本発明によれば、２台の呼制御装置のうち、運用状態の呼制御装置に障害が生じても、待機状態の呼制御装置が運用状態となって、各通信端末相互の呼制御を行うので、呼制御障害による被害を最小限に抑えることができる。また、２台の呼制御装置相互間で、呼制御可能な状態であるか否かを通信で確認しあっているので、２台の呼制御装置の他に別途、これらを管理する呼制御管理装置が不要になり、装置コストを抑えることができる。
【図面の簡単な説明】
【図１】本発明に係る第１の実施形態における通信システムの機能ブロック図である。
【図２】本発明に係る第１の実施形態における通信システムのシーケンス図である。
【図３】本発明に係る第１の実施形態における通信端末の立ち上がり時からの動作を示すフローチャートである。
【図４】本発明に係る第１の実施形態における呼制御装置の各状態での動作を示す説明図である。
【図５】本発明に係る第２の実施形態における通信システムの回路ブロック図である。
【図６】本発明に係る第２の実施形態における通信システムのシーケンス図（その１）である。
【図７】本発明に係る第２の実施形態における通信システムのシーケンス図（その２）である。
【図８】従来の通信システムの機能ブロック図である。
【符号の説明】
１…ＷＡＮ、２ａ，２ｂ…中継装置、３，１０ａ，１０ｂ…呼制御装置、９，９ａ，９ｂ…ＬＡＮ回線、１１ａ，１１ｂ…通信インタフェース、１２ａ，１２ｂ…呼制御部、１３ａ，１３ｂ…監視部、１４ａ，１４ｂ…設定情報管理部、１５ａ，１５ｂ…記憶部、２０，２０ａ，２０ｂ，２８，２９，２９ａ，２９ｂ…通信端末、２１…通信インタフェース、２２…符号化・複合化部、２５…監視部、２６…記憶部。
【発明の属する技術分野】
本発明は、ＩＰパケット通信を行う複数の通信端末相互間の呼制御を行う呼制御装置、通信端末、これらを含む通信システム、及び呼制御障害の対策方法に関する。
【０００２】
【従来の技術】
従来、ＩＰパケット通信システムとしては、例えば、図８に示すようなものがある。
【０００３】
このＩＰパケット通信システムは、ＩＰパケット通信を行う複数の通信端末７，８と、複数の通信端末７，８相互間の呼制御を行う呼制御装置３と、を有している。複数の通信端末７，８や呼制御装置３の相互間は、ＬＡＮ回線９で接続されている。通信端末７，８としては、ＩＰ電話機や、ＩＰゲートウエイや、一般電話機が複数接続されるＩＰ・ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ Ｅｘｃｈａｎｇｅｒ）等があげられる。
【０００４】
呼制御装置３は、無停止呼サービスを行うために、第１の呼制御部５ａと、第２の呼制御部５ｂと、これらの呼制御部５ａ，５ｂを管理する呼制御管理部６と、ＩＰパケット通信を行うための通信インタフェース４と、を有している。この呼制御装置３は、仮に、第１の呼制御部５ａが運用状態である際には、第２の呼制御部５ｂは待機状態になっている。この際、呼制御管理部６は、運用状態にある第１の呼制御部５ａに障害が発生していないかを常時監視していると共に、第１の呼制御部５ｂが所有している呼サービス設定情報や呼制御状態情報をそのまま第２の呼制御部５ｂに与えている。言い換えると、第１の呼制御部５ａが呼サービス情報や呼制御状態情報を取得すると、これとほぼ同時にこれらの情報を第２の呼制御部５ｂにデッドコピーしている。なお、呼サービス設定情報とは、各端末が設定し得る呼サービスに関する情報で、例えば、端末自身への着信を他の端末へ転送する着信転送サービス等の各種サービスである。また、呼制御状態情報とは、いずれの端末が通話中であるか等、各端末の状態に関する情報である。
【０００５】
この呼制御装置３は、第１の呼制御部５ａに障害が生じた場合、呼制御管理部６が、この障害を直ちに検知して、第１の呼制御部５ａの全ての情報を所有している待機中の第２の呼制御部５ｂを起動させて、無停止呼サービスを実現している。
【０００６】
【発明が解決しようとする課題】
しかしながら、以上の従来技術では、第１の呼制御部５ａの他に、予備機としての第２の呼制御部５ｂを設けておくと共に、二つの呼制御部５ａ，５ｂから独立したハードウェアーとしての呼制御管理部６を設けておく必要があるため、装置コストがかさむという問題点がある。特に、呼制御管理部６は、前述したように、第１の呼制御部５ａが端末の呼サービス設定情報や呼制御状態情報を取得すると、ほぼ同時に、これらの情報を第２の呼制御部５ｂにデッドコピーするために、特殊なハードウェアーで構成され、非常に高価である。
【０００７】
本発明は、このような従来技術の問題点に着目してなされたもので、装置コストを抑えつつ、呼制御に障害が生じても対応することができる、装置、これを含む通信システム、及び呼制御障害の対策方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
前記目的を達成するため呼制御装置は、
複数の通信端末及び他の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記通信端末の呼制御を行う呼制御手段と、
前記通信手段を介して、前記他の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が一定時間以上受信できない場合、該他の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御手段を起動させて、運用状態にする監視手段と、
を備えていることを特徴とするものである。
【０００９】
ここで、前記呼制御装置は、
複数の前記端末の呼サービスに関する設定情報であって、前記呼制御手段が呼制御を行う際に用いる呼サービス設定情報を、前記待機状態において、前記通信手段を介して、前記他の呼制御装置から取得し管理する設定情報管理手段を備えていることが好ましい。
【００１０】
この場合、前記呼制御手段が運用状態になると、
前記設定情報管理手段は、前記通信手段を介して、該設定情報管理手段が管理している呼サービス設定情報を前記他の呼制御装置へ送り、
前記監視手段は、前記呼制御手段による呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に、前記一定時間毎に前記他の呼制御装置へ動作可通知を送り、前記呼制御手段による呼制御に障害が発生していることを認識すると、該他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手段を運用状態から待機状態にする、ことが好ましい。
【００１１】
また、前記目的を達成するための他の呼制御装置は、
複数の通信端末及び他の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記通信端末の呼制御を行う呼制御手段と、
前記呼制御手段による呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に前記他の呼制御装置へ動作可通知を送り、前記呼制御手段による呼制御に障害が発生していることを認識すると、前記他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手段を運用状態から待機状態にする監視手段と、
を備えていることを特徴とするものである。
【００１２】
ここで、前記呼制御装置は、
複数の前記端末の呼サービスに関する設定情報であって、前記呼制御手段が呼制御を行う際に用いる呼サービス設定情報を管理すると共に、前記運用状態において、前記通信手段を介して、一定時間毎に該呼サービス設定情報を前記他の呼制御装置へ送る設定情報管理手段を備えていることが好ましい。
【００１３】
また、以上の各呼制御装置は、
前記呼制御手段が運用状態である際には、前記監視手段は、前記通信手段を介して、複数の前記通信端末に対して、呼制御可能な状態である旨を通知することが好ましい。
【００１４】
さらに、以上の各呼制御装置は、
前記呼制御手段が運用状態である際、前記監視手段は、複数の前記通信端末のうちいずれかから、現時点で呼制御可能な運用状態である呼制御装置に対しての応答要求を、前記通信手段を介して受信すると、該応答要求を送信してきた前記通信端末に対して、呼制御装置のＩＰアドレスを送信することが好ましい。
【００１５】
前記目的を達成するための通信端末は、
他の通信端末及び複数の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記呼制御装置のうちの一の呼制御装置が呼制御可能な運用状態で、他の呼制御装置が待機状態であるときに、前記通信手段を介して、該一の呼制御装置から呼制御可能な運用状態である旨を一定時間毎に受信して、該運用状態の該一の呼制御装置を監視し、該呼制御可能な運用状態である旨を該一定時間以上受信できない場合には、該一の呼制御装置による呼制御に障害が発生していると認識して、該一の呼制御装置に対する呼制御接続を該通信手段に解放さる監視手段と、
を備えていることを特徴とするものである。
【００１６】
ここで、前記通信端末の前記監視手段は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できず、前記一の呼制御装置に対する呼制御接続を解放させた後、複数の前記呼制御装置のうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を、前記通信手段を介して、要求することが好ましい。
【００１７】
また、前記目的を達成するための呼制御装置の動作プログラムは、
複数の通信端末の呼制御を行う呼制御手順と、
他の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が一定時間以上受信できない場合、該他の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御手段を起動させて、運用状態にする監視手順と、
を演算装置に実行させることを特徴とするものである。
【００１８】
前記目的を達成するための他の呼制御装置の動作プログラムは、
複数の通信端末の呼制御を行う呼制御手順と、
前記呼制御手順での呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に他の呼制御装置へ動作可通知を送り、前記呼制御手順での呼制御に障害が発生していることを認識すると、前記他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手順を運用状態から待機状態にする監視手順と、
を演算装置に実行させることを特徴とするものである。
【００１９】
前記目的を達成するための通信端末の動作プログラムにおいて、
複数の呼制御装置のうちの一の呼制御装置が呼制御可能な運用状態で、他の呼制御装置が待機状態であるときに、該一の呼制御装置に対して、他の通信端末との通信のために呼制御を、通信手段を介して依頼する呼制御依頼手順と、
前記一の呼制御装置から呼制御可能な運用状態である旨を一定時間毎に受信して、該運用状態の該一の呼制御装置を監視し、該呼制御可能な運用状態である旨を該一定時間以上受信できない場合には、該一の呼制御装置による呼制御に障害が発生していると認識して、該一の呼制御装置に対する呼制御接続を前記通信手段に解放させ、前記一の呼制御装置に対する呼制御接続を解放させた後、複数の前記呼制御装置のうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を、前記通信手段を介して、要求する監視手順と、
を演算装置に実行させることを特徴とするのである。も
また、前記目的を達成するための呼制御障害の対策方法は、
複数の通信端末とＩＰパケット通信が可能な第１の呼制御装置及び第二の呼制御装置を設け、
前記第１の呼制御装置は、
複数の前記通信端末の呼制御を行う呼制御工程と、
前記呼制御工程での呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に前記第２の呼制御装置へ一定時間毎に動作可通知を送り、前記呼制御工程での呼制御に障害が発生していることを認識すると、該第２の呼制御装置への前記動作可通知の送信を中止して、前記呼制御工程を運用状態から待機状態にする監視工程と、
を実行し、
前記第２の呼制御装置は、
複数の前記通信端末の呼制御を行う呼制御工程と、
前記第１の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が前記一定時間以上受信できない場合、該第１の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御工程を起動させて、運用状態にする監視工程と、
を実行することを特徴とするものである。
【００２０】
ここで、以上の呼制御障害の対策方法において、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、前記呼制御工程が運用状態である呼制御装置の前記監視工程では、複数の前記通信端末に対して、呼制御可能な状態である旨を一定時間毎に通知し、
複数の前記通信端末は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できないときには、前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を要求し、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置の監視工程では、複数の前記通信端末からの前記応答要求に対して、該応答要求を送信してきた前記通信端末に対して、該呼制御装置のＩＰアドレスを送信することが好ましい。
【００２１】
【発明の実施の形態】
以下、本発明に係るＩＰパケット通信システムの各種実施形態について、図面を用いて説明する。
【００２２】
まず、図１〜図４を用いて、本発明に係る第１の実施形態としてのＩＰパケット通信システムについて説明する。
【００２３】
本実施形態のＩＰパケット通信システムは、図１に示すように、ＩＰパケット通信を行う複数の通信端末２０，２８，２９と、複数の通信端末相互間の呼制御を行う第１及び第２の呼制御装置１０ａ，１０ｂと、を有している。複数の通信端末２０，２８，２９や各呼制御装置１０ａ，１０ｂの相互間は、ＬＡＮ回線９で接続されている。この実施形態において、複数の通信端末２０，２８，２９のうち、一つはＩＰゲートウエイ２０で、残りはＩＰ電話機２８，２９である。
【００２４】
第１及び第２の呼制御装置１０ａ，１０ｂは、いずれも、ＩＰパケット通信を行うための通信インタフェース１１ａ，１１ｂと、各通信端末相互間の呼制御を実際に行う呼制御部１２ａ，１２ｂと、この呼制御部１２ａ，１２ｂ及び他方の呼制御装置１０ｂ，１０ａの状態を監視する監視部１３ａと、各端末２０，２８，２９の呼制御サービスに関する設定情報を管理する設定情報管理部１４ａと、呼サービス設定情報や各通信端末のＩＰアドレス等を記憶する記憶部１５ａ，１５ｂと、を備えている。
【００２５】
監視部１３ａ，１３ｂは、呼制御部１２ａ，１２ｂ及び通信インタフェース１１ａ，１１ｂを監視し、これらの障害がなければ、通信インタフェース１１ａ，１１ｂを介して、呼制御可能状態であることを示す動作可能通知を他方の呼制御装置に送信する。また、他方の呼制御装置からは、通信インタフェース１１ａ，１１ｂを介して、動作可能通知を受信する。監視部１３ａ，１３ｂは、呼制御部１２ａ，１２ｂ及び通信インタフェース１１ａ，１１ｂの監視結果、及び他方の呼制御装置からの動作可能通知に基づき、呼制御部１２ａ，１２ｂ及び設定情報管理部１４ａ，１４ｂを待機状態から運用状態へ、又は運用状態から待機状態へ切り替える。
【００２６】
設定情報管理部１４ａ，１４ｂは、運用状態の際、通信インタフェース１１ａ，１１ｂを介して、記憶部１５ａ，１５ｂに記憶されている呼サービス設定情報を他方の呼制御装置へ送信し、待機状態の際には、他方の呼制御装置から呼サービス設定情報を取得し、記憶部１５ａ，１５ｂに登録する。
【００２７】
各通信端末２０，２８，２９は、ＩＰパケット通信を行うための通信インタフェース２１と、この通信インタフェース２１で受信したＩＰパケットを音声信号等に変換する一方で、音声信号等をＩＰパケットに変換する符号化・復号化部２２と、符号化・復号化部２２で復号化された音声信号をアナログ信号に変換するＡ／Ｄ変換器２３と、二つの呼制御装置１０ａ，１０ｂの状態を監視する監視部２５と、を有している。なお、通信端末がＩＰゲートウエイ２０である場合には、Ａ／Ｄ変換器２３に、ＰＢＸ等との間で音声信号等を送受信するためのインタフェース２４が接続されることになる。また、通信端末がＩＰ電話機２８，２９である場合には、Ａ／Ｄ変換器に、ハンドセット等が接続されることになる。
【００２８】
次に、以上で説明した本実施形態の通信システムの動作について、図２を用いて説明する。なお、同図では、初期設定により、第１の呼制御装置１０ａの呼制御部１１ａが運用状態で、この第１の呼制御装置１０ａが運用系として働き、第２の呼制御装置１０ｂの呼制御部１１ｂが待機状態で、この第２の呼制御装置１０ｂが予備系として働くよう、設定されているものとする。また、通信端末２０は、運用系として働いている第１の呼制御装置１０ａに対して接続運用中であるとする。
【００２９】
運用系である第１の呼制御装置１０ａの監視部１３ａは、定期的に、自身の呼制御部１２ａ及び通信インタフェース１１ａを監視し、呼制御可能な状態であることを確かめて、通信インタフェース１１ａ及びＬＡＮ回線９を介して、動作可通知を第２の呼制御装置１０ｂへ送信する（ステップ１）。また、予備系である第２の呼制御装置１０ｂの監視部１３ｂも、以上と同様に、動作可通知を定期的に第１の呼制御装置１０ａへ送信する（ステップ２）。また、第１の呼制御装置１０ａの設定情報管理部１４ａは、定期的に、記憶部１５ａに記憶されている各通信端末の呼サービス設定情報を、通信インタフェース１１ａ及びＬＡＮ回線９を介して、第２の呼制御装置１０ｂへ送信する（ステップ３）。なお、各通信端末２０の呼サービス設定情報は、各通信端末２０において、ユーザ等による操作で設定され、この情報が、後述の呼制御通信（ステップ４）で、呼制御装置１０ａの設定情報管理部１４ａに渡される。
【００３０】
通信端末２０が他の通信端末と通話する場合には、この通信端末２０が運用系であると認識している呼制御装置１０ａとの間で呼制御通信が行われる、つまり、この通信端末２０と他の通信端末との間の呼制御が呼制御装置１０ａに依頼される（ステップ４）。この呼制御通信により、他の通信端末との通信回線が確立すると、他の通信端末との間で通話が可能になる。
【００３１】
運用系呼制御装置１０ａの監視部１３ａは、動作可通知を送信する際と同様、定期的に、自身の呼制御部１２ａ及び通信インタフェース１１ａの監視し、呼制御可能な状態であることを確かめて、通信インタフェース１１ａ及びＬＡＮ回線９を介して、呼制御可能な状態であることを示すと共に、その応答を要求する動作確認要求を各通信端末２０に送信する（ステップ５）。通信端末２０の監視部２５は、この動作確認要求を受け取ると、この動作確認要求元が運用系であると認識する。そして、この動作確認要求に対する返答として、動作確認応答を運用系呼制御装置１０ａへ送信する（ステップ６）
つまり、運用系呼制御装置１０ａは、定期的に、例えば、５秒毎に、動作可通知及び呼サービス設定情報を予備系呼制御装置１０ｂへ送信し（ステップ１，３）、予備系呼制御装置１０ｂは、定期的に、動作可通知を運用系呼制御装置１０ａへ送信する（ステップ２）。さらに、運用系呼制御装置１０ａは、定期的に、各通信端末２０に動作確認要求を送信する（ステップ５）。
【００３２】
以上のように、二つの呼制御装置１０ａ，１０ｂが互いに他方の呼制御装置１０ｂ，１０ａに対して動作可通知を送信し合うことで、他方の呼制御装置が呼制御可能な状態であるか否かを認識することができる。また、運用系呼制御装置１０ａが定期的に呼サービス設定情報を予備系呼制御装置２０ｂへ送信することで、この呼サービス設定情報の共有化を図ることができる。また、運用系呼制御装置１０ａが定期的に動作確認要求を送信することで、各端末１０はいずれの呼制御装置が現在運用系であるかを認識することができる。
【００３３】
運用系呼制御装置１０ａの呼制御部１２ａ又は通信インタフェース１１ａに障害が生じると（ステップ７）、運用系呼制御装置１０ａの監視部１３ａは、この障害を認識し、現在の予備系呼制御装置１０ｂへの動作可通知及び各通信端末への動作確認要求を停止し、呼制御部を待機状態にして、予備系に切り替える（ステップ８）。
【００３４】
予備系である第２の呼制御装置１０ｂの監視部１３ｂは、当初、運用系であった第１の呼制御装置１０ａから、一定期間、動作可通知が送信されてこないことから、この第１の呼制御装置１０ａに障害が発生したと認識して、待機状態であった呼制御部１２ｂを運用状態にして、当該第２の呼制御装置１０ｂを運用系に切り替える（ステップ９）。
【００３５】
また、各通信端末２０の監視部２５も、当初、運用系であった第１の呼制御装置１０ａから、一定期間、動作確認要求が送信されてこないことから、この第１の呼制御装置１０ａに障害が発生したと認識して、この第１の呼制御装置１０ａとの接続を解放する（ステップ１０）。
【００３６】
各通信端末２０の監視部２５は、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ１１）。この検索応答要求に対して、予備系に切り替わった第１の呼制御装置１０ｂは応答せず、運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、検索応答要求のあった通信端末２０に対して、検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを送信して、現在運用状態にある呼制御装置１０ｂを認識させると共に（ステップ１２）、検索応答要求のあった通信端末２０のＩＰアドレスを記憶する（ステップ１５）。検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを受信した通信端末２０の通信インタフェース２１は、このＩＰアドレスを記憶し（ステップ１３）、その後、この運用系になった第２の呼制御装置１０ｂとの間で、呼制御通信のための接続処理を行う（ステップ１４）。
【００３７】
運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、第１の呼制御装置１０ａが運用系であったときと同様に、定期的に、自身の呼制御部１２ｂ及び通信インタフェース１１ｂを監視し、呼制御可能な状態であることを確かめて、動作可通知を予備系である第１の呼制御装置１０ａへ送信すると共に（ステップ２１）、各通信端末に動作確認要求を送信する（ステップ２５）。この動作確認要求に対して、各通信端末２０は、現在運用系である第２の呼制御装置１０ｂに動作確認応答を返す（ステップ２６）。また、第２の呼制御装置１０ｂの設定情報管理部１４ｂは、呼サービス設定情報を第１の呼制御装置１０ａへ送信する（ステップ２３）。予備系である第１の呼制御装置１０ａの監視部１３ａは、自身の呼制御部１２ａ及び通信インタフェース１１ａを監視し、故障等の障害が復旧して呼制御可能な状態になると、第２の呼制御装置１０ｂに対して、動作可通知を定期的に送信し始める。
【００３８】
通信端末２０が他の通信端末と通話する場合には、ステップ４と同様に、この通信端末２０の監視部が運用系であると認識している呼制御装置、この場合は、第２の呼制御装置１０ｂとの間で呼制御通信が行われる（ステップ２４）。この呼制御通信により、他の通信端末との通信回線が確立すると、他の通信端末との間で通話が可能になる。
【００３９】
なお、以上で説明したステップ１１〜１４の処理は、各通信端末２０の立ち上げ時にも、各通信端末２０が運用系呼制御装置を認識等するために、初期処理として行われる。具体的は、図３のフローチャートに示すように、まず、通信端末２０の監視部２５が、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ１１）。続いて、監視部２５は、この検索応答要求に対する運用系呼制御装置からの検索応答の受信を待ち（ステップ１２）、この検索応答を受信すると、監視部２５は、検索応答と共に送られてきた運用系呼制御装置のＩＰアドレスを記憶部２６に登録する（ステップ１３）。さらに、監視部２５は、通信インタフェース２１に、運用系呼制御装置との間での呼制御通信を行うための接続処理を実行させる（ステップ１４）。
【００４０】
その後、この通信端末２０が他の通信端末と通話する場合には、この通信端末２０の記憶部２６に運用系として記憶されている呼制御装置との間で、呼制御通信が行われる（ステップ２４）。また、監視部２５は、運用系呼制御装置からの動作確認要求を定期的に受信しているか否かを判断し（ステップ２５）、動作確認要求を受信できない場合には、ステップ１１に戻り、動作確認要求を受信できた場合には、運用系呼制御装置へ動作確認応答を送る（ステップ２６）。
【００４１】
ここで、図４を用いて、各呼制御装置の動作について、まとめて説明する。
【００４２】
運用系呼制御装置は、障害がない場合、予備系呼制御装置に障害が在ろうが無かろうが、予備系呼制御装置に対して、動作可通知及び呼サービス設定情報を定期的に送信する。また、通信端末に対しては、動作確認要求を送信し、検索応答要求に対して検索応答を返し、呼制御接続時の呼サービス指示を与える。
【００４３】
運用系呼制御装置に障害が発生し、この運用系が予備系に移行し、予備系が運用系に移動した場合、予備系から運用系に移動した呼制御装置は、運用系から予備系に移行した呼制御装置に対して、この呼制御装置に障害が在ろうが無かろうが、動作可通知及び呼サービス設定情報を定期的に送信する。また、通信端末に対しては、動作確認要求を送信し、検索応答要求に対して検索応答を返し、呼制御接続時の呼サービス指示を与える。
【００４４】
予備系呼制御装置は、障害がない場合、運用系呼制御装置に対して、動作可通知を定期的に送信する。運用系呼制御装置に対する呼サービス設定情報の送信、通信端末に対する動作確認要求の送信、通信端末からの検索応答要求に対する検索応答、呼制御接続時の呼サービス指示は、いずれも、運用系呼制御装置が行い、予備系呼制御装置は行わない。
【００４５】
運用系呼制御装置に障害が発生し、この運用系が予備系に移行した場合、運用系から予備系に移行した呼制御装置は、運用系呼制御装置に対する動作可通知及び呼サービス設定情報の送信を行わない。さらに、通信端末に対する動作確認要求の送信、通信端末からの検索応答要求に対する検索応答、呼制御接続時の呼サービス指示も行わない。
【００４６】
以上のように、本実施形態では、２台の呼制御装置１０ａ，１０ｂのうち、運用系呼制御装置１０ａに障害が生じても、予備系呼制御装置１０ｂが運用系となって、各通信端末相互の呼制御を行うので、呼制御障害による被害を最小限に抑えることができる。また、２台の呼制御装置１０ａ，１０ｂ相互間で、呼制御可能な状態であるか否かを通信で確認しあっているので、２台の呼制御装置１０ａ，１０ｂの他に別途、これらを管理する呼制御管理装置が不要になり、装置コストを抑えることができる。
【００４７】
次に、図５〜図７を用いて、本発明に係る第２の実施形態としてのＩＰパケット通信システムについて説明する。
【００４８】
本実施形態のＩＰパケット通信システムは、図５に示すように、ＩＰ網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ ｎｅｔｗｏｒｋ）１及びルータ等の中継装置２ａ，２ｂを介して、二つの通信拠点Ａ，Ｂが接続されているものである。各通信拠点Ａ，Ｂには、呼制御装置１０ａ，１０ｂと、前述の中継装置２ａ，２ｂと、複数の通信端末２０ａ，２９ａ，２０ｂ，２９ｂとを備えている。呼制御装置１０ａ，１０ｂ、中継装置２ａ，２ｂ、複数の端末２０ａ，２９ａ，２０ｂ，２９ｂ相互は、ＬＡＮ回線９ａ，９ｂで接続されている。つまり、第１の実施形態は、ある拠点内に２台の呼制御装置と複数の通信端末とを設けたものであるが、本実施形態は、ＷＡＮ１を介して、二つの通信拠点にそれぞれ一台ずつの呼制御装置と複数の通信端末とを設けたものである。
【００４９】
各拠点Ａ，Ｂの呼制御装置１０ａ，１０ｂは、第１の実施形態と同様に、ＩＰパケット通信を行うための通信インタフェース１１ａ，１１ｂと、各通信端末相互間の呼制御を実際に行う呼制御部１２ａ，１２ｂと、この呼制御部１２ａ，１２ｂ及び他方の呼制御装置の状態を監視する監視部１３ａ，１３ｂと、各端末の呼制御サービスに関する設定情報を管理する設定情報管理部１４ａ，１４ｂと、呼サービス設定情報等を記憶する記憶部１５ａ，１５ｂと、を備えている。
【００５０】
また、各拠点Ａ，Ｂの通信端末２０ａ，２０ｂも、第１の実施形態と同様に、ＩＰパケット通信を行うための通信インタフェース２１と、この通信インタフェース２１で受信したＩＰパケットを音声信号等に変換する一方で、音声信号等をＩＰパケットに変換する符号化・復号化部２２と、符号化・復号化部２２で復号化された音声信号をアナログ信号に変換するＡ／Ｄ変換器２３と、二つの呼制御装置の状態を監視する監視部２５と、記憶部２６と、を備えている。
【００５１】
次に、以上で説明した本実施形態の通信システムの動作について、図６を用いて説明する。なお、同図では、初期設定により、拠点Ａの第１の呼制御装置１０ａが運用系として働き、拠点Ｂの第２の呼制御装置１０ｂが予備系として働くよう、設定されているものとする。また、各拠点Ａ，Ｂの通信端末２０ａ，２０ｂは、運用系として働いている第１の呼制御装置１０ａに対して接続運用中であるとする。
【００５２】
運用系である第１の呼制御装置１０ａの監視部１３ａは、第１の実施形態と同様に、通信インタフェース１１ａ、中継装置２ａ，２ｂ及びＷＡＮ１を介して、動作可通知及び各通信端末の呼サービス設定情報を予備系である第２の呼制御装置１０ｂへ送信する（ステップ３１，３３）。また、予備系である第２の呼制御装置１０ｂの監視部１３ｂも、以上と同様に、動作可通知を定期的に第１の呼制御装置１０ａへ送信する（ステップ３２）。
【００５３】
拠点Ａ，Ｂの通信端末２０ａ，２０ｂが他の通信端末２０ｂ，２０ａと通話する場合には、この通信端末２０ａ，２０ｂが運用系であると認識している呼制御装置１０ａとの間で呼制御通信が行われる（ステップ３４ａ，３４ｂ）。
【００５４】
拠点Ａの運用系呼制御装置１０ａの監視部１３ａは、動作確認要求を各拠点Ａ，Ｂの通信端末２０ａ，２０ｂに送信する（ステップ３５ａ，３５ｂ）。各拠点Ａ，Ｂの通信端末２０ａ，２０ｂの監視部１３ａ，１３ｂは、この動作確認要求を受け取ると、この動作確認要求元が運用系であると認識し、この動作確認要求に対する返答として、動作確認応答を運用系呼制御装置１０ａへ送信する（ステップ３６ａ，３６ｂ）。
【００５５】
つまり、以上のステップ３１〜３６ｂまでの処理は、第１の実施形態におけるステップ１〜６までの処理と同様の処理である。
【００５６】
拠点Ａ，Ｂ間の中継回線に障害が生じた場合（ステップ３７）、運用系呼制御装置１０ａの監視部１３ａは、自身の呼制御部１２ａの障害ではないため、この中継回線障害を認識せず、拠点Ｂの予備系呼制御装置１０ｂへ動作可通知を送信する共に（ステップ３８）、拠点Ａ，Ｂの各通信端末２０ａ，２０ｂへ動作確認要求を送信する（ステップ４０ａ，４０ｂ）。また、拠点Ｂの予備系呼制御装置１０ｂの監視部１３ｂも、拠点Ａの運用系呼制御装置１０ａへ動作確認要求を送信する（ステップ３９）。しかしながら、拠点Ａ，Ｂ間の中継回線に障害が生じているため、拠点Ａの運用系呼制御装置１０ａから拠点Ｂへの動作可通知及び動作確認要求は、拠点Ｂに到達せず（ステップ３８，ステップ４０ｂ）、また、拠点Ｂの予備系呼制御装置１０ｂから拠点Ａへの動作可通知も、拠点Ａに到達しない（ステップ３９）。
【００５７】
拠点Ａの運用系呼制御装置１０ａは、拠点Ｂの予備系呼制御装置からの動作可通知を受信できないため、拠点Ｂで障害が生じたと認識して、以降、拠点Ａの通信端末２０ａにのみ、動作確認要求を送信し（ステップ４０ａ）、この端末２０ａから動作確認応答を受信する（ステップ４１ａ）。さらに、拠点Ａの通信端末とのみ、呼制御通信を行う（ステップ４２ａ）。但し、拠点Ｂへの動作確認要求の送信は、以降も定期的に行う（ステップ３８，３８，…）。
【００５８】
一方、拠点Ｂの予備系呼制御装置１０ｂの監視部１３ｂは、拠点Ａの運用系呼制御装置１０ａから、一定期間、動作可通知が送信されてこないことから（ステップ３８）、拠点Ａの運用系呼制御装置１０ａに障害が発生したと認識して、待機状態であった呼制御部１２ｂを運用状態にして、予備系であった第２の呼制御装置１０ｂを運用系に切り替える（ステップ４３）。
【００５９】
また、拠点Ｂの各通信端末２０ｂの監視部２５も、当初、運用系であった第１の呼制御装置２０ａから、一定期間、動作確認要求が送信されてこないことから（ステップ４０ｂ）、拠点Ａの第１の呼制御装置１０ａに障害が発生したと認識して、この第１の呼制御装置１０ａとの接続を解放する（ステップ４１）。
【００６０】
そして、拠点Ｂの各通信端末２０ｂの監視部２５は、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ４４）。この検索応答要求に対して、運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、検索応答要求のあった拠点Ｂの通信端末２０ｂに対して、検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを送信して、現在運用状態にある呼制御装置１０ｂを認識させると共に（ステップ４５）、検索応答要求のあった通信端末２０ｂのＩＰアドレスを記憶する（ステップ４８）。検索応答と共に第２の呼制御装置１０ｂのＩＰアドレスを受信した通信端末２０ｂの通信インタフェース２１は、このＩＰアドレスを記憶部２５に記憶し（ステップ４６）、その後、この運用系になった第２の呼制御装置１０ｂとの間で、呼制御通信のための接続処理を行う（ステップ４７）。
【００６１】
運用系に切り替わった第２の呼制御装置１０ｂの監視部１３ｂは、第１の呼制御装置１０ａが運用系であったときと同様に、定期的に、自身の呼制御部１２ｂ及び通信インタフェース１１ｂを監視し、呼制御可能な状態であることを確かめて、動作可通知を拠点Ａの第１の呼制御装置１０ａへ送信すると共に（ステップ５２）、拠点Ｂの各通信端末２０ｂに動作確認要求を送信する（ステップ５０ｂ）。この動作確認要求に対して、拠点Ｂの各通信端末２０ｂは、動作確認応答を返す（ステップ５１ｂ）。
【００６２】
以上のように、中継回線に障害が発生した場合には、拠点Ａの第１の呼制御装置１０ａは、運用系を維持するものの、拠点Ａの各通信端末２０ａに対してのみ呼制御装置として機能し、当初、予備系であった拠点Ｂの第２の呼制御装置１０ｂは、運用系に切り替わるものの、拠点Ｂの各通信端末２０ｂに対してのみ呼制御装置として機能する。つまり、中継回線に障害が発生している際中は、各拠点の呼制御装置が、それぞれの拠点の運用系呼制御装置となる。
【００６３】
次に、図７を用いて、中継回線の障害が復旧した場合の動作について、説明する。
【００６４】
中継回線の障害が復旧すると（ステップ５５）、拠点Ｂの第２の呼制御装置１０ｂからの動作可通知が拠点Ａの第１の呼制御装置１０ａへ到達するようになる（ステップ５６）。同様に、拠点Ａの第１の呼制御装置１０ａからの動作可通知が拠点Ｂの第２の呼制御装置１０ｂへ到達するようになる（ステップ５７）。
【００６５】
この結果、拠点Ｂの第２の呼制御装置１０ｂの監視部１３ｂは、当初、運用系であった拠点Ａの第１の呼制御装置１０ａの障害が復旧したと認識して、運用状態であった呼制御部１２ｂを待機状態にして、運用系であった第２の呼制御装置１０ｂを予備系に切り替える（ステップ５８）。そして、予備系として、拠点Ａの第１の呼制御装置１０ａに動作可通知を送信する（ステップ６０）。なお、拠点Ｂの第２の呼制御装置１０ｂの監視部１３ｂは、予備系に切り替わった時点から、拠点Ｂの各通信端末２０ｂへ動作確認要求を送信しなくなる。
【００６６】
また、拠点Ａの第１の呼制御装置１０ａの監視部１３ｂは、障害発生中も定期的に送っていた動作可通知を拠点Ｂの第２の呼制御装置１０ｂへ送信すると共に（ステップ５７）、拠点Ｂの第２の呼制御装置１０ｂからの動作可通知により（ステップ６０）、この第２の呼制御装置１０ｂが復旧したと認識して、第１の呼制御装置１０ａの設定情報管理部１４ａは、呼サービス設定情報を拠点Ｂの第２の呼制御装置１０ｂへ送信し始める（ステップ６１）。
【００６７】
一方、拠点Ｂの通信端末２０ｂの監視部２５は、今まで運用系であった第２の呼制御装置１０ｂから、一定期間、動作確認要求が送信されてこないことから（ステップ５０ｂ）、拠点Ｂの第２の呼制御装置１０ｂに障害が発生したと認識して、この第２の呼制御装置１０ｂとの接続を解放する（ステップ６２）。
【００６８】
そして、拠点Ｂの各通信端末２０ｂの監視部２５は、呼制御可能な呼制御装置を検索するため、端末自身のＩＰアドレスと共に、検索応答要求をマルチキャストで送信する（ステップ６３）。この検索応答要求に対して、再び、運用系になった第１の呼制御装置１０ａの監視部１３ａは、検索応答要求のあった拠点Ｂの通信端末２０ｂに対して、検索応答と共に第１の呼制御装置１０ａのＩＰアドレスを送信して、現在運用状態にある呼制御装置１０ａを認識させると共に（ステップ６４）、検索応答要求のあった通信端末２０ｂのＩＰアドレスを記憶する（ステップ６８）。検索応答と共に第１の呼制御装置１０ａのＩＰアドレスを受信した通信端末２０ｂの通信インタフェース２１は、このＩＰアドレスを記憶し（ステップ６５）、その後、この運用系になった第１の呼制御装置１０ａとの間で、呼制御通信のための接続処理を行う（ステップ６７）。
【００６９】
以降、図７に示す中継回線に障害が発生する前と同様に、拠点Ａの第１の呼制御装置１０ａは、拠点Ａ，Ｂの通信端末２０ａ，２０ｂに対して、動作確認要求を送信し（ステップ３５ａ，３５ｂ）、拠点Ａ，Ｂの通信端末２０ａ，２０ｂから動作確認応答を受信する（ステップ３６ａ，３６ｂ）。さらに、第１の呼制御装置１０ａは、再び予備系になった第２の呼制御装置１０ｂに動作可通知及び呼サービス設定情報を送信し（ステップ３１，３３）、この第２の呼制御装置１０ｂから動作可通知を受信する（ステップ３２）。
【００７０】
以上のように、本実施形態では、二つの拠点間の中継回線に障害が生じても、各拠点に設けられている呼制御装置が運用系になり、各拠点内での各通信端末相互の呼制御を行うので、中継回線障害による被害を最小限に抑えることができる。また、中継回線に障害が生じて、予備系であった呼制御装置が運用系に切り替わっても、当初から運用系であった呼制御装置から、呼サービス設定情報を取得しているので、各拠点で同じサービスを提供することができる。
【００７１】
なお、本実施形態で、当初、運用系である第１の呼制御装置１０ａに障害が発生した場合には、第１の実施形態と同様に、第２の呼制御装置１０ｂが運用系になり、この第２の呼制御装置１０ｂが各拠点Ａ，Ｂの各通信端末２０ａ，２０ｂの呼制御を行うことになる。従って、本実施形態でも、第１の実施形態と同様の効果を得ることができる。
【００７２】
また、本実施形態では、二つの拠点Ａ，Ｂにそれぞれ呼制御装置１０ａ，１０ｂを設けた例を示したが、本発明は、これに限定されるものではなく、三つ以上の拠点にそれぞれ呼制御装置を設けてもよい。この場合、複数の拠点の各予備系呼制御装置に関して、予め優先順位を定めておき、一つの拠点の運用系呼制御装置に障害が発生すると、この優先順位に従って、複数の予備系のうちの一つが運用系になるようにするとよい。
【００７３】
【発明の効果】
本発明によれば、２台の呼制御装置のうち、運用状態の呼制御装置に障害が生じても、待機状態の呼制御装置が運用状態となって、各通信端末相互の呼制御を行うので、呼制御障害による被害を最小限に抑えることができる。また、２台の呼制御装置相互間で、呼制御可能な状態であるか否かを通信で確認しあっているので、２台の呼制御装置の他に別途、これらを管理する呼制御管理装置が不要になり、装置コストを抑えることができる。
【図面の簡単な説明】
【図１】本発明に係る第１の実施形態における通信システムの機能ブロック図である。
【図２】本発明に係る第１の実施形態における通信システムのシーケンス図である。
【図３】本発明に係る第１の実施形態における通信端末の立ち上がり時からの動作を示すフローチャートである。
【図４】本発明に係る第１の実施形態における呼制御装置の各状態での動作を示す説明図である。
【図５】本発明に係る第２の実施形態における通信システムの回路ブロック図である。
【図６】本発明に係る第２の実施形態における通信システムのシーケンス図（その１）である。
【図７】本発明に係る第２の実施形態における通信システムのシーケンス図（その２）である。
【図８】従来の通信システムの機能ブロック図である。
【符号の説明】
１…ＷＡＮ、２ａ，２ｂ…中継装置、３，１０ａ，１０ｂ…呼制御装置、９，９ａ，９ｂ…ＬＡＮ回線、１１ａ，１１ｂ…通信インタフェース、１２ａ，１２ｂ…呼制御部、１３ａ，１３ｂ…監視部、１４ａ，１４ｂ…設定情報管理部、１５ａ，１５ｂ…記憶部、２０，２０ａ，２０ｂ，２８，２９，２９ａ，２９ｂ…通信端末、２１…通信インタフェース、２２…符号化・複合化部、２５…監視部、２６…記憶部。
Claims (14)
- ＩＰパケット通信を行う複数の通信端末相互間の呼制御を行う呼制御装置において、
複数の前記通信端末及び他の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記通信端末の呼制御を行う呼制御手段と、
前記通信手段を介して、前記他の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が一定時間以上受信できない場合、該他の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御手段を起動させて、運用状態にする監視手段と、
を備えていることを特徴とする呼制御装置。 - 請求項１に記載の呼制御装置において、
複数の前記端末の呼サービスに関する設定情報であって、前記呼制御手段が呼制御を行う際に用いる呼サービス設定情報を、前記待機状態において、前記通信手段を介して、前記他の呼制御装置から取得し管理する設定情報管理手段を備えている、
ことを特徴とする呼制御装置。 - 請求項２に記載の呼制御装置において、
前記呼制御手段が運用状態になると、
前記設定情報管理手段は、前記通信手段を介して、該設定情報管理手段が管理している呼サービス設定情報を前記他の呼制御装置へ送り、
前記監視手段は、前記呼制御手段による呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に、前記一定時間毎に前記他の呼制御装置へ動作可通知を送り、前記呼制御手段による呼制御に障害が発生していることを認識すると、該他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手段を運用状態から待機状態にする、
ことを特徴とする呼制御装置。 - ＩＰパケット通信を行う複数の通信端末相互間の呼制御を行う呼制御装置において、
複数の前記通信端末及び他の呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記通信端末の呼制御を行う呼制御手段と、
前記呼制御手段による呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に前記他の呼制御装置へ動作可通知を送り、前記呼制御手段による呼制御に障害が発生していることを認識すると、前記他の呼制御装置への前記動作可通知の送信を中止して、前記呼制御手段を運用状態から待機状態にする監視手段と、
を備えていることを特徴とする呼制御装置。 - 請求項４に記載の呼制御装置において、
複数の前記端末の呼サービスに関する設定情報であって、前記呼制御手段が呼制御を行う際に用いる呼サービス設定情報を管理すると共に、前記運用状態において、前記通信手段を介して、一定時間毎に該呼サービス設定情報を前記他の呼制御装置へ送る設定情報管理手段を備えている、
ことを特徴とする呼制御装置。 - 請求項１から５のいずれか一項に記載の呼制御装置において、
前記呼制御手段が運用状態である際には、前記監視手段は、前記通信手段を介して、複数の前記通信端末に対して、呼制御可能な状態である旨を通知する、
ことを特徴とする呼制御装置。 - 請求項１から６のいずれか一項に記載の呼制御装置において、
前記呼制御手段が運用状態である際、前記監視手段は、複数の前記通信端末のうちいずれかから、現時点で呼制御可能な運用状態である呼制御装置に対しての応答要求を、前記通信手段を介して受信すると、該応答要求を送信してきた前記通信端末に対して、呼制御装置のＩＰアドレスを送信する、
ことを特徴とする呼制御装置。 - 他の通信端末とＩＰパケット通信を行うために、複数の呼制御装置のうちの一つに呼制御される通信端末であって、
前記他の通信端末及び複数の前記呼制御装置との間でＩＰパケット通信を行う通信手段と、
複数の前記呼制御装置のうちの一の呼制御装置が呼制御可能な運用状態で、他の呼制御装置が待機状態であるときに、前記通信手段を介して、該一の呼制御装置から呼制御可能な運用状態である旨を一定時間毎に受信して、該運用状態の該一の呼制御装置を監視し、該呼制御可能な運用状態である旨を該一定時間以上受信できない場合には、該一の呼制御装置による呼制御に障害が発生していると認識して、該一の呼制御装置に対する呼制御接続を該通信手段に解放さる監視手段と、
を備えていることを特徴とする通信端末。 - 請求項８に記載の通信端末において、
前記監視手段は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できず、前記一の呼制御装置に対する呼制御接続を解放させた後、複数の前記呼制御装置のうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を、前記通信手段を介して、要求する、
ことを特徴とする通信端末。 - 請求項４及び５のいずれか一項に記載の呼制御装置（以下、第１の呼制御装置とする）と、
請求項１から３のいずれか一項に記載の呼制御装置（以下、第２の呼制御装置とする）と、
請求項８に記載の複数の通信端末と、
を備え、
前記第１の呼制御装置と前記第２の呼制御装置と複数の通信端末のそれぞれとは、互いに回線で接続され、
複数の通信端末のうち、一の通信端末と他の通信端末との間で通信する際には、前記第１の呼制御装置の前記呼制御手段と前記第２の呼制御装置の呼制御手段とのうち、前記運用状態の呼制御手段により、呼制御が行われる、
ことを特徴とする通信システム。 - 請求項４及び５のいずれか一項に記載の呼制御装置（以下、第１の呼制御装置とする）と、
前記第１の呼制御装置に対して、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ ｎｅｔｗｏｒｋ）回線を介して接続されている複数の、請求項８に記載の通信端末（以下、第１の通信端末とする）と、
前記第１の呼制御装置に対して、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ ｎｅｔｗｏｒｋ）を介して接続されている請求項１から３のいずれか一項に記載の呼制御装置（以下、第２の呼制御装置とする）と、
前記第２の呼制御装置に対して、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ ｎｅｔｗｏｒｋ）回線を介して接続されている複数の、請求項８に記載の通信端末（以下、第２の通信端末とする）と、
を備え、
複数の前記第１の通信端末と複数の前記第２の通信端末とのうちのいずれか二つの通信端末相互間で通信する際には、前記第１の呼制御装置の前記呼制御手段と前記第２の呼制御装置の呼制御手段とのうち、前記運用状態の呼制御手段により、呼制御が行われる、
ことを特徴とする通信システム。 - 請求項１０及び１１のいずれか一項に記載の通信システムにおいて、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、前記呼制御手段が運用状態である呼制御装置の前記監視手段は、前記通信手段を介して、複数の前記通信端末に対して、呼制御可能な状態である旨を一定時間毎に通知し、
複数の前記通信端末の前記監視手段は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できないときには、前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を要求し、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置の前記監視手段は、複数の前記通信端末からの前記応答要求に対して、該応答要求を送信してきた前記通信端末に対して、該呼制御装置のＩＰアドレスを送信する、
ことを特徴とする通信システム。 - ＩＰパケット通信を行う複数の通信端末相互間の呼制御障害の対策方法において、
複数の通信端末とＩＰパケット通信が可能な第１の呼制御装置及び第二の呼制御装置を設け、
前記第１の呼制御装置は、
複数の前記通信端末の呼制御を行う呼制御工程と、
前記呼制御工程での呼制御に障害が発生しているか否かを監視し、障害が発生しておらず呼制御可能状態である際に前記第２の呼制御装置へ一定時間毎に動作可通知を送り、前記呼制御工程での呼制御に障害が発生していることを認識すると、該第２の呼制御装置への前記動作可通知の送信を中止して、前記呼制御工程を運用状態から待機状態にする監視工程と、
を実行し、
前記第２の呼制御装置は、
複数の前記通信端末の呼制御を行う呼制御工程と、
前記第１の呼制御装置から呼制御可能状態であることを示す動作可通知を受け付け、該動作可通知が前記一定時間以上受信できない場合、該第１の呼制御装置が呼制御不可状態であると判断し、待機状態の前記呼制御工程を起動させて、運用状態にする監視工程と、
を実行する、
ことを特徴とする呼制御障害の対策方法。 - 請求項１３に記載の呼制御障害の対策方法において、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、前記呼制御工程が運用状態である呼制御装置の前記監視工程では、複数の前記通信端末に対して、呼制御可能な状態である旨を一定時間毎に通知し、
複数の前記通信端末は、前記呼制御可能な運用状態である旨を前記一定時間以上受信できないときには、前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置からの応答を要求し、
前記第１の呼制御装置と前記第２の呼制御装置とのうち、現時点で該呼制御可能な運用状態である呼制御装置の監視工程では、複数の前記通信端末からの前記応答要求に対して、該応答要求を送信してきた前記通信端末に対して、該呼制御装置のＩＰアドレスを送信する、
ことを特徴とする呼制御障害の対策方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002226306A JP4038091B2 (ja) | 2002-08-02 | 2002-08-02 | 通信端末、これを含む通信システム、及び呼制御障害の対策方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002226306A JP4038091B2 (ja) | 2002-08-02 | 2002-08-02 | 通信端末、これを含む通信システム、及び呼制御障害の対策方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007257271A Division JP4564523B2 (ja) | 2007-10-01 | 2007-10-01 | 通信システム及び通信端末 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004072256A true JP2004072256A (ja) | 2004-03-04 |
| JP4038091B2 JP4038091B2 (ja) | 2008-01-23 |
Family
ID=32013691
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002226306A Expired - Fee Related JP4038091B2 (ja) | 2002-08-02 | 2002-08-02 | 通信端末、これを含む通信システム、及び呼制御障害の対策方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4038091B2 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007004351A1 (ja) * | 2005-06-30 | 2007-01-11 | Oki Electric Industry Co., Ltd. | 音声処理周辺装置及びｉｐ電話システム |
| JP2007124231A (ja) * | 2005-10-27 | 2007-05-17 | Oki Electric Ind Co Ltd | 分散制御通信システムおよび方法 |
| JP2008244570A (ja) * | 2007-03-26 | 2008-10-09 | Hitachi Communication Technologies Ltd | 電話システムおよび運用情報の同期方法 |
| JP2011045124A (ja) * | 2010-10-14 | 2011-03-03 | Oki Electric Industry Co Ltd | 交換システムおよび交換システムの障害復旧方法 |
| JP2011151632A (ja) * | 2010-01-21 | 2011-08-04 | Nakayo Telecommun Inc | データ中継の引継方法およびデータ中継装置 |
| JP2020150498A (ja) * | 2019-03-15 | 2020-09-17 | アイコム株式会社 | 音声通信システムおよび呼制御サーバの冗長化方法 |
-
2002
- 2002-08-02 JP JP2002226306A patent/JP4038091B2/ja not_active Expired - Fee Related
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007004351A1 (ja) * | 2005-06-30 | 2007-01-11 | Oki Electric Industry Co., Ltd. | 音声処理周辺装置及びｉｐ電話システム |
| JP2007013604A (ja) * | 2005-06-30 | 2007-01-18 | Oki Electric Ind Co Ltd | 音声処理周辺装置及びｉｐ電話システム |
| US8867527B2 (en) | 2005-06-30 | 2014-10-21 | Oki Electric Industry Co., Ltd. | Speech processing peripheral device and IP telephone system |
| JP2007124231A (ja) * | 2005-10-27 | 2007-05-17 | Oki Electric Ind Co Ltd | 分散制御通信システムおよび方法 |
| JP4570551B2 (ja) * | 2005-10-27 | 2010-10-27 | 沖電気工業株式会社 | 分散制御通信システムおよび方法 |
| JP2008244570A (ja) * | 2007-03-26 | 2008-10-09 | Hitachi Communication Technologies Ltd | 電話システムおよび運用情報の同期方法 |
| JP2011151632A (ja) * | 2010-01-21 | 2011-08-04 | Nakayo Telecommun Inc | データ中継の引継方法およびデータ中継装置 |
| JP2011045124A (ja) * | 2010-10-14 | 2011-03-03 | Oki Electric Industry Co Ltd | 交換システムおよび交換システムの障害復旧方法 |
| JP2020150498A (ja) * | 2019-03-15 | 2020-09-17 | アイコム株式会社 | 音声通信システムおよび呼制御サーバの冗長化方法 |
| WO2020189003A1 (ja) * | 2019-03-15 | 2020-09-24 | アイコム株式会社 | 音声通信システムおよび呼制御サーバの冗長化方法 |
| CN113519149A (zh) * | 2019-03-15 | 2021-10-19 | 艾可慕株式会社 | 声音通信系统以及呼叫控制服务器的冗余化方法 |
| EP3941029A4 (en) * | 2019-03-15 | 2022-12-28 | Icom Incorporated | VOICE COMMUNICATION SYSTEM AND REDUNDANCY METHOD FOR CALL CONTROL SERVERS |
| US11777999B2 (en) | 2019-03-15 | 2023-10-03 | Icom Incorporated | Voice communication system and redundancy method for call control server |
| JP7381834B2 (ja) | 2019-03-15 | 2023-11-16 | アイコム株式会社 | 音声通信システムおよび呼制御サーバの冗長化方法 |
| CN113519149B (zh) * | 2019-03-15 | 2024-03-08 | 艾可慕株式会社 | 声音通信系统以及呼叫控制服务器的冗余化方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4038091B2 (ja) | 2008-01-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004186766A (ja) | バックアップ制御装置および制御装置バックアップ方法 | |
| CN101155073B (zh) | 计算机系统及切换到后备系统的方法 | |
| JPH1132006A (ja) | 移動体通信システム | |
| JP2010124421A (ja) | 電話システムとそのゲートウェイ、および冗長切替方法 | |
| JP4038091B2 (ja) | 通信端末、これを含む通信システム、及び呼制御障害の対策方法 | |
| WO2009089787A1 (fr) | Procédé, système et dispositif permettant à une centrale d'appels de traiter des appels de clients | |
| JP4564523B2 (ja) | 通信システム及び通信端末 | |
| JP2009218727A (ja) | 通信管理システム、通信管理方法及び通信装置 | |
| JP3964589B2 (ja) | 情報通信システムおよび呼制御装置の接続方法 | |
| JP2008187621A (ja) | 電話システム及びサーバ装置 | |
| JP5135290B2 (ja) | 一斉指令放送を受信するｉｐ電話機及びｉｐ通信指令システム | |
| KR100723698B1 (ko) | 이동통신 교환기에서 데이터 경로의 장애를 방지하는 방법 | |
| JP2605635B2 (ja) | 移動通信システムおよびその制御方法 | |
| JP5248415B2 (ja) | 無線ｌａｎ通信システム | |
| JP3016458B2 (ja) | 通信システムにおける着信端末状態制御方法 | |
| JP3811019B2 (ja) | 通信システムにおける通信機器登録方法及び通信システム | |
| JP2005094715A (ja) | 音声ゲートウェイ装置 | |
| JP4017298B2 (ja) | 構内電話交換機システム | |
| JP2006303779A (ja) | 制御装置及び処理装置 | |
| JP2005204454A (ja) | 電源遠隔操作システム、電源制御装置及び電源遠隔操作方法 | |
| JP2023125007A (ja) | 通信装置及び通信方法 | |
| JP2000286882A (ja) | マルチメディア情報通信システム | |
| JP3623460B2 (ja) | コンパクト制御局間のイーサネットを利用したデータ伝送方法 | |
| JP2022131415A (ja) | 通信システム、通信システムのサーバ保守動作方法、サーバ、及びサーバの保守動作方法 | |
| WO2018055694A1 (ja) | エレベータシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050602 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20050602 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20061201 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070613 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070731 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071001 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071023 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071102 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101109 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101109 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101109 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111109 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111109 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121109 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121109 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131109 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |