JP2014235643A - セッション・ボーダ・コントローラのクラスタシステム、アプリケーション・サーバのクラスタシステム、および、そのｓｉｐダイアログ生成方法 - Google Patents

Abstract

【課題】ＳＩＰネットワークに於いて関連するＳＩＰダイアログのＳＩＰ信号を一元的に処理する。
【解決手段】クラスタシステム１は、ＳＩＰダイアログを処理する複数のセッション・ボーダ・コントローラ２と、振分装置３とを備えている。振分装置３は、これらＳＩＰダイアログの識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部３２と、ハッシュ値に基づき複数のセッション・ボーダ・コントローラ２のいずれかに、このＳＩＰ信号を振り分けるＬ７スイッチ部３１を有する。各セッション・ボーダ・コントローラ２は、第１のＳＩＰダイアログが含む第１識別子とは異なり、かつ、第１識別子の第１ハッシュ値と同一の値がハッシュ演算される第２識別子を算出する識別子算出部２１と、第１のＳＩＰダイアログに関連して、第２識別子を含む第２のＳＩＰダイアログを新たに生成するセッション・ボーダ・コントローラ処理部２３とを備える。
【選択図】図１

Description

本発明は、複数のＳＩＰ（Session Initiation Protocol）ダイアログを関連づけて処理するセッション・ボーダ・コントローラ（ＳＢＣ：Session Border Controller）のクラスタシステム、アプリケーション・サーバ（ＡＳ：Application Server）のクラスタシステム、および、これらクラスタシステムのＳＩＰダイアログ生成方法に関する。

クラスタ技術とは、複数の物理マシンまたは仮想マシンを用いて分散処理を行う技術である。このクラスタ技術によってリクエストを分散処理するためには、分散処理を行う複数の物理マシンや仮想マシンの前段で、リクエストのトラヒックを振り分ける必要がある。リクエストのトラヒックを振り分ける振分装置と、このリクエストを分散処理する複数の物理マシンや仮想マシンとは、クラスタシステムを構成する。

ＨＴＴＰ（Hypertext Transfer Protocol）サーバに対するリクエストは、一般的に、その送信元の端末ごとにＩＰ（Internet Protocol）アドレスが異なっている。そのため、ＨＴＴＰサーバのクラスタシステムは、リクエストのトラヒックを振り分ける際に、その送信元ＩＰアドレスを鍵として振り分けることができる。よって、レイヤ４スイッチまたはレイヤ３スイッチを、リクエストのトラヒックを振り分ける振分装置として使用することができる。

ＳＩＰサーバに対するリクエストは、ネットワーク内の中継サーバを経由する場合もある。これら中継サーバによって送信元ＩＰアドレスが書き換えられるので、ＳＩＰサーバのクラスタシステムでは、ＳＩＰリクエストを、その送信元ＩＰアドレスを鍵として振り分けることができないという問題がある。そこで、ＳＩＰサーバのクラスタシステムでは、ＳＩＰリクエストを、そのセッションの識別子を鍵として振り分けを行う方式が提案されている。例えば、特許文献１の段落０００２には、「振分装置３は、端末（クライアント）からセッション接続要求などのメッセージを受信すると、そのメッセージに含まれるセッション制御用のデータを分析し、メッセージを所定の方法に従って、処理装置に振り分ける。」と記載されている。

セッション・ボーダ・コントローラは、Ｂ２ＢＵＡ（Back-to-Back User Agent）処理を行い、発側のＳＩＰユーザ・エージェントとの間でＳＩＰダイアログを保持し、着側のＳＩＰユーザ・エージェントとの間でＳＩＰダイアログを保持するものである。
ここでＳＩＰダイアログとは、２つのＳＩＰユーザ・エージェントの間や、サーバとＳＩＰユーザ・エージェントとの間で保持される関係のことをいう。ここでサーバとは、例えば、セッション・ボーダ・コントローラや、アプリケーション・サーバなどである。ＳＩＰダイアログは、INVITEリクエストによって生成され、200 OKレスポンスにより確立する。ＳＩＰダイアログを一意に識別する識別子は、Call-IDヘッダである。
このとき、発側のＳＩＰダイアログと着側のＳＩＰダイアログとは、異なる場合がある。この場合、セキュリティ上などの理由により、着側のＳＩＰダイアログのセッション識別子（Call-ID）は、発側のＳＩＰダイアログのセッション識別子とは異なる値が設定される。

アプリケーション・サーバでは、フォーキング、フォローミー、転送などのサービスに於いても、発側のＳＩＰダイアログと異なる着側のＳＩＰダイアログを生成する場合がある。この場合も、各ダイアログのセッション識別子は、それぞれ異なる値が設定される。

セッション・ボーダ・コントローラやアプリケーション・サーバでは、関連するダイアログのＳＩＰ信号を一元的に処理しなければ適切なサービスを提供できない。よって、ＳＩＰ信号のセッション識別子を単純に用いるだけでは、セッション・ボーダ・コントローラやアプリケーション・サーバのクラスタシステムを構成し、適切な分散処理を実現することができない。
このため、ＳＩＰ信号中のRecord-RouteヘッダやContactヘッダなどに、識別子の文字列を埋め込む技術や、識別子の文字列を示す独自パラメータを追加する技術が提案されている。

非特許文献１のアプリケーション構成モデルの章には「たとえば、Request-URIヘッダで指定されているユーザを調べ、ユーザのサブスクリプション・レベルに基づいてアプリケーションを選択するようなコンポーザ・アプリケーションが考えられます。その後、このコンポーザ・アプリケーションは1つまたは複数のRouteヘッダをリクエストに挿入します。このとき、それぞれのRouteヘッダで、リクエストを処理すべきデプロイ済みＳＩＰアプリケーションの名前と場所を指定します。」と記載されている。すなわち、非特許文献１の技術に於いて、セッション識別子は、ＳＩＰ信号のRecord-Routeヘッダ中のSIP-URI（Uniform Resource Identifier）のuser部に記載される。ＳＩＰサーブレットは、ＳＩＰ信号を受信した際、このＳＩＰ信号のRecord-Routeヘッダ中に記載されているセッション識別子を読み取り、これを鍵として物理マシンまたは仮想マシンに振り分ける。

特開２０１２−２５２５４５号公報

BEA Systems、「Web Logic SIP ServerによるSIPサーブレットの開発」、［online］、［平成２５年５月８日検索］、インターネット<ＵＲＬ：http://otndnld.oracle.co.jp/document/products/wlcp/wlss21/programming/composition.html>

非特許文献１に記載された技術に於いて、ＳＩＰ信号は、エンド・ツー・エンドで送受信される間に、セッション・ボーダ・コントローラなどに代表されるＳＩＰサーバを経由する。これらＳＩＰサーバは、ＳＩＰ信号に独自に挿入された文字列を削除するおそれがある。よって、ＳＩＰ信号中に独自に挿入された文字列は、クラスタシステムの振分装置３が振り分ける鍵として利用できないという問題がある。
例えば、ＳＩＰ信号中のRecord-RouteヘッダのSIP-URIのuser部に、識別子として用いる文字列を独自パラメータとして挿入した場合を検討する。Record-RouteヘッダのSIP-URIのuser部は、ＳＩＰのルーティングに必須のパラメータではなく、他のセッション・ボーダ・コントローラによって削除される可能性がある。

次に、発側セッション・ボーダ・コントローラが着側セッション・ボーダ・コントローラに送信するＳＩＰ信号のContactヘッダに、識別子として用いる文字列を独自パラメータとして埋め込んだ場合を検討する。このＳＩＰ信号のContactヘッダに独自に埋め込まれた文字列は、このＳＩＰ信号が経由する他のセッション・ボーダ・コントローラによって削除されるおそれがある。
着側セッション・ボーダ・コントローラは、このＳＩＰ信号に応答する新たなＳＩＰ信号を、発側セッション・ボーダ・コントローラに送信する。当該他のセッション・ボーダ・コントローラは、この新たなＳＩＰ信号のContactヘッダに対して、識別子として用いる文字列を追加すればよいが、このような動作は行わない。

