JP4270020B2

JP4270020B2 - 構内交換システム、ゲートウエイ装置、構内交換方法、および構内交換プログラム

Info

Publication number: JP4270020B2
Application number: JP2004133639A
Authority: JP
Inventors: 典光高橋; 雅士内苑; 竜夫雲田
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2004-04-28
Filing date: 2004-04-28
Publication date: 2009-05-27
Anticipated expiration: 2024-04-28
Also published as: JP2005318265A

Description

本発明は構内交換システム、ゲートウエイ装置、構内交換方法、および構内交換プログラムに関し、例えば、ＶｏＩＰ（VoiceOver IP）に対応していない一般電話機を収容してＶｏＩＰ通信を可能にするためのＰＢＸ（構内交換機）であるＩＰ−ＰＢＸなどに適用して好適なものである。

従来のＩＰ−ＰＢＸシステムのなかには、ＩＰＬＴＵ（インターネット・プロトコル・ライン・トランク・ユニット（ＶｏＩＰ対応回線収容装置））を有するものがある。

ＩＰＬＴＵはＶｏＩＰゲートウエイに相当する構成要素であり、ＶｏＩＰ機能を持たない一般電話機を収容するとともにＬＡＮインタフェースを備えている。ＩＰＬＴＵは自身では、ＩＰアドレスと電話番号の対応など、ＶｏＩＰ通信に必須の情報（局データ）を備えていないため、呼制御時には、その局データを蓄積した呼処理装置と通信する必要がある。

具体的には、ある企業がＩＰ網によって接続された複数の拠点を持ち、そのうちの１つの拠点（大規模拠点）が本社に、他の拠点（小規模拠点）が各支社に相当するケースの場合、ＩＰＬＴＵを支社の拠点に設置し、前記呼処理装置を含むＩＰ−ＰＢＸ本体は本社の拠点に設置しておく構成を取る。

この構成において、支社の拠点内に配置された一般電話機Ａから着信先の電話番号ＮＢ１を指定して発呼する場合などには、その一般電話機Ａを収容したＩＰＬＴＵは、当該電話番号ＮＢ１に対応するＩＰアドレスをＩＰ網経由で本社の前記呼処理装置に問い合わせることになる。ＩＰ網上で通信相手を特定する唯一の識別子はＩＰアドレスであり、ＩＰ網を経由して音声通話などを行うには、通信相手のＩＰアドレスを知ることが不可欠だからである。

前記構成を取ることにより、各支社の拠点にはＩＰＬＴＵを設置するだけで内線電話網を構築できるため、すべての拠点にＩＰ−ＰＢＸ本体を設置する場合に比べ、各支社の拠点に設置する装置の規模が小さくなり、全体としてコストを低減できる。また、支社の拠点で一般電話機を用いるユーザでも、本社のユーザとほぼ同様なサービスを利用することができる。

しかしながら上述した構成の場合、例えばＩＰ網に障害が発生したり、ＩＰ−ＰＢＸ本体に障害が発生すること等により、支社の拠点に設置したＩＰＬＴＵと本社の拠点に設置したＩＰ−ＰＢＸ本体の呼処理装置が通信不能となると、支社の拠点に設置したＩＰＬＴＵに収容されている一般電話機のユーザは、他拠点内の電話機（一般電話機またはＩＰ電話機）のユーザだけでなく、自拠点内の電話機（一般電話機またはＩＰ電話機）のユーザとも通話することができなくなるため、可用性が低いといえる。

かかる課題を解決するために、第１の本発明は、音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムにおいて、（１）前記複数の拠点のうち一部の拠点に設置され、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理するメイン呼制御対応部と、（２）前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点に設置され、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理するサブ呼制御対応部と、（３）前記複数の拠点のうち、前記音声通信対応端末を有する拠点に設置され、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うゲートウエイ部とを備え、（４）前記メイン呼制御対応部は、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応部に変更内容情報を送り、（５）前記サブ呼制御対応部は、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更し、（６）前記各拠点のうちメイン呼制御対応部を持たない拠点内に設置された前記ゲートウエイ部は、少なくとも前記メイン呼制御対応部との通信が不能となったことを認識すると、自拠点内の前記サブ呼制御対応部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援することを特徴とする。

また、第２の本発明は、音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムの構成要素であり、前記複数の拠点のうち、前記音声通信対応端末を有する拠点に設置され、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うゲートウエイ装置において、（１）前記構内交換システムは、前記複数の拠点のうち一部の拠点に設置され、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理するメイン呼制御対応部と、前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点に設置され、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理するサブ呼制御対応部とを含み、前記メイン呼制御対応部は、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応部に変更内容情報を送り、前記サブ呼制御対応部は、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更するものであり、（２）前記メイン呼制御対応部との通信の可否を判定する通信可否判定部と、（３）当該通信可否判定部がメイン呼制御対応部との通信が不能であると判定した場合、当該ゲートウエイ装置が設けられている拠点内の前記サブ呼制御対応部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援する呼制御選択部とを備えることを特徴とする。

