JP4527651B2

JP4527651B2 - 構内交換機

Info

Publication number: JP4527651B2
Application number: JP2005322529A
Authority: JP
Inventors: 仁史宮崎
Original assignee: NEC Engineering Ltd
Current assignee: NEC Engineering Ltd
Priority date: 2005-11-07
Filing date: 2005-11-07
Publication date: 2010-08-18
Anticipated expiration: 2025-11-07
Also published as: JP2007129656A

Description

本発明は、構内交換機、特に、ＶｏＩＰを提供する上で使用するＩＰネットワークの様々な障害の把握、及び障害発生時の迂回路の選択等を標準的な機器を使用して行うことが可能な構内交換機に関する。

特許文献１には、ＩＰネットワークを利用してＩＰ電話を使用している環境において、ＧＷ装置をネットワークの末端と位置付け、ＧＷ装置間（エンド−エンド）のＶｏＩＰの音声品質を監視する技術が記載されている。具体的には、各ＧＷ装置に予め障害と位置付ける音声パケットの遅延等のしきい値を設定し、しきい値を超えた場合には、ＳＮＭＰ（Simple Network Management Protocol）マネージャに通知し、ＳＮＭＰマネージャは、ネットワークのどの区間で音声品質が低下しているかを認識する。

また、別の動作として、周期的にＳＮＭＰマネージャからポーリング処理によって音声品質に関する情報を収集し、リアルタイムでＧＷ装置を通過する音声パケットの状態を認識することができる。本動作によって得られた情報から、ＩＰネットワークトポロジーを作成し、ＩＰネットワークのルーティング情報の変更（ＩＰネットワーク内での迂回）、帯域の増減による伝送速度向上（帯域制御）、接続できない区間の呼の規制（呼制御）が行われる。また、別の測定器、解析用の装置を各ＧＷ装置の配下に設置しておくことで、音声パケットを試験的に生成し、各区間のエンド−エンドの音声品質を調査することができる。さらに、ＧＷ装置が接続されているネットワークの品位に合わせ、高品位ネットワークには厳しい値を、低品位ネットワークには緩い値を個別に設定することもできる。

一方、特許文献２に記載のインターネット電話システム及びその迂回路生成方法は、ＩＰネットワークの中でもＷＡＮ回線の障害を検出した際に、その情報をネットワーク監視サーバに収集し、その情報に基づいて、呼制御管理サーバとＧＷ装置により、ＩＰ電話の呼をＰＰＰ（ポイント・ツー・ポイント・プロトコル）接続により公衆網に迂回させ、ネットワーク管理サーバを中継させて呼を接続することを可能としている。ＰＰＰを使用しているのは、１本の公衆回線に複数の呼を接続させることにより、迂回路用の公衆回線を有効利用し、音声圧縮により、公衆回線１本は、６４Ｋｂｐｓであるところを、最大８Ｋｂｐｓ／Ｇ．７２９を使用することで８つの呼の接続を可能としている。

また、本システムは、１台のネットワーク管理サーバと、複数の呼制御管理サーバ、ＧＷ装置、ユーザが使用するＩＰ電話端末により構成され、呼制御管理サーバは、各ネットワークに分散して設置され、ネットワーク管理サーバは、ＩＰネットワークのＩ／Ｆと公衆網のＩ／Ｆを備え、各ＧＷ装置は、ＩＰネットワークのＩ／Ｆと公衆網のＩ／Ｆを備えることが特徴である。

特開２００２−２７１３９２号公報特開２００３−２１９０２７号公報

しかし、上記特許文献１に記載の技術では、ＩＰネットワークを監視する専用のサーバが必要となるとともに、エンド−エンド間の音声品質の測定を行うには、専用の測定器を各エンドポイント（全ＧＷ装置の配下）に設置する必要があり、さらに、解析用の装置を設置しなければならないため、ＩＰネットワークを監視するにあたって、コスト及び機器の保守作業の面で、ユーザ及び保守員の負担が大きいという問題があった。

また、生成した呼の状態に問題があった場合に迂回させることはできるが、事前に問題があるか否かを検証していない。もっとも、音声品質測定専用の測定器を各エンドポイントに設置し、解析用の装置を設置するとともに、この文献に記載の機能を連動させることで事前に検証可能であると推測できるが、そのためには、これらのテスト用の装置を常時接続する必要があり、コスト及び保守作業の面で相当の負担が発生するという問題があった。