次に、発側セッション・ボーダ・コントローラが着側セッション・ボーダ・コントローラに送信するＳＩＰ信号に独自ヘッダを設け、識別子として用いる文字列をパラメータとして埋め込んだ場合を検討する。このＳＩＰ信号の独自ヘッダに埋め込まれた文字列は、このＳＩＰ信号が経由する他のセッション・ボーダ・コントローラによって削除されるおそれがある。
着側セッション・ボーダ・コントローラは、このＳＩＰ信号に応答する新たなＳＩＰ信号を、発側セッション・ボーダ・コントローラに送信する。当該他のセッション・ボーダ・コントローラは、この新たなＳＩＰ信号に対して、独自ヘッダおよび識別子として用いる文字列とを追加すればよいが、このような動作は行わない。

よって、関連するＳＩＰダイアログのＳＩＰ信号を一元的に処理するために、ＳＩＰ信号中のSIP-URIのuser部にセッションＩＤを埋め込む方式や、セッションＩＤを設定した独自パラメータを用いる方式や、セッションＩＤを設定した独自ヘッダを用いる方式は、他のＳＩＰサーバを含むＳＩＰネットワークでは適用できないおそれがある。

本発明は、前記した問題を解決し、ＳＩＰネットワークに於いて関連するＳＩＰダイアログのＳＩＰ信号を一元的に処理することができるセッション・ボーダ・コントローラのクラスタシステム、アプリケーション・サーバのクラスタシステム、および、これらクラスタシステムのＳＩＰダイアログ生成方法を提供することを課題とする。

前記課題を解決するため、請求項１に記載の発明であるセッション・ボーダ・コントローラのクラスタシステムは、ＩＰユーザ・エージェントとの間のＳＩＰダイアログに係るＳＩＰ信号を処理する複数のセッション・ボーダ・コントローラと、前記ＳＩＰダイアログに係るＳＩＰ信号の識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記セッション・ボーダ・コントローラのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置とを備える。各前記セッション・ボーダ・コントローラは、振り分けられた第１のＳＩＰダイアログに係るＳＩＰ信号の第１識別子とは異なり、かつ、前記第１識別子の第１ハッシュ値と同一の値がハッシュ演算される第２識別子を算出する識別子算出部と、前記第１のＳＩＰダイアログに関連し、かつ、前記第２識別子で識別される第２のＳＩＰダイアログを新たに生成する処理部とを備える。

このようにすることで、本発明によれば、ＳＩＰネットワークに於いて関連するＳＩＰダイアログのＳＩＰ信号を、同一のハッシュ値を介して一元的に処理することができる。よって、振分装置は、関連するＳＩＰダイアログに係るリクエストやレスポンスを、同一のセッション・ボーダ・コントローラに振り分けることができる。

請求項２に記載の発明では、請求項１に記載のセッション・ボーダ・コントローラのクラスタシステムに於いて、前記識別子を、前記ＳＩＰダイアログに係るＳＩＰ信号が含むCall-IDヘッダとした。

Call-IDヘッダはＳＩＰの基本的な識別子であり、必ずＳＩＰ信号で使用される。Call-IDヘッダの文字列は、どのＳＩＰサーバでも削除されず、セッション・ボーダ・コントローラなどで書き換えが行われても必ず復元される。これにより、本発明によれば、関連するＳＩＰダイアログのＳＩＰ信号をCall-IDヘッダのハッシュ値で関連づけているので、どのようなＳＩＰネットワークに於いても、関連するＳＩＰダイアログを一元的に処理することができる。

請求項３に記載の発明では、請求項１に記載のセッション・ボーダ・コントローラのクラスタシステムに於いて、前記振分装置の前記スイッチ部は、各前記セッション・ボーダ・コントローラから前記ＳＩＰダイアログに係るINVITEリクエストを受信したならば、Request-URIまたはRouteヘッダに基づいて転送し、各前記セッション・ボーダ・コントローラから前記ＳＩＰダイアログに係るレスポンスを受信したならば、Viaヘッダに基づいて転送する。

このようにすることで、本発明によれば、振分装置は、ＳＩＰの規格に準拠してＳＩＰ信号を転送している。よって、このＳＩＰ信号を、ＳＩＰに準拠したネットワークを経由して、ＳＩＰユーザ・エージェントに送信することができる。

請求項４に記載の発明では、請求項１に記載のセッション・ボーダ・コントローラのクラスタシステムに於いて、前記識別子算出部は、前記振分装置の前記ハッシュ演算部と同一のハッシュ演算を行う第２ハッシュ演算部を有する。

このようにすることで、本発明によれば、振分装置は、新たなＳＩＰダイアログのＳＩＰ信号を、既存のＳＩＰダイアログのＳＩＰ信号と同一のセッション・ボーダ・コントローラに振り分けることができる。

請求項５に記載の発明では、請求項１に記載のセッション・ボーダ・コントローラのクラスタシステムに於いて、各前記セッション・ボーダ・コントローラは、それぞれ記憶部を備えている。前記処理部は、振り分けられた前記第１のＳＩＰダイアログに関連する前記第２のＳＩＰダイアログを新たに生成すると共に、前記第１識別子および前記第２識別子の組合せを前記記憶部に記憶した前記第２識別子を含むＳＩＰ信号が振り分けられたならば、当該第２識別子に対応する前記第１識別子を含むＳＩＰ信号を生成する。

このようにすることで、本発明によれば、処理部は、記憶部に記憶した第２識別子を含むＳＩＰ信号が、このセッション・ボーダ・コントローラに振り分けられたならば、この第２識別子に対応する第１識別子を含むＳＩＰ信号を生成することができる。

請求項６に記載の発明であるアプリケーション・サーバのクラスタシステムは、ＳＩＰユーザ・エージェントとの間のＳＩＰダイアログに係るＳＩＰ信号を処理する複数のアプリケーション・サーバと、前記ＳＩＰダイアログに係るＳＩＰ信号の識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記アプリケーション・サーバのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置とを備える。各前記アプリケーション・サーバは、振り分けられた第１のＳＩＰダイアログに係るＳＩＰ信号の第１識別子とは異なり、かつ、前記第１識別子の第１ハッシュ値と同一の値がハッシュ演算される第２識別子を算出する識別子算出部と、前記第１のＳＩＰダイアログに関連して、前記第２識別子を含む第２のＳＩＰダイアログを新たに生成する処理部とを備える。

このようにすることで、本発明によれば、アプリケーション・サーバのクラスタシステム１Ａがフォーキング、フォローミー、転送などのサービスを提供する際に、各アプリケーション・サーバで分散処理を行わせることができると共に、複数のＳＩＰダイアログを関連づけて処理することができる。

請求項７に記載の発明は、ＳＩＰユーザ・エージェントとの間のＳＩＰダイアログを処理する複数のセッション・ボーダ・コントローラと、前記ＳＩＰダイアログに係る識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記セッション・ボーダ・コントローラのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置とを備えるセッション・ボーダ・コントローラのクラスタシステムのＳＩＰダイアログ生成方法である。各前記セッション・ボーダ・コントローラは、振り分けられた第１のＳＩＰダイアログのＳＩＰ信号が含む第１識別子をハッシュ演算して第１ハッシュ値を算出するステップと、前記第１識別子とは異なる複数の候補値をハッシュ演算するステップと、前記第１ハッシュ値と同一のハッシュ値が算出される第２識別子を得るステップと、前記第２識別子を含むＳＩＰ信号を前記振分装置に送信するステップとを実行する。