さらに、第３の本発明は、音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムが実行する構内交換方法において、（１）前記複数の拠点のうち一部の拠点には、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理するメイン呼制御対応部を設置し、（２）前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点には、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理するサブ呼制御対応部を設置し、（３）前記複数の拠点のうち、前記音声通信対応端末を有する拠点には、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うゲートウエイ部を設置しておき、（４）前記メイン呼制御対応部は、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応部に変更内容情報を送り、（５）前記サブ呼制御対応部は、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更し、（６）前記各拠点のうちメイン呼制御対応部を持たない拠点内に設置された前記ゲートウエイ部は、少なくとも前記メイン呼制御対応部との通信が不能となったことを認識すると、自拠点内の前記サブ呼制御対応部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援することを特徴とする。

さらにまた、第４の本発明は、音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムを構成する各拠点に分散配置されたコンピュータを機能させる構内交換プログラムにおいて、（１）前記複数の拠点のうち一部の拠点に配置されたコンピュータを、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理すると共に、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応機能部に変更内容情報を送るメイン呼制御対応機能部として機能させ、（２）前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点に配置されたコンピュータを、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理すると共に、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更するサブ呼制御対応機能部として機能させ、（３）前記複数の拠点のうち、前記音声通信対応端末を有する拠点に配置されたコンピュータを、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うものであって、少なくとも前記メイン呼制御対応機能との通信が不能となったことを認識すると、自拠点内の前記サブ呼制御対応機能部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援するゲートウエイ機能部として機能させることを特徴とする。

本発明によれば、可用性を高めることができる。

（Ａ）実施形態
以下、本発明にかかる構内交換システム、ゲートウエイ装置、構内交換方法、および構内交換プログラムをＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。

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

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

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

個々の拠点ＳＴ１〜ＳＴ４はそれぞれＬＡＮ（ローカル・エリア・ネットワーク）を構成しているが、拠点ＳＴ１はある企業の本社に構成されたＬＡＮに対応し、拠点ＳＴ２〜ＳＴ４はその企業の各支社に構成されたＬＡＮに対応する。

拠点ＳＴ１内には、図１に示すように、ルータ１２と、本体呼処理装置１３と、ＩＰＬＴＵ１４と、これらを接続する伝送路ＰＲ１が設けられている。

基本的に、すでに説明した従来のＩＰＬＴＵと同じＩＰＬＴＵである当該ＩＰＬＴＵ１４には、ＶｏＩＰ対応機能を搭載していない一般電話機１５，１６が収容されている。

ＩＰＬＴＵ１４の局番はＮＢ１４であり、一般電話機１５の内線番号はＮＢ１５，一般電話機１６の内線番号はＮＢ１６である。外部からこれらの一般電話機に着信しようとする場合、局番＋内線番号をダイヤルすることになる。例えば、一般電話機２３から一般電話機１５に着信するには、一般電話機２３のユーザＵ３は電話番号「ＮＢ１４＋ＮＢ１５」をダイヤルすることになる。

ここで、一般電話機１５を指定する電話番号「ＮＢ１４＋ＮＢ１５」にはＩＰアドレスＩＰＡ１５が対応し、一般電話機１６を指定する電話番号「ＮＢ１４＋ＮＢ１６」にはＩＰアドレスＩＰＡ１６が対応するものとする。

一般電話機１５はユーザＵ５によって利用され、一般電話機１６はユーザＵ６によって利用される。

本体呼処理装置１３は、前記ＩＰ−ＰＢＸ本体に含まれる呼処理装置であり、局データＦＤ１を蓄積している。

局データはＶｏＩＰ通信に必須の情報であり、ＶｏＩＰ通信システム１０内の番号計画を反映した情報が含まれている。各一般電話機のＩＰアドレスと電話番号（局番＋内線番号）の対応なども、このような情報の１つである。本体呼処理装置１３の管理範囲はＶｏＩＰ通信システム１０全体であるので、当該局データＦＤ１には拠点ＳＴ１に含まれる一般電話機（例えば、１５，１６）だけでなく、他の拠点ＳＴ２〜ＳＴ４に含まれる一般電話機（例えば、２３，２４など）に関する情報も含まれる。

