(57)【要約】【課題】通話路の状態を自動的に検査できるようにする。【解決手段】複数の拠点を接続する所定のデータ通信用ネットワーク上で音声通信を実行する音声通信システムにおいて、前記各拠点には、通話路検査エージェント手段を設け、当該通話路検査エージェント手段は、他の拠点の通話路検査エージェント手段とのあいだの呼設定を自動的に要求する呼設定要求部と、他の拠点の通話路検査エージェント手段から供給された呼設定の要求に対し、自動的に応答して自他の通話路検査エージェント手段のあいだに通話路を確立させる呼設定応答部と、当該通話路の状態を自動的に判定する通話路状態判定部とを備える。【選択図】　図１
2004096541.tif 000002
【特許請求の範囲】
【請求項１】
複数の拠点を接続する所定のデータ通信用ネットワーク上で音声通信を実行する音声通信システムにおいて、
前記各拠点には、通話路検査エージェント手段を設け、
当該通話路検査エージェント手段は、
他の拠点の通話路検査エージェント手段とのあいだの呼設定を自動的に要求する呼設定要求部と、
他の拠点の通話路検査エージェント手段から供給された呼設定の要求に対し、自動的に応答して自他の通話路検査エージェント手段のあいだに通話路を確立させる呼設定応答部と、
当該通話路の状態を自動的に判定する通話路状態判定部とを備えたことを特徴とする音声通信システム。
【請求項２】
請求項１の音声通信システムにおいて、
前記通話路状態判定部は、
前記呼設定要求部と呼設定応答部の動作を監視することで、通話路の確立の正常性を判定、または、
自通話路検査エージェント手段の音信号送受部に受信された音信号の品質、または音信号が受信されたか否かを監視して、前記通話路の状態を判定し、
当該通話路状態判定部が音信号の品質または受信の有無を判定する場合、前記各通話路検査エージェント手段は、
確立された前記通話路を介して所定の音信号を双方向に伝送させるため、前記音信号送受部を備えることを特徴とする音声通信システム。
【請求項３】
請求項１の音声通信システムにおいて、
前記データ通信用ネットワークを既存の公衆電話網と接続するゲートウエイ装置を設け、
前記通話路は、当該ゲートウエイ装置を介在させて、当該データ通信用ネットワークおよび公衆電話網をカバーするように設定することを特徴とする音声通信システム。
【請求項４】
請求項１〜３のいずれかの音声通信システムにおいて、
前記各拠点に設けた各通話路検査エージェント手段を要素とするエージェント集合中から選択した１つの通話路検査エージェント手段を、前記呼設定を要求する要求エージェント手段とし、
当該要求エージェント手段から呼設定を要求することによって当該エージェント集合中の他の要素である応答エージェント手段とのあいだで確立された通話路に関し、当該通話路の確立の正常性および／または通話路の状態を判定し、全応答エージェント手段とのあいだでこの判定が終了すると、要求エージェント手段の選択を前記エージェント集合の他の通話路検査エージェント手段に変更することを特徴とする音声通信システム。
【請求項５】
請求項１または２の音声通信システムにおいて、
前記各通話路検査エージェント手段は、
前記通話路状態判定部の判定結果に関するログ情報を蓄積しておくログ情報蓄積部と、
所定の監視センタ装置からの要求に応じて、当該ログ情報蓄積部に蓄積しているログ情報を送信するログ情報提供部とを備えたことを特徴とする音声通信システム。
【請求項６】
所定のデータ通信用ネットワーク上で音声通信を実行する拠点内の音声通信システムにおいて、
前記拠点には、複数の通話路検査エージェント手段を設け、
当該通話路検査エージェント手段は、
他の通話路検査エージェント手段とのあいだの呼設定を自動的に要求する呼設定要求部と、
他の通話路検査エージェント手段から供給された呼設定の要求に対し、自動的に応答して自他の通話路検査エージェント手段のあいだに通話路を確立させる呼設定応答部と、
当該通話路の状態を自動的に判定する通話路状態判定部とを備えたことを特徴とする音声通信システム。
【発明の詳細な説明】
【０００１】
【発明の所属する技術分野】
本発明は音声通信システムに関し、例えば、ＶｏＩＰ（Ｖｏｉｃｅ　ｏｖｅｒ　ＩＰ）技術によって音声通信を行う場合などに適用して好適なものである。
【０００２】
【従来の技術】
ＶｏＩＰ技術を利用するＩＰ電話サービスを行う場合そのネットワーク構成は、例えば、図２に示すようになる。
【０００３】
図２において、家庭やオフィスなどのユーザ利用場所１２に設置されたＩＰ電話機（例えば、２５、２７）は、当該ユーザ利用場所１２のＬＡＮ（ローカルエリアネットワーク）に直結される。ただし、ＶｏＩＰに対応していない一般の電話機（例えば、２６，２８）の場合には、ＬＡＮに直結することはできないので、ＶｏＩＰゲートウエイ装置（メディア変換装置）２３、２４と図示しないＰＢＸ（構内交換機）を介して接続される。
【０００４】
ユーザ利用場所１２内の当該ＩＰ電話機（ＩＰ電話端末）２５，２７や一般電話機２６，２８を用いるユーザは、ＩＰ網１０をバックボーンにＶｏＩＰゲートウェイ装置２１，２２を介して固定電話機２９や携帯電話機３０等を用いるユーザと通話する。
【０００５】
ＩＰ網１０と公衆電話網１１を接続する当該ＶｏＩＰゲートウエイ装置２１，２２は、ＩＰ電話交換機（このＩＰ電話交換機は、いわゆるコールエージェント（ＣＡ）に対応する構成要素）１４，１５の制御下で呼設定などの動作を行う。なお、当該ＩＰ電話交換機１４，１５に送受され、ＩＰ電話交換機１４，１５で処理されるのは、呼設定などに必要な制御用信号のみであり、エンドエンドの電話機間の通話の構成要素となる音声データを収容したＩＰパケットは、前記ルータ１６〜１８、スイッチ１９，２０，ゲートウエイ装置２１，２２などによって構成されるバックボーンを流れる。
【０００６】
ＩＰ網１０は、多数のルータ（例えば、１６〜１８）やスイッチ（例えば、１９，２０）などのネットワーク機器によって構成されＩＰプロトコルに対応するネットワークである。当該ＩＰ網１０としてはインターネットを用いることもできるが、ＶｏＩＰサービスを提供するために通信事業者が構築した専用のＩＰネットワークを利用することも多い。
【０００７】
このようなネットワーク構成のもとでは、例えば、図３に示すような形態で、ＳＮＭＰ（Ｓｉｍｐｌｅ　Ｎｅｔｗｏｒｋ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）等を用いたネットワーク管理システムを構築することができる。
【０００８】
図３においては、ＶｏＩＰゲートウエイ装置２１，２２、スイッチ１９，２０、ルータ１６〜１８などの周辺機器にＳＮＭＰエージェントを配置し、図示の監視システム２５にＳＮＭＰマネージャを配置する。そして、各ＳＮＭＰエージェントは、自身が配置されている管理対象（例えば、ゲートウエイ装置２１に配置されたＳＮＭＰエージェントの場合には、ゲートウエイ装置２１）に関する各種の管理情報（管理対象自体の状態や管理対象間の接続インタフェースの状態を示す情報）を収集して所定のデータベース（ＭＩＢ）に蓄積しておき、基本的に、ＳＮＭＰマネージャからの読出し要求があると、当該ＭＩＢの内容を読み出してＳＮＭＰマネージャに送信する仕組みになっている。
【０００９】
したがって読出し要求を定期的に送信すれば、管理情報を定期的にＳＮＭＰマネージャに集めることができる。
【００１０】
また、必要に応じて、読出し要求が無くても、ＳＮＭＰエージェント発で、ＭＩＢの内容をＳＮＭＰエージェントからＳＮＭＰマネージャに送信することができる。
【００１１】
【発明が解決しようとする課題】
しかしながら、このようなネットワーク管理システムでは、ＳＮＭＰエージェントが管理情報を収集できる範囲は管理対象の機器や装置に局限されるため、例えば、ゲートウエイ装置２１に配置したＳＮＭＰエージェントが当該ゲートウエイ装置２１を介した通信トラフィックを管理情報として取得することさえ、かなり困難で、ＲＭＯＮなどを利用する必要がある。
【００１２】
また、ＲＭＯＮを利用したとしても、例えば、前記ユーザ利用場所１２内の電話機（２５，２６など）から公衆電話網１１側の電話機（例えば、２９）とのあいだで、多数のネットワーク機器やゲートウエイ装置、あるいは公衆電話網側の回線交換機や基地局などを介して設定される長い通話路の状態を検査し、管理することは、ほとんど不可能である。
【００１３】
さらに、このような通話路の設定を協調動作によって制御するＩＰ電話交換機１４，１５などの状態を管理することも困難である。
【００１４】
また、その設定ミスが、呼制御や通話路の異常（誤接続、接続不良・片通話など）の原因となる各種の情報、例えば、ＩＰ電話交換機（例えば、１４，１５）、ゲートウェイ装置（２１，２３）などに設定されるアドレス情報、ルータ１６〜１８などに設定されるルーティング情報などを管理情報としてＳＮＭＰマネージャに集めることができ、ＳＮＭＰマネージャ側で画面表示できたとしても、このような各種の情報から構成される膨大な量の数字の羅列をもとに、将来おきる呼制御や通話路の異常を予測することは、通常、管理者にとって容易ではない。
【００１５】
なお、音声遅延などの通信品質の劣化は、通話路上のいずれかのネットワーク機器や装置などにおける通信トラフィックが過大で輻輳が発生している場合などに発生する現象であるが、個々のネットワーク機器や装置について前記ＲＭＯＮによって通信トラフィックを得たとしても、通話路上のネットワーク機器や装置の数が多い場合などには、音声遅延の発生を事前に予測することは容易ではない。
【００１６】
また、ＩＰ網に関しては、いずれかの電話機（ＩＰ電話機、一般電話機）が呼設定を要求しても、実際に呼設定が行われ、通話路が確立されるまでに長い時間（一例としては、８秒程度）を要する現象（接続遅延）が起きることがある。このような接続遅延は、ＩＰ電話交換機１４，１５などの処理能力に比して要求される呼設定の要求頻度が高い場合などに発生し得るが、呼設定の要求頻度などの動的な要因は予測することが困難である。
【００１７】
【課題を解決するための手段】
かかる課題を解決するために、第１の発明では、複数の拠点を接続する所定のデータ通信用ネットワーク上で音声通信を実行する音声通信システムにおいて、（１）前記各拠点には、通話路検査エージェント手段を設け、当該通話路検査エージェント手段は、（２）他の拠点の通話路検査エージェント手段とのあいだの呼設定を自動的に要求する呼設定要求部と、（３）他の拠点の通話路検査エージェント手段から供給された呼設定の要求に対し、自動的に応答して自他の通話路検査エージェント手段のあいだに通話路を確立させる呼設定応答部と、（４）当該通話路の状態を自動的に判定する通話路状態判定部とを備えたことを特徴とする。
【００１８】
また、第２の発明では、所定のデータ通信用ネットワーク上で音声通信を実行する拠点内の音声通信システムにおいて、（１）前記拠点には、複数の通話路検査エージェント手段を設け、当該通話路検査エージェント手段は、（２）他の通話路検査エージェント手段とのあいだの呼設定を自動的に要求する呼設定要求部と、（３）他の通話路検査エージェント手段から供給された呼設定の要求に対し、自動的に応答して自他の通話路検査エージェント手段のあいだに通話路を確立させる呼設定応答部と、（４）当該通話路の状態を自動的に判定する通話路状態判定部とを備えたことを特徴とする。
【００１９】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる音声通信システムの実施形態について説明する。
【００２０】
第１〜第４の実施形態に共通する特徴は、自動呼出し機能、自動応答機能などを備えた通話コンタクト部を各拠点に配置した上で、通話コンタクト部相互間で自動的に通信させて、実際にＩＰ電話機などからユーザが電話をかける場合にバックボーンとなるＩＰ網などの内部で起きる動作を模擬的に発生させ、呼制御や通話路の状態を監視することにより、ユーザによる実際の呼設定や通話において発生し得る障害や品質の劣化を事前に検知する点にある。
【００２１】
相互に通信する通話コンタクト部の組合せを網羅的に選定し、当該通信を定期的に実行すれば、いずれの電話ユーザがいつ電話をかけるケースでも、障害や品質劣化の事前検知が可能となる。
【００２２】
（Ａ−１）第１の実施形態の構成
本実施形態のＶｏＩＰネットワーク４０の全体構成例を図１に示す。
【００２３】
図１において、当該ＶｏＩＰネットワーク４０は、ＩＰ網１０と、ＩＰ電話交換機４１〜４４と、通話コンタクト部４５〜４８と、監視システム４９とを備えている。
【００２４】
このうちＩＰ網１０は実質的に図２のＩＰ網１０と同じであり、ＩＰ電話交換機４１〜４４も実質的に図２のＩＰ電話交換機１４，１５と同じであるので、その詳しい説明は省略する。
【００２５】
ただし図２のＩＰ網１０は、ＶｏＩＰゲートウエイ装置２１，２２を介して公衆電話網１１と接続されていたが、図１に示す本実施形態のＩＰ網１０は、公衆電話網と接続されていない。
【００２６】
このようなネットワーク構成によるＶｏＩＰネットワークを内線電話網型ＶｏＩＰネットワークと呼ぶ。ＩＰ電話機に割り当てる電話番号の体系は、現在のところ、グローバルなものではないため、公衆電話網に接続されていないＶｏＩＰネットワークは、例えば、１つの組織（企業など）の内部だけで通用する内線電話網になる。
【００２７】
内線電話網型ＶｏＩＰネットワークのためのＩＰ網１０としてインターネットを用いれば、いわゆるインターネット電話になるが、ここでは、専用のＩＰネットワークを用いるものとする。品質の保証されていないインターネットと異なり、専用のＩＰネットワークでは、比較的、良好な通信品質を得やすい。専用のＩＰネットワークとしてのＩＰ網１０は、１つの企業が自身で利用するために構築してもかまわないが、通信事業者が構築して他の企業に提供してもかまわない。ここでは、当該ＩＰ網１０は、通信事業者が構築したものとする。
【００２８】
通信事業者が構築した当該ＩＰ網１０を利用するのは、多くの場合、１つの企業だけではないため、１つの企業がその拠点間を秘匿性を保ちながら接続できるように、ＩＰ−ＶＰＮを利用するのが普通である。
【００２９】
したがって、図１は、通信事業者が提供する内線電話網サービス（内線電話網型ＶｏＩＰネットワーク）を利用し、ＩＰ網１０を共用する複数の企業のうち、１つの企業に関する構成要素だけを示したものである。ＩＰ網１０上の設備であるルータ、スイッチ（図１では図示していない）などは、この内線電話網サービスを利用する各企業によって共用されることになる。
【００３０】
前記通話コンタクト部４５〜４８はＣＴＩテクノロジーを応用した構成要素で、１つの企業の拠点ＳＴ１〜ＳＴ４ごとに配置する。１つの企業の各拠点ＳＴ１〜ＳＴ４は、広域に分散していてもよく、例えば、複数の国に分散していてもよい。図示した拠点はＳＴ１〜ＳＴ４の４つであるが、この数は４つより少なくてもよく、多くてもよいことは当然である。
【００３１】
各拠点（例えば、ＳＴ１）は通信機能を持つ多数の情報処理装置の集合体でり、その内部構成は、一例として、図１１に示すようなものであってよい。各拠点の内部構成は実質的に同じであってよいが、以下では、図１１には主として拠点ＳＴ１の内部構成を示したものとして説明を進める。
【００３２】
（Ａ−１−１）拠点の内部構成例
図１１において、当該拠点ＳＴ１は、ルータ６０と、ＶｏＩＰゲートウエイ装置６１と、ＩＰ電話機６２，６３と、パソコン６４と、ＰＢＸ（構内交換機）６５と、一般電話機６６，６７とを備えている。
【００３３】
このうちルータ６０は、ＩＰ網１０に対し拠点ＳＴ１内のＬＡＮの伝送路Ｌ１や伝送路Ｌ２を接続する機器である。伝送路Ｌ１はルータ６０のＬＡＮインタフェース（ＬＡＮポート）ＬＦに接続され、伝送路Ｌ２はＰＢＸ収容インタフェースＰＦに接続される。前記ＩＰ−ＶＰＮを利用する場合、ＩＰ−ＶＰＮのために必要な暗号化や復号化の機能は、当該ルータ６０に搭載されるものであってよい。
【００３４】
ゲートキーパ機能なども、当該ルータ６０に搭載され得る。
【００３５】
ゲートキーパとは、電話番号とＩＰアドレスの対応関係を管理する一種のサーバで、ＩＰ電話機などからの問い合わせに応じて、ＩＰアドレスを返す機能を持つ。電話をかける際、ＩＰ電話機のユーザ（例えば、Ｕ３）がＩＰ電話機（例えば、６２）に入力するのは、通信相手の電話番号だけであるが、ＩＰプロトコルに応じた通信を行うＩＰ網１０上で通信相手を識別するために有効な唯一の識別子はＩＰアドレスであるから、当該ゲートキーパに問い合わせて、当該電話番号に対応するＩＰアドレスを取得することが必要になる。
【００３６】
ＩＰ電話機６２，６３はＶｏＩＰに対応した機能を内蔵した電話機で、当該伝送路Ｌ１に直結されている。
【００３７】
パソコン６４は、マイクロフォンやスピーカなどを装備して、ＶｏＩＰ電話機として利用することも可能であるが、音声データ以外のデータを送受するデータ通信端末として利用することもできる。
【００３８】
このほか、伝送路Ｌ１には、必要に応じて、各種のサーバやグループウエアなどが接続され得る。
【００３９】
ＶｏＩＰゲートウエイ装置６１は、ＰＢＸ６５の配下の一般電話機６６，６７を伝送路Ｌ２に接続する。一般電話機６６，６７は、前記ＩＰ電話機６２，６３と異なり、ＶｏＩＰに対応した機能を備えていないため、当該ＶｏＩＰゲートウエイ装置６１が提供するＶｏＩＰ機能が必要になる。
【００４０】
当該ＶｏＩＰゲートウエイ装置６１の機能は専用の装置ではなく、ルータに搭載するようにしてもよい。このルータは、前記ルータ６０であってもよく、ルータ６０の配下に設けた新たなルータであってもよい。
【００４１】
上述した通話コンタクト部４５をこのような構造を持つ拠点ＳＴ１のなかにどのように配置するかについては様々な方法が可能である。例えば、伝送路Ｌ１に接続された図示した、または図示しないいずれかの構成要素に通話コンタクト部４５の機能を搭載してもよいが、ここでは、ルータ６０上に搭載するものとする。
【００４２】
通話コンタクト部４５は他の拠点（例えば、ＳＴ２）の通話コンタクト部（例えば、４６）などと定期的に通信するため、伝送路Ｌ１上に設けないほうが、その定期的な通信によって伝送路Ｌ１上の他の構成要素のあいだの通信が妨げられず、効率的である。
【００４３】
通話コンタクト部４５の機能は、ハードウエア的に実現してもかまわないが、本実施形態では、ソフトウエア的に実現するものとする。一般的に、ある機能をソフトウエア的に実現するとハードウエア的に実現する場合に比べ、処理速度は遅くなるが、柔軟性に富み、はるかに低価格なものになる。
【００４４】
通話コンタクト部４５の内部構成例を図１２に示す。
【００４５】
各拠点ＳＴ１〜ＳＴ４に配置される通話コンタクト部４５〜４８の内部構成は実質的に同じであってよいが、以下では、図１２には主として、通話コンタクト部４５を示したものとして説明を進める。
【００４６】
（Ａ−１−２）通話コンタクト部の内部構成例
図１２において、当該通話コンタクト部４５は、呼制御部５０と、ＰＢ送受部５１と、通話レベル解析部５２と、障害通知部５３と、コンタクト情報部５４とを備えている。
【００４７】
このうち呼制御部５０は、自動呼出し（呼設定）、自動応答部、自動切断などの呼制御を行う部分である。
【００４８】
これらの呼制御は、当該呼制御部５０が、所定の呼制御メッセージ（制御信号）をＩＰ電話交換機４１などとやり取りすることによって実行する。
【００４９】
例えば、呼制御部５０が他のいずれかの拠点の通話コンタクト部（例えば、拠点ＳＴ２の通話コンタクト部４６）に対する呼設定を要求する場合、着信先である相手通話コンタクト部４６を指定する識別子（例えば、電話番号ＮＢ２）を収容した呼設定を要求する制御信号（呼設定メッセージ）を、当該呼制御部５０からＩＰ電話交換機４１に送信することになる。
【００５０】
ＩＰ電話交換機４１は他のＩＰ電話交換機（例えば、４２）を介して（あるいは、可能ならば、ＩＰ電話交換機４１自身で）、相手通話コンタクト部４６の呼制御部（５０に対応）を制御して、双方の通話コンタクト部（ここでは、４５，４６）のあいだに呼を確立させる。
【００５１】
ＰＢ送受部５１は、呼制御部５０によって目的とする通話コンタクト部（ここでは、４６）とのあいだで呼が確立され、通話路が設定されたとき、当該通話路を介してＰＢ（プッシュボタン）信号を送信および受信する部分である。通話路上にはＩＰ網１０上の多数のルータやスイッチが存在しているため、このＰＢ信号は、これらのルータやスイッチを介して送信または受信される。
【００５２】
ここでは、ＰＢ信号を用いているが、このＰＢ信号は、実際の人間による会話が当該通話路を通して正常に行えるか否か等を検査するための信号であるから、その目的に反しないかぎり、その他の音信号あるいは、合成音声などの音声信号に置換可能である。解析の容易さなどにも配慮する必要があるが、できるだけ実際の人間の会話音声に近い特性を持つ音（あるいは音声）を使って検査することが望ましいといえる。
【００５３】
このような呼制御部５０やＰＢ送受部５１を有する通話コンタクト部４５は、ＩＰ電話交換機４１やＩＰ網１０側からみると通常のＩＰ電話機（例えば、６２）とまったく同じ機能を持つ電話機であり、ＩＰ電話機６２などと区別なく処理される。
【００５４】
通話レベル解析部５２は、当該ＰＢ送受部５１による相手通話コンタクト部（ここでは、４６）からのＰＢ信号の受信が行われたか否か判定し、あるいは、受信が行われた場合には、その遅延の程度などを解析する部分である。
【００５５】
相手通話コンタクト部４６内でもこの通話コンタクト部４５と同様、ＰＢ送受部（５１に対応）がＰＢ信号を送受するため、ＰＢ信号がまったく受信できなければ、上述した誤接続、接続不良・片通話などの呼制御や通話路の異常が発生していることが推測できる。
【００５６】
また、受信が行われた場合、受信されたＰＢ信号を詳細に解析することによって、上述した音声遅延が発生しているか否かを判定することができる。例えば、解析の結果、予め設定したしきい値（音声遅延用しきい値）を越えたレベルの音声遅延が認められた場合には、通話路の通信品質が劣化しているものと判定するようにしてもよい。音声遅延による通信品質の劣化は、通話路上のいずれかのネットワーク機器や装置などにおける通信トラフィックが過大で輻輳が発生している場合などに発生し得る。
【００５７】
さらに当該通話レベル解析部５２は、呼制御部５０が前記呼設定メッセージを送信してから、呼が確立されるまでの時間などを計測し、計測結果を所定のしきい値（接続遅延用しきい値）を越えた場合には、大きな接続遅延が発生していると判定するようにしてもよい。大きな接続遅延は、ＩＰ電話交換機４１，４６などの処理能力に比して要求される呼設定の要求頻度が高い場合などに発生し得る。
【００５８】
当該通話レベル解析部５２はまた、通話コンタクト部４５全体の制御部としての機能も備えている。
【００５９】
コンタクト情報部５４は、所定の検査手順にしたがって、当該通話コンタクト部４５が呼設定を要求すべき相手通話コンタクト部の識別子を格納している部分である。前記制御部としての通話レベル解析部５２は、所定の手順で当該コンタクト情報部５４から当該識別子を読み出すことにより、次に呼設定を要求すべき相手通話コンタクト部と、その相手通話コンタクト部に呼設定を要求するタイミングを認識することができる。
【００６０】
コンタクト情報部５４に格納する識別子としては、電話番号またはＩＰアドレスのいずれかを用いることが可能である。ＩＰアドレスを用いた場合、前記ゲートキーパに対する問い合わせを行う時間や処理を省略できる点で有利であるが、電話番号を識別子とすれば、拠点内で相手通話コンタクト部の配置変更などが行われた場合でもコンタクト情報部５４の格納内容を変更する必要がなく、管理が容易でインターオペラビリティ（相互運用性）が向上する。本実施形態では、管理の容易さや、インターオペラビリティの高さを重視して電話番号を用いるものとする。
【００６１】
障害通知部５３は、前記通話レベル解析部５２からの指示に応じて、監視システム４９へ障害通知を送信する部分である。
【００６２】
前記誤接続、接続不良・片通話などは明確な障害であるが、音声遅延または接続遅延の程度が大きいことは、必ずしも障害とはいえない。ただし、あまりにもその程度が甚だしい場合には、障害に分類し障害通知を行ったほうがよい場合もある。
【００６３】
監視システム４９がこの障害通知を受信した場合に実行する処理には様々なものが考えられる。例えば、前記ＳＮＭＰエージェントのようなプログラムをＩＰ網１０上のルータやスイッチに配置している場合には、そのプログラムの機能で可能な自動復旧処理の実行を指示し、この指示とともに、あるいは当該自動復旧処理だけでは復旧できないことが確認できたときに、所定の保守者などに通知して保守作業を依頼するようにしてもよい。
【００６４】
また、ＩＰ電話機などのユーザ（例えば、Ｕ３やＵ１など）に対しては、話中音などを聴取させて、復旧するまで、電話をかけることができないことを伝えるようにしてもよい。電話をかけられないことは不便であるが、電話をかけることを許容しても、劣悪な通話品質であると、ユーザはかえって不快な思いをする可能性が高いからである。
【００６５】
なお、図１上、ＩＰ電話交換機４１〜４４は拠点ＳＴ１〜ＳＴ４と１対１に対応するように設けてあるが、必ずしもその必要はない。例えば、ＩＰ電話交換機４１〜４４の数は、拠点ＳＴ１〜ＳＴ４の数よりも少なくしてもよい。
【００６６】
また、当該ＩＰ電話交換機４１〜４４は、各拠点ＳＴ１〜ＳＴ４の構成要素としてもよいが、ＩＰ網１０を構築する通信事業者側の設備として設けられるのが普通である。
【００６７】
さらに、当該ＩＰ電話交換機４１〜４４は、必ずしもＩＰ網１０の構成要素である必要はない。例えば、ＩＳＤＮ網内において通話網と共通線信号網が独立であるということと同様な意味において、ＩＰ電話交換機４１〜４４は、ＩＰ網１０とは独立した存在であるとみることもできる。
【００６８】
以下、上記のような構成を有する本実施形態の動作について、図４を参照しながら説明する。図４は、図１のなかから、前記通話コンタクト部の動作を説明するために必要な一対の発側拠点と着側拠点に対応する構成要素を抜き出して示したもので、Ｓ１〜Ｓ１０の各ステップを備えている。
【００６９】
発側拠点とは、前記呼制御部５０を用いて他のいずれかの通話コンタクト部への呼設定を要求するほうの通話コンタクト部を有する拠点を指し、反対に、着側拠点とは、この呼設定要求に応じて着信するほうの通話コンタクト部を有する拠点を指す。
【００７０】
原理的には、図１中に示した拠点ＳＴ１〜ＳＴ４のうち、いずれの拠点も発側拠点となることが可能であり、いずれの拠点も着側拠点となることが可能であるが、ここでは、前記通話コンタクト部４５を有する拠点ＳＴ１が発側拠点となり、前記通話コンタクト部４６を有する拠点ＳＴ２が着側拠点となる場合について説明する。
【００７１】
発側と着側の通話コンタクト部４５、４６の構成要素を区別するため、図４上では、通話コンタクト部４５の構成要素に付与した符号は末尾を「Ａ」とし、通話コンタクト部４６の構成要素に付与した符号は末尾を「Ｂ」としている。
【００７２】
すなわち、通話コンタクト部４５は構成要素５０Ａ〜５４Ａを備え、通話コンタクト部４６は構成要素５０Ｂ〜５４Ｂを備えている。
【００７３】
なお、このとき着側となる通話コンタクト部４６も発側になることがあるのであれば、構成要素として前記コンタクト情報部５４に対応するコンタクト情報部５４Ｂを装備する必要があるが、発側となることがなく着側としてのみ機能するのであれば、当該コンタクト情報部５４Ｂは省略可能である。当該通話コンタクト部４６が発側となることがあるか否かは、前記検査手順の具体的な内容に依存する。
【００７４】
（Ａ−２）第１の実施形態の動作
発側拠点ＳＴ１内の前記通話コンタクト部４５において、前記通話レベル解析部５２Ａが、前記コンタクト情報部５４Ａの内容を読出し、前記検査手順にしたがって今回、呼設定を要求すべき通話コンタクト部の電話番号を検索する。今回、呼設定を行うべき電話番号は着側拠点ＳＴ２内の通話コンタクト部４６を指す電話番号ＮＢ２であるものとすると、通話レベル解析部５２Ａは、当該電話番号ＮＢ２を収容した呼設定メッセージを、呼設定部５０Ａに送信させる。
【００７５】
呼設定部５０Ａは、当該呼設定メッセージをＩＰ電話交換機４１に送信し（Ｓ１）、ＩＰ電話交換機４１内で方路決定が行われ当該方路決定の結果としてＩＰ電話交換機４２へ、呼設定を要求する交換機間のメッセージ（例えば、ＩＡＭ（Ｉｎｉｔｉａｌ　Ａｄｄｒｅｓｓ　Ｍｅｓｓａｇｅ）メッセージ）が送信される（Ｓ２）。このメッセージを受信したＩＰ電話交換機４２でも、同様な方路決定が行われ、方路決定の結果としてＩＰ電話交換機４２から着信先の通話コンタクト部４２内の呼設定部５０Ｂへ、呼設定メッセージが送信されて呼設定が要求される（Ｓ３）。
【００７６】
もしも、ＩＰ電話交換機４１，４２が、ＩＰ電話機間の通話などのための呼制御により、その処理能力にかかる負荷が高い状態にある場合には、これら呼設定メッセージの受信、送信および方路決定に長い時間がかかって、大きな接続遅延が発生し得るが、通常は、十分に短い時間で、呼設定メッセージが受信、送信され方路決定が行われるから、ステップＳ１の開始からステップＳ３の終了までの時間は十分に短い。
【００７７】
ステップＳ３で呼設定の要求を受けた呼設定部５０Ｂでは、自動的に応答し、前記ステップＳ１〜Ｓ３の経路を反対にたどる経路、すなわち、呼制御部５０Ｂ→ＩＰ電話交換機４２→ＩＰ電話交換機４１→呼制御部５０Ａの経路で、ステップＳ４，Ｓ５，Ｓ６により、応答を伝達する。
【００７８】
発側拠点の通話コンタクト部４５は、前記ステップＳ１の開始からこのステップＳ６の終了までの時間を計測し、計測結果が前記接続遅延用しきい値を越えるか否かを調べることにより、大きな接続遅延が発生したか否かを判定することができる。
【００７９】
接続遅延の大小にかかわらず、ステップＳ６が終了すると、通話レベル解析部５２Ａは、発側のＰＢ送受部５１ＡからＰＢ信号を送信する（Ｓ７）。このＰＢ信号に対応する音声データはＩＰパケットに収容されてＩＰ網１０上の機器（例えば、ルータ１６Ａ、１６Ｂや、スイッチ１９Ａ、１９Ｂなど）によって構成される通話路を伝送され、通常は、着側のＰＢ送受部５１Ｂまで到達し、ＰＢ送受部５１Ｂによって受信される（Ｓ８）。
【００８０】
この受信とともに、または、受信の前後にＰＢ送受部５１Ｂは、ＰＢ信号を送信する（Ｓ９）。このＰＢ信号に対応する音声データは、前記ステップＳ７と同様に、ＩＰパケットに収容されて、ＩＰ網１０上の前記通話路をステップＳ９、Ｓ１０の場合と反対方向に伝送される。通常、このＩＰパケットは、発側のＰＢ送受部５１Ａまで到達し、ＰＢ送受部５１Ａによって受信される（Ｓ１０）。
【００８１】
着側の通信コンタクト部４６内では、通話レベル解析部５２Ｂが、前記ステップＳ８のＰＢ信号の到達（受信）が行われたか否か、行われた場合には、音声遅延は、前記音声遅延用しきい値を越えたか否かを検査する。
【００８２】
同様に、発側の通話コンタクト部４５内でも、通話レベル解析部５２Ａが、前記ステップＳ１０のＰＢ信号の到達（受信）が行われたか否か、行われた場合には、音声遅延は、前記音声遅延用しきい値を越えたか否かを検査する。
【００８３】
上述した呼制御や通話路の異常（誤接続、接続不良・片通話など）があると、これら通話レベル解析部５２Ａ、５２Ｂの双方または一方が、ＰＢ信号の受信が行われなかったと判定する。
【００８４】
このような通話路の異常や、音声遅延用しきい値を越える大きな音声遅延を検出すると、その通話レベル解析部５２Ａおよび／または５２Ｂは、障害通知部５３Ａおよび／または５３Ｂに、監視システム４９に宛てた障害通知を行わせる。障害通知の具体的な内容は、大きな音声遅延を検出した場合、通話路の異常を検出した場合、大きな接続遅延を検出した場合など、それぞれ相違するものとしてよいことは当然である。
【００８５】
このような障害通知を受信すると、監視システム４９は、障害通知の具体的内容に応じて、上述した自動復旧処理や保守作業の依頼などの対応処理を実行する。また、復旧前に電話をかけようとするＩＰ電話機などのユーザ（例えば、Ｕ３やＵ１など）に対しては、必要に応じて、話中音などを聴取させて、電話をかけることができないことを伝えるようにしてもよい。
【００８６】
このように、ユーザが電話をかける前に、呼制御や、通話路の状態を自動的に検査して検査結果に応じた対応処理を実行しておけば、実際にユーザが電話をかけるときには、障害が復旧し、通信の品質が高い状態に復旧している可能性が高いため、高品質で、より快適なＶｏＩＰサービスを提供することができる。
【００８７】
なお、障害通知部５３Ａや５３Ｂが監視システム４９に対して障害通知を行うための伝送路は、ＩＰ網１０内に設けるようにしてもよいが、ＩＰ網１０とは別個の伝送路を用意してもよい。また、ＩＰ網１０内に障害通知用の伝送路を設ける場合には、予め、障害通知専用の帯域を確保しておくことが望ましい。これは、ＩＰ網１０の輻輳などによって、障害通知そのものが実行できなくなる事態を回避するためである。
【００８８】
また、ここでは、発側拠点として拠点ＳＴ１を、着側拠点として拠点ＳＴ２を選んだが、その他の組合せで、定期的かつ網羅的に発側拠点と着側拠点を選ぶことができる。
【００８９】
例えば、拠点ＳＴ１から拠点ＳＴ３やＳＴ４の通話コンタクト部４７，４８に対しても、同様な呼設定を要求し、呼制御や通話路の状態を検査することも可能である。
【００９０】
（Ａ−３）第１の実施形態の効果
以上のように、本実施形態では、従来は困難であった呼制御や通話路の状態を自動的に検査することが可能になる。
【００９１】
また、この検査結果に応じて所定の対応処理を実行すれば、ユーザ（例えば、Ｕ３など）に対して、高品質で、より快適なＶｏＩＰサービスを提供することができる。
【００９２】
（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。
【００９３】
第１の実施形態では通話路はＩＰ網１０の内部に閉じていたが、本実施形態における通話路は、ＩＰ網１０から公衆電話網１１にまたがって設定され得る。これにともない、呼制御のための呼制御メッセージ（制御信号）の送受も公衆電話網１１側にまでおよぶ。
【００９４】
（Ｂ−１）第２の実施形態の構成および動作
本実施形態のＶｏＩＰネットワーク７０の全体構成例を図５に示す。
【００９５】
図５において、第１の実施形態と対応する構成要素には図１と同じ符号１０，４１〜４４，４５〜４８，４９，ＳＴ１〜ＳＴ４を付与してその詳しい説明は省略する。
【００９６】
公衆電話網１１は、携帯電話網などのネットワークであってもよいが、本実施形態では、ＩＳＤＮ網であるものとする。当該ＩＳＤＮ網１１は、ＶｏＩＰゲートウエイ装置２１，２２を介してＩＰ網１０と接続されている。前記内線電話網サービスに対し、このように公衆電話網と接続するＶｏＩＰサービスを、公衆網サービス（ＩＰ中継電話サービス）と呼ぶ。
【００９７】
本実施形態の拠点ＳＴ１〜ＳＴ３は第１の実施形態と同様にＩＰ網１０に収容された拠点であるが、拠点ＳＴ４は、ＩＳＤＮ網１１に収容されている。
【００９８】
したがって本実施形態の場合、拠点ＳＴ４の内部構成は、上述した図１１と異なり、ＩＳＤＮ対応電話機や、アナログ電話機などから構成されている。ただしこの拠点ＳＴ４にも、前記通話コンタクト部４８が設けられている。
【００９９】
本実施形態において、ＩＰ網１０内に収容されている拠点ＳＴ１〜ＳＴ３の通話コンタクト部４５〜４７のあいだで呼制御を行う場合の動作は、第１の実施形態とまったく同じであるが、これらの通話コンタクト部４５〜４７のいずれかと、ＩＳＤＮ網１１に収容されている拠点ＳＴ４の通話コンタクト部４８のあいだで呼制御を行う場合には、呼制御メッセージの伝送にＩＳＤＮ網１１の共通線信号網が介在する点などが異なる。
【０１００】
拠点ＳＴ４内の電話機は、通話コンタクト部４８も含め、すべてＩＳＤＮ網１１内の１つの加入者交換機（図示せず）に収容されているため、通話コンタクト部４５〜４７のいずれかから拠点ＳＴ４の通話コンタクト部４８に呼設定を要求した場合、その呼設定メッセージは、前記ＩＰ電話交換機４１などを経由して前記ＩＰ電話交換機４４に届けられ、さらに、当該ＩＰ電話交換機４４から図示しない信号中継局（ＳＴＰ）などを介して前記加入者交換機に届けられて、当該加入者交換機から通話コンタクト部４８の呼制御部５０に届く。
【０１０１】
そして、呼設定メッセージに通話コンタクト部４８の呼制御部５０が応答すると、これと反対の経路を応答メッセージが伝送されることになる。
【０１０２】
また、ＰＢ信号の送受では、ＩＳＤＮ網１１の通話網が介在する点などが異なる。
【０１０３】
すなわち、通話コンタクト部４５〜４７のいずれかから、拠点ＳＴ４の通話コンタクト部４８にＰＢ信号を送信すると、当該ＰＢ信号に対応する音声データを収容したＩＰパケットは、ＩＰ網１０上のスイッチやルータによって伝送されてＶｏＩＰゲートウエイ装置２１または２２まで届けられ、ＶｏＩＰゲートウエイ装置２１または２２では、ＩＰパケットがら取り出した音声データを、ＩＳＤＮに対応した信号に変換した上でＩＳＤＮ網１１上に送出し、ＩＳＤＮ網１１の通話網を介して、前記加入者交換機から、通話コンタクト部４８のＰＢ送受部５１に届けられる。
【０１０４】
通話コンタクト部４８のＰＢ送受部５１からＰＢ信号を送信する場合には、これと反対の経路をＰＢ信号が伝送されることになる。もちろん、途中のＶｏＩＰゲートウエイ装置２１または２２では、ＰＢ信号が音声データに変換され、ＩＰパケットに収容する処理が行われる。
【０１０５】
この場合、通話コンタクト部４５〜４７のいずれかと、通話コンタクト部４８のあいだに設定される通話路は、ＩＰ網１０からＩＳＤＮ網１１にいたる。
【０１０６】
ただし、これらの点を除くと、本実施形態でも、第１の実施形態と同様に、自動的に呼制御や通話路の状態を検査することが可能である。
【０１０７】
なお、ここで当該拠点ＳＴ４の電話機はすべてＩＳＤＮ網（公衆電話網）１１に収容されるものとしたが、拠点ＳＴ４の一部の電話機を公衆電話網１１に収容し、他の電話機をＩＰ網１０に収容すること等も可能であることは当然である。
【０１０８】
以上のような本実施形態の動作を、上述した図４と同じ形式で表現すると、例えば、図６に示すようになる。
【０１０９】
ただし図６上、通話コンタクト部４８の構成要素に付与した符号は、前記「Ｂ」の替わりに、末尾を「Ｄ」としてある。
【０１１０】
（Ｂ−２）第２の実施形態の効果
以上のように、本実施形態では、拠点が公衆電話網（１１）側と、ＩＰ網（１０）側に分散配置されている条件下で、第１の実施形態の効果と同等な効果を得ることができる。
【０１１１】
（Ｃ）第３の実施形態
以下では、本実施形態が第１、第２の実施形態と相違する点についてのみ説明する。
【０１１２】
本実施形態では、第１、第２の実施形態において必ずしも明確でなかった前述の検査手順につき、網羅的な検査を行う上で好ましい具体例を提案するものである。
【０１１３】
発側拠点となり得る拠点を複数用意し、それぞれの発側拠点の通話コンタクト部が非同期に呼設定メッセージの送信などを行うと、着信の衝突などが発生するために、呼制御や通話路の状態の検査が正常に行えない可能性もある。
【０１１４】
そこで、本実施形態では、検査手順にしたがって同時にはただ一つの発側拠点（発側の通話コンタクト部）を選定し、なおかつ、選定する発側拠点（発側の通話コンタクト部）を循環的に変化させることで、網羅的な検査を実現するものである。
【０１１５】
（Ｃ−１）第３の実施形態の構成および動作
本実施形態のＶｏＩＰネットワークの全体構成としては、図１に示した第１の実施形態のＶｏＩＰネットワーク４０を用いることも可能であるが、ここでは、図５に示した第２の実施形態のＶｏＩＰネットワーク７０を用いるものとする。
【０１１６】
また、本実施形態では、発側通話コンタクト部を選定するため、発側通話コンタクト部となり得る通話コンタクト部４５〜４７の前記コンタクト情報部５４内には、例えば、図７に示すような、各通話コンタクト部４５〜４７の識別子（ここでは、電話番号を想定）と循環番号（１〜３）を対応付けて格納した番号対応テーブルＴＢ１が蓄積される。
【０１１７】
図７において、電話番号ＮＢ１の通話コンタクト部４５の循環番号は１で、電話番号ＮＢ２の通話コンタクト部４６の循環番号は２で、電話番号ＮＢ３の通話コンタクト部４７の循環番号は３である。
【０１１８】
ある発側通話コンタクト部（例えば、４５）は、その他の通話コンタクト部（ここでは、４６〜４８）に対し、１つずつ呼設定を要求すること等により、すべての着側通話コンタクト部（４６〜４８）とのあいだで、呼制御および通話路の状態の検査を行う。この検査を終えると、発側通話コンタクト部（ここでは、４５）は、前記番号対応テーブルＴＢ１を検索し、自身の次の循環番号に対応付けられた電話番号（ここでは、循環番号２に対応付けられた電話番号ＮＢ２）の通話コンタクト部（４６）に対して、所定の循環通知を送信する。
【０１１９】
循環通知は、それを受信した通話コンタクト部に、発側通話コンタクト部となる権限が委譲されたことを伝えるメッセージである。
【０１２０】
したがって、当該循環通知を受信すると、前回は着側通話コンタクト部の１つであった通話コンタクト部４６が、今回は発側通話コンタクト部として動作することになり、１つずつ呼設定を要求すること等により、他のすべての通話コンタクト部４５，４７，４８とのあいだで、呼制御および通話路の状態の検査を行う。
【０１２１】
当該通話コンタクト部４６がこの検査を終えると、以降は、図８に示すように、同様の動作が循環的に繰り返される。
【０１２２】
なお、このような動作を循環的に繰り返していると、いずれかの通話コンタクト部に関して、前記呼制御や通話路の異常が検出されることがある。
【０１２３】
例えば、循環番号１の通話コンタクト部４５が発側通話コンタクト部であるときの検査で、循環番号２の通話コンタクト部４６に関して、前記呼制御や通話路の異常が検出されることが起こり得るが、その場合、単純に前記番号対応テーブルＴＢ１にしたがって通話コンタクト部４６に宛てて循環通知を送信したとしても、通話コンタクト部４６が発側通話コンタクト部として正常に検査を遂行できる可能性は低く、場合によっては、発側通話コンタクト部となる権限の循環的な委譲が、この通話コンタクト部４６で停滞してしまう可能性もあるため、一例として、呼制御や通話路の異常が検出されていない通話コンタクト部のなかから、当該通話コンタクト部４６に最も近い循環番号（ここでは、循環番号３）に対応する通話コンタクト部（ここでは、４７）へ、循環通知を送信するようにしてもよい。
【０１２４】
また、循環通知を送信するための伝送路は、前記障害通知を行うための伝送路と同様、ＩＰ網１０内に設けるようにしてもよいが、ＩＰ網１０とは別個の伝送路を用意してもよい。また、ＩＰ網１０内に循環通知を伝送するための伝送路を設ける場合には、予め、循環通知専用の帯域を確保しておくことも望ましい。これは、ＩＰ網１０の輻輳などによって、循環通知が伝送できなくなる事態を回避するためである。
【０１２５】
なお、本実施形態において、公衆電話網１１に収容されている拠点ＳＴ４の通話コンタクト部４８が発側通話コンタクト部となることがないのは、上述したように、現在のところ、ＩＰ電話機（通話コンタクト部（例えば、４５〜４７）も含む）に割り当てる電話番号の体系はグローバルなものではないため、公衆電話網１１側の電話機（ここでは通話コンタクト部４８を指す）からＩＰ網１０側の電話機に発呼することが困難である点を反映したものである。
【０１２６】
したがって、例えば、図１に示した第１の実施形態のＶｏＩＰネットワーク４０を用いる場合には、すべての通話コンタクト部４５〜４８が発側の通話コンタクト部となり得るし、ＩＰ電話機に割り当てるグローバルな電話番号の体系が整備された場合には、図５に示すＶｏＩＰネットワーク７０において、通話コンタクト部４８が発側の通話コンタクト部となることも可能である。
【０１２７】
（Ｃ−２）第３の実施形態の効果
本実施形態によれば、第１、第２の実施形態の効果と同等な効果を得ることができる。
【０１２８】
加えて、本実施形態では、呼制御や通話路の状態の検査の効率的で網羅的な実行を、ＶｏＩＰネットワーク全体について保証することが可能である。
【０１２９】
（Ｄ）第４の実施形態
以下では、本実施形態が第１〜第３の実施形態と相違する点についてのみ説明する。
【０１３０】
本実施形態は、各通話コンタクト部４５〜４８が、呼制御や通話路の状態に関して検査した結果をログ情報として蓄積しておき、前記監視システム４９からの要求に応じて（あるいは、自発的に）、監視システム４９へ当該ログ情報を送信することができるようにした点に特徴を有する。
【０１３１】
（Ｄ−１）第４の実施形態の構成および動作
本実施形態のＶｏＩＰネットワークの全体構成例は、図１に示す第１の実施形態の全体構成であってもよく、図５に示す第２の実施形態の全体構成であってもかまわない。
【０１３２】
本実施形態の通話コンタクト部４５〜４８の内部構成例を図９に示す。
【０１３３】
図９において、第１〜第３の実施形態の通信コンタクト部４５〜４８と対応する構成要素には図１２と同じ符号５０，５１，５２，５３，５４を付与してその詳しい説明は省略する。
【０１３４】
ログ情報部５５には、例えば、図１０に示すログテーブルＴＢ２のような形式でログ情報が蓄積されている。当該ログテーブルＴＢ２には、発信、着信、ＰＢ信号の送出、受信などの通信の記録を、当該動作を行った時間情報（時刻情報）とともに、ログ情報として蓄積する。
【０１３５】
具体的には、図１０において、当該ログテーブルＴＢ２には、発信呼のログとして、発信先番号（発信先の電話番号）、発信時間、ＰＢ信号送出時間、送出ＰＢ信号種別、切断時間の各データ項目を蓄積している。
【０１３６】
また、着信呼のログとしては、発信元番号（発信元の電話番号）、着信時間、ＰＢ信号受信時間、受信ＰＢ信号種別、切断時間の各データ項目を蓄積している。
【０１３７】
通信インタフェース部（通信Ｉ／Ｆ部）５６は、監視システム４９からログ情報取得要求（読出し要求）を受信すると、当該ログテーブルＴＢ２の各データ項目の具体値を読み出して監視システム４９へ送信する部分である。
【０１３８】
各通話コンタクト部４５〜４８に蓄積されているログテーブルＴＢ２の値は、各通話コンタクト部からみた検査の結果にすぎないから、異常の全体像を正確に捉えるためには、複数の通話コンタクト部のログテーブルＴＢ２の値を総合的に解析することが必要になる可能性が高い。そのような総合的な解析の必要性を認めたとき、監視システム４９から前記ログ情報取得要求を該当する複数の通話コンタクト部に送信するようにするとよい。
【０１３９】
ログ情報取得要求や、当該ログ情報取得要求に応じて監視システム４９に送信されるログテーブルＴＢ２の具体値を伝送するための伝送路は、前記障害通知の場合などと同様、ＩＰ網１０とは別個の伝送路としたり、ＩＰ網１０内に専用の帯域を確保するようにすることも望ましい。
【０１４０】
必要ならば、ログ情報取得要求を受信しない場合でも、通話コンタクト部の判断に基づいて、自発的に、ログテーブルＴＢ２の具体値を監視システム４９に送信できるようにしてもよいことは当然である。
【０１４１】
（Ｄ−２）第４の実施形態の効果
本実施形態によれば、第１、第２の実施形態と同等な効果を得ることができる。
【０１４２】
加えて、本実施形態では、各通話コンタクト部から供給されるログテーブル（ＴＢ２）の値に基づいて、監視システム（４９）が異常の全体像を正確に捉えること等が可能である。
【０１４３】
これにより、例えば、前記発信先番号、発信元番号から対応する（発着の）通話ログを特定し、ログ情報の内容を比較することにより、ＶｏＩＰネットワークにおける遅延時間を算出すること等も可能になる。
【０１４４】
また、異常の全体像を正確に捉えることにより、監視システムは、いっそう適切な対応処理を実行することが可能になる。
【０１４５】
（Ｅ）他の実施形態
上記第１の実施形態では、前記コンタクト情報部５４には識別子として電話番号（またはＩＰアドレス）を格納するものとしたが、必要に応じてその他の識別子を用いることも可能である。例えば、ドメイン名（ＦＱＤＮ）を利用することも可能である。
【０１４６】
また、上記第１〜第４の実施形態では呼の確立後、音声遅延など通話路の品質の検査まで行うようにしたが、呼の確立の確認までで、１つの着信先通話コンタクト部に対する検査を終了するようにしてもよい。
【０１４７】
さらに、上記第１〜第４の実施形態では、各拠点に１つずつ通話コンタクト部を配置して拠点間における呼制御や通話路の状態について検査したが、１拠点の内部においても同様にして呼制御や通話路の状態について検査することが可能である。ただしその場合には、当然、１つの拠点内に複数の通話コンタクト部を配置する必要がある。拠点の規模が大きい場合などには、このように１拠点内に複数の通話コンタクト部を配置することは、有効である。
【０１４８】
また、上記第１〜第４の実施形態の通話コンタクト部では、図１２などに、呼制御部（５０）、ＰＢ送受部（５１）、通話レベル解析部（５２）、障害通知部（５３）などを分けて示したが、これは論理的な機能を示したものであり、実装上のハードウェア・ソフトウェア構成を限定するものではない。
【０１４９】
同様に、上記第３の実施形態では、コンタクト情報部５４に格納する番号対応テーブルＴＢ１のデータ項目として、循環番号と電話番号の２つを設けたが、これはスキーマの一例を示したものであり、実装上のソフトウェア構成を限定するものではない。また、コンタクト情報部５４に関係型データベース以外のデータベースを用いることも可能である。
【０１５０】
なお、図５に示した第２の実施形態のネットワーク構成は、公専公型のネットワーク構成に拡張することも容易である。
【０１５１】
また、上記第１〜第４の実施形態のＩＰ網はその他のデータ通信用のネットワークに置換可能である。一例としては、フレームリレー網などに置換することができる。
【０１５２】
さらに、第３の実施形態の特徴部分と第４の実施形態の特徴部分は背反の関係にないので、両者を同一のＶｏＩＰネットワーク内に併存させることも可能である。
【０１５３】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１５４】
【発明の効果】
以上に説明したように、本発明によれば、従来は困難であった通話路の状態を自動的に判定することが可能になる。
【０１５５】
これにより、例えば、品質の高いＶｏＩＰサービスを提供すること等が容易になる。
【図面の簡単な説明】
【図１】第１の実施形態に係るＶｏＩＰネットワークの全体構成例を示す概略図である。
【図２】従来のＶｏＩＰネットワークの全体構成例を示す概略図である。
【図３】従来のＶｏＩＰネットワークにおけるネットワーク管理システムの構成例を示す概略図である。
【図４】第１の実施形態の動作説明図である。
【図５】第２および第３の実施形態に係るＶｏＩＰネットワークの全体構成例を示す概略図である。
【図６】第２の実施形態の動作説明図である。
【図７】第３の実施形態に係るＶｏＩＰネットワークの全体構成例を示す概略図である。
【図８】第３の実施形態の動作説明図である。
【図９】第４の実施形態で使用する通話コンタクト部の主要部の構成例を示す概略図である。
【図１０】第４の実施形態の動作説明図である。
【図１１】第１〜第４の実施形態で使用する拠点の内部構成例を示す概略図である。
【図１２】第１〜第３の実施形態で使用する通話コンタクト部の主要部の構成例を示す概略図である。
【符号の説明】
１０…ＩＰ網、１１…公衆電話網、１４，２５，４１〜４４…ＩＰ電話交換機、４５〜４８…通話コンタクト部、２１，２２，６１…ＶｏＩＰゲートウエイ装置、４０，７０…ＶｏＩＰネットワーク、４９…監視システム、２５，２７，６２、６３…ＩＰ電話機、５０、５０Ａ、５０Ｂ…呼制御部、５１、５１Ａ、５１Ｂ…ＰＢ送受部、５２、５２Ａ、５２Ｂ…通話レベル解析部、５３、５３Ａ、５３Ｂ…障害通知部、５４、５４Ａ、５４Ｂ…コンタクト情報部、６０…ルータ、ＳＴ１〜ＳＴ４…拠点。
【図１】
2004096541.tif 000003
【図２】
2004096541.tif 000004
【図３】
2004096541.tif 000005
【図４】
2004096541.tif 000006
【図５】
2004096541.tif 000007
【図６】
2004096541.tif 000008
【図７】
2004096541.tif 000009
【図８】
2004096541.tif 000010
【図９】
2004096541.tif 000011
【図１０】
2004096541.tif 000012
【図１１】
2004096541.tif 000013
【図１２】
2004096541.tif 000014