このようにすることで、本発明によれば、セッション・ボーダ・コントローラは、このＳＩＰ信号による新たな第２のＳＩＰダイアログを生成できる。更に、この第２のＳＩＰダイアログの識別子のハッシュ値は、第１のＳＩＰダイアログの識別子のハッシュ値と同一である。よって、セッション・ボーダ・コントローラは、第１のＳＩＰダイアログと第２のＳＩＰダイアログとを関連づけて処理することができる。

請求項８に記載の発明は、ＳＩＰユーザ・エージェントとの間のＳＩＰダイアログを処理する複数のアプリケーション・サーバと、前記ＳＩＰダイアログに係る識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記アプリケーション・サーバのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置とを備えるアプリケーション・サーバのクラスタシステムのＳＩＰダイアログ生成方法である。各前記アプリケーション・サーバは、振り分けられた第１のＳＩＰダイアログに係る第１識別子をハッシュ演算して第１ハッシュ値を算出するステップと、前記第１識別子とは異なる複数の候補値をハッシュ演算するステップと、前記第１ハッシュ値と同一のハッシュ値が算出される第２識別子を得るステップと、前記第２識別子を含むＳＩＰ信号を前記振分装置に送信するステップとを実行する。

このようにすることで、本発明によれば、アプリケーション・サーバは、このＳＩＰ信号による新たな第２のＳＩＰダイアログを生成できる。更に、この第２のＳＩＰダイアログの識別子のハッシュ値は、第１のＳＩＰダイアログの識別子のハッシュ値と同一である。よって、アプリケーション・サーバは、第１のＳＩＰダイアログと第２のＳＩＰダイアログとを関連づけて処理することができる。

本発明によれば、ＳＩＰネットワークに於いて関連するＳＩＰダイアログのＳＩＰ信号を一元的に処理することができるセッション・ボーダ・コントローラのクラスタシステム、アプリケーション・サーバのクラスタシステム、および、これらクラスタシステムのＳＩＰダイアログ生成方法を提供することが可能となる。

第１の実施形態に於けるセッション・ボーダ・コントローラのクラスタシステムを示す概略の構成図である。 第１の実施形態に於けるＳＩＰダイアログの動作を示すシーケンス図である。 INVITEリクエストのリクエスト行とヘッダを示す図である。 200 OK応答のステータス行とヘッダを示す図である。 第１の実施形態に於ける振分装置３の処理を示すフローチャートである。 第１の実施形態に於けるセッション・ボーダ・コントローラの処理を示すフローチャートである。 第２の実施形態に於けるアプリケーション・サーバのクラスタシステムを示す概略の構成図である。 第２の実施形態に於けるフォーキング動作を示す図である。

次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
図１は、第１の実施形態に於けるセッション・ボーダ・コントローラのクラスタシステム１を示す概略の構成図である。
セッション・ボーダ・コントローラのクラスタシステム１は、複数のサーバであるセッション・ボーダ・コントローラ２−１〜２−３と、振分装置３とを含んで構成される。セッション・ボーダ・コントローラのクラスタシステム１は、ネットワーク９を介して複数のＳＩＰユーザ・エージェント４−１〜４−４に接続されて、各ＳＩＰユーザ・エージェント４−１〜４−４が送信したＳＩＰ信号を分散処理するものである。
ＳＩＰユーザ・エージェント４−１には、ＩＰアドレス10.63.19.1が払い出されている。ＳＩＰユーザ・エージェント４−２には、ＩＰアドレス10.63.19.2が払い出されている。ＳＩＰユーザ・エージェント４−３には、ＩＰアドレス10.63.19.3が払い出されている。ＳＩＰユーザ・エージェント４−４には、ＩＰアドレス10.63.19.4が払い出されている。振分装置３には、ＩＰアドレス10.72.84.1が払い出されている。これら各装置のSIP-URIは、各装置に付与されたＩＰアドレスを記載することができる。

以下、セッション・ボーダ・コントローラ２−１〜２−３を特に区別しないときには、単にセッション・ボーダ・コントローラ２と記載する場合があり、「ＳＢＣ」と図に記載している場合がある。ＳＩＰユーザ・エージェント４−１〜４−４も同様に、単にＳＩＰユーザ・エージェント４と記載する場合があり、「ＳＩＰ−ＵＡ」と図に記載している場合がある。

振分装置３は、各ＳＩＰユーザ・エージェント４が送信した各ＳＩＰ信号を、複数のＳＩＰユーザ・エージェント４のうちいずれかに振り分けるものである。振分装置３は、Ｌ７スイッチ部３１と、ハッシュ演算部３２とを含んで構成されている。

Ｌ７スイッチ部３１は、ＯＳＩ（Open Systems Interconnection）参照モデルの第７層であるアプリケーション層のデータに基づいてルーティングを行う処理部である。Ｌ７スイッチ部３１は、アプリケーション層レベルのプロトコルであるＳＩＰの各ヘッダを認識する機能を有し、ＳＩＰユーザ・エージェント４が送信した各ＳＩＰ信号を、複数のＳＩＰユーザ・エージェント４に振り分けるものである。Ｌ７スイッチ部３１は更に、ＳＩＰユーザ・エージェント４から送信されたＳＩＰ信号を、対応するＳＩＰユーザ・エージェント４に転送する。Ｌ７スイッチ部３１の処理は、後記する図５で詳細に説明する。

ハッシュ演算部３２は、ＳＩＰダイアログに係るＳＩＰ信号の識別子から、そのＳＩＰ信号の振り分け先を示すハッシュ値を算出する演算部である。Ｌ７スイッチ部３１は、このハッシュ値に基づき、セッション・ボーダ・コントローラ２のいずれかに、このＳＩＰ信号を振り分ける。

セッション・ボーダ・コントローラ２は、ＳＩＰユーザ・エージェント４との間のＳＩＰダイアログを生成し、このＳＩＰダイアログに係るＳＩＰ信号を処理するものである。セッション・ボーダ・コントローラ２は、異なるＩＰ電話サービス・ネットワークの境界に設置されて、アドレス変換処理やセキュリティ処理などを行う。セッション・ボーダ・コントローラ２は、識別子算出部２１と、識別子記憶部２２と、セッション・ボーダ・コントローラ処理部２３（ＳＢＣ処理部）とを含んで構成されている。

識別子算出部２１は、第２ハッシュ演算部２１１を含んで構成されている。この第２ハッシュ演算部２１１は、振分装置３のハッシュ演算部３２と同一のハッシュ値を算出する。振分装置３は、ハッシュ演算部３２が演算するハッシュ値に基づいて、いずれかのセッション・ボーダ・コントローラ２に振り分けている。よって、振分装置３は、このセッション・ボーダ・コントローラ２が生成した新たな第２のＳＩＰダイアログのＳＩＰ信号を、既存の第１のＳＩＰダイアログのＳＩＰ信号と同一のセッション・ボーダ・コントローラに振り分けることができる。

識別子算出部２１は、第２ハッシュ演算部２１１により、既存の第１のＳＩＰダイアログの第１識別子から、その振り分け先を示すハッシュ値を算出し、同一の振り分け先を示すハッシュ値が算出される別の識別子を算出する。この別の識別子のうちひとつは、新たに開始する第２のＳＩＰダイアログの第２識別子として用いられる。よって、識別子算出部２１は、既存の第１のＳＩＰダイアログと関連する新たな第２のＳＩＰダイアログを、同一のハッシュ値を介して一元的に処理することができる。これにより、新たな第２のＳＩＰダイアログのＳＩＰ信号が、既存の第１のＳＩＰダイアログのＳＩＰ信号と同一のセッション・ボーダ・コントローラ２に振り分けられるようにすることができる。

セッション・ボーダ・コントローラ処理部２３は、第２のＳＩＰダイアログを新たに生成する。セッション・ボーダ・コントローラ処理部２３は、識別子算出部２１により第２のＳＩＰダイアログの第２識別子を算出し、新たな第２のＳＩＰダイアログのCall-IDヘッダの文字列に設定する。この第２識別子は、第１のＳＩＰダイアログの第１識別子とは異なり、かつ、第１識別子と同一の振り分け先を示すハッシュ値が算出される。第２のＳＩＰダイアログは、第１のＳＩＰダイアログのＢ２ＢＵＡ処理に係る反対側のＳＩＰダイアログである。