なお、実装上、ＩＰＬＴＵには、１つのＩＰアドレスだけを付与する構成と、当該ＩＰＬＴＵが収容している一般電話機の数と同数のＩＰアドレスを付与する構成があり得ると考えられるが、ここでは、収容している一般電話機の数と同数のＩＰアドレスを付与する構成を前提とする。

また、図１上は別個のものとして図示しているが、当該本体呼処理装置１３と前記ＩＰＬＴＵ１４は物理的に一体の装置であってよいことは当然である。

拠点ＳＴ１内でも、少なくとも伝送路ＰＲ１に接続された部分では、ネットワーク層のプロトコルとしてＩＰプロトコルが使用される。したがって伝送路ＰＲ１に接続されている本体呼処理装置１３自体にもＩＰアドレスが割当てられている。本体呼処理装置１３のＩＰアドレスは、ＩＰＡ１３である。

ルータ１２は、伝送路ＰＲ１とＩＰ網１１を接続し、ネットワーク層で中継処理を行う中継装置である。

一方、各支社にあたる各拠点ＳＴ２〜ＳＴ４の内部構成はすべて実質的に同じであってよいため、図１では拠点ＳＴ２の内部構成のみを図示している。

当該拠点ＳＴ２は、ルータ２０と、遠隔呼処理装置２１と、ＩＰＬＴＵ２２と、一般電話機２３，２４と、伝送路ＰＲ２を備えている。

このうち伝送路ＰＲ２は前記伝送路ＰＲ１に対応し、ルータ２０は前記ルータ１２に対応し、ＩＰＬＴＵ２２は前記ＩＰＬＴＵ１４に対応し、一般電話機２３，２４は前記一般電話機１５，１６に対応し、遠隔呼処理装置２１は前記本体呼処理装置１３に対応するので、その詳しい説明は省略する。

ただし当該遠隔呼処理装置２１が蓄積する局データＦＤ２は、前記局データＦＤ１の一部にあたるため、局データＦＤ１に比べて情報の種類や量が少ない。これは、前記本体呼処理装置１３の管理範囲がＶｏＩＰ通信システム１０全体（拠点ＳＴ２もその一部である）であるのに対し、遠隔呼処理装置２１の管理範囲が拠点ＳＴ２の内部に限定されているからである。

局データＦＤ２が局データＦＤ１に比べて情報の種類や量が少ないことは、遠隔呼処理装置２１が、本体呼処理装置１３に比べて処理する通信装置（例えば、一般電話機やＩＰＬＴＵ）の数も少なくてよいことを意味する。したがって遠隔呼処理装置２１は本体呼処理装置１３よりも小型で安価な装置として構成することが可能である。

前記ＩＰＬＴＵ２２の局番はＮＢ２２で、一般電話機２３の内線番号はＮＢ２３、一般電話機２４の内線番号はＮＢ２４である。

ここで、一般電話機２３を指定する電話番号「ＮＢ２２＋ＮＢ２３」にはＩＰアドレスＩＰＡ２３が対応し、一般電話機２４を指定する電話番号「ＮＢ２２＋ＮＢ２４」にはＩＰアドレスＩＰＡ２４が対応するものとする。

さらに、遠隔呼処理装置２１のＩＰアドレスは、ＩＰＡ２１である。

ＩＰＬＴＵ２２は基本的に前記ＩＰＬＴＵ１４と同様な中継装置であるが、本実施形態に特徴的な機能も備えている。ＩＰＬＴＵ２２の内部構成例を図２に示す。

（Ａ−１−１）ＩＰＬＴＵの内部構成例
図２において、当該ＩＰＬＴＵ２２は、通信部３０，３１と、制御部３２と、記憶部３３と、障害復旧検知部３４と、本体接続可否判定部３５と、接続先切替部３６とを備えている。

このうち通信部３０は前記伝送路ＰＲ２に接続された部分で、ＩＰパケットの送信や受信を実行する。

他方の通信部３１は、一般電話機２３や２４に接続された部分で、これら一般電話機（例えば、２４）とのあいだで加入電話網（ＰＳＴＮ）の加入者線と同様な通信を実行する。

制御部３２は、ハードウエア的には当該ＩＰＬＴＵ２２のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）などの各種プログラムに相当する部分である。ＶｏＩＰゲートウエイの機能もこの制御部３２に対応する。

前記記憶部３３はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）などの揮発性記憶手段や、ＲＯＭ、ＥＥＰＲＯＭ、ハードディスクなどの不揮発性記憶手段によって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。ＯＳなどのプログラムファイルもこのようなファイルの一例であるから、これらのファイルも、その物理的な実体はこの記憶部３３に位置する。