さらに、ＩＰ電話−ＧＷ装置間の障害や、ＧＷ装置内の遅延、ＧＷ装置自体の障害等が検出されないため、ＩＰ電話を利用しているエンドユーザが感じる音声品質の低下をＧＷ装置が検出していない可能性があるという問題があった。

また、検出した音声品質低下箇所に応じてＩＰネットワークの内部で迂回させているが、ＧＷ装置自体の障害や基幹ネットワークの障害等が発生した場合には、ＩＰ電話が使用できない状態になってしまう技術では、発生した障害の種類によっては迂回させることができなかったり、真に信頼性が高いとはいえない面があった。

一方、上記特許文献２に記載の技術では、ＷＡＮ回線の状態を監視しているＧＷ装置に対して呼制御管理サーバを設置する必要があり、大規模ＶｏＩＰネットワークを構築するには相当な台数のサーバが必要となり、コスト及び機器の保守作業の面でユーザ及び保守員の負担が大きいという問題があった。

また、公衆回線を有効利用することを特徴としていることで、ＧＷ装置に公衆回線を集中して収容し、ＧＷ装置自体に障害が発生した場合には、ＩＰネットワーク及び公衆網がともに利用することができなくなり、ＩＰ電話を利用することができず、多様な障害に対応することができないという問題があった。

さらに、ＩＰネットワークの障害ＷＡＮ回線の監視を行って迂回の実行を決定したり、圧縮・複合やトラフィック等によるＧＷ装置内の処理能力オーバーや、ＧＷ装置−ＩＰ電話間の遅延等は検出されないことや、ＧＷ装置がＷＡＮ回線の障害と検出する基準が音声パケットの品質低下の要因（エコー・ノイズとなる少しの遅延）を検出できないと考えられるため、ＩＰ電話を利用しているエンドユーザが感じる音声品質の低下をネットワーク監視サーバが検出できない可能性があるという問題があった。

そこで、本発明は、ユーザや保守員に、コスト及び保守作業の負担を与えることなく、監視用の機器、クライアント、サーバを必要とせず、ＶｏＩＰを提供している標準的な機器のみを使用して、信頼性の高いＶｏＩＰ対応のＩＰ−ＰＢＸシステムを提供することを目的とする。

また、本発明は、障害検出機能とＩＰ電話を使用しているエンドユーザの間に認識の差が発生しないようにＩＰ電話を音声サービスの末端として扱う、音声品質を監視するＶｏＩＰ対応のＩＰ−ＰＢＸシステムを提供すること、さらに、音声品質を監視するにあたって専用の機器を必要とせず、有限なＩＰアドレスを監視用の機器で無駄に消費させないことを目的とする。

上記目的を達成するため、本発明は、インターネットプロトコルの環境下にあるネットワークと接続され、端末間の呼接続処理を行う構内交換機であって、呼制御及び周辺機器の監視を含む処理を行い、運用系及び予備系にて冗長化される本体制御装置と、該本体制御装置と前記端末とに接続され、音声パケットの変換を含む処理を行う端末制御装置とを備え、前記本体制御装置は、前記端末制御装置にヘルスチェックパケットを送信し、該ヘルスチェックパケットに対して前記端末制御装置から応答がない場合を異常、応答がある場合を正常と判定し、前記本体制御装置と前記端末制御装置との間で障害を検出した場合には、前記運用系の本体制御装置と前記端末制御装置との間の正常数と、前記予備系の本体制御装置と前記端末制御装置との間の正常数とを比較し、正常数の多い系を新運用系として動作させることを特徴とする。

そして、本発明によれば、本体制御装置を冗長化し、音声パケットの変換を含む処理を行う端末制御装置との間の障害が検出されると、正常数の多い運用系に切り替えるため、構内交換機の冗長性を強化し、より信頼性の高い構内交換機及びＶｏＩＰ対応のＩＰ−ＰＢＸシステムを提供することができる。

前記構内交換機において、前記本体制御装置は、前記端末にヘルスチェックパケットを送信し、該ヘルスチェックパケットに対する応答が前記端末からない場合を異常と判定し、異常回数が所定回数以上となった場合には、該端末の切り離し処理を行うことができる。