Call-IDヘッダはＳＩＰの基本的な識別子であり、必ずＳＩＰ信号で使用される。Call-IDヘッダの文字列は、どのＳＩＰサーバでも削除されず、セッション・ボーダ・コントローラなどで書き換えが行われても必ず復元される。第１のＳＩＰダイアログと関連する第２のＳＩＰダイアログを、Call-IDヘッダのハッシュ値で関連づけているので、どのようなＳＩＰネットワークに於いても、関連するＳＩＰダイアログを一元的に処理することができる。

識別子記憶部２２は、第１のＳＩＰダイアログの第１識別子と、第２のＳＩＰダイアログの第２識別子との組合せを記憶する記憶部である。セッション・ボーダ・コントローラ処理部２３は、識別子記憶部２２に記憶した第２識別子を含むＳＩＰ信号が、このセッション・ボーダ・コントローラ２に振り分けられたならば、この第２識別子に対応する第１識別子を含むＳＩＰ信号を生成する。

図２は、第１の実施形態に於けるＳＩＰダイアログの動作を示すシーケンス図である。
図２に示すシーケンスＱ１０〜Ｑ１９は、ＳＩＰユーザ・エージェント４−１が発信してＳＩＰユーザ・エージェント４−２が着信するセッションである。シーケンスＱ２０〜Ｑ２９は、ＳＩＰユーザ・エージェント４−３が発信してＳＩＰユーザ・エージェント４−４が着信するセッションである。セッション・ボーダ・コントローラのクラスタシステム１は、これらのセッションを複数のサーバで分散処理する。

各ＳＩＰユーザ・エージェント４から送信されるＳＩＰ信号は、振分装置３にあるＬ７スイッチ部３１により、セッション・ボーダ・コントローラのクラスタシステム１を構成する各サーバに振り分けられる。振り分け先は、振分装置３にあるハッシュ演算部３２によってＳＩＰ信号中の基本的なダイアログ識別子であるCall-IDヘッダから計算されたハッシュ値によって決定される。振り分けたＳＩＰ信号は、それぞれのサーバのセッション・ボーダ・コントローラ処理部２３によって処理される。

以下のシーケンスＱ１０〜Ｑ１２と、シーケンスＱ１８，Ｑ１９とは、ＳＩＰダイアログＤ１（第１のＳＩＰダイアログ）に係る処理を示している。ＳＩＰダイアログＤ１（第１のＳＩＰダイアログ）は、ＳＩＰユーザ・エージェント４−１と、セッション・ボーダ・コントローラ２−１との間で保持される関係である。

シーケンスＱ１０に於いて、ＳＩＰユーザ・エージェント４−１は、ＳＩＰユーザ・エージェント４−２と接続するために、セッション・ボーダ・コントローラのクラスタシステム１の振分装置３にＳＩＰ信号であるINVITEリクエストを送信する。このＳＩＰ信号中のダイアログ識別子は、Call-IDヘッダの文字列「P1」とする。
シーケンスＱ１１に於いて、振分装置３は、振分処理を行う。振分装置３は、ハッシュ演算部３２により、受信したＳＩＰ信号中のダイアログ識別子であるCall-IDヘッダの文字列「P1」からハッシュ値ｐを算出し、対応する振り分け先のサーバであるセッション・ボーダ・コントローラ２−１を選択する。

シーケンスＱ１２に於いて、振分装置３は、Ｌ７スイッチ部３１により、ハッシュ値ｐに対応するセッション・ボーダ・コントローラ２−１を選択してINVITEリクエストを振り分ける。

その後、セッション・ボーダ・コントローラ２−１のセッション・ボーダ・コントローラ処理部２３は、Ｂ２ＢＵＡ処理を行い、ＳＩＰダイアログＤ１（第１のＳＩＰダイアログ）とは異なる新たなＳＩＰダイアログＤ２（第２のＳＩＰダイアログ）を生成する。ＳＩＰダイアログＤ２（第２のＳＩＰダイアログ）は、セッション・ボーダ・コントローラ２−１と、その接続先であるＳＩＰユーザ・エージェント４−２との間で保持される関係である。セッション・ボーダ・コントローラ処理部２３は、識別子算出部２１によって、ハッシュ値ｐであり、かつ、文字列「P1」とは異なる新たな文字列「P2」を生成し、新たなＳＩＰダイアログＤ２に於ける識別子とする。

以下のシーケンスＱ１３〜Ｑ１７は、ＳＩＰダイアログＤ２（第２のＳＩＰダイアログ）に係る処理を示している。
シーケンスＱ１３に於いて、セッション・ボーダ・コントローラ２−１は、シーケンスＱ１２で受信したINVITEリクエストを複製したのちに文字列「P2」をCall-IDヘッダに設定し、このINVITEリクエストを送信する。
シーケンスＱ１４に於いて、振分装置３は、ＳＩＰユーザ・エージェント４−２に対してINVITEリクエストを転送する。ＳＩＰユーザ・エージェント４−２は、このINVITEリクエストを受信する。

シーケンスＱ１５に於いて、ＳＩＰユーザ・エージェント４−２は、ＳＩＰユーザ・エージェント４−１に向けて、ＳＩＰ信号を送信する。この例では、ＳＩＰ信号として、INVITEリクエストに対するレスポンスである200 OKレスポンスを返している。この200 OKレスポンスのCall-IDヘッダは、文字列「P2」である。このＳＩＰ信号は、振分装置３に到着する。

シーケンスＱ１６において、振分装置３は、振分処理に於いて、受信したＳＩＰ信号のCall-IDヘッダの文字列「P2」からハッシュ値ｐを得て、ハッシュ値ｐに対応するサーバであるセッション・ボーダ・コントローラ２−１を振り分け先として選択する。
シーケンスＱ１７に於いて、振分装置３は、振り分け先であるセッション・ボーダ・コントローラ２−１に、200 OKレスポンスを送信する。

上記までの動作により、振分装置３は、これら２つのＳＩＰダイアログＤ１，Ｄ２に係るセッション・ボーダ・コントローラ２−１を選択して、ＳＩＰ信号を振り分けることができる。

シーケンスＱ１８に於いて、セッション・ボーダ・コントローラ２−１は、振分装置３を介して、ＳＩＰユーザ・エージェント４−１に対し、Call-IDヘッダが文字列「P1」である200 OKレスポンスを送信する。振分装置３は、この200 OKレスポンスを受信する。
シーケンスＱ１９に於いて、振分装置３は、ＳＩＰユーザ・エージェント４−１に、200 OKレスポンスを転送する。ＳＩＰユーザ・エージェント４−１は、200 OKレスポンスを受信する。これにより、ＳＩＰユーザ・エージェント４−１とＳＩＰユーザ・エージェント４−２との間で、呼のセッションが確立する。

以下のシーケンスＱ２０〜Ｑ２２と、シーケンスＱ２８，Ｑ２９とは、ＳＩＰダイアログＤ３（第１のＳＩＰダイアログ）に係る処理を示している。ＳＩＰダイアログＤ３（第１のＳＩＰダイアログ）は、ＳＩＰユーザ・エージェント４−３と、セッション・ボーダ・コントローラ２−３との間で保持される関係である。

シーケンスＱ２０に於いて、ＳＩＰユーザ・エージェント４−３は、ＳＩＰユーザ・エージェント４−４と接続するために、ネットワーク内の振分装置３にＳＩＰ信号であるINVITEリクエストを送信する。このＳＩＰ信号中のダイアログ識別子は、Call-IDヘッダの文字列「Q1」とする。