当該記憶部３３にはまた、当該ＩＰＬＴＵ２２自身が収容している一般電話機２３，２４のＩＰアドレスであるＩＰＡ２３，ＩＰＡ２４と、前記本体呼処理装置１３のＩＰアドレスであるＩＰＡ１３と、前記遠隔呼処理装置２１のＩＰアドレスであるＩＰＡ２１が記憶されている。

このうち当該ＩＰＬＴＵ２２自身が収容している一般電話機２３，２４のＩＰアドレスであるＩＰＡ２３，ＩＰＡ２４を記憶する理由は、ＩＰＬＴＵ２２が収容している一般電話機（例えば、２４）から送信された音声情報に由来する音声データを収容したＩＰパケットを送信する場合などにＩＰヘッダにそのＩＰアドレスを送信元ＩＰアドレスとして記述するとともに、伝送路ＰＲ２上から、収容している一般電話機（例えば、２４）宛てのＩＰパケットを受信するためである。また、伝送路ＰＲ２経由で受信されたＩＰパケットが、２３，２４いずれの一般電話機宛てであるかを識別するためにも、当該ＩＰＡ２３，ＩＰＡ２４が利用され得る。

さらに、前記本体呼処理装置１３のＩＰアドレスであるＩＰＡ１３を記憶する理由は、呼制御時に使用する呼制御メッセージなどを収容したＩＰパケットを本体呼処理装置１３へ届けるためである。

また、前記遠隔呼処理装置２１のＩＰアドレスであるＩＰＡ２１を記憶する理由は、例えばＩＰ網１１に障害が発生したり、本体呼処理装置１３に障害が発生すること等により、当該ＩＰＬＴＵ２２と本体呼処理装置１３の通信が不能になったとき、局データ（ＦＤ１またはＦＤ２）を提供する呼処理装置として、それまで用いていた本体呼処理装置１３ではなく、遠隔呼処理装置２１を用いるためである。

本実施形態において、ＩＰＬＴＵ２２は、可能な限り本体呼処理装置１３を利用し、本体呼処理装置１３との通信が不能となった場合にのみ、遠隔呼処理装置２１を利用する。

本体呼処理装置１３との通信が不能となったか否かを判定するのが、前記本体接続可否判定部３５である。当該本体接続可否判定部３５は、本体呼処理装置１３から届けられる後述の状態確認要求メッセージの受信状況に応じて、通信不能であるか否かを判定する。

前記障害復旧検知部３４は、障害の復旧を検知する部分である。すなわち、障害によって、いったん不能となった本体呼処理装置１３との通信が障害復旧により再開できるようになったことが、当該障害復旧検知部３４によって検知される。

この検知の実現法には様々なものがあり得るが、ここでは、本体呼処理装置１３からＩＰＬＴＵ２２宛てに送信されたパケットで届けられる接続要求メッセージが、複数回、受信されたことを検知したことをもって、障害復旧の検知とする。このパケットは、ＩＰＬＴＵ２２自体を最終的な宛先とする管理用のパケットである。このような管理用パケットを一般電話機（例えば、２４）宛てのパケット（呼制御用のパケットや音声データを収容したパケット）と識別するため、専用のＩＰアドレスを用意しておいてもよい。あるいは、レイヤ４のヘッダ（例えば、ＴＣＰヘッダやＵＤＰヘッダ）に含まれる識別子（例えば、宛先ポート番号など）等を利用して管理用パケットであることを識別すること等も可能である。

接続先切替部３６は、当該ＩＰＬＴＵ２２が局データを利用するために接続する接続先の切り替えを実行する部分である。この接続先は、本体呼処理装置１３または遠隔呼処理装置２１のいずれか選択されたほうに切り替えられる。

本実施形態で当該接続先切替部３６は、通常、接続先として本体呼処理装置１３を選択しているが、本体呼処理装置１３との通信が不能となった場合には接続先を遠隔呼処理装置２１に切り替える。また、前記障害復旧検知部３４によって障害の復旧が検知されたときには、再度、接続先の切り替えを行い、本体呼処理装置１３と接続するようになる。

以下、上記のような構成を有する本実施形態の動作について、図３、図４の動作シーケンスを参照しながら説明する。図３，図４では、各拠点ＳＴ２〜ＳＴ４のうち拠点ＳＴ２内のＩＰＬＴＵ２２に注目して動作を示している。

図３は接続先切り替え時の動作を示し、Ｓ１０〜Ｓ３７の各ステップを備えている。図４は、局データ同期のための動作を示し、Ｓ４０〜Ｓ４５の各ステップを備えている。

（Ａ−２）実施形態の動作
通常、拠点ＳＴ２内のＩＰＬＴＵ２２は拠点ＳＴ１内の本体呼処理装置１３と接続され、オンライン状態にあり（Ｓ１０）、拠点ＳＴ２内の遠隔呼処理装置２１とは接続されていない（Ｓ１１）。