また、前記構内交換機において、前記本体制御装置は、前記端末制御装置に対して前記端末のアドレスを通知し、前記端末制御装置は、前記本体制御装置からの指示に基づき、前記端末に対してヘルスチェックパケットを送信するとともに、前記本体制御装置は、周期的に前記端末制御装置にヘルスチェックパケットを送信して前記端末情報を収集し、該端末の状態が異常であると判定された回数が所定回数以上となった場合には、該端末の切り離し処理を行うことができる。

さらに、前記構内交換機において、前記端末のうち２台の端末が通話状態となると、該両方の端末で送受信の音声パケットをカウントし、該両方の端末のカウント値を、前記本体制御装置が周期的に収集し、該端末の音声品質を監視することができ、監視用の機器、クライアント、サーバを必要とせず、ＶｏＩＰを提供している標準的な機器のみを使用して、信頼性の高いＶｏＩＰ対応のＩＰ−ＰＢＸシステムを提供することができる。

また、前記構内交換機において、前記端末のうち２台の端末が通話状態となり、前記本体制御装置が該端末の音声品質を監視し、音声品質が低下していると判定した場合には、前記端末と各々同一拠点に設置されている未通話状態の端末を２台抽出するとともに、ヘルスチェックが正常に行われている端末制御装置を検索して選定し、前記未通話状態の端末と前記選択した端末制御装置間に各々試験的通話を行い、該試験的通話が正常である場合には、前記音声品質が低下している２台の端末を前記選択した端末制御装置に接続し、該端末制御装置間を折り返すことでネットワーク内迂回処理を行うことができる。これによって、音声品質を監視するにあたって専用の機器を必要とせず、ユーザが感じる音声品質への不満を漏れなく収集し、迂回等の処理により高い音声品質を常に提供することができ、有限なＩＰアドレスを監視用の機器で無駄に消費させることもない。また、ＩＰ−ＰＢＸを構成する標準的な機器のみで、迂回経路の事前確認を実施しているため、専用の測定機器等を用いることなく、迂回の際に選択する経路の音声品質の事前確認が可能となる。

以上のように、本発明によれば、ユーザや保守員に、コスト及び保守作業の負担を与えずに、監視用の機器、クライアント、サーバが不要で、ＶｏＩＰを提供している標準的な機器のみを使用して、信頼性の高いＶｏＩＰ対応のＩＰ−ＰＢＸシステムを提供することなどが可能となる。

図１は、本発明にかかる構内交換機（以下「ＩＰ−ＰＢＸ」という）の一実施の形態を備えたシステムを示し、このＩＰ−ＰＢＸシステムは、運用系・予備系と冗長化された本体ＣＰＵ（本体制御装置、Ａ１）と、ＩＰ端末制御装置（Ｂ１〜Ｂ６）と、ＩＰネットワークを構成するネットワーク機器（Ｄ１〜Ｄ１０）と、各拠点のフロアに設置されているＩＰ端末（Ｃ１〜Ｃ４：電話機、Ｃ５〜Ｃ７：ＴＲＫ（Trunk））とで構成される。

ＴＲＫのＩ／Ｆを具備するＩＰ端末は、ＩＰネットワークと公衆網を接続するＧＷ（ゲートウェイ）として位置付けされる。また、電話機のＩ／Ｆを具備するＩＰ端末は、ＩＰネットワークとの通信が可能な電話機として位置付けされる。

運用系・予備系と冗長化されている本体ＣＰＵ（Ａ１）は、図２に示すように、ＣＰＵ（ａ１）と、記憶媒体（ａ２）と、メモリ（ａ３）と、ＴＤＭ（Time Division Multiplex：時分割多重）のＩ／Ｆを提供するための従来のＰＢＸで使用しているものと同じ専用のハードウェア（ａ４）と、基本ＯＳ部（ａ５）と、呼処理部（ａ６）と、監視処理部（ａ７）と、課金装置・保守端末とのＩ／Ｆを管理する外部装置管理部（ａ８）と、本体ＣＰＵ（Ａ１）に専用ハードウェアで接続している一般内線や専用線・公衆回線等の各種回路のＩ／Ｆを管理する回路管理部（ａ９）と、周辺機器との通信を行う送受信処理部（ａ１０）とで構成される。尚、これら中で従来のＰＢＸを構成するものと同じ専用ハードウェアの詳細の構成については、本発明と直接関係しないので、説明を省略する。