シーケンスＱ２１に於いて、振分装置３は、振分処理を行い、当該ＳＩＰ信号が含んでいるCall-IDヘッダの文字列「Q1」からハッシュ値ｑを得て、対応する振り分け先のサーバであるセッション・ボーダ・コントローラ２−３を選択する。
このように、シーケンスＱ２０で受信したINVITE信号のCall-IDヘッダの文字列「Q1」と、シーケンスＱ１０で受信したINVITE信号のCall-IDヘッダの文字列「P1」とは異なっており、かつ、これら文字列のハッシュ値も異なっている。よって、振分装置３は、これらINVITE信号を、それぞれ対応するセッション・ボーダ・コントローラ２−３に振り分けて、処理を分散することができる。

シーケンスＱ２２に於いて、振分装置３は、Ｌ７スイッチ部３１により、ハッシュ値ｑに対応するセッション・ボーダ・コントローラ２−３を選択してINVITEリクエストを振り分ける。
その後、セッション・ボーダ・コントローラ２−３のセッション・ボーダ・コントローラ処理部２３は、Ｂ２ＢＵＡ処理を行い、ＳＩＰダイアログＤ３（第１のＳＩＰダイアログ）とは異なる新たなＳＩＰダイアログＤ４（第２のＳＩＰダイアログ）を生成する。ＳＩＰダイアログＤ４（第２のＳＩＰダイアログ）は、セッション・ボーダ・コントローラ２−３と、その接続先であるＳＩＰユーザ・エージェント４−４との間で保持される関係である。セッション・ボーダ・コントローラ処理部２３は、ハッシュ演算部３２と連携して、ハッシュ値ｑであり、かつ、文字列「Q1」とは異なる新たな文字列「Q2」を生成し、新たなＳＩＰダイアログＤ４に於ける識別子とする。

以下のシーケンスＱ２３〜Ｑ２７は、ＳＩＰダイアログＤ４（第２のＳＩＰダイアログ）に係る処理を示している。
シーケンスＱ２３に於いて、セッション・ボーダ・コントローラ２−３は、シーケンスＱ２２で受信したINVITEリクエストを複製したのちに文字列「Q2」をCall-IDヘッダに設定し、このINVITEリクエストを送信する。
シーケンスＱ２４に於いて、振分装置３は、ＳＩＰユーザ・エージェント４−４に対してINVITEリクエストを転送する。ＳＩＰユーザ・エージェント４−４は、このINVITEリクエストを受信する。

シーケンスＱ２５に於いて、ＳＩＰユーザ・エージェント４−４は、ＳＩＰユーザ・エージェント４−３に向けて、ＳＩＰ信号を送信する。この例では、ＳＩＰ信号として、INVITEリクエストに対するレスポンスである200 OKレスポンスを返している。この200 OKレスポンスのCall-IDヘッダは、文字列「Q2」である。このＳＩＰ信号は、振分装置３に到着する。

シーケンスＱ２６において、振分装置３は、受信したＳＩＰ信号のCall-IDヘッダの文字列「Q2」からハッシュ値ｑを得て、ハッシュ値ｑに対応するサーバであるセッション・ボーダ・コントローラ２−３を振り分け先として選択する。
シーケンスＱ２７に於いて、振分装置３は、振り分け先であるセッション・ボーダ・コントローラ２−３に、200 OKレスポンスを送信する。

上記までの動作により、振分装置３は、これら２つのＳＩＰダイアログＤ３，Ｄ４を処理すべきセッション・ボーダ・コントローラ２−３を適切に選択して、ＳＩＰ信号を振り分けることができる。

シーケンスＱ２８に於いて、セッション・ボーダ・コントローラ２−３は、振分装置３を介して、ＳＩＰユーザ・エージェント４−３に対し、Call-IDヘッダが文字列「Q1」である200 OKレスポンスを送信する。振分装置３は、この200 OKレスポンスを受信する。
シーケンスＱ２９に於いて、振分装置３は、ＳＩＰユーザ・エージェント４−３に、200 OKレスポンスを転送する。ＳＩＰユーザ・エージェント４−３は、200 OKレスポンスを受信する。これにより、ＳＩＰユーザ・エージェント４−３とＳＩＰユーザ・エージェント４−４との間で、呼のセッションが確立する。

図３（ａ），（ｂ）は、INVITEリクエストのリクエスト行とヘッダを示す図である。図３（ａ）は、ＳＩＰダイアログＤ１に於いて、ＳＩＰユーザ・エージェント４−１から最初に送信されるINVITEリクエストを示している。図３（ｂ）は、ＳＩＰダイアログＤ２に於いて、ＳＩＰユーザ・エージェント４−２が受信する、Ｂ２ＢＵＡ処理に係る反対側のINVITEリクエストを示している。

図３（ａ）に示すように、１行目であるリクエスト行には、リクエストの内容を示す「INVITE」と、送信先のＳＩＰユーザ・エージェント４−２を示すSIP-URI「sip:10.63.19.2」と、ＳＩＰのバージョンを示す「SIP/2.0」とが記載されている。
２行目には、Viaヘッダであることを示す「Via:」と、ＵＤＰ（User Datagram Protocol）であることを示す「SIP/2.0/UDP」と、最初の経由地であり、かつ、送信元のＳＩＰユーザ・エージェント４−１を示すSIP-URI「10.63.19.1」が記載されている。
３行目には、Fromヘッダであることを示す「From:」と、送信元のＳＩＰユーザ・エージェント４−１を示すSIP-URI「Alice<sip:10.63.19.1>」が記載されている。

４行目には、Toヘッダであることを示す「To:」と、送信先のＳＩＰユーザ・エージェント４−２を示すSIP-URI「Bob<sip:10.63.19.2>」が記載されている。
５行目には、Call-IDヘッダであることを示す「Call-ID:」と、このＳＩＰダイアログＤ１の識別子である文字列「P1」が記載され、更に送信元のＳＩＰユーザ・エージェント４−１のＩＰアドレスが「@」以降に記載されている。このCall-IDヘッダの文字列「P1」に基づいて、振分装置３は、いずれかのセッション・ボーダ・コントローラ２に、このINVITEリクエストを振り分けることができる。
以下、６行目以降の説明は、省略する。

図３（ｂ）に示すＢ２ＢＵＡ処理に係る反対側のINVITEリクエストの１〜５行目は、ＳＩＰユーザ・エージェント４−１により最初に送信された図３（ａ）に示すINVITEリクエストと同様に記載されている。しかし、Ｂ２ＢＵＡ処理に係る反対側のINVITEリクエストの５行目のCall-IDヘッダは、図３（ａ）に示すINVITEリクエストとは異なっている。
５行目には、Call-IDヘッダであることを示す「Call-ID:」と、このＳＩＰダイアログＤ２の識別子である文字列「P2」が記載され、更に、このINVITEリクエストを振り分けた振分装置３のＩＰアドレスが「@」以降に記載されている。文字列「P2」をハッシュ演算した振り分け先は、文字列「P1」をハッシュ演算した振り分け先と同一のセッション・ボーダ・コントローラ２−１である。

図４（ａ），（ｂ）は、200 OKレスポンスのステータス行とヘッダを示す図である。図４（ａ）は、ＳＩＰダイアログＤ２に於いて、ＳＩＰユーザ・エージェント４−２から応答した、Ｂ２ＢＵＡ処理に係る反対側の200 OKレスポンスを示している。図４（ｂ）は、ＳＩＰダイアログＤ２に於いて、ＳＩＰユーザ・エージェント４−１が受信する200 OKレスポンスを示している。

図４（ａ）に示すように、１行目であるステータス行には、ＳＩＰのバージョンを示す「SIP/2.0」と、レスポンスの内容を示す「200 OK」とが記載されている。
２行目には、Viaヘッダであることを示す「Via:」と、ＵＤＰであることを示す「SIP/2.0/UDP」と、ＳＩＰユーザ・エージェント４−２を示すSIP-URI「10.63.19.2」とが記載されている。
３行目には、Toヘッダであることを示す「To:」と、ＳＩＰユーザ・エージェント４−２を示すSIP-URI「Bob<sip:10.63.19.2>」とが記載されている。

