(57)【要約】      （修正有）【課題】シグナリングプロトコルにより制御されるＩＰ電話等のインターネットサービスで、網の品質を監視する技術に関し、ネットワークの品質を迅速に監視可能とする。【解決手段】ＳＩＰパケット抽出部２０２は、ＳＩＰパケットを抽出し、ＳＩＰパケット解析部２０３は、ＳＩＰパケットを解析することにより、セッション状態の遷移を管理しながら、ＳＩＰパケットから得られるＳＩＰ情報及びセッション状態を、セッション毎及び入側及び出側毎に関連付けてセッション管理テーブルとして管理し、記憶部２０５に記憶する。ＳＩＰ品質分析部２０４は、セッション管理テーブルのうち、通信終了（完了／不完了）等の所定の通信状態に遷移したセッションに対応するセッション管理テーブルから、ネットワーク品質に関する品質情報を収集し、その収集結果に基づいてネットワーク品質に関する統計情報を分析する。これらは、統計情報通知部２０６によって通知される。【選択図】図２
2010141855.tif 000002
【特許請求の範囲】
【請求項１】
インターネットプロトコルに基づいて通信が行われるＩＰネットワーク上で運用され、シグナリングプロトコルに基づいて通信の状態が制御されるインターネットサービスにおいてネットワーク品質を監視するネットワーク品質監視装置であって、
前記シグナリングプロトコルを処理するサーバ装置であってクライアントからのリクエストを受信するシグナリングプロトコルサーバ装置が前記ＩＰネットワークとの間で通信するパケットを受信するパケット受信部と、
該パケット受信部が受信したパケットのうち、前記シグナリングプロトコルを制御するためのシグナリングプロトコルパケットを抽出するシグナリングプロトコルパケット抽出部と、
該シグナリングプロトコルパケット抽出部が抽出し、前記シグナリングプロトコルサーバ装置が該装置の入側及び出側のそれぞれで送受信する前記通信のセッションを確立するためのシグナリングプロトコルパケットを解析することにより、前記セッション状態の遷移を管理しながら、前記シグナリングプロトコルパケットから得られるシグナリングプロトコル情報及び前記セッション状態を、前記セッション毎及び前記入側及び出側毎に関連付けてセッション管理テーブルとして管理するシグナリングプロトコルパケット解析部と、
前記セッション管理テーブルを記憶するセッション管理テーブル記憶部と、
該セッション管理テーブル記憶部に記憶されるセッション管理テーブルのうち、所定の通信状態に遷移したセッションに対応するセッション管理テーブルから、前記ネットワーク品質に関する品質情報を収集し、該収集結果に基づいて前記ネットワーク品質に関する統計情報を分析するシグナリングプロトコル品質分析部と、
該シグナリングプロトコル品質分析部にて得られた前記品質情報及び前記統計情報を通知する統計情報通知部と、
を含むことを特徴とするネットワーク品質監視装置。
【請求項２】
前記所定の通信状態に遷移したセッションは、前記通信の呼設定開始後通話中状態に遷移したセッション及び前記通信の呼設定開始後通話中状態に達しないで不完了の終了状態に遷移したセッションを含む、
ことを特徴とする請求項１に記載のネットワーク品質監視装置。
【請求項３】
前記シグナリングプロトコル品質分析部は、前記入側及び出側のそれぞれの単位、及び該入側及び出側を纏めた前記セッションの単位で、前記品質情報の収集及び前記統計情報の分析を行う、
ことを特徴とする請求項１又は２の何れか１項に記載のネットワーク品質監視装置。
【請求項４】
前記シグナリングプロトコルパケット解析部は、前記シグナリングプロトコル情報の受信時刻を収集して前記セッション管理テーブルにて管理し、
前記シグナリングプロトコル品質分析部は、前記セッション管理テーブルから、前記シグナリングプロトコル情報の受信時刻に関する情報を収集し、該収集結果に基づいて前記ネットワークの接続時間に関する統計情報を分析する、
ことを特徴とする請求項１乃至３の何れか１項に記載のネットワーク品質監視装置。
【請求項５】
前記シグナリングプロトコルパケット解析部は、前記シグナリングプロトコル情報の受信時刻を収集して前記セッション管理テーブルにて管理し、
前記シグナリングプロトコル品質分析部は、前記セッション管理テーブルから、前記入側及び出側のそれぞれに対応するシグナリングプロトコル情報の受信時刻に関する情報を収集して該入側及び出側間の時間差に関する情報を算出することにより、前記シグナリングプロトコルサーバ装置の処理時間に関する統計情報を分析する、
ことを特徴とする請求項１乃至４の何れか１項に記載のネットワーク品質監視装置。
【請求項６】
インターネットプロトコルに基づいて通信が行われるＩＰネットワーク上で運用され、シグナリングプロトコルに基づいて通信の状態が制御されるインターネットサービスにおいてネットワーク品質を監視するネットワーク品質監視方法であって、
前記シグナリングプロトコルを処理するサーバ装置であってクライアントからのリクエストを受信するシグナリングプロトコルサーバ装置が前記ＩＰネットワークとの間で通信するパケットを受信するパケット受信ステップと、
該パケット受信ステップが受信したパケットのうち、前記シグナリングプロトコルを制御するためのシグナリングプロトコルパケットを抽出するシグナリングプロトコルパケット抽出ステップと、
該シグナリングプロトコルパケット抽出ステップが抽出し、前記シグナリングプロトコルサーバ装置が該装置の入側及び出側のそれぞれで送受信する前記通信のセッションを確立するためのシグナリングプロトコルパケットを解析することにより、前記セッション状態の遷移を管理しながら、前記シグナリングプロトコルパケットから得られるシグナリングプロトコル情報及び前記セッション状態を、前記セッション毎及び前記入側及び出側毎に関連付けてセッション管理テーブルとして管理するシグナリングプロトコルパケット解析ステップと、
前記セッション管理テーブルのうち、所定の通信状態に遷移したセッションに対応するセッション管理テーブルから、前記ネットワーク品質に関する品質情報を収集し、該収集結果に基づいて前記ネットワーク品質に関する統計情報を分析するシグナリングプロトコル品質分析ステップと、
該シグナリングプロトコル品質分析ステップにて得られた前記品質情報及び前記統計情報を通知する統計情報通知ステップと、
を含むことを特徴とするネットワーク品質監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
開示する技術は、シグナリングプロトコルにより制御されるＩＰ電話等のインターネットサービスで、網の品質を監視する技術に関する。この品質監視は例えば、シグナリングサーバやルータ等において故障や輻輳などが発生した場合に影響を受ける範囲（局番、ユーザ）を特定するために利用することができる。
【背景技術】
【０００２】
インターネット上でピア・ツー・ピアで通信を行うサービスでは、音声や映像、テキスト等のメディア情報をＩＰ（インターネットプロトコル）パケットを使ってリアルタイムに伝送するための技術が必要である。これに加えて、インターネット上でピア・ツー・ピアのセッション（呼）の確立・変更・切断（終了）を制御するためのシグナリング技術が重要である。ピア・ツー・ピア通信のサービスとしては、ＩＰ電話やテレビ電話、インスタントメッセンジャー等がある。
【０００３】
特に、近年普及の著しいＩＰ電話は、音声信号をＩＰパケットでリアルタイム伝送するためのＶｏＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  ＩＰ）技術と、シグナリング技術とを組み合わせて実現されている。
【０００４】
ＩＰ電話で利用可能なシグナリングプロトコルには、ＩＴＵ−Ｔ（国際電気通信連合電気通信標準化セクタ：Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  ｓｅｃｔｏｒ）が１９９７年に勧告したＨ．３２３方式が実現されている。また、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）にて標準化され２００２年に発行されたＲＦＣ３２６１でスタンダードトラックとして規定された、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が実現されている。特に、ＳＩＰは、メッセージがテキストで記述される。また、ＳＩＰは、ＷｅｂのためのＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や電子メールのためのＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍｅｓｓａｇｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を模範に設計された。このため、ＳＩＰは、シンプルで拡張性が高くインターネットと親和性が高く、ＩＰ電話で用いられるシグナリングプロトコルの標準となりつつある。
【０００５】
ＳＩＰは、アプリケーション層で、端末間において、セッション（呼）の確立・変更・切断（終了）を制御するためのシグナリングプロトコルである。
インターネット上に配置されるＳＩＰサーバと呼ばれる中継用のサーバを介して端末間で、メソッド（ＳＩＰリクエストメッセージ）とレスポンス（ＳＩＰレスポンスメッセージ）が所定の手順に従って交換される。これにより、セッションの確立・変更・切断（終了）が制御される。
【０００６】
例えば、セッションの確立は、ＩＮＶＩＴＥ（招待）メッセージの送信から始まる。ＳＩＰにおける端末（ＵＡ：Ｕｓｅｒ  Ａｇｅｎｔ）の識別は、ｓｉｐ：ｈａｎａｋｏ＠ｆｕｊｉｔｓｕ．ｃｏｍ、ｓｉｐ：ｔａｒｏ＠ｆｕｊｉｔｓｕ．ｃｏｍのように、ＵＲＩ（Ｕｎｉｖｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）形式で行われる。
【０００７】
ＳＩＰメッセージの交換では、メディア（音声・映像・テキスト）として何が使用されるのか、例えば音声メディアなら使用される符号化方式、音声パケットを運ぶプロトコル、使用するポート番号や音声パケット送出周期等が通知される。
【０００８】
電話サービス全般において、ネットワーク障害発生時の対応とすばやいサービスの回復は、顧客満足度及びサービスへの信頼性を確保するための要である。障害発生時においては、想定される顧客問合せへの適切な対応のため、また、影響の拡大抑止とサービス復旧のために、迅速にネットワーク品質と影響範囲（影響ユーザ）を把握することが求められている。
【０００９】
従来の公衆交換電話網：ＰＳＴＮ（Ｐｕｂｌｉｃ  Ｓｗｉｃｈｅｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ）は、ひとつの回線単位で通信路が確保され、通信エラーや輻輳などが検出されると通信路自体が閉塞される方式であった。このため、通信路の閉塞状態を確認することで回線の品質や影響範囲を特定することができた。
【００１０】
ＩＰ電話は、新しい形態の電話サービスであり、基本的にはＩＰプロトコルに従ったサービスである。このため、ＰＳＴＮにあったような通信路という概念に基づいてネットワークの品質や障害範囲を特定する技術は、適用することができない。
【００１１】
従って、ＩＰ電話サービスにおける品質監視及び障害検出は従来、ＩＰ網の品質及び障害検出手法に頼っているというのが現実であった。
例えば下記特許文献１に記載されている従来技術では、端末間でインターネットを構成する全ての経路の組合せについて通信品質情報が測定されることにより障害が発生した経路組が特定される。
【００１２】
また、ＩＰ網がツリー構成を採っている場合には、予めネットワーク装置間の接続情報とネットワーク装置に収容されているユーザ情報とが対応付けられて管理される。そして、障害が発生した際は、その発生箇所よりユーザ側のネットワークに収容されている全てのユーザが影響を受けていると見なされるような制御が考えられる。
【００１３】
更に、ＩＰ網がメッシュ構成をとっている場合には、対置間（局番間）での通話試験により影響範囲を絞り込んでいくという手法が考えられる。
【特許文献１】特開２００５−１０２１８０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、上述の特許文献１に記載の従来技術は、全ての経路組を想定しなければならないため、現在のインターネットのように膨大な規模を有するネットワークに適用するには非現実的であるという問題点を有していた。
【００１５】
また、ツリー構成やメッシュ構成を想定した前述の従来技術も、ＩＰ電話ネットワークのようなシグナリングプロトコルに基づいて制御されるネットワーク全体に適用することは、やはり非現実的である。
【００１６】
このように従来は、シグナリングプロトコルに基づくＩＰ電話サービス等のインターネットサービスが、パケット単位でデータが運ばれネットワークで障害が発生しても障害箇所を迂回して音声パケットが最終的に目的地に到達可能なプロトコルである。このため、これらのサービスでは、障害発生時に、迂回でサービスへの影響が回避されたのか或いは迂回路も塞がっていて影響を受けてしまったのかを、ピア・ツー・ピアレベルで的確に判断し影響の範囲を特定することが困難であるという問題点を有していた。
【００１７】
従って、開示する技術が解決しようとする課題は、シグナリングプロトコルに基づいて制御されるインターネットサービスにおいて、ネットワークの品質を迅速に監視可能とす
ることにある。
【課題を解決するための手段】
【００１８】
開示する技術の態様は、インターネットプロトコルに基づいて通信が行われるＩＰネットワーク上で運用され、シグナリングプロトコルに基づいて通信の状態が制御されるインターネットサービスにおいてネットワーク品質を監視するネットワーク品質監視装置を前提とする。
【００１９】
パケット受信部は、シグナリングプロトコルを処理するサーバ装置であってクライアントからのリクエストを受信するシグナリングプロトコルサーバ装置がＩＰネットワークとの間で通信するパケットを受信する。
【００２０】
シグナリングプロトコルパケット抽出部は、パケット受信部が受信したパケットのうち、シグナリングプロトコルを制御するためのシグナリングプロトコルパケットを抽出する。
【００２１】
シグナリングプロトコルパケット解析部は、シグナリングプロトコルパケット抽出部が抽出し、シグナリングプロトコルサーバ装置がその入側及び出側のそれぞれで送受信する通信のセッションを確立するためのシグナリングプロトコルパケットを解析することにより、セッション状態の遷移を管理しながら、シグナリングプロトコルパケットから得られるシグナリングプロトコル情報及びセッション状態を、セッション毎及び入側及び出側毎に関連付けてセッション管理テーブルとして管理する。
【００２２】
セッション管理テーブル記憶部は、セッション管理テーブルを記憶する。
シグナリングプロトコル品質分析部は、セッション管理テーブル記憶部に記憶されるセッション管理テーブルのうち、所定の通信状態に遷移したセッションに対応するセッション管理テーブルから、ネットワーク品質に関する品質情報を収集し、その収集結果に基づいてネットワーク品質に関する統計情報を分析する。
【００２３】
統計情報通知部は、シグナリングプロトコル品質分析部にて得られた品質情報及び統計情報を通知する。
【発明の効果】
【００２４】
開示した技術によれば、シグナリングプロトコルサーバでの統計情報収集では無く、ネットワーク側のネットワーク品質監視装置によるシグナリングプロトコル品質情報の収集が可能となる。
【００２５】
また、シグナリングプロトコルサーバが障害により停止した状態の期間でも、停止前後も含め該当シグナリングプロトコルサーバへのトラヒック状況などの品質情報を収集することが可能となる。
【００２６】
また、品質情報を収集する上でシグナリングプロトコルサーバへの処理負担が全くないため、シグナリングプロトコルサーバの処理性能に影響を与えること無く、ネットワーク品質状況を把握することが可能となる。
【００２７】
監視対象のシグナリングプロトコルサーバが処理するシグナリングプロトコルセッションのトラヒック量と同一のトラヒック量をネットワーク側で収集することが可能となり、適正なネットワーク運用管理を行うことが可能となる。
【００２８】
ネットワーク管理者は監視対象サーバの入側のシグナリングプロトコルセッションの制
御品質状況、出側のシグナリングプロトコルセッションの制御品質状況、入側、出側トータルでのシグナリングプロトコルセッション品質状況を、それぞれ把握することが可能となる。
【００２９】
また、通信のセッションを確立するためのシグナリングプロトコルパケットを解析するのみでネットワークの品質監視が可能となり、通話中に移行後のセッションは監視する必要がない。これにより、迅速な品質監視が可能となる。
【発明を実施するための最良の形態】
【００３０】
以下、図面を参照しながら、最良の実施形態（以下、「本実施形態」と呼ぶ）について詳細に説明する。
図１は、本実施形態が適用されるネットワークの全体構成図である。このネットワークは、ＮＧＮネットワークとして実現されている。ＮＧＮとは、固定電話のように安心で高い信頼性を持ち、なおかつＩＰ網の自由度を目指した、ＩＰ技術をベースにした次世代ネットワーク（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）をいう。ＩＴＵ−Ｔで国際標準化が進んでいる。ＮＧＮでは、従来の固定電話や携帯電話のサービスに加え、高品質な映像配信、テレビ電話、企業向けの高信頼性通信サービスなどを同一のＩＰ網上で提供できる。
【００３１】
ＮＧＮを実現するＩＰ網１０２は、移動網１０３や他網１０４などのＩＰプロトコル以外の他プロトコルによって運用されるネットワークと相互接続される。
本実施形態は、ＩＰ網１０２内で品質監視装置１０１として実現される。この品質監視装置１０１は、以下に説明する１０２−１〜１０２−６として示される各ノードを監視し、ＳＩＰの収集・解析を行う。これらのノードは、ＳＩＰの制御を実施する。
【００３２】
図１において、Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）１０２−１は、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、端末からのＳＩＰメッセージを次に説明するＩ−ＣＳＣＦ、Ｓ−ＣＳＣＦに転送する機能などを提供する。
【００３３】
Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）１０２−２も、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、ＩＰ網において通信を実現するための呼制御機能を提供する。ＳＩＰアプリケーションサーバとの連携も行う。
【００３４】
Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ  Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）１０２−３も、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、端末をネットワークに登録する際に複数存在するＳ−ＣＳＣＦの中で適切なものを選択する機能、及び他網に対して自網のネットワーク構成を保護するセキュリティ機能などを提供する。
【００３５】
ＣＳ−ＡＳ（Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）１０２−４も、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、３Ｇ移動網に対する回線交換サービスを提供するアプリケーションサーバである。
【００３６】
ＭＧＣＦ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）１０２−５も、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、既存の電話網と相互接続する際に必要となる。次に説明するＳＧＷ１０２−７を制御する機能を提供する。
【００３７】
ＳＧＷ（Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ）１０２−７は、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、異種ネットワーク間の接続機能を提供する。例えば、ＳＧＷは、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）網に対する音声ＣＯＤＥＣ（Ｃｏｄｅｒ／Ｄｅｃｏｄｅｒ）変換及びプロトコル変換を行う。また例えば、ＳＧＷは、ＴＤＭ（Ｔｉｍｅ  Ｄｏｍａｉｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）回線を収容する。また例えば、ＳＧＷは、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ）回線の収容及びプロトコル変換を行う。更に例えば、ＳＧＷは、ＩＰ回線の収容及びプロトコル変換を行う。
【００３８】
ＧＷ（ＧａｔｅＷａｙ）１０２−６も、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、ＩＰ網側に配置され、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）網と移動網との中継機能を提供する。
【００３９】
ＳＷ−ＨＵＢ（ＳＷｉｔｃｈｉｎｇ  ＨＵＢ）１０２−８も、ＩＰ網１０２によって実現されるＮＧＮの構成要素として推奨される装置の１つである。この装置は、ＩＰ網内の上述の各装置同士や端末を接続する。
【００４０】
ＢＴＳ（Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｔａｔｉｏｎ）１０３−１は、移動網１０３の構成要素の１つの装置である。この装置は、ネットワーク側の有線回線からのデータを無線インタフェースに合うデータフォーマットに変換して自セル内にある移動端末１０３−３に無線周波数で搬送する。また逆に、ＢＴＳは、無線周波数で搬送される移動端末１０３−３からのデータを受信して有線インタフェースに合うデータフォーマットに変換し、ネットワーク側に搬送することです。
【００４１】
ＢＳＣ（Ｂａｓｅ  Ｓｔａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）１０３−２も、移動網１０３の構成要素の１つの装置である。この装置は、ＢＴＳとと既存ネットワークとの中継機能を担当する。
【００４２】
例えば、移動網１０３内から発信したの移動端末１０３−３がＩＰ網１０２を経由し、他網１０４と通信を行う場合を示している。移動網１０３とＩＰ網１０２を接続するＧＷ１０２−６が、移動網１０３のシグナリングをＳＩＰシグナリングに変換し、ＩＰ網１０２内でのシグナリングを行う。ＩＰ網１０２内では、ＧＷ１０２−６、Ｐ−ＣＳＣＦ１０２−１、Ｓ−ＣＳＣＦ１０２−２、Ｉ−ＣＳＣＦ１０２−３、ＣＳ−ＡＳ１０２−４、ＭＧＣＦ１０２−５等の各ノードのＳＩＰサーバが、ＳＩＰシグナリングを制御し接続を実施する。
【００４３】
図２は、図１に示される本実施形態による品質監視装置１０１の構成図である。この装置は、図１において１０２−１〜１０２−６として示される各ＳＩＰサーバが収容するＩＰ回線部分に、プローブ装置として接続される。
【００４４】
図２において、パケット受信部２０１は、図１のＳＷ−ＨＵＢ１０２−８のミラーポートなどに接続され、監視対象となるＳＩＰサーバに対して入力又は出力するＩＰパケットを受信し、ＳＩＰパケット抽出部２０２へ送信する。
【００４５】
ＳＩＰパケット抽出部２０２は、パケット受信部２０１から受信したパケットのうち、ＳＩＰパケットのみを抽出し、抽出したＳＩＰパケットをＳＩＰパケット解析部２０３へ送信する。ＳＩＰパケットか否かの判断は、パケットのトランスポート層のヘッダ部を参照し、宛先（ｄｅｓｔｉｎａｔｉｏｎ）ポート番号がＳＩＰ用ポート番号か否かを判断することで実現する。判断に使用するＳＩＰ用ポート番号は、ＳＩＰのｗｅｌｌ  ｋｎｏｗ
ｎポートである５０６０や５０６１に加え、ネットワークポリシーで決定されたポート番号を予めコンフィグ等により設定しておくことも可能である。
ＳＩＰパケット解析部２０３は、ＳＩＰパケット抽出部２０２から抽出されたＳＩＰパケットを受信し、ＳＩＰ信号の解析を行うと共に、ＳＩＰセッションの状態管理を行う。
【００４６】
図３及び図４は、ＳＩＰメッセージの例を示す図であり、図３は、セッションを開始させるためのＳＩＰリクエストであるＩＮＶＩＴＥメソッドの例である。また、図４は、ＩＮＶＩＴＥメソッドに対するＳＩＰレスポンスの例である。ＳＩＰメッセージは、電子メールデータと良く似た構成を有し、図３又は図４に示されるように、ＳＩＰヘッダ３０１又は４０１と本文３０２又は４０２とから構成される。ＳＩＰパケット解析部２０３は、これらのＳＩＰメッセージのＳＩＰヘッダ３０１又は４０１を解析する。
【００４７】
セッション状態や品質分析に有効なセッション情報は、セッション管理テーブル記憶部２０５に記憶されるセッション管理テーブルに保持する。セッション管理テーブルは、セッション毎に１エントリずつが割り当てられる。セッションの特定には、Ｃａｌｌ−ＩＤなどのセッションで一意な情報が使用される。セッション管理テーブルでは、監視対象ＳＩＰサーバへの入側パケットか出側パケットかが識別され、入側、出側のセッション状態を制御し、また、セッション情報を保持する。
【００４８】
ＳＩＰ品質分析部２０４は、ＳＩＰパケット解析部２０３によりＳＩＰセッション状態及びセッション情報が保持されたセッション管理テーブルを参照し、情報を分析する。これにより、ＳＩＰ品質分析部２０４は、セッションの完了、不完了（準正常、異常）の特定、発信者がセッション呼出し中状態（１８０Ｒｉｎｇｉｎｇ受信）を把握するまでの接続時間の特定、ＳＩＰサーバで呼接続信号の処理に要している時間の特定などを行う。そして、ＳＩＰ品質分析部２０４は、分析対象となる複数セッションの全てを分析し、統計情報として集計する。また、ＳＩＰ品質分析部２０４は、予め品質劣化と判断する統計データの閾値を定義しておくことにより、閾値オーバーであれば品質劣化としてアラームをネットワーク管理者に通知するという判断も行う。
【００４９】
統計情報通知部２０６は、ＳＩＰ品質分析部２０４にて収集された統計情報を、ネットワーク管理者に提供する。また、統計情報通知部２０６は、アラームをネットワーク管理者に通知する。
セッション管理テーブル記憶部２０５は、セッション管理テーブルを記憶する。
【００５０】
図５は、１つのセッション管理テーブルに記憶される情報を示すデータ構成図である。
セッション管理テーブルは、セッション状態（呼設定中、呼出し中、通信中など）及びセッション情報を管理するテーブルである。
【００５１】
セッション管理テーブルは、セッション共通情報として、セッション管理完了フラグ及びＳＩＰヘッダ情報を保有する。ＳＩＰヘッダ情報は、Ｃａｌｌ−ＩＤ、ＳＩＰ−ＵＲＩ形式による発信者情報（Ｆｒｏｍ）、ＳＩＰ−ＵＲＩ形式による着信者情報（Ｔｏ）を含む。
【００５２】
また、セッション管理テーブルは、監視対象ＳＩＰサーバの出側、入側の各々につき、宛先ＩＰアドレス、送信元ＩＰアドレス、セッション状態、最終レスポンスコード、完了／不完了表示、各ＳＩＰメッセージの受信時刻（複数可能）を保持する。
【００５３】
図６は、本実施形態の動作概要の説明図である。図６（ａ）及び（ｂ）において、品質監視装置１０１、ＩＰ網１０２、他網１０４、及びＳＷ−ＨＵＢ１０２−８はそれぞれ、図１に示されるものと同じである。また、ＳＩＰサーバ６０１は、図１の１０２−１〜１
０２−４の各ＳＩＰサーバに対応する。ＳＩＰ−ＧＷ（ゲートウェイ）６０３は、図１の１０２−５又は１０２−６のＳＩＰゲートウェイ装置に対応する。
【００５４】
まず、図６（ａ）に示されるように、本実施形態では、ＳＩＰサーバ６０１で品質監視が行われるのではなく、ＩＰ網１０２内の監視対象のＳＩＰサーバ６０１が接続されるＳＷ−ＨＵＢ１０２−８のミラーポート等に、品質監視装置１０１が配置される。そして品質監視装置１０１が、監視対象のＳＩＰサーバ６０１の入出力パケットをキャプチャ及び品質分析する。これにより、ＳＩＰサーバ６０１の障害状況に影響されることなく、またＳＩＰサーバ６０１の処理性能に影響を与えることなく、監視対象のＳＩＰサーバ６０１のＳＩＰ制御品質を把握することを可能としている。
【００５５】
図１に示されるＮＧＮなどのＩＰ網１０２において利用されるＳＩＰセッションは、ＳＩＰサーバ６０１を介してセッション接続を実現している。そして、１つのＳＩＰセッションを確立するために、ＳＩＰサーバ６０１は、ＳＩＰ信号のプロキシを実施している。
【００５６】
ＩＰ網１０２に配置される品質監視装置１０１は、監視対象のＳＩＰサーバ６０１の入側を流れるパケットと出側を流れるパケットの両方をキャプチャする。そして、品質監視装置１０１は、１つのＳＩＰセッションを一意に特定するＣａｌｌ−ＩＤなどの情報に基づいて、ＳＩＰサーバ６０１の入側と出側を流れるセッション接続用のパケットを全て紐付けし、入側及び出側のそれぞれでセッション状態を管理する。図６（ｃ）に示されるように、品質監視装置１０１は、セッション状態の管理を、図５に示されるデータを含むセッション管理テーブルによって行う。セッション管理テーブルは、図２のセッション管理テーブル記憶部２０５に記憶される。
【００５７】
品質監視装置１０１では、入側、出側のそれぞれで、セッション接続が完了か不完了かの判断が可能となる。これと共に、品質監視装置１０１では、入側、出側のセッション接続結果を総合的に判断し、監視対象のＳＩＰサーバ６０１が制御する１つのＳＩＰセッションを単位として、セッション接続が完了か不完了かの判断も可能となる。
【００５８】
そして、品質監視装置１０１では、上述の判断が監視対象のＳＩＰサーバ６０１に対して入出力する全てのセッションに対して実施され、その実施結果が統計情報としてネットワーク管理者に提供される。
【００５９】
また、品質監視装置１０１では、セッション状態管理がＳＩＰサーバ６０１の入側と出側の各々で実施される。これにより、セッション接続の不完了時には、監視対象のＳＩＰサーバ６０１が原因で不完了となったのか、監視対象のＳＩＰサーバ６０１の後位のＳＩＰサーバ６０２が原因で不完了となったのかの判断が可能となる。そして、各サーバの品質データが追跡されることで、障害サーバや障害ネットワークが特定可能とされる。
【００６０】
次に、図６（ｂ）において、ＳＩＰ−ＧＷ（ゲートウェイ）６０３は、他のプロトコルで運用される他網１０４をＩＰ網１０２と接続する。この場合も、ＳＩＰ−ＧＷ６０３で品質監視が行われるのではなく、ＩＰ網１０２内の監視対象のＳＩＰ−ＧＷ６０３が接続されるＳＷ−ＨＵＢ１０２−８のミラーポート等に、品質監視装置１０１が配置される。
【００６１】
ＩＰ網１０２から他網１０４に向けてＳＩＰメッセージが転送される方向では、品質監視装置１０１は、監視対象のＳＩＰ−ＧＷ６０３の入側のみを監視する。ＳＩＰ−ＧＷ６０３の出側にはＳＩＰメッセージは送出されないためである。一方、他網１０４からＩＰ網１０２に向けてＳＩＰメッセージが転送される方向では、品質監視装置１０１は、監視対象のＳＩＰ−ＧＷ６０３の出側のみを監視する。ＳＩＰ−ＧＷ６０３の入側にはＳＩＰメッセージは流入しないためである。
【００６２】
この場合、品質監視装置１０１は、主にＳＩＰメッセージが順次転送されるときの接続時間を収集して監視する。
次に、本実施形態において、監視対象のＳＩＰサーバの入側、出側のＳＩＰリクエスト及びＳＩＰレスポンスのパケットを識別する動作の詳細について説明する。
【００６３】
図７は、一般的なＳＩＰプロキシの動作シーケンス例を示す図、図８は、その動作説明図である。図８において、品質監視装置１０１、ＩＰ網１０２、及びＳＷ−ＨＵＢ１０２−８はそれぞれ、図１に示されるものと同じである。また、ＳＩＰサーバ８０１〜８０３は、図１の１０２−１〜１０２−４の各ＳＩＰサーバに対応する。
【００６４】
まず、前位のＳＩＰサーバ８０２から監視対象のＳＩＰサーバ８０１に対して、ＩＮＶＩＴＥリクエストのＳＩＰメッセージが発行され、セッションの確立が要求される（図７のＳ１）。なお、前位のＳＩＰサーバ８０２は、発信端末であってもよい。
【００６５】
ＩＮＶＩＴＥリクエストを受け取った監視対象のＳＩＰサーバ８０１は、現在リクエストを転送中であることを示すＳＩＰメッセージである１００  Ｔｒｙｉｎｇレスポンスを前位のＳＩＰサーバ８０２に返信する（図７のＳ２）。
【００６６】
これに続いて、監視対象のＳＩＰサーバ８０１は、後位のＳＩＰサーバ８０３に、ＩＮＶＩＴＥリクエストを転送する（図７のＳ３）。なお、後位のＳＩＰサーバ８０３は、着信端末であってもよい。
【００６７】
ＩＮＶＩＴＥリクエストを受け取った後位のＳＩＰサーバ８０３は、もし通信先のＳＩＰサーバ又は端末が存在する場合には更にＩＮＶＩＴＥリクエストの転送を試みる。このとき、後位のＳＩＰサーバ８０３から監視対象のＳＩＰサーバ８０１にも同様に、１００
Ｔｒｙｉｎｇレスポンスが返信される（図７のＳ４）。
【００６８】
最終的に端末を呼び出したＳＩＰサーバはその手前のＳＩＰサーバに呼出し中であることを示すＳＩＰメッセージである１８０  Ｒｉｎｇｉｎｇレスポンスを返す。そのレスポンスが転送されてきた結果、後位のＳＩＰサーバ８０３から監視対象のＳＩＰサーバ８０１に１８０  Ｒｉｎｇｉｎｇレスポンスが返信される（図７のＳ５）。監視対象のＳＩＰサーバ８０１は、この１８０  Ｒｉｎｇｉｎｇレスポンスを、前位のＳＩＰサーバ８０２に転送する（図７のＳ６）。
【００６９】
着信側の端末が呼出しに応じると、ＳＩＰメッセージとして２００  ＯＫレスポンスが返される。そのレスポンスが転送されてきた結果、後位のＳＩＰサーバ８０３から監視対象のＳＩＰサーバ８０１に２００  ＯＫレスポンスが返信される（図７のＳ７）。監視対象のＳＩＰサーバ８０１は、この２００  ＯＫレスポンスを、前位のＳＩＰサーバ８０２に転送する（図７のＳ８）。
【００７０】
上記２００  ＯＫレスポンスに対して、前位のＳＩＰサーバ８０２から監視対象のＳＩＰサーバ８０１に、応答を示すＳＩＰメッセージとしてＡＣＫメッセージが返信される（図７のＳ９）。同様に、監視対象のＳＩＰサーバ８０１から後位のＳＩＰサーバ８０３にも、ＡＣＫメッセージが返信される（図７のＳ１０）。
【００７１】
以上のシーケンスの後に、発信側の端末と着信側の端末は通信中の状態になる（図７のＳ１１）。
通信終了後は、例えば前位のＳＩＰサーバ８０２から監視対象のＳＩＰサーバ８０１に、終了を示すＳＩＰメッセージとしてＢＹＥメッセージが送信される（図７のＳ１２）。
監視対象のＳＩＰサーバ８０１は後位のＳＩＰサーバ８０３に、ＢＹＥメッセージを転送する（図７のＳ１３）。
【００７２】
これに対して、後位のＳＩＰサーバ８０３から監視対象のＳＩＰサーバ８０１に２００
ＯＫレスポンスが返され（図７のＳ１４）、監視対象のＳＩＰサーバ８０１から前位のＳＩＰサーバ８０２にも２００  ＯＫレスポンスが返される（図７のＳ１５）。
以上で通信が終了する。
【００７３】
上述したように、ＳＩＰ信号は、ＳＩＰリクエストに対するＳＩＰレスポンスの応答によって、１つのリクエストが終了となる。このため、図８（ａ）において、品質監視装置１０１は、ＳＩＰリクエスト及びＳＩＰレスポンスの各々をキャプチャし、それらに対して入側か出側かの判断を行う必要がある。図２のＳＩＰパケット解析部２０３は、図８（ｂ）に示す論理にてＳＩＰメッセージが入側のものか出側のものかの判断を行う。そして、ＳＩＰパケット解析部２０３は、ＩＮＶＩＴＥリクエストを受信した時に、それに対応するセッション用のセッション管理テーブルを割り当てる。図７に示されるような通常のＳＩＰプロキシシーケンスであれば、入側でＩＮＶＩＴＥリクエストを受信した時（図７のＳ１の場合）にセッション管理テーブルが割り当てられる。そして、出側でＩＮＶＩＴＥリクエストを受信した時（図７のＳ３の場合）には、既に割り当てられたセッション管理テーブルが利用される。
【００７４】
監視対象のＳＩＰサーバ８０１のＩＰアドレス＝（ｂ）は、予め品質監視装置１０１にて把握されている。そして、複数のＩＰアドレスを監視対象のＳＩＰサーバ８０１として認識することも可能である。
【００７５】
図７に例示されるＳＩＰプロキシの動作シーケンスの過程で、ＳＩＰパケット解析部２０３は、ＳＩＰパケットの受信時に、入側、出側の各々につき、図２のセッション管理テーブル記憶部２０５に、図５に示されるセッション管理テーブルを保持する。そして、ＳＩＰパケット解析部２０３は、ＳＩＰパケットの受信状況に応じて、セッション管理テーブルを制御しながら、図９の状態遷移で示されるセッション状態の管理を実行する。即ち、ＳＩＰパケット解析部２０３は、ＳＩＰメッセージを受信する毎に、状態Ｓ９０１〜Ｓ９１１までの間で、現在の状態を遷移させる。
【００７６】
この詳細な状態遷移動作については後述するが、入側、出側のセッション状態が品質分析対象の状態となった場合には、図５に示されるセッション管理テーブルの「セッション管理完了フラグ」を「ＯＮ」にする。図９の灰色で塗りつぶされた状態Ｓ９０５、Ｓ９０６、Ｓ９０７、Ｓ９０９、Ｓ９１１が、品質分析対象の状態である。
【００７７】
図２のＳＩＰ品質分析部２０４は、セッション管理テーブル記憶部２０５に記憶されているセッション管理テーブル群のうち、セッション管理完了フラグが「ＯＮ」になっているセッションについて、品質情報を収集する。品質情報は、入側、出側のセッションの完了、不完了や接続時間、監視対象のＳＩＰサーバ８０１（図８）での信号処理時間などである。そして、ＳＩＰ品質分析部２０４は、一定周期内に品質分析対象となっている全てのセッションに関する品質情報を統計情報として集計し、統計情報通知部２０６を通じて、ネットワーク管理者の保守端末（図１では特には図示しない）に通知する。
【００７８】
入側、出側のセッションの完了、不完了については、入側と出側の各々において個別に決定されるが、入側と出側を合わせて１つのＳＩＰセッションとして完了、不完了を決定させることも考えられる。その場合には、入側、出側のそれぞれの情報に基づいて完了、不完了を判断する必要がある。例えば、入側、出側共に完了状態であれば、ＳＩＰセッションとしても完了とされ、入側、出側共に不完了であれば不完了とされる。但し、入側が不完了で出側が完了となるケースや、入側、出側共に不完了だが不完了要因が異なることも考えられる。そのような場合には、予め品質監視装置１０１が配置されるＩＰ網１０２のポリシーに従って、完了、不完了が決定することが望ましい。例えば、入側、出側のどちらかで不完了であれば、１つのＳＩＰセッションとしても不完了としたり、不完了要因が異なる場合には不完了要因に重み付けをしておき、重要視すべき要因を採用するなどが考えられる。
【００７９】
図１０〜図２２は、ＳＩＰパケット解析部２０３が、図９の状態遷移で示されるセッション状態の管理を実行する場合の動作を示す動作フローチャートである。以下、これらの動作フローチャートで示される動作について、順次説明する。
【００８０】
まず、図１０の動作フローチャートについて説明する。
まず、ＳＩＰパケット解析部２０３は、空き状態（図９のＳ９０１）において、受信パケットの内容を解析する（ステップＳ１００１）。ここで、「空き」状態とは、ＳＩＰパケット解析部２０３が、対象となるＳＩＰセッションについて呼制御を行っていない状態をいう。
【００８１】
次に、ＳＩＰパケット解析部２０３は、受信パケットがＳＩＰパケットであるか否かを判定する（ステップＳ１００２）。
ステップＳ１００２にて受信パケットがＳＩＰパケットでないと判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１００１の処理に戻り、次の受信パケットの内容を解析する。
【００８２】
ステップＳ１００２にて受信パケットがＳＩＰパケットであると判定したならば、ＳＩＰパケット解析部２０３は、受信パケットからＳＩＰメッセージを抽出し、そのフォーマットをチェックする（ステップＳ１００３）。ＳＩＰメッセージは、図４又は図５に例示されるようなフォーマットを有している。ステップＳ１００３では、ＳＩＰメッセージが成立するために必要な条件がチェックされる。
【００８３】
そして、ステップＳ１００４の判定において、チェック結果がエラーならば、ＳＩＰパケット解析部２０３は、ステップＳ１００１の処理に戻り、次の受信パケットの内容を解析する。
【００８４】
ステップＳ１００４の判定において、チェック結果がＯＫならば、ＳＩＰパケット解析部２０３は、セッション管理テーブルを特定するためのハッシュ値を生成する（ステップＳ１００５）。具体的には、ＳＩＰパケット解析部２０３は、受信されたＳＩＰメッセージのＳＩＰヘッダ内のセッション特定情報であるＣａｌｌ−ＩＤ（図３、図４参照）に対応するハッシュ値を演算する。
【００８５】
次に、ＳＩＰパケット解析部２０３は、そのハッシュ値より、セッション管理テーブル記憶部２０５に記憶されているセッション管理テーブルを特定する。もしセッション管理テーブルが無ければ、ＳＩＰパケット解析部２０３は、新たなセッション管理テーブルを割り当てる（以上、ステップＳ１００６）。ハッシュ値を用いることにより、図２３に示されるように、各セッションのセッション管理テーブルを一意に特定することでき、なおかつ同じセッションについては常に同じセッション管理テーブルを特定することができる。
【００８６】
次に、ＳＩＰパケット解析部２０３は、上記特定されたセッション管理テーブルに、受信されたＳＩＰメッセージのＳＩＰヘッダの情報を設定する（ステップＳ１００７）。具体的には、ＳＩＰパケット解析部２０３は、例えば図３に示されるＳＩＰヘッダ３０１内
のセッション特定情報であるＣａｌｌ−ＩＤ、発信者情報（Ｆｒｏｍ）、及び着信者情報（Ｔｏ）を、図５に示されるＳＩＰヘッダ情報の対応するフィールドに設定する。
【００８７】
次に、ＳＩＰパケット解析部２０３は、受信されたＳＩＰメッセージが、監視対象のＳＩＰサーバ８０１（図８（ａ）参照）の入側のメッセージなのか出側のメッセージなのかを判断する（ステップＳ１００８）。
ここでは、図８（ｂ）に示される決定規則が用いられる。
【００８８】
即ち、ＳＩＰメッセージが、発信者から着信者に向かうＳＩＰリクエストで、ＳＩＰヘッダ内の宛先ＩＰアドレス（図５参照）が監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の入側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、前位のＳＩＰサーバ８０２から監視対象のＳＩＰサーバ８０１に向けて転送されてきたＳＩＰリクエストである。ＳＩＰリクエストが、発信者から着信者に向かうものであるかその逆であるかは、ＳＩＰヘッダ内の情報から判定できる。
【００８９】
ＳＩＰメッセージが、発信者から着信者に向かうＳＩＰリクエストで、ＳＩＰヘッダ内の送信元ＩＰアドレス（図５参照）が監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の出側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、監視対象のＳＩＰサーバ８０１から後位のＳＩＰサーバ８０３に向けて転送送信されたＳＩＰリクエストである。
【００９０】
ＳＩＰメッセージが、着信者から発信者に向かうＳＩＰレスポンスで、ＳＩＰヘッダ内の宛先ＩＰアドレスが監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の出側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、後位のＳＩＰサーバ８０３から監視対象のＳＩＰサーバ８０１に向けて転送されてきたＳＩＰレスポンスである。
【００９１】
ＳＩＰメッセージが、着信者から発信者に向かうＳＩＰレスポンスで、ＳＩＰヘッダ内の送信元ＩＰアドレスが監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の入側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、監視対象のＳＩＰサーバ８０１から前位のＳＩＰサーバ８０２に向けて転送送信されたＳＩＰレスポンスである。
【００９２】
ＳＩＰメッセージが、着信者から発信者に向かうＳＩＰリクエストで、ＳＩＰヘッダ内の宛先ＩＰアドレスが監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の出側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、後位のＳＩＰサーバ８０３から監視対象のＳＩＰサーバ８０１に向けて転送されてきたＳＩＰリクエストである。
【００９３】
ＳＩＰメッセージが、着信者から発信者に向かうＳＩＰリクエストで、ＳＩＰヘッダ内の送信元ＩＰアドレスが監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の入側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、監視対象のＳＩＰサーバ８０１から前位のＳＩＰサーバ８０２に向けて転送送信されたＳＩＰリクエストである。
【００９４】
ＳＩＰメッセージが、発信者から着信者に向かうＳＩＰレスポンスで、ＳＩＰヘッダ内の宛先ＩＰアドレスが監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の入側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、前位のＳＩＰサーバ８０２から監視対象のＳＩＰサーバ８０１に向けて転送されてきたＳＩＰレスポンスである。
【００９５】
ＳＩＰメッセージが、発信者から着信者に向かうＳＩＰレスポンスで、ＳＩＰヘッダ内の送信元ＩＰアドレスが監視対象のＳＩＰサーバ８０１になっていれば、監視対象のＳＩＰサーバ８０１の出側を流れるＳＩＰメッセージと判定される。つまり、そのＳＩＰメッセージは、監視対象のＳＩＰサーバ８０１から後位のＳＩＰサーバ８０３に向けて転送送信されたＳＩＰレスポンスである。
【００９６】
ＳＩＰパケット解析部２０３は、受信ＳＩＰメッセージが監視対象のＳＩＰサーバ８０１の入側を流れるものと判断したときには、これ以後ステップＳ１００６にて特定されたセッション管理テーブルにアクセスするときに、入側情報の領域にアクセスする。逆に、ＳＩＰパケット解析部２０３は、受信ＳＩＰメッセージが監視対象のＳＩＰサーバ８０１の出側を流れるものと判断したときには、これ以後ステップＳ１００６にて特定されたセッション管理テーブルにアクセスするときに、出側情報の領域にアクセスする。以後の説明で、「対象セッション管理テーブル」と記述した場合は、ステップＳ１００６で特定されたセッション管理テーブル内の入側情報又は出側情報の領域のうち、ステップＳ１００８で判定された入側又は出側に対応するほうの領域を示すものとする。なお、セッション管理テーブルは、図２のセッション管理テーブル記憶部２０５に記憶されている。
【００９７】
次に、ＳＩＰパケット解析部２０３は、受信されたＳＩＰメッセージがどの種別（メソッド）であるかを判定する（ステップＳ１００９）。この判定は、ＳＩＰメッセージのＳＩＰヘッダ内の先頭に記載されているメッセージ記述を判断することにより実現できる。
【００９８】
そして、ＳＩＰパケット解析部２０３は、上述の判定結果に応じた受信メッセージ毎の処理を実行する（ステップＳ１０１０）。この処理は、図１１〜図１９のうちの何れかの動作フローチャートで示される。
【００９９】
図１０のステップＳ１００９にて、受信メッセージがＩＮＶＩＴＥリクエストであると判定した場合には、ＳＩＰパケット解析部２０３は、図１１の動作フローチャートの処理を実行する。以下、図１１の動作フローチャートによる動作について説明する。
【０１００】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１１０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１０１】
ステップＳ１１０１での判定の結果、現在の遷移状態が「空き」状態（図９のＳ９０１）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１１０２〜Ｓ１１０７の処理を実行する。
【０１０２】
即ち、ＳＩＰパケット解析部２０３は、ＩＮＶＩＴＥリクエストが受信された時刻を、対象セッション管理テーブル内の「ＩＮＶＩＴＥ受信時刻」フィールド（図５参照）に保持する（ステップＳ１１０２）。
【０１０３】
次に、ＳＩＰパケット解析部２０３は、ＩＮＶＩＴＥリクエストが格納されていたＩＰパケットのヘッダ内の送信元ＩＰアドレスを、対象セッション管理テーブル内の「送信元ＩＰアドレス」フィールド（図５参照）に保持する（ステップＳ１１０３）。
【０１０４】
次に、ＳＩＰパケット解析部２０３は、ＩＮＶＩＴＥリクエストが格納されていたＩＰパケットのヘッダ内の宛先ＩＰアドレスを、対象セッション管理テーブル内の「宛先ＩＰアドレス」フィールド（図５参照）に保持する（ステップＳ１１０４）。
【０１０５】
次に、ＳＩＰパケット解析部２０３は、「呼設定中」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１１０５）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「空き」状態（図９のＳ９０１）から「呼設定中」状態（図９のＳ９０２）に遷移する。
【０１０６】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に対応させてレスポンスタイマを設定し、スタートさせる（ステップＳ１１０６）。レスポンスタイマは、該当するＳＩＰセッションの入側又は出側の経路に関して、何らかのレスポンスを監視するタイマである。例えば、ＩＮＶＩＴＥリクエストに対してレスポンスが返らない場合に、このレスポンスタイマが満了することにより、そのＳＩＰセッション（入側又は出側）は不完了であるとして、セッション管理テーブルや各種タイマ等のリソースを解放することができる。レスポンスタイマが計時する時間長は、例えば４０秒程度である。このレスポンスタイマは、ＳＩＰパケット解析部２０３内で任意に生成し個別に動作させることができるものとする。レスポンスタイマが満了したときの処理は、後述する図１０のステップＳ１０１１での判定に基づいて図２０の動作フローチャートとして実行される。
【０１０７】
そして、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に対応させてＡｕｄｉｔタイマを設定し、スタートさせる（ステップＳ１１０７）。Ａｕｄｉｔタイマは、２００  ＯＫレスポンスなどの最終レスポンスが受信できない場合に、セッション管理のためのリソースが浪費されてしまうことを防ぐタイマである。このＡｕｄｉｔタイマが計時する時間長は、例えば５分程度の長い時間長となる。このＡｕｄｉｔタイマは、レスポンスタイマと同様に、ＳＩＰパケット解析部２０３内で任意に生成し個別に動作させることができるものとする。Ａｕｄｉｔタイマが満了したときの処理は、後述する図１０のステップＳ１０１１での判定に基づいて図２２の動作フローチャートとして実行される。
【０１０８】
その後、ＳＩＰパケット解析部２０３は、図１１の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
以上のステップＳ１１０２〜Ｓ１１０７の一連の処理の動作シーケンス例は、例えば図２５〜図２７の各Ｓ１のシーケンスや、図２５、図２６の各Ｓ３のシーケンスに対応する。
【０１０９】
前述したステップＳ１１０１での判定の結果、現在の遷移状態が「ＩＮＶＩＴＥリトライ待ち」状態（図９のＳ９０３）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１１０８〜Ｓ１１１２の処理を実行する。
【０１１０】
ここで、「ＩＮＶＩＴＥリトライ待ち」状態は、例えば図２４（ａ）の動作シーケンス図として例示される。即ち、例えばＳＩＰサーバが端末等からＩＮＶＩＴＥリクエストを受信（Ｓ１）した後に、ＳＩＰサーバ側から端末等に、認証要求を行う場合がある。この場合には、ＳＩＰサーバから端末等に「４０７  Ｐｒｏｘｙ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄ」という特殊なレスポンスが返される（Ｓ２）。これを受けて、端末からＳＩＰサーバに再度、ＩＮＶＩＴＥリクエストが送られる（Ｓ３）。上述の４０７レスポンスが受信されると、ＳＩＰパケット解析部２０３は、「呼設定中」状態（図９のＳ９０２）から「ＩＮＶＩＴＥリトライ待ち」状態（図９のＳ９０３）に遷移する。この遷移処理は、図１３の動作フローチャートの説明にて後述する。この状態において、更にＩＮＶＩＴＥリクエストが受信されると（図２４（ａ）のＳ３）、ＳＩＰパケット解析部２０３は、「ＩＮＶＩＴＥリトライ待ち」状態から再び「呼設定中」状態（図９のＳ９０２）に遷移状態を戻す。これを実現するのが、図１１のステップＳ１１０８〜Ｓ１１１２の一連の処理である。
【０１１１】
まず、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に関して設定されているＩＮＶＩＴＥリトライ待ちタイマを解除する（ステップＳ１１０８）。このタイマは、上述の４０７レスポンスの受信時に後述する図１３のステップＳ１３０５において設定されスタートされたものである。このタイマ解除により、「ＩＮＶＩＴＥリトライ待ち」状態において次のＩＮＶＩＴＥリクエストを待つための時間カウントが終了する。
【０１１２】
次に、ＳＩＰパケット解析部２０３は、ステップＳ１１０９〜Ｓ１１１２の一連の処理として、対象セッション管理テーブルへの送信元ＩＰアドレスと宛先ＩＰアドレスの保持及び「呼設定中」状態の設定、並びに、レスポンスタイマの設定及びスタートを行う。これらの処理は、前述したステップＳ１１０３〜Ｓ１１０６の一連の処理と同様である。
その後、ＳＩＰパケット解析部２０３は、図１１の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１１３】
前述したステップＳ１１０１での判定の結果、現在の遷移状態が「呼設定中」状態（図９のＳ９０２）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１１１３及びＳ１１１４の処理を実行する。この状態は、ＩＮＶＩＴＥリクエストが受信されて「呼設定中」状態になった後に更に、ＩＮＶＩＴＥリクエストが重ねて受信されたような場合である。
【０１１４】
この場合には、ＳＩＰパケット解析部２０３は、レスポンスタイマを一旦解除し（ステップＳ１１１３）、更にレスポンスタイマを設定し直す（ステップＳ１１１４）処理のみを実行して、図１１の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。この場合には、「呼設定中」状態（図９のＳ９０２）がそのまま維持される。
【０１１５】
前述のステップＳ１１０１での判定の結果、現在の遷移状態が「空き」状態でも「ＩＮＶＩＴＥリトライ待ち」状態でも「呼設定」状態でもないと判定したならば、ＳＩＰパケット解析部２０３は、ＩＮＶＩＴＥリクエストを無視して破棄する（ステップＳ１１１５）。
その後、ＳＩＰパケット解析部２０３は、図１１の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１１６】
次に、図１０のステップＳ１００９にて、受信メッセージが１００  Ｔｒｙｉｎｇレスポンスであると判定した場合には、ＳＩＰパケット解析部２０３は、図１２の動作フローチャートの処理を実行する。以下、図１２の動作フローチャートによる動作について説明する。
【０１１７】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１２０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１１８】
ステップＳ１２０１での判定の結果、現在の遷移状態が「呼設定中」状態（図９のＳ９０２）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１２０２の処理を実行する。この状態は、「呼設定中」状態において、ＩＮＶＩＴＥリクエストに対して１００  Ｔｒｙｉｎｇレスポンスが正常に受信された状態である。
【０１１９】
この場合には、ＳＩＰパケット解析部２０３は、レスポンスタイマを解除する処理（ス
テップＳ１２０２）のみを実行して、図１２の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。この場合には、「呼設定中」状態（図９のＳ９０２）がそのまま維持される。
この動作シーケンス例は、例えば図２５〜図２７の各Ｓ２のシーケンスや、図２５、図２６の各Ｓ４のシーケンスに対応する。
【０１２０】
前述のステップＳ１２０１での判定の結果、現在の遷移状態が「呼設定」状態でないと判定したならば、ＳＩＰパケット解析部２０３は、１００  Ｔｒｙｉｎｇレスポンスを無視して破棄する（ステップＳ１２０３）。
その後、ＳＩＰパケット解析部２０３は、図１２の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１２１】
次に、図１０のステップＳ１００９にて、受信メッセージが前述した４０７レスポンスであると判定した場合には、ＳＩＰパケット解析部２０３は、図１３の動作フローチャートの処理を実行する。以下、図１３の動作フローチャートによる動作について説明する。
【０１２２】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１３０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１２３】
ステップＳ１３０１での判定の結果、現在の遷移状態が「呼設定中」状態（図９のＳ９０２）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１３０２〜Ｓ１３０５の処理を実行する。ここでは、図２４（ａ）のＳ２として前述したように、「呼設定中」状態において、ＳＩＰサーバ側から端末等に認証要求を行うために更にＩＮＶＩＴＥリクエストを要求するための「ＩＮＶＩＴＥリトライ待ち」状態（図９のＳ９０３）に遷移するための状態遷移が行われる。
【０１２４】
まず、ＳＩＰパケット解析部２０３は、４０７レスポンスが受信された時刻を、対象セッション管理テーブル内の「２３４５６ｘｘ受信時刻」フィールド（図５参照）に保持する（ステップＳ１３０２）。
【０１２５】
次に、ＳＩＰパケット解析部２０３は、レスポンスタイマを解除する（ステップＳ１３０３）。
次に、ＳＩＰパケット解析部２０３は、「ＩＮＶＩＴＥリトライ待ち」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１３０４）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「呼設定中」状態（図９のＳ９０２）から「ＩＮＶＩＴＥリトライ待ち」状態（図９のＳ９０３）に遷移する。
【０１２６】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に対応させてＩＮＶＩＴＥリトライ待ちタイマを設定し、スタートさせる（ステップＳ１３０５）。このタイマは、該当するＳＩＰセッションの入側又は出側の経路に関して、４０７レスポンスの受信後更にＩＮＶＩＴＥリクエストの受信待ちを行うためのタイマである。
その後、ＳＩＰパケット解析部２０３は、図１３の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１２７】
前述のステップＳ１３０１での判定の結果、現在の遷移状態が「呼設定」状態でないと判定したならば、ＳＩＰパケット解析部２０３は、４０７レスポンスを無視して破棄する（ステップＳ１３０６）。
その後、ＳＩＰパケット解析部２０３は、図１３の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１２８】
次に、図１０のステップＳ１００９にて、受信メッセージが前述した１８ｘ（「ｘ」は任意の１桁の数字）であると判定した場合には、ＳＩＰパケット解析部２０３は、図１４の動作フローチャートの処理を実行する。以下、図１４の動作フローチャートによる動作について説明する。このメッセージは、呼出中状態であることを表示するメッセージである。
【０１２９】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１４０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１３０】
ステップＳ１４０１での判定の結果、現在の遷移状態が「呼設定中」状態（図９のＳ９０２）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１４０２〜Ｓ１４０４の処理を実行する。
【０１３１】
まず、ＳＩＰパケット解析部２０３は、１８ｘレスポンスが受信された時刻を、対象セッション管理テーブル内の「１８ｘ受信時刻」フィールド（図５参照）に保持する（ステップＳ１４０２）。
【０１３２】
次に、ＳＩＰパケット解析部２０３は、レスポンスタイマを解除する（ステップＳ１４０３）。
次に、ＳＩＰパケット解析部２０３は、「呼出中」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１４０４）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「呼設定中」状態（図９のＳ９０２）から「呼出中」状態（図９のＳ９０４）に遷移する。
【０１３３】
その後、ＳＩＰパケット解析部２０３は、図１３の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
以上のステップＳ１４０２〜Ｓ１４０４の一連の処理の動作シーケンス例は、例えば図２５のＳ５のシーケンス（１８０  Ｒｉｎｇｉｎｇレスポンス）に対応する。
【０１３４】
前述のステップＳ１４０１での判定の結果、現在の遷移状態が「呼設定」状態でないと判定したならば、ＳＩＰパケット解析部１８ｘレスポンスを無視して破棄する（ステップＳ１４０５）。
その後、ＳＩＰパケット解析部２０３は、図１３の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１３５】
次に、図１０のステップＳ１００９にて、受信メッセージが前述した２００  ＯＫレスポンスであると判定した場合には、ＳＩＰパケット解析部２０３は、図１５の動作フローチャートの処理を実行する。以下、図１５の動作フローチャートによる動作について説明する。このメッセージは、呼出中状態であることを表示するメッセージである。
【０１３６】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１５０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１３７】
ステップＳ１５０１での判定の結果、現在の遷移状態が「呼設定中」状態（図９のＳ９
０２）又は呼出中状態（図９のＳ９０４）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１５０２〜Ｓ１５０５の処理を実行する。
【０１３８】
まず、ＳＩＰパケット解析部２０３は、２００  ＯＫレスポンスが受信された時刻を、対象セッション管理テーブル内の「２３４５６ｘｘ受信時刻」フィールド（図５参照）に保持する（ステップＳ１５０２）。
【０１３９】
次に、ＳＩＰパケット解析部２０３は、レスポンスタイマを解除する（ステップＳ１５０３）。
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）に、完了を示す値「１」を保持する（ステップＳ１５０４）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側のセッション管理状態が完了状態になり、ＳＩＰ品質分析部２０４による品質分析が可能な状態になる。
【０１４０】
次に、ＳＩＰパケット解析部２０３は、「通話中」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１５０５）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「呼設定中」状態（図９のＳ９０２）又は「呼出中」状態（図９のＳ９０４）から「通話中」状態（図９のＳ９０５）に遷移する。
【０１４１】
その後、ＳＩＰパケット解析部２０３は、図１３の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
以上のステップＳ１５０２〜Ｓ１５０５の一連の処理の動作シーケンス例は、例えば図２５のＳ７及びＳ８のシーケンスに対応する。
【０１４２】
前述したステップＳ１５０１での判定の結果、現在の遷移状態が「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１５０６〜Ｓ１５１４の処理を実行する。
【０１４３】
今、発信者情報又は着信者情報とＩＰアドレスの対応関係を保持するＳＩＰサーバが存在する。このＳＩＰサーバに対して、新たな対応関係を登録したいときに、端末又は他のＳＩＰサーバから当該ＳＩＰサーバに向けて、ＲＥＧＩＳＴＥＲリクエストが発行される。このＲＥＧＩＳＴＥＲリクエストに対して、レジストラと呼ばれるＳＩＰサーバが上記対応関係の登録作業を行い、それが完了すると、ＲＥＧＩＳＴＥＲリクエストの送信元に２００  ＯＫレスポンスを返して処理を終了する。上記ＲＥＧＩＳＴＥＲリクエストが発行されたときには、後述する図１９の動作フローチャートによって、遷移状態が「ＲＥＧＩＳＴＥＲ受信」状態にされる。この状態において、２００  ＯＫレスポンスが返されたときの処理が、以下のステップＳ１５０６〜Ｓ１５１４の処理である。ここでは、対応するセッションをクローズするための処理が実行される。
【０１４４】
まず、ＳＩＰパケット解析部２０３は、２００  ＯＫレスポンスが受信された時刻を、対象セッション管理テーブル内の「２３４５６ｘｘ受信時刻」フィールド（図５参照）に保持する（ステップＳ１５０６）。
【０１４５】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路のうち両方、即ち、当該ＳＩＰセッション全体をクローズ可能であるか否かの判定を行う（ステップＳ１５０７）。この選択は、予めネットワーク運用者によって設定されている。ＳＩＰパケット解析部２０３は、その設定内容を参照して上記判定を行う。
【０１４６】
ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ可能であると判定したときは、対象となるＳＩＰセッションに対応する全てのタイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＲＥＧＩＳＴＥＲリトライ待ちタイマ）を解除する（ステップＳ１５０８→Ｓ１５０９）。
【０１４７】
一方、ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ不可であると判定したときは、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側のうちの処理側のみに対応する全タイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＲＥＧＩＳＴＥＲリトライ待ちタイマ）を解除する（ステップＳ１５０８→Ｓ１５１０）。
【０１４８】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）に、完了を示す値「１」を保持する（ステップＳ１５１１）。また、ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ可能であると判定したときは、対象セッション管理テーブル内のセッション管理完了フラグを「ＯＮ」に設定する（ステップＳ１５１３→Ｓ１５１４）。これらの処理により、対象セッション管理テーブルで示されるＳＩＰセッション全体（ＳＩＰセッション全体をクローズ可能な場合）又はＳＩＰセッションの入側又は出側のうちの処理側（クローズ不可の場合）のセッション管理状態が完了状態になる。これにより、ＳＩＰ品質分析部２０４による品質分析が可能な状態になる。以上により、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）から「ＲＥＧＩＳＴＥＲ終了」状態（図９のＳ９０９）に遷移する。
【０１４９】
その後、ＳＩＰパケット解析部２０３は、図１５の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
前述のステップＳ１５０１での判定の結果、現在の遷移状態が「呼設定」状態でも「呼呼出中」状態でも「ＲＥＧＩＳＴＥＲ受信」状態でもないと判定したならば、ＳＩＰパケット解析部は、２００  ＯＫレスポンスを無視して破棄する（ステップＳ１５１５）。
その後、ＳＩＰパケット解析部２０３は、図１５の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１５０】
次に、図１０のステップＳ１００９にて、受信メッセージが解析対象外のメッセージであると判定した場合には、ＳＩＰパケット解析部２０３は、図１６の動作フローチャートの処理を実行する。
即ち、ＳＩＰパケット解析部２０３は、受信したメッセージを破棄し（ステップＳ１６０１）、図１６の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１５１】
次に、図１０のステップＳ１００９にて、受信メッセージが前述した３ｘｘ、４ｘｘ（４０１及び４０７以外）、５ｘｘ、又は６ｘｘのレスポンスであると判定した場合には、ＳＩＰパケット解析部２０３は、図１７の動作フローチャートの処理を実行する。以下、図１７の動作フローチャートによる動作について説明する。これらのレスポンスは、何らかのエラーを表示するＳＩＰレスポンスであり、セッション状態を不完了とすべき状態である。なお、４０７レスポンス受信時の処理は、図１３の動作フローチャートの説明にて前述した。また、４０１レスポンス受信時の処理は、図１８の動作フローチャートの説明において後述する。
【０１５２】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を
判定する（ステップＳ１７０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１５３】
前述したステップＳ１７０１での判定の結果、現在の遷移状態が「呼設定中」状態（図９のＳ９０２）又は呼出中状態（図９のＳ９０４）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１７０２〜Ｓ１７１１の処理を実行する。
【０１５４】
まず、ＳＩＰパケット解析部２０３は、レスポンスが受信された時刻を、対象セッション管理テーブル内の「２３４５６ｘｘ受信時刻」フィールド（図５参照）に保持する（ステップＳ１７０２）。
【０１５５】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路のうち両方、即ち、当該ＳＩＰセッション全体をクローズ可能であるか否かの判定を行う（ステップＳ１７０３）。この判定は、図１５のステップＳ１５０７の場合と同様である。
【０１５６】
ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ可能であると判定したときは、対象となるＳＩＰセッションに対応する全てのタイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＩＮＶＩＴＥリトライ待ちタイマ）を解除する（ステップＳ１７０４→Ｓ１７０５）。
【０１５７】
一方、ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ不可であると判定したときは、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側のうちの処理側のみに対応する全タイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＩＮＶＩＴＥリトライ待ちタイマ）を解除する（ステップＳ１７０４→Ｓ１７０６）。
【０１５８】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）に、不完了を示す値「０」を保持する（ステップＳ１７０７）。
【０１５９】
次に、ＳＩＰパケット解析部２０３は、受信したレスポンスに対応するコードを、最終レスポンスコードとして、対象セッション管理テーブル内の「最終レスポンスコード」フィールドに保持する（ステップＳ１７０８）。
【０１６０】
次に、ＳＩＰパケット解析部２０３は、「セッション終了」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１７０９）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「呼設定中」状態（図９のＳ９０２）又は「呼出中」状態（図９のＳ９０４）から「セッション終了」状態（図９のＳ９０７）に遷移する。このセッション終了状態では、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）の内容が不完了を示す値「０」となっているため、ＳＩＰ品質分析部２０４によって不完了状態でセッションが終了したことが認識される。
【０１６１】
そして、ＳＩＰパケット解析部２０３は、ステップＳ１７０３に基づき、対象ＳＩＰセッションをクローズ可能であると判定したときは、対象セッション管理テーブル内のセッション管理完了フラグを「ＯＮ」に設定する（ステップＳ１７１０→Ｓ１７１１）。
【０１６２】
以上の処理により、対象セッション管理テーブルで示されるＳＩＰセッション全体（ＳＩＰセッション全体をクローズ可能な場合）又はＳＩＰセッションの入側又は出側のうちの処理側（クローズ不可の場合）のセッション管理状態が終了する。これにより、ＳＩＰ
品質分析部２０４による品質分析が可能な状態になる。
【０１６３】
その後、ＳＩＰパケット解析部２０３は、図１７の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
以上のステップＳ１７０２〜Ｓ１７１１の一連の処理の動作シーケンス例は、例えば図２５〜図２７の各Ｓ１のシーケンスや、図２５のＳ５、Ｓ６のシーケンスや、図２６のＳ３のシーケンスに対応する。
【０１６４】
前述したステップＳ１７０１での判定の結果、現在の遷移状態が「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１７１２〜Ｓ１７２１の処理を実行する。
【０１６５】
ここで、ステップＳ１７１２〜Ｓ１７１８、Ｓ１７２０、Ｓ１７２１の一連処理は、「呼設定中」状態（図９のＳ９０２）又は呼出中状態（図９のＳ９０４）であると判定された場合におけるステップＳ１７０２〜Ｓ１７０８、Ｓ１７１０、Ｓ１７１１の一連の処理と同様である。但し、ステップＳ１７１５及びＳ１７１６では、ＩＮＶＩＴＥリトライ待ちタイマの代わりにＲＥＧＩＳＴＥＲリトライ待ちタイマが解除される。
【０１６６】
ステップＳ１７１９では、ＳＩＰパケット解析部２０３は、「ＲＥＧＩＳＴＥＲ終了」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）から「ＲＥＧＩＳＴＥＲ終了」状態（図９のＳ９１１）に遷移する。このセッション終了状態では、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）の内容が不完了を示す値「０」となっているため、ＳＩＰ品質分析部２０４によって不完了状態でＲＥＧＩＳＴＥＲ受信が終了したことが認識される。
【０１６７】
ステップＳ１７２０又はＳ１７２１の処理の後、ＳＩＰパケット解析部２０３は、図１７の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１６８】
前述のステップＳ１７０１での判定の結果、現在の遷移状態が「呼設定」状態でも「呼呼出中」状態でも「ＲＥＧＩＳＴＥＲ受信」状態でもないと判定したならば、ＳＩＰパケット解析部は、受信したＳＩＰレスポンスを無視して破棄する（ステップＳ１７２２）。
その後、ＳＩＰパケット解析部２０３は、図１７の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１６９】
次に、図１０のステップＳ１００９にて、受信メッセージが前述した４０１レスポンスであると判定した場合には、ＳＩＰパケット解析部２０３は、図１８の動作フローチャートの処理を実行する。以下、図１８の動作フローチャートによる動作について説明する。この処理は、「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）から「ＲＥＧＩＳＴＥＲリトライ待ち」状態（図９のＳ９１０）に状態遷移するための処理である。
【０１７０】
「ＲＥＧＩＳＴＥＲリトライ待ち」状態は、例えば図２４（ｂ）の動作シーケンス図として例示される。これは、図２４（ａ）において前述した「ＩＮＶＩＴＥリトライ待ち」状態（図９のＳ９０３）と同様の状態である。即ち、例えばＳＩＰサーバが端末等からＲＥＧＩＳＴＥＲリクエストを受信（Ｓ１）した後に、ＳＩＰサーバ側から端末等に、認証要求を行う場合がある。この場合には、ＳＩＰサーバから端末等に「４０１  Ｕｎａｕｔｈｏｒｉｚｅｄ」という特殊なレスポンスが返される（Ｓ２）。これを受けて、端末からＳＩＰサーバに再度、ＲＥＧＩＳＴＥＲリクエストが送られる（Ｓ３）。上述の４０１レ
スポンスが受信されたときの処理が、以下に説明する処理である。
【０１７１】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１８０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１７２】
ステップＳ１８０１での判定の結果、現在の遷移状態が「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１８０２〜Ｓ１８０４の処理を実行する。
【０１７３】
まず、ＳＩＰパケット解析部２０３は、レスポンスタイマを解除する（ステップＳ１８０２）。
次に、ＳＩＰパケット解析部２０３は、「ＲＥＧＩＳＴＥＲリトライ待ち」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１８０３）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）から「ＲＥＧＩＳＴＥＲリトライ待ち」状態（図９のＳ９１０）に遷移する。
【０１７４】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に対応させてＲＥＧＩＳＴＥＲリトライ待ちタイマを設定し、スタートさせる（ステップＳ１８０４）。このタイマは、該当するＳＩＰセッションの入側又は出側の経路に関して、４０１レスポンスの受信後更にＲＥＧＩＳＴＥＲリクエストの受信待ちを行うためのタイマである。
【０１７５】
その後、ＳＩＰパケット解析部２０３は、図１８の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
前述のステップＳ１８０１での判定の結果、現在の遷移状態が「ＲＥＧＩＳＴＥＲ受信」状態でないと判定したならば、ＳＩＰパケット解析部２０３は、４０１レスポンスを無視して破棄する（ステップＳ１８０５）。
その後、ＳＩＰパケット解析部２０３は、図１８の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
【０１７６】
図１０のステップＳ１００９にて、受信メッセージがＲＥＧＩＳＴＥＲリクエストであると判定した場合には、ＳＩＰパケット解析部２０３は、図１９の動作フローチャートの処理を実行する。以下、図１９の動作フローチャートによる動作について説明する。
【０１７７】
まず、ＳＩＰパケット解析部２０３は、該当するＳＩＰセッションの現在の遷移状態を判定する（ステップＳ１９０１）。この判定は、前述した対象セッション管理テーブル内の「セッション状態」フィールドの値を参照することで実現できる。
【０１７８】
ステップＳ１９０１での判定の結果、現在の遷移状態が「空き」状態（図９のＳ９０１）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１９０２〜Ｓ１９０７の処理を実行する。
【０１７９】
即ちまず、ＳＩＰパケット解析部２０３は、ＲＥＧＩＳＴＥＲリクエストが格納されていたＩＰパケットのヘッダ内の送信元ＩＰアドレスを、対象セッション管理テーブル内の「送信元ＩＰアドレス」フィールド（図５参照）に保持する（ステップＳ１９０２）。
【０１８０】
次に、ＳＩＰパケット解析部２０３は、ＲＥＧＩＳＴＥＲリクエストが格納されていたＩＰパケットのヘッダ内の宛先ＩＰアドレスを、対象セッション管理テーブル内の「宛先
ＩＰアドレス」フィールド（図５参照）に保持する（ステップＳ１９０３）。
【０１８１】
次に、ＳＩＰパケット解析部２０３は、「ＲＥＧＩＳＴＥＲ受信」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ１９０４）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「空き」状態（図９のＳ９０１）から「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）に遷移する。
【０１８２】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に対応させてレスポンスタイマを設定し、スタートさせる（ステップＳ１９０５）。ＲＥＧＩＳＴＥＲリクエストに対してレスポンスが返らない場合に、このレスポンスタイマが満了することにより、そのＳＩＰセッション（入側又は出側）は不完了であるとして、セッション管理テーブルや各種タイマ等のリソースを解放することができる。
【０１８３】
そして、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に対応させてＡｕｄｉｔタイマを設定し、スタートさせる（ステップＳ１９０６）。
【０１８４】
その後、ＳＩＰパケット解析部２０３は、図１９の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
前述したステップＳ１９０１での判定の結果、現在の遷移状態が「ＲＥＧＩＳＴＥＲリトライ待ち」状態（図９のＳ９１０）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１９０７〜Ｓ１９１２の処理を実行する。
【０１８５】
「ＲＥＧＩＳＴＥＲリトライ待ち」状態については、例えば図２４（ｂ）の動作シーケンス図として説明した。この状態において、更にＲＥＧＩＳＴＥＲリクエストが受信されると（図２４（ｂ）のＳ３）、ＳＩＰパケット解析部２０３は、「ＲＥＧＩＳＴＥＲリトライ待ち」状態から再び「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）に遷移状態を戻す。これを実現するのが、図１９のステップＳ１９０７〜Ｓ１９１２の一連の処理である。
【０１８６】
まず、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路に関して設定されているＲＥＧＩＳＴＥＲリトライ待ちタイマを解除する（ステップＳ１９０７）。このタイマは、前述の４０１レスポンスの受信時に図１８のステップＳ１８０４において設定されスタートされたものである。このタイマ解除により、「ＲＥＧＩＳＴＥＲリトライ待ち」状態において次のＲＥＧＩＳＴＥＲリクエストを待つための時間カウントが終了する。
【０１８７】
次に、ＳＩＰパケット解析部２０３は、ステップＳ１９０８〜Ｓ１９１２の一連の処理として、対象セッション管理テーブルへの送信元ＩＰアドレスと宛先ＩＰアドレスの保持及び「呼設定中」状態の設定、並びに、レスポンスタイマの設定及びスタートを行う。これらの処理は、前述したステップＳ１９０２〜Ｓ１９０６の一連の処理と同様である。
【０１８８】
その後、ＳＩＰパケット解析部２０３は、図１９の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
前述したステップＳ１９０１での判定の結果、現在の遷移状態が「ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）であると判定したならば、ＳＩＰパケット解析部２０３は、ステップＳ１９１３〜Ｓ１９１８の処理を実行する。この状態は、ＲＥＧＩＳＴＥＲリクエストが受信されて「ＲＥＧＩＳＴＥＲ受信」状態になった後に更に、ＲＥＧＩＳＴＥＲ
リクエストが重ねて受信されたような場合である。
【０１８９】
この場合には、ＳＩＰパケット解析部２０３は、レスポンスタイマを一旦解除し（ステップＳ１９１３）、再度、ステップＳ１９１４〜Ｓ１９１８の一連の処理として、対象セッション管理テーブルへの送信元ＩＰアドレスと宛先ＩＰアドレスの保持及び「呼設定中」状態の設定、並びに、レスポンスタイマの設定及びスタートを行う。これらの処理は、前述したステップＳ１９０２〜Ｓ１９０６の一連の処理と同様である。
【０１９０】
その後、ＳＩＰパケット解析部２０３は、図１９の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
前述のステップＳ１９０１での判定の結果、現在の遷移状態が「空き」状態でも「ＲＥＧＩＳＴＥＲリトライ待ち」状態でも「ＲＥＧＩＳＴＥＲ受信」状態でもないと判定したならば、ＳＩＰパケット解析部２０３は、ＲＥＧＩＳＴＥＲリクエストを無視して破棄する（ステップＳ１９１９）。
【０１９１】
その後、ＳＩＰパケット解析部２０３は、図１９の動作フローチャートの処理を終了して図１０のステップＳ１０１０の処理を終了する。
以上説明した一連の動作により、図１０のステップＳ１０１０の処理が具体的に実行される。ステップＳ１０１０の処理の後、ＳＩＰパケット解析部２０３は、ステップＳ１００１の処理に戻り、次の受信パケットの内容を解析する。
【０１９２】
図１０に示されるＳＩＰパケット解析処理とは独立して、ＳＩＰパケット解析部２０３は、タイマ監視処理を実行している。ここでは、ＳＩＰパケット解析部２０３は、全てのセッション管理テーブルの入側及び出側毎に設定しているレスポンスタイマ、Ａｕｄｉｔタイマ、ＩＮＶＩＴＥリトライ待ちタイマ、及びＲＥＧＩＳＴＥＲリトライ待ちタイマのそれぞれが、計時期間を満了したか否かを監視する。そして、ＳＩＰパケット解析部２０３は、満了が発生したタイマについて、図２０〜図２２で示される動作フローチャートの処理を実行する。
【０１９３】
図２０は、レスポンスタイマが満了したときの動作を示す動作フローチャートである。
まず、ＳＩＰパケット解析部２０３は、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側の経路のうち両方、即ち、当該ＳＩＰセッション全体をクローズ可能であるか否かの判定を行う（ステップＳ２００１）。この判定は、図１５のステップＳ１５０７の場合と同様である。
【０１９４】
ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ可能であると判定したときは、対象となるＳＩＰセッションに対応する全てのタイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＩＮＶＩＴＥリトライ待ちタイマ）を解除する（ステップＳ２００２→Ｓ２００３）。
【０１９５】
一方、ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションをクローズ不可であると判定したときは、対象セッション管理テーブルに対応するＳＩＰセッションの入側又は出側のうちの処理側のみに対応する全タイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＩＮＶＩＴＥリトライ待ちタイマ）を解除する（ステップＳ２００２→Ｓ２００４）。
【０１９６】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）に、不完了を示す値「０」を保持する（ステップＳ２００５）。
【０１９７】
次に、ＳＩＰパケット解析部２０３は、「セッション終了」又は「ＲＥＧＩＳＴＥＲ終
了」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ２００６）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「セッション終了」状態（図９のＳ９０７）又は「ＲＥＧＩＳＴＥＲ終了」状態（図９のＳ９１１）に遷移する。この状態では、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）の内容が不完了を示す値「０」となっているため、ＳＩＰ品質分析部２０４によって不完了状態でセッション又はＲＥＧＩＳＴＥＲが終了したことが認識される。
【０１９８】
そして、ＳＩＰパケット解析部２０３は、ステップＳ２００１に基づき、対象ＳＩＰセッションをクローズ可能であると判定したときは、対象セッション管理テーブル内のセッション管理完了フラグを「ＯＮ」に設定する（ステップＳ２００７→Ｓ２００８）。
その後、ＳＩＰパケット解析部２０３は、図２０の動作フローチャートの処理を終了する。
【０１９９】
図２１は、ＩＮＶＩＴＥリトライ待ちタイマ又はＲＥＧＩＳＴＥＲリトライ待ちタイマが満了したときの動作を示す動作フローチャートである。ここに示されるステップＳ２１０１〜Ｓ２１０８の一連の処理は、レスポンスタイマが満了したときに実行される図２０のステップＳ２００１〜Ｓ２００８の一連の処理と同様である。これにより、これらのタイマが満了したセッションが不完了状態でクローズされる。
【０２００】
図２２は、Ａｕｄｉｔタイマが満了したときの動作を示す動作フローチャートである。
まず、ＳＩＰパケット解析部２０３は、対象となるＳＩＰセッションに対応する全てのタイマ（レスポンスタイマ、Ａｕｄｉｔタイマ、ＩＮＶＩＴＥリトライ待ちタイマ）を無条件に解除する（ステップＳ２２０１）。
【０２０１】
次に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）に、不完了を示す値「０」を保持する（ステップＳ２２０２）。
【０２０２】
次に、ＳＩＰパケット解析部２０３は、「セッション終了」又は「ＲＥＧＩＳＴＥＲ終了」を対象セッション管理テーブル内の「セッション状態」フィールド（図５参照）に保持する（ステップＳ２２０３）。これにより、対象セッション管理テーブルで示されるＳＩＰセッションの入側又は出側の遷移状態が、「セッション終了」状態（図９のＳ９０７）又は「ＲＥＧＩＳＴＥＲ終了」状態（図９のＳ９１１）に遷移する。この状態では、対象セッション管理テーブル内の「完了／不完了」表示フィールド（図５参照）の内容が不完了を示す値「０」となっているため、ＳＩＰ品質分析部２０４によって不完了状態でセッション又はＲＥＧＩＳＴＥＲが終了したことが認識される。
【０２０３】
最後に、ＳＩＰパケット解析部２０３は、対象セッション管理テーブル内のセッション管理完了フラグを「ＯＮ」に設定する（ステップＳ２２０４）。
その後、ＳＩＰパケット解析部２０３は、図２２の動作フローチャートの処理を終了する。
【０２０４】
図９に示される状態遷移において、「通話中」状態（図９のＳ９０５）でＳＩＰメッセージとしてＢＹＥメッセージが受信された場合には、「セッション終了」状態（図９のＳ９０６）に遷移する。ただし、本実施形態では、「通話中」状態になった時点で、それ移行の遷移は監視することなく、図２のＳＩＰ品質分析部２０４がセッション品質を分析可能となる。これにより、迅速なＳＩＰ品質の分析が実現される。
【０２０５】
また、図９に示される状態遷移において、「呼設定中」状態（図９のＳ９０２）又は「
ＲＥＧＩＳＴＥＲ受信」状態（図９のＳ９０８）において、４０７レスポンスや４０１レスポンスが受信された場合、図１３や図１８で前述したように「ＩＮＶＩＴＥリトライ待ち」状態（図９のＳ９０３）又は「ＲＥＧＩＳＴＥＲリトライ待ち」状態（図９のＳ９１０）に移行するように制御が行われたが、ネットワーク運用者が設定するネットワークポリシーとして、これらは不完了セッションとして扱われてもよい。この場合には、４０７レスポンスや４０１レスポンスが受信された場合、図１７に示される動作フローチャートが実行されるように制御される。これらがネットワーク運用者によって選択されてもよい。
【０２０６】
図２８は、図２のＳＩＰ品質分析部２０４が実行する接続時間算出処理を示す動作フローチャートである。
まず、ステップＳ２８０１でセッション管理テーブル記憶部２０５に記憶されている全てのセッション管理テーブルの検索が完了したと判定されるまで、ステップＳ２８０２〜Ｓ２８１４の一連の処理が実行される。
【０２０７】
まず、ＳＩＰ品質分析部２０４は、検索したセッション管理テーブルについて、セッション管理完了フラグが完了状態を示しているか否か、即ち「ＯＮ」が設定されているか否かを判定する（ステップＳ２８０２）。
【０２０８】
セッション管理完了フラグが「ＯＮ」であるセッション管理テーブルについてのみ、以下のステップＳ２８０３〜Ｓ２８１４の処理が実行される。
まず、ＳＩＰ品質分析部２０４は、セッション管理テーブルの入側情報領域の１８ｘ受信時刻を抽出する（ステップＳ２８０３）。１８ｘレスポンスは呼出中状態を示している。次に、ＳＩＰ品質分析部２０４は、セッション管理テーブルの入側情報領域のＩＮＶＩＴＥ受信時刻を抽出する（ステップＳ２８０４）。そして、ＳＩＰ品質分析部２０４は、入側情報領域の１８ｘ受信時刻から入側情報領域のＩＮＶＩＴＥ受信時刻を引いて入側接続時間を算出し、それをＳＩＰ品質分析部２０４内に保持される接続時間テーブルに設定する（ステップＳ２８０５）。図２９（ａ）は接続時間テーブルの例を示す図である。
【０２０９】
次に、ＳＩＰ品質分析部２０４は、上記処理で算出した入側接続時間を、ＳＩＰ品質分析部２０４内に保持される処理時間統計情報テーブルの入側呼出時間（積算）に加算する。また、入側呼出呼数を加算する（以上、ステップＳ２８０６）。図２９（ｂ）は処理時間統計情報テーブルの例を示す図である。
【０２１０】
次に、ＳＩＰ品質分析部２０４は、セッション管理テーブルの出側情報領域の１８ｘ受信時刻を抽出する（ステップＳ２８０７）。次に、ＳＩＰ品質分析部２０４は、セッション管理テーブルの出側情報領域のＩＮＶＩＴＥ受信時刻を抽出する（ステップＳ２８０８）。そして、ＳＩＰ品質分析部２０４は、出側情報領域の１８ｘ受信時刻から出側情報領域のＩＮＶＩＴＥ受信時刻を引いて出側接続時間を算出し、それをＳＩＰ品質分析部２０４内に保持される接続時間テーブル（図２９（ａ）参照）に設定する（ステップＳ２８０９）。
【０２１１】
次に、ＳＩＰ品質分析部２０４は、上記処理で算出した出側接続時間を、ＳＩＰ品質分析部２０４内に保持される処理時間統計情報テーブル（図２９（ｂ）参照）の出側呼出時間（積算）に加算する。また、出側呼出呼数を加算する（以上、ステップＳ２８１０）。
【０２１２】
次に、ＳＩＰ品質分析部２０４は、セッション管理テーブルの出側情報領域のＩＮＶＩＴＥ受信時刻を抽出する（ステップＳ２８１１）。次に、ＳＩＰ品質分析部２０４は、セッション管理テーブルの入側情報領域のＩＮＶＩＴＥ受信時刻を抽出する（ステップＳ２８１２）。次に、ＳＩＰ品質分析部２０４は、出側情報領域のＩＮＶＩＴＥ受信時刻から入側情報領域のＩＮＶＩＴＥ受信異国を引いてＩＮＶＩＴＥ処理時間を算出し、接続時間テーブル（図２９（ａ）参照）に設定する（ステップＳ２８１３）。
【０２１３】
次に、ＳＩＰ品質分析部２０４は、上記処理で算出したＩＮＶＩＴＥ処理時間を処理時間統計情報テーブル（図２９（ｂ）参照）のＩＮＶＩＴＥ処理時間（積算）に加算する。また、ＩＮＶＩＴＥ処理呼数を加算する（以上、ステップＳ２８１４）。
【０２１４】
以上のステップＳ２８０２〜Ｓ２８１４の処理が検索できた全てのセッション管理テーブルについて処理された後、ステップＳ２８０１の判定がＹＥＳとなる。
この結果、ＳＩＰ品質分析部２０４は、処理時間統計情報テーブル（図２９（ｂ）参照）のＩＮＶＩＴＥ処理時間（積算）をＩＮＶＩＴＥ処理呼数で割った値をＩＮＶＩＴＥ処理時間(平均)に設定する（ステップＳ２８１５）。
【０２１５】
次に、ＳＩＰ品質分析部２０４は、処理時間統計情報テーブル（図２９（ｂ）三ｓんほう）の入側呼出時間（積算）を入側呼出呼数で割った値を入側呼出時間(平均)に設定する（ステップＳ２８１６）。
【０２１６】
最後に、ＳＩＰ品質分析部２０４は、処理時間統計情報テーブル（図２９（ｂ）参照）の出側呼出時間（積算）を出側呼出呼数で割った値を出側呼出時間(平均)に設定する（ステップＳ２８１７）。
上記処理によって収集される入側接続時間、ＩＮＶＩＴＥ処理時間、及び出側接続時間の関係を図３０に示す。
【０２１７】
図３１は、図２のＳＩＰ品質分析部２０４が実行する統計処理を示す動作フローチャートである。
まず、ステップＳ３１０１でセッション管理テーブル記憶部２０５に記憶されている全てのセッション管理テーブルの検索が完了したと判定されるまで、ステップＳ３１０２〜Ｓ３１１４の一連の処理が実行される。
【０２１８】
まず、ＳＩＰ品質分析部２０４は、検索したセッション管理テーブルについて、セッション管理完了フラグが完了状態を示しているか否か、即ち「ＯＮ」が設定されているか否かを判定する（ステップＳ３１０２）。
【０２１９】
セッション管理完了フラグが「ＯＮ」であるセッション管理テーブルについてのみ、以下のステップＳ３１０３〜Ｓ３１１９の処理が実行される。
まず、ＳＩＰ品質分析部２０４は、それが内部に保持する統計情報テーブル（３分）の総呼数(全呼、入側、出側)のそれぞれに１を加算する（ステップＳ３１０３）。図３２（ａ）は、統計情報テーブル（３分）の構成例を示す図である。
【０２２０】
次に、ＳＩＰ品質分析部２０４は、入側情報領域に完了／不完了表示として「完了」「不完了」のどちらが登録されているかを判定する（ステップＳ３１０４）。
入側情報領域に「完了」が表示されていると判定されたときには更に、出側情報領域に完了／不完了表示として「完了」「不完了」のどちらが登録されているかを判定する（ステップＳ３１０５）。
【０２２１】
出側情報領域にも「完了」が表示されていると判定されたときには、ステップＳ３１０１の次のセッション管理テーブルの検索処理に戻る。
ステップ３１０４において入側情報領域に「不完了」が表示されていると判定されたときには、ＳＩＰ品質分析部２０４は、入側情報領域について不完了発生テーブルに入側レ
スポンスコードが設定済であるか否かを判定する（ステップＳ３１０６）。図３２（ｂ）は、不完了発生テーブルの構成例を示す図である。
【０２２２】
ＳＩＰ品質分析部２０４は、入側情報領域について不完了発生テーブルに入側レスポンスコードが未設定であるときには、入側についてＳＩＰ情報は設定されていないため、ステップＳ３１０３で余分に加算された分だけ、統計情報テーブル（３分）の総呼数（入側）を１減算する（ステップＳ３１０７）。
【０２２３】
ＳＩＰ品質分析部２０４は、入側情報領域について不完了発生テーブルに入側レスポンスコードが設定済であるときには、不完了発生テーブルの入側レスポンスコード／入側完了フラグを設定する（ステップＳ３１０８）。
【０２２４】
次に、ＳＩＰ品質分析部２０４は、出側情報領域に完了／不完了表示として「完了」「不完了」のどちらが登録されているかを判定する（ステップＳ３１０９）。
ステップ３１０９において出側情報領域に「不完了」が表示されていると判定されたときには、ＳＩＰ品質分析部２０４は、出側情報領域について不完了発生テーブルに出側レスポンスコードが設定済であるか否かを判定する（ステップＳ３１１０）。
【０２２５】
ＳＩＰ品質分析部２０４は、出側情報領域について不完了発生テーブルに出側レスポンスコードが未設定であるときには、出側についてＳＩＰ情報は設定されていないため、ステップＳ３１０３で余分に加算された分だけ、統計情報テーブル（３分）の総呼数（出側）を１減算する（ステップＳ３１１１）。
【０２２６】
ＳＩＰ品質分析部２０４は、出側情報領域について不完了発生テーブルに出側レスポンスコードが設定済であるときには、不完了発生テーブルの出側レスポンスコード／出側完了フラグを設定する（ステップＳ３１１２）。
【０２２７】
上記ステップＳ３１１２の処理の後又は前述のステップＳ３１０９において出側情報領域に「完了」が表示されていると判定されたときに、ＳＩＰ品質分析部２０４は、不完了発生テーブルの入側/出側レスポンスコードを判断し、重要度の高い方を全呼レスポンスコードに設定する（ステップＳ３１１３）。
【０２２８】
次に、ＳＩＰ品質分析部２０４は、不完了発生テーブルの入側／出側完了フラグを判断し、どちらか一方或いは両方が不完了の場合、不完了発生フラグに不完了発生を設定する（ステップＳ３１１４）。
【０２２９】
次に、ＳＩＰ品質分析部２０４は、不完了発生テーブルの完了時刻、Ｃａｌｌ−ＩＤ、発信者情報（Ｆｒｏｍ）、着信者譲歩（Ｔｏ）、送信元ＩＰアドレス、宛先ＩＰアドレスを設定する（ステップＳ３１１５）。
【０２３０】
次に、ＳＩＰ品質分析部２０４は、不完了発生テーブルの入側レスポンスコードを判定し、統計情報テーブルの入側の異常呼数、不完了呼数を加算する（ステップＳ３１１６）。
【０２３１】
次に、ＳＩＰ品質分析部２０４は、不完了発生テーブルの出側レスポンスコードを判定し、統計情報テーブルの出側の異常呼数、不完了呼数を加算する（ステップＳ３１１７）。
【０２３２】
次に、ＳＩＰ品質分析部２０４は、不完了発生テーブルの入側/出側レスポンスコードを判定し、入側のみ不完了のレスポンスコードとなっている場合は、統計情報テーブルの
入側／全呼の不完了発生呼数を加算する（ステップＳ３１１８）。
【０２３３】
次に、ＳＩＰ品質分析部２０４は、不完了発生テーブルの入側/出側レスポンスコードを判定し、どちらか一方或いは両方が異常呼及び不完了呼を示している場合は、統計情報テーブルの全呼の異常呼数、不完了呼数を加算する（ステップＳ３１１９）。
【０２３４】
以上の処理の後、次のセッション管理テーブルを検索するためのステップＳ３１０１の処理に戻る。
ステップＳ３１０１において、全てのセッション管理テーブルの検索が終了したら、ＳＩＰ品質分析部２０４は、図３１の統計処理を終了する。
【０２３５】
以上のようにしてＳＩＰ品質分析部２０４は、ＳＩＰパケット解析部２０３によりＳＩＰセッション状態及びセッション情報が保持されたセッション管理テーブルを参照し、情報を分析する。これにより、ＳＩＰ品質分析部２０４は、セッションの完了、不完了（準正常、異常）の特定、発信者がセッション呼出し中状態（１８０Ｒｉｎｇｉｎｇ受信）を把握するまでの接続時間の特定、ＳＩＰサーバで呼接続信号の処理に要している時間の特定などを行うことが可能となる。
【０２３６】
そして、ＳＩＰ品質分析部２０４は、分析対象となる複数セッションの全てを分析し、統計情報として集計することが可能となる。また、ＳＩＰ品質分析部２０４は、予め品質劣化と判断する統計データの閾値を定義しておくことにより、閾値オーバーであれば品質劣化としてアラームをネットワーク管理者に通知するという判断も行うことが可能となる。
【０２３７】
そして、統計情報通知部２０６は、ＳＩＰ品質分析部２０４にて収集された統計情報を、ネットワーク管理者に提供し、また、アラームをネットワーク管理者に通知することができる。
【０２３８】
以上の開示技術により、シグナリングプロトコルサーバでの統計情報収集では無く、ネットワーク側のネットワーク品質監視装置によるシグナリングプロトコル品質情報の収集が可能となる。
【０２３９】
また、シグナリングプロトコルサーバが障害により停止した状態の期間でも、停止前後も含め該当シグナリングプロトコルサーバへのトラヒック状況などの品質情報を収集することが可能となる。
【０２４０】
また、品質情報を収集する上でシグナリングプロトコルサーバへの処理負担が全くないため、シグナリングプロトコルサーバの処理性能に影響を与えること無く、ネットワーク品質状況を把握することが可能となる。
【０２４１】
また、監視対象のシグナリングプロトコルサーバが処理するシグナリングプロトコルセッションのトラヒック量と同一のトラヒック量をネットワーク側で収集することが可能となり、適正なネットワーク運用管理を行うことが可能となる。
【０２４２】
また、ネットワーク管理者は監視対象サーバの入側のＳＩＰセッション制御品質状況、出側のＳＩＰセッション制御品質状況、入側、出側トータルでのＳＩＰセッション品質状況を把握することが可能となる。
【０２４３】
また、不完了時に監視対象サーバが不完了検出サーバであるのか、監視対象サーバは不完了を通知されたのみで、実際には後位サーバやネットワークが不完了検出をしているの
かを容易に把握することが可能となる。
【０２４４】
また、入側単位、出側単位及び総数として統計情報を把握することが可能となり、障害サーバや障害区間を早期に特定することが可能となり、早期の障害要因の解消につながる。
【０２４５】
また、ＳＩＰセッションの確立に至るまでに必要となるＳＩＰ最終レスポンスと不完了とすべき最終レスポンスを区別して完了・不完了判断を行うため、ＳＩＰセッション制御品質測定の精度を向上することが可能となり、適正なネットワーク運用管理が行える。
【０２４６】
また、他プロトコルとのゲートウェイサーバなどの監視時には入側で測定した接続時間に遅延が見られれば、自サーバを含む後位の他プロトコルネットワークになんらかの要因があり、出側で測定した接続時間に遅延が見られれば、ＳＩＰ網内に遅延要因があるということを一意に把握することが可能であり、早期の遅延理由の特定が図れる。
そして、監視対象ＳＩＰサーバのＳＩＰ信号処理性能が認識できるため、ＳＩＰサーバの輻輳状況を把握することが可能となる。
【０２４７】
以上の実施形態に関して、更に以下の付記を開示する。
（付記１）
インターネットプロトコルに基づいて通信が行われるＩＰネットワーク上で運用され、シグナリングプロトコルに基づいて通信の状態が制御されるインターネットサービスにおいてネットワーク品質を監視するネットワーク品質監視装置であって、
前記シグナリングプロトコルを処理するサーバ装置であってクライアントからのリクエストを受信するシグナリングプロトコルサーバ装置が前記ＩＰネットワークとの間で通信するパケットを受信するパケット受信部と、
該パケット受信部が受信したパケットのうち、前記シグナリングプロトコルを制御するためのシグナリングプロトコルパケットを抽出するシグナリングプロトコルパケット抽出部と、
該シグナリングプロトコルパケット抽出部が抽出し、前記シグナリングプロトコルサーバ装置が該装置の入側及び出側のそれぞれで送受信する前記通信のセッションを確立するためのシグナリングプロトコルパケットを解析することにより、前記セッション状態の遷移を管理しながら、前記シグナリングプロトコルパケットから得られるシグナリングプロトコル情報及び前記セッション状態を、前記セッション毎及び前記入側及び出側毎に関連付けてセッション管理テーブルとして管理するシグナリングプロトコルパケット解析部と、
前記セッション管理テーブルを記憶するセッション管理テーブル記憶部と、
該セッション管理テーブル記憶部に記憶されるセッション管理テーブルのうち、所定の通信状態に遷移したセッションに対応するセッション管理テーブルから、前記ネットワーク品質に関する品質情報を収集し、該収集結果に基づいて前記ネットワーク品質に関する統計情報を分析するシグナリングプロトコル品質分析部と、
該シグナリングプロトコル品質分析部にて得られた前記品質情報及び前記統計情報を通知する統計情報通知部と、
を含むことを特徴とするネットワーク品質監視装置。
（付記２）
前記所定の通信状態に遷移したセッションは、前記通信の呼設定開始後通話中状態に遷移したセッション及び前記通信の呼設定開始後通話中状態に達しないで不完了の終了状態に遷移したセッションを含む、
ことを特徴とする付記１に記載のネットワーク品質監視装置。
（付記３）
前記シグナリングプロトコルパケット解析部は、
前記セッションを前記不完了の終了状態に遷移させるシグナリングプロトコルパケットを予めネットワークポリシーとして定義し、
該定義に合致したシグナリングプロトコルパケットが抽出されたときに、前記セッションの通信状態を前記不完了の終了状態に遷移させる、
ことを特徴とする付記２に記載のネットワーク品質監視装置。
（付記４）
前記シグナリングプロトコル品質分析部は、前記入側及び出側のそれぞれの単位、及び該入側及び出側を纏めた前記セッションの単位で、前記品質情報の収集及び前記統計情報の分析を行う、
ことを特徴とする付記１乃至３の何れか１項に記載のネットワーク品質監視装置。
（付記５）
前記シグナリングプロトコルパケット解析部は、前記シグナリングプロトコル情報の受信時刻を収集して前記セッション管理テーブルにて管理し、
前記シグナリングプロトコル品質分析部は、前記セッション管理テーブルから、前記シグナリングプロトコル情報の受信時刻に関する情報を収集し、該収集結果に基づいて前記ネットワークの接続時間に関する統計情報を分析する、
ことを特徴とする付記１乃至４の何れか１項に記載のネットワーク品質監視装置。
（付記６）
前記シグナリングプロトコルパケット解析部は、前記シグナリングプロトコル情報の受信時刻を収集して前記セッション管理テーブルにて管理し、
前記シグナリングプロトコル品質分析部は、前記セッション管理テーブルから、前記入側及び出側のそれぞれに対応するシグナリングプロトコル情報の受信時刻に関する情報を収集して該入側及び出側間の時間差に関する情報を算出することにより、前記シグナリングプロトコルサーバ装置の処理時間に関する統計情報を分析する、
ことを特徴とする付記１乃至５の何れか１項に記載のネットワーク品質監視装置。
（付記７）
インターネットプロトコルに基づいて通信が行われるＩＰネットワーク上で運用され、シグナリングプロトコルに基づいて通信の状態が制御されるインターネットサービスにおいてネットワーク品質を監視するネットワーク品質監視方法であって、
前記シグナリングプロトコルを処理するサーバ装置であってクライアントからのリクエストを受信するシグナリングプロトコルサーバ装置が前記ＩＰネットワークとの間で通信するパケットを受信するパケット受信ステップと、
該パケット受信ステップが受信したパケットのうち、前記シグナリングプロトコルを制御するためのシグナリングプロトコルパケットを抽出するシグナリングプロトコルパケット抽出ステップと、
該シグナリングプロトコルパケット抽出ステップが抽出し、前記シグナリングプロトコルサーバ装置が該装置の入側及び出側のそれぞれで送受信する前記通信のセッションを確立するためのシグナリングプロトコルパケットを解析することにより、前記セッション状態の遷移を管理しながら、前記シグナリングプロトコルパケットから得られるシグナリングプロトコル情報及び前記セッション状態を、前記セッション毎及び前記入側及び出側毎に関連付けてセッション管理テーブルとして管理するシグナリングプロトコルパケット解析ステップと、
前記セッション管理テーブルのうち、所定の通信状態に遷移したセッションに対応するセッション管理テーブルから、前記ネットワーク品質に関する品質情報を収集し、該収集結果に基づいて前記ネットワーク品質に関する統計情報を分析するシグナリングプロトコル品質分析ステップと、
該シグナリングプロトコル品質分析ステップにて得られた前記品質情報及び前記統計情報を通知する統計情報通知ステップと、
を含むことを特徴とするネットワーク品質監視方法。
（付記８）
前記所定の通信状態に遷移したセッションは、前記通信の呼設定開始後通話中状態に遷移したセッション及び前記通信の呼設定開始後通話中状態に達しないで不完了の終了状態に遷移したセッションを含む、
ことを特徴とする付記７に記載のネットワーク品質監視方法。
（付記９）
前記シグナリングプロトコルパケット解析ステップは、
前記セッションを前記不完了の終了状態に遷移させるシグナリングプロトコルパケットを予めネットワークポリシーとして定義し、
該定義に合致したシグナリングプロトコルパケットが抽出されたときに、前記セッションの通信状態を前記不完了の終了状態に遷移させる、
ことを特徴とする付記８に記載のネットワーク品質監視方法。
（付記１０）
前記シグナリングプロトコル品質分析ステップは、前記入側及び出側のそれぞれの単位、及び該入側及び出側を纏めた前記セッションの単位で、前記品質情報の収集及び前記統計情報の分析を行う、
ことを特徴とする付記７乃至９の何れか１項に記載のネットワーク品質監視方法。
（付記１１）
前記シグナリングプロトコルパケット解析ステップは、前記シグナリングプロトコル情報の受信時刻を収集して前記セッション管理テーブルにて管理し、
前記シグナリングプロトコル品質分析ステップは、前記セッション管理テーブルから、前記シグナリングプロトコル情報の受信時刻に関する情報を収集し、該収集結果に基づいて前記ネットワークの接続時間に関する統計情報を分析する、
ことを特徴とする付記７乃至１０の何れか１項に記載のネットワーク品質監視方法。
（付記１２）
前記シグナリングプロトコルパケット解析ステップは、前記シグナリングプロトコル情報の受信時刻を収集して前記セッション管理テーブルにて管理し、
前記シグナリングプロトコル品質分析ステップは、前記セッション管理テーブルから、前記入側及び出側のそれぞれに対応するシグナリングプロトコル情報の受信時刻に関する情報を収集して該入側及び出側間の時間差に関する情報を算出することにより、前記シグナリングプロトコルサーバ装置の処理時間に関する統計情報を分析する、
ことを特徴とする付記７乃至１１の何れか１項に記載のネットワーク品質監視方法。
【図面の簡単な説明】
【０２４８】
【図１】本実施形態が適用されるネットワークの全体構成図である。
【図２】本実施形態による品質監視装置１０１の構成図である。
【図３】ＳＩＰメッセージ（ＳＩＰリクエスト）のデータ構成例を示す図である。
【図４】ＳＩＰメッセージ（ＳＩＰレスポンス）のデータ構成例を示す図である。
【図５】セッション管理テーブルに記憶される情報を示すデータ構成図である。
【図６】本実施形態の動作概要の説明図である。
【図７】一般的なＳＩＰプロキシの動作シーケンス例を示す図である。
【図８】一般的なＳＩＰプロキシの動作説明図である。
【図９】ＳＩＰパケット解析部２０３の制御動作を示す状態遷移図である。
【図１０】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（全体処理）である。
【図１１】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（ＩＮＶＩＴＥリクエストの受信処理）である。
【図１２】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（１００  Ｔｒｙｉｎｇレスポンスの受信処理）である。
【図１３】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（４０７レスポンスの受信処理）である。
【図１４】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（１８ｘレスポンスの受信処理）である。
【図１５】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（２００  ＯＫレスポンスの受信処理）である。
【図１６】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（解析対象外信号の受信処理）である。
【図１７】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（３ｘｘ／４ｘｘ（４０１、４０７以外）／５ｘｘ／６ｘｘレスポンスの受信処理）である。
【図１８】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（４０１レスポンスの受信処理）である。
【図１９】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（ＲＥＧＩＳＴＥＲリクエストの受信処理）である。
【図２０】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（レスポンスタイマ終了処理）である。
【図２１】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（リクエストリトライ待ちタイマ満了処理）である。
【図２２】ＳＩＰパケット解析部２０３の制御動作を示す動作フローチャート（Ａｕｄｉｔタイマ満了処理）である。
【図２３】セッション管理テーブルのハッシュ検索処理の動作説明図である。
【図２４】リクエストリトライ処理の動作例を示す動作シーケンス図である。
【図２５】本実施形態の動作例（完了処理）を示す動作シーケンスである。
【図２６】本実施形態の動作例（後位のＳＩＰサーバによる不完了処理）を示す動作シーケンスである。
【図２７】本実施形態の動作例（監視対象のＳＩＰサーバによる不完了処理）を示す動作シーケンスである。
【図２８】ＳＩＰ品質分析部２０４による接続時間算出処理を示す動作フローチャートである。
【図２９】接続時間テーブル及び処理時間統計情報テーブルのデータ構成例を示す図である。
【図３０】接続時間算出処理の動作説明図である。
【図３１】ＳＩＰ品質分析部２０４による統計処理を示す動作フローチャートである。
【図３２】統計情報テーブル及び不完了発生テーブルのデータ構成例を示す図である。
【符号の説明】
【０２４９】
１０１  品質監視装置
１０２  ＩＰ網
１０２−１  Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）
１０２−２  Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）
１０２−３  Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ  Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）
１０２−４  ＣＳ−ＡＳ（Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）
１０２−５  ＭＧＣＦ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）
１０２−６  ＧＷ（ＧａｔｅＷａｙ）
１０２−７  ＳＧＷ（Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ）１０２−７
１０２−８  ＳＷ−ＨＵＢ（ＳＷｉｔｃｈｉｎｇ  ＨＵＢ）
１０３  移動網
１０３−１  ＢＴＳ（Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｔａｔｉｏｎ）
１０３−２  ＢＳＣ（Ｂａｓｅ  Ｓｔａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）
１０３−３  移動端末
１０４  他網
２０１  パケット受信部
２０２  ＳＩＰパケット抽出部
２０３  ＳＩＰパケット解析部
２０４  ＳＩＰ品質分析部
２０５  セッション管理テーブル記憶部
２０６  統計情報通知部
３０１、４０１  ＳＩＰヘッダ
３０２、４０２  本文
６０１、８０１  監視対象のＳＩＰサーバ
６０２、８０３  後位のＳＩＰサーバ
６０３  ＳＩＰ−ＧＷ
８０２  前位のＳＩＰサーバ
【図２】
2010141855.tif 000003
【図３】
2010141855.tif 000004
【図４】
2010141855.tif 000005
【図５】
2010141855.tif 000006
【図１０】
2010141855.tif 000007
【図１１】
2010141855.tif 000008
【図１２】
2010141855.tif 000009
【図１３】
2010141855.tif 000010
【図１４】
2010141855.tif 000011
【図１５】
2010141855.tif 000012
【図１６】
2010141855.tif 000013
【図１７】
2010141855.tif 000014
【図１８】
2010141855.tif 000015
【図１９】
2010141855.tif 000016
【図２０】
2010141855.tif 000017
【図２１】
2010141855.tif 000018
【図２２】
2010141855.tif 000019
【図２３】
2010141855.tif 000020
【図２８】
2010141855.tif 000021
【図２９】
2010141855.tif 000022
【図３１】
2010141855.tif 000023
【図３２】
2010141855.tif 000024
【図１】
2010141855.tif 000025
【図６】
2010141855.tif 000026
【図７】
2010141855.tif 000027
【図８】
2010141855.tif 000028
【図９】
2010141855.tif 000029
【図２４】
2010141855.tif 000030
【図２５】
2010141855.tif 000031
【図２６】
2010141855.tif 000032
【図２７】
2010141855.tif 000033
【図３０】
2010141855.tif 000034