この通常状態で、ＩＰＬＴＵ２２に収容されているいずれかの一般電話機（例えば、２３）のユーザＵ３がオフフック後、ダイヤルして、他の一般電話機に発呼しようとすると、当該ＩＰＬＴＵ２２は、ＩＰ網１１経由の通信により、拠点ＳＴ１内の本体呼処理装置１３の局データＦＤ１を利用して呼制御を開始する。これは、発呼先の一般電話機が拠点ＳＴ２内に存在するか否かによらない。例えば、発呼先の一般電話機が拠点ＳＴ１内の一般電話機１５である場合も、拠点ＳＴ３内のいずれかの一般電話機（図示せず）である場合も、拠点ＳＴ２内のいずれかの一般電話機（例えば、２４）である場合も、本体呼処理装置１３の局データＦＤ１を利用する。

なお、ネットワーク構成上、通話するのにＶｏＩＰ通信を用いる必要のない相手である場合、例えば、当該一般電話機２３のユーザＵ３が同じＩＰＬＴＵ２２に収容されている一般電話機２４のユーザＵ４と通話する場合には、ＩＰＬＴＵ２２の内部構造によっては局データＦＤ１を用いることなく通話できる可能性もあるが、話中などの情報も含め適切に呼処理装置（ここでは、１３）が管理できるようにするには、やはり呼制御の段階で本体呼処理装置１３と通信することが必要になる。

ステップＳ１０のように、ＩＰＬＴＵ２２が本体呼処理装置１３と接続されている通常状態では、定期的に、本体呼処理装置１３からＩＰパケットに収容された状態確認要求メッセージが送信される（Ｓ１２）。伝送路ＰＲ１，ルータ１２，ＩＰ網１１，ルータ２０、伝送路ＰＲ２の経路をこの順番に経由して届けられた当該状態確認要求メッセージを受け取ったＩＰＬＴＵ２２は、ＩＰパケットを用いて状態確認応答メッセージを返送する（Ｓ１３）。当該状態確認応答メッセージは通常、前記状態確認要求メッセージと同じ経路を逆方向に伝送されて、本体呼処理装置１３まで届けられる。

本体呼処理装置１３が状態確認要求メッセージを送信するタイミングは、必ずしも定期的なものである必要はなく、不定期的なものであってもかまわないが、いずれにしても、どのようなタイミングで届くかを、ＩＰＬＴＵ２２側でも認識していることが必要である。このように状態確認要求メッセージと状態確認応答メッセージをやり取りするのは、呼制御の段階で行われるＩＰＬＴＵ２２と本体呼処理装置１３の通信が不能となっておらず、正常に行えることを確認するためである。

前記伝送路ＰＲ１，ルータ１２，ＩＰ網１１，ルータ２０、伝送路ＰＲ２からなる経路が正常で、送信元の本体呼処理装置１３も、宛先のＩＰＬＴＵ２２も正常であれば、以上のような通常状態が継続され、ＩＰＬＴＵ２２に収容されている一般電話機（例えば、２４）からの発呼や、ＩＰＬＴＵ２２に収容されている一般電話機への着信も、本体呼処理装置１３の局データＦＤ１を利用して、随時、実行される。

ところが、前記経路、送信元、宛先のいずれか１つでも障害が発生すると、状態確認要求メッセージの受信がＩＰＬＴＵ２２で検出できなくなる。現実には、送信元である本体呼処理装置１３や宛先であるＩＰＬＴＵ２２自体の障害によって状態確認要求メッセージの受信がＩＰＬＴＵ２２に検出できなくなることも起こり得るが、ここでは、前記経路上のいずれか（例えば、ルータ１２）で障害が発生したものとする（Ｓ１５，Ｓ１６）。

この場合、本体呼処理装置１３は、状態確認要求メッセージの送信後、予め定めた時間が経過してもＩＰＬＴＵ２２からの状態確認応答メッセージが返送されてこないことから状態確認試験異常の発生を認め（Ｓ１７）、通信障害を検出し、ＩＰＬＴＵ２２との通信が不能となったことを認識する（Ｓ１８）。

一方、ＩＰＬＴＵ２２のほうでも、本来、届くはずのタイミングになっても状態確認要求メッセージが届かない場合に、状態確認試験異常の発生を認め（Ｓ１９）、通信障害を検出し、本体呼処理装置１３との通信が不能となったことを認識する（Ｓ２０）。ここで、本来、届くはずのタイミングは、最後に状態確認応答メッセージを返送してからの時間が予め定めた時間に達したタイミングとすることも望ましい。

