(57)【特許請求の範囲】
【請求項１】
リクエスト信号を取得するリクエスト信号取得部と、
取得された前記リクエスト信号の並列処理可能な複数のリクエスト内容のいずれかを処理する複数のリクエスト内容処理部と、
前記複数のリクエスト内容処理部による処理結果を結合して出力する処理結果出力部と、
を備え、
前記複数のリクエスト内容処理部は、互いに並列に接続されており、
前記リクエスト信号取得部は、取得された前記リクエスト信号をコピーして前記複数のリクエスト内容処理部へそれぞれ出力し、
前記リクエスト内容は、シーケンシャル処理が必要な一連のリクエストから構成されており、
前記複数のリクエスト内容処理部は、前記リクエストを処理する一以上のリクエスト処理ブロックを備えるとともに、一の前記リクエスト処理ブロックから出力された処理結果を一時的に格納し、次の前記リクエスト処理ブロック又は前記処理結果出力部へ出力するキューを備え、
前記リクエスト信号は、電話網における発呼信号であり、
前記複数のリクエスト内容処理部として、
前記発呼信号に基づいて端末種別分析を行うリクエスト処理ブロックを有する第一のリクエスト内容処理部と、
前記発呼信号に基づいて信号分析を行うリクエスト処理ブロック、及び、前記信号分析を行うリクエスト処理ブロックの処理結果に基づいて加入者認証を行うリクエスト処理ブロックを有する第二のリクエスト内容処理部と、
を備え、
前記端末種別分析を行うリクエスト処理ブロックは、前記発呼信号に含まれる文字列から端末種別情報を抽出し、抽出された前記端末種別情報に基づいて、前記発呼信号に対応する呼に必要な帯域を算出し、算出された帯域を処理結果として当該端末種別分析を行うリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力し、
前記信号分析を行うリクエスト処理ブロックは、前記発呼信号に含まれる文字列から当該発呼信号を発信した発側電話端末に固有な加入者ＩＤを抽出し、抽出された前記加入者ＩＤを処理結果として当該信号分析を行うリクエスト処理ブロックの下流の前記キューを介して前記加入者認証を行うリクエスト処理ブロックへ出力し、
前記加入者認証を行うリクエスト処理ブロックは、前記加入者ＩＤを用いて加入者認証を行い、認証結果を処理結果として当該加入者認証を行うリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力する
ことを特徴とするリクエスト処理サーバ。
【請求項２】
前記第一のリクエスト内容処理部は、前記端末種別分析を行うリクエスト処理ブロックの処理結果に基づいて帯域予約を行うリクエスト処理ブロックをさらに有し、
前記帯域予約を行うリクエスト処理ブロックは、算出された前記帯域を前記端末種別分析を行うリクエスト処理ブロックから当該端末種別分析を行うリクエスト処理ブロックの下流の前記キューを介して取得し、取得された前記帯域を、前記発呼信号に対応する前記発側電話端末及び着側電話端末に対して割り当てることによって帯域予約を行い、割り当てられた前記帯域予約を処理結果として当該帯域予約を行うリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力する
ことを特徴とする請求項１に記載のリクエスト処理サーバ。
【請求項３】
前記複数のリクエスト内容処理部として、
前記発呼信号に基づいて当該発呼信号のセッションがＳＤＰ（Session Description Protocol）に違反しているか否かをチェックするリクエスト処理ブロックを有する第三のリクエスト処理部をさらに備え、
前記ＳＤＰに違反しているか否かをチェックするリクエスト処理ブロックは、前記発呼信号に含まれるＳＤＰの内容を用いてチェックを行い、違反していないというチェック結果の場合には、当該チェック結果を処理結果として当該ＳＤＰに違反しているか否かをチェックするリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力し、違反しているというチェック結果の場合には、当該チェック結果を前記発呼信号の送信元である前記発側電話端末へ出力する
ことを特徴とする請求項１又は請求項２の記載のリクエスト処理サーバ。
【請求項４】
前記複数のリクエスト内容処理部は、処理結果と当該処理結果に対応する前記発呼信号とを関連付けて出力し、
前記処理結果出力部は、同一の前記発呼信号と関連付けられた前記複数のリクエスト内容処理部による処理結果を結合して出力する
ことを特徴とする請求項１から請求項３のいずれか一項に記載のリクエスト処理サーバ。
【請求項５】
リクエスト処理サーバによるリクエスト処理方法であって、
リクエスト信号を取得するステップと、
取得された前記リクエスト信号に基づいて、複数のリクエスト内容を並列処理するステップと、
並列処理による処理結果を結合して出力するステップと、
を含み、
前記リクエスト内容は、シーケンシャル処理が必要な一連のリクエストから構成されており、
前記複数のリクエスト内容を並列処理するステップでは、前記一連のリクエストを順に処理するとともに、一のリクエストの処理結果をキューに一時的に格納し、格納された前記処理結果に基づいて次のリクエストを処理し、
前記リクエスト信号は、電話網における発呼信号であり、
前記複数のリクエスト内容を並列処理するステップは、
前記発呼信号に基づいて端末種別分析を行うリクエスト処理ステップを有する第一のリクエスト内容処理部ステップと、
前記発呼信号に基づいて信号分析を行うリクエスト処理ステップ、及び、前記信号分析を行うリクエスト処理ブロックの処理結果に基づいて加入者認証を行うリクエスト処理ステップを有する第二のリクエスト内容処理ステップと、
を並列に含み、
前記端末種別分析を行うリクエスト処理ステップでは、前記発呼信号に含まれる文字列から端末種別情報を抽出し、抽出された前記端末種別情報に基づいて、前記発呼信号に対応する呼に必要な帯域を算出し、算出された帯域を処理結果として前記キューを介して出力し、
前記信号分析を行うリクエスト処理ステップでは、前記発呼信号に含まれる文字列から当該発呼信号を発信した発側電話端末に固有な加入者ＩＤを抽出し、抽出された前記加入者ＩＤを処理結果として前記キューを介して出力し、
前記加入者認証を行うリクエスト処理ステップでは、前記加入者ＩＤを用いて加入者認証を行い、認証結果を処理結果として前記キューを介して出力する
ことを特徴とするリクエスト処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰネットワーク等の通信網においてリクエスト信号に含まれるリクエストを処理するリクエスト処理サーバ及びリクエスト処理方法に関する。
【背景技術】
【０００２】
ＰＳＴＮ（Public Switched Telephone Network）、ＩＳＤＮ（Integrated Services Digital Network）等のテレコムネットワークでは、クライアント装置（端末）からの呼の受付処理を行う呼制御サーバが存在する。ＩＰ（Internet Protocol）ネットワーク上では、２つ以上のクライアント装置の間でセッションを確立するプロトコルとしてＳＩＰ（Session Initiation Protocol）が用いられている（J.Rosenberg, et.al, “SIP: Session Initiation Protocol”, RFC3261, IETF, 2002.6）。ＳＩＰ信号をクライアント装置から受信し、それを他に送信する等の処理を行うサーバは、呼制御サーバの一種であり、ＳＩＰサーバと呼ばれている。また、ＳＩＰを利用したテレコムシステムとして、ＩＭＳ（IP Multimedia Subsystem）（Miikka Poikselka (著), Georg Mayer (著),” The IMS: IP Multimedia Concepts and Services”, Wiley, 2009.3）、ＮＧＮ（Next Generation Network）（ITU-T Recommendation Y.2012, “Functional requirements and architecture of the NGN,” 2006.）等が存在する。
【０００３】
従来、呼制御サーバにおいて呼処理を迅速に行うための方式として、優先度の異なる２種類以上のキューを用意することで、呼処理時のキュー取り出しにおいて接続要求処理の実行を切断要求処理の実行よりも優先して行うこと可能にする通信制御処理実行方式がある（特開２００７−３２９６１７号公報）。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、リクエスト（すなわち呼）ごとに様々な種類のサービスを提供するＩＭＳでは、呼制御サーバにおいて、各処理ブロックでの処理時間がリクエストごとに異なる。非特許文献１には、呼処理をテキストパージング、振り分けと主処理の２つのステージに分けてそれぞれスレッドないしプロセスで動作させる方法が開示されているが、ＩＭＳのＣＳＣＦ（Call State Control Function）のように大規模で多くの処理ブロックから構成される呼制御サーバでは、呼処理の流れを単に直列に２つのステージに分けるだけでは不十分である。すなわち、従来技術では、並列性を加味して大きな処理ブロックを細かく柔軟に分割することは想定しておらず、また処理ブロック間に依存関係がない箇所も逐次的に処理されていたため、全体の呼処理に時間がかかるという問題があった。
【０００５】
また、もう一つの問題として、様々な種類のサービスを提供する拡張性を備えているＩＭＳにおいて、呼制御サーバは多くの種類の処理ブロックから構成されており、ＩＭＳにおいて新たなサービスや機能を提供するときには、既存の呼制御サーバ内の多数の呼処理ブロックを修正・改変する必要があるという問題があった。
【０００６】
これまで、新たなサービス追加を容易にするサーバやプラットフォームに関する技術としては、特開２００８−１４０３２６号公報に記載された技術のように、ＳＯＡ（Service Oriented Architecture）の概念（非特許文献２参照）に従い、ＸＭＬ（Extensible Markup Language）、ＳＯＡＰ（Simple Object Access Protocol）等を用いて、サービスバスやＥＳＢ（Enterprise Service Bus）にサービス（又はコンポーネント）を着脱する方法がある。また、従来の大半のサービスバスやＥＳＢはＪａｖａ（登録商標）上で実現されており、Ｊａｖａ上で動作するサーバとしては、ＪａｖａＥＥサーバがある（斉藤 賢哉 “マスタリングJavaEE5” 翔泳社 2007.8）。ＪａｖａＥＥサーバは、再利用可能なソフトウェア集合であるＷｅｂコンポーネント、ＥＪＢコンポーネントなどのコンポーネントと、コンポーネントを動作及び制御するための実行環境を提供するソフトウェアであるコンテナと、から構成される。コンテナは、オペレーティングシステム上の仮想マシン（Java Virtual Machine等）上で動作し、コンテナやコンポーネントはＪａｖａ言語により記述・実装されている。
【０００７】
しかし、サービスバス、ＥＳＢ、ＪａｖａＥＥ等といった従来の方法は、仮想マシン（Java Virtual Machine等）上で実現され、かつコンポーネント間やサービス間の通信はＸＭＬ又は仮想マシン上の通信手段を介して行われるため、コンポーネント間の通信に時間を要するため、呼制御サーバに新たなサービスや機能を追加することが容易な柔軟性を持たせたとしても、呼制御サーバでの処理時間が多く要するという問題点があった。
【０００８】
本発明は、前記した問題を解決するために創案されたものであり、リクエスト信号に対する処理に要する時間を短縮することが可能であり、かつ、機能変更及び機能拡張を容易に行うことが可能なリクエスト処理サーバ及びリクエスト処理方法を提供することを課題とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するため、本発明のリクエスト処理サーバは、リクエスト信号を取得するリクエスト信号取得部と、取得された前記リクエスト信号の並列処理可能な複数のリクエスト内容のいずれかを処理する複数のリクエスト内容処理部と、前記複数のリクエスト内容処理部による処理結果を結合して出力する処理結果出力部と、を備え、前記複数のリクエスト内容処理部は、互いに並列に接続されており、前記リクエスト信号取得部は、取得された前記リクエスト信号をコピーして前記複数のリクエスト内容処理部へそれぞれ出力し、前記リクエスト内容は、シーケンシャル処理が必要な一連のリクエストから構成されており、前記複数のリクエスト内容処理部は、前記リクエストを処理する一以上のリクエスト処理ブロックを備えるとともに、一の前記リクエスト処理ブロックから出力された処理結果を一時的に格納し、次の前記リクエスト処理ブロック又は前記処理結果出力部へ出力するキューを備え、前記リクエスト信号は、電話網における発呼信号であり、前記複数のリクエスト内容処理部として、前記発呼信号に基づいて端末種別分析を行うリクエスト処理ブロックを有する第一のリクエスト内容処理部と、前記発呼信号に基づいて信号分析を行うリクエスト処理ブロック、及び、前記信号分析を行うリクエスト処理ブロックの処理結果に基づいて加入者認証を行うリクエスト処理ブロックを有する第二のリクエスト内容処理部と、を備え、前記端末種別分析を行うリクエスト処理ブロックは、前記発呼信号に含まれる文字列から端末種別情報を抽出し、抽出された前記端末種別情報に基づいて、前記発呼信号に対応する呼に必要な帯域を算出し、算出された帯域を処理結果として当該端末種別分析を行うリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力し、前記信号分析を行うリクエスト処理ブロックは、前記発呼信号に含まれる文字列から当該発呼信号を発信した発側電話端末に固有な加入者ＩＤを抽出し、抽出された前記加入者ＩＤを処理結果として当該信号分析を行うリクエスト処理ブロックの下流の前記キューを介して前記加入者認証を行うリクエスト処理ブロックへ出力し、前記加入者認証を行うリクエスト処理ブロックは、前記加入者ＩＤを用いて加入者認証を行い、認証結果を処理結果として当該加入者認証を行うリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力することを特徴とする。
【００１０】
かかる構成によると、リクエスト内容を並列処理することによって、リクエスト内容処理に要する時間を短縮することができ、さらには、リクエスト内容処理部の追加及び変更が容易であるので、リクエスト内容処理の機能変更及び機能拡張を容易に行うことができる。
また、かかる構成によると、「端末種別分析」と「信号分析＋加入者認証」とを同時に行うことができるので、リクエスト内容処理に要する時間を短縮することができる。
【００１３】
また、前記第一のリクエスト内容処理部は、前記端末種別分析を行うリクエスト処理ブロックの処理結果に基づいて帯域予約を行うリクエスト処理ブロックをさらに有し、前記帯域予約を行うリクエスト処理ブロックは、算出された前記帯域を前記端末種別分析を行うリクエスト処理ブロックから当該端末種別分析を行うリクエスト処理ブロックの下流の前記キューを介して取得し、取得された前記帯域を、前記発呼信号に対応する前記発側電話端末及び着側電話端末に対して割り当てることによって帯域予約を行い、割り当てられた前記帯域予約を処理結果として当該帯域予約を行うリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力する構成であってもよい。
【００１４】
かかる構成によると、「端末種別分析＋帯域予約」と「信号分析＋加入者認証」とを同時に行うことができるので、リクエスト内容処理に要する時間を短縮することができる。
【００１５】
前記リクエスト処理サーバは、前記複数のリクエスト内容処理部として、前記発呼信号に基づいて当該発呼信号のセッションがＳＤＰ（Session Description Protocol）に違反しているか否かをチェックするリクエスト処理ブロックを有する第三のリクエスト処理部をさらに備え、前記ＳＤＰに違反しているか否かをチェックするリクエスト処理ブロックは、前記発呼信号に含まれるＳＤＰの内容を用いてチェックを行い、違反していないというチェック結果の場合には、当該チェック結果を処理結果として当該ＳＤＰに違反しているか否かをチェックするリクエスト処理ブロックの下流の前記キューを介して前記処理結果出力部へ出力し、違反しているというチェック結果の場合には、当該チェック結果を前記発呼信号の送信元である前記発側電話端末へ出力する構成であってもよい。
【００１６】
かかる構成によると、「端末種別分析＋帯域予約」と「信号分析＋加入者認証」といわゆる「ＳＤＰチェック」とを同時に行うことができるので、リクエスト内容処理に要する時間を短縮することができる。
また、前記複数のリクエスト内容処理部は、処理結果と当該処理結果に対応する前記発呼信号とを関連付けて出力し、前記処理結果出力部は、同一の前記発呼信号と関連付けられた前記複数のリクエスト内容処理部による処理結果を結合して出力する構成であってもよい。
【００１７】
また、本発明のリクエスト処理方法は、リクエスト処理サーバによるリクエスト処理方法であって、リクエスト信号を取得するステップと、取得された前記リクエスト信号に基づいて、複数のリクエスト内容を並列処理するステップと、並列処理による処理結果を結合して出力するステップと、を含み、前記リクエスト内容は、シーケンシャル処理が必要な一連のリクエストから構成されており、前記複数のリクエスト内容を並列処理するステップでは、前記一連のリクエストを順に処理するとともに、一のリクエストの処理結果をキューに一時的に格納し、格納された前記処理結果に基づいて次のリクエストを処理し、前記リクエスト信号は、電話網における発呼信号であり、前記複数のリクエスト内容を並列処理するステップは、前記発呼信号に基づいて端末種別分析を行うリクエスト処理ステップを有する第一のリクエスト内容処理部ステップと、前記発呼信号に基づいて信号分析を行うリクエスト処理ステップ、及び、前記信号分析を行うリクエスト処理ブロックの処理結果に基づいて加入者認証を行うリクエスト処理ステップを有する第二のリクエスト内容処理ステップと、を並列に含み、前記端末種別分析を行うリクエスト処理ステップでは、前記発呼信号に含まれる文字列から端末種別情報を抽出し、抽出された前記端末種別情報に基づいて、前記発呼信号に対応する呼に必要な帯域を算出し、算出された帯域を処理結果として前記キューを介して出力し、前記信号分析を行うリクエスト処理ステップでは、前記発呼信号に含まれる文字列から当該発呼信号を発信した発側電話端末に固有な加入者ＩＤを抽出し、抽出された前記加入者ＩＤを処理結果として前記キューを介して出力し、前記加入者認証を行うリクエスト処理ステップでは、前記加入者ＩＤを用いて加入者認証を行い、認証結果を処理結果として前記キューを介して出力することを特徴とする。
【発明の効果】
【００１８】
本発明によれば、リクエスト内容処理に要する時間を短縮することができ、かつ、リクエスト内容処理の機能変更及び機能拡張を容易に行うことができる。
【先行技術文献】
【非特許文献】
【００１９】
【非特許文献１】Kundan Singh and Henning Schulzrinne, "Failover, Load Sharing and Server Architecture in SIP Telephony", Submitted to Computer Communication Journal, Elsevier, Aug 2006
【非特許文献２】ディルク・クラフツィック (翻訳), カール・バンク (著), ディルク・スラマ (著), 山下 眞澄 (著)、“SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針”、日経BP社、2005.11
【図面の簡単な説明】
【００２０】
【図１】本発明の実施形態に係るリクエスト処理サーバを模式的に示す図である。
【図２】図１のリクエスト処理サーバの動作例を説明するための図である。
【図３】本発明の第一具体例に係るリクエスト処理サーバを模式的に示す図である。
【図４】本発明の第二具体例に係るリクエスト処理サーバを模式的に示す図である。
【図５】本発明の第三具体例に係るリクエスト処理サーバを模式的に示す図である。
【発明を実施するための形態】
【００２１】
以下、本発明の実施形態及びその具体例について、適宜図面を参照しながら説明する。本発明のリクエスト処理サーバは、リクエスト信号（例えば、電話網における発呼信号）に対する処理が、シーケンシャル処理が必要な一連の（リクエストが一つの場合も含む）リクエストから構成された複数のリクエスト内容からなるとともに、かかる複数のリクエスト内容がそれぞれ並列処理可能であることに着目し、複数のリクエスト内容を並列処理するとともに、各リクエスト内容に含まれる一連のリクエスト（例えば、「端末種別分析＋帯域予約」、「信号分析＋加入者認証」、「ＳＤＰチェック」等）をシーケンシャル処理するものである。すなわち、リクエスト内容は、シーケンシャル処理が必要な一連のリクエストからなるリクエスト群であるといえる。
【００２２】
＜実施形態＞
図１に示すように、本発明の実施形態に係るリクエスト処理サーバ１は、機能部として、リクエスト信号取得部１０と、リクエスト内容処理部２０，３０，４０と、処理結果出力部５０と、を備える。本実施形態では、リクエスト処理サーバ１は、３つのリクエスト内容処理部を備えているが、リクエスト内容処理部は２つであってもよく、４つ以上であってもよい。
【００２３】
リクエスト信号取得部１０は、外部装置から送信されたリクエスト信号（発呼信号）を取得し、取得されたリクエスト信号をコピーしてリクエスト内容処理部２０，３０，４０へそれぞれ出力する。
【００２４】
リクエスト内容処理部２０，３０，４０は、それぞれ、リクエスト信号に対して行うべき複数のリクエストのいずれかを処理するものであり、互いに並列に接続されている。
【００２５】
本実施形態において、リクエスト内容処理部２０は、キュー２１と、リクエスト処理ブロック２２と、キュー２３と、リクエスト処理ブロック２４と、キュー２５と、をシーケンシャルに備える。
【００２６】
キュー２１には、リクエスト信号取得部１０から出力されたリクエスト信号が順に格納される。キュー２１は、キュー２１の先頭に格納されたリクエスト信号が後段のリクエスト処理ブロック２２によって読み出されると、読み出されたリクエスト信号を消去し、次に格納されたリクエスト信号を順次前に格納し直すように構成されている。これは、他のキューに関しても同様である。
【００２７】
リクエスト処理ブロック２２は、キュー２１の先頭に格納されたリクエスト信号を読み出し、読み出されたリクエスト信号に基づいて、当該リクエスト処理ブロック２２が処理すべきリクエストを処理し、処理結果及びリクエスト信号をキュー２３へ出力する。
リクエスト処理ブロック２２は、処理ブロック２２ａ，２２ｂを備えており、２つのリクエストを非同期で処理することができる。
【００２８】
キュー２３には、リクエスト処理ブロック２２から出力された処理結果及びリクエスト信号が順に格納される。
【００２９】
リクエスト処理ブロック２４は、キュー２３の先頭に格納された、リクエスト処理ブロック２２による処理結果及びリクエスト信号を読み出し、読み出された処理結果（必要であれば、リクエスト信号も）に基づいて、当該リクエスト処理ブロック２４が処理すべきリクエストを処理し、リクエスト処理ブロック２４による処理結果（必要であれば、リクエスト処理ブロック２２による処理結果も）及びリクエスト信号をキュー２５へ出力する。
リクエスト処理ブロック２４は、処理ブロック２４ａ，２４ｂを備えており、２つのリクエストを非同期で処理することができる。処理ブロック２４ａ，２４ｂの非動作中にリクエスト処理ブロック２４がリクエストを読み出した場合には、処理ブロック２４ａが当該リクエストを処理し、処理ブロック２４ａの動作中かつ処理ブロック２４ｂの非動作中にリクエスト処理ブロック２４がリクエストを読み出した場合には、処理ブロック２４ｂが当該リクエストを処理する。これは、他のリクエスト処理ブロックにおける処理ブロックに関しても同様である。
【００３０】
キュー２５には、リクエスト処理ブロック２４から出力された処理結果及びリクエスト信号が順に格納される。
【００３１】
本実施形態において、リクエスト内容処理部３０は、キュー３１と、リクエスト処理ブロック３２と、キュー３３と、リクエスト処理ブロック３４と、キュー３５と、リクエスト処理ブロック３６と、キュー３７と、を直列に備える。キュー３１，３３，３５，３７は、前記したキュー２１，２３，２５と同様の機能を有し、リクエスト処理ブロック３２，３４，３６は、前記したリクエスト処理ブロック２２，２４と同様の機能を有する。
【００３２】
また、リクエスト処理ブロック３２は、処理ブロック３２ａ，３２ｂを備えており、２つのリクエストを非同期で処理することができる。リクエスト処理ブロック３４は、処理ブロック３４ａ，３４ｂを備えており、２つのリクエストを非同期に処理することができる。リクエスト処理ブロック３６は、処理ブロック３６ａ，３６ｂを備えており、２つのリクエストを非同期で処理することができる。
【００３３】
本実施形態において、リクエスト内容処理部４０は、キュー４１と、リクエスト処理ブロック４２と、リクエスト処理ブロック４３と、キュー４４と、を直列に備える。キュー４１，４４は、前記したキュー２１，２３，２５と同様の機能を有し、リクエスト処理ブロック４３，４４は、当該リクエスト処理ブロック４３，４４と対応するリクエストを処理する。
【００３４】
また、リクエスト処理ブロック４２は、処理ブロック４２ａ，４２ｂを備えており、２つのリクエストを非同期で処理することができる。リクエスト処理ブロック４３は、処理ブロック４３ａ，４３ｂを備えており、２つのリクエストを非同期で処理することができる。
【００３５】
本実施形態では、リクエスト処理ブロック４３の入力口にはキューが設けられていないため、リクエスト処理ブロック４３の処理ブロック４３ａ，４３ｂの処理中にリクエスト内容処理部４２による処理結果及びリクエスト信号が出力されてきた場合には、リクエスト処理ブロック４３は、処理結果及びリクエスト信号をリクエスト処理ブロック４２に返送するか破棄する。これは、後記する実施形態における、入力口にキューが設けられていない他のリクエスト処理ブロックについても同様である。
【００３６】
処理結果出力部５０は、リクエスト内容処理部２０，３０，４０による処理結果を結合して外部装置へ出力する。本実施形態では、処理結果出力部５０は、キュー２５，３７，４４に格納された処理結果及びリクエスト信号を読み出し、読み出されたリクエスト信号が同一である処理結果を結合し、結合された処理結果及びリクエスト信号を外部装置へ出力する。
【００３７】
＜動作例＞
続いて、本発明の実施形態に係るリクエスト処理サーバ１の動作例について、図２を参照し、特にリクエスト内容処理部２０の動作を中心に説明する。
【００３８】
図２に示すように、リクエスト信号Ｒ１をリクエスト信号取得部１０が取得すると、リクエスト信号取得部１０は、リクエスト信号Ｒ１をコピーしてリクエスト内容処理部２０，３０，４０のキュー２１，３１，４１へそれぞれ出力する（ステップＳ１１）。
【００３９】
リクエスト信号Ｒ１がキュー２１の最後尾（ここでは、他のリクエスト信号が格納されていないため、先頭）に格納されると（ステップＳ２１）、この時点では処理ブロック２２ａ，２２ｂはともに動作していないので、リクエスト処理ブロック２２の処理ブロック２２ａは、リクエスト信号Ｒ１を読み出して処理し（ステップＳ２２）、リクエスト信号Ｒ１及び処理結果をキュー２３の最後尾に格納する（ステップＳ２３）。
【００４０】
一方、ステップＳ１１の後にリクエスト信号Ｒ２をリクエスト信号取得部１０が取得すると、リクエスト信号取得部１０は、リクエスト信号Ｒ２をコピーして複数のリクエスト内容処理部２０，３０，４０のキュー２１，３１，４１へ出力する（ステップＳ１２）。
【００４１】
リクエスト信号Ｒ２がキュー２１の最後尾（ここでは、リクエスト信号Ｒ１が読み出されて消去されているため、先頭が最後尾に該当する。）に格納されると（ステップＳ３１）、この時点では処理ブロック２２ａは動作中であるので、リクエスト処理ブロック２２の処理ブロック２２ｂは、リクエスト信号Ｒ２を読み出して処理し（ステップＳ３２）、リクエスト信号Ｒ２及び処理結果をキュー２３の最後尾に格納する（ステップＳ３３）。
【００４２】
ここで、ステップＳ３３がステップＳ２３よりも先に実行された場合には、キュー２３において、リクエスト信号Ｒ２及びその処理結果がリクエスト信号Ｒ１及びその処理結果よりも前に格納される。
【００４３】
そのため、この時点では処理ブロック２２ａ，２２ｂはともに動作していないので、リクエスト処理ブロック２４の処理ブロック２４ａは、リクエスト信号Ｒ２及びその処理結果を読み出して処理し（ステップＳ２４）、リクエスト信号Ｒ２及び処理結果をキュー２５の最後尾に格納する（ステップＳ２５）。
【００４４】
一方、処理ブロック２２ａが動作中であるので、リクエスト処理ブロック２４の処理ブロック２４ｂは、リクエスト信号Ｒ１及びその処理結果を読み出して処理し（ステップＳ３４）、リクエスト信号Ｒ１及び処理結果をキュー２５の最後尾に格納する（ステップＳ３５）。
【００４５】
リクエスト内容処理部３０，４０も、リクエスト内容処理部２０と同様の動作を行い、リクエスト信号Ｒ１，Ｒ２及びこれらの処理結果がキュー３７，４４に格納される。
【００４６】
処理結果出力部５０は、キュー２５，３７，４４に格納されたリクエスト信号Ｒ１及びその処理結果、並びに、リクエスト信号Ｒ２及びその処理結果を順次読み出し、リクエスト信号Ｒ１の処理結果を結合し、結合された処理結果及びリクエスト信号Ｒ１を外部装置へ出力するとともに、リクエスト信号Ｒ２の処理結果を結合し、結合された処理結果及びリクエスト信号Ｒ２を外部装置へ出力する（ステップＳ４１）。
【００４７】
本発明の実施形態に係るリクエスト処理サーバ１は、複数のリクエスト内容を並列処理することによって、リクエスト内容処理に要する時間を短縮することができる。
また、本発明の実施形態に係るリクエスト処理サーバ１は、リクエスト内容処理部の追加及び変更、並びに、リクエスト内容処理部内に直列に設けられたリクエスト処理ブロックの追加及び変更が容易であるので、リクエスト処理の機能変更及び機能拡張を容易に行うことができる。
【００４８】
＜第一具体例＞
続いて、本発明の第一具体例に係るリクエスト処理サーバについて、図３を参照し、実施形態に係るリクエスト処理サーバ１との相違点を中心に説明する。本具体例において、リクエスト処理サーバは、２つのリクエスト内容を並列処理する。１番目のリクエスト内容は、リクエストとして端末種別分析を含み、２番目のリクエスト内容は、リクエストとして信号分析及び加入者認証を含む。
【００４９】
図３に示すように、本発明の第一具体例に係るリクエスト処理サーバ１Ａは、ＩＰ電話網等で用いられる呼制御サーバであり、機能部として、リクエスト信号取得部１０と、リクエスト内容処理部２０Ａ，３０Ａと、処理結果出力部５０と、を備える。
【００５０】
リクエスト内容処理部２０Ａは、端末種別分析を行うリクエスト処理ブロック２２と、キュー２３と、をシーケンシャルに備える。すなわち、本具体例に係るリクエスト内容処理部２０Ａは、実施形態に係るリクエスト内容処理部２０からキュー２１、リクエスト処理ブロック２４及びキュー２５を省略した構成である。
【００５１】
リクエスト処理ブロック２２は、リクエスト信号（発呼信号）に基づいて、リクエスト信号を発信した電話端末の端末種別を分析し、リクエスト信号及び分析結果をキュー２３へ出力する。より詳細には、リクエスト処理ブロック２２は、リクエスト信号に含まれるメッセージ片に記述されている文字列を構文解析し、当該文字列に含まれる端末種別情報を抽出し、抽出された端末種別情報に基づいて、当該リクエスト信号に対応する呼に必要な帯域を算出し、算出された帯域を分析結果としてキュー２３へ出力する。なお、リクエスト内容処理部２０Ａは、端末種別情報と必要な帯域とを関連付けた帯域データベース（図示せず）を備え、リクエスト処理ブロック２２が、端末種別情報を用いて帯域データベースを参照することによって必要な帯域を算出する構成であってもよい。
【００５２】
リクエスト内容処理部３０Ａは、信号分析を行うリクエスト処理ブロック３２と、キュー３３と、加入者認証を行うリクエスト処理ブロック３４と、キュー３５と、をシーケンシャルに備えるとともに、加入者情報データベースＤＢ１を備える。すなわち、本具体例に係るリクエスト内容処理部３０Ａは、実施形態に係るリクエスト内容処理部３０からキュー３１、リクエスト処理ブロック３６及びキュー３７を省略するとともに加入者情報データベースＤＢ１を追加した構成である。
【００５３】
リクエスト処理ブロック３２は、リクエスト信号に含まれる信号を分析し、リクエスト信号及び分析結果をキュー３３へ出力する。より詳細には、リクエスト処理ブロック３２は、リクエスト信号に含まれるメッセージ片に記述されている文字列を構文解析し、当該文字列に含まれる加入者ＩＤ（発呼信号を発信した電話端末に固有のＩＤ）を識別子として抽出し、抽出された識別子（加入者ＩＤ）を、分析結果としてキュー３３へ出力する。
【００５４】
リクエスト処理ブロック３４は、キュー３３の先頭に格納されたリクエスト信号及び分析結果を読み出し、分析結果を用いて加入者情報データベースＤＢ１を参照して加入者認証を行い、リクエスト信号及び認証結果をキュー３５へ出力する。より詳細には、加入者情報データベースＤＢ１には、登録された加入者ＩＤが記憶されており、リクエスト処置ブロック３４は、リクエスト処理ブロック３２によって抽出された識別子（加入者ＩＤ）が加入者情報データベースＤＢ１に記憶されているか否かに基づいて認証を行い、認証結果をキュー３５へ出力する。
【００５５】
処理結果出力部５０は、キュー２３，３５に格納されたリクエスト信号、分析結果及び認証結果を読み出し、読み出されたリクエスト信号が同一である処理結果（分析結果及び認証結果）を結合し、結合された処理結果及びリクエスト信号を外部装置へ出力する。
【００５６】
本発明の第一具体例に係るリクエスト処理サーバ１Ａは、「端末種別分析」と「信号分析＋加入者認証」とを同時に行うことができるので、リクエスト内容処理に要する時間を短縮することができる。
【００５７】
＜第二具体例＞
続いて、本発明の第二具体例に係るリクエスト処理サーバについて、図４を参照し、第一具体例に係るリクエスト処理サーバ１Ａとの相違点を中心に説明する。本具体例において、リクエスト処理サーバは、２つのリクエスト内容を並列処理する。１番目のリクエスト内容は、リクエストとして端末種別分析及び帯域予約を含み、２番目のリクエスト内容は、リクエストとして信号分析及び加入者認証を含む。
【００５８】
図４に示すように、本発明の第二具体例に係るリクエスト処理サーバ１Ｂは、機能部として、リクエスト信号取得部１０と、２つのリクエスト内容処理部２０Ｂ，３０Ｂと、処理結果出力部５０と、を備える。
【００５９】
リクエスト内容処理部２０Ｂは、キュー２１と、端末種別分析を行うリクエスト処理ブロック２２と、キュー２３と、帯域予約を行うリクエスト処理ブロック２４と、キュー２５と、をシーケンシャルに備える。すなわち、本具体例に係るリクエスト内容処理部３０Ｂは、実施形態に係るリクエスト内容処理部３０からリクエスト処理ブロック３６及びキュー３７を省略するとともに加入者情報データベースＤＢ１を追加した構成である。
【００６０】
リクエスト処理ブロック２４は、キュー２３の先頭に格納されたリクエスト信号及び分析結果（端末種別）を読み出し、分析結果に基づいて帯域予約を行い（リクエスト信号に対応する発側電話端末及び着側電話端末に対して帯域を割り当て）、リクエスト信号、分析結果及び予約結果をキュー２５へ出力する。
【００６１】
リクエスト内容処理部３０Ｂは、キュー３１と、信号分析を行うリクエスト処理ブロック３２と、キュー３３と、加入者認証を行うリクエスト処理ブロック３４と、キュー３５と、をシーケンシャルに備えるとともに、加入者情報データベースＤＢ１を備える。
【００６２】
処理結果出力部５０は、キュー２５，３５に格納されたリクエスト信号、分析結果、予約結果及び認証結果を読み出し、読み出されたリクエスト信号が同一である処理結果（分析結果、予約結果及び認証結果）を結合し、結合された処理結果及びリクエスト信号を外部装置へ出力する。
【００６３】
本発明の第二具体例に係るリクエスト処理サーバ１Ｂは、「端末種別分析＋帯域予約」と「信号分析＋加入者認証」とを同時に行うことができるので、リクエスト内容処理に要する時間を短縮することができる。
【００６４】
＜第三具体例＞
続いて、本発明の第三具体例に係るリクエスト処理サーバについて、図５を参照し、第二具体例に係るリクエスト処理サーバ１Ｂとの相違点を中心に説明する。本実施形態において、リクエスト処理サーバは、３つのリクエスト内容を並列処理する。１番目のリクエスト内容は、リクエストとして端末種別分析及び帯域予約を含み、２番目のリクエスト内容は、リクエストとして信号分析及び加入者認証を含み、３番目のリクエスト内容は、リクエストとしてＳＤＰチェックを含む。
【００６５】
図５に示すように、本発明の第三具体例に係るリクエスト処理サーバ１Ｃは、機能部として、リクエスト信号取得部１０と、３つのリクエスト内容処理部２０Ｂ，３０Ｂ，４０Ｃと、処理結果出力部５０と、を備える。
【００６６】
リクエスト内容処理部４０Ｃは、キュー４１と、ＳＤＰ（Session Description Protocol）チェックを行うリクエスト処理ブロック４２と、キュー４４と、をシーケンシャルに備えるとともに、ＳＤＰマッチングデータベースＤＢ２を備える。すなわち、本具体例に係るリクエスト内容処理部４０Ｃは、実施形態に係るリクエスト内容処理部４０からリクエスト処理ブロック４３を省略するとともにＳＤＰマッチングデータベースＤＢ２を追加した構成である。
【００６７】
リクエスト処理ブロック４２は、キュー４１の先頭に格納されたリクエスト信号を読み出し、リクエスト信号を用いてＳＤＰマッチングデータベースＤＢ２を参照してＳＤＰチェックを行い、リクエスト信号及びチェック結果をキュー４４へ出力する。ここで、ＳＤＰチェックとは、セッションのセッション情報を記述するプロトコルであるＳＤＰに当該セッションが違反しているか否かをチェックすることを指す。より詳細には、ＳＤＰマッチングデータベースＤＢ２には、リクエスト処理サーバ１Ｃが処理結果及びリクエスト信号の送信先である外部装置のＩＦ条件が外部装置ごとに記憶されており、リクエスト処理ブロック４２は、ＳＩＰ信号であるリクエスト信号に含まれるＳＤＰの内容を用いてＳＤＰマッチングデータベースＤＢを参照し、リクエスト信号に含まれるＳＤＰの送信先である外部装置によって受け入れ可能であるか否かをチェックし、チェック結果が受け入れ可能である場合には、チェック結果をキュー４４へ出力し、チェック結果が受け入れ不可である場合には、チェック結果（エラーレスポンス）をリクエスト信号の送信元である外部装置へ出力する。
【００６８】
処理結果出力部５０は、キュー２５，３５，４４に格納されたリクエスト信号、分析結果、予約結果、認証結果及びチェック結果を読み出し、読み出されたリクエスト信号が同一である処理結果（分析結果、予約結果、認証結果及びチェック結果）を結合し、結合された処理結果及びリクエスト信号を外部装置へ出力する。
【００６９】
本発明の第三具体例に係るリクエスト処理サーバ１Ｃは、「端末種別分析＋帯域予約」と「信号分析＋加入者認証」と「ＳＤＰチェック」とを同時に行うことができるので、リクエスト内容処理に要する時間を短縮することができる。
【００７０】
以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜設計変更可能である。例えば、各リクエスト処理ブロックにおける処理ブロックの数は、２個に限定されず、３個以上であってもよい。
【符号の説明】
【００７１】
１，１Ａ，１Ｂ，１Ｃ  リクエスト処理サーバ
１０    リクエスト信号取得部
２０，２０Ａ，２０Ｂ  リクエスト内容処理部
２２，２４  リクエスト処理ブロック
３０，３０Ａ，３０Ｂ  リクエスト内容処理部
３２，３４，３６  リクエスト処理ブロック
４０，４０Ｃ  リクエスト内容処理部
４２，４３  リクエスト処理ブロック
５０    処理結果出力部
【図１】
0005444165.tif 000002
【図２】
0005444165.tif 000003
【図３】
0005444165.tif 000004
【図４】
0005444165.tif 000005
【図５】
0005444165.tif 000006