ＩＰ端末制御装置Ｂ１〜Ｂ６は、図３に示すように、ＣＰＵ（ｂ１）と、記憶媒体（ｂ２）と、メモリ（ｂ３）と、基本ＯＳ部（ｂ４）と、本体ＣＰＵ（Ａ１）とのＩ／Ｆを管理する本体ＣＰＵ通信部（ｂ５）と、ＩＰ端末の制御を行うＩＰ端末管理部（ｂ６）と、ＴＤＭとＩＰパケットの音声変換や音声圧縮・復元の処理を行う音声管理部（ｂ７）と、ＩＰ端末・本体ＣＰＵ（Ａ１）との通信を行う送受信処理部（ｂ８）とで構成される。

ＩＰ端末Ｃ１〜Ｃ７は、図４に示すように、ＣＰＵ（ｃ１）と、記憶媒体（ｃ２）と、メモリ（ｃ３）と、電話機・ＴＲＫのＩ／Ｆを行うための専用ハードウェア（ｃ４）と、基本ＯＳ部（ｃ５）と、ＩＰ端末制御装置とのＩ／Ｆを管理するＩＰ端末制御装置通信部（ｃ６）と、ＩＰパケットとＴＤＭの音声変換や音声圧縮・復元の処理を行う音声管理部（ｃ７）と、ＩＰ端末制御装置・本体ＣＰＵ（Ａ１）との通信を行う送受信処理部（ｃ８）と、電話機／ＴＲＫの基本機能を行うモジュール（ｃ９）とで構成される。尚、この一般の電話機として動作させるための専用ソフトウェア・ハードウェアの構成については、本発明と直接関係しないので、説明を省略する。

次に、図５〜図６の説明図と、図７〜図１２のフローチャートと、図１３〜図１４の監視に使用しているパケットフォーマットと、図１５〜図１９のデータベースの構成図を参照しながら、上記構成を有するＩＰ−ＰＢＸシステムの動作について説明する。

まず、本発明のネットワーク監視処理の動作について、図５と、図７〜図１０のフローチャートと、図１３〜図１４のパケットフォーマットと、図１５〜図１９のデータベースを参照しながら説明する。

図５の構成で構築されているＩＰ−ＰＢＸシステム、及びＩＰネットワーク、公衆網において、運用系・予備系の本体ＣＰＵ（Ａ１）は、ＩＰ端末制御装置Ｂ１〜Ｂ６、ＩＰ端末Ｃ１〜Ｃ７へのヘルスチェックを行っている。本ヘルスチェックは、センターに設置されているＩＰ−ＰＢＸから周辺機器（ＩＰ端末制御装置、ＩＰ端末）へヘルスチェックを行っていることから、本発明では「スター型」ヘルスチェックとして表現されている。

まず、本体ＣＰＵ（Ａ１）とＩＰ端末制御装置Ｂ１〜Ｂ６との間のヘルスチェックの処理について、図７を中心に参照しながら説明する。

ＩＰ端末制御装置の登録情報をデータベースから読み出し、ヘルスチェックパケットを作成してＩＰ端末制御装置に送信する（Ｓ１１）。この時参照するデータベースは、図１７のデータベース中のＩＰアドレスである。送信するパケットのフォーマットは、図１３に示される。

この中で、本体ＣＰＵ→ＩＰ端末制御装置方向（左側）にある要求データ種別に、ヘルスチェックに関するデータで要求するもののデータ番号が設定されている。その要求に応じて、ＩＰ端末装置側は、返信データを作成する。図１３のフォーマットは、全データを要求した状態で記載されている。同様に要求データ種別（端末データ）には、ＩＰ端末制御装置からＩＰ端末のヘルスチェックを行う際に必要となるデータが設定されている。

ＩＰ端末制御装置から本体ＣＰＵに返信するパケット（右側）については、各区間の送信・受信に関する回数や時刻が設定されている。また、警告音送出に関するデータが設定されている。この警告音とは、ＩＰ端末が一定時間（ＩＰ端末の初期データ登録時に設定される）以上、音声パケット（ＲＴＰ）を受信しなかった（受信側が無音状態）場合に、ＩＰ端末から受話器側／公衆網側に警告音を聞かせる処理があり、その実行が行われたか否かを、ＩＰ端末からＩＰ端末制御装置が収集し、結果を本体ＣＰＵに対して通知するよう動作する。本警告音については、本発明の動作とは直接関係がないため、詳細説明を省略する。