通信不能を認識すると、ＩＰＬＴＵ２２は、自身と同じ拠点ＳＴ２内に設置されている遠隔呼処理装置２１に接続要求メッセージを送信し（Ｓ２４）、遠隔呼処理装置２１が接続許可メッセージを返送してくると（Ｓ２４）、接続先を前記本体呼処理装置１３から当該遠隔呼処理装置２１に切り替える（Ｓ２５）。

この障害発生状態では、ＩＰＬＴＵ２２に収容されている一般電話機（例えば、２３）が他の一般電話機に発呼しようとすると、呼制御の段階で、ＩＰＬＴＵ２２と遠隔呼処理装置２１が通信し遠隔呼処理装置２１に蓄積されている前記局データＦＤ２が利用される。

局データＦＤ２の内容は拠点ＳＴ２内の一般電話機に関する情報に限られるから、これによって可能な通話は、拠点ＳＴ２内の一般電話機間の通話に制限されるが、従来、まったく通話できなかったことと比べると、ＩＰＬＴＵ２２や一般電話機２３，２４の稼働率が向上する。

また、障害が発生している具体的な箇所によっては、拠点ＳＴ１内の本体呼処理装置１３との通信は不能であっても、第３の拠点（例えば、ＳＴ２）内との通信や、拠点ＳＴ１内の本体呼処理装置１３以外の通信装置との通信は実行できる可能性もある。例えば、ルータ１２に障害が発生した場合などには、拠点ＳＴ３内の一般電話機（図示せず）と拠点ＳＴ２内の一般電話機（例えば、２３）が通話できる可能性があるし、伝送路ＰＲ１のうち本体呼処理装置１３近傍の箇所に障害が発生した場合には、拠点ＳＴ１内のＩＰＬＴＵ１４に収容されている一般電話機（例えば、１５）と拠点ＳＴ２内の一般電話機（例えば、２３）が通話できる可能性がある。

ただしこのような通話を実現するには、本体呼処理装置１３が蓄積している局データＦＤ１が利用できない状況でも呼制御を実行できることが必要となる。

例えば、前記局データＦＤ２として、拠点ＳＴ２以外の範囲の情報も蓄積しておけば、前記障害発生状態において、拠点ＳＴ２内の一般電話機（例えば、２３）が他の拠点（ＳＴ１、ＳＴ３など）の一般電話機と通話できる可能性がある。

通信の不能、すなわち障害発生状態への移行を認識したあとでも、本体呼処理装置１３は繰り返し、ＩＰＬＴＵ２２宛てのＩＰパケットで接続要求メッセージを送信する（Ｓ２２，Ｓ２６）これは、障害が復旧し、通信が正常に行えるようになったとき、それを早期に認識するためである。ただし障害が復旧するまでの期間、この接続要求メッセージはＩＰＬＴＵ２２まで届かない。

前記障害発生状態となると、前記経路上で障害が発生している箇所を特定し、その障害を復旧するための処理が実行される（Ｓ２７）。このような復旧処理の開始を促すため、本体呼処理装置１３またはＩＰＬＴＵ２２が、管理者などに障害の発生を通知する機能を持つことも望ましい。

障害が復旧すると、復旧後に前記本体呼処理装置１３から送信された接続要求メッセージがＩＰＬＴＵ２２まで届くようになる（Ｓ２８，Ｓ２９）。ＩＰＬＴＵ２２はこの接続要求メッセージを受信すると（Ｓ３０）、本体呼処理装置１３との通信が可能となったことを認識するため（Ｓ３１）、再度、接続先の切り替えを行う（Ｓ３２〜Ｓ３７）。

すなわち当該ＩＰＬＴＵ２２は、そのとき接続していた遠隔呼処理装置２１との接続を切断するとともに（Ｓ３２，Ｓ３３）、本体呼処理装置１３との接続を再開し（Ｓ３４，Ｓ３６）、前記通常状態に復帰する（Ｓ３７）。

なお、上述したように、遠隔呼処理装置２１が蓄積している局データＦＤ２は本体呼処理装置１３が蓄積している局データＦＤ１の一部であるから、局データＦＤ１のうち局データＦＤ２に対応する部分が変更された場合には、その変更は局データＦＤ２の内容に反映し、ＦＤ１とＦＤ２の同期を取る必要がある。局データＦＤ１を変更するのは、例えば、各通信装置（例えば、ＩＰＬＴＵ２２など）に付与するＩＰアドレス（例えば、ＩＰＡ２３など）を変更する場合など、ネットワークの構成に変更が生じる場合であり、局データＦＤ２にその変更の内容が反映されていないと、局データＦＤ２を利用する通信が正常に行えなくなる可能性があるからである。したがって、局データＦＤ１の変更は、できるだけ速やかにＶｏＩＰ通信システム１０内の各遠隔呼処理装置（その１つが、２１）が蓄積する局データ（例えば、ＦＤ２）に反映させ、同期のリアルタイム性を高める必要がある。