４行目には、Fromヘッダであることを示す「From:」と、ＳＩＰユーザ・エージェント４−１を示すSIP-URI「Alice<sip:10.63.19.1>」とが記載されている。
５行目には、Call-IDヘッダであることを示す「Call-ID:」と、このＳＩＰダイアログＤ２の識別子である文字列「P2」が記載され、更にＳＩＰユーザ・エージェント４−２のＩＰアドレスが「@」以降に記載されている。
このCall-IDヘッダの文字列「P2」に基づいて、振分装置３は、セッション・ボーダ・コントローラ２−１に、この200 OKレスポンスを振り分けることができる。
以下、６行目以降の説明は、省略する。

図４（ｂ）に示す200 OKレスポンスの１〜４行目は、図４（ａ）に示す200 OKレスポンスと同様に記載されている。しかし、この200 OKレスポンスの５行目のCall-IDヘッダは、図４（ａ）に示す200 OKレスポンスとは異なっている。
５行目には、Call-IDヘッダであることを示す「Call-ID:」と、このＳＩＰダイアログＤ１の識別子である文字列「P1」が記載され、更に振分装置３のＩＰアドレスが「@」以降に記載されている。

図５は、第１の実施形態に於ける振分装置３の振分処理を示すフローチャートである。
いずれかの装置からＳＩＰ信号を受信したならば、振分装置３は、振分処理を開始する。
ステップＳ１０に於いて、振分装置３は、送信元がいずれであるかを判断する。振分装置３は、送信元がＳＩＰユーザ・エージェント４ならば、ステップＳ１１の処理を行い、送信元がセッション・ボーダ・コントローラ２ならば、ステップＳ１４の処理を行う。
ステップＳ１１に於いて、振分装置３は、ハッシュ演算部３２により、ＳＩＰダイアログの識別子であるCall-IDヘッダの文字列のハッシュ値を演算する。

ステップＳ１２に於いて、振分装置３は、ハッシュ値に基づいて振り分け先のセッション・ボーダ・コントローラ２を決定する。
ステップＳ１３に於いて、振分装置３は、Ｌ７スイッチ部３１により、受信したＳＩＰ信号を、決定したセッション・ボーダ・コントローラ２に振り分けて（転送）、図５の処理を終了する。
Call-IDヘッダの文字列は、どのＳＩＰサーバでも削除されない。よって、振分装置３は、ＳＩＰ信号を、そのCall-IDヘッダの文字列に基づいて、いずれかのセッション・ボーダ・コントローラ２に振り分けることができる。

ステップＳ１４に於いて、振分装置３は、受信したＳＩＰ信号（メッセージ）を判断する。振分装置３は、受信したＳＩＰ信号がリクエストならば、ステップＳ１５の処理を行い、受信したＳＩＰ信号がＳＩＰのレスポンスならば、ステップＳ１６の処理を行う。
ステップＳ１５に於いて、振分装置３は、Ｌ７スイッチ部３１により、受信したリクエストを、リクエスト行のＵＲＩ（RequestURI）が示すＳＩＰユーザ・エージェント４に転送し、図５の処理を終了する。なお、振分装置３は、リクエスト行のＵＲＩに限定されず、Routeヘッダが示すＳＩＰユーザ・エージェント４に転送してもよい。
ステップＳ１６に於いて、振分装置３は、Ｌ７スイッチ部３１により、受信したレスポンスを、Viaヘッダが示すＳＩＰユーザ・エージェント４に転送し、図５の処理を終了する。
このように、振分装置３は、セッション・ボーダ・コントローラ２からＳＩＰユーザ・エージェント４に対しては、ＳＩＰの規格に準拠してＳＩＰ信号を転送している。よって、このＳＩＰ信号を、ＳＩＰに準拠したネットワーク９を経由して、ＳＩＰユーザ・エージェント４に送信することができる。

図６は、第１の実施形態に於けるセッション・ボーダ・コントローラ２の処理を示すフローチャートである。
振分装置３からＳＩＰ信号を振り分けられたならば、セッション・ボーダ・コントローラ２は、処理を開始する。
ステップＳ２０に於いて、セッション・ボーダ・コントローラ２は、振り分けられたＳＩＰ信号を複製して、第２のＳＩＰダイアログの新たなＳＩＰ信号とする。この第２のＳＩＰダイアログは、振り分けられたＳＩＰ信号に係る第１のＳＩＰダイアログのＢ２ＢＵＡ処理の反対側のＳＩＰダイアログである。これにより、セッション・ボーダ・コントローラ２は、このＳＩＰ信号による新たな第２のＳＩＰダイアログを生成できる。

ステップＳ２１に於いて、セッション・ボーダ・コントローラ２は、振り分けられたＳＩＰ信号の識別子は、識別子記憶部２２に記憶済であるか否かを判断する。ＳＩＰ信号が含む識別子とは、このＳＩＰ信号のCall-IDヘッダの文字列である。セッション・ボーダ・コントローラ２は、当該判断条件が成立しなかったならば（Ｎｏ）、ステップＳ２２の処理を行い、当該判断条件が成立したならば（Ｙｅｓ）、ステップＳ２７の処理を行う。
ステップＳ２２に於いて、セッション・ボーダ・コントローラ２は、第２ハッシュ演算部２１１により、振り分けられたＳＩＰ信号が含む識別子のハッシュ値を演算する。
ステップＳ２３に於いて、セッション・ボーダ・コントローラ２は、第２ハッシュ演算部２１１により、振り分けられたＳＩＰ信号が含む識別子とは異なる複数の候補値をハッシュ演算する。

ステップＳ２４に於いて、セッション・ボーダ・コントローラ２は、振り分けられたＳＩＰ信号が含む識別子と同一の振り分け先となる候補値を、新たなＳＩＰ信号の識別子に設定する。これにより、セッション・ボーダ・コントローラ２は、振り分けられたＳＩＰ信号に係る第１のＳＩＰダイアログと関連する新たなＳＩＰ信号を生成できる。
ステップＳ２５に於いて、セッション・ボーダ・コントローラ２は、新たなＳＩＰ信号を振分装置３に送信する。この新たなＳＩＰ信号は、Ｂ２ＢＵＡ処理に係る反対側のＳＩＰダイアログに係るものである。これにより、セッション・ボーダ・コントローラ２は、このＳＩＰ信号による新たな第２のＳＩＰダイアログを生成できる。更にセッション・ボーダ・コントローラ２は、第１のＳＩＰダイアログと第２のＳＩＰダイアログとを関連づけて処理することができる。

ステップＳ２６に於いて、セッション・ボーダ・コントローラ２は、受信したＳＩＰ信号の識別子と、Ｂ２ＢＵＡ処理に係る反対側のＳＩＰダイアログ識別子との組合せを、識別子記憶部２２に格納し、図６の処理を終了する。
このようにすることで、セッション・ボーダ・コントローラ２は、このＳＩＰ信号による新たな第２のＳＩＰダイアログを生成する。この第２のＳＩＰダイアログは、このセッション・ボーダ・コントローラ２と、ＳＩＰユーザ・エージェント４との間で保持される。更に、この第２のＳＩＰダイアログの識別子のハッシュ値は、第１のＳＩＰダイアログの識別子のハッシュ値と同一である。このように、セッション・ボーダ・コントローラ２は、第１のＳＩＰダイアログと第２のＳＩＰダイアログとを関連づけて処理することができる。

