(57)【要約】【課題】  どの部分で障害が発生しているかを特定することを可能とし、障害の解析時間を大幅に短縮することが可能なネットワークを提供する。【解決手段】  ネットワーク装置１と音声ＩＰ端末４とゲートウェイ装置８とＶＯＩＰ交換装置５とにそれぞれ通話中の音声パケットを監視して実時間で障害情報を検出する障害検出機能と、障害検出機能の障害情報を基に障害発生を他の装置に送付する機能と、障害内容を可聴信号にて通知する可聴音通知機能と、障害情報を保持する機能とを具備している。ネットワーク装置１と音声ＩＰ端末４とゲートウェイ装置８とＶＯＩＰ交換装置５とにおいては、通話開始から通話終了までの実時間にて、装置間連携して障害監視と障害通知とを行っている。【選択図】      図１                                                  
2005175856.tif 000002
【特許請求の範囲】
【請求項１】
ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を構成する複数のネットワーク装置と、前記ネットワーク装置を介してＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続する音声ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）端末と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網を前記ＷＡＮに接続するゲートウェイ装置と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網及び既存端末を前記ＷＡＮに接続するＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）交換装置とを含むネットワークであって、
前記ネットワーク装置と音声ＩＰ端末とゲートウェイ装置とＶＯＩＰ交換装置とにそれぞれ、通話中の音声パケットを監視して実時間で障害情報を検出する障害検出手段と、前記障害検出手段の障害情報を基に障害発生を他装置に通知する通知手段と、障害内容を可聴信号にて通知する可聴音通知手段と、前記障害情報を保持する保持手段とを有し、
前記ネットワーク装置と前記音声ＩＰ端末と前記ゲートウェイ装置と前記ＶＯＩＰ交換装置とにおいて通話開始から通話終了までの実時間にて装置間で連携して障害監視と障害通知とを行うことを特徴とするネットワーク。
【請求項２】
前記可聴信号を送信する際に前記聴音信号として通話信号と合成した信号の通知と可聴音制御信号としての通知とのうちのいずれか選択する手段と、前記障害検出が可能な装置が受信側になった時に前記可聴音信号のそのままの再生と前記可聴音制御信号のデータに基づいた前記可聴音の再生とのうちのいずれか選択する手段とを含むことを特徴とする請求項１記載のネットワーク。
【請求項３】
前記ネットワーク装置間にてパケットが通過するメインルートと、前記障害情報を受け渡すための通知ルートとを設け、
前記ネットワーク装置に、前記障害情報を前記メインルートと前記通知ルートとのうちのいずれかに送信制御するための切替え手段を含み、
その選択を外部から制御することを特徴とする請求項１または請求項２記載のネットワーク。
【請求項４】
前記障害検出が可能な装置が障害検出を行う際に、前記障害の閾値を外部から制御し、
前記障害が重障害と軽障害とのいずれかを前記閾値を基に判別する手段と、前記重障害の場合に重障害用の可聴音信号を送付する手段と、前記軽障害の場合に軽障害用の可聴音信号を送付する手段と、前記可聴音信号を外部から書換える手段と、前記障害の段階を複数段階的に設定する手段とを含むことを特徴とする請求項１から請求項３のいずれか記載のネットワーク。
【請求項５】
前記ＷＡＮ上に存在しかつ前記音声ＩＰ端末と前記ゲートウェイ装置と前記ＶＯＩＰ交換装置とにおける呼接続処理及び前記ネットワーク装置の障害情報を集中管理する呼処理サーバ装置を含み、
前記呼処理サーバ装置を論理的にソフトウェアプログラムとして形成したことを特徴とする請求項１から請求項４のいずれか記載のネットワーク。
【請求項６】
前記障害検出が可能な装置が保持する前記障害情報を前記ＬＡＮ及び前記ＷＡＮを介して外部から読出し自在としたことを特徴とする請求項１から請求項４のいずれか記載のネットワーク。
【請求項７】
ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を構成する複数のネットワーク装置と、前記ネットワーク装置を介してＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続する音声ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）端末と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網を前記ＷＡＮに接続するゲートウェイ装置と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網及び既存端末を前記ＷＡＮに接続するＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）交換装置とを含むネットワークのＶＯＩＰ障害発生通知方法であって、
前記ネットワーク装置と音声ＩＰ端末とゲートウェイ装置とＶＯＩＰ交換装置とのそれぞれに、通話中の音声パケットを監視して実時間で障害情報を検出する第１のステップと、前記第１のステップの障害情報を基に障害発生を他装置に通知する第２のステップと、障害内容を可聴信号にて通知する第３のステップと、前記障害情報を保持手段に保持する第４のステップを有し、
前記ネットワーク装置と前記音声ＩＰ端末と前記ゲートウェイ装置と前記ＶＯＩＰ交換装置とにおいて通話開始から通話終了までの実時間にて装置間で連携して障害監視と障害通知とを行うことを特徴とするＶＯＩＰ障害発生通知方法。
【請求項８】
前記可聴信号を送信する際に前記聴音信号として通話信号と合成した信号の通知と可聴音制御信号としての通知とのうちのいずれか選択するステップと、前記障害検出が可能な装置が受信側になった時に前記可聴音信号のそのままの再生と前記可聴音制御信号のデータに基づいた前記可聴音の再生とのうちのいずれか選択するステップとを含むことを特徴とする請求項７記載のＶＯＩＰ障害発生通知方法。
【請求項９】
前記ネットワーク装置間にてパケットが通過するメインルートと、前記障害情報を受け渡すための通知ルートとを設け、
前記ネットワーク装置側に、前記障害情報を前記メインルートと前記通知ルートとのうちのいずれかに送信制御するための切替えを行うステップを含み、
その選択を外部から制御することを特徴とする請求項７または請求項８記載のＶＯＩＰ障害発生通知方法。
【請求項１０】
前記障害検出が可能な装置が障害検出を行う際に、前記障害の閾値を外部から制御し、
前記障害が重障害と軽障害とのいずれかを前記閾値を基に判別するステップと、前記重障害の場合に重障害用の可聴音信号を送付するステップと、前記軽障害の場合に軽障害用の可聴音信号を送付するステップと、前記可聴音信号を外部から書換えるステップと、前記障害の段階を複数段階的に設定するステップとを含むことを特徴とする請求項７から請求項９のいずれか記載のＶＯＩＰ障害発生通知方法。
【請求項１１】
前記ＷＡＮ上に存在しかつ前記音声ＩＰ端末と前記ゲートウェイ装置と前記ＶＯＩＰ交換装置とにおける呼接続処理及び前記ネットワーク装置の障害情報を集中管理する呼処理サーバ装置を含み、
前記呼処理サーバ装置を論理的にソフトウェアプログラムとして形成したことを特徴とする請求項７から請求項１０のいずれか記載のＶＯＩＰ障害発生通知方法。
【請求項１２】
前記障害検出が可能な装置が保持する前記障害情報を前記ＬＡＮ及び前記ＷＡＮを介して外部から読出し自在としたことを特徴とする請求項７から請求項１１のいずれか記載のＶＯＩＰ障害発生通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク及びそれに用いるＶＯＩＰ障害発生通知方法に関し、特にＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）に代表される音声とデータとを統合したネットワークシステムにおいて、ネットワークの障害情報を把握しかつ障害発生を通知する障害通知方法に関する。
【背景技術】
【０００２】
従来、音声やデータを統合したネットワークにおいては、障害情報を監視して通知する方法として、監視サーバに対して障害発生情報をイベントベースに上げる方法や、障害情報を一定量分保持して監視サーバからその情報がポーリングされる方法が一般的である。
【０００３】
また、エンドツーエンドにてネットワーク障害を検出するために、ヘルスチェック機能によってＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網に障害が発生した場合には、通話を既存公衆網に迂回する機能等が開発されている。
【０００４】
上記のようなネットワークの構成例を図２１に示す。このネットワークでは、ＶＯＩＰ対応ＰＢＸ（Ｐｒｉｖａｔｅ  Ｂｒａｎｃｈ  ｅＸｃｈａｎｇｅ）６５（通信交換管理装置）が任意の時間間隔でゲートキーパ装置６１（ＩＰネットワーク管理装置）に擬似問合せを行い、その応答の有無をチェックすることによって、ゲートキーパ装置６１の動作状態を把握し、非動作状態であった場合に複数の通信端末６６にその旨を通知することを特徴としている。
【０００５】
図２１において、ＩＰネットワーク６００にはゲートキーパ装置６１と、Ｈ．３２３端末６２と、公衆網７００が接続されるゲートウェイ装置６３と、予備ゲートキーパ装置６４と、通信端末６６が接続されるＶＯＩＰ対応ＰＢＸ６５と、ルータ装置６８を介してＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）６９が接続されるダイヤルアップルータ装置６７とが接続されている。
【０００６】
通信端末６６にはＩＰネットワーク６００を通じた通信の起動のためのキーが設けられており、回線障害がＩＰネットワーク６００で発生していることを認識する。ＩＰネットワーク障害が発生した場合には、ゲートキーパ装置６１を設けずに、呼設定送信を行うモードに切替え、ＶＯＩＰ対応ＰＢＸ６５は任意の時間間隔にてゲートキーパ装置６１に問合せを行い、その有無をチェックし、非動作と認識した場合には予備ゲートキーパ装置６４に切替える。
【０００７】
そして、動作していないと判断しているゲートキーパ装置６１から動作状態である旨受信した場合には、ゲートキーパ装置６１を切戻す。また、ゲートキーパ装置６１なしでも、ＶＯＩＰ対応ＰＢＸ６５にてアドレスを解決できる機能も有している。
【０００８】
この効果としては、ＶＯＩＰが使用不能である時には、そのことを使用者に事前に知らせることができ、また長時間待つことなしにＶＯＩＰ回線が使用不能であるのを知らせることができるともとに、さらにゲートキーパ装置６１が非動作状態になったとしても予備ゲートキーパ装置６４を使用するように、ＶＯＩＰ対応ＰＢＸ６５にてアドレス解決を自動的に実施することができる（例えば、特許文献１参照）。
【０００９】
【特許文献１】特開２００３−１１０７４１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述した従来の監視方法では、リアルタイム性を保障しなければならない音声にあって、障害情報がその通話に関連しているのか、関連していないのか、または発生時間が通話時間と一致しているのか等の各種情報が連携していない。
【００１１】
そして、従来のＶＯＩＰネットワークはデータ系をベースとしているため、レイヤ２、レイヤ３スイッチ（以降、ＳＷとする）やルータにＱＯＳ（Ｑｕａｌｉｔｙ  Ｏｆ  Ｓｅｒｖｉｃｅ）機能を搭載してＶＯＩＰの品質を維持している。そのため、従来のＶＯＩＰネットワークでは、ＳＷやルータのリソース不足によるパケット廃棄や、ルーティングテーブル変更、ＳＷの学習テーブルの変更等が発生した時点で音声品質は低下してしまう可能性がある。その改善策としては高機能なルータやＳＷを採用したり、冗長構成をとることが考案されているが、費用対効果の面で十分な効果が期待できない場合もある。
【００１２】
また、従来のＶＯＩＰネットワークでは、事前ネットワーク監視やヘルスチェック機能による場合、断続的なネットワーク障害や予告なしの障害に対応することができないため、バースト的に発生する障害等が見つけにくいという問題がある。
【００１３】
さらに、従来のＶＯＩＰネットワークでは、障害発生を使用者に通知するという目的はあるが、障害を検出するために任意の時間間隔でゲートキーパに問合せを行っているため、リアルタイムで障害を検出することが方式的に難しいという問題がある。
【００１４】
そこで、本発明の目的は上記の問題点を解消し、ネットワークのどの部分で障害が発生しているかを特定することができ、障害の解析時間を大幅に短縮することができるネットワーク及びそれに用いるＶＯＩＰ障害発生通知方法を提供することにある。
【課題を解決するための手段】
【００１５】
本発明によるネットワークは、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を構成する複数のネットワーク装置と、前記ネットワーク装置を介してＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続する音声ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）端末と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網を前記ＷＡＮに接続するゲートウェイ装置と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網及び既存端末を前記ＷＡＮに接続するＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）交換装置とを含むネットワークであって、
前記ネットワーク装置と音声ＩＰ端末とゲートウェイ装置とＶＯＩＰ交換装置とにそれぞれ、通話中の音声パケットを監視して実時間で障害情報を検出する障害検出手段と、前記障害検出手段の障害情報を基に障害発生を他装置に通知する通知手段と、障害内容を可聴信号にて通知する可聴音通知手段と、前記障害情報を保持する保持手段とを備え、
前記ネットワーク装置と前記音声ＩＰ端末と前記ゲートウェイ装置と前記ＶＯＩＰ交換装置とにおいて通話開始から通話終了までの実時間にて装置間で連携して障害監視と障害通知とを行っている。
【００１６】
本発明によるＶＯＩＰ障害発生通知方法は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を構成する複数のネットワーク装置と、前記ネットワーク装置を介してＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続する音声ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）端末と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網を前記ＷＡＮに接続するゲートウェイ装置と、前記ネットワーク装置を介して前記ＷＡＮに接続されかつ公衆網及び既存端末を前記ＷＡＮに接続するＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）交換装置とを含むネットワークのＶＯＩＰ障害発生通知方法であって、
前記ネットワーク装置と音声ＩＰ端末とゲートウェイ装置とＶＯＩＰ交換装置とのそれぞれに、通話中の音声パケットを監視して実時間で障害情報を検出する第１のステップと、前記第１のステップの障害情報を基に障害発生を他装置に通知する第２のステップと、障害内容を可聴信号にて通知する第３のステップと、前記障害情報を保持手段に保持する第４のステップを備え、
前記ネットワーク装置と前記音声ＩＰ端末と前記ゲートウェイ装置と前記ＶＯＩＰ交換装置とにおいて通話開始から通話終了までの実時間にて装置間で連携して障害監視と障害通知とを行っている。
【００１７】
すなわち、本発明のネットワークは、公衆網とＷＡＮ［Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：広域ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク］とＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：ローカルネットワーク）の範囲にて適用されるＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークにおいて、ＬＡＮを構成する複数のネットワーク装置に、ＷＡＮと複数の音声ＩＰ端末と公衆網を中継して制御するゲートウェイ装置と既存端末及び公衆網を中継して制御するＶＯＩＰ交換装置とが接続され、ＷＡＮ上に存在して音声ＩＰ端末やゲートウェイ装置やＶＯＩＰ交換装置の呼接続処理やネットワーク装置の障害情報を集中管理する呼処理サーバ装置を備えている。
【００１８】
ネットワーク装置は、通話中の音声パケットを監視して実時間で障害情報を検出する障害検出機能と、該障害検出機能の障害情報を基に障害発生を通話ルートに存在する装置（以下、他の装置とする）に送付する機能と、障害内容の重要度を可聴信号にて通知する可聴音通知機能と、障害情報を保持する機能と、ネットワーク装置間にてＩＰパケットが通過するメインルートの他に障害情報を受け渡すための通知ルートとを具備している。
【００１９】
音声ＩＰ端末は、通話中の音声パケットを監視して実時間で障害情報を検出する障害検出機能と、該障害検出機能の障害情報を基に障害発生を他の装置に送付する機能と、障害内容を可聴信号にて通知する可聴音通知機能と、障害情報を保持する機能とを具備している。
【００２０】
ゲートウェイ装置は、通話中の音声パケットを監視して実時間で障害情報を検出する障害検出機能と、該障害検出機能の障害情報を基に障害発生を他の装置に送付する機能と、障害内容を可聴信号にて通知する可聴音通知機能と、障害情報を保持する機能とを具備している。
【００２１】
ＶＯＩＰ交換装置は、通話中の音声パケットを監視して実時間で障害情報を検出する障害検出機能と、該障害検出機能の障害情報を基に障害発生を他の装置に送付する機能と、障害内容を可聴信号にて通知する可聴音通知機能と、障害情報を保持する機能とを具備している。
【００２２】
本発明のネットワークは、上記のように構成されたネットワーク装置、音声ＩＰ端末、ゲートウェイ装置、ＶＯＩＰ交換装置各々において、通話開始から終了まで実時間にて装置間連携して障害監視と障害通知とを行うことを特徴としている。
【００２３】
また、ネットワーク装置、音声ＩＰ端末、ゲートウェイ装置、ＶＯＩＰ交換装置（以下、障害検出が可能な装置とする）各々は、可聴信号を送信する際に可聴音信号として通話信号と合成して通知するか可聴音制御信号として別に通知するかを選択する機能と、障害検出が可能な装置が受信側になった場合、可聴音信号をそのまま再生するか、可聴音制御信号のデータを基に可聴音を再生するかを選択する選択機能とを有している。
【００２４】
さらに、ネットワーク装置は、障害情報をメインルート及び通知ルートのどちらかに送信制御するための切替え機能と、その選択を外部から制御する機能とを具備している。
【００２５】
さらにまた、障害検出が可能な装置は、障害検出を行う際に障害の閾値を外部から制御して重障害なのか軽障害なのかを判別する機能と、重障害の場合に重障害用の可聴音信号を送付する機能と、低障害の場合に低障害用の可聴音信号を送付する機能と、可聴音信号の外部からの書換えを行う機能と、障害の段階を複数段階的に設定する機能とを具備している。
【００２６】
呼処理サーバ装置は物理的に存在しなく、論理的にソフトウェアとして存在することも、障害検出が可能な装置が保持する障害情報をＬＡＮやＷＡＮを介して外部から読出すことも可能である。
【００２７】
これによって、本発明のネットワークは、上記の問題点を解消し、時間変動やトラヒック変動と動的に変化するネットワークにあっても、監視装置や通話者に対して状態を通知し、別手段への切替え催促もしくはそのまま状態が改善するまで待機することによって、通話問題によるビジネスチャンスを失することなく、安心感を与えることが可能となる。
【発明の効果】
【００２８】
本発明は、以下に述べるような構成及び動作とすることで、ネットワークのどの部分で障害が発生しているかを特定することができ、障害の解析時間を大幅に短縮することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２９】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例によるネットワークの構成を示すブロック図である。図１において、本発明の一実施例によるネットワークはＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：ローカルネットワーク）を構成するネットワーク装置１〜３と、音声ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）端末４と、ＶＯＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）交換装置５と、既存端末６と、呼処理サーバ装置７と、ゲートウェイ装置８とから構成されている。
【００３０】
図１においては代表例として企業内ネットワークを示している。ネットワーク装置１〜３はＳＷ（スイッチ）やルータ等の機能を持つ装置であり、音声ＩＰ端末４とＶＯＩＰ交換装置５とゲートウェイ装置８とはそれぞれ最寄りのネットワーク装置１〜３に接続されている。また、ネットワーク装置２は企業ネットワークの代表としてＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：広域ＩＰネットワーク）２００に接続することで、広域通信を可能としている。
【００３１】
呼処理サーバ装置７はシステム内の番号管理等を集中的に行うための装置であり、論理的にはネットワーク上に存在しており、ＷＡＮ２００及びネットワーク装置１〜３からなるＬＡＮ内のどちらにでも設置可能となっているが、図１においてはＷＡＮ２００上に設置する構成としている。
【００３２】
呼処理サーバ装置７は基本的にＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）やサーバに専用ソフトウェアを搭載したものであり、専用ソフトウェアはＨ．３２３やＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）といった標準プロトコルや独自プロトコルにて動作し、発信制御や着信制御に関するものであり、公知の技術である。
【００３３】
音声ＩＰ端末４はＩＰ電話機やＩＰ電話機能を持つＰＣであり、通信は全てＩＰプロトコルを用いて通信制御される。ＶＯＩＰ交換装置５は従来のＰＢＸ（Ｐｒｉｖａｔｅ  Ｂｒａｎｃｈ  ｅＸｃｈａｎｇｅ）機能にＩＰインタフェース機能を備えたものであり、既存端末６との間に公衆網インタフェース機能を有する。既存端末６は従来の電話機、低速データ端末等を示しており、ＶＯＩＰ交換装置５を介して他端末装置と接続する。
【００３４】
ゲートウェイ装置８は公衆網専用とＩＰネットワークとをインタワークする装置であり、基本的にはＶＯＩＰ交換装置５と機能的には類似しているが、規模的には大きく、局用対応という機能差はある。
【００３５】
ネットワーク装置１〜３間、ネットワーク装置１と音声ＩＰ端末４との間、ネットワーク装置１とＶＯＩＰ交換装置５との間、呼処理サーバ装置７とＷＡＮ２００との間、ネットワーク装置２とＷＡＮ２００との間、ネットワーク装置３とゲートウェイ装置８との間はそれぞれＥｔｈｅｒ（Ｒ）ネット等に代表されるレイヤ２（以下、Ｌ２とする）リンク１０１，１０２，１１１〜１１３，１２１，１２２，１３１，１４１，１５１，１６１で接続されており、レイヤ１（以下、Ｌ１とする）はＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃ  Ｅｎｇｉｎｅｅｒｓ）８０２に代表される媒体にて接続されている。
【００３６】
また、Ｌ２リンク１０１，１０２とＬ２リンク１１１，１１２とＬ２リンク１２１，１２２とはそれぞれペア接続を行っており、Ｌ２リンク１０１，１１１，１２１にそれぞれ不具合が発生した場合に、Ｌ２リンク１０２，１１２，１２２にそれぞれ切替わるような機能を有している。
【００３７】
図２は図１のネットワーク装置１〜３の構成を示すブロック図である。図２において、ネットワーク装置１〜３はＳＷ・ルーティング機能部１１と、障害検出機能部１２と、起動機能部１３と、送信機能部１４と、通知機能部１５と、可聴信号機能部１６と、時間管理機能部１７と、保持機能部１８とから構成されている。
【００３８】
ＳＷ・ルーティング機能部１１はＥｔｈｅｒ（Ｒ）フレームのスイッチング機能と、ＩＰパケット等のルーティング機能とを有しており、複数の物理回線（以下、物理ポートとする）を備えている。
【００３９】
ここで、スイッチング機能とは既に公知の事実であり、それを応用した製品は数多い。具体的にはＩＥＥＥ８０２．３に準拠しており、物理ポートに入力されるＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）フレームの中の宛先ＭＡＣアドレスを基にスイッチングするもので、物理ポート配下に存在するＭＡＣアドレス以外のパケットが入力された場合に他の物理ポートに送信し、そうでなければそのフレームを廃棄する機能等を持っている。この機能は公知であるので、その詳細な説明は省略する。
【００４０】
また、ルーティング機能はＩＰパケットのネットワークアドレス（以下、ＩＰアドレスとする）を基にルーティングするものであり、ＩＰパケットの宛先ＩＰアドレスのネットワークアドレスがどのルートに存在するのかを選択して配信するものである。その動作については公知であり、例えばダイナミックルーティング機能やスタティックルーティング機能がある。
【００４１】
ＳＷ・ルーティング機能部１１は上記の機能以外に、メインルート１０１から入力されるＩＰパケットを全て障害検出機能部１２に送出する機能と、送信機能部１４からのＩＰパケットを入力する機能と、起動機能部１３の指示によって送信機能部１４から入力するＩＰパケットとメインルート１０１，１２１から入力するＩＰパケットを選択する機能とを備えている。
【００４２】
障害検出機能部１２はＳＷ・ルーティング機能部１１から入力されるＩＰパケットのＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）部分の監視を行う機能を備えており、ネットワーク装置における障害検出動作を行っている。例えば、ＲＴＰの障害を発見した場合には、起動機能部１３に障害発生通知２１２を起動し、同時に通知機能部１５に対して障害情報と障害が発生しているＩＰパケット２１３とを送信する。
【００４３】
起動機能部１３は障害検出機能部１２からの障害発生通知２１２を入力した場合に起動信号２１４をＳＷ・ルーティング機能部１１に送出する機能を備えている。送信機能部１４は通知機能部１５からのＩＰパケット２１６をＩＰパケット２１５としてＳＷ・ルーティング機能部１１に送信する機能を備えている。
【００４４】
通知機能部１５はＨ．２４５開設要求とＨ．２４５開設許可とによって通信が開始されたことを認識する機能と、障害が発生しているＩＰパケット２１３を受信した場合に時間管理機能部１７から障害が発生した時間情報２１８を受取り、その時間情報と障害情報とを一体化した情報２１９を保持機能部１８に送出する機能と、可聴信号機能部１６からの可聴音データ２１７と障害が発生しているＩＰパケット２１３内のデータ部とを合成する機能と、その可聴音ＩＰパケットをカプセリングした信号２１６を送信機能部１４に送出する機能とを備えている。
【００４５】
可聴音データとＩＰパケット内のデータとの合成方法については公知であり、既存ＰＢＸのカンファレンストランクで良く知られている。合成動作としてはＩＰパケット内のデータをいったんＧ．７１１（６４ＫＰＣＭ信号）に変換し、その変換したデータにＧ．７１１データである可聴音信号をアナログ的に合成し、変換前の圧縮データに戻してＩＰパケットへのカプセリングを行う。ＩＰパケット上の音声データはＧ．７１１の他に、Ｇ．７２９Ａ、Ｇ．７２３．１等の音声圧縮が使用されている。
【００４６】
また、通知機能部１５はＩＰパケット２１３を障害検出機能部１２から受信した際のジッタ吸収用の少量のバッファを備え、このバッファを用いて内部処理のタイミングを調整する機能を備えている。
【００４７】
可聴音機能部１６は音声アナウンス用のメッセージやＰＢ（Ｐｕｓｈ  Ｂｕｔｔｏｎ）信号等の人間が可聴できる可聴データを保持しており、通知機能部１５の指示にしたがって可聴音データ２１７を通知機能部１５に送出する。実際には、“ルータ番号１です。現在ネットワークの問題により音声品質が低下しております”や“ルータ２です。重要な通信である場合は迂回機能等をお使い下さい”等のメッセージが蓄積されている。また、ＰＢ信号である場合には、“ピピピ“という固定音の連続とする。可聴音が保有する音源の切替え制御は可聴信号機能部１６に対する通知機能部１５からの指示に応じて行われる。
【００４８】
時間管理機能部１７は標準時間の時計を管理しており、通知機能部１５からの指示にしたがって時間情報２１８を通知機能部１５に送出する機能を備えている。保持機能部１８は通知機能部１５からの情報２１９を保持するデータベース機能を備えている。この保持情報２１９は通知機能部１５を経由してＬＡＮとＷＡＮ２００とにアクセスする装置によって読出しが可能である。
【００４９】
図３は本発明の一実施例で用いるＭＡＣフレーム及びＩＰパケットの構造を示す図である。図３（ａ）において、ＬＡＮやＷＡＮ上を流れるフレームのＬ２レベルはＭＡＣフレームの構成になっており、ＭＡＣ  ＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓ）、ＭＡＣ  ＳＡ（Ｓｏｕｒｃｅ  ａｄｄｒｅｓｓ）、Ｔｙｐｅ、ＩＰ  Ｄａｔａｇｒａｍ、ＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）からなっている。この構成はＩＥＥＥ８０２．３で規定されているもので、公知である。
【００５０】
ＭＡＣ  ＤＡは宛先ＭＡＣアドレスを、ＭＡＣ  ＳＡは発信元ＭＡＣアドレスをそれぞれ示しており、各装置がＭＡＣフレームを引取る場合には、そのＭＡＣアドレスが自分宛であるかを確認している。
【００５１】
ＩＰ  ＤａｔａｇｒａｍはＩＰパケット［図３（ｂ）参照］と呼ばれている部分であり、その中身はＩＰヘッダ、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ヘッダ、ＲＴＰヘッダ［図３（ｃ）参照］、ＶＯＩＣＥ（音声）からなっている。
【００５２】
ＩＰヘッダはＳｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓ（発信元ＩＰアドレス）、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓ（宛先ＩＰアドエス）を含んでおり、各装置はＩＰパケットを引取る場合、その宛先ＩＰアドレスが自分と一致しているかを確認している。
【００５３】
同様に、ＵＤＰヘッダ内もＳｏｕｒｃｅ  Ｐｏｒｔ  ｎｕｍｂｅｒ（発信元ポート番号）、Ｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ  ｎｕｍｂｅｒ（宛先ポート番号）を含んでおり、各装置はＲＴＰパケットを引取る場合、その宛先ポート番号が自分と一致しているかを確認している。
【００５４】
ＲＴＰヘッダ内にはデータ識別子やシーケンス番号を含んでおり、データ識別子にはこの音声が圧縮されているのか、そうである場合にはどういう圧縮方式なのかを示すデータが入っている。このデータ識別子を基に音声データの再生が行われる。また、シーケンス番号はＲＴＰパケットの順序番号が入っており、通常であれば１，２，３，・・・の順番で入力される予定であるが、１，３となった場合、２のパケットがＬＡＮやＷＡＮ２００でロスしたことを検出している。このシーケンス番号は、音声に用いられるため、ＲＴＰパケットの順序性を保証したものである。
【００５５】
図４は図１の音声ＩＰ端末４の構成を示すブロック図である。図４において、音声ＩＰ端末４は通知機能部４０と、ＣＰＵ（中央処理装置）部４１と、ＭＡＣ機能部４２と、ＩＰパケット化機能部４３と、ＲＴＰ制御部４４と、ＰＣＭ（Ｐｕｌｓｅ  Ｃｏｄｅ  Ｍｏｄｕｌａｔｉｏｎ）制御部４５と、既存電話制御部４６と、可聴信号制御部４７と、保持機能部４８と、時間管理機部４９とから構成されている。
【００５６】
ＣＰＵ部４１は音声ＩＰ端末装置４を集中管理する機能を有しており、各機能部の動作制御やＣＰＵバス４１１を介したデータ転送制御を行っている。また、ＣＰＵ部４１は外部インタフェース４１２を有しており、各機能部の状態監視情報を外部に通知することや各機能部への動作条件等を設定することが可能である。
【００５７】
ＭＡＣ機能部４２はＬ２リンク１３１のＬＡＮから入力されるＥｔｈｅｒ（Ｒ）フレームのフィルタリングを行い、そのフレームが自分宛である場合にそのフレームからＩＰパケットを抽出し、このＩＰパケットをＣＰＵ部４１を経由してＩＰパケット化機能部４３に送信する。
【００５８】
また、ＭＡＣ機能部４２はＣＰＵ部４１の指示によってＩＰパケット化機能部４３からのＩＰパケットをＭＡＣフレームにカプセリングしてＬ２リンク１３１に送出する機能を有している。ＭＡＣ機能部４２の制御としては、基本的にＩＥＥＥ８０２のＬ１制御とＬ２制御とが行われている。
【００５９】
ＩＰパケット化機能部４３はＭＡＣ機能部４２のＩＰパケットからＲＴＰパケットを取出し、ＣＰＵ部４１の制御によってＲＴＰ制御部４４にＲＴＰパケットを引き渡す。その際、ＩＰパケット化機能部４３は自端末宛のＩＰパケットであることを確認している。
【００６０】
また、ＩＰパケット化機能部４３はＣＰＵ部４１の指示によってＲＴＰ制御部４４からのＲＴＰパケットをＩＰパケット化し、そのＩＰパケットのＭＡＣフレーム機能部４２への引渡しを行っている。
【００６１】
ＲＴＰ制御部４４はＩＰパケット化機能部４３からのＲＴＰパケットをいったんジッタ吸収バッファにて取込み、音声を再生するための処理を行う。ジッタ吸収バッファはＲＴＰパケットを数パケット蓄積し、再生する連続性を保証するための機能であり、その機能は公知である。
【００６２】
例えば、ペイロード周期としてバッファを取出し、ＣＰＵ部４１の制御によってＲＴＰ制御部４４に対してＲＴＰパケットのパケット間隔を示すペイロード周期が４０ｍｓｅｃである場合、ジッタ吸収バッファのサイズは２パケット、８０ｍｓｅｃ分が一般的であり、そのサイズはＬＡＮやＷＡＮ２００でのパケット間隔変動分が適用される。ジッタ吸収バッファが深いサイズである場合には、遅延時間に影響する。
【００６３】
ジッタ吸収バッファはＩＰパケットのポート番号単位（いわゆる回線数）に応じて論理的に存在しており、その蓄積が完了した時点で音声データがＰＣＭ制御部４５に対して連続的に送出される。ＰＣＭ制御部４５への音声データ４１３は時分割バスに代表される構成となっており、数回線分、同時処理が行われる。また、ＰＣＭ制御部４５からＲＴＰ制御部４４に送信される音声データ４１３は、順次ある一定量を基準にＲＴＰパケット化され、その後、ＣＰＵ部４１によってＩＰパケット化機能部４３に送出される。
【００６４】
ＰＣＭ制御部４５は音声圧縮機能と伸張機能とを持ち、音声圧縮の方式にしたがってそのデータをＰＣＭ信号に変換する機能を有している。ＲＴＰ制御部４４から入力された音声データ４１３は、そのままでは人間の耳に聞こえないため、ＰＣＭ制御部４５にて伸張されて音声信号４１４として既存電話制御部４６に送出される。音声信号４１４上は６４ＫＰＣＭデータとして統一されている。
【００６５】
また、既存電話制御部４６からの音声信号４１４はＰＣＭ制御部４５に入力され、そこで音声圧縮処理が行われ、ＲＴＰ制御部４４に音声データ４１３として送出される。音声圧縮処理を行う場合には、可聴信号制御部４８から可聴音信号４１５があれば、その可聴音信号４１５と音声信号４１４とを合成して音声データ４１３としてＲＴＰ制御部４４に送出する。
【００６６】
可聴音データとＩＰパケット内のデータとの合成については公知であり、既存ＰＢＸのカンファレンストランクで良く知られており、ＩＰパケット内のデータをいったんＧ．７１１（６４ＫＰＣＭ信号）に変換し、その変換したデータとＧ．７１１データである可聴音信号とをアナログ的に合成する。音声信号の圧縮方式にはＧ．７１１の他に、Ｇ．７２９Ａ、Ｇ．７２３．１等が使用されている。
【００６７】
既存電話制御部４６は音声信号をハンドセット（図示せず）に送出する機能と、ハンドセットからの音声信号をＰＣＭ制御部４５に送出する機能とを有しており、いわゆる既存電話機の受話器に相当する。
【００６８】
通知機能部４０は障害発生通知を各機能部からＣＰＵバス４１１を介して受信した場合、時間管理機能部４９から障害が発生した時間情報４１６を受取り、その時間情報４１６と障害発生通知情報とを一体化して保持機能部４８に送出する。
【００６９】
可聴音機能部４７は音声アナウンス用のメッセージやＰＢ信号等の人間が可聴できる可聴データを保持しており、通知機能部４０からの要求に対するＣＰＵ部４１からの指示に基づいて可聴音信号４１５をＰＣＭ制御部４５に送出する。
【００７０】
実際には、“ＩＰ端末４です。現在ネットワークの問題により音声品質が低下しております”や“ＩＰ端末です。重要な通信である場合は迂回機能等をお使い下さい”等のメッセージが蓄積されている。また、ＰＢ信号である場合には“ピピピ“という固定音の連続が蓄積されている。可聴音が保有する音源の切替え制御は通知機能部４０がＣＰＵ部４１に対して要求を出すことで、ＣＰＵ部４１から可聴信号制御部４７に対して出力される指示にしたがって行われる。
【００７１】
時間管理部４９は標準時間の時計を管理しており、通知機能部４０の指示によって時間情報４１６を通知機能部４０に送出する機能を有している。保持機能部４８は通知機能部４０からの障害発生情報を保持するデータベース機能である。この障害発生情報はＬＡＮとＷＡＮ２００とにアクセスする装置によっても読出しが可能である。
【００７２】
図５は図１のＶＯＩＰ交換装置５の構成を示すブロック図である。図５において、ＶＯＩＰ交換装置５は通知機能部５０と、ＣＰＵ部５１と、ＭＡＣ機能部５２と、ＩＰパケット化機能部５３と、ＲＴＰ制御部５４と、ＰＣＭ制御部５５と、既存回線制御部５６と、可聴信号制御部５７と、保持機能部５８と、時間管理機部５９と、既存端末６１，６２とから構成されている。
【００７３】
ＣＰＵ部５１はＶＯＩＰ交換装置５を集中管理する機能を有しており、各機能部の動作制御やＣＰＵバス５１１を介したデータ転送制御を行っている。また、ＣＰＵ部５１は外部インタフェース５１２を有しており、各機能部の状態監視情報を外部に通知することや各機能部への動作条件等を設定することが可能である。
【００７４】
ＭＡＣ機能部５２はＬ２リンク１４１のＬＡＮから入力されるＥｔｈｅｒ（Ｒ）フレームのフィルタリングを行い、自装置宛である場合にはそのフレームからＩＰパケットを抽出し、そのＩＰパケットをＣＰＵ部５１を経由させてＩＰパケット化機能部５３に送信する。
【００７５】
また、ＭＡＣ機能部５２はＣＰＵ部５１の指示によってＩＰパケット化機能部５３からのＩＰパケットをＭＡＣフレームにカプセリングしてＬ２リンク１４１に送出する機能を有している。ＭＡＣ機能部５２の制御としては、基本的にＩＥＥＥ８０２のＬ１制御とＬ２制御とが行われている。
【００７６】
ＩＰパケット化機能部５３はＭＡＣ機能部５２のＩＰパケットからＲＴＰパケットを取出し、ＣＰＵ部５１の制御によってＲＴＰ制御部５４にＲＴＰパケットを引き渡す。その際、ＩＰパケット化機能部５３は自装置宛のＩＰパケットであることを確認している。
【００７７】
また、ＩＰパケット化機能部５３はＣＰＵ５１の指示によってＲＴＰ制御部５４からのＲＴＰパケットをＩＰパケット化し、そのＩＰパケットのＭＡＣフレーム機能部５２への引渡しを行っている。
【００７８】
ＲＴＰ制御部５４はＩＰパケット化機能部５３からのＲＴＰパケットをいったんジッタ吸収バッファにて取込み、音声を再生するための処理を行う。ジッタ吸収バッファはＲＴＰパケットを数パケット蓄積し、再生する連続性を保証するための機能であり、その機能は公知である。
【００７９】
例えば、ペイロード周期としてバッファを取出し、ＣＰＵ部５１の制御によってＲＴＰ制御部５４に対してＲＴＰパケットのパケット間隔を示すペイロード周期が４０ｍｓｅｃである場合、ジッタ吸収バッファのサイズは２パケット、８０ｍｓｅｃ分が一般的であり、そのサイズはＬＡＮやＷＡＮ２００でのパケット間隔変動分が適用される。ジッタ吸収バッファが深いサイズである場合には、遅延時間に影響してしまう。
【００８０】
ジッタ吸収バッファはＩＰパケットのポート番号単位（いわゆる回線数）に応じて論理的に存在しており、その蓄積が完了した時点で音声データがＰＣＭ制御部５５に対して連続的に送出される。ＰＣＭ制御部５５への音声データ５１３は時分割バスに代表される構成となっており、数回線分、同時処理が行われる。また、ＰＣＭ制御部５５からＲＴＰ制御部５４に送信される音声データ５１３は、順次ある一定量を基準にＲＴＰパケット化され、その後、ＣＰＵ部５１によってＩＰパケット化機能部５３に送出される。
【００８１】
ＰＣＭ制御部５５は音声圧縮機能と伸張機能とを持ち、音声圧縮の方式にしたがってそのデータをＰＣＭ信号に変換する機能を有している。ＲＴＰ制御部５４から入力された音声データ５１３は、そのままでは人間の耳に聞こえないため、ＰＣＭ制御部５５にて伸張されて音声信号５１４として既存回線制御部５６に送出される。音声信号５１４上は６４ＫＰＣＭデータとして統一されている。
【００８２】
また、既存回線制御部５６からの音声信号５１４はＰＣＭ制御部５５に入力され、そこで音声圧縮処理が行われ、ＲＴＰ制御部５４に音声データ５１３として送出される。音声圧縮処理を行う場合には、可聴信号制御部５８から可聴音信号５１５があれば、その可聴音信号５１５と音声信号５１４とを合成して音声データ５１３としてＲＴＰ制御部５４に送出される。
【００８３】
可聴音データとＩＰパケット内のデータとの合成については公知であり、既存ＰＢＸのカンファレンストランクで良く知られており、ＩＰパケット内のデータをいったんＧ．７１１（６４ＫＰＣＭ信号）に変換し、その変換したデータとＧ．７１１データである可聴音信号とをアナログ的に合成する。音声信号の圧縮方式にはＧ．７１１の他に、Ｇ．７２９Ａ、Ｇ．７２３．１等が使用されている。
【００８４】
既存回線制御部５６には既存端末６１，６２が接続されており、既存端末６１，６２の発信番号制御と、着信番号制御、音声の通話スイッチング制御とを行う機能を有しており、企業内の回線数をカバーできる機能を有している。基本的に、既存回線制御部５６は既存ＰＢＸ機能であり、その技術は公知である。
【００８５】
既存端末６１，６２が自局内相手と通話する場合には、音声信号がＰＣＭ制御部５５を経由してＬＡＮやＷＡＮ２００に送出される。通信相手からの音声信号はＶＯＩＰ交換装置５向けとなる。
【００８６】
通知機能部５０は障害発生通知を各機能部からＣＰＵバス５１１を介して受信した場合、時間管理機能部５９から障害が発生した時間情報５１６を受取り、その時間情報５１６と障害発生通知情報とを一体化して保持機能部５８に送出する。
【００８７】
可聴音機能部５７は音声アナウンス用のメッセージやＰＢ信号等の人間が可聴できる可聴データを保持しており、通知機能部５０からの要求に対してＣＰＵ部５１からの指示に基づいて可聴音信号５１５をＰＣＭ制御部５５に送出する。
【００８８】
実際には、“ＶＯＩＰ交換装置５です。現在ネットワークの問題により音声品質が低下しております”や“ＶＯＩＰ交換装置５です。重要な通信である場合は迂回機能等をお使い下さい”等のメッセージが蓄積されている。また、ＰＢ信号である場合には“ピピピ“という固定音の連続が蓄積されている。可聴音が保有する音源の切替え制御は通知機能部５０がＣＰＵ部５１に対して要求を出すことで、ＣＰＵ部５１から可聴信号制御部５７に対して出力される指示にしたがって行われる。
【００８９】
時間管理部５９は標準時間の時計を管理しており、通知機能部５０の指示によって時間情報５１６を通知機能部５０に送出する機能を有している。保持機能部５８は通知機能部５０からの障害発生情報を保持するデータベース機能である。この障害発生情報はＬＡＮとＷＡＮ２００とにアクセスする装置によっても読出しが可能である。
【００９０】
図６は図１のゲートウェイ装置８の構成を示すブロック図である。図６において、ゲートウェイ装置８は通知機能部８０と、ＣＰＵ部８１と、ＭＡＣ機能部８２と、ＩＰパケット化機能部８３と、ＲＴＰ制御部８４と、ＰＣＭ制御部８５と、回線制御部８６と、可聴信号制御部８７と、保持機能部８８と、時間管理機部８９とから構成されている。
【００９１】
ＣＰＵ部８１はゲートウェイ装置８を集中管理する機能を有しており、各機能部の動作制御やＣＰＵバス８１１を介したデータ転送制御を行っている。また、ＣＰＵ部８１は外部インタフェース８１２を有しており、各機能部の状態監視情報を外部に通知することや各機能部への動作条件等を設定することが可能である。
【００９２】
ＭＡＣ機能部８２はＬ２リンク１６１のＬＡＮから入力されるＥｔｈｅｒ（Ｒ）フレームのフィルタリングを行い、自装置宛である場合にはそのフレームからＩＰパケットを抽出し、そのＩＰパケットをＣＰＵ部８１を経由させてＩＰパケット化機能部８３に送信する。
【００９３】
また、ＭＡＣ機能部８２はＣＰＵ部８１の指示によってＩＰパケット化機能部８３からのＩＰパケットをＭＡＣフレームにカプセリングしてＬ２リンク１６１に送出する機能を有している。ＭＡＣ機能部８２の制御としては、基本的にＩＥＥＥ８０２のＬ１制御とＬ２制御とが行われている。
【００９４】
ＩＰパケット化機能部８３はＭＡＣ機能部８２のＩＰパケットからＲＴＰパケットを取出し、ＣＰＵ部８１の制御によってＲＴＰ制御部８４にＲＴＰパケットを引き渡す。その際、ＩＰパケット化機能部８３は自装置宛のＩＰパケットであることを確認している。
【００９５】
また、ＩＰパケット化機能部８３はＣＰＵ８１の指示によってＲＴＰ制御部８４からのＲＴＰパケットをＩＰパケット化し、そのＩＰパケットのＭＡＣフレーム機能部８２への引渡しを行っている。
【００９６】
ＲＴＰ制御部８４はＩＰパケット化機能部８３からのＲＴＰパケットをいったんジッタ吸収バッファにて取込み、音声を再生するための処理を行う。ジッタ吸収バッファはＲＴＰパケットを数パケット蓄積し、再生する連続性を保証するための機能であり、その機能は公知である。
【００９７】
例えば、ペイロード周期としてバッファを取出し、ＣＰＵ部８１の制御によってＲＴＰ制御部８４に対してＲＴＰパケットのパケット間隔を示すペイロード周期が４０ｍｓｅｃである場合、ジッタ吸収バッファのサイズは２パケット、８０ｍｓｅｃ分が一般的であり、そのサイズはＬＡＮやＷＡＮ２００でのパケット間隔変動分が適用される。ジッタ吸収バッファが深いサイズである場合には、遅延時間に影響してしまう。
【００９８】
ジッタ吸収バッファはＩＰパケットのポート番号単位（いわゆる回線数）に応じて論理的に存在しており、その蓄積が完了した時点で音声データがＰＣＭ制御部８５に対して連続的に送出される。ＰＣＭ制御部８５への音声データ８１３は時分割バスに代表される構成となっており、数回線分、同時処理が行われる。また、ＰＣＭ制御部８５からＲＴＰ制御部８４に送信される音声データ８１３は，順次ある一定量を基準にＲＴＰパケット化され、その後、ＣＰＵ部８１によってＩＰパケット化機能部８３に送出される。
【００９９】
ＰＣＭ制御部８５は音声圧縮機能と伸張機能とを持ち、音声圧縮の方式にしたがってそのデータをＰＣＭ信号に変換する機能を有している。ＲＴＰ制御部８４から入力された音声データ８１３は、そのままでは人間の耳に聞こえないため、ＰＣＭ制御部８５にて伸張されて音声信号８１４として回線制御部８６に送出される。音声信号８１４上は６４ＫＰＣＭデータとして統一されている。
【０１００】
また、回線制御部８６からの音声信号８１４はＰＣＭ制御部８５に入力され、そこで音声圧縮処理が行われ、ＲＴＰ制御部８４に音声データ８１３として送出される。音声圧縮処理を行う場合には、可聴信号制御部８８から可聴音信号８１５があれば、その可聴音信号８１５と音声信号８１４とを合成して音声データ８１３としてＲＴＰ制御部８４に送出される。
【０１０１】
可聴音データとＩＰパケット内のデータとの合成については公知であり、既存ＰＢＸのカンファレンストランクで良く知られており、ＩＰパケット内のデータをいったんＧ．７１１（６４ＫＰＣＭ信号）に変換し、その変換したデータとＧ．７１１データである可聴音信号とをアナログ的に合成する。音声信号の圧縮方式にはＧ．７１１の他に、Ｇ．７２９Ａ、Ｇ．７２３．１等が使用されている。
【０１０２】
回線制御部８６は音声信号を既存公衆網３０２に送出する機能と、既存公衆網３０２からの音声信号をＰＣＭ制御部８５に送出する機能とを有しており、いわゆる既存網とのインタワークを行う公衆側の交換機相当の機能を有している。
【０１０３】
通知機能部８０は障害発生通知を各機能部からＣＰＵバス８１１を介して受信した場合、時間管理機能部８９から障害が発生した時間情報８１６を受取り、その時間情報８１６と障害発生通知情報とを一体化して保持機能部８８に送出する。
【０１０４】
可聴音機能部８７は音声アナウンス用のメッセージやＰＢ信号等の人間が可聴できる可聴データを保持しており、通知機能部８０からの要求に対してＣＰＵ部８１から指示に基づいて可聴音信号８１５をＰＣＭ制御部８５に送出する。
【０１０５】
実際には、“ゲートウェイ装置８です。現在ネットワークの問題により音声品質が低下しております”や“ゲートウェイ装置８です。重要な通信である場合は迂回機能等をお使い下さい”等のメッセージが蓄積されている。また、ＰＢ信号である場合には“ピピピ“という固定音の連続が蓄積されている。可聴音が保有する音源の切替え制御は通知機能部８０がＣＰＵ部８１に対して要求を出すことで、ＣＰＵ部８１から可聴信号制御部８７に対して出力される指示にしたがって行われる。
【０１０６】
時間管理部８９は標準時間の時計を管理しており、通知機能部８０の指示によって時間情報８１６を通知機能部８０に送出する機能を有している。保持機能部８８は通知機能部８０からの障害発生情報を保持するデータベース機能である。この障害発生情報はＬＡＮとＷＡＮ２００とにアクセスする装置によっても読出しが可能である。
【０１０７】
図７は本発明の一実施例による各装置間の障害検出動作を示すシーケンスチャートである。これら図１〜図７を参照して本発明の一実施例による各装置間の障害検出動作について説明する。
【０１０８】
図７において、Ａ，Ｂ，Ｃ，Ｄ，Ｅは時刻を示しており、後述する音声ＩＰ端末４の障害情報、ネットワーク装置２における障害情報、ネットワーク装置１における障害情報の記録情報と連携している。
【０１０９】
以下、障害検出動作を説明するために、音声ＩＰ端末４とゲートウェイ装置８との間にて通信を行う時に、音声ＩＰ端末４内と、ネットワーク装置１、ネットワーク装置２、ゲートウェイ装置８、呼処理サーバ装置７がどのよう動作しているのかを説明するとともに、音声ＩＰ端末４内の通知機能部４０と、ネットワーク装置１内の通知機能部１５、ネットワーク装置２内の通知機能部１５、ゲートウェイ装置８内の通知機能部８０（以下、各装置内の通知機能部とする）がどのように障害を検出するのかについて説明する。
【０１１０】
通常の発信動作において、音声ＩＰ端末４は「１２３４番」とし、ゲートウェイ装置８の公衆に「５６７８番」が存在するものと仮定する。音声ＩＰ端末４のＩＰアドレスは「１０．１０．１０．１」、使用ポート番号を「１０２４」とする。また、ゲートウェイ装置８のＩＰアドレスを「１０．２０．５．０」、使用ポート番号を「５１２」とする。
【０１１１】
音声ＩＰ端末４が「５６７８」とダイヤルすると、接続要求が呼処理サーバ装置７に送出される（図７のａ１）。この情報には「５６７８番」を検索し、「５６７８番」が通話可能状態であるかどうかを確認する内容が入っている。呼処理サーバ装置７には電話番号に対するＩＰアドレスの対応表があり、それを用いて検索することができる。
【０１１２】
呼処理サーバ装置７は「５６７８番」がゲートウェイ装置８の配下にあることを認識することができるため、ゲートウェイ装置８の通信が可能である場合、ＩＰアドレス「１０．２０．５．０」、使用ポート番号「５１２」を接続許可として音声ＩＰ端末４に返信する（図７のａ２〜ａ４）。ゲートウェイ装置８は公衆網３０２のインタフェースを有しているため、基本的には「５６７８番」が通話中なのかどうかを判断してはいない。
【０１１３】
次に、音声ＩＰ端末４はゲートウェイ装置８と通信コネクションを張るため、Ｈ．２４５開設要求を送出する（図７のａ５）。この情報は公知のものであり、音声圧縮の種類やペイロード周期のネゴシエーションを行う。音声ＩＰ端末４は、例えば音声圧縮がＧ．７１１、ペイロード周期が４０ｍｓｅｃという要求を出す。
【０１１４】
これに対して、ゲートウェイ装置８はＲＴＰ制御部８４の受信制御をこの設定に合わせる。ペイロード周期が４０ｍｓｅｃであることは、ＲＴＰパケットが少なくとも４０ｍｓｅｃの間隔をもって受信されることを意味するため、ゲートウェイ装置８はそうでない場合に障害が発生することを認識している。そして、ゲートウェイ装置８は資源管理上、問題が無い場合にＨ．２４５開設許可を音声ＩＰ端末４に送出する（図７のａ６）。
【０１１５】
音声ＩＰ端末４は通話者に対してリングバックトーン等の通知を行い、ゲートウェイ装置８は「５６７８番」に対してリンギング指示を行う。「５６７８番」が通話可能になった段階で、ゲートウェイ装置８は通話要求を呼処理サーバ装置７に送出し（図７のａ７）、呼処理サーバ装置７は音声ＩＰ端末４とゲートウェイ装置８とにそれぞれ通話許可を出す（図７のａ８，ａ９）。
【０１１６】
この時点で、音声ＩＰ端末４によるリングバックトーンとゲートウェイ装置８によるリンギング指示とが停止される。呼処理サーバ装置７はこの時点から課金等の処理を開始する。
【０１１７】
音声ＩＰ端末４は通話者の音声信号をＩＰパケット化し、ネットワーク装置１に送出する（図７のａ１０）。ネットワーク装置１はＩＰパケットの宛先ＩＰアドレス「１０．２０．５．０」を見て、そのＩＰアドレスがネットワーク装置２側にいることを認識し、ネットワーク装置２に送出する（図７のａ１１）。
【０１１８】
ネットワーク装置２はＩＰパケットの宛先ＩＰアドレス「１０．２０．５．０」を見て、そのＩＰアドレスがゲートウェイ装置８であることを認識し、ゲートウェイ装置８に送出する（図７のａ１２）。そして＜この通信は通話が終了するまで継続する。
【０１１９】
また、ゲートウェイ装置８は公衆網３０２側の音声信号をＩＰパケット化し、ネットワーク装置２に送出する（図７のａ１９）。ネットワーク装置２はＩＰパケットの宛先ＩＰアドレス「１０．１０．１０．１」を見て、そのＩＰアドレスがネットワーク装置１側にいることを認識し、ネットワーク装置１に送出する（図７のａ２０）。
【０１２０】
ネットワーク装置１はＩＰパケットの宛先ＩＰアドレス「１０．１０．１０．１」を見て、そのＩＰアドレスが音声ＩＰ端末４であることを認識し、音声ＩＰ端末４に送出する（図７のａ２１）。そして、この通信は通話が終了するまで継続する。
【０１２１】
「５６７８番」が通話終了した時点で、ゲートウェイ装置８は切断要求を呼処理サーバ装置７に送出し（図７のａ２２）、呼処理サーバ装置７は音声ＩＰ端末４とゲートウェイ装置８とにそれぞれ切断指示を出す（図７のａ２３，ａ２４）。呼処理サーバ装置７はこの時点で課金等の処理を終了する。
【０１２２】
音声ＩＰ端末４はゲートウェイ装置８との通信コネクションを終了するために、Ｈ．２４５閉塞要求を送出し（図７のａ２５〜ａ２７）、ゲートウェイ装置８もこれに対してＨ．２４５閉塞許可を音声ＩＰ端末４に送出する（図７のａ２８〜ａ３０）。これによって、セッションが終了する。
【０１２３】
音声ＩＰ端末４は終話信号を呼処理サーバ７に送出し（図７のａ３１）、呼処理サーバ７も終話信号をゲートウェイ装置８に送出し（図７のａ３２）、全シーケンスが終了する。上記のシーケンスは一例であるため、Ｈ．２４５開設要求、Ｈ．２４５閉塞要求、切断指示等の方向性は場合によって異なる。
【０１２４】
次に、障害発生時の動作について説明する。ネットワーク装置１，２は音声ＩＰ端末４が送出するＨ．２４５開設要求を監視しており、その通信のセッションが開始されたことを認識する。図７中のＨ．２４５スヌープ（盗み聴く）と示した部分である。このＨ．２４５スヌープは監視を行っている間、全セッションに対して行う。これらの保持の方法については、後述するネットワーク装置２における障害情報にて説明する。
【０１２５】
図７中のＢ点において、ネットワーク装置２が音声ＩＰ端末４からのＩＰパケットの障害を検出した場合、エラー発生として認識し（図７のａ１３）、障害発生通知をネットワーク装置１と音声ＩＰ端末４とゲートウェイ装置８とに送出する（図７のａ１４〜ａ１６）。
【０１２６】
同時点で、ネットワーク装置２は可聴音を可聴通知として現在通話中のセッションに対してのみ障害発生を示す情報をＩＰ端末装置４とゲートウェイ装置８とに送出する（図７のａ１７，ａ１８）。
【０１２７】
図８〜図１２は図１のネットワーク装置２における障害検出動作を示すフローチャートである。これら図１と図８〜図１２とを参照してネットワーク装置２における障害検出動作について説明する。この障害検出フローは基本的にパケット受信にて行う。
【０１２８】
ネットワーク装置２は発着信処理が開始されると、まずＨ．２４５が開設するのかどうか（Ｈ．２４５  Ｏｐｅｎ）を確認する（図８ステップＳ１）。ネットワーク装置２はＨ．２４５が開設するまで、この動作を繰り返す。
【０１２９】
ネットワーク装置２はＨ．２４５が開設されると、ＩＰ  Ａｄｄｒｅｓｓ（Ｓｏｕｒｃｅ，Ｄｅｓｔｉｎａｔｉｏｎ）：ＩＰアドレスの発信元と宛先、ＵＤＰ−ｐｏｒｔ−ｎｕｍｂｅｒ（Ｓｏｕｒｃｅ，Ｄｅｓｔｉｎａｔｉｏｎ）：ＵＤＰポート番号の発信元と宛先、ＣＯＤＥＣ  Ｔｙｐｅ：音声圧縮の方式、Ｐａｙｌｏａｄ  ｐｅｒｉｏｄ：ペイロード周期を認識する（図８ステップＳ２）。ネットワーク装置２ではＨ．２４５の信号に対してスヌープ（盗み聞く）を行っている。
【０１３０】
ネットワーク装置２は上記の情報をトレースして蓄積するために、Ａ情報を定義する（図８ステップＳ３，Ｓ４）。例えば、受信パケットのＩＰアドレスが「１０．１０．１０．１」で、ポート番号が「１０２４」である場合には、「１０１１０２４０」という変数を定義する。これによって、複数のセッションをはった時の識別としている。
【０１３１】
ネットワーク装置２は通話が開始されると、通信がＲＴＰパケットの情報Ｂを入手する（図８ステップＳ５，Ｓ６）。例えば、受信パケットのＩＰアドレスが「１０．１０．１０．１」で、ポート番号が「１０２４」である場合、「１０１１０２４０」という変数を定義する。
【０１３２】
これによって、ネットワーク装置２は情報Ａがあり、その情報Ａに情報Ｂが一致したことで、障害監視を開始する（図８ステップＳ７〜Ｓ９）。あくまでも、上記の変数はソフトプログラム上必要なものである。もし、情報Ａと情報Ｂとが一致しない場合、例えば途中放棄した場合には障害情報監視を行わない。
【０１３３】
次に、どのような障害情報を監視しているのかについて説明する。監視する内容は、ＳＷＰＲ＝ＳＷのパケットロス監視、ＩＰＰＲ＝ＩＰパケット監視、ＲＣ＝受信パケット数、ＳＣ＝送信パケット数、ＳＱＮ＝シーケンス番号、ＴＲＦ＝トラヒック監視等である（図９ステップＳ１０、図１０ステップＳ１９、図１１ステップＳ２３、図１２ステップＳ２７）。
【０１３４】
ＳＷＰＲ＝ＳＷのパケットロスはＳＷ・ルーティング機能部１１で監視している主にＬ１インタフェース部分と、障害検出機能部１２で監視しているＦＣＳエラー、Ｌ２部分とである。
【０１３５】
ＩＰＰＲ＝受信パケットロスは障害検出機能部１２で監視しており、Ｈ．２４５が開設された後の音声ＩＰパケットにおいてＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）エラー等によってＩＰパケットを廃棄したものである。
【０１３６】
ＴＲＦ＝トラヒック監視はＳＷ・ルーティング機能部１１で監視しているもので、ＳＷ・ルーティング機能部１１が保有するリソースに対してその状態がどうなっているか、トラヒック的にどうなっているかを認識しているものである。
【０１３７】
例えば、ＳＷ・ルーティング機能部１１のパケットスループットが「１００００ＰＰＳ」最大であるにもかかわらず、瞬間的に「１０１００ＰＰＳ」になった場合にはＴＲＦ値「１０１００」を記録する。これはＲＴＰパケットのジッタ発生に影響しているものである。
【０１３８】
送信側では音声圧縮とペイロードとに合わせて送出しており、仮に４０ｍｓｅｃである場合、ネットワークに何も問題がない場合には４０ｍｓｅｃ間隔で受信されるが、ＳＷやルータを経由している時にトラヒックの影響によって誤差が発生する。
【０１３９】
ＲＣ＝受信パケット数はＲＴＰ制御部４４で受信するＲＴＰパケット数であり、ＳＣ＝送信パケット数はＲＴＰ制御部４４が送信するＲＴＰパケット数である。
【０１４０】
上記の各種情報はエラーが発生すると（図９ステップＳ１１、図１０ステップＳ２０、図１１ステップＳ２４）、それぞれ発生時刻情報とペアで記録される（図９ステップＳ１２、図１０ステップＳ２１、図１１ステップＳ２５、図１２ステップＳ２８）。
【０１４１】
ＳＷＰＲエラー、ＩＰＰＲエラー、ＴＲＦエラーが発生しなかった場合には（図９ステップＳ１１、図１０ステップＳ２０、図１１ステップＳ２４）、通知機能部１５に対してエラーなしを通知する（図９ステップＳ１７，Ｓ１８、図１０ステップＳ２２、図１１ステップＳ２６）。
【０１４２】
なにかしらのエラーが発生した場合には通知機能部１５にその障害を通知する（図９ステップＳ１３）。通知機能部１５では予め設定された障害リストと対比し、重障害なのか軽障害なのかを判断し、必要であれば可聴信号機能部１６に要求を出す（図９ステップＳ１４）。例えば、ＩＰＰＲが「１００」を超えた場合に重障害とし、５以下であれば軽障害とする。最終的に、全ての情報は保持機能部１８で保持される（図９ステップＳ１５，Ｓ１６）。
【０１４３】
図１３〜図１７は図１の音声ＩＰ端末４における障害検出動作を示すフローチャートである。これら図１と図１３〜図１７とを参照して音声ＩＰ端末４における障害検出動作について説明する。この障害検出フローは基本的にパケット受信にて行う。
【０１４４】
音声ＩＰ端末４は発着信処理が開始されると、まずＨ．２４５が開設するのかどうか（Ｈ．２４５  Ｏｐｅｎ）を確認する（図１３ステップＳ３１）。音声ＩＰ端末４はＨ．２４５が開設するまで、この動作を繰り返す。
【０１４５】
音声ＩＰ端末４はＨ．２４５が開設されると、ＩＰ  Ａｄｄｒｅｓｓ（Ｓｏｕｒｃｅ）、ＵＤＰ−ｐｏｒｔ−ｎｕｍｂｅｒ（Ｓｏｕｒｃｅ，  Ｄｅｓｔｉｎａｔｉｏｎ）、ＣＯＤＥＣ  Ｔｙｐｅ，Ｐａｙｌｏａｄ  ｐｅｒｉｏｄを認識する（図１３ステップＳ３２）。
【０１４６】
音声ＩＰ端末４は上記の情報をトレースして蓄積するために、Ａ情報を定義する（図１３ステップＳ３３，Ｓ３４）。例えば、受信パケットのＩＰアドレスが「１０．１０．１０．１」で、ポート番号が「１０２４」である場合には、「１０１１０２４０」という変数を定義する。これによって、複数のセッションをはった時の識別としている。また、変数はソフトウェア上の定義である。
【０１４７】
音声ＩＰ端末４は通話が開始されると、通信がＲＴＰパケットの情報Ｂを入手する（図１３ステップＳ３５，Ｓ３６）。例えば、受信パケットのＩＰアドレスが「１０．１０．１０．１」で、ポート番号が「１０２４」である場合、「１０１１０２４０」という変数を定義する。
【０１４８】
これによって、音声ＩＰ端末４は情報Ａがあり、その情報Ａに情報Ｂが一致したことで、障害監視を開始する（図１３ステップＳ３７〜Ｓ３９）。もし、情報Ａと情報Ｂとが一致しない場合、例えば途中放棄した場合には障害情報監視を行わない。
【０１４９】
次に、どのような障害情報を監視しているのかについて説明する。監視する内容は、ＭＲＲ＝受信パケットロス、ＲＰＲ＝ＲＴＰロス、Ｊ＝ジッタ発生率、Ｌ１ＰＲ＝Ｌ１のパケットロス、ＲＣ＝受信パケット数、ＳＣ＝送信パケット数、ＳＱＮ＝シーケンス番号等である（図１４ステップＳ４０、図１５ステップＳ４９、図１６ステップＳ５３、図１７ステップＳ５５）。
【０１５０】
ＭＲＲ＝受信パケットロスはＩＰパケット化機能部４３で監視しており、ＩＰパケットのＣＲＣエラー等によりＩＰパケットを廃棄したものである。ＲＰＲ＝ＲＴＰロスはＲＴＰ制御部４４で監視しているものであり、ＲＴＰヘッダのシーケンス番号抜けが発生した場合にこのロスが記録される。
【０１５１】
Ｊ＝ジッタ発生はＲＴＰ制御部４３で監視するものであり、ＲＴＰパケットのペイロード周期の障害を記録する。送信側では音声圧縮とペイロードとに合わせて送出しており、仮に４０ｍｓｅｃである場合、ネットワークに何も問題がない場合には４０ｍｓｅｃ間隔で受信されるが、ＳＷやルータを経由しているので誤差が発生する。ここでは基準４０ｍｓｅｃに対して振れ幅を記録する。
【０１５２】
ジッタエラーとしては初期設定値に合わせてそれ以上の振れ幅である場合にジッタエラーとして記録する。仮に＋／−１０ｍｓｅｃとすると、受信ＲＴＰパケットが５０ｍｓｅｃとなった時点でジッタエラーを発生する。
【０１５３】
Ｌ１ＰＲ＝Ｌ１のパケットロスはＭＡＣ機能部４２で検出されるＭＡＣフレームのロスを監視しており、ＦＣＳエラー発生時等のそれが記録される。ＲＣ＝受信パケット数はＲＴＰ制御部４４で受信するＲＴＰパケット数であり、ＳＣ＝送信パケット数はＲＴＰ制御部４４が送信するＲＴＰパケット数である。
【０１５４】
ＳＱＮ＝シーケンス番号はＲＴＰパケットの最初のシーケンス番号と最後のシーケンス番号とを記録したものであり、Ｔ＝時刻監視情報から通話時間を算出し、その時刻内に何パケット受信するかの理論値を出す。例えば、シーケンス番号が「１０」から開始し、「１５０９」で終了した場合には１５００パケット分（一分間に通話している）ことが理論的にわかる。そして、実際のＲＰＲ＝ＲＴＰロス数とその割合とを計算することで、ＲＴＰ受信パケットロス率が判明する。
【０１５５】
上記の各種情報はエラーが発生すると（図１４ステップＳ４１、図１５ステップＳ５０）、それぞれ発生時刻情報とペアで記録される（図１４ステップＳ４２、図１５ステップＳ５１、図１６ステップＳ５４、図１７ステップＳ５６）。
【０１５６】
ＭＲＲ値、ＲＰＲ値、シーケンスエラー、ジッタエラーが発生しなかった場合には（図１４ステップＳ４１、図１５ステップＳ５０）、通知機能部４０に対してエラーなしを通知する（図１４ステップＳ４７，Ｓ４８、図１５ステップＳ５２）。
【０１５７】
なにかしらのエラーが発生した場合は通知機能部４０にその障害を通知する（図１４ステップＳ４３）。通知機能部４０では予め設定された障害リストと対比し重障害なのか軽障害なのかを判断し、必要であれば可聴信号機能部４７へ要求を出す（図１４ステップＳ４４）。例えば、ＲＰＲが「１００」を超えた場合に重障害とし、５以下であれば軽障害とする。最終的に、全ての情報は保持機能部４８で保持される（図１４ステップＳ４５，Ｓ４６）。
【０１５８】
ＶＯＩＰ交換装置５については、基本的に、上述した音声ＩＰ端末４やゲートウェイ装置８と同様の動きを行う。ネットワーク装置１，２や音声ＩＰ端末４、ゲートウェイ装置８、ＶＯＩＰ交換装置５の重障害情報や低障害情報の段階は初期設定が可能であり、例えば３段階や５段階のレベルが設定される。
【０１５９】
図１８は図１の音声ＩＰ端末４における障害情報を示す図であり、図１９は図１のネットワーク装置２における障害情報を示す図であり、図２０は図１のネットワーク装置１における障害情報を示す図である。これら図１８〜図２０を参照して各装置間の障害検出シーケンスと音声ＩＰ端末４における障害情報とネットワーク装置２における障害情報とネットワーク装置１における障害情報との関連性について説明する。
【０１６０】
図１８に示す音声ＩＰ端末４における障害情報、図１９に示すネットワーク装置２における障害情報、図２０に示すネットワーク装置１における障害情報はそれぞれ障害が発生した時点での各保持機能部４８，１８上の記録内容であり、図７に示す各装置間の障害検出シーケンスにて記載した時刻Ａ，Ｂ，Ｃ，Ｄ，Ｅによって情報がどのように伝達されて記録されていくのかを示している。保持情報はメモリ番地とデータとで保持されており、メモリ番地順番に使用されている。
【０１６１】
時刻ＡではＨ．２４５が開設し、ＲＴＰパケットが音声ＩＰ端末４から送出される。音声ＩＰ端末４の保持情報は、通話時間開始「２００３／０７／２４  １０：１０  ９：３０：２０（Ａ）」、つまり「２００３年７月２４日１０時１０分９秒３２２０」である。
【０１６２】
音声ＩＰ端末４の保持情報において、発信元ＩＰアドレスは「１０．１０．１０．１」、発信元ポート番号は「１０２４」、宛先ＩＰアドレスは「１０．２０．５．０」、宛先ポート番号は「５１２」、ＶＬＡＮ（Ｖｉｒｔｕａｌ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）番号は「１００」、ＲＴＰ種別のＣＯＤＥＣ（音声圧縮種別）は「Ｇ．７１１」、ペイロード周期は「４０ｍｓｅｃ」である。ここで、ＶＬＡＮ番号とはＩＥＥＥ８０２．１ＰＱに準拠しているものであり、公知である。
【０１６３】
ネットワーク装置１の保持情報はＨ．２４５のスヌープを行うため、遅延があり、通話時間開始「２００３／０７／２４  １０：１０  ９：３３：２０（Ａ）」、つまり「２００３年７月２４日１０時１０分９秒３３２０」である。
【０１６４】
ネットワーク装置１の保持情報において、発信元ＩＰアドレスは「１０．１０．１０．１」、発信元ポート番号は「１０２４」、宛先ＩＰアドレスは「１０．２０．５．０」、宛先ポート番号は「５１２」、ＶＬＡＮ番号は「１００」、ＲＴＰ種別のＣＯＤＥＣ（音声圧縮種別）は「Ｇ．７１１」、ペイロード周期は「４０ｍｓｅｃ」である。
【０１６５】
ネットワーク装置２の保持情報はＨ．２４５のスヌープを行うため、さらに遅延があり、通話時間開始「２００３／０７／２４  １０：１０  ９：３６：２０（Ａ）」、つまり「２００３年７月２４日１０時１０分９秒３６２０」である。
【０１６６】
ネットワーク装置２の保持情報において、発信元ＩＰアドレスは「１０．１０．１０．１」、発信元ポート番号は「１０２４」、宛先ＩＰアドレスは「１０．２０．５．０」、宛先ポート番号は「５１２」、ＶＬＡＮ番号は「１００」、ＲＴＰ種別のＣＯＤＥＣ（音声圧縮種別）は「Ｇ．７１１」、ペイロード周期は「４０ｍｓｅｃ」である。
【０１６７】
時刻Ｂではネットワーク装置２によってエラー検出が行われる。ネットワーク装置２の保持情報は、受信処理障害発生時間「２００３／０７／２４  １０：１２：１０：００００（Ｂ）」、つまり「２００３年７月２４日１０時１２分１０秒００００」に、「ＳＷＰＲ＝受信フレームロス数＝８パケット」、「ＩＰＰＲ＝受信パケットロス数＝８パケット」をそれぞれ検出し、ＴＲＦ＝受信トラヒック数は「３０」と記録している。
【０１６８】
ネットワーク装置２には予め、ＳＷＰＲとＩＰＰＲとが「５」を超えた時点で障害発生としていたため、障害発生コード番号「Ｎ２．１０．２０．５．０／５１２，１０．１０．１０．１／１０２４，０  （Ｂ）」が定義される。これは「Ｎ２：ネットワーク装置２を示す数値」、「１０．２０．５．０／５１２」は宛先ＩＰアドレスと宛先ポート番号とを示す数値、「１０．１０．１０．１／１０２４」は送信元ＩＰアドレスと送信元ポート番号とを示す数値、「０」は同時接続処理における識別子を示す。
【０１６９】
時刻Ｃではネットワーク装置１がネットワーク装置２から障害発生コードを受信している。ネットワーク装置１は、ネットワーク装置２からの障害発生コード番号「Ｎ２．１０．２０．５．０／５１２，１０．１０．１０．１／１０２４，０」を受信した場合、その障害発生時刻を記録する。時間は「２００３／０７／２４  １０：１２：１０：００００（Ｃ）」、つまり「２００３年７月２４日１０時１２分１０秒００００」にネットワーク装置２によって検出されたものであることが認識できる。
【０１７０】
時刻Ｄでは端末ＩＰ装置４がネットワーク装置１経由にて障害発生コードを受信している。音声ＩＰ端末４はネットワーク装置２からの障害発生コード番号「Ｎ２．１０．２０．５．０／５１２，１０．１０．１０．１／１０２４，０」を受信した場合、その障害発生時刻を記録する。時間は「２００３／０７／２４  １０：１２：１０：００００（Ｄ）」、つまり「２００３年７月２４日１０時１２分１０秒００００」にネットワーク装置２によって検出されたものであることが認識できる。
【０１７１】
時刻Ｅでは音声ＩＰ端末４とゲートウェイ装置８との通話が終了している。音声ＩＰ端末４は通話時間の終話を「２００３／０７／２４  １０：１５  ９：３０２０（Ｅ）」、つまり「２００３年７月２４日１０時１５分９秒３０２０」に送受信が停止されている。受信処理のＲＣ＝送信パケット数を「７５００（Ｅ）」と登録し、同じくＳＣ＝送信処理を「７５００（Ｅ）」と登録している。この通話は約５分間通話していたことと同等になり、音声ＩＰ端末４側ではパケット廃棄がないことも意味している。
【０１７２】
ネットワーク装置１も同様に話時間の終話を「２００３／０７／２４  １０：１５  ９：６０２０（Ｅ）」、つまり「２００３年７月２４日１０時１５分９秒６０２０」に送受信が停止されている。受信処理のＲＣ＝送信パケット数を「７５００（Ｅ）」と登録し、同じくＳＣ＝送信処理を「７５００（Ｅ）」と登録している。この通話は約５分間通話していたことと同等になり、ネットワーク装置１ではパケット廃棄がないことも意味している。
【０１７３】
ネットワーク装置２も同様に、話時間の終話を「２００３／０７／２４  １０：１５  ９：９０２０（Ｅ）」、つまり「２００３年７月２４日１０時１５分９秒９０２０」に送受信が停止されている。受信処理のＲＣ＝送信パケット数を「７４９２（Ｅ）」と登録し、同じくＳＣ＝送信処理を「７５００（Ｅ）」と登録している。この通話は約５分間通話していたが、受信処理にてＳＷＰＲとＩＰＰＲとが８パケットロスしているため、「７５００−８＝７４９２」となっている。これはネットワーク装置１とネットワーク装置２との間でなんらかのネットワーク障害が発生したことを意味しており、この情報から障害発生を特定することができる。
【０１７４】
ＴＲＦ＝受信トラヒック値が「３００（３００はこの装置が３００％のトラヒックを処理していることを示す）」を表示しているため、瞬間的にトラヒック輻輳状態となり、パケットを廃棄したことと認識することができる。
【０１７５】
通話時間のその他は、将来使用のためのオプションデータである。メモリ番地Ｎ＋６のその他はＩＰｖ６（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ６）やセキュリティ対応等のパケットフォーマットが新規追加された場合の情報表示としている。
【０１７６】
受信処理と送信処理と他装置障害とは一組のセット情報となっており、仮に複数の障害が同時刻に発生し、それらの情報を記録するためには、チェイン制御を使う。チェイン制御は一組の情報が引き続きメモリ上に存在しているのかいないのかを判断するものであり、０はデータ無効、１はデータ有効を示している。
【０１７７】
他装置からの障害が続く場合には、チェイン制御によってメモリデータが増え、他装置障害のデータエリアが埋まっていくが、受信処理と送信処理とに障害が発生しないため、そのデータアリアは空きのままとなる。
【０１７８】
時刻Ｄ以降の早い段階にて、ネットワーク装置２は可聴信号を音声ＩＰ端末４とゲートウェイ装置８とに対して可聴通知として送出する。可聴信号はそのＲＴＰパケット化されて送出される方式と、可聴制御信号として送出して受信側にて再生する方式との２種類がある。これら方式の選択についてはシステムのコンフィグ設定とする。
【０１７９】
障害発生コード番号と障害発生時間情報とを他装置に送付する場合には、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）／ＩＰパケットへのカプセリングを行い、通話ルートに関する装置のみへ送付する。いわゆるアウトバンド制御になるため、情報には重障害なのか軽障害なのかも送付している。
【０１８０】
受信側装置はこの情報を基に音声信号を再生するが、システムコンフィグレーションとして再生禁止であれば再生しなく、再生許可が設定されている場合のみその再生制御が行われる。
【０１８１】
次に、ネットワーク装置１〜３の障害情報通知に関して説明する。上記にて各装置が障害情報を他装置に通知する動作であるが、ネットワーク装置１〜３においてはメインルート１０１，１２１と通知ルート１０２，１２２との２種類を設定する。基本的にはメインルート１０１，１２１でＩＰパケットの送受を行っていくが、メインルート１０１，１２１が障害になった場合、障害情報を他の局に通知することはできない。そのため、通知機能部１５にはどちらのルートを使って通知するかを可変する。この設定はシステムコンフィグによって行う。
【０１８２】
このように、本実施例では、ネットワークのどの部分で障害が発生しているかを特定することができるため、解析時間を大幅に短縮することができるとともに、アウトソーシングへの適用が広がる。
【０１８３】
また、本実施例では、利用者に障害情報通知をリアルタイムで送るため、通話品質がある程度まで許容できる場合にはそのまま利用し、そうでない場合には即座に切替え手段に移行することができる。
【０１８４】
さらに、本実施例では、障害データをリアルタイムにすることで、従来、全障害データを長時間保存することなしに必要最低限の情報をすることで、ハードウェアの価格を低下させる等の効果が得られる。
【図面の簡単な説明】
【０１８５】
【図１】本発明の一実施例によるネットワークの構成を示すブロック図である。
【図２】図１のネットワーク装置の構成を示すブロック図である。
【図３】本発明の一実施例で用いるＭＡＣフレーム及びＩＰパケットの構造を示す図である。
【図４】図１の音声ＩＰ端末の構成を示すブロック図である。
【図５】図１のＶＯＩＰ交換装置の構成を示すブロック図である。
【図６】図１のゲートウェイ装置の構成を示すブロック図である。
【図７】本発明の一実施例による各装置間の障害検出動作を示すシーケンスチャートである。
【図８】図１のネットワーク装置における障害検出動作を示すフローチャートである。
【図９】図１のネットワーク装置における障害検出動作を示すフローチャートである。
【図１０】図１のネットワーク装置における障害検出動作を示すフローチャートである。
【図１１】図１のネットワーク装置における障害検出動作を示すフローチャートである。
【図１２】図１のネットワーク装置における障害検出動作を示すフローチャートである。
【図１３】図１の音声ＩＰ端末における障害検出動作を示すフローチャートである。
【図１４】図１の音声ＩＰ端末における障害検出動作を示すフローチャートである。
【図１５】図１の音声ＩＰ端末における障害検出動作を示すフローチャートである。
【図１６】図１の音声ＩＰ端末における障害検出動作を示すフローチャートである。
【図１７】図１の音声ＩＰ端末における障害検出動作を示すフローチャートである。
【図１８】図１の音声ＩＰ端末における障害情報を示す図である。
【図１９】図１のネットワーク装置２における障害情報を示す図である。
【図２０】図１のネットワーク装置１における障害情報を示す図である。
【図２１】従来例によるネットワークの構成を示すブロック図である。
【符号の説明】
【０１８６】
１〜３  ネットワーク装置
４  音声ＩＰ端末
５  ＶＯＩＰ交換装置
６，６１，６２  既存端末
７  呼処理サーバ装置
８  ゲートウェイ装置
１１  ＳＷ・ルーティング機能部
１２  障害検出機能部
１３  起動機能部
１４  送信機能部
１５  通知機能部
１６  可聴信号機能部
１７  時間管理機能部
１８，４８，５８，８８  保持機能部
４０，５０，８０  通知機能部
４１，５１，８１  ＣＰＵ部
４２，５２，８２  ＭＡＣ機能部
４３，５３，８３  ＩＰパケット化機能部
４４，５４，８４  ＲＴＰ制御部
４５，５５，８５  ＰＣＭ制御部
４６  既存電話制御部
４７，５７，８７  可聴信号制御部
４９，５９，８９  時間管理機部
５６  既存回線制御部
８６  回線制御部
【図１】
2005175856.tif 000003
【図２】
2005175856.tif 000004
【図３】
2005175856.tif 000005
【図４】
2005175856.tif 000006
【図５】
2005175856.tif 000007
【図６】
2005175856.tif 000008
【図７】
2005175856.tif 000009
【図８】
2005175856.tif 000010
【図９】
2005175856.tif 000011
【図１０】
2005175856.tif 000012
【図１１】
2005175856.tif 000013
【図１２】
2005175856.tif 000014
【図１３】
2005175856.tif 000015
【図１４】
2005175856.tif 000016
【図１５】
2005175856.tif 000017
【図１６】
2005175856.tif 000018
【図１７】
2005175856.tif 000019
【図１８】
2005175856.tif 000020
【図１９】
2005175856.tif 000021
【図２０】
2005175856.tif 000022
【図２１】
2005175856.tif 000023