現状では、保守者が保守コンソール（図示せず）から手作業で本体呼処理装置１３に蓄積された局データＦＤ１の変更と、遠隔呼処理装置（例えば、２１）に蓄積された局データ（例えば、ＦＤ２）の変更を行っているため、十分なリアルタイム性を求めることは困難であるが、図４によればリアルタイム性を高めることが可能である。

なお、図４の動作は本体呼処理装置１３と遠隔呼処理装置２１とが、前記ＩＰ網１１経由で通信できることが前提となっているため、基本的に、前記通常状態において実行される。

図４において、例えば、保守コンソールを操作する保守者によって、本体呼処理装置１３に蓄積された局データＦＤ１が変更されると（Ｓ４０）、本体呼処理装置１３は、この変更の内容が反映されるべき局データを蓄積した遠隔呼処理装置を特定する（Ｓ４１）。ここでは、本体呼処理装置１３は遠隔呼処理装置２１を該当する呼処理装置として特定したものとする。

遠隔呼処理装置２１が蓄積している局データＦＤ２が、拠点ＳＴ２以外の範囲の情報を含まない場合には、拠点ＳＴ２内のＩＰアドレスの変更などが実行されたときに、その変更に合わせて保守者が局データＦＤ１を変更すると、前記ステップＳ４１で、本体呼処理装置１３が遠隔呼処理装置２１を特定することになる。

ステップＳ４１につづき、本体呼処理装置１３は、当該遠隔呼処理装置２１へ宛てて、設定変更要求メッセージを収容したＩＰパケットを送信する（Ｓ４２）。これを受信した遠隔呼処理装置２１は、局データＦＤ２を変更することに支障がなければ、設定変更許可応答メッセージを収容したＩＰパケットを本体呼処理装置１３へ宛てて送信する（Ｓ４３）。

この設定変更許可応答メッセージを受信すると、本体呼処理装置１３は、変更局データを収容したＩＰパケットを遠隔呼処理装置２１へ送信する（Ｓ４４）。変更局データとして送信するデータは、その時点の局データＦＤ１のうち、遠隔呼処理装置２１が蓄積している局データＦＤ２に対応する部分だけでよい。また、それまでの局データＦＤ２との差分に相当する情報を当該変更局データとして送信すること等により、送信するデータ量を抑制することができる。

変更局データを受信した遠隔呼処理装置２１は、それまで蓄積していた局データＦＤ２に、変更局データの内容を反映させることにより、局データの同期を取る（Ｓ４５）。

（Ａ−３）実施形態の効果
本実施形態によれば、本体呼処理装置（１３）とＩＰＬＴＵ（２２）との通信が不能となっても、ＩＰＬＴＵ（２２）や一般電話機（２３など）が稼動することが可能であるため、支社に相当する拠点（ＳＴ２〜ＳＴ４）内のＩＰＬＴＵや一般電話機の稼働率を高め、可用性を向上することができる。

しかも本実施形態では、支社に相当する各拠点（ＳＴ２〜ＳＴ４）に設置する遠隔呼処理装置（例えば、２１）は、本体呼処理装置（１３）よりも小型で安価な装置として構成でき、ＶｏＩＰ通信システム（１０）全体として効率的な構成となる。

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

なお、上記実施形態では、各拠点内に１つのＩＰＬＴＵを設置したが、拠点内のＩＰＬＴＵの数は必ずしも１つに限定する必要はない。

また、上記実施形態では、１つのＩＰＬＴＵが２つの一般電話機を収容する構成であったが、１つのＩＰＬＴＵが収容する一般電話機の数は２つに限定する必要がないことは当然である。

さらに、上記実施形態にかかわらず、各拠点には、ＶｏＩＰ対応機能を搭載したＩＰ電話機が含まれていてもよい。

また、上記実施形態にかかわらず、本発明では、障害の発生していない正常時でも、自拠点（例えば、ＳＴ２）内の通話のため、ＩＰＬＴＵ（例えば、２２）が自拠点内の遠隔呼処理装置（ここでは、２１）を使用するようにしてもよい。ＩＰＬＴＵ２２が自拠点内の通話であるか否かを識別する機能を持っていれば、他の拠点との通話の場合の呼制御メッセージだけを本体呼処理装置１３へ送信することも可能である。

この場合、ＩＰＬＴＵ（例えば、２２）は自拠点内の遠隔呼処理装置との通信が不能になったときに、本体呼処理装置と通信するものであってよい。

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

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

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

