(57)【特許請求の範囲】
【請求項１】
一連の処理において種類の異なる複数のプロトコルでそれぞれ送信される複数の信号に同一のキー情報を付与してそれぞれ送信する利用者端末と、
前記複数のプロトコルでそれぞれ送信された前記複数の信号をそれぞれ受信し、受信した前記複数の信号にそれぞれ付与された前記同一のキー情報を用いて前記複数の信号を同一の処理ノードに振り分ける呼制御サーバと、を備え、
前記利用者端末は、プロトコルにおける設定ルールのバージョンに応じて異なる位置に前記同一のキー情報を付与し、
前記呼制御サーバは、プロトコルにおける抽出ルールのバージョンに応じて異なる位置から前記同一のキー情報を抽出する
ことを特徴とする信号振り分けシステム。
【請求項２】
信号振り分けシステムで行う信号振り分け方法において、
利用者端末が、一連の処理において種類の異なる複数のプロトコルでそれぞれ送信される複数の信号に同一のキー情報を付与してそれぞれ送信する送信ステップを行い、
呼制御サーバが、前記複数のプロトコルでそれぞれ送信された前記複数の信号をそれぞれ受信し、受信した前記複数の信号にそれぞれ付与された前記同一のキー情報を用いて前記複数の信号を同一の処理ノードに振り分ける振分ステップを行い、
前記送信ステップでは、プロトコルにおける設定ルールのバージョンに応じて異なる位置に前記同一のキー情報を付与し、
前記振分ステップでは、プロトコルにおける抽出ルールのバージョンに応じて異なる位置から前記同一のキー情報を抽出する
ことを特徴とする信号振り分け方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンシステント・ハッシュ法を用いた分散処理方式で信号を振り分ける技術に関する。
【背景技術】
【０００２】
近年、企業における顧客への対応業務において、Ｗｅｂ技術と連携した方式が登場しつつある。例えば、ＷｅｂＲＴＣ（Web Real-Time Communication）を用いた直接通話による質問対応があり、利用者は、端末上のＷｅｂブラウザから企業のホームページの問い合わせフォームを押下することで、企業のコンタクトセンタへの接続操作を行う。その接続操作が行われると、利用者端末と呼制御サーバとの間で通信用のコネクションが確立される。そして、確立されたコネクション内で呼制御信号による処理が行われ、利用者端末とオペレータ端末との間で接続が完了した時点で通話が可能となる。これらの処理に用いられるプロトコルとしては、例えば、コネクション確立用としてはＷｅｂＳｏｃｋｅｔのＨＴＴＰが用いられ、呼制御用としてはＳＩＰが用いられる。
【０００３】
一方、サーバの処理能力を向上させる技術として、複数のサーバを分散処理行うことにより、単体サーバよりも大きな処理能力を実現するクラスタ化の技術が普及しつつある。非特許文献１，２では、コンシステント・ハッシュ法を用いた分散処理方式を提案している。
【０００４】
この分散処理方式では、クラスタ上の機能ブロックは、図８に示すように、単純振り分け部（Ｂ：Balancer）と、高度振り分け部（Ｄ：Dispatcher）と、処理ノード（Ｐ：Processor）と、データストア（Ｓ：Storage）と、に大別される。利用者端末（Ｃ：Client）からの信号がクラスタに入力されると、まず、単純振り分け部（Ｂ）によっていずれかの高度振り分け部（Ｄ）に振り分けられる。そして、高度振り分け部（Ｄ）では、受信した信号からキー情報を抽出し、そのキー情報から算出されたハッシュ値に基づき該信号を処理する処理ノード（Ｐ）を一意に決定して転送する。その後、処理ノード（Ｐ）は、必要なデータをデータストア（Ｓ）から取得して信号を処理する。このような仕組みを備えることにより、複数の処理ノードで分散処理を行いつつも、同一のキー情報を持つ信号（例えば、通話処理の要求から終話までの一連の処理に用いられる信号）は同じ処理ノード上で処理されることになる。このような分散処理方式は、上述した呼処理システムに用いられている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】入江、外４名、“スケールアウトと柔軟な構成変更を実現するセッション制御サーバのクラスタモデル”、2011年電子情報通信学会総合大会、B-6-11、通信講演論文集２、p.11
【非特許文献２】野口、外２名、“広域ネットワークにおける高可用サーバクラスタ構成方式に関する一検討”、2014年電子情報通信学会総合大会、B-6-104、通信講演論文集２、p.104
【発明の概要】
【発明が解決しようとする課題】
【０００６】
コンタクトセンタの規模が大きくなり、呼処理システムに接続する利用者とイオペレータの数が増加すると、それに伴い高度振り分け部（Ｄ）の処理能力も要求される。ゆえに、高度振り分け部（Ｄ）においてもクラスタ化による処理能力向上が求められるが、その実現には次の課題を解決する必要がある。
【０００７】
コンシステント・ハッシュ法を用いた分散処理方式をＷｅｂと呼処理の連携技術に適用した場合、高度振り分け部（Ｄ）は、コネクション確立用のＨＴＴＰ信号と呼制御用のＳＩＰ信号を同一の処理ノード（Ｐ）に転送する必要がある。しかし、コンシステント・ハッシュ法を用いた分散処理方式では、入力された信号からキー情報を抽出し、そのキー情報のハッシュ値を元に振り分け先の処理ノード（Ｐ）を決定するため、異なるプロトコル間で同一のキー情報を共有し、適切に抽出する仕組みを確立する必要がある（図９参照）。
【０００８】
本発明は、上記事情を鑑みてなされたものであり、コンシステント・ハッシュ法を用いて異なるプロトコルに係る信号を振り分ける呼制御サーバ（高度振り分け部（Ｄ））において、該信号を振り分ける処理能力を改善することを目的とする。
【課題を解決するための手段】
【０００９】
以上の課題を解決するため、請求項１に係る信号振り分けシステムは、一連の処理において種類の異なる複数のプロトコルでそれぞれ送信される複数の信号に同一のキー情報を付与してそれぞれ送信する利用者端末と、前記複数のプロトコルでそれぞれ送信された前記複数の信号をそれぞれ受信し、受信した前記複数の信号にそれぞれ付与された前記同一のキー情報を用いて前記複数の信号を同一の処理ノードに振り分ける呼制御サーバと、を備え、前記利用者端末は、プロトコルにおける設定ルールのバージョンに応じて異なる位置に前記同一のキー情報を付与し、前記呼制御サーバは、プロトコルにおける抽出ルールのバージョンに応じて異なる位置から前記同一のキー情報を抽出することを要旨とする。
【００１０】
請求項２に係る信号振り分け方法は、信号振り分けシステムで行う信号振り分け方法において、利用者端末が、一連の処理において種類の異なる複数のプロトコルでそれぞれ送信される複数の信号に同一のキー情報を付与してそれぞれ送信する送信ステップを行い、呼制御サーバが、前記複数のプロトコルでそれぞれ送信された前記複数の信号をそれぞれ受信し、受信した前記複数の信号にそれぞれ付与された前記同一のキー情報を用いて前記複数の信号を同一の処理ノードに振り分ける振分ステップを行い、前記送信ステップでは、プロトコルにおける設定ルールのバージョンに応じて異なる位置に前記同一のキー情報を付与し、前記振分ステップでは、プロトコルにおける抽出ルールのバージョンに応じて異なる位置から前記同一のキー情報を抽出することを要旨とする。
【発明の効果】
【００１１】
本発明によれば、コンシステント・ハッシュ法を用いて異なるプロトコルに係る信号を振り分ける呼制御サーバ（高度振り分け部（Ｄ））において、該信号を振り分ける処理能力を向上できる。
【図面の簡単な説明】
【００１２】
【図１】本発明の概要を示す図である。
【図２】呼制御システムの全体構成を示す図である。
【図３】利用者端末の機能ブロック構成を示す図である。
【図４】呼制御サーバの機能ブロック構成を示す図である。
【図５】ＨＴＴＰによるコネクション確立時の処理動作を示す図である。
【図６】ＳＩＰによる呼確立時の処理動作を示す図である。
【図７】ＳＩＰによる呼確立時の処理動作を示す図である。
【図８】コンシステント・ハッシュ法を用いた分散処理方式のクラスタ上の機能ブロックを示す図である。
【図９】課題説明時の参照図である。
【発明を実施するための形態】
【００１３】
本発明は、異なる複数のプロトコルに跨って同一のキー情報をそれぞれ付与し、該複数のプロトコルからそれぞれ取得した該同一のキー情報を用いて同一の処理ノードに転送することを特徴とする。以下、本発明を実施する一実施の形態について図面を用いて説明する。
【００１４】
本実施の形態では、Ｗｅｂ技術を用いてコネクションを設定し、そのコネクションを用いてＳＩＰによる呼制御によって通話コネクションを確立する一連のサービスにおいて、図１に示すように、利用者端末（Ｃ：Client）１０が、ＷｅｂＲＴＣの処理上でＨＴＴＰとＳＩＰでそれぞれ送信されるデータ信号と呼制御信号に同一のキー情報を付与してそれぞれ送信し、呼制御サーバ（高度振り分け部（Ｄ））３０が、利用者端末１０からの各信号にそれぞれ付与されたキー情報（同一のキー情報）を用いて該各信号を同一の処理ノードに振り分ける。以下詳述する。
【００１５】
図２は、本実施の形態に係る呼制御システムの全体構成を示す図である。この呼制御システム１（信号振り分けシステム）は、複数の利用者がそれぞれ利用する複数の利用者端末１０と、複数の利用者端末１０からそれぞれ送信された複数の信号を分散処理する複数の呼制御サーバ３０と、利用者端末１０からの信号をいずれかの呼制御サーバ３０に振り分けるセッション制御サーバ５０と、を備えて構成される。本実施の形態において、信号とは、ＷｅｂＲＴＣに係る信号であり、ＨＴＴＰで送信されるデータ信号、ＳＩＰで送信される呼制御信号を指す。
【００１６】
該呼制御システム１は、コンシステント・ハッシュ法の分散処理方式を用いて信号の処理負荷を分散する。該分散処理方式は、背景技術で説明した通り、信号をランダムにいずれかの高度振り分け部（Ｄ）に単純に振り分ける単純振り分け部（Ｂ）と、信号からキー情報を抽出してそのハッシュ値を元に該信号を同一の処理ノード（Ｐ）及びデータストア（Ｓ）に振り分ける高度振り分け部（Ｄ）と、振り分けられた信号を処理する処理ノード（Ｐ）と、信号の処理に必要なデータを記憶するデータストア（Ｓ）と、で構成される。
【００１７】
本実施の形態では、セッション制御サーバ５０が単純振り分け部（Ｂ）として機能し、呼制御サーバ３０が高度振り分け部（Ｄ）と処理ノード（Ｐ）とデータストア（Ｓ）として機能する。なお、本発明では、高度振り分け部（Ｄ）と利用者端末１０に特徴があるため、セッション制御サーバ５０の説明は省略する。
【００１８】
まず、利用者端末１０の機能について説明する。図３は、利用者端末１０の機能ブロック構成を示す図である。利用者端末１０は、ＳｅｓｓｉｏｎＩＤ生成部１１０ａと信号生成部１１０ｂとを備えたアプリケーション１１０と、データ受付部１２０ａとＫｅｙ変換部１２０ｂと信号送信部１２０ｃとを備えたＫｅｙ変換機能１２０と、を備えて構成される。
【００１９】
ＳｅｓｓｉｏｎＩＤ生成部１１０ａは、ＨＴＴＰとＳＩＰとの間で共通する同一のキー情報を生成する機能を備えて構成される。本実施の形態では、キー情報の例として、ＷｅｂＲＴＣの処理のセッションを識別するためのＳｅｓｓｉｏｎＩＤを生成する。
【００２０】
信号生成部１１０ｂは、ＷｅｂＲＴＣの処理を行うにあたり、利用者端末１０が呼制御サーバ３０に送信するための送信信号をプロトコルの種類に応じて生成する機能を生成する。詳細には、利用者端末１０が呼制御サーバ３０との間でＷｅｂＳｏｃｋｅｔを確立する際にはＨＴＴＰのデータ信号を生成し、その後に呼制御サーバ３０を介してオペレータ端末（不図示）との間で呼を確立する際にはＳＩＰの呼制御信号を生成する。
【００２１】
データ受付部１２０ａは、アプリケーション１１０から、キー情報（ＳｅｓｓｉｏｎＩＤ）と、呼制御サーバ３０への送信信号（ＨＴＴＰのデータ信号又はＳＩＰの呼制御信号）と、を受信する機能を備えて構成される。
【００２２】
Ｋｅｙ変換部１２０ｂは、キー情報を送信プロトコルに設定するための設定ルールをプロトコルの種類毎に保持し、データ受付部１２０ａで受け付けたキー情報（ＳｅｓｓｉｏｎＩＤ）を送信信号のプロトコルに応じた設定ルールで変換する機能を備えて構成される。つまり、送信プロトコルの種類に応じてキー情報（ＳｅｓｓｉｏｎＩＤ）のデータ通信形式を変換する。
【００２３】
信号送信部１２０ｃは、データ受付部１２０ａで受け付けた送信信号に、Ｋｅｙ変換部１２０ｂで変換したキー情報（ＳｅｓｓｉｏｎＩＤ）を付与して呼制御サーバ３０に送信する機能を備えて構成される。
【００２４】
続いて、呼制御サーバ３０の高度振り分け部（Ｄ）の機能について説明する。図４は、呼制御サーバ３０の高度振り分け部（Ｄ）の機能ブロック構成を示す図である。呼制御サーバ３０（高度振り分け部（Ｄ））は、ハッシュ計算部３１０ａと信号振分部３１０ｂとを備えたアプリケーション３１０と、信号受信部３２０ａと信号判定部３２０ｂとＫｅｙ抽出部３２０ｃとデータ送信部３２０ｄとを備えたＫｅｙ抽出機能３２０と、を備えて構成される。以下、Ｋｅｙ抽出機能３２０の信号受信部３２０ａから順に説明する。
【００２５】
信号受信部３２０ａは、利用者端末１０からの信号（キー情報が付与されたＨＴＴＰのデータ信号又はＳＩＰの呼制御信号）を受信する機能を備えて構成される。
【００２６】
信号判定部３２０ｂは、信号受信部３２０ａで受信した受信信号（キー情報が付与されたＨＴＴＰのデータ信号又はＳＩＰの呼制御信号）のプロトコルの種類を判定する機能を備えて構成される。
【００２７】
Ｋｅｙ抽出部３２０ｃは、受信信号からキー情報を抽出するための抽出ルールをプロトコルの種類毎に保持し、信号判定部３２０ｂで判定したプロトコルに応じた抽出ルールで受信信号からキー情報（ＳｅｓｓｉｏｎＩＤ）を抽出する機能を備えて構成される。
【００２８】
データ送信部３２０ｄは、キー情報（ＳｅｓｓｉｏｎＩＤ）が抽出された受信信号と、Ｋｅｙ抽出部３２０ｃで抽出したキー情報（ＳｅｓｓｉｏｎＩＤ）とを関連付けてアプリケーション３１０に送信する機能を備えて構成される。
【００２９】
ハッシュ計算部３１０ａは、Ｋｅｙ抽出機能３２０から送信されたキー情報（ＳｅｓｓｉｏｎＩＤ）のハッシュ値を計算する機能を備えて構成される。
【００３０】
信号振分部３１０ｂは、ハッシュ計算部３１０ａで計算したキー情報（ＳｅｓｓｉｏｎＩＤ）のハッシュ値を元に、同一のハッシュ値に係る信号（ＨＴＴＰのデータ信号又はＳＩＰの呼制御信号）を同じ処理ノード（Ｐ）に振り分ける機能を備えて構成される。
【００３１】
次に、呼制御システム１の動作について説明する。ここでは、ＷｅｂＲＴＣにより通話する際の動作例について説明する。
【００３２】
最初に、図５を参照しながら、利用者端末１０と呼制御サーバ３０との間でＨＴＴＰによるコネクション確立時の処理動作について説明する。
【００３３】
まず、利用者端末１０では、アプリケーション１１０が、呼制御サーバ３０との間でＷｅｂＳｏｃｋｅｔを確立するため、その確立に係るＨＴＴＰのデータ信号を生成し、該データ信号に対応する一意のキー情報（ＳｅｓｓｉｏｎＩＤ；オリジナルキー情報）を更に生成する（ステップＳ１０１）。
【００３４】
続いて、アプリケーション１１０は、生成したデータ信号及びキー情報を、該データ信号がＨＴＴＰで送信されることを示す送信プロトコル情報と共にＫｅｙ変換機能１２０に送信する（ステップＳ１０２）。
【００３５】
次に、Ｋｅｙ変換機能１２０は、送信プロトコル情報（ＨＴＴＰ）に対応するＫｅｙ変換部１２０ｂの設定ルールを用いて、キー情報をＨＴＴＰで利用可能な通信形式に変換する（ステップＳ１０３）。
【００３６】
その後、Ｋｅｙ変換機能１２０は、データ信号に、ステップＳ１０３で変換したキー情報を付与して呼制御サーバ３０に送信する（ステップＳ１０４）。
【００３７】
ここまでの処理において、例えば、キー情報が「１１」、ＨＴＴＰに対応するＫｅｙ変換部１２０ｂの設定ルールが「ｘ−ｋｅｙに設定」の場合、変換後のキー情報「ｘ−ｋｅｙ（１１）」を含むデータ信号がＨＴＴＰで送信される。
【００３８】
続いて、呼制御サーバ３０では、Ｋｅｙ抽出機能３２０が、利用者端末１０からのデータ信号を受信し（ステップＳ１０５）、該データ信号のプロトコルの種類がＨＴＴＰであることを特定する（ステップＳ１０６）。
【００３９】
次に、Ｋｅｙ抽出機能３２０は、特定したＨＴＴＰに対応するＫｅｙ抽出部３２０ｃの抽出ルールを用いて、データ信号からキー情報を抽出する（ステップＳ１０７）。
【００４０】
ここで、Ｋｅｙ抽出部３２０ｃの抽出ルールは、Ｋｅｙ変換部１２０ｂの設定ルールと対の関係にある。例えば、ＨＴＴＰに対応するＫｅｙ変換部１２０ｂの設定ルールが「ｘ−ｋｅｙに設定」の場合、同じプロトコルに対応するＫｅｙ抽出部３２０ｃの抽出ルールには「ｘ−ｋｅｙから抽出」が設定される。そのため、上記例の場合、変換後のキー情報「ｘ−ｋｅｙ（１１）」からオリジナルのキー情報「１１」が抽出される。
【００４１】
続いて、アプリケーション３１０は、抽出したキー情報のハッシュ値を計算し、コンシステント・ハッシュ法に基づきキー情報抽出後のデータ信号を所定の処理ノード（Ｐ）に振り分けて送信する（ステップＳ１０８）。その後、利用者端末１０と振り分け先の処理ノード（Ｐ）との間でコネクションが確立する。なお、ステップＳ１０８の際、キー情報又はキー情報のハッシュ値と、振り分け先の処理ノード（Ｐ）のＩＤとを関連付けて保持しておいてもよい。
【００４２】
次に、図６を参照しながら、利用者端末１０と呼制御サーバ３０との間でＳＩＰによる呼確立時の処理動作について説明する。この処理は、ＨＴＴＰでのコネクション確立後に引き続き行われる。
【００４３】
まず、利用者端末１０では、アプリケーション１１０が、ＨＴＴＰによるコネクション確立時に生成していたキー情報（ＳｅｓｓｉｏｎＩＤ）に関連付けてＳＩＰの呼制御信号を生成する（ステップＳ２０１）。
【００４４】
続いて、アプリケーション１１０は、生成した呼制御信号及びキー情報を、該呼制御信号がＳＩＰで送信されることを示す送信プロトコル情報と共にＫｅｙ変換機能１２０に送信する（ステップＳ２０２）。
【００４５】
次に、Ｋｅｙ変換機能１２０は、送信プロトコル情報（ＳＩＰ）に対応するＫｅｙ変換部１２０ｂの設定ルールを用いて、キー情報をＳＩＰで利用可能な通信形式に変換する（ステップＳ２０３）。
【００４６】
その後、Ｋｅｙ変換機能１２０は、呼制御信号に、ステップＳ２０３で変換したキー情報を付与して呼制御サーバ３０に送信する（ステップＳ２０４）。
【００４７】
ここまでの処理において、例えば、キー情報が「１１」、ＳＩＰに対応するＫｅｙ変換部１２０ｂの設定ルールが「Ｃａｌｌ−ＩＤに“ｋｅｙ＠ｄｏｍ”で設定」の場合、変換後のキー情報「ｃａｌｌ−ｉｄ（１１ａａａ＠ｄｏｍ）」を含む呼制御信号がＳＩＰで送信される。なお、「ａａａ＠ｄｏｍ」は、Ｃａｌｌ−ＩＤの設定情報である。
【００４８】
続いて、呼制御サーバ３０では、Ｋｅｙ抽出機能３２０が、利用者端末１０からの呼制御信号を受信し（ステップＳ２０５）、該呼制御信号のプロトコルの種類がＳＩＰであることを特定する（ステップＳ２０６）。
【００４９】
次に、Ｋｅｙ抽出機能３２０は、特定したＳＩＰに対応するＫｅｙ抽出部３２０ｃの抽出ルールを用いて、呼制御信号からキー情報を抽出する（ステップＳ２０７）。
【００５０】
ここで、Ｋｅｙ抽出部３２０ｃの抽出ルールは、上述した通り、Ｋｅｙ変換部１２０ｂの設定ルールと対の関係にある。例えば、ＳＩＰに対応するＫｅｙ変換部１２０ｂの設定ルールが「Ｃａｌｌ−ＩＤに“ｋｅｙ＠ｄｏｍ”で設定」の場合、同じプロトコルに対応するＫｅｙ抽出部３２０ｃの抽出ルールには「Ｃａｌｌ−ＩＤから抽出」が設定される。そのため、上記例の場合、変換後のキー情報「ｃａｌｌ−ｉｄ（１１ａａａ＠ｄｏｍ）」からオリジナルのキー情報「１１」が抽出される。
【００５１】
続いて、アプリケーション３１０は、抽出したキー情報のハッシュ値を計算し、コンシステント・ハッシュ法に基づきキー情報抽出後の呼制御信号を所定の処理ノード（Ｐ）に振り分けて送信する（ステップＳ２０８）。
【００５２】
ここでは、キー情報のハッシュ値がステップＳ１０８で計算されたハッシュ値と同じ値になるため、コンシステント・ハッシュ法に基づき、キー情報抽出後の呼制御信号は同一の処理ノード（Ｐ）に振り分けられることになる。その後、利用者端末１０と振り分け先の処理ノード（Ｐ）との間で呼処理が行われる。
【００５３】
ここまで、プロトコルの種類毎に１つの設定ルール及び抽出ルールが設けられている場合について説明した。
【００５４】
次に、プロトコルの種類毎に複数の設定ルール及び抽出ルールを設ける場合について説明する。この場合、Ｋｅｙ変換部１２０ｂは、所定のプロトコルに対する複数の設定ルールにバージョン情報を付与して管理し、信号送信部１２０ｃは、キー情報の変換に用いた設定ルールのバージョン情報を送信信号（ＨＴＴＰ信号又はＳＩＰ信号）に更に付与して呼制御サーバ３０に送信する。また、Ｋｅｙ抽出部３２０ｃも同様にバージョン情報を用いて抽出ルールを管理し、利用者端末１０からの受信信号にバージョン情報が付与されている場合、送信プロトコルの種類と該バージョン情報に対応する抽出ルールを用いて受信信号からキー情報を抽出する。
【００５５】
引き続き、プロトコルの種類毎に複数の設定ルール及び抽出ルールが設けられた場合について、図７を参照しながら、ＳＩＰによる呼確立時の処理動作を例に説明する。
【００５６】
まず、利用者端末１０では、アプリケーション１１０が、ＨＴＴＰによるコネクション確立時に生成していたキー情報（ＳｅｓｓｉｏｎＩＤ）に関連付けてＳＩＰの呼制御信号を生成する（ステップＳ３０１）。
【００５７】
続いて、アプリケーション１１０は、生成した呼制御信号及びキー情報を、該呼制御信号がＳＩＰで送信されることを示す送信プロトコル情報と共にＫｅｙ変換機能１２０に送信する（ステップＳ３０２）。
【００５８】
次に、Ｋｅｙ変換機能１２０は、送信プロトコル情報（ＳＩＰ）に対応するＫｅｙ変換部１２０ｂの設定ルールを用いて、キー情報をＳＩＰで利用可能な通信形式に変換する（ステップＳ３０３）。
【００５９】
その後、Ｋｅｙ変換機能１２０は、呼制御信号に、ステップＳ３０３で変換したキー情報と、キー情報の変換に用いた設定ルールのバージョン情報とを付与して呼制御サーバ３０に送信する（ステップＳ３０４）。
【００６０】
ここまでの処理において、例えば、キー情報が「１１」、ＳＩＰに対応するＫｅｙ変換部１２０ｂの設定ルールが「Ｃａｌｌ−ＩＤに“ｋｅｙ＠ｄｏｍ”で設定」、該設定ルールのバージョンが「１」の場合、変換後のキー情報「ｃａｌｌ−ｉｄ（１１ａａａ＠ｄｏｍ），ｖｅｒｓｉｏｎ（１）」を含む呼制御信号がＳＩＰで送信される。
【００６１】
続いて、呼制御サーバ３０では、Ｋｅｙ抽出機能３２０が、利用者端末１０からの呼制御信号を受信し（ステップＳ３０５）、該呼制御信号のプロトコルの種類がＳＩＰであり、キー情報の変換に用いた設定ルールのバージョン情報が「１」であることを特定する（ステップＳ３０６）。
【００６２】
次に、Ｋｅｙ抽出機能３２０は、特定したＳＩＰ及びバージョン情報「１」に対応するＫｅｙ抽出部３２０ｃの抽出ルールを用いて、呼制御信号からキー情報を抽出する（ステップＳ３０７）。
【００６３】
ここで、Ｋｅｙ抽出部３２０ｃの抽出ルールは、Ｋｅｙ変換部１２０ｂの設定ルールとバージョン毎に対の関係にある。例えば、ＳＩＰに対応するバージョン「１」の設定ルールが「Ｃａｌｌ−ＩＤに“ｋｅｙ＠ｄｏｍ”で設定」の場合、同じプロトコルに対応するバージョン「１」の抽出ルールには「Ｃａｌｌ−ＩＤから抽出」が設定される。そのため、上記例の場合、変換後のキー情報「ｃａｌｌ−ｉｄ（１１ａａａ＠ｄｏｍ），ｖｅｒｓｉｏｎ（１）」からオリジナルのキー情報「１１」が抽出される。
【００６４】
続いて、アプリケーション３１０は、抽出したキー情報のハッシュ値を計算し、コンシステント・ハッシュ法に基づきキー情報抽出後の呼制御信号を所定の処理ノード（Ｐ）に振り分けて送信する（ステップＳ３０８）。
【００６５】
ここまで、本実施の形態に係る機能及び動作について説明した。
【００６６】
次に、本発明における理想的な実施例を説明する。
【００６７】
ステップＳ４０１）  まず、利用者端末１０のアプリケーション１１０から呼制御サーバ３０に対してＷｅｂＳｏｃｋｅｔを確立する際に、そのアプリケーション１１０内で一意となるＳｅｓｓｉｏｎＩＤを生成する。そして、ＷｅｂＳｏｃｋｅｔ用のデータ信号を作成した後に、該データ信号とＳｅｓｓｉｏｎＩＤをＫｅｙ変換機能１２０に渡す。
【００６８】
ステップＳ４０２）  続いて、Ｋｅｙ変換機能１２０内でＳｅｓｓｉｏｎＩＤをＫｅｙ変換部１２０ｂに入力して変換後のＳｅｓｓｉｏｎＩＤ（以下、ＨＴＴＰ変換ｋｅｙ）を生成する。その後、生成したＨＴＴＰ変換ｋｅｙをデータ信号の独自ヘッダ（ｘ−ｋｅｙヘッダ）に付与して呼制御サーバ３０に送信する。例えば、ＳｅｓｓｉｏｎＩＤが“ＡＢＣ１２３”場合、ＨＴＴＰ変換ｋｅｙは“ＡＢＣ１２３．ｓｅｓｓｉｏｎ”となる。
【００６９】
ステップＳ４０３）  一方、呼制御サーバ３０では、信号判定部３２０ｂが、受信したデータ信号がＨＴＴＰかＳＩＰかを判定する。該判定の方法は様々であるが、送信先のポート番号や信号上の特定の文字列を判別する方法等が考えられる。例えば、ＨＴＴＰの信号であれば、信号内に含まれる“ＨＴＴＰ”という文字列により判別する。
【００７０】
ステップＳ４０４）  その後、データ信号のプロトコルの種類を判定の結果、ＨＴＴＰであれば、該データ信号と判別したプロトコルの種類を入力情報としてＫｅｙ抽出部３２０ｃに渡し、該データ信号からオリジナルキー情報（ＳｅｓｓｉｏｎＩＤ）を抽出してアプリケーション３１０に返却する。アプリケーション３１０は、返却されたオリジナルキー情報を元にハッシュ値を生成して振り分け先の処理ノード（Ｐ）を決定する。
【００７１】
ステップＳ４０５）  データ信号を受信した振り分け先の処理ノード（Ｐ）は、該データ信号が正しく解釈できた場合は正常応答を返却し、利用者端末１０のアプリケーション１１０と処理ノード（Ｐ）との間でＷｅｂＳｏｃｋｅｔを確立する。
【００７２】
ステップＳ４０６）  ＷｅｂＳｏｃｋｅｔが確立された後、利用者端末１０のアプリケーション１１０は、呼制御サーバ３０に対してＳＩＰによる発信動作を行う。その際、ＳＩＰ用の呼制御信号を生成した後に、該呼制御信号とステップＳ４０１で生成したＳｅｓｓｉｏｎＩＤとをＫｅｙ変換機能１２０に渡す。
【００７３】
ステップＳ４０７）  続いて、Ｋｅｙ変換機能１２０内でＳｅｓｓｉｏｎＩＤをＫｅｙ変換部１２０ｂに入力して変換後のＳｅｓｓｉｏｎＩＤ（以下、ＳＩＰ変換ｋｅｙ）を生成する。その後、生成したＳＩＰ変換ｋｅｙを呼制御信号のヘッダに付与して呼制御サーバ３０に送信する。例えば、ＳｅｓｓｉｏｎＩＤが“ＡＢＣ１２３”場合、ＳＩＰ変換ｋｅｙは“ＡＢＣ１２３＠ｃａｌｌ１”となる。付与するヘッダは、同一の呼（ＳＩＰダイアログ）であれば必ず一意の値が付与されるＳＩＰヘッダ（例えば、Ｃａｌｌ−ＩＤヘッダ）に記述する。
【００７４】
ステップＳ４０８）  呼制御サーバ３０からの呼制御信号は、ステップＳ４０３と同様、呼制御サーバ３０において、信号判定部３２０ｂが、受信した呼制御信号がＨＴＴＰかＳＩＰかを判定する。判定の方法は様々であるが、送信先のポート番号や信号上の特定の文字列を判別する方法等が考えられる。例えば、ＳＩＰの信号であれば、信号上の１行目に含められた“ＳＩＰ”という文字列により判別する。
【００７５】
ステップＳ４０９）  その後、呼制御信号のプロトコルの種類を判定の結果、ＳＩＰであれば、該呼制御信号と判別したプロトコルの種類を入力情報としてＫｅｙ抽出部３２０ｃに渡し、該呼制御信号からオリジナルキー情報（ＳｅｓｓｉｏｎＩＤ）を抽出してアプリケーション３１０に返却する。アプリケーション３１０は、返却されたオリジナルキー情報を元にハッシュ値を生成して振り分け先の処理ノード（Ｐ）を決定する。
【００７６】
ステップＳ４１０）  呼制御信号を受信した振り分け先の処理ノード（Ｐ）は、該呼制御信号が正しく解釈できた場合は正常応答を返却し、利用者端末１０のアプリケーション１１０と処理ノード（Ｐ）との間で呼制御を実施する。
【００７７】
以上より、本実施の形態によれば、利用者端末１０は、ＷｅｂＲＴＣの処理においてＨＴＴＰとＳＩＰでそれぞれ送信されるデータ信号と呼制御信号に同一のキー情報を付与してそれぞれ送信し、呼制御サーバ３０（高度振り分け部（Ｄ））は、受信したデータ信号と呼制御信号にそれぞれ付与されたキー情報（同一のキー情報）を用いて該データ信号と該呼制御信号を同一の処理ノード（Ｐ）に振り分けるので、コンシステント・ハッシュ法を用いた分散処理を用いたクラスタ上でＷｅｂＲＴＣを用いたコンタクトセンタサービスで用いられる呼制御サーバを構築でき、呼制御サーバ（高度振り分け部（Ｄ））で信号を振り分ける処理能力を向上することができる。
【００７８】
最後に、本実施の形態で説明した利用者端末１０及び呼制御サーバ３０は、ＣＰＵ、メモリ、ハードディスク等を備えたコンピュータで実現できる。また、利用者端末１０及び呼制御サーバ３０としてコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。
【符号の説明】
【００７９】
１…呼制御システム（信号振り分けシステム）
１０…利用者端末
１１０…アプリケーション
１１０ａ…ＳｅｓｓｉｏｎＩＤ生成部
１１０ｂ…信号生成部
１２０…Ｋｅｙ変換機能
１２０ａ…データ受付部
１２０ｂ…Ｋｅｙ変換部
１２０ｃ…信号送信部
３０…呼制御サーバ
３１０…アプリケーション
３１０ａ…ハッシュ計算部
３１０ｂ…信号振分部
３２０…Ｋｅｙ抽出機能
３２０ａ…信号受信部
３２０ｂ…信号判定部
３２０ｃ…Ｋｅｙ抽出部
３２０ｄ…データ送信部
５０…セッション制御サーバ
Ｓ１０１〜Ｓ１０８、Ｓ２０１〜Ｓ２０８、Ｓ３０１〜Ｓ３０８、Ｓ４０１〜Ｓ４１０…ステップ
【図１】
0006529180.tif 000002
【図２】
0006529180.tif 000003
【図３】
0006529180.tif 000004
【図４】
0006529180.tif 000005
【図５】
0006529180.tif 000006
【図６】
0006529180.tif 000007
【図７】
0006529180.tif 000008
【図８】
0006529180.tif 000009
【図９】
0006529180.tif 000010