ヘルスチェックパケットの送信の結果、返信がないか確認（Ｓ１２）し、正常に返信があれば、その結果を図１７のデータベースに保存し、次の装置のチェックに移る（Ｓ１３）。返信がない場合には、異常回数を確認（Ｓ１４）し、図１５のデータベースに記録されている、障害として認知する設定値に満たない場合には、その結果（異常回数のカウントアップ）を図１７のデータベースに保存し、次の装置のチェックに移る（Ｓ１３）。

上記異常回数が設定値以上になった場合には、その結果（異常）を図１７のデータベースに保存し、本体ＣＰＵの運用系と予備系の正常な装置の台数の比較を行う（Ｓ１５・Ｓ１６）。その結果、現在の運用系の方が台数が少ない（予備系の方が台数が多い）場合には、本体ＣＰＵの運用系の切り替えを行う（Ｓ１７）。一方、現在の運用系の方が正常な装置の台数が多い場合には、運用系の切り替えは行わずにＩＰ端末制御装置の切り離しを行う（Ｓ１８）。

次に、本体ＣＰＵ（Ａ１）とＩＰ端末Ｃ１〜Ｃ７との間のヘルスチェック処理について、図８を中心に参照しながら説明する。

まず、ＩＰ端末の登録情報をデータベースから読み出し、ヘルスチェックパケット（Ｐ
ＩＮＧ）を作成してＩＰ端末に送信する（Ｓ２１）。この時参照するデータベースは、図１８のデータベース中のＩＰアドレスである。送信の結果、正常に応答があれば、その結果を図１８のデータベースに保存し、次の端末のチェックに移る（Ｓ２３）。応答がない場合には、異常回数を確認（Ｓ２４）し、図１６のデータベースに記録されている、障害として認知する設定値に満たない場合には、その結果（異常回数のカウントアップ）を図１８のデータベースに保存し、次の端末のチェックに移る（Ｓ２３）。上記異常回数が設定値以上になった場合は、その結果（異常）を図１８のデータベースに保存し、ＩＰ端末の切り離し処理を行う（Ｓ２５）。

次に、ＩＰ端末制御装置Ｂ１〜Ｂ６とＩＰ端末Ｃ１〜Ｃ７間のヘルスチェックの処理について、図９を中心に参照しながら説明する。

まず、本体ＣＰＵからＩＰ端末制御装置に対してＩＰ端末のＩＰアドレスを通知する。通知に使用するＩ／Ｆは、本体ＣＰＵとＩＰ端末制御装置間のヘルスチェックのパケットを使用する。パケットのフォーマットは、図１３に示すとおりである。この中で、本体ＣＰＵ→ＩＰ端末制御装置方向（左側）の要求データ（端末データ種別）に、端末のＩＰアドレスが含まれている。ＩＰ端末制御装置は、本体ＣＰＵからの指示に基づき、ＩＰ端末に対してＰＩＮＧを送信する（Ｓ３２）。本体ＣＰＵは、周期的にＩＰ端末制御装置へのヘルスチェックパケットを使用してＩＰ端末の情報を収集する（Ｓ３３）。

上記動作の結果、ＩＰ端末制御装置からの返信がない場合には、ＩＰ端末制御装置のヘルスチェックＮＧの処理（図７のＳ１２へ）を行う（Ｓ３５）。返信があった場合は、パケットの内容を確認（Ｓ３６・Ｓ３７）し、ＩＰ端末の状態が正常な場合には、結果（正常）を図１８のデータベースに保存し、次の処理へ移る（Ｓ３８）。結果が異常な場合は、異常回数を確認（Ｓ３９）し、図１６のデータベースに記録されている、障害として認知する設定値に満たない場合には、その結果（異常回数のカウントアップ）を図１８のデータベースに保存し、次の端末のチェックに移る（Ｓ３８）。上記異常回数が設定値以上になった場合には、その結果（異常）を図１８のデータベースに保存し、ＩＰ端末の切り離し処理を行う（Ｓ３ａ）。