実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。実施形態にかかるＶｏＩＰ通信システムで使用するＩＰＬＴＵの内部構成例を示す概略図である。実施形態の動作説明図である。実施形態の動作説明図である。

符号の説明

１０…ＶｏＩＰ通信システム、１１…ＩＰ網、１２，２０…ルータ、１３…本体呼処理装置、１４，２２…ＩＰＬＴＵ、１５，１６，２３，２４…一般電話機、２１…遠隔呼処理装置、ＳＴ１〜ＳＴ４…拠点。

Claims

音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムにおいて、
前記複数の拠点のうち一部の拠点に設置され、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理するメイン呼制御対応部と、
前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点に設置され、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理するサブ呼制御対応部と、
前記複数の拠点のうち、前記音声通信対応端末を有する拠点に設置され、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うゲートウエイ部とを備え、
前記メイン呼制御対応部は、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応部に変更内容情報を送り、
前記サブ呼制御対応部は、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更し、
前記各拠点のうちメイン呼制御対応部を持たない拠点内に設置された前記ゲートウエイ部は、少なくとも前記メイン呼制御対応部との通信が不能となったことを認識すると、自拠点内の前記サブ呼制御対応部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援する
ことを特徴とする構内交換システム。
音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムの構成要素であり、前記複数の拠点のうち、前記音声通信対応端末を有する拠点に設置され、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うゲートウエイ装置において、
前記構内交換システムは、前記複数の拠点のうち一部の拠点に設置され、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理するメイン呼制御対応部と、前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点に設置され、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理するサブ呼制御対応部とを含み、前記メイン呼制御対応部は、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応部に変更内容情報を送り、前記サブ呼制御対応部は、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更するものであり、
前記メイン呼制御対応部との通信の可否を判定する通信可否判定部と、
当該通信可否判定部がメイン呼制御対応部との通信が不能であると判定した場合、当該ゲートウエイ装置が設けられている拠点内の前記サブ呼制御対応部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援する呼制御選択部と
を備えることを特徴とするゲートウエイ装置。
音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムが実行する構内交換方法において、
前記複数の拠点のうち一部の拠点には、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理するメイン呼制御対応部を設置し、
前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点には、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理するサブ呼制御対応部を設置し、
前記複数の拠点のうち、前記音声通信対応端末を有する拠点には、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うゲートウエイ部を設置しておき、
前記メイン呼制御対応部は、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応部に変更内容情報を送り、
前記サブ呼制御対応部は、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更し、
前記各拠点のうちメイン呼制御対応部を持たない拠点内に設置された前記ゲートウエイ部は、少なくとも前記メイン呼制御対応部との通信が不能となったことを認識すると、自拠点内の前記サブ呼制御対応部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援する
ことを特徴とする構内交換方法。
音声通信用の第２の通信プロトコルに対応する音声通信対応端末を、第１の通信プロトコルに対応するネットワークに接続させるためにプロトコル変換を行う機能と、前記第１の通信プロトコル上で端末を識別するための第１の端末識別子と第２の通信プロトコル上で端末を識別するための第２の端末識別子との対応関係を含む呼制御基礎情報を蓄積、管理する機能とを有する、前記ネットワークを介して接続可能な複数の拠点のシステムを包含する構内交換システムを構成する各拠点に分散配置されたコンピュータを機能させる構内交換プログラムにおいて、
前記複数の拠点のうち一部の拠点に配置されたコンピュータを、各拠点の拠点内および拠点間の通信に関する前記呼制御基礎情報を管理すると共に、呼制御基礎情報に変更が生じると、この変更に係る拠点の拠点内通信に関する呼制御基礎情報を管理するサブ呼制御対応機能部に変更内容情報を送るメイン呼制御対応機能部として機能させ、
前記複数の拠点のうちの残りの拠点であって、前記音声通信対応端末を有する拠点に配置されたコンピュータを、少なくとも自拠点の拠点内通信に関する前記呼制御基礎情報を管理すると共に、前記変更内容情報が与えられると、前記変更内容情報に応じて管理している呼制御基礎情報を変更するサブ呼制御対応機能部として機能させ、
前記複数の拠点のうち、前記音声通信対応端末を有する拠点に配置されたコンピュータを、前記音声通信対応端末を収容し、前記プロトコル変換を含む、収容している前記音声通信対応端末と前記ネットワーク側との通信の支援処理を行うものであって、少なくとも前記メイン呼制御対応機能との通信が不能となったことを認識すると、自拠点内の前記サブ呼制御対応機能部が管理している呼制御基礎情報を利用して、収容している前記音声通信対応端末の通信を支援するゲートウエイ機能部として機能させる
ことを特徴とする構内交換プログラム。