ステップＳ２７に於いて、セッション・ボーダ・コントローラ２は、振り分けられたＳＩＰ信号の識別子に対応する、Ｂ２ＢＵＡ処理に係る反対側のＳＩＰダイアログの識別子を、識別子記憶部２２から取得する。
ステップＳ２８に於いて、セッション・ボーダ・コントローラ２は、Ｂ２ＢＵＡ処理に係る反対側のＳＩＰダイアログの識別子を、新たなＳＩＰ信号の識別子に設定する。
ステップＳ２９に於いて、セッション・ボーダ・コントローラ２は、新たなＳＩＰ信号を振分装置３に送信し、図６の処理を終了する。

（第１の実施形態の効果）
（Ａ） Call-IDヘッダの文字列は、ＳＩＰの基本的な識別子であり、必ずＳＩＰ信号で使用される。そのため、Call-IDの文字列は、どのＳＩＰサーバでも削除されず、セッション・ボーダ・コントローラ２などで書き換えが行われても必ず復元される。振分装置３は、Call-IDヘッダの文字列に基づく同一のハッシュ値を介して、関連するＳＩＰダイアログに係るリクエストやレスポンスを、同一のセッション・ボーダ・コントローラ２に振り分けることができる。

（Ｂ） 第１のＳＩＰダイアログの識別子のハッシュ値と、この第１のダイアログと関連する第２のダイアログの識別子のハッシュ値とは同一である。これにより、セッション・ボーダ・コントローラ２は、第１のＳＩＰダイアログと、この第１のＳＩＰダイアログと関連する第２のＳＩＰダイアログとを関連づけて処理することができる。

（第２の実施形態）
図７は、第２の実施形態に於けるアプリケーション・サーバのクラスタシステム１Ａを示す概略の構成図である。
第２の実施形態のアプリケーション・サーバのクラスタシステム１Ａは、複数のサーバとして、図１に示すセッション・ボーダ・コントローラ２とは異なるアプリケーション・サーバ２Ａ−１〜２Ａ−３を含んで構成される。以下、アプリケーション・サーバ２Ａ−１〜２Ａ−３を特に区別しないときには、単にアプリケーション・サーバ２Ａと記載している場合があり、「ＡＳ」と図で記載している場合がある。

第２の実施形態のアプリケーション・サーバ２Ａは、図１に示す第１の実施形態のセッション・ボーダ・コントローラ処理部２３とは異なるアプリケーション・サーバ処理部２３Ａ（ＡＳ処理部）を備えている。アプリケーション・サーバ２Ａは、アプリケーション・サーバ処理部２３Ａにより、フォローミー（follow-me）、フォーキング、転送などのサービスを、ＳＩＰユーザ・エージェント４に対して提供するものである。

フォローミーとは、複数の端末のいずれか１つから、単一の着信呼に応答可能とするサービスのことをいう。フォローミーのサービスにより、例えば、複数の事業所にオフィスがある場合は、それら複数のオフィスのデスクに内線用のＩＰ電話を置いておき、特定の内線に呼び出しがあると、すべてを同時に鳴動させることができる。
フォーキングとは、単一のリクエストを複数の端末に送信する動作のことをいう。例えばフォローミーのサービスは、着信呼に係るINVITEリクエストを複数の端末に送信するフォーキング動作により、複数のＩＰ電話を同時に鳴らしている。
転送とは、例えば、デスクにある内線のＩＰ電話に出られない時に、別の内線である秘書のＩＰ電話や、携帯電話へと転送するサービスのことをいう。
アプリケーション・サーバのクラスタシステム１Ａによれば、これらフォーキング、フォローミー、転送などのサービスを提供する際に、各アプリケーション・サーバ２Ａに分散処理を行わせることができると共に、着信呼に係る複数のＳＩＰダイアログを関連づけて処理することができる。

図８は、第２の実施形態に於けるフォーキング動作を示す図である。
図８に示すシーケンスＱ４０〜Ｑ４５は、ＳＩＰユーザ・エージェント４−１が発信して、ＳＩＰユーザ・エージェント４−２，４−３にそれぞれ着信するものである。アプリケーション・サーバのクラスタシステム１Ａは、発信に係るINVITEリクエストをフォーキングして、複数のＳＩＰユーザ・エージェント４に送信する。

シーケンスＱ４０に於いて、ＳＩＰユーザ・エージェント４−１が、アプリケーション・サーバのクラスタシステム１Ａの振分装置３にＳＩＰ信号（INVITEリクエスト）を送信する。当該ＳＩＰ信号中のダイアログ識別子は、Call-IDヘッダの文字列「P1」である。当該ＳＩＰ信号のリクエスト行には、ＳＩＰユーザ・エージェント４−２のSIP-URIが示されている。このとき、振分装置３は、受信したＳＩＰ信号中のダイアログ識別子であるCall-IDヘッダの文字列「P1」からハッシュ値ｐを算出する。

シーケンスＱ４１に於いて、振分装置３は、ハッシュ値ｐに対応するアプリケーション・サーバ２Ａ−１を選択してＳＩＰ信号を振り分ける。
このとき、アプリケーション・サーバ２Ａ−１のアプリケーション・サーバ処理部２３Ａは、ハッシュ演算部３２と連携して、ハッシュ値ｐであり、かつ、文字列「P1」とは異なる新たな文字列「P2」と、文字列「P3」とを生成する。アプリケーション・サーバ処理部２３Ａは、受信したＳＩＰ信号（INVITEリクエスト）を複製してCall-IDヘッダを文字列「P2」に書き換える。アプリケーション・サーバ処理部２３Ａは更に、受信したＳＩＰ信号（INVITEリクエスト）を複製し、リクエスト行に示されたSIP-URIを、このSIP-URIに関連する端末であるＳＩＰユーザ・エージェント４−３のSIP-URIに書き換える。

シーケンスＱ４２に於いて、アプリケーション・サーバ２Ａ−１は、INVITEリクエストのCall-IDヘッダに、この文字列「P2」を設定し、振分装置３に送信する。
シーケンスＱ４３に於いて、振分装置３は、このINVITEリクエストを、リクエスト行に示されたSIP-URIに基づき、ＳＩＰユーザ・エージェント４−２に転送する。なお、振分装置３は、リクエスト行に示されたSIP-URIに限定されず、Routeヘッダが示すＳＩＰユーザ・エージェント４に転送してもよい。
このINVITEリクエストのCall-IDヘッダには文字列「P2」が設定されているので、このINVITEリクエストに対するレスポンスのCall-IDヘッダにも文字列「P2」が設定される。これにより、振分装置３は、ＳＩＰユーザ・エージェント４−２からのレスポンスをアプリケーション・サーバ２Ａ−１に振り分けることができる。

シーケンスＱ４４に於いて、アプリケーション・サーバ２Ａ−１は、この文字列「P3」をCall-IDヘッダに設定したINVITEリクエストを、振分装置３に送信する。
シーケンスＱ４５に於いて、振分装置３は、このINVITEリクエストを、リクエスト行に示されたSIP-URIに基づき、ＳＩＰユーザ・エージェント４−３に転送する。なお、振分装置３は、リクエスト行に示されたSIP-URIに限定されず、Routeヘッダが示すＳＩＰユーザ・エージェント４に転送してもよい。
このINVITEリクエストのCall-IDヘッダには文字列「P3」が設定されているので、このINVITEリクエストに対するレスポンスのCall-IDヘッダにも文字列「P3」が設定される。これにより、振分装置３は、ＳＩＰユーザ・エージェント４−３からのレスポンスをアプリケーション・サーバ２Ａ−１に振り分けることができる。

アプリケーション・サーバ２ＡにＳＩＰ信号が振り分けられたときの処理は、図６に示す第１の実施形態に於けるセッション・ボーダ・コントローラ２の処理と同様である。
このようにすることで、アプリケーション・サーバ２Ａは、第１の実施形態のセッション・ボーダ・コントローラ２と同様に、このＳＩＰ信号による新たな第２のＳＩＰダイアログを生成できる。更に、この第２のＳＩＰダイアログの識別子のハッシュ値は、第１のＳＩＰダイアログの識別子のハッシュ値と同一である。よって、アプリケーション・サーバ２Ａは、第１のＳＩＰダイアログと第２のＳＩＰダイアログとを関連づけて処理することができる。