次に、ＩＰ端末−ＩＰ端末間、又はＩＰ端末−ＩＰ端末制御装置間の音声品質の情報収集の処理について説明する。本監視処理は、前述の「スター型」に対して「エンド−エンド型」として表現されている。これは、ユーザに最も近い場所にある各ＩＰ端末をＩＰネットワークの末端（エンドポイント）として位置付け、各々のＩＰ端末が呼毎に音声品質の監視を行っているためである。この処理の処理シーケンスは、図１０に示すとおりである。

同図には、ＩＰ端末（電話機）同士が通話する際の全体の処理のシーケンスが記載されている。本発明により新規に追加した処理は、点線内の処理である。ＩＰ端末（電話機）は、空き（未使用）の状態から発信し、相手を決定して相手のＩＰ端末（電話機）が応答することで通話状態となる。ここまでの処理は、既存の技術のとおりであるため、説明は省略する。本発明により、ＩＰ端末が通話状態になると、両方のＩＰ端末で送信・受信の音声パケット（ＲＴＰ）のカウントを開始する。発信者側、着信者側のＩＰ端末が監視・収集した（Ｓ４１・Ｓ４２）結果のデータを、本体ＣＰＵは、周期的に収集する。

本処理は、本体ＣＰＵとＩＰ端末間のヘルスチェックとは別に行われる。本処理のＩ／Ｆで使用するパケットのフォーマットは、図１４に示すとおりである。この中で、本体ＣＰＵ→ＩＰ端末方向（左側）に要求データの種別（ＲＴＰデータ）が設定され、ＩＰ端末は、要求データを返信するよう動作する。ＩＰ端末→本体ＣＰＵ方向（右側）に返信するＲＴＰデータを記載している。設定されているデータは、当該通話の開始時刻・終話時刻（終話済みの場合）、コーデック・ペイロード情報、ＲＴＰ送信・受信・受信ロス回数となる。尚、ＩＰ端末に設定されたジッタバッファを超過したものはロスとして扱われる。本体ＣＰＵは、本パケットによりＩＰ端末の音声品質を監視（Ｓ４１〜Ｓ４３）している。

次に、以上の処理によって収集した図１７、図１８のデータベースと、図１９のデータベースに記録されている各ＩＰ端末と拠点ＩＤの関連付け情報から得られる情報を利用し、音声品質が低下している呼を迂回させる処理について、図１１及び図１２を中心に参照しながら説明する。

まず、ＩＰ端末Ａ（電話機）とＩＰ端末Ｂ（電話機）がＩＰネットワークを利用して直接接続され、音声を提供している。この状態で収集した音声品質情報（ＲＴＰデータ）を確認した（Ｓ５１・Ｓ５２）ところ、音声品質の低下が確認されず、音声品質に問題がなければ、そのまま通話状態が継続される（Ｓ５３）。

音声品質低下を確認した本体ＣＰＵは、図１９のデータベースから、ＩＰ端末Ａ／Ｂと同一拠点に設置されているＩＰ端末を２台、未使用中のものから抽出する。本説明では、ＩＰ端末Ｃ／Ｄを抽出している。さらに、本体ＣＰＵは、ＩＰ端末Ｃ／Ｄとのヘルスチェックが正常であるＩＰ端末制御装置を検索し、選定する。本体ＣＰＵは、ＩＰ端末Ｃ−ＩＰ端末制御装置、ＩＰ端末Ｄ−ＩＰ端末制御装置間各々に試験的に通話（音声データは、試験用のデータが双方向から送出される）を行うよう指示する。この時使用するコーデック、ペイロードについては、ＩＰ端末Ａ／Ｂ間の通話で使用しているものと同じ設定値を使用する（Ｓ５４）。

