(57)【要約】【課題】従来からある装置やネットワークの仕様を変更することをなく許可されない端末装置からの接続を排除し、かつ音声通信システムのネットワークの構成や設定を変更することなく通話音質試験を行うことが可能な通話音質評価システムを提供する。【解決手段】本発明の通話音質評価システムは、セキュリティポリシーにより音声パケット以外のプロトコルの通信が規制されているような環境下でも、データを音声パケットのペイロードに埋め込んで送受信する。【選択図】        図４
2007259320.tif 000002
【特許請求の範囲】
【請求項１】
音声パケットのみを通過させるセキュアなネットワークにおいて、該ネットワーク上に配置される試験通信装置間における通話音質試験のために、該ネットワークに接続される試験管理装置と該試験通信装置との間、及び該試験通信装置間で、該通話音質試験にかかる通信情報を送受信する通話音質評価システムであって、
前記通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする通話音質評価システム。
【請求項２】
前記通話音質試験の開始に先立って、前記試験管理装置から前記試験通信装置へ、該試験通信装置が実行する該通話音質試験の試験内容及び試験手順を定めた試験シナリオを前記音声パケットのペイロードに埋め込んで送信することを特徴とする請求項１に記載の通話音質評価システム。
【請求項３】
前記ネットワークは、該ネットワークに接続又は該ネットワーク上に配置される装置の追加又は移動が可能であり、該接続元装置から接続先装置への伝送路確保を行う伝送路確保装置がさらに配置されていることを特徴とする請求項１又は２に記載の通話音質評価システム。
【請求項４】
前記接続先装置が、該接続先装置との通信を許可する接続元装置からの通信開始依頼か否かを判定し、該判定結果が接続先装置との通信を許可する接続元装置からの通信開始依頼である場合に、通信開始を許可する通信許可手段を備えたことを特徴とする請求項３に記載の通話音質評価システム。
【請求項５】
音声パケットのみを通過させるセキュアなネットワークにおいて、音声パケットを送受信して音声通話のための通信を行うネットワークに接続される装置間でシステム間通信情報を送受信する通信システムであって、
前記システム間通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする通信システム。
【請求項６】
通信プロトコル選択基準に基づいて前記通信に使用する通信プロトコルを選択する通信プロトコル選択手段と、
前記通信プロトコル選択手段により選択された前記通信プロトコルを記憶管理するプロトコル管理手段と
をさらに有することを特徴とする請求項５に記載の通信システム。
【請求項７】
前記ネットワークに接続又は配置される送信側装置から受信側装置へ送信される前記音声パケットは、ＲＴＰ（Real-time Transport Protocol）パケットであることを特徴とする請求項５又は６に記載の通信システム。
【請求項８】
前記ＲＴＰパケットは、複数のシーケンスからなり、
前記受信側装置における前記ＲＴＰパケットの受信時において、該複数のシーケンスのうちの一部が欠落したと判定される場合に、前記送信側装置に該欠落したシーケンス又は該ＲＴＰパケットの再送を要求する再送要求手段を有することを特徴とする請求項７に記載の通信システム。
【請求項９】
音声パケットを送受信して音声通話のための通信を行うネットワーク上に配置される試験通信装置間における通話音質試験を管理する試験管理装置であって、
前記試験通信装置へ、前記通話音質試験にかかる通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする試験管理装置。
【請求項１０】
前記通話音質試験の開始に先立って、前記試験通信装置へ、該試験通信装置が実行する該通話音質試験の試験内容及び試験手順を定めた試験シナリオを前記音声パケットのペイロードに埋め込んで送信することを特徴とする請求項９に記載の試験管理装置。
【請求項１１】
音声パケットを送受信して音声通話のための通信を行うネットワーク上に通話音質試験を行うために配置される試験通信装置であって、
他の試験通信装置へ、前記通話音質試験にかかる通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする試験通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、音声パケットを送受信して音声通話のための通信を行うネットワークにおいて、該ネットワーク上に配置される試験通信装置間における通話音質試験のために、該ネットワークに接続される試験管理装置と該試験通信装置との間、及び該試験通信装置間で、該通話音質試験にかかる通信情報を送受信する通話音質評価システム、通信システム、試験管理装置及び試験通信装置に関し、特に、従来からある装置やネットワークの仕様を変更することをなく許可されない端末装置からの接続を排除し、かつ音声通信システムのネットワークの構成や設定を変更することなく通話音質試験を行うための通話音質評価システム、通信システム、試験管理装置及び試験通信装置に関する。
【背景技術】
【０００２】
近年、インターネット網を利用した音声通信システムが普及してきている。このような音声通信システムは、比較的低コストでシステム構築が可能ために、安価に音声通信サービスを提供することができる。
【０００３】
かかる音声通信システムにおける通話品質を測定するために、種々の試験を行う必要がある。このような試験は、通話音質試験（ＶＱＴ；Voice Quality Testing）と呼ばれる。このような試験の方法として、例えば、特許文献１には、インターネット網へ入力する以前の信号とインターネット網を通過した以後の信号とを比較することにより、インターネット網が通話品質に与える影響を測定することが可能な通話品質測定方法が開示されている。
【０００４】
また、インターネット網におけるセキュリティの確保もますます重要になってきている。特に、該インターネット網に接続することを許可されている端末装置を選別して端末装置からの不正な接続を排除する必要がある。このような方法として、例えば、特許文献２には、端末の位置特定情報であるＵＲＩ（Uniform Resource Indicator）に基づいてセッション（接続）開始を許可するＳＩＰ（Session Initial Protocol）を拡張して使用するセッション開始プロトコルシステムが開示されている。
【０００５】
【特許文献１】特開２００４−２９７８０３号公報
【特許文献２】特表２００４−５２３８２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献１に代表される従来技術では、セキュリティポリシーに基づき、伝送路がＲＴＰ（Real-time Transport Protocol）パケットのみを通過させるようにネットワークが設定されている近年の音声通信システムにおいて、ＴＣＰ（Transmission Control Protocol）などＲＴＰとは異なるプロトコルによるパケットで送受信される通話音質試験にかかる制御情報を通過させることができなかった。
【０００７】
このために、近年、ますますセキュリティレベルが向上した近年の音声通信システムにおいて通話音質試験を行う際に、ネットワークの構成や設定を変更することが必要となり、作業手順の増大を招くのみならず、セキュリティの低下の問題が発生しかねなかった。
【０００８】
また、上記特許文献２に代表される従来技術では、ＳＩＰの拡張を伴うために、従来からあるＳＩＰに準拠した装置やネットワークの仕様を変更せねばならず、この変更に伴うコストの負担が問題となっていた。
【０００９】
従って、上記特許文献１及び２の従来技術を組み合わせたとしても、従来からある装置やネットワークの仕様を変更することをなく許可されない端末装置からの接続を排除し、かつ音声通信システムのネットワークの構成や設定を変更することなく通話音質試験を行うことは不可能であった。
【００１０】
本発明は、上記問題点（課題）を解消するためになされたものであって、ＲＴＰネットワークにおける通話音質評価システム、通信システム、試験管理装置及び試験通信装置であって、従来からある装置やネットワークの仕様を変更することをなく許可されない端末装置からの接続を排除し、かつ音声通信システムのネットワークの構成や設定を変更することなく通話音質試験を行うことが可能な通話音質評価システム、通信システム、試験管理装置及び試験通信装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した問題を解決し、目的を達成するため、本発明は、音声パケットのみを通過させるセキュアなネットワークにおいて、該ネットワーク上に配置される試験通信装置間における通話音質試験のために、該ネットワークに接続される試験管理装置と該試験通信装置との間、及び該試験通信装置間で、該通話音質試験にかかる通信情報を送受信する通話音質評価システムであって、前記通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする。
【００１２】
また、本発明は、上記発明において、前記通話音質試験の開始に先立って、前記試験管理装置から前記試験通信装置へ、該試験通信装置が実行する該通話音質試験の試験内容及び試験手順を定めた試験シナリオを前記音声パケットのペイロードに埋め込んで送信することを特徴とする。
【００１３】
また、本発明は、上記発明において、前記ネットワークは、該ネットワークに接続又は該ネットワーク上に配置される装置の追加又は移動が可能であり、該接続元装置から接続先装置への伝送路確保を行う伝送路確保装置がさらに配置されていることを特徴とする。
【００１４】
また、本発明は、上記発明において、前記接続先装置が、該接続先装置との通信を許可する接続元装置からの通信開始依頼か否かを判定し、該判定結果が接続先装置との通信を許可する接続元装置からの通信開始依頼である場合に、通信開始を許可する通信許可手段を備えたことを特徴とする。
【００１５】
また、本発明は、音声パケットのみを通過させるセキュアなネットワークにおいて、音声パケットを送受信して音声通話のための通信を行うネットワークに接続される装置間でシステム間通信情報を送受信する通信システムであって、前記システム間通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする。
【００１６】
また、本発明は、上記発明において、通信プロトコル選択基準に基づいて前記通信に使用する通信プロトコルを選択する通信プロトコル選択手段と、前記通信プロトコル選択手段により選択された前記通信プロトコルを記憶管理するプロトコル管理手段とをさらに有することを特徴とする。
【００１７】
また、本発明は、上記発明において、前記ネットワークに接続又は配置される送信側装置から受信側装置へ送信される前記音声パケットは、ＲＴＰ（Real-time Transport Protocol）パケットであることを特徴とする。
【００１８】
また、本発明は、上記発明において、前記ＲＴＰパケットは、複数のシーケンスからなり、前記受信側装置における前記ＲＴＰパケットの受信時において、該複数のシーケンスのうちの一部が欠落したと判定される場合に、前記送信側装置に該欠落したシーケンス又は該ＲＴＰパケットの再送を要求する再送要求手段を有することを特徴とする。
【００１９】
また、本発明は、音声パケットを送受信して音声通話のための通信を行うネットワーク上に配置される試験通信装置間における通話音質試験を管理する試験管理装置であって、前記試験通信装置へ、前記通話音質試験にかかる通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする。
【００２０】
また、本発明は、上記発明において、前記通話音質試験の開始に先立って、前記試験通信装置へ、該試験通信装置が実行する該通話音質試験の試験内容及び試験手順を定めた試験シナリオを前記音声パケットのペイロードに埋め込んで送信することを特徴とする。
【００２１】
また、本発明は、音声パケットを送受信して音声通話のための通信を行うネットワーク上に通話音質試験を行うために配置される試験通信装置であって、他の試験通信装置へ、前記通話音質試験にかかる通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする。
【発明の効果】
【００２２】
本発明によれば、音声パケットを送受信するネットワーク上の通話音質評価システムにおいて、通話音質試験にかかる通信情報を音声パケットのペイロードに埋め込んで送受信することにより、ネットワークの構成や設定を変更することなく、容易に通話音質試験を行うことができる。
【００２３】
また、本発明によれば、音声パケットを送受信するネットワーク上の通話音質評価システムにおいて、通話音質試験にかかる試験シナリオを音声パケットのペイロードに埋め込んで送受信することにより、ネットワークの構成や設定を変更することなく、容易に試験シナリオを送受信することができる。
【００２４】
また、本発明によれば、伝送路確保装置により接続元装置を確認して該接続元装置から接続先装置への伝送路確保が行なわれ、さらに、この伝送路確保にかかる通信情報を音声パケットのペイロードに埋め込んで送受信することにより、ネットワークの構成や設定を変更することなく、容易に接続元装置を確認した伝送路確保を行うことができる。
【００２５】
また、本発明によれば、音声パケットを送受信するネットワーク上でシステム間情報を送受信する通信システムにおいて、システム間情報を音声パケットのペイロードに埋め込んで送受信することにより、ネットワークの構成や設定を変更することなく、容易にシステム間情報の送受信を行うことができる。
【００２６】
また、本発明によれば、複数の通信プロトコルが併用されるネットワークにおいて、最適な通信プロトコルを自動的に選択することができ、プロトコルの設定ミスを防止し、許容されないプロトコルによる接続を排除してセキュリティを維持することができる。
【００２７】
また、本発明によれば、ＲＴＰパケットを送受信するネットワーク上でシステム間情報を送受信する通信システムにおいて、システム間情報をＲＴＰパケットのペイロードに埋め込んで送受信することにより、ネットワークの構成や設定を変更することなく、容易にシステム間情報の送受信を行うことができる。
【００２８】
また、本発明によれば、欠落シーケンスが発生した場合に欠落シーケンス又は全データを含むＲＴＰパケットの再送を要求するので、通信の信頼性を高めることができる。
【発明を実施するための最良の形態】
【００２９】
以下に添付図面を参照して、本発明に係る通話音質評価システム、通信システム、試験管理装置及び試験通信装置の好適な実施例を詳細に説明する。なお、以下に示す実施例では、本発明を音声パケットであるＲＴＰ（Real-time Transport Protocol）パケットを送受信して音声通話のための通信を行うネットワークにおける通話音質評価システム、通信システム、試験管理装置及び試験通信装置に適用した場合を示すこととする。なお、音声パケットは、ＲＴＰに限られるものではなく、広く一般に音声を伝送するためのパケットであってもよい。
【実施例１】
【００３０】
先ず、図１〜１０を参照して、試験シナリオ送信機能、ＲＴＰパケット送信機能及び試験結果送信機能を含む実施例１について説明する。図１は、音声専用ネットワークにおける音声評価試験の問題点の概略を示す図である。同図に示すように、プローブＡ及びＩＰ電話機Ａが接続されるルータＡが配置される音声専用ネットワークＡ、及び、プローブＢ及びＩＰ電話機Ｂが接続されるルータＢが配置される音声専用ネットワークＢがファイアウォールＡを境界に接続されている。ここで、プローブとは、試験通信装置であり、通話音質評価の測定拠点である。
【００３１】
また、プローブＡ及びプローブＢ間で行う通話音質評価を管理する試験管理装置（マネージャ）がファイアウォールＢを境界にプローブＡ及びプローブＢに接続されている。試験管理装置は、プローブ制御を行うものである。
【００３２】
音声専用ネットワークＡ及び音声専用ネットワークＢは、ＲＴＰパケットを伝送するための音声専用のネットワークである。よって、ファイアウォールＡは、ＲＴＰパケットのみの通過を許可するものであって、ＲＴＰパケット以外の種類のパケットの通過を許可しないように設定されている。なお、ファイアウォールＢは、試験管理装置とプローブとの間の通信を制限するのみであるので、ＲＴＰパケットのみの通過を許可する設定はされていない。
【００３３】
かかるネットワークにおいて通話音質評価を行う場合に、通話音質評価にかかる通信情報は、ソケット通信によるＴＣＰ（Transmission Control Protocol）パケット等、ＲＴＰパケットとは異なるパケットが使用されることが一般的である。よって、前述のようにネットワークの設定がなされている場合に、ＴＣＰパケットは、ファイアウォールＢを越えて試験管理装置とプローブＡ及びプローブＢとの間で送受信されるが、ファイアウォールＡを越えてプローブＡとプローブＢとの間では送受信不可能である。このために、例えば、プローブＡからプローブＢへ通話音質評価のためのＴＣＰパケットの試験パケットを送信しても、該試験パケットは、ファイアウォールＡでブロックされてしまうこととなる。
【００３４】
このように、ネットワークにおいては、一般に、システム間通信により制御情報の送受信が行われるが、該ネットワークが音声専用ネットワークであって、該システム間通信の伝送路がセキュリティポリシー等によってＲＴＰパケットのみの伝送を許容することとなっている場合に通話音質評価を行うことができないという問題点があった。
【００３５】
例えば、プローブが音声専用ネットワークのサービス網ゾーン（アクセス網、コアルータ網）に複数配置され、プローブ同士で試験パケットのやりとりを行って通話音質評価を行う場合に、コアルータ網への不正アクセスを防止するために、セキュリティポリシーによりＲＴＰパケット以外のプロトコルが規制されている場合がある。コアルータ網とアクセス網との境界にファイアウォールが配置され、ＲＴＰパケット等の音声パケット以外を通過させないというものである。
【００３６】
この場合に、試験パケットの送受信時の実測データは音声パケットではないために、ＴＣＰパケットとして通信が行われることとなるが、前述のセキュリティポリシーにより、該ＴＣＰパケットがファイアウォールを通過できないために、通話音質評価を行うことができないという課題があった。本発明は、かかる課題を解決するためになされたものであって、試験パケットがファイアウォールを通過でき、通話音質評価を行うことが可能とすることを目的とする。
【００３７】
そこで、図１に示した課題を解決するために、本発明において、ＴＣＰパケットのＲＴＰパケット化を行うこととした。図２は、図１に示した課題を解決するために、本発明において行うＴＣＰパケットのＲＴＰパケット化の概要を説明する図である。同図に示すように、ＴＣＰパケットである試験パケットをＲＴＰパケットのペイロードに埋め込むことにより、試験パケットに含まれる通話音質評価にかかる各種情報がファイアウォールを通過することを可能とした。
【００３８】
ＴＣＰパケットは、ＴＣＰデータの前後にＴＣＰ制御情報を付加したパケットであるが、このＴＣＰパケット全体をデータと見なして、ＲＴＰパケットのペイロードに埋め込む。ＴＣＰパケットであるＲＴＰペイロードのデータの前後にＲＴＰ制御情報を付加することにより、試験パケットに含まれる通話音質評価にかかる各種情報を含んだＲＴＰパケットが生成されることとなる。
【００３９】
図２は、実施例１において行うＴＣＰパケットのＲＴＰパケット化の概要を説明する図であるが、ＴＣＰ制御情報を付与せず、ＴＣＰデータのみをＲＴＰパケットのペイロードに埋め込む構成であってもよい。
【００４０】
このＴＣＰパケットのＲＴＰパケット化により生成されたＲＴＰパケットの使用方法について、通常におけるＲＴＰパケットの使用方法と対比させて説明する。図３は、ＴＣＰパケットのＲＴＰパケット化により生成されたＲＴＰパケットの使用方法を示す図である。図３（ａ）は、通常におけるＲＴＰパケットの使用方法を示す図である。また、図３（ｂ）は、本発明におけるＲＴＰパケットの使用方法を示す図である。
【００４１】
図３（ａ）に示すように、通常においては、音声入力をＡ／Ｄコンバータによりデジタル変換して符号化したものをＲＴＰパケット化する。このＲＴＰパケットをネットワークを介して受信すると、ＲＴＰパケット化の逆の手順によるＲＴＰデパケット化を行う。このデパケット化されたものを復調してＤ／Ａコンバータでアナログ変換して出力することとなる。
【００４２】
他方、図３（ｂ）に示すように、本発明においては、ＲＴＰパケット化されたＴＣＰデータをネットワークを介して受信すると、ＲＴＰデパケット化してＴＣＰデータを取り出すことになる。
【００４３】
このように、本発明で取り扱われるＲＴＰパケットは、音声をＲＴＰパケット化したものではなく、本来ＴＣＰパケットであるＴＣＰデータをＲＴＰパケット化して送受信されるものであるところに特徴がある。
【００４４】
上記のようにＴＣＰパケットをＲＴＰパケット化したＲＴＰパケットを使用して行う音声評価試験ことが可能となる。図４は、本発明の音声ネットワークにおける音声評価試験の概略を示す図である。同図に示すように、プローブＡ２００及びＩＰ電話機Ａ６００ａが接続されるルータＡ５００ａが配置される音声専用ネットワークＡ８００ａ、及び、プローブＢ４００及びＩＰ電話機Ｂ６００ｂが接続されるルータＢ５００ｂが配置される音声専用ネットワークＢ８００ｂがファイアウォールＡ７００ａを境界に接続されている。
【００４５】
また、プローブＡ２００及びプローブＢ４００間で行う通話音質評価を管理する試験管理装置１００がファイアウォールＢ７００ｂを境界にプローブＡ２００及びプローブＢ４００に接続されている。
【００４６】
試験管理装置１００とプローブＡ２００及びプローブＢ４００との間の制御情報の通信はＴＣＰパケットで行われるが、ファイアウォールＢ７００ｂは、ＴＣＰパケットの通過を許可するために、該制御情報は、ファイアウォールＢを越えて試験管理装置１００とプローブＡ２００及びプローブＢ４００との間でやりとりが可能である。
【００４７】
しかし、プローブＡ２００とプローブＢ４００との間に存在するファイアウォールＡ７００ａは、ＴＣＰパケットの通過を許可せず、ＲＴＰパケットのみの通過を許可する設定となっている。このために、プローブＡ２００とプローブＢ４００との制御情報の通信は、ＴＣＰパケットで行えないが、上記のようにＴＣＰパケットをＲＴＰパケット化することによって、該ＲＴＰパケットにてファイアウォールＡ７００ａを通過することが可能となる。例えば、プローブＡ２００からプローブＢ４００へＲＴＰパケット化された試験パケットを送信すると、プローブＢ４００は該試験パケットを受信して試験結果をＲＴＰパケット化してプローブＡ２００へ返却する。このようにして、プローブが音声専用ネットワークのサービス網ゾーンに配置されるプローブ間で通話音質評価が可能となる。
【００４８】
このように、実施例１の通話音質評価システムは、セキュリティポリシーにより音声パケット以外のプロトコルの通信が規制されているような環境下でも、データを音声パケットのペイロードに埋め込んで送受信可能とする点に特徴がある。
【００４９】
次に、本発明の音声専用ネットワークにおける音声評価システムのネットワーク構成を説明する。図５は、本発明の音声専用ネットワークにおける音声評価システムのネットワーク構成を示す図である。同図に示すように、プローブＡ２００及びＩＰ電話機Ａ６００ａが接続されるルータＡ５００ａが配置される音声専用ネットワークＡ８００ａ、及び、プローブＢ４００及びＩＰ電話機Ｂ６００ｂが接続されるルータＢ５００ｂが配置される音声専用ネットワークＢ８００ｂがファイアウォールＡ７００ａを境界に接続されている。
【００５０】
また、プローブＡ２００及びプローブＢ４００間で行う通話音質評価を管理する試験管理装置１００がファイアウォールＢ７００ｂを境界にプローブＡ２００及びプローブＢ４００に接続されている。
【００５１】
ここで、試験管理装置１００は、プローブの管理を行い、試験シナリオの管理を行い、試験シナリオに規定される試験パケットの送信側プローブの判定を行い、該送信側プローブであるプローブＡ２００へ試験シナリオの送信を行い、プローブＡ２００から音声評価結果を受信し、該音声評価結果の蓄積と管理を行うものである。
【００５２】
また、プローブＡ２００は、試験管理装置１００から後述の試験シナリオを受信し、プローブＢ４００へ試験開始情報（試験開始のトリガや試験の実測データを出力する単位）を送信し、試験シナリオで規定される情報に基づき、プローブＢ４００へ試験パケットを送信し、プローブＢ４００から実測データを受信し、プローブＢ４００から受信した実測データと試験シナリオに基づき音声評価結果を判定し、該音声評価結果を試験管理装置１００へ送信するものである。
【００５３】
また、プローブＢ４００は、プローブＡ２００から前述の試験開始情報を受信し、プローブＡ２００から試験パケットを受信し、受信した試験パケットのパケット欠落数、受信間隔及び受信回数を実測データとして蓄積し、蓄積した実測データをプローブＡ２００へ送信するものである。
【００５４】
さらに、音声専用ネットワークＡ８００ａには、試験管理装置１００とプローブＡ２００との間に、ＳＩＰ（Session Initial Protocol）サーバ３００が配置されている。このＳＩＰサーバ３００は、装置の位置情報を示すＳＩＰ−ＵＲＩ（Session Initial Protocol-Uniform Resource Indicator）に基づいたＳＩＰシグナリングを受信して試験管理装置１００とプローブＡ２００との通信開始ネゴシエーションを行う。また、ＳＩＰサーバ３００は、ＳＩＰシグナリングを受信して試験管理装置１００とプローブＡ２００との通信終了ネゴシエーションを行うものである。ＳＩＰシグナリングは、ＳＩＰに基づくパケットである。
【００５５】
また、試験管理装置１００には、ＬＡＮ（Local Area Network）等を介して、少なくとも１台の端末装置９００が接続されている。この試験管理装置１００は、音声評価試験システムの運用者が該音声評価試験システムの運用を行うためのインターフェースを提供するものである。該インターフェースは、具体的には、ＧＵＩ（Graphical User Interface）である。該インターフェースは、運用者が試験シナリオを登録し、音声評価試験の中断や再開などの制御を入力し、音声評価結果の確認を行うためのインターフェースである。
【００５６】
ここで、試験シナリオは、試験パケットの送信側プローブと受信側プローブとを指定して定められる試験区間、試験開始日時、試験終了日時、試験パケットのパケット長、試験パケットの送信間隔及び試験パケットの送信回数等が指定されるものである。
【００５７】
次に、実施例１の試験管理装置の構成について説明する。図６は、実施例１の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、試験管理装置１００は、該試験管理装置１００全体の制御を司り、音声評価試験に係る各種処理を実行する処理部１０１と、各種情報を予め記憶し、かつ音声評価結果を蓄積する記憶部１０２と、ＴＣＰパケットをＲＴＰパケット化するＲＴＰパケット生成部１０３と、ＲＴＰパケットからＴＣＰパケットを抽出するＴＣＰパケット抽出部１０４と、ＲＴＰパケット生成部１０３から受け渡されたＲＴＰパケットを外部へ送信し、外部から受信したＲＴＰパケットをＴＣＰパケット抽出部１０４へ受け渡すＲＴＰ−Ｉ／Ｆ部１０５と、該試験管理装置１００とＳＩＰサーバ３００との通信を司るＳＩＰサーバＩ／Ｆ部１０６と、端末装置９００との通信を司る端末装置Ｉ／Ｆ部１０７とを有する。
【００５８】
処理部１０１は、さらに、記憶部１０２に記憶されるプローブ情報及び試験管理装置情報から受信許可する装置のＳＩＰ−ＵＲＩ情報を生成し、該ＳＩＰ−ＵＲＩ情報を必要に応じてＳＩＰサーバ３００へ送信する受信許可ＳＩＰ−ＵＲＩ情報生成部１０１ａと、ＳＩＰサーバ３００から受信したＳＩＰ−ＵＲＩ情報が受信を許可するものであるか否かを記憶部１０２に記憶される受信許可ＳＩＰ−ＵＲＩの情報に基づいて判定するＳＩＰ−ＵＲＩ受信許可判定処理部１０１ｂと、試験パケットの送信側プローブとのセッション開始をＳＩＰサーバ３００に依頼するセッション開始依頼処理部１０１ｃと、ＧＵＩから登録された又は記憶部１０２に記憶される試験シナリオを送信側プローブへ送信し、試験管理装置１００から受信した試験シナリオを記憶部１０２へ登録する試験シナリオ処理部１０１ｄと、送信側プローブとのセッション終了をＳＩＰサーバ３００に依頼するセッション終了依頼処理部１０１ｅと、送信側プローブから受信した試験結果を記憶部１０２に蓄積し、端末装置９００のＧＵＩに表示させる試験結果受信部１０１ｆとを有する。
【００５９】
記憶部１０２は、さらに、プローブ情報を記憶するプローブ情報記憶部１０２ａと、試験管理装置情報を記憶する試験管理装置情報記憶部１０２ｂと、受信許可する装置のＳＩＰ−ＵＲＩを記憶する受信許可ＳＩＰ−ＵＲＩ記憶部１０２ｃと、試験シナリオを記憶する試験シナリオ記憶部１０２ｄと、試験パケットの受信側プローブから受信した試験結果を蓄積する試験結果蓄積部１０２ｅとを有する。
【００６０】
次に、実施例１のプローブの構成について説明する。図７は、実施例１のプローブＡ２００の構成を示す機能ブロック図である。同図に示すように、プローブＡ２００は、該プローブＡ２００全体の処理を司り、音声評価試験に係る各種処理を実行する処理部２０１と、各種情報を予め記憶し、かつ音声評価試験の実測データである試験データを蓄積する記憶部２０２と、ＴＣＰパケットをＲＴＰパケット化するＲＴＰパケット生成部２０３と、ＲＴＰパケットが試験パケットであった場合に該ＲＴＰパケットのパケット長、受信間隔、受信回数などのデータを試験データを取得し、ＲＴＰパケットが試験パケットでなかった場合に該ＲＴＰパケットからＴＣＰパケットを抽出するＴＣＰパケット抽出部２０４と、ＲＴＰパケット生成部２０３から受け渡されたＲＴＰパケットを外部へ送信し、外部から受信したＲＴＰパケットをＴＣＰパケット抽出部２０４へ受け渡すＲＴＰ−Ｉ／Ｆ部２０５と、該プローブＡ２００とＳＩＰサーバ３００との通信を司るＳＩＰサーバＩ／Ｆ部１０６とを有する。
【００６１】
処理部２０１は、さらに、ＳＩＰサーバ３００から受信した試験パケットの送信側プローブのＳＩＰ−ＵＲＩ情報が受信を許可するものであるか否かを記憶部２０２に記憶される受信許可ＳＩＰ−ＵＲＩの情報に基づいて判定するＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａと、ＳＩＰサーバ３００にからのセッション開始依頼に基づいて試験パケットの受信側プローブとのセッションを開始するセッション開始処理部２０１ｂと、ＳＩＰサーバ３００から受信した試験シナリオを記憶部１０２に記憶する試験シナリオ受信処理部２０１ｃと、記憶部１０２に蓄積される試験データを試験パケットの送信側プローブへ通知する試験データ通知処理部２０１ｄと、記憶部１０２に記憶される試験データと試験シナリオに基づいて試験結果を判定する試験結果判定処理部２０１ｅと、試験結果判定処理部２０１ｅによる判定結果を試験パケットの送信側プローブへ通知する試験結果通知処理部２０１ｆと、ＳＩＰサーバ３００にからのセッション終了依頼に基づいて試験パケットの受信側プローブとのセッションを終了するセッション終了処理部２０１ｇと、受信側プローブから受信した試験データを記憶部１０２に記憶する試験データ受信処理部２０１ｈと、記憶部２０２に記憶される試験シナリオに基づいて試験を実行する試験実行部２０１ｉとを有する。
【００６２】
なお、試験結果判定処理部２０１ｅにより判定される試験結果は、パケット遅延、パケットロス、ジッタ値、Ｒ値などである。
【００６３】
記憶部２０２は、さらに、受信許可する装置のＳＩＰ−ＵＲＩを記憶する受信許可ＳＩＰ−ＵＲＩ記憶部２０２ａと、試験シナリオを記憶する試験シナリオ記憶部２０２ｂと、試験パケットの受信側プローブから受信した試験データを蓄積する試験データ蓄積部２０２ｃとを有する。
【００６４】
次に、試験管理装置１００とプローブＡ２００との間での試験シナリオ送信処理について説明する。図８は、試験シナリオ送信処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。同図に示すように、先ず、端末装置９００から試験シナリオが入力され（ステップＳ１０１）、試験管理装置１００の端末装置Ｉ／Ｆ部１０７を介して受信された該試験シナリオが処理部１０１により記憶部１０２に登録される（ステップＳ１０２）。
【００６５】
次に、試験シナリオに基づいて試験パケット送信側プローブを判断し（ステップＳ１０３）、送信側プローブとのセッションを開始するようにＳＩＰサーバ３００へ依頼する（ステップＳ１０４、ステップＳ１０５）。この依頼を受けＳＩＰサーバ３００は、該依頼をプローブＡ２００へ送信し（ステップＳ１０６）、依頼を受信した旨を試験管理装置１００へ送信する（ステップＳ１０７）。
【００６６】
次に、プローブＡ２００では、ＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ１０８）、受信可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信する（ステップＳ１０９、ステップＳ１１０）。この受信可の情報を受信した試験管理装置１００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由してプローブＡ２００へ送信する（ステップＳ１１１、ステップＳ１１２）。
【００６７】
そして、試験管理装置１００の処理部１０１は、セッション開始完了を検知（ステップＳ１１３）した後、試験シナリオ送付依頼を出力し（ステップＳ１１４）、この試験シナリオをＲＴＰパケット化して（ステップＳ１１５）プローブＡ２００へ送信する（ステップＳ１１６、ステップＳ１１７）。試験シナリオを受信したプローブＡ２００では、受信した試験シナリオをＴＣＰパケット抽出部２０４へ送信し（ステップＳ１１８）、該ＴＣＰパケット抽出部２０４でＲＴＰデパケット化を行ったものを試験シナリオ受信処理部２０１ｃへ送信する（ステップＳ１１９）。
【００６８】
試験シナリオ受信処理部２０１ｃでは、受信した試験シナリオのシーケンスから試験シナリオを組み立て（ステップＳ１２０）、この試験シナリオを試験実行部２０１ｉへ送信する（ステップＳ１２１）。
【００６９】
試験シナリオの送信が終了したならば、試験管理装置１００の処理部１０１において試験シナリオ送付完了が検知され（ステップＳ１２２）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由してプローブＡ２００へ送信される（ステップＳ１２３、ステップＳ１２４、ステップＳ１２５）。
【００７０】
プローブＡ２００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信し（ステップＳ１２６、ステップＳ１２７）、このセッション終了可の情報が最終的に処理部１０１に検知される（ステップＳ１２８）。処理部１０１は、セッション終了を検知すると、試験シナリオ登録完了の情報を端末装置Ｉ／Ｆ部１０７を介して端末装置９００へ送信する（ステップＳ１２９、ステップＳ１３０）。このようにして、試験シナリオをプローブＡ２００に登録する処理が終了する。
【００７１】
次に、プローブＡ２００とプローブＢ４００との間でのＲＴＰ試験パケット送信処理について説明する。図９は、ＲＴＰ試験パケット送信処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとし、プローブＢ４００を試験パケット受信側プローブとする。同図に示すように、先ず、プローブＡ２００の試験実行部２０１ｉは、試験シナリオに基づき、試験開始情報送付依頼を送信する（ステップＳ１３１）。この試験開始情報送付依頼は、ＲＴＰパケット生成部２０３でＲＴＰパケット化され（ステップＳ１３２）、このＲＴＰパケットがＲＴＰ−Ｉ／Ｆ２０５を介してプローブＢ４００へ送信される（ステップＳ１３３、ステップＳ１３４）。
【００７２】
ＲＴＰ−Ｉ／Ｆ部４０５を介して受信されたＲＴＰパケットは、ＴＣＰパケット抽出部４０４に送信され（ステップＳ１３５）、該ＴＣＰパケット抽出部４０４でＲＴＰデパケット化された後に試験データ受信処理部４０１ｈへ受け渡される（ステップＳ１３６）。試験データ受信処理部４０１ｈがＲＴＰデパケット化された情報を受信することにより、試験開始を認識し、試験データを出力する単位を入手することとなる（ステップＳ１３７）。
【００７３】
次に、プローブＡ２００は、ＲＴＰ試験パケット送付依頼を送信する（ステップＳ１３８）。このＲＴＰ試験パケット送付依頼は、ＲＴＰパケット生成部２０３でＲＴＰパケット化され（ステップＳ１３９）、このＲＴＰパケットがＲＴＰ−Ｉ／Ｆ２０５を介してプローブＢ４００へ送信される（ステップＳ１４０、ステップＳ１４１）。
【００７４】
プローブＢ４００は、ＲＴＰ−Ｉ／Ｆ部４０５を介して試験パケットを受信したならば、この受信パケットをＴＣＰパケット抽出部４０４へ送信する（ステップＳ１４２）。ＴＣＰパケット抽出部４０４で受信パケットのＲＴＰデカプセル化を行うことにより得た試験データを試験データ受信処理部４０１ｈへ送信する（ステップＳ１４３）。このステップＳ１４０〜ステップＳ１４３の処理が、試験シナリオに規定される試験パケット送信回数分だけ繰り返されることとなる。このようにして、プローブＢ４００の記憶部２０２に試験データが蓄積されることとなる。
【００７５】
次に、ステップＳ１４０〜ステップＳ１４３の処理が繰り返されることによりプローブＢ４００の記憶部２０２に蓄積された試験データをプローブＡ２００へ送信するために、プローブＢ４００の試験データ受信処理部４０１ｈは、試験データ通知処理部４０１ｄへ試験データ送信依頼を出す（ステップＳ１４４）。この依頼に基づいて試験データ通知処理部４０１ｄは記憶部２０２から蓄積された試験データを読み出して送信することとなる（ステップＳ１４５）。
【００７６】
試験データ通知処理部４０１ｄから送信された試験データは、ＲＴＰパケット生成部４０３においてＲＴＰパケット化され（ステップＳ１４６）、このＲＴＰパケット化された情報がＲＴＰ−Ｉ／Ｆ部４０５を介してプローブＡ２００へ送信される（ステップＳ１４７、ステップＳ１４８）。
【００７７】
プローブＡ２００では、ＲＴＰ−Ｉ／Ｆ部２０５で受信したＲＴＰパケットをＴＣＰパケット抽出部２０４へ送信する（ステップＳ１４９）。ＴＣＰパケット抽出部２０４は、受信したＲＴＰパケットからＲＴＰデカプセル化により試験データを抽出し、試験結果判定処理部２０１ｅへ送信する（ステップＳ１５０）。試験データを受信した試験結果判定処理部２０１ｅは、試験データと試験シナリオから試験結果を判定する（ステップＳ１５１）。この判定結果は、試験結果通知処理部２０１ｆへ送信され（ステップＳ１５２）、記憶部２０２に蓄積され、端末装置９００のＧＵＩに表示されることとなる。
【００７８】
次に、試験管理装置１００とプローブＡ２００との間での試験結果送信処理について説明する。図１０は、試験結果送信処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。同図に示すように、先ず、プローブＡ２００の試験結果通知処理部２０１ｆが、試験結果を送付するために、試験管理装置１００とのセッション開始を依頼する（ステップＳ１６１）。この依頼は、ＳＩＰサーバＩ／Ｆ部２０６からＳＩＰサーバ３００を経由して試験管理装置１００へと送信される（ステップＳ１６２、ステップＳ１６３）。また、セッション開始依頼をプローブＡ２００へも送り返す（ステップＳ１６４）。
【００７９】
試験管理装置１００では、ＳＩＰサーバＩ／Ｆ部１０６を介してセッション開始依頼を受信したならば、ＳＩＰ−ＵＲＩ受信許可判定処理部１０１ｂが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ１６５）、受信可の情報をＳＩＰサーバ３００を経由してプローブＡ２００へ送信する（ステップＳ１６６、ステップＳ１６７）。この受信可の情報を受信したプローブＡ２００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由して試験管理装置１００へ送信する（ステップＳ１６８、ステップＳ１６９）。
【００８０】
そして、プローブＡ２００の試験結果通知処理部２０１ｆは、セッション開始完了を検知（ステップＳ１７０）した後、試験結果送付依頼を出力し（ステップＳ１７１）、この試験結果をＲＴＰパケット化して（ステップＳ１７２）試験管理装置１００へ送信する（ステップＳ１７３、ステップＳ１７４）。試験結果を受信した試験管理装置１００では、受信した試験結果をＴＣＰパケット抽出部１０４へ送信し（ステップＳ１７５）、該ＴＣＰパケット抽出部１０４でＲＴＰデパケット化を行ったものを試験結果受信部１０１ｆへ送信する（ステップＳ１７６）。このようにして試験管理装置１００に試験結果が送達することとなる。
【００８１】
試験結果の送信が終了したならば、プローブＡ２００の試験結果通知処理部２０１ｆにより試験結果送付完了が検知され（ステップＳ１７７）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由して試験管理装置１００へ送信される（ステップＳ１７８、ステップＳ１７９、ステップＳ１８０）。
【００８２】
試験管理装置１００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由してプローブＡ２００へ送信し（ステップＳ１８１、ステップＳ１８２）、このセッション終了可の情報が最終的にプローブＡ２００の試験結果通知処理部２０１ｆに検知される（ステップＳ１８３）。このようにして、試験結果をプローブＡ２００から試験管理装置１００へ送信する処理が終了する。
【００８３】
実施例１によれば、セキュリティポリシーにより特定パケット以外のプロトコルが規制されているような環境下であっても、ネットワーク上に配置される装置間で前述特定パケット以外のプロトコルで伝送可能なシステム間通信情報を送受信することが可能となる。
【００８４】
特に、本発明を利用した通話音質評価システムは、音声専用ネットワークなどのセキュリティポリシーにより音声パケット以外のプロトコルが規制されているような環境下であっても、ネットワーク上に配置される装置間（試験管理装置１００、プローブ又はＩＰ電話機等）で試験結果情報、試験開始情報、試験制御情報、試験シナリオ情報、時刻同期情報、ファームウェア情報を送受信することが可能となる。
【００８５】
また、遠隔からの試験シナリオの送信指示が可能となり、この試験シナリオに基づいてプローブが自動的に通話音質評価試験を行うことから、通話音質評価試験を遠隔から制御することが可能となることとなる。
【００８６】
なお、実施例１の発明は、次の課題を解決するためになされた。即ち、ＴＣＰソケット通信やＨＴＴＰ／ＨＴＴＰＳ通信可能な場合であっても、通信対象が複数であり、接続装置の移設や増設が頻繁に行われるようなシステムにおいては、通信対象の移設や増設の度にファイアウォールの設定を変更しなければならない場合があり、システム運用上、不便であったという課題である。
【００８７】
また、実施例１において、音質評価システムがＳＩＰサーバ３００を有する理由は次の課題を解決するためである。即ち、データの受信側となりうる装置（試験管理装置１００やプローブ）は、ＳＩＰでの伝送路確保機能とＲＴＰパケットでの通信機能を備えている。このために、これらの機能を備えた装置であれば、正当な装置でなくとも通信を開始できるが、通話音質評価システムの一機能を担うことから、悪意を持った装置からのデータの送信を排除しなければならない。このために、通信可能な送信側装置を選択できることが必要であったことによる。
【００８８】
例えば、通話音質評価システムでは、試験を行いたい区間に応じて、プローブの増設や移設が必要となる。プローブは、ＴＣＰソケット又はＨＴＴＰ／ＨＴＴＰＳにより、試験結果を試験管理装置１００へ通知する。これと共に、プローブは、試験管理装置１００から、試験シナリオ、最新ファームウェア及び時刻同期情報を受信する。プローブは、通常、サービス網ゾーン（コアルータ網、アクセス網）に置かれるため、試験管理装置１００とプローブとの間は、ファイアウォールが置かれることが通常である。
【００８９】
このために、試験管理装置１００とプローブとの間で使用するＴＣＰポートは開放されなければならず、また、ファイアウォールの設定を変更してＴＣＰソケット通過させるようにしなければならない。この作業は、プローブ数が多いほど作業負担を増大させるものである。ＴＣＰポートが開放されることにより、セキュリティ上の問題も、さらに発生することとなる。
【００９０】
実施例１の発明は、ファイアウォールでのＴＣＰソケットの通過許可設定の手順を必要とすることなく、また、ＴＣＰポートの開放によりセキュリティの問題が発生すること防止することができる。さらに、データの送信側装置のＳＩＰ−ＵＲＩを判定することにより、許可されない送信側装置からのデータ受信を行わず、正当な送信側装置からのデータのみを受信することが可能となる。
【実施例２】
【００９１】
次に、図１１〜１４を参照して、試験中断機能を含む実施例２について説明する。実施例２におけるネットワーク構成、各装置の構成及び機能は、試験管理装置１００及びプローブＡ２００、プローブＢ４００が試験中断機能にかかる構成を有して処理を行う以外は、実施例１のものと同一である。
【００９２】
先ず、実施例２の試験管理装置の構成について説明する。図１１は、実施例２の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、実施例２の試験管理装置１００は、実施例１の試験管理装置１００の処理部１０１に試験中断処理部１０１ｇをさらに有した構成となっている。この差異以外は、実施例２の試験管理装置１００は実施例１の試験管理装置１００と同一である。
【００９３】
試験中断処理部１０１ｇは、端末装置９００から入力された試験中断指示に基づいて、プローブへ試験中断のための指示を送信するものである。この指示は、ＲＴＰパケット生成部１０３でＲＴＰパケット化された後に、ＲＴＰ−Ｉ／Ｆ部１０５を介してプローブへと送信される。
【００９４】
次に、実施例２のプローブの構成について説明する。図１２は、実施例２のプローブＡ２００の構成を示す機能ブロック図である。なお、実施例２においても、プローブＢ４００の構成は、プローブＡ２００の構成と同一である。同図に示すように、実施例２のプローブＡ２００は、実施例１のプローブＡ２００の処理部２０１に試験中断処理部２０１ｊをさらに有した構成となっている。この差異以外は、実施例２のプローブＡ２００は実施例１のプローブＡ２００と同一である。
【００９５】
試験中断処理部２０１ｊは、試験管理装置１００から受信した試験中断指示に基づいて、試験実行部２０１ｉへ試験中断のための指示を出力するものである。また、この指示は、ＲＴＰ−Ｉ／Ｆ部２０５を介して試験パケット送信側プローブから受信されてＲＴＰパケット抽出部２０４でＲＴＰデパケット化された後に、試験中断処理部２０１ｊにより受信されるものである。この指示を受信した試験中断処理部２０１ｊは、試験実行部２０１ｉに対して試験の中断を指示することとなる。
【００９６】
次に、試験管理装置１００とプローブＡ２００との間での試験中断処理について説明する。図１３は、試験中断処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。同図に示すように、先ず、端末装置９００から試験中断指示が入力され（ステップＳ１９１）、試験管理装置１００の端末装置Ｉ／Ｆ部１０７を介して受信された該試験中断指示が試験中断処理部１０１ｇにより検知される（ステップＳ１９２）。
【００９７】
次に、ＳＩＰ−ＵＲＩ受信許可判定処理部１０１ｂが試験シナリオに基づいて試験パケット送信側プローブを判断し（ステップＳ１９３）、セッション開始依頼処理部１０１ｃが送信側プローブとのセッションを開始するようにＳＩＰサーバ３００へ依頼する（ステップＳ１９４、ステップＳ１９５）。この依頼を受けＳＩＰサーバ３００は、該依頼をプローブＡ２００へ送信し（ステップＳ１９６）、依頼を受信した旨を試験管理装置１００へ送信する（ステップＳ１９７）。
【００９８】
次に、プローブＡ２００では、ＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ１９８）、受信可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信する（ステップＳ１９９、ステップＳ２００）。この受信可の情報を受信した試験管理装置１００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由してプローブＡ２００へ送信する（ステップＳ２０１、ステップＳ２０２）。
【００９９】
そして、試験管理装置１００の処理部１０１は、セッション開始完了を検知（ステップＳ２０３）した後、試験中断依頼を出力し（ステップＳ２０４）、この試験中断依頼をＲＴＰパケット化して（ステップＳ２０５）プローブＡ２００へ送信する（ステップＳ２０６、ステップＳ２０７）。試験中断依頼を受信したプローブＡ２００では、受信した試験中断依頼をＴＣＰパケット抽出部２０４へ送信し（ステップＳ２０８）、該ＴＣＰパケット抽出部２０４でＲＴＰデパケット化を行ったものを試験中断処理部２０１ｊへ送信する（ステップＳ２０９）。試験中断処理部２０１ｊは、受信した試験中断依頼を試験実行部２０１ｉへ受け渡し（ステップＳ２１０）、試験中断が実行されることとなる。
【０１００】
試験中断依頼の送信が終了したならば、試験管理装置１００の処理部１０１において試験中断指示完了が検知され（ステップＳ２１１）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由してプローブＡ２００へ送信される（ステップＳ２１２、ステップＳ２１３、ステップＳ２１４）。
【０１０１】
プローブＡ２００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信し（ステップＳ２１５、ステップＳ２１６）、このセッション終了可の情報が最終的に処理部１０１に検知される（ステップＳ２１７）。処理部１０１は、セッション終了を検知すると、試験中断指示完了の情報を端末装置Ｉ／Ｆ部１０７を介して端末装置９００へ送信する（ステップＳ２１８、ステップＳ２１９）。このようにして、試験中断指示をプローブＡ２００に送信する処理が終了する。
【０１０２】
なお、試験中断処理は、音声評価システムの運用者の試験中断指示に基づいて実行されることとしたが、これに限らず、試験シナリオと関連させて試験中断を実行することとしてもよいし、試験管理装置１００が他のシステムとの連携に基づいて試験中断を実行することとしてもよい。
【０１０３】
次に、プローブＡ２００とプローブＢ４００との間での試験中断処理について説明する。図１４は、試験中断処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとし、プローブＢ４００を試験パケット受信側プローブとする。同図に示すように、先ず、プローブＡ２００の試験中断処理部２０１ｊは、試験中断情報送付依頼を送信する（ステップＳ２２１）。この試験中断情報送付依頼は、ＲＴＰパケット生成部２０３でＲＴＰパケット化され（ステップＳ２２２）、このＲＴＰパケットがＲＴＰ−Ｉ／Ｆ２０５を介してプローブＢ４００へ送信される（ステップＳ２２３、ステップＳ２２４）。
【０１０４】
ＲＴＰ−Ｉ／Ｆ部４０５を介して受信された試験中断の依頼情報を含むＲＴＰパケットは、ＴＣＰパケット抽出部４０４に送信され（ステップＳ２２５）、該ＴＣＰパケット抽出部４０４でＲＴＰデパケット化された後に試験中断処理部４０１ｊへ受け渡される（ステップＳ２２６）。試験中断処理部４０１ｊがＲＴＰデパケット化された情報を受信することにより、試験中断を認識することとなる（ステップＳ２２７）。以上の処理を経て、以降のプローブＡ２００からプローブＢ４００への試験パケットの送付が全てキャンセルざれることとなる。実施例２によれば、遠隔からの試験中断の指示が可能となることとなる。
【０１０５】
なお、試験管理装置１００とプローブＡ２００との間のＳＩＰサーバ３００を介したセッションも同様に中断処理が可能である。よって、試験シナリオ送信処理においても、同様に送信中断処理を行うことが可能である。
【０１０６】
また、一般的に、ＳＩＰサーバ３００を介した装置間のセッションも同様に中断処理が可能である。即ち、ＳＩＰサーバ３００を介した装置間でＲＴＰパケットのペイロードにシステム間通信情報を埋め込んで送信する処理も、中断処理が可能である。よって、例えば、プローブＡ２００とプローブＢ４００との間での試験結果情報、試験開始情報、試験制御情報、試験シナリオ情報、同期時刻情報、ファームウェア更新情報等の送信処理においても、同様に送信中断処理を行うことが可能である。
【実施例３】
【０１０７】
次に、図１５〜１８を参照して、試験再開機能を含む実施例３について説明する。実施例３におけるネットワーク構成、各装置の構成及び機能は、試験管理装置１００及びプローブＡ２００、プローブＢ４００が試験再開機能にかかる構成を有して処理を行う以外は、実施例１のものと同一である。試験再開機能は、試験の実行が障害等により中断した場合や実施例２に示したように試験の実行が音声評価システムの運用者により中断された場合に、該試験を再開するために利用されるものである。
【０１０８】
先ず、実施例３の試験管理装置の構成について説明する。図１５は、実施例３の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、実施例３の試験管理装置１００は、実施例１の試験管理装置１００の処理部１０１に試験再開処理部１０１ｈをさらに有した構成となっている。この差異以外は、実施例３の試験管理装置１００は実施例１の試験管理装置１００と同一である。
【０１０９】
試験再開処理部１０１ｈは、端末装置９００から入力された試験再開指示に基づいて、プローブへ試験再開のための指示を送信するものである。この指示は、ＲＴＰパケット生成部１０３でＲＴＰパケット化された後に、ＲＴＰ−Ｉ／Ｆ部１０５を介してプローブへと送信される。
【０１１０】
次に、実施例３のプローブの構成について説明する。図１６は、実施例３のプローブＡ２００の構成を示す機能ブロック図である。なお、実施例３においても、プローブＢ４００の構成は、プローブＡ２００の構成と同一である。同図に示すように、実施例３のプローブＡ２００は、実施例１のプローブＡ２００の処理部２０１に試験再開処理部２０１ｋをさらに有した構成となっている。この差異以外は、実施例３のプローブＡ２００は実施例１のプローブＡ２００と同一である。
【０１１１】
試験再開処理部２０１ｋは、試験管理装置１００から受信した試験再開指示に基づいて、試験実行部２０１ｉへ試験再開のための指示を出力するものである。また、この指示は、ＲＴＰ−Ｉ／Ｆ部２０５を介して試験パケット送信側プローブから受信されてＲＴＰパケット抽出部２０４でＲＴＰデパケット化された後に、試験再開処理部２０１ｋにより受信されるものである。この指示を受信した試験再開処理部２０１ｋは、試験実行部２０１ｉに対して試験の再開を指示することとなる。
【０１１２】
次に、試験管理装置１００とプローブＡ２００との間での試験再開処理について説明する。図１７は、試験再開処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。同図に示すように、先ず、端末装置９００から試験再開指示が入力され（ステップＳ２３１）、試験管理装置１００の端末装置Ｉ／Ｆ部１０７を介して受信された該試験再開指示が試験再開処理部１０１ｈにより検知される（ステップＳ２３２）。
【０１１３】
次に、ＳＩＰ−ＵＲＩ受信許可判定処理部１０１ｂが試験シナリオに基づいて試験パケット送信側プローブを判断し（ステップＳ２３３）、セッション開始依頼処理部１０１ｃが送信側プローブとのセッションを開始するようにＳＩＰサーバ３００へ依頼する（ステップＳ２３４、ステップＳ２３５）。この依頼を受けＳＩＰサーバ３００は、該依頼をプローブＡ２００へ送信し（ステップＳ２３６）、依頼を受信した旨を試験管理装置１００へ送信する（ステップＳ２３７）。
【０１１４】
次に、プローブＡ２００では、ＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ２３８）、受信可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信する（ステップＳ２３９、ステップＳ２４０）。この受信可の情報を受信した試験管理装置１００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由してプローブＡ２００へ送信する（ステップＳ２４１、ステップＳ２４２）。
【０１１５】
そして、試験管理装置１００の処理部１０１は、セッション開始完了を検知（ステップＳ２４３）した後、試験再開依頼を出力し（ステップＳ２４４）、この試験再開依頼をＲＴＰパケット化して（ステップＳ２４５）プローブＡ２００へ送信する（ステップＳ２４６、ステップＳ２４７）。試験再開依頼を受信したプローブＡ２００では、受信した試験再開依頼をＴＣＰパケット抽出部２０４へ送信し（ステップＳ２４８）、該ＴＣＰパケット抽出部２０４でＲＴＰデパケット化を行ったものを試験再開処理部２０１ｋへ送信する（ステップＳ２４９）。試験再開処理部２０１ｋは、受信した試験再開依頼を試験実行部２０１ｉへ受け渡し、試験再開が実行されることとなる。
【０１１６】
試験再開依頼の送信が終了したならば、試験管理装置１００の処理部１０１において試験再開指示完了が検知され（ステップＳ２５１）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由してプローブＡ２００へ送信される（ステップＳ２５２、ステップＳ２５３、ステップＳ２５４）。
【０１１７】
プローブＡ２００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信し（ステップＳ２５５、ステップＳ２５６）、このセッション終了可の情報が最終的に処理部１０１に検知される（ステップＳ２５７）。処理部１０１は、セッション終了を検知すると、試験再開指示完了の情報を端末装置Ｉ／Ｆ部１０７を介して端末装置９００へ送信する（ステップＳ２５８、ステップＳ２５９）。このようにして、試験再開指示をプローブＡ２００に送信する処理が終了する。
【０１１８】
なお、試験中断処理は、音声評価システムの運用者の試験再開指示に基づいて実行されることとしたが、これに限らず、試験シナリオと関連させて試験再開を実行することとしてもよいし、試験管理装置１００が他のシステムとの連携に基づいて試験再開を実行することとしてもよい。
【０１１９】
次に、プローブＡ２００とプローブＢ４００との間での試験再開処理について説明する。図１８は、試験再開処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとし、プローブＢ４００を試験パケット受信側プローブとする。同図に示すように、先ず、プローブＡ２００の試験再開処理部２０１ｋは、試験再開情報送付依頼を送信する（ステップＳ２６１）。この試験再開情報送付依頼は、ＲＴＰパケット生成部２０３でＲＴＰパケット化され（ステップＳ２６２）、このＲＴＰパケットがＲＴＰ−Ｉ／Ｆ２０５を介してプローブＢ４００へ送信される（ステップＳ２６３、ステップＳ２６４）。
【０１２０】
ＲＴＰ−Ｉ／Ｆ部４０５を介して受信された試験再開の依頼情報を含むＲＴＰパケットは、ＴＣＰパケット抽出部４０４に送信され（ステップＳ２６５）、該ＴＣＰパケット抽出部４０４でＲＴＰデパケット化された後に試験再開処理部４０１ｋへ受け渡される（ステップＳ２６６）。試験再開処理部４０１ｋがＲＴＰデパケット化された情報を受信することにより、試験再開を認識することとなる（ステップＳ２６７）。
【０１２１】
次に、プローブＡ２００は、ＲＴＰ試験パケット送付再開依頼を送信する（ステップＳ２６８）。このＲＴＰ試験パケット送付再開依頼は、ＲＴＰパケット生成部２０３でＲＴＰパケット化され（ステップＳ２６９）、このＲＴＰパケットがＲＴＰ−Ｉ／Ｆ２０５を介してプローブＢ４００へ送信される（ステップＳ２７０、ステップＳ２７１）。
【０１２２】
プローブＢ４００は、ＲＴＰ−Ｉ／Ｆ部４０５を介して試験パケットを受信したならば、この受信パケットをＴＣＰパケット抽出部４０４へ送信する（ステップＳ２７２）。ＴＣＰパケット抽出部４０４で受信パケットのＲＴＰデカプセル化を行うことにより得た試験データを試験データ受信処理部４０１ｈへ送信する（ステップＳ２７３）。このステップＳ２７０〜ステップＳ２７３の処理が、試験シナリオに規定される試験パケット送信回数分だけ繰り返されることとなる。このようにして、中断された試験パケットの送付が再開されることとなる。実施例３によれば、遠隔からの試験再開の指示が可能となることとなる。
【０１２３】
なお、試験管理装置１００とプローブＡ２００との間のＳＩＰサーバ３００を介したセッションも同様に再開処理が可能である。よって、試験シナリオ送信処理においても、同様に送信再開処理を行うことが可能である。
【０１２４】
また、一般的に、ＳＩＰサーバ３００を介した装置間のセッションも同様に再開処理が可能である。即ち、ＳＩＰサーバ３００を介した装置間でＲＴＰパケットのペイロードにシステム間通信情報を埋め込んで送信する処理も、再開処理が可能である。よって、例えば、プローブＡ２００とプローブＢ４００との間での試験結果情報、試験開始情報、試験制御情報、試験シナリオ情報、同期時刻情報、ファームウェア更新情報等の送信処理においても、同様に送信再開処理を行うことが可能である。
【実施例４】
【０１２５】
次に、図１９〜２１を参照して、時刻同期機能を含む実施例４について説明する。実施例４におけるネットワーク構成、各装置の構成及び機能は、試験管理装置１００及びプローブＡ２００、プローブＢ４００が時刻同期機能にかかる構成を有して処理を行う以外は、実施例１のものと同一である。時刻同期機能は、音声評価システム内に配置される装置のシステム時刻の同期を取るために利用されるものである。
【０１２６】
先ず、実施例４の試験管理装置１００の構成について説明する。図１９は、実施例４の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、実施例４の試験管理装置１００は、実施例１の試験管理装置１００に、同期時刻送信部１０８をさらに有した構成となっている。この差異以外は、実施例４の試験管理装置１００は実施例１の試験管理装置１００と同一である。
【０１２７】
同期時刻送信部１０８は、端末装置９００から入力された時刻同期開始指示に基づいて、プローブへ時刻同期のための指示を送信するものである。この時刻同期指示の時刻同期対象のプローブに対しての送信に先立って、ＳＩＰサーバ３００を介したＳＩＰによるセッション確立が実行される。時刻同期指示及び同期時刻情報は、ＲＴＰパケット生成部１０３でＲＴＰパケット化された後に、ＲＴＰ−Ｉ／Ｆ部１０５を介してプローブへと送信される。
【０１２８】
次に、実施例４のプローブの構成について説明する。図２０は、実施例４のプローブＡ２００の構成を示す機能ブロック図である。なお、実施例４においても、プローブＢ４００の構成は、プローブＡ２００の構成と同一である。同図に示すように、実施例４のプローブＡ２００は、実施例１のプローブＡ２００の処理部２０１に同期時刻受信部２０１ｌ及び時刻設定部２０１ｍをさらに有した構成となっている。この差異以外は、実施例４のプローブＡ２００は実施例１のプローブＡ２００と同一である。
【０１２９】
同期時刻受信部２０１ｌは、試験管理装置１００から受信した時刻同期指示に基づいて、時刻設定部２０１ｍへ時刻同期のための指示を出力するものである。また、この指示は、ＲＴＰ−Ｉ／Ｆ部２０５を介して試験パケット送信側プローブから受信されてＲＴＰパケット抽出部２０４でＲＴＰデパケット化された後に、同期時刻受信部２０１ｌにより受信されるものである。この指示を受信した同期時刻受信部２０１ｌは、時刻設定部２０１ｍに対してシステム時刻の同期を指示することとなる。
【０１３０】
次に、試験管理装置１００とプローブＡ２００との間での時刻同期処理について説明する。図２１は、時刻同期処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。同図に示すように、先ず、端末装置９００から時刻同期開始指示が入力され（ステップＳ２８１）、試験管理装置１００の端末装置Ｉ／Ｆ部１０７を介して受信された同期時刻情報が同期時刻送信部１０８により認識される（ステップＳ２８２）。
【０１３１】
次に、同期時刻情報の送信先プローブを判断し（ステップＳ２８３）、送信先プローブとのセッションを開始するようにＳＩＰサーバ３００へ依頼する（ステップＳ２８４、ステップＳ２８５）。この依頼を受けＳＩＰサーバ３００は、該依頼をプローブＡ２００へ送信し（ステップＳ２８６）、依頼を受信した旨を試験管理装置１００へ送信する（ステップＳ２８７）。
【０１３２】
次に、プローブＡ２００では、ＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ２８８）、受信可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信する（ステップＳ２８９、ステップＳ２９０）。この受信可の情報を受信した試験管理装置１００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由してプローブＡ２００へ送信する（ステップＳ２９１、ステップＳ２９２）。
【０１３３】
そして、試験管理装置１００の処理部１０１は、セッション開始完了を検知（ステップＳ２９３）した後、同期時刻情報送付依頼を出力し（ステップＳ２９４）、この同期時刻情報をＲＴＰパケット化して（ステップＳ２９５）プローブＡ２００へ送信する（ステップＳ２９６、ステップＳ２９７）。同期時刻情報を受信したプローブＡ２００では、受信した同期時刻情報をＴＣＰパケット抽出部２０４へ送信し（ステップＳ２９８）、該ＴＣＰパケット抽出部２０４でＲＴＰデパケット化を行ったものを同期時刻受信部２０１ｌへ送信する（ステップＳ２９９）。
【０１３４】
同期時刻受信部２０１ｌでは、受信した同期時刻情報を時刻設定部２０１ｍへ送信し（ステップＳ３００）、この同期時刻情報に基づき、プローブＡ２００のシステム時刻が時刻設定部２０１ｍにより更新される（ステップＳ３０１）。
【０１３５】
同期時刻情報の送信が終了したならば、試験管理装置１００の同期時刻送信部１０８において同期時刻情報送付完了が検知され（ステップＳ３０２）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由してプローブＡ２００へ送信される（ステップＳ３０３、ステップＳ３０４、ステップＳ３０５）。
【０１３６】
プローブＡ２００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信し（ステップＳ３０６、ステップＳ３０７）、このセッション終了可の情報が最終的に同期時刻送信部１０８に検知される（ステップＳ３０８）。同期時刻送信部１０８は、セッション終了を検知すると、時刻同期終了の情報を端末装置Ｉ／Ｆ部１０７を介して端末装置９００へ送信する（ステップＳ３０９、ステップＳ３１０）。このようにして、試験管理装置１００とプローブＡ２００とのシステム時刻同期処理が終了する。実施例４によれば、遠隔からのシステム時刻の同期処理が可能となる。
【実施例５】
【０１３７】
次に、図２２〜２４を参照して、ファームウェア更新機能を含む実施例５について説明する。実施例５におけるネットワーク構成、各装置の構成及び機能は、試験管理装置１００及びプローブＡ２００、プローブＢ４００がファームウェア更新機能にかかる構成を有して処理を行う以外は、実施例１のものと同一である。ファームウェア更新機能は、音声評価システム内に配置される装置の動作を制御するファームウェアの更新を行うために利用されるものである。
【０１３８】
先ず、実施例５の試験管理装置の構成について説明する。図２２は、実施例５の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、実施例５の試験管理装置１００は、実施例１の試験管理装置１００に、ファームウェア更新情報送信部１０９をさらに有した構成となっている。この差異以外は、実施例５の試験管理装置１００は実施例１の試験管理装置１００と同一である。
【０１３９】
ファームウェア更新情報送信部１０９は、端末装置９００から入力されたファームウェア更新開始指示に基づいて、プローブへファームウェア更新のための指示を送信するものである。このファームウェア更新指示の対象のプローブに対しての送信に先立って、ＳＩＰサーバ３００を介したＳＩＰによるセッション確立が実行される。ファームウェア更新指示及びファームウェア更新情報は、ＲＴＰパケット生成部１０３でＲＴＰパケット化された後に、ＲＴＰ−Ｉ／Ｆ部１０５を介してプローブへと送信される。
【０１４０】
次に、実施例５のプローブの構成について説明する。図２２は、実施例５のプローブＡ２００の構成を示す機能ブロック図である。なお、実施例５においても、プローブＢ４００の構成は、プローブＡ２００の構成と同一である。同図に示すように、実施例５のプローブＡ２００は、実施例１のプローブＡ２００の処理部２０１にファームウェア更新情報受信部２０１ｎ及びファームウェア更新処理部２０１ｏをさらに有した構成となっている。この差異以外は、実施例５のプローブＡ２００は実施例１のプローブＡ２００と同一である。
【０１４１】
ファームウェア更新情報受信部２０１ｎは、試験管理装置１００から受信したファームウェア更新指示に基づいて、ファームウェア更新処理部２０１ｏへファームウェア更新のための指示を出力するものである。また、この指示は、ＲＴＰ−Ｉ／Ｆ部２０５を介して試験パケット送信側プローブから受信されてＲＴＰパケット抽出部２０４でＲＴＰデパケット化された後に、ファームウェア更新情報受信部２０１ｎにより受信されるものである。この指示を受信したファームウェア更新情報受信部２０１ｎは、ファームウェア更新処理部２０１ｏに対して記憶部２０２のファームウェア記憶部２０２ｄに記憶されるファームウェア更新を指示することとなる。
【０１４２】
次に、試験管理装置１００とプローブＡ２００との間でのファームウェア更新処理について説明する。図２４は、ファームウェア更新処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。同図に示すように、先ず、端末装置９００からファームウェア更新開始指示が入力され（ステップＳ３１１）、試験管理装置１００の端末装置Ｉ／Ｆ部１０７を介して受信されたファームウェア更新情報がファームウェア更新情報送信部１０９により認識される（ステップＳ３１２）。
【０１４３】
次に、ファームウェアの更新対象プローブを判断し（ステップＳ３１３）、更新対象プローブとのセッションを開始するようにＳＩＰサーバ３００へ依頼する（ステップＳ３１４、ステップＳ３１５）。この依頼を受けＳＩＰサーバ３００は、該依頼をプローブＡ２００へ送信し（ステップＳ３１６）、依頼を受信した旨を試験管理装置１００へ送信する（ステップＳ３１７）。
【０１４４】
次に、プローブＡ２００では、ＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ３１８）、受信可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信する（ステップＳ３１９、ステップＳ３２０）。この受信可の情報を受信した試験管理装置１００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由してプローブＡ２００へ送信する（ステップＳ３２１、ステップＳ３２２）。
【０１４５】
そして、試験管理装置１００の処理部１０１は、セッション開始完了を検知（ステップＳ３２３）した後、ファームウェア更新情報送付依頼を出力し（ステップＳ３２４）、このファームウェア更新情報をＲＴＰパケット化して（ステップＳ３２５）プローブＡ２００へ送信する（ステップＳ３２６、ステップＳ３２７）。ファームウェア更新情報を受信したプローブＡ２００では、受信したファームウェア更新情報をＴＣＰパケット抽出部２０４へ送信し（ステップＳ３２８）、該ＴＣＰパケット抽出部２０４でＲＴＰデパケット化を行ったものをファームウェア更新情報受信部２０１ｎへ送信する（ステップＳ３２９）。
【０１４６】
ファームウェア更新情報受信部２０１ｎでは、受信したファームウェア更新情報をファームウェア更新処理部２０１ｏへ送信し（ステップＳ３３０）、このファームウェア更新情報に基づき、プローブＡ２００のファームウェアがファームウェア更新処理部２０１ｏにより更新される（ステップＳ３３１）。
【０１４７】
ファームウェア更新情報の送信が終了したならば、試験管理装置１００のファームウェア更新情報送信部１０９においてファームウェア更新情報送付完了が検知され（ステップＳ３３２）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由してプローブＡ２００へ送信される（ステップＳ３３３、ステップＳ３３４、ステップＳ３３５）。
【０１４８】
プローブＡ２００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信し（ステップＳ３３６、ステップＳ３３７）、このセッション終了可の情報が最終的にファームウェア更新情報送信部１０９に検知される（ステップＳ３３８）。ファームウェア更新情報送信部１０９は、セッション終了を検知すると、ファームウェア更新終了の情報を端末装置Ｉ／Ｆ部１０７を介して端末装置９００へ送信する（ステップＳ３３９、ステップＳ３４０）。このようにして、プローブＡ２００のファームウェア更新処理が終了する。実施例５によれば、遠隔からのファームウェアの更新処理が可能となる。
【実施例６】
【０１４９】
次に、図２５及び２６を参照して、ＲＴＰパケット再送機能を含む実施例６について説明する。実施例６におけるネットワーク構成、各装置の構成及び機能は、プローブＡ２００（又はプローブＢ４００）のＲＴＰパケット生成部２０３（又はＲＴＰパケット生成部４０３）及びＴＣＰパケット抽出部２０４（又はＴＣＰパケット抽出部４０４）がＲＴＰパケット再送機能にかかる処理を行う以外は、実施例１のものと同一である。なお、実施例６では、プローブＡ２００を試験パケット送信側プローブとし、プローブＢ４００を試験パケット受信側プローブとする。
【０１５０】
先ず、プローブ間におけるＲＴＰパケット部分再送処理について説明する。図２５は、ＲＴＰパケット部分再送処理を示すシーケンス図である。先ず、プローブＡ２００のＲＴＰパケット生成部２０３は、試験パケットをＲＴＰパケット化し（ステップＳ３４１）、このＲＴＰパケットをＲＴＰ−Ｉ／Ｆ部２０５を介してプローブＢ４００へ送信する（ステップＳ３４２、ステップＳ３４３）。
【０１５１】
ＲＴＰ−Ｉ／Ｆ部４０５を介してＲＴＰパケットを受信したプローブＢ４００では、この受信パケットをＴＣＰパケット抽出部４０４へ送信する（ステップＳ３４４）。ＴＣＰパケット抽出部４０４では、受信パケットのＲＴＰパケットヘッダの順序情報からデータの欠落があるか否かを判定する（ステップＳ３４５）。データの欠落があると判定された場合に、欠落シーケンスの再送依頼をＲＴＰ−Ｉ／Ｆ部４０５を介してプローブＡ２００へ送信する（ステップＳ３４６、ステップＳ３４７）。
【０１５２】
ＲＴＰ−Ｉ／Ｆ部２０５を介して欠落シーケンス送信依頼を受信したプローブＡ２００は、受信した依頼をＲＴＰパケット生成部２０３へ送信する（ステップＳ３４８）。この依頼に基づき、ＲＴＰパケット生成部２０３は、該当するＲＴＰパケットをプローブＢ４００へ送信（再送）する（ステップＳ３４９、ステップＳ３５０）。この再送されたＲＴＰパケットを受信したプローブＢ４００では、該受信パケットをＴＣＰパケット抽出部４０４へ送信する（ステップＳ３５１）。そして、ＴＣＰパケット抽出部４０４がデータの再構築を行う（ステップＳ３５２）。このようにして、パケットの欠落が発生した場合に、欠落したパケットが再送され、受信データの再構築が行われることとなる。
【０１５３】
次に、プローブ間におけるＲＴＰパケット全再送処理について説明する。図２６は、ＲＴＰパケット全再送処理を示すシーケンス図である。先ず、プローブＡ２００のＲＴＰパケット生成部２０３は、試験パケットをＲＴＰパケット化し（ステップＳ３６１）、このＲＴＰパケットをＲＴＰ−Ｉ／Ｆ部２０５を介してプローブＢ４００へ送信する（ステップＳ３６２、ステップＳ３６３）。
【０１５４】
ＲＴＰ−Ｉ／Ｆ部４０５を介してＲＴＰパケットを受信したプローブＢ４００では、この受信パケットをＴＣＰパケット抽出部４０４へ送信する（ステップＳ３６４）。ＴＣＰパケット抽出部４０４では、受信パケットのＲＴＰパケットヘッダの順序情報からデータの欠落があるか否かを判定する（ステップＳ３６５）。データの欠落があると判定された場合に、全データの再送依頼をＲＴＰ−Ｉ／Ｆ部４０５を介してプローブＡ２００へ送信する（ステップＳ３６６、ステップＳ３６７）。
【０１５５】
ＲＴＰ−Ｉ／Ｆ部２０５を介して全データ再送依頼を受信したプローブＡ２００は、受信した依頼をＲＴＰパケット生成部２０３へ送信する（ステップＳ３６８）。この依頼に基づき、ＲＴＰパケット生成部２０３は、該当するデータをＲＴＰパケット化してプローブＢ４００へ再送する（ステップＳ３６９、ステップＳ３７０）。この再送されたデータを受信したプローブＢ４００では、該受信データをＴＣＰパケット抽出部４０４へ送信する（ステップＳ３７１）。このようにして、パケットの欠落が発生した場合に、全データが再送されることとなる。実施例６によれば、受信ＲＴＰパケットの欠落があった場合に、自動的に欠落シーケンス又は全データを含むＲＴＰパケットの再送処理が可能となる。特になお、欠落シーケンスのみを再送する場合には、ネットワークの負荷を高めることなく再送を実現することができる。また、欠落シーケンスが発生した場合に、全データを含むＲＴＰパケットを再送することとする場合は、パケットの組み直し処理を必要とせず、簡易な仕組みで再送機能を実装することが可能となる。
【０１５６】
なお、実施例６に示した再送機能は、次の課題を解決するためになされたものである。即ち、ＴＣＰパケットをＲＴＰペイロードに埋め込んで送受信する場合に、ＲＴＰはリアルタイム性を維持するためにＵＤＰ（User Datagram Protocol）上で実装されることが一般的である。しかし、ＵＤＰは、パケットの再送機能を持たない。このために、ＲＴＰは、再送機能を持たないことになる。これは、本来再送機能があるＴＣＰで送受信するはずのデータをＲＴＰパケット化したために、再送機能を失ってしまうという不都合がある。通信の信頼性を維持するためには、ＲＴＰにも再送機能を持たせることが必要であった。
【０１５７】
従って、実施例６の発明により、試験管理装置１００とプローブとの間、又はプローブ間において、通信の信頼性を高めることが可能となる。なお、実施例６に示した再送機能は、ＲＴＰに限らず、本来再送機能を有さない通信プロトコル一般に実装することが可能である。
【実施例７】
【０１５８】
次に、図２７〜２９を参照して、プロトコル選択機能を含む実施例７について説明する。実施例７におけるネットワーク構成、各装置の構成及び機能は、試験管理装置１００のセッション開始依頼処理部１０１ｃがプロトコル選択機能にかかる処理を行い、記憶部１０２がプロトコル管理テーブル１０２ｆをさらに有する以外は、実施例１のものと同一である。なお、実施例７は、試験管理装置１００がプローブＡ２００と接続する際の通信プロトコルを選択するものである。
【０１５９】
先ず、実施例７の試験管理装置の構成について説明する。図２７は、実施例７の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、実施例７の試験管理装置１００は、実施例１の試験管理装置１００の記憶部１０２が、プロトコル管理テーブル１０２ｆをさらに有した構成となっている。また、実施例７の試験管理装置１００は、実施例１の試験管理装置１００のセッション開始依頼処理部１０１ｃが、プロトコル選択機能にかかる機能をさらに有するものである。この差異以外は、実施例７の試験管理装置１００は実施例１の試験管理装置１００と同一である。
【０１６０】
セッション開始依頼処理部１０１ｃは、プロトコル管理テーブルに記憶されるプローブ毎の接続プロトコル種別に基づいて、プローブとの接続のための通信プロトコルを優先的に選択する。また、このプロトコル管理テーブル１０２ｆに記憶されるプローブ毎の接続プロトコル種別で接続できない場合、又はプローブ毎の接続プロトコル種別の記憶がない場合に、予め定められたプロトコル種別選択順位に基づいて、それぞれの通信プロトコルで順次接続を試行する。
【０１６１】
次に、プロトコル種別選択に関する情報について声明する。図２８は、プロトコル選択に関する図である。図２８（ａ）のプロトコル種別選択の順位を示す図に示すように、順次接続を試行する通信プロトコルの優先順位は、例えば、プロトコル（１）（ＴＣＰソケット）、プロトコル（２）（ＨＴＴＰ）、プロトコル（３）（ＳＩＰ＋ＲＴＰ）となっている。この優先順位は一例に過ぎず、システム運用の利便性を考慮して変更可能である。また、通信プロトコルの優先順位は、システム運用者の操作により、随時変更可能であるとしてもよい。
【０１６２】
図２８（ｂ）は、プロトコル管理テーブル１０２ｆのテーブルイメージを示す図である。同図に示すように、プロトコル管理テーブル１０２ｆには、プローブ毎に、試験管理装置１００との間の通信プロトコル種別が記憶されている。例えば、プローブＡはプロトコル（１）、プローブＢはプロトコル（２）、プローブＣはプロトコル（３）、・・・、と記憶されている。この記憶に基づいて、各プローブとの通信プロトコルが選択されることとなる。このプロトコル管理テーブル１０２ｆの記憶に基づいて、試験管理装置１００及び各プローブとのセッション接続の通信プロトコルが管理されることとなる。
【０１６３】
次に、プロトコル管理テーブル１０２ｆに記憶されるプローブ毎の接続プロトコル種別で接続できない場合、又はプローブ毎の接続プロトコル種別の記憶がない場合に行われるプロトコル選択処理手順について説明する。図２９は、プロトコル選択処理手順を示すフローチャートである。
【０１６４】
先ず、試験管理装置１００では、接続先プローブであるプローブＸとのセッション開始に際し、プロトコル（１）でセッション開始可能か否かを判定する（ステップＳ３８１）。プロトコル（１）でセッション開始可能である場合に（ステップＳ３８１肯定）、ステップＳ３８６へ処理を移し、プロトコル（１）でセッション開始可能でない場合に（ステップＳ３８１否定）、ステップＳ３８２へ処理を移す。
【０１６５】
ステップＳ３８２では、プローブＸとのセッション開始に際し、プロトコル（２）でセッション開始可能か否かを判定する（ステップＳ３８２）。プロトコル（２）でセッション開始可能である場合に（ステップＳ３８２肯定）、ステップＳ３８６へ処理を移し、プロトコル（２）でセッション開始可能でない場合に（ステップＳ３８２否定）、ステップＳ３８３へ処理を移す。
【０１６６】
ステップＳ３８３では、プローブＸとのセッション開始に際し、プロトコル（３）でセッション開始可能か否かを判定する（ステップＳ３８３）。プロトコル（３）でセッション開始可能である場合に（ステップＳ３８３肯定）、ステップＳ３８６へ処理を移し、プロトコル（３）でセッション開始可能でない場合に（ステップＳ３８３否定）、ステップＳ３８４へ処理を移す。
【０１６７】
ステップＳ３８４では、ステップＳ３８１〜ステップＳ３８３の処理を所定回数だけ再試行したか否かを判定する（ステップＳ３８４）。所定回数だけ再試行したと判定される場合に（ステップＳ３８４肯定）、プローブＸと試験管理装置１００との間の接続環境の確認を行う（ステップＳ３８５）。所定回数だけ再試行したと判定されない場合には（ステップＳ３８４否定）、ステップＳ３８１へ処理を移す。他方、ステップＳ３８６では、セッション開始がＯＫであったプロトコル種別をプロトコル管理テーブル１０２ｆへ登録する。以上で、プロトコル選択処理は終了する。実施例７によれば、試験管理装置１００とプローブとの通信プロトコルを自動的に選択可能となり、さらに選択された通信プロトコルを記憶しておくことにより、以降のセッション確立を迅速に行うことができる。
【０１６８】
なお、実施例７の発明は、次の課題を解決するためになされた。即ち、ネットワークの構成上、ＳＩＰ＋ＲＴＰを使用しなくとも、ＴＣＰやＨＴＴＰ／ＨＴＴＰＳなどＲＴＰとは異なる通信プロトコルを通過セルことができる設定がされているファイアウォールが存在する場合があり、ＴＣＰやＨＴＴＰ／ＨＴＴＰＳがデータ通信の通信プロトコルとなりうる場合がある。かかる場合にも、システムが最適なプロトコルを自動的に選択することにより、セキュリティの設定ミスによる問題発生を未然に防ぐ必要があった。
【実施例８】
【０１６９】
次に、図３０及び３１を参照して、ＲＴＰセッション開始ネゴシエーション機能を含む実施例８について説明する。実施例８におけるネットワーク構成、各装置の構成及び機能は、試験管理装置１００の処理部１０１がセッション開始ネゴシエーション処理部１０１ｉをさらに有する以外は、実施例１のものと同一である。なお、実施例８では、プローブＡ２００を試験パケット送信側プローブとする。
【０１７０】
先ず、実施例８の試験管理装置１００の構成について説明する。図３０は、実施例８の試験管理装置１００の構成を示す機能ブロック図である。同図に示すように、実施例８の試験管理装置１００は、実施例１の試験管理装置１００の処理部１０１がセッション開始ネゴシエーション処理部１０１ｉをさらに有した構成となっている。この差異以外は、実施例８の試験管理装置１００は実施例１の試験管理装置１００と同一である。
【０１７１】
セッション開始ネゴシエーション処理部１０１ｉは、プローブＡ２００へのＲＴＰパケット送信に先立って、データ送信開始要求をプローブＡ２００へ送信し、この要求に対してプローブＡ２００からＯＫが返却されてきた場合にのみＲＴＰパケット送信を行う。データ送信開始要求に対してプローブＡ２００からＯＫが返却されて来なかった場合は、セッション終了依頼処理部１０１ｅに対してセッションの終了依頼を指示する。
【０１７２】
次に、試験管理装置１００とプローブＡ２００との間での通信処理においてＲＴＰセッション開始ネゴシエーション処理を含んだ試験シナリオ送信処理について説明する。図３１は、セッション開始ネゴシエーション処理を示すシーケンス図である。同図では、プローブＡ２００を試験パケット送信側プローブとする。なお、試験シナリオ送信処理に限らず、全てのＲＴＰパケット通信に同様に適用可能である。同図に示すように、先ず、端末装置９００から試験シナリオが入力され（ステップＳ３９１）、試験管理装置１００の端末装置Ｉ／Ｆ部１０７を介して受信された該試験シナリオが処理部１０１により記憶部１０２に登録される（ステップＳ３９２）。
【０１７３】
次に、試験シナリオに基づいて試験パケット送信側プローブを判断し（ステップＳ３９３）、送信側プローブとのセッションを開始するようにＳＩＰサーバ３００へ依頼する（ステップＳ３９４、ステップＳ３９５）。この依頼を受けＳＩＰサーバ３００は、該依頼をプローブＡ２００へ送信し（ステップＳ３９６）、依頼を受信した旨を試験管理装置１００へ送信する（ステップＳ３９７）。
【０１７４】
次に、プローブＡ２００では、ＳＩＰ−ＵＲＩ受信許可判定処理部２０１ａが、記憶される受信許可ＳＩＰ−ＵＲＩに基づき受信許可されるＳＩＰ−ＵＲＩからの依頼か否かを判定し（ステップＳ３９８）、受信可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信する（ステップＳ３９９、ステップＳ４００）。この受信可の情報を受信した試験管理装置１００は、ＡＣＫ（セッション確立了解）をＳＩＰサーバ３００経由してプローブＡ２００へ送信する（ステップＳ４０１、ステップＳ４０２）。
【０１７５】
そして、試験管理装置１００の処理部１０１は、セッション開始完了を検知（ステップＳ４０３）した後、試験シナリオ送付依頼を出力する（ステップＳ４０４）。この試験シナリオをＲＴＰパケット化して（ステップＳ４０５）ＲＴＰ−Ｉ／Ｆ部１０５へ送信する（ステップＳ４０６）。このＲＴＰパケット化された試験シナリオをプローブＡ２００へ送信するのに先立ち、データ通信開始要求をプローブＡ２００へ送信する（ステップＳ４０７）。このデータ通信開始要求に対して開始可であれば、プローブＡ２００のＲＴＰ−Ｉ／Ｆ部４０９から試験管理装置１００へデータ通信開始可の情報が送信される（ステップＳ４０８）。なお、Ｓ４０８のＯＫが到達したと判断されない場合には、試験管理装置１００は、プローブＡ２００へ、セッション切断要求を送信することとなる。
【０１７６】
前述のデータ通信開始可の情報が試験管理装置１００に送達したならば、ＲＴＰパケット化された試験シナリオをプローブＡ２００へ送信する（ステップＳ４０９、ステップＳ４１０）。試験シナリオを受信したプローブＡ２００では、受信した試験シナリオをＴＣＰパケット抽出部２０４へ送信し（ステップＳ４１０）、該ＴＣＰパケット抽出部２０４でＲＴＰデパケット化を行ったものを試験シナリオ受信処理部２０１ｃへ送信する（ステップＳ４１１）。
【０１７７】
試験シナリオ受信処理部２０１ｃでは、受信した試験シナリオのシーケンスから試験シナリオを組み立て（ステップＳ４１２）、この試験シナリオを試験実行部２０１ｉへ送信する（ステップＳ４１３）。
【０１７８】
試験シナリオの送信が終了したならば、試験管理装置１００の処理部１０１において試験シナリオ送付完了が検知され（ステップＳ４１４）、続いて、セッション終了依頼がＳＩＰサーバ３００を経由してプローブＡ２００へ送信される（ステップＳ４１５、ステップＳ４１６、ステップＳ４１７）。
【０１７９】
プローブＡ２００は、セッション終了依頼を受信したならば、セッション終了可の情報をＳＩＰサーバ３００を経由して試験管理装置１００へ送信し（ステップＳ４１８、ステップＳ４１９）、このセッション終了可の情報が最終的に処理部１０１に検知される（ステップＳ４２０）。処理部１０１は、セッション終了を検知すると、試験シナリオ登録完了の情報を端末装置Ｉ／Ｆ部１０７を介して端末装置９００へ送信する（ステップＳ４２１、ステップＳ４２２）。このように、ステップＳ４０６とステップＳ４０９との間にステップＳ４０７とステップＳ４０８を実行することにより、ＲＴＰパケットをプローブＡ２００に送信する際に送信先を間違えた場合に、音声データとして異音を発生させることのないビット構成として異音を発生させることなくスムースにセッションを終了させることができる。
【０１８０】
なお、実施例８の発明は、次の課題を解決すためになされた。即ち、試験データの受信側プローブとなり得る装置ではあるが、誤った装置へ試験データを送信した場合であって、特にその装置がＩＰ電話機であった場合に、このＩＰ電話機において試験データは音声データとして変換されることになる。この音声データは本来の音声データではないために、異音として受信者に届くことが考えられる。このような事故を未然に防ぎ、スムースに運用を終了させる必要があったことである。
【０１８１】
以上の実施例１〜８でＲＴＰパケットされて送信される制御情報は、試験結果、試験開始情報、試験制御情報（試験中断情報や試験再開情報など）、試験シナリオ情報、試験終了情報、時刻同期情報、ファームウェア更新情報などがあるが、これらに限定されるものではない。
【０１８２】
以上の実施例１〜８では、本発明の適用例の一例として、通話音質評価試験を例示したが、これに限らず、ネットワークのノード故障検知試験、疎通試験、ループバック試験などにも適用可能である。
【０１８３】
以上の実施例１〜８は、本発明を試験管理装置１００とプローブとＳＩＰサーバ３００とが配置される通話音質評価システムに適用した場合を示したが、通話音質評価システムに限らず、試験管理装置１００、プローブ及びＳＩＰサーバ３００以外の通信装置が配置された音声パケットで通信を行う通信システム一般に広く適用可能である。また、音声パケットをＲＴＰパケットとした場合も、このＲＴＰパケットに限らず、広く音声パケット一般に適用可能である。さらに、システム間通信制御データをＴＣＰパケットにより送受信するとした場合も、このＴＣＰパケットに限らず、制御データを送受信可能なプロトコル一般に適用可能である。
【０１８４】
以上、本発明の実施例１〜８を説明したが、本発明は、これらに限られるものではなく、特許請求の範囲に記載した技術的思想の範囲内で、更に種々の異なる実施例で実施されてもよいものである。また、当然に、実施例１〜８は同時に実施可能であるものである。また、実施例１〜８に記載した効果は、これに限定されるものではない。
【０１８５】
（付記１）音声パケットのみを通過させるセキュアなネットワークにおいて、該ネットワーク上に配置される試験通信装置間における通話音質試験のために、該ネットワークに接続される試験管理装置と該試験通信装置との間、及び該試験通信装置間で、該通話音質試験にかかる通信情報を送受信する通話音質評価システムであって、
前記通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする通話音質評価システム。
【０１８６】
（付記２）前記試験管理装置から前記試験通信装置へ、前記通話音質試験にかかる前記通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする付記１に記載の通話音質評価システム。
【０１８７】
（付記３）前記通話音質試験の開始に先立って、前記試験管理装置から前記試験通信装置へ、該試験通信装置が実行する該通話音質試験の試験内容及び試験手順を定めた試験シナリオを前記音声パケットのペイロードに埋め込んで送信することを特徴とする付記１又は２に記載の通話音質評価システム。
【０１８８】
（付記４）前記試験通信装置から他方の試験通信装置へ、前記通話音質試験のための前記通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする付記１、２又は３に記載の通話音質評価システム。
【０１８９】
（付記５）前記ネットワークは、該ネットワークに接続又は該ネットワーク上に配置される装置の追加又は移動が可能であり、該接続元装置から接続先装置への伝送路確保を行う伝送路確保装置がさらに配置されていることを特徴とする付記１〜４のいずれか一つに記載の通話音質評価システム。
【０１９０】
（付記６）前記接続先装置が、該接続先装置との通信を許可する接続元装置からの通信開始依頼か否かを判定し、該判定結果が接続先装置との通信を許可する接続元装置からの通信開始依頼である場合に、通信開始を許可する通信許可手段を備えたことを特徴とする付記５に記載の通話音質評価システム。
【０１９１】
（付記７）前記接続先装置は、前記接続元装置のＵＲＩ（Uniform Resource Indicator）に基づいて該接続元装置が接続を許可された装置であるかを判定し、接続を許可することを特徴とする付記５又は６に記載の通話音質評価システム。
【０１９２】
（付記８）前記ネットワークに接続又は配置される送信側装置から受信側装置へ、同期時刻情報を前記音声パケットのペイロードに埋め込んで送信することにより、該装置間での時刻同期が可能なことを特徴とする付記１〜７のいずれか一つに記載の通話音質評価システム。
【０１９３】
（付記９）前記ネットワークに接続又は配置される送信側装置から受信側装置へ、ファームウェア情報を前記音声パケットのペイロードに埋め込んで送信することにより、該受信側装置のファームウェアの更新が可能なことを特徴とする付記１〜７のいずれか一つに記載の通話音質評価システム。
【０１９４】
（付記１０）音声パケットのみを通過させるセキュアなネットワークにおいて、音声パケットを送受信して音声通話のための通信を行うネットワークに接続される装置間でシステム間通信情報を送受信する通信システムであって、
前記システム間通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする通信システム。
【０１９５】
（付記１１）前記ネットワークは、該ネットワークに接続又は該ネットワーク上に配置される装置の追加又は移動が可能であり、接続先装置を確認することにより接続元装置から該接続先装置への伝送路確保を行う伝送路確保装置がさらに配置されており、
前記装置から受信側装置への通信に先立って行われる前記伝送路確保装置を介した伝送路確保の際に、該伝送路確保にかかるシステム間通信情報を前記音声パケットのペイロードに埋め込んで送受信することを特徴とする付記１０に記載の通信システム。
【０１９６】
（付記１２）通信プロトコル選択基準に基づいて前記通信に使用する通信プロトコルを選択する通信プロトコル選択手段と、
前記通信プロトコル選択手段により選択された前記通信プロトコルを記憶管理するプロトコル管理手段と
をさらに有することを特徴とする付記１０又は１１に記載の通信システム。
【０１９７】
（付記１３）前記ネットワークに接続又は配置される送信側装置から受信側装置へ送信される前記音声パケットは、ＲＴＰ（Real-time Transport Protocol）パケットであることを特徴とする付記１０、１１又は１２に記載の通信システム。
【０１９８】
（付記１４）前記ＲＴＰパケットは、複数のシーケンスからなり、
前記受信側装置における前記ＲＴＰパケットの受信時において、該複数のシーケンスのうちの一部が欠落したと判定される場合に、前記送信側装置に該欠落したシーケンス又は該ＲＴＰパケットの再送を要求する再送要求手段を有することを特徴とする付記１３に記載の通信システム。
【０１９９】
（付記１５）前記送信側装置は、前記送信側装置から前記受信側装置への前記ＲＴＰパケットの送信時において、該送信側装置から該受信側装置への該ＲＴＰパケット送信の許可の要求に対して該送信側装置が該受信側装置から該許可を受信した場合に、該ＲＴＰパケットの送信を開始することを特徴とする付記１３又は１４に記載の通信システム。
【０２００】
（付記１６）前記送信側装置は、前記送信側装置から前記受信側装置への前記ＲＴＰパケットの送信時において、該送信側装置から該受信側装置への該ＲＴＰパケット送信の許可の要求に対して該送信側装置が該受信側装置から該許可を受信しなかった場合に、該ＲＴＰパケットの送信を中止することを特徴とする付記１５に記載の通信システム。
【０２０１】
（付記１７）音声パケットを送受信して音声通話のための通信を行うネットワーク上に配置される試験通信装置間における通話音質試験を管理する試験管理装置であって、
前記試験通信装置へ、前記通話音質試験にかかる通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする試験管理装置。
【０２０２】
（付記１８）前記通話音質試験の開始に先立って、前記試験通信装置へ、該試験通信装置が実行する該通話音質試験の試験内容及び試験手順を定めた試験シナリオを前記音声パケットのペイロードに埋め込んで送信することを特徴とする付記１７に記載の試験管理装置。
【０２０３】
（付記１９）前記ネットワーク上配置される前記試験通信装置へ、同期時刻情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする付記１７又は１８に記載の試験管理装置。
【０２０４】
（付記２０）前記ネットワーク上に配置される前記試験通信装置へ、ファームウェア情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする付記１７又は１８に記載の試験管理装置。
【０２０５】
（付記２１）音声パケットを送受信して音声通話のための通信を行うネットワーク上に通話音質試験を行うために配置される試験通信装置であって、
他の試験通信装置へ、前記通話音質試験にかかる通信情報を前記音声パケットのペイロードに埋め込んで送信することを特徴とする試験通信装置。
【０２０６】
（付記２２）前記音声パケットは、複数のシーケンスからなり、
前記他の試験通信装置からの前記通信情報の受信時において、該複数のシーケンスのうちの一部が欠落したと判定される場合に、該他の試験通信装置に該欠落したシーケンス又は該音声パケットの再送を要求する再送要求手段を有することを特徴とする付記２１に記載の試験通信装置。
【０２０７】
（付記２３）他の試験通信装置への前記音声パケットの送信時において、該他の試験通信装置への該音声パケット送信の許可の要求に対して該他の試験通信装置から該許可を受信した場合に、該音声パケットの送信を開始することを特徴とする付記２１又は２２に記載の試験通信装置。
【０２０８】
（付記２４）他の試験通信装置への前記音声パケットの送信時において、該他の試験通信装置への該音声パケット送信の許可の要求に対して該他の試験通信装置から該許可を受信しなかった場合に、該音声パケットの送信を中止することを特徴とする付記２１又は２２に記載の試験通信装置。
【産業上の利用可能性】
【０２０９】
本発明は、従来からある装置やネットワークの仕様を変更することをなく許可されない端末装置からの接続を排除し、かつ音声通信システムのネットワークの構成や設定を変更することなく通話音質試験を行いたい場合に有用である。
【図面の簡単な説明】
【０２１０】
【図１】音声専用ネットワークにおける音声評価試験の問題点の概略を示す図である。
【図２】ＴＣＰパケットのＲＴＰパケット化の概要を説明する図である。
【図３】ＲＴＰパケットの使用方法を示す図である。
【図４】本発明の音声専用ネットワークにおける音声評価試験の概要を示す図である。
【図５】音声専用ネットワークにおける音声評価試験システムのネットワーク構成を示す図である。
【図６】実施例１の試験管理装置の構成を示す機能ブロック図である。
【図７】実施例１のプローブの構成を示す機能ブロック図である。
【図８】試験シナリオ送信処理を示すシーケンス図である。
【図９】ＲＴＰ試験パケット送信処理を示すシーケンス図である。
【図１０】試験結果送信処理を示すシーケンス図である。
【図１１】実施例２の試験管理装置の構成を示す機能ブロック図である。
【図１２】実施例２のプローブの構成を示す機能ブロック図である。
【図１３】試験中断処理を示すシーケンス図である。
【図１４】試験中断処理を示すシーケンス図である。
【図１５】実施例３の試験管理装置の構成を示す機能ブロック図である。
【図１６】実施例３のプローブの構成を示す機能ブロック図である。
【図１７】試験再開処理を示すシーケンス図である。
【図１８】試験再開処理を示すシーケンス図である。
【図１９】実施例４の試験管理装置の構成を示す機能ブロック図である。
【図２０】実施例４のプローブの構成を示す機能ブロック図である。
【図２１】時刻同期処理を示すシーケンス図である。
【図２２】実施例５の試験管理装置の構成を示す機能ブロック図である。
【図２３】実施例５のプローブの構成を示す機能ブロック図である。
【図２４】ファームウェア更新処理を示すシーケンス図である。
【図２５】ＲＴＰ試験パケット部分再送処理を示すシーケンス図である。
【図２６】ＲＴＰ試験パケット全再送処理を示すシーケンス図である。
【図２７】第７実施例の試験管理装置の構成を示す機能ブロック図である。
【図２８】プロトコル種別選択に関する図である。
【図２９】プロトコル選択処理手順を示すフローチャートである。
【図３０】第８実施例の試験管理装置の構成を示す機能ブロック図である。
【図３１】ＲＴＰセッション開始ネゴシエーション処理を示すシーケンス図である。
【符号の説明】
【０２１１】
１００    試験管理装置
１０１    処理部
１０１ａ    受信許可ＳＩＰ−ＵＲＩ情報生成部
１０１ｂ    ＳＩＰ−ＵＲＩ受信許可判定処理部
１０１ｃ    セッション開始依頼処理部
１０１ｄ    試験シナリオ処理部
１０１ｅ    セッション終了依頼処理部
１０１ｆ    試験結果受信部
１０１ｇ    試験中断処理部
１０１ｈ    試験再開処理部
１０１ｉ    セッション開始ネゴシエーション処理部
１０２    記憶部
１０２ａ    プローブ情報記憶部
１０２ｂ    試験管理装置情報記憶部
１０２ｃ    受信許可ＳＩＰ−ＵＲＩ記憶部
１０２ｄ    試験シナリオ記憶部
１０２ｅ    試験結果蓄積部
１０２ｆ    プロトコル管理テーブル
１０３    ＲＴＰパケット生成部
１０４    ＴＣＰパケット抽出部
１０５    ＲＴＰ−Ｉ／Ｆ部
１０６    ＳＩＰサーバＩ／Ｆ部
１０７    端末装置Ｉ／Ｆ部
１０８    同期時刻送信部
１０９    ファームウェア更新情報送信部
２００    プローブＡ
２０１    処理部
２０１ａ    ＳＩＰ−ＵＲＩ受信許可判定処理部
２０１ｂ    セッション開始処理部
２０１ｃ    試験シナリオ受信処理部
２０１ｄ    試験データ通知処理部
２０１ｅ    試験結果判定処理部
２０１ｆ    試験結果通知処理部
２０１ｇ    セッション終了処理部
２１０ｈ    試験データ受信処理部
２０１ｉ    試験実行部
２０１ｊ    試験中断処理部
２０１ｋ    試験再開処理部
２０１ｌ    同期時刻受信部
２０１ｍ    時刻設定部
２０１ｎ    ファームウェア更新情報受信部
２０１ｏ    ファームウェア更新処理部
２０２    記憶部
２０２ａ    受信許可ＳＩＰ−ＵＲＩ記憶部
２０２ｂ    試験シナリオ記憶部
２０２ｃ    試験データ記憶部
２０３    ＲＴＰパケット生成部
２０４    ＴＣＰパケット抽出部
２０５    ＲＴＰ−Ｉ／Ｆ部
２０６    ＳＩＰサーバＩ／Ｆ部
３００    ＳＩＰサーバ
４００    プローブＢ
４０１ｄ    試験データ通知処理部
４０１ｈ    試験データ受信処理部
４０１ｊ    試験中断処理部
４０１ｋ    試験再開処理部
４０３    ＲＴＰパケット生成部
４０４    ＴＣＰパケット抽出部
４０５    ＲＴＰ−Ｉ／Ｆ部
５００ａ    ルータＡ
５００ｂ    ルータＢ
６００ａ、６００ｂ    ＩＰ電話機
７００ａ    ファイアウォールＡ
７００ｂ    ファイアウォールＢ
８００ａ    音声専用ネットワークＡ
８００ｂ    音声専用ネットワークＢ
９００    端末装置
【図１】
2007259320.tif 000003
【図２】
2007259320.tif 000004
【図３】
2007259320.tif 000005
【図４】
2007259320.tif 000006
【図５】
2007259320.tif 000007
【図６】
2007259320.tif 000008
【図７】
2007259320.tif 000009
【図８】
2007259320.tif 000010
【図９】
2007259320.tif 000011
【図１０】
2007259320.tif 000012
【図１１】
2007259320.tif 000013
【図１２】
2007259320.tif 000014
【図１３】
2007259320.tif 000015
【図１４】
2007259320.tif 000016
【図１５】
2007259320.tif 000017
【図１６】
2007259320.tif 000018
【図１７】
2007259320.tif 000019
【図１８】
2007259320.tif 000020
【図１９】
2007259320.tif 000021
【図２０】
2007259320.tif 000022
【図２１】
2007259320.tif 000023
【図２２】
2007259320.tif 000024
【図２３】
2007259320.tif 000025
【図２４】
2007259320.tif 000026
【図２５】
2007259320.tif 000027
【図２６】
2007259320.tif 000028
【図２７】
2007259320.tif 000029
【図２８】
2007259320.tif 000030
【図２９】
2007259320.tif 000031
【図３０】
2007259320.tif 000032
【図３１】
2007259320.tif 000033