（第２の実施形態の効果）
（Ｃ） フォローミー、フォーキング、転送などのサービスを提供するアプリケーション・サーバのクラスタシステム１Ａは、関連する複数のＳＩＰダイアログを同一のアプリケーション・サーバ２Ａで扱えるようになる。

（Ｄ） これら複数のＳＩＰダイアログの識別子から同一のハッシュ値が算出されるので、アプリケーション・サーバ２Ａは、これら複数のＳＩＰダイアログを関連づけて処理することができる。

（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｃ）のようなものがある。

（ａ） ハッシュ演算部３２や、第２ハッシュ演算部２１１が実行するハッシュ関数は、極めて簡単なものでよく、例えば、文字列コードの和をセッション・ボーダ・コントローラ２の数で除算した剰余としてもよい。

（ｂ） ハッシュ演算部３２や、第２ハッシュ演算部２１１が実行するハッシュ関数は、逆関数を有するものとしてもよい。これにより、振り分けられたＳＩＰ信号が含む識別子と同一の振り分け先となる候補値を、簡単かつ迅速に算出することができる。

（ｃ） 振分装置３は、ＳＩＰの基本的なダイアログ識別子であるCall-IDヘッダの文字列に加えて、FromヘッダやToヘッダを組み合わせて振分処理をおこなってもよい。

１ セッション・ボーダ・コントローラのクラスタシステム
１Ａ アプリケーション・サーバのクラスタシステム
２，２−１〜２−３ セッション・ボーダ・コントローラ
２Ａ，２Ａ−１〜２Ａ−３ アプリケーション・サーバ
２１ 識別子算出部
２１１ 第２ハッシュ演算部
２２ 識別子記憶部 （記憶部）
２３ セッション・ボーダ・コントローラ処理部 （処理部）
２３Ａ アプリケーション・サーバ処理部 （処理部）
３ 振分装置
３１ Ｌ７スイッチ部 （スイッチ部）
３２ ハッシュ演算部
４，４−１〜４−４ ＳＩＰユーザ・エージェント
９ ネットワーク
Ｄ１ ＳＩＰダイアログ （第１のＳＩＰダイアログ）
Ｄ２ ＳＩＰダイアログ （第２のＳＩＰダイアログ）
Ｄ３ ＳＩＰダイアログ （第１のＳＩＰダイアログ）
Ｄ４ ＳＩＰダイアログ （第２のＳＩＰダイアログ）

Claims (8)

1. ＳＩＰ（Session Initiation Protocol）ユーザ・エージェントとの間のＳＩＰダイアログに係るＳＩＰ信号を処理する複数のセッション・ボーダ・コントローラと、
   前記ＳＩＰダイアログに係るＳＩＰ信号の識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記セッション・ボーダ・コントローラのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置と、
   を備えており、
   各前記セッション・ボーダ・コントローラは、
   振り分けられた第１のＳＩＰダイアログに係るＳＩＰ信号の第１識別子とは異なり、かつ、前記第１識別子の第１ハッシュ値と同一の値がハッシュ演算される第２識別子を算出する識別子算出部と、
   前記第１のＳＩＰダイアログに関連し、かつ、前記第２識別子で識別される第２のＳＩＰダイアログを新たに生成する処理部と、
   を備えることを特徴とするセッション・ボーダ・コントローラのクラスタシステム。
2. 前記識別子は、
   前記ＳＩＰダイアログに係るＳＩＰ信号が含むCall-IDヘッダである、
   ことを特徴とする請求項１に記載のセッション・ボーダ・コントローラのクラスタシステム。
3. 前記振分装置の前記スイッチ部は、
   各前記セッション・ボーダ・コントローラから前記ＳＩＰダイアログに係るINVITEリクエストを受信したならば、Request-URIまたはRouteヘッダに基づいて転送し、
   各前記セッション・ボーダ・コントローラから前記ＳＩＰダイアログに係るレスポンスを受信したならば、Viaヘッダに基づいて転送する、
   ことを特徴とする請求項１に記載のセッション・ボーダ・コントローラのクラスタシステム。
4. 前記識別子算出部は、
   前記振分装置の前記ハッシュ演算部と同一のハッシュ演算を行う第２ハッシュ演算部を有する、
   ことを特徴とする請求項１に記載のセッション・ボーダ・コントローラのクラスタシステム。
5. 各前記セッション・ボーダ・コントローラは、それぞれ記憶部を備えており、
   前記処理部は、
   振り分けられた前記第１のＳＩＰダイアログに関連する前記第２のＳＩＰダイアログを新たに生成すると共に、前記第１識別子および前記第２識別子の組合せを前記記憶部に記憶し、
   前記記憶部に記憶した前記第２識別子を含むＳＩＰ信号が振り分けられたならば、当該第２識別子に対応する前記第１識別子を含むＳＩＰ信号を生成する、
   ことを特徴とする請求項１に記載のセッション・ボーダ・コントローラのクラスタシステム。
6. ＳＩＰユーザ・エージェントとの間のＳＩＰダイアログに係るＳＩＰ信号を処理する複数のアプリケーション・サーバと、
   前記ＳＩＰダイアログに係るＳＩＰ信号の識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記アプリケーション・サーバのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置と、
   を備えており、
   各前記アプリケーション・サーバは、
   振り分けられた第１のＳＩＰダイアログに係るＳＩＰ信号の第１識別子とは異なり、かつ、前記第１識別子の第１ハッシュ値と同一の値がハッシュ演算される第２識別子を算出する識別子算出部と、
   前記第１のＳＩＰダイアログに関連して、前記第２識別子を含む第２のＳＩＰダイアログを新たに生成する処理部と、
   を備えることを特徴とするアプリケーション・サーバのクラスタシステム。
7. ＳＩＰユーザ・エージェントとの間のＳＩＰダイアログを処理する複数のセッション・ボーダ・コントローラと、
   前記ＳＩＰダイアログに係る識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記セッション・ボーダ・コントローラのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置と、
   を備えており、
   各前記セッション・ボーダ・コントローラは、
   振り分けられた第１のＳＩＰダイアログのＳＩＰ信号が含む第１識別子をハッシュ演算して第１ハッシュ値を算出するステップと、
   前記第１識別子とは異なる複数の候補値をハッシュ演算するステップと、
   前記第１ハッシュ値と同一のハッシュ値が算出される第２識別子を得るステップと、
   前記第２識別子を含むＳＩＰ信号を前記振分装置に送信するステップと、
   を実行することを特徴とするセッション・ボーダ・コントローラのクラスタシステムのＳＩＰダイアログ生成方法。
8. ＳＩＰユーザ・エージェントとの間のＳＩＰダイアログを処理する複数のアプリケーション・サーバと、
   前記ＳＩＰダイアログに係る識別子をハッシュ演算してハッシュ値を算出するハッシュ演算部、および、前記識別子のハッシュ値に基づき、複数の前記アプリケーション・サーバのいずれかに当該ＳＩＰダイアログに係るＳＩＰ信号を振り分けるスイッチ部を有する振分装置と、
   を備えており、
   各前記アプリケーション・サーバは、
   振り分けられた第１のＳＩＰダイアログに係る第１識別子をハッシュ演算して第１ハッシュ値を算出するステップと、
   前記第１識別子とは異なる複数の候補値をハッシュ演算するステップと、
   前記第１ハッシュ値と同一のハッシュ値が算出される第２識別子を得るステップと、
   前記第２識別子を含むＳＩＰ信号を前記振分装置に送信するステップと、
   を実行することを特徴とするアプリケーション・サーバのクラスタシステムのＳＩＰダイアログ生成方法。

Images