本体ＣＰＵは、試験的に行っている通話の音声品質を、図１０の処理シーケンスと同様のシーケンスで収集、監視する（Ｓ５５〜Ｓ５８）。収集した結果を確認（Ｓ５９・Ｓ５ａ）し、問題がなければ、ＩＰ端末Ｃの代わりにＩＰ端末Ａを、ＩＰ端末Ｄの代わりにＩＰ端末Ｂを、各々ＩＰ端末制御装置に接続（Ｓ５ｃ）し、ＩＰ端末制御装置間を折り返すように接続することでＩＰネットワーク内迂回処理が行われる。万が一、試験した通話においても音声品質低下が確認された（Ｓ５ｂ）場合には、ＩＰ端末Ｃ／Ｄと接続可能な他のＩＰ端末制御装置が存在するか否かを確認（Ｓ５ｄ・Ｓ５ｅ）する。他のＩＰ端末制御装置が検索できた場合は、前頁のＳ５１の処理に戻り、再び音声品質の試験を行う。

こうしてＩＰネットワーク内に正常な経路が見つかるまで、本試験は行われるが、途中でＩＰ端末Ａ−ＩＰ端末Ｂ間の音声品質が改善されたことを周期的な図１０の音声品質監視処理により確認できた場合には、Ｓ５１の確認により、本処理も自動的に中断される。こうした処理の中で、ＩＰネットワーク内の迂回経路で確実に音声品質の良い通話を提供することができないと判断した場合（図１２：Ｓ５ｆ）は、最終処理として、公衆網迂回処理に入る。

本処理は、ＩＰ端末Ａ（電話機）と同一拠点にあるＩＰ端末Ｅ（ＴＲＫ）、ＩＰ端末Ｂ（電話機）と同一拠点にあるＩＰ端末Ｆ（ＴＲＫ）を抽出し、ＩＰ端末ＡとＩＰ端末Ｅを、ＩＰ端末ＢとＩＰ端末Ｆを各々ＩＰネットワーク上で接続するように処理を行う。ＩＰ端末Ａが自動的にＩＰ端末Ｆの公衆網の電話番号（ダイヤルイン番号）とＩＰ端末Ｂの番号（追加ダイヤルイン番号）先に転送処理を行うように動作することで、この処理を可能としている。本処理は、従来ＰＢＸの技術の中では標準的に記載されている技術であるため、詳細は省略する。

以上の処理を行う本発明により、ユーザが使用しているＩＰ端末の音声品質の低下を確認した際に、特別な装置を必要とせず、かつ、ユーザに何の操作を行わせることもなく、自動的に安定した音声品質を提供できる経路へと迂回させることで、信頼性の高い、品質の良い音声を提供できるＩＰ−ＰＢＸを実現している。

本発明にかかるＩＰ−ＰＢＸの一実施の形態を備えたシステムの構成図である。図１に示したＩＰ−ＰＢＸの本体ＣＰＵの構成図である。図１に示したＩＰ−ＰＢＸのＩＰ端末制御装置の構成図である。図１に示したＩＰ−ＰＢＸシステムのＩＰ端末の構成図である。本発明にかかるＩＰ−ＰＢＸによるネットワーク監視の説明図である。本発明にかかるＩＰ−ＰＢＸによる呼の迂回の説明図である。本発明にかかるＩＰ−ＰＢＸによる本体ＣＰＵ−ＩＰ端末制御装置間のヘルスチェックのフローチャートである。本発明にかかるＩＰ−ＰＢＸによる本体ＣＰＵ−ＩＰ端末間のヘルスチェックのフローチャートである。本発明にかかるＩＰ−ＰＢＸによるＩＰ端末制御装置−ＩＰ端末間のヘルスチェックのフローチャートである。本発明にかかるＩＰ−ＰＢＸによるＩＰ端末の音声品質情報収集のフローチャートである。本発明にかかるＩＰ−ＰＢＸによるＩＰ端末の迂回経路選択のフローチャートである。本発明にかかるＩＰ−ＰＢＸによるＩＰ端末の迂回経路選択のフローチャートである。本発明にかかるＩＰ−ＰＢＸによるヘルスチェックに用いられるパケットフォーマットを示す図である。本発明にかかるＩＰ−ＰＢＸによる音声品質情報収集に用いられるパケットフォーマットを示す図である。本発明にかかるＩＰ−ＰＢＸのデータベースに記録されているＩＰ端末制御装置ヘルスチェック関連データを示す図である。本発明にかかるＩＰ−ＰＢＸのデータベースに記録されているＩＰ端末ヘルスチェック関連データを示す図である。本発明にかかるＩＰ−ＰＢＸのＩＰ端末制御装置管理メモリに記録されているデータを示す図である。本発明にかかるＩＰ−ＰＢＸのＩＰ端末管理メモリに記録されているデータを示す図である。本発明にかかるＩＰ−ＰＢＸのＩＰ端末管理メモリに記録されている拠点ＩＤを示す図である。

符号の説明

Ａ１ＩＰ−ＰＢＸの本体ＣＰＵ（運用系／予備系）
Ｂ１〜Ｂ６ＩＰ端末制御装置
Ｃ１〜Ｃ４ＩＰ端末（電話機）
Ｃ５〜Ｃ７ＩＰ端末（ＴＲＫ）
Ｃ８〜Ｃ９一般電話機
Ｄ１〜Ｄ１０ＩＰネットワーク機器
Ｅ１一般電話機制御装置
Ｅ２従来Ｉ／ＦのＴＲＫ回路装置
ａ１〜ａ１０本体ＣＰＵを構成する機能ブロック
ｂ１〜ｂ８ＩＰ端末制御装置を構成する機能ブロック
ｃ１〜ｃ９ＩＰ端末を構成する機能ブロック
Ｓ１１〜Ｓ１８本体ＣＰＵ−ＩＰ端末制御装置間ヘルスチェック処理のシーケンス番号
Ｓ２１〜Ｓ２５本体ＣＰＵ−ＩＰ端末間ヘルスチェック処理のシーケンス番号
Ｓ３１〜Ｓ３ａＩＰ端末制御装置−ＩＰ端末間ヘルスチェック処理のシーケンス番号
Ｓ４１〜Ｓ４３ＩＰ端末の音声品質情報収集処理のシーケンス番号
Ｓ５１〜Ｓ５ｆ迂回経路選択処理のシーケンス番号

Claims

インターネットプロトコルの環境下にあるネットワークと接続され、端末間の呼接続処理を行う構内交換機であって、
呼制御及び周辺機器の監視を含む処理を行い、運用系及び予備系にて冗長化される本体制御装置と、
該本体制御装置と前記端末とに接続され、音声パケットの変換を含む処理を行う端末制御装置とを備え、
前記本体制御装置は、前記端末制御装置にヘルスチェックパケットを送信し、該ヘルスチェックパケットに対して前記端末制御装置から応答がない場合を異常、応答がある場合を正常と判定し、前記本体制御装置と前記端末制御装置との間で障害を検出した場合には、前記運用系の本体制御装置と前記端末制御装置との間の正常数と、前記予備系の本体制御装置と前記端末制御装置との間の正常数とを比較し、正常数の多い系を新運用系として動作させることを特徴とする構内交換機。
前記本体制御装置は、前記端末にヘルスチェックパケットを送信し、該ヘルスチェックパケットに対する応答が前記端末からない場合を異常と判定し、異常回数が所定回数以上となった場合には、該端末の切り離し処理を行うことを特徴とする請求項１に記載の構内交換機。
前記本体制御装置は、前記端末制御装置に対して前記端末のアドレスを通知し、前記端末制御装置は、前記本体制御装置からの指示に基づき、前記端末に対してヘルスチェックパケットを送信するとともに、前記本体制御装置は、周期的に前記端末制御装置にヘルスチェックパケットを送信して前記端末情報を収集し、該端末の状態が異常であると判定された回数が所定回数以上となった場合には、該端末の切り離し処理を行うことを特徴とする請求項１又は２に記載の構内交換機。
前記端末のうち２台の端末が通話状態となると、該両方の端末で送受信の音声パケットをカウントし、該両方の端末のカウント値を、前記本体制御装置が周期的に収集し、該端末の音声品質を監視することを特徴とする請求項１、２又は３に記載の構内交換機。
前記端末のうち２台の端末が通話状態となり、前記本体制御装置が該端末の音声品質を監視し、音声品質が低下していると判定した場合には、前記端末と各々同一拠点に設置されている未通話状態の端末を２台抽出するとともに、ヘルスチェックが正常に行われている端末制御装置を検索して選定し、前記未通話状態の端末と前記選択した端末制御装置間に各々試験的通話を行い、該試験的通話が正常である場合には、前記音声品質が低下している２台の端末を前記選択した端末制御装置に接続し、該端末制御装置間を折り返すことでネットワーク内迂回処理を行うことを特徴とする請求項１乃至４のいずれかに記載の構内交換機。