(57)【要約】【課題】  ＵＲＩの長大化を避け、スケーラブルなＳＩＰ端末の収容を可能とする。【解決手段】  ＳＩＰの手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御装置において、ＳＩＰ端末からのＳＩＰプロトコルパケットのヘッダ内容を参照し、このヘッダの少なくとも一部の情報を基に、複数のＳＩＰサーバの１つにＳＩＰプロトコルパケットを転送するための制御を行うゲートウェイと、一部の情報を変更するためのデータベースとを有する。【選択図】  図１
2006303754.tif 000002
【特許請求の範囲】
【請求項１】
セッションイニシエーションプロトコル(ＳＩＰと略す)の手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御装置において、該ＳＩＰ端末からのＳＩＰプロトコルパケットのヘッダ内容を参照し、該ヘッダの少なくとも一部の情報を基に、複数のＳＩＰサーバのあるＳＩＰサーバに該ＳＩＰプロトコルパケットを転送するための制御を行うゲートウェイと、該一部の情報を変更するための情報を登録するデータベースと、を有することを特徴とする複合セッション制御装置。
【請求項２】
ＳＩＰの手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御装置であって、複数のＳＩＰサーバと、該複数のＳＩＰサーバのいずれかにＳＩＰ端末からのＳＩＰプロトコルパケットを転送する機能を有し、該転送機能は該ＳＩＰプロトコルパケットの一部の情報をキーとして該複数のＳＩＰサーバのいずれかを選択するためのアドレス情報を取得し、かつ該ＳＩＰプロトコルパケットの該一部の情報または他の部分の情報を書き換えるための情報を取得することを特徴とする複合セッション制御装置。
【請求項３】
ＳＩＰの手順に基づいてIPネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御装置において、複数のＳＩＰサーバと、該複数のＳＩＰサーバのいずれかに該ＳＩＰ端末からのＳＩＰプロトコルパケットを転送する転送手段と、該複数のＳＩＰサーバに転送したＳＩＰプロトコルパケットが属するセッションＩＤと被転送ＳＩＰサーバとの対応関係を登録する記憶手段とを有し、
該転送手段から、該記憶手段の該対応関係を参照して、該複数のＳＩＰサーバのいずれかを選択する制御を行うことを特徴とする複合セッション制御装置。
【請求項４】
請求項３において、該ＳＩＰプロトコルパケットの該転送手段からロケーションサーバを参照することを特徴とする複合セッション制御装置。
【請求項５】
請求項２において、該ＳＩＰプロトコルパケットを転送する機能はＳＩＰプロトコルパケットの一部を解析するリゾルバ機能、該アドレス情報を取得しかつ該ＳＩＰプロトコルパケットの該一部の情報または他の部分の情報を書き換えるための情報を取得するためのリダイレクタ、該アドレス情報を基に該ＳＩＰプロトコルパケットを転送するためのスイッチを有することを特徴とする複合セッション制御装置。
【請求項６】
請求項３において、該ＳＩＰプロトコルパケットを転送手段はＳＩＰプロトコルパケットの一部を解析するリゾルバ機能と、該複合セッション制御サーバにおいて処理を行っている個々のＳＩＰプロトコルセッションと該複数のＳＩＰサーバの内で該ＳＩＰ個々のＳＩＰプロトコルセッションを分担するＳＩＰサーバアドレスとの対応関係および該対応関係を基にＳＩＰプロトコルパケットを転送する該ＳＩＰサーバを決定するリダイレクタと、該リダイレクタの決定に基づいて該ＳＩＰプロトコルパケットを該ＳＩＰサーバへ転送する機能とを有することを特徴とする複合セッション制御装置。
【請求項７】
前記ＳＩＰサーバは、ＳＩＰプロキシにより構成され、
更に前記データベースは、ＳＩＰ端末のユーザ名に対応付けて、ＳＩＰプロトコルパケットに含まれて送信されるＵＲＩ，ＶＵＲＩ，登録ＩＰアドレス、及び収容ＳＩＰサーバのＩＰアドレスを登録することを特徴とする請求項１の複合セッション制御装置。
【請求項８】
ＳＩＰの手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御方法において、
該ＳＩＰ端末から送信されるＳＩＰプロトコルパケットに含まれる送信先を指定するＵＲＩを抽出するステップと、
抽出された該ＵＲＩに関して、データベースを参照して、該ＵＲＩに仮想的に対応付けられたＶＵＲＩを取得するステップと、
ＳＩＰプロトコルパケット中の該ＵＲＩを、取得された該ＶＵＲＩに置き換えるステップと、
複数のＳＩＰサーバから選択されたあるＳＩＰサーバに、該ＶＵＲＩを含む該ＳＩＰプロトコルパケットを送信するステップと、
選択されたＳＩＰサーバでは、受信したＳＩＰプロトコルパケットに関するダイアログの処理を行い、ロケーションサーバでは、該ＳＩＰ端末の位置情報の登録を行うステップと、
該ＶＵＲＩに関して、該データベースを参照して、該ＶＵＲＩに対応付けられたＵＲＩを取得するステップと、
ＳＩＰプロトコルパケット中の該ＶＵＲＩを、取得された該ＵＲＩに置き換えるステップと、
作成された該ＳＩＰプロトコルパケットを宛先のＳＩＰ端末へ送信するステップと、を有することを特徴とするＳＩＰ制御方法。
【請求項９】
前記ＶＵＲＩを取得するステップでは、該ＶＵＲＩを処理するＳＩＰサーバのＩＰアドレスも併せて取得することを含み、
該ＩＰアドレスに基づいて選択されたＳＩＰサーバに対して該ＳＩＰプロトコルパケットを送信することを特徴とする請求項８のＳＩＰ制御方法。
【請求項１０】
前記データベースは、ＳＩＰ端末のユーザ名に対応付けて、ＳＩＰプロトコルパケットに含まれて送信されるＵＲＩ，ＶＵＲＩ，登録ＩＰアドレス、及び収容ＳＩＰサーバのＩＰアドレスを登録することを特徴とする請求項８又は９のＳＩＰ制御方法。
【請求項１１】
収容ＳＩＰサーバのＩＰアドレスに対応して、現在のセッション数及び負荷状態を管理するテーブルを参照して、負荷の低いＩＰアドレスを取得して、該ＩＰアドレスに関連する該ＵＲＩに関して該ＶＵＲＩを取得すると共に、該ＶＵＲＩを該ＵＲＩに変換した後、該テーブルの負荷状態を更新することを特徴とする請求項９のＳＩＰ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複合セッション制御装置及び方法に係り、特にインターネットプロトコルを用いるネットワークにおける通信セッション制御において、多数の端末からの制御要求を効率的に処理するための複合セッション制御サーバ及びその制御方法に関する。
【背景技術】
【０００２】
インターネットのようなIPプロトコルをベースとするネットワークにおいて、通信セッションを動的に制御する方法としてセッションイニシエーションプロトコル(Session Initiation Protocol、以下ＳＩＰと略す)が知られている。ＳＩＰでは、ＳＩＰサーバと呼ばれるサーバシステムが端末からのセッション接続要求を処理中継することにより、IPネットワークを介して相互接続されている端末の間の通信セッションを確立する。ＳＩＰプロトコル上でのユーザは統一的なリソース識別子(Universal Resource Identifier、以下ＵＲＩと略す)によって識別され、ユーザは自ＵＲＩと使用しているＩＰアドレスをＳＩＰサーバ経由でロケーションサーバに登録することにより、IPネットワーク上での自らの位置、即ち自装置のＵＲＩとＩＰアドレスの対応関係、を登録する。
【０００３】
例えば特開２００２−１５２８０５号公報（特許文献１）には、ＳＩＰを利用した通信システムにおいて、呼び出し先の位置を指定することによりネットワーク上の双方向通信を可能にした技術が開示されている。とりわけこれは、ＳＩＰアドレスとＩＰアドレスとの対応情報を保持するＳＩＰサーバと、ＳＩＰアドレスと端末の位置情報との関係を保持するＳＩＰサーバの２つのサーバを用いて、端末の位置情報からＩＰアドレスを特定してセッション制御を行うものである。
【０００４】
【特許文献１】特開２００２−１５２８０５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ＳＩＰに関する技術標準や上記従来技術ではＳＩＰサーバは単一の論理機能として把握されている。すなわち、ＳＩＰサーバは収容する端末の数やセッション制御要求の頻度等の数的パラメータには依存しない構成でその機能の規定がされている。しかし、実際の適用にあたってはＳＩＰサーバの物理的な処理能力限界からＳＩＰサーバで収容する端末の数やセッション制御要求の頻度に対応限界がある。
【０００６】
Ｗｅｂサーバ等ではロードバランサの技術により同等のサーバを複数台設置し、サーバの負荷に応じて端末からの処理要求を複数のサーバに振り分けることが一般に行われている。しかし、ＳＩＰサーバの場合には、端末とその位置情報を保持するロケーションサーバは一対一に対応している必要がある。よって端末同士でＳＩＰによる通信を開始する場合には、必ず通信相手の位置情報を登録するロケーションサーバに接続されたＳＩＰサーバに通信の開始を要求するメッセージを送信しなければならず、Ｗｅｂ等のロードバランサのように負荷状況に応じて任意のサーバに処理要求を振り分けることができない。
【０００７】
また、収容する端末の数を増加させる別の手段として、メールサーバで通常行われているようにサーバを複数に分割し、それぞれにサブドメイン名を付与する方法が考えられる。しかし、ＳＩＰをベースとするサービスを利用する利用者の視点からはＵＲＩはできるだけ記憶しやすい単純な形式が望ましく、サブドメイン名＋ドメイン名のようにＵＲＩが長大となることを避けることが重要である。
【０００８】
本発明の目的は、ＵＲＩの長大化を避け、スケーラブルなＳＩＰ端末の収容を可能とし、また利用者から見ても簡単なＵＲＩでＳＩＰサービスを利用できるようにした複合セッション制御装置及び方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明は、好ましくは、ＳＩＰの手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御装置において、ＳＩＰ端末からのＳＩＰプロトコルパケットのヘッダ内容を参照し、ヘッダの少なくとも一部の情報を基に、複数のＳＩＰサーバのあるＳＩＰサーバにＳＩＰプロトコルパケットを転送するための制御を行うゲートウェイと、一部の情報を変更するための情報を登録するデータベースと、を有するように構成される。
【００１０】
また本発明は、ＳＩＰの手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御装置において、複数のＳＩＰサーバと、複数のＳＩＰサーバのいずれかにＳＩＰ端末からのＳＩＰプロトコルパケットを転送する転送手段と、複数のＳＩＰサーバに転送したＳＩＰプロトコルパケットが属するセッションＩＤと被転送ＳＩＰサーバとの対応関係を登録する記憶手段とを有し、転送手段から記憶手段の対応関係を参照して、複数のＳＩＰサーバのいずれかを選択する制御を行う。
また、一例では、ＳＩＰプロトコルパケットを転送する機能はＳＩＰプロトコルパケットの一部を解析するリゾルバ機能、アドレス情報を取得しかつＳＩＰプロトコルパケットの一部の情報または他の部分の情報を書き換えるための情報を取得するためのリダイレクタ、アドレス情報を基にＳＩＰプロトコルパケットを転送するためのスイッチを有するように構成される。
【００１１】
また、本発明に係るＳＩＰ制御方法は、ＳＩＰの手順に基づいてＩＰネットワークを介して接続されたＳＩＰ端末からの接続要求を処理するＳＩＰ制御方法において、ＳＩＰ端末から送信されるＳＩＰプロトコルパケットに含まれる送信先を指定するＵＲＩを抽出するステップと、抽出されたＵＲＩに関して、データベースを参照して、ＵＲＩに仮想的に対応付けられたＶＵＲＩを取得するステップと、ＳＩＰプロトコルパケット中のＵＲＩを、取得されたＶＵＲＩに置き換えるステップと、複数のＳＩＰサーバから選択されたあるＳＩＰサーバに、ＶＵＲＩを含むＳＩＰプロトコルパケットを送信するステップと、選択されたＳＩＰサーバでは、受信したＳＩＰプロトコルパケットに関するダイアログの処理を行い、ロケーションサーバでは、ＳＩＰ端末の位置情報の登録を行うステップと、ＶＵＲＩに関して、データベースを参照して、ＶＵＲＩに対応付けられたＵＲＩを取得するステップと、ＳＩＰプロトコルパケット中のＶＵＲＩを、取得されたＵＲＩに置き換えるステップと、作成されたＳＩＰプロトコルパケットを宛先のＳＩＰ端末へ送信するステップとを有するＳＩＰ制御方法として把握される。
【００１２】
好ましい例では、上記記ＶＵＲＩを取得するステップでは、ＶＵＲＩを処理するＳＩＰサーバのＩＰアドレスも併せて取得することを含み、ＩＰアドレスに基づいて選択されたＳＩＰサーバに対してＳＩＰプロトコルパケットを送信する。
また、好ましい例では、上記データベースは、ＳＩＰ端末のユーザ名に対応付けて、ＳＩＰプロトコルパケットに含まれて送信されるＵＲＩ，ＶＵＲＩ，登録ＩＰアドレス、及び収容ＳＩＰサーバのＩＰアドレスを登録する。
【発明の効果】
【００１３】
本発明によれば、SIPプロトコルの内容を解釈して複数のSIPサーバにセッション制御要求メッセージを振り分けるように構成することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の実施例について説明する。
図１は、一実施例によるＳＩＰ端末を用いた通信システムの構成例を示す。
インターネット１０を介してＳＩＰ端末１５がＳＩＰゲートウェイ２に接続されている。尚、図１には１台のＳＩＰ端末１５がインターネット１０に接続される例が示されているが、実際には多数のＳＩＰ端末１５が接続されて、ＳＩＰゲートウェイ２を通してそれらのＳＩＰ端末１５間で通信が行われる。
【００１５】
ＳＩＰゲートウェイ２には、複数のＳＩＰサーバ１２１、１２２、１２３（以下、番号１２で代表的に表示する）、及びサブドメイン分配データベース（ＤＢと言う）３が接続される。また各ＳＩＰサーバ１２には、それぞれロケーションサーバ１３１、１３２，１３３（以下、番号１３で代表的に表示する）が接続される。ここで、各ＳＩＰサーバ１２は、例えばＳＩＰプロキシにより構成される。尚、ＳＩＰゲートウェイ２及びサブドメイン分配データベース３の構成については、図２，３を参照して後述する。
【００１６】
ＳＩＰ端末１５からインターネット１０を介してＳＩＰゲートウェイ２にＳＩＰプロトコルにしたがったＳＩＰプロトコルパケットが入力される。
この場合、ＳＩＰ端末１５はＳＩＰゲートウェイのＩＰアドレスを論理的なＳＩＰサーバのアドレスとしてＤＮＳあるいはＤＨＣＰ（Dynamic Host Configuration Protocol）等の仕組みにより取得するものとしており、当該SIPプロトコルパケットの宛先IPアドレスはSIPゲートウェイのIPアドレスとなっている。
【００１７】
ＳＩＰゲートウェイ２は入力されたＳＩＰプロトコルパケットの内容の一部を解析し、たとえばＵＲＩを取得する。ＳＩＰゲートウェイは取得したＳＩＰ−ＵＲＩをキーとしてサブドメイン分配データベース４を参照する。ここで、サブドメイン分配データベースには各ＵＲＩに対応してそれぞれのＵＲＩのドメイン部分をサブドメイン表記した仮想的なＵＲＩであるＶＵＲＩ(Virtual ＵＲＩ)が関連付けて保持されている。このＶＵＲＩはＳＩＰサーバと一対一に対応しており、サブドメイン分配データベースにはそれぞれのＶＵＲＩに対応するＳＩＰサーバのIPアドレスも格納されている。
【００１８】
SIPゲートウェイ2は、このサブドメイン分配データベース4を参照することで、受信したSIPプロトコルパケットに含まれるURIに対応付けて格納されているVURIとIPアドレスを取得する。そしてSIPゲートウェイ2は、当該VURIとIPアドレスを有するSIPサーバ12に、SIPプロトコルパケットをリダイレクションする。ＳＩＰサーバ１２はリダイレクションされたＳＩＰプロトコルパケットを、ロケーションサーバ１３を参照しながら処理する。ＳＩＰゲートウェイ２によるリダイレクションはサブドメイン分配データベース１４を参照することにより行う。
【００１９】
図２はＳＩＰゲートウェイ２の構成例を示す。
図２において、リゾルバ２１はＳＩＰプロトコルパケットのＵＲＩ部分を解析し、リダイレクタ２３に転送する。リダイレクタ２３は接続線１０４を介してサブドメイン分配データベース３を参照し、取得したＶＵＲＩをＳＩＰリゾルバ２１に転送する。ＳＩＰリゾルバ２１はＳＩＰプロトコルパケットのＵＲＩを、得られたＶＵＲＩに変更する。またリダイレクタ２３は同様にして、取得したＩＰアドレスを元にスイッチ２２を制御し、ＳＩＰプロトコルパケットをＳＩＰサーバ(例えば１２１)への接続線２０１へ出力する。
【００２０】
図３は、サブドメイン分配ＤＢ３のデータベース構造を示す。
サブドメイン分配ＤＢ３は、ＳＩＰプロトコルパケットの一部に含まれるＵＲＩからＶＵＲＩを索引するために、或いはその逆の索引を行うために関係する情報を登録する。即ち、ユーザ名３１に対応して、ＵＲＩ３２、ＶＵＲＩ３３、登録アドレス３４、収容ＳＩＰサーバＩＰアドレス３５を登録する。
【００２１】
ここで、ユーザ名とは、ＳＩＰ−ＵＲＩの＠より前の部分をいう。ＶＵＲＩはＵＲＩのサブドメイン形式で記載されている。例えばＵＲＩがA＠XX.co.jpであると、これに対応するＶＵＲＩはA＠xx1.XX.co.jpのように、ドメインの階層を増やした形で表記される。収容ＳＩＰサーバＩＰアドレスとは、そのＳＩＰ−ＵＲＩを有するＳＩＰプロトコルパケットを実際に処理するよう割り当てられたＳＩＰサーバのＩＰアドレスをいう。
【００２２】
ＳＩＰゲートウェイ２はサブドメイン分配ＤＢ３から得たＶＵＲＩ３３および収容ＳＩＰサーバのＩＰアドレス３５を基にＵＲＩ使用ユーザの収容すべきＳＩＰサーバ１２を選択し、そのサーバへＳＩＰプロトコルパケットを転送する。その際ＳＩＰゲートウェイ２はＵＲＩをＶＵＲＩに変換する。
【００２３】
選択されたＳＩＰサーバ(例えば１２１)は、転送されたＳＩＰプロトコルパケットを通常のＳＩＰ処理手順に従って処理又は中断する。ＳＩＰサーバ１２１に接続されたロケーションサーバ１３１はＳＩＰプロトコルに従ってＳＩＰ端末１５の位置登録を行うためのものである。この場合、ロケーションサーバ１３１はVURIと収容SIPサーバIPアドレスの対応関係を登録する。
【００２４】
ＳＩＰサーバ１２により中継されたＳＩＰプロトコルパケットはＶＵＲＩで特徴づけられており、これを入力されたＳＩＰゲートウェイ２は再度サブドメイン分配データベース３を参照し、第３図に示すデータベース構造からＶＵＲＩに対応するＵＲＩおよび登録ＩＰアドレスを取得する。ＳＩＰゲートウェイ２は、取得したデータに基づいてＶＵＲＩをＵＲＩに変換して、その変換対を自らの記憶部に記憶すると共に、登録ＩＰアドレスに対して送信する。即ちこれは、例えばＳＩＰゲートウェイ２で、ＳＩＰ端末１５から受信したパケットのＳＩＰ−ＵＲＩ部分をＶＵＲＩに置き換え、ＳＩＰサーバ１２で処理後、ＳＩＰゲートウェイ２では再度ＳＩＰ−ＵＲＩに書き換えることにより行われる。
【００２５】
次に図４を参照して、ＳＩＰ端末間のＳＩＰメッセージの通信動作について概略説明する。
この例では、ＳＩＰ端末１５０からＳＩＰ端末１５１へリクエストメッセージを送信し、通信を行う例である。
ここで、リクエストメッセージは例えば以下の通りである。
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
また、ＳＩＰ端末１５１からのレスポンスメッセージは、例えば以下の通りである。
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
図４において、ＳＩＰ端末１５０から送信されるリクエストメッセージ「ＩＮＶＩＴＥ」をＳＩＰサーバ１２が受信すると、ＳＩＰサーバ１２はそのメッセージの内容を解析し、宛先ＳＩＰ/２．０に相当するＳＩＰ端末１５１へそのリクエストメッセージを送信する。
これに対して、ＳＩＰ端末１５１からは、レスポンスメッセージ「２００ＯＫ」が返送される。ＳＩＰサーバ１２はこのレスポンスを送信元のＳＩＰ端末１５０へ送信する。
【００２６】
これにより両方のＳＩＰ端末１５０，１５１間にセッションが確立したので、以後、ＳＩＰ端末１５０からＡＣＫを送信する、等の通常のＲＴＰ（Real-time Transport Protocol）に従った通信が行われる。
【００２７】
次に、図５を参照して、ＳＩＰ端末間の通信におけるセッション確立のための動作について説明する。
ＳＩＰ端末１５０から送信されるリクエストメッセージには、ＩＮＶＩＴＥ及び宛先となるＳＩＰ端末１５１を指定するＵＲＩ−Ｂを含まれるものとする。
まず、ＳＩＰゲートウェイ２がこのリクエストメッセージを受信すると、そのメッセージからＵＲＩを抽出して、そのＵＲＩ−Ｂをサブドメイン分配ＤＢ３へ送る（Ｓ５０１）。
【００２８】
サブドメイン分配ＤＢ３には、図３に示すように、ユーザ名毎にＵＲＩ/ＶＵＲＩの対応表が登録されているので、この対応表のユーザ名を参照して、ＵＲＩ−Ｂに対応するＶＵＲＩ、及びＳＩＰサーバＩＰアドレスを取得する（Ｓ５０２）。
【００２９】
ＳＩＰゲートウェイ２では、ＵＲＩを取得したＶＵＲＩに書き換え（Ｓ５０３）、更にＵＲＩとＶＵＲＩの対応を、データベースに登録する（Ｓ５０４）。更に取得したＳＩＰサーバＩＰアドレスから該当するＳＩＰサーバ（例えば１２１）を選定する。そして、ＶＵＲＩ−Ｂを含むリクエストメッセージＩＮＶＩＴＥを、該当するＳＩＰサーバ１２１へ送信する。
【００３０】
ＳＩＰサーバ１２１では、ダイアログ処理が行なわれる（Ｓ５０５）。即ちロケーションサーバ１３１に対して、ＶＵＲＩ−Ｂのアドレスを問合せて、ＳＩＰ端末１５１のＶＵＲＩ−Ｂアドレスを取得する（Ｓ５０６）。
取得されたＶＵＲＩ−Ｂアドレスは、ＳＩＰサーバ１２１からＳＩＰゲートウェイ２へ送信され、ここでＶＵＲＩがＵＲＩへ書き換えられる（Ｓ５０７）。そして、ＵＲＩ−Ｂの示す目的のＳＩＰ端末１５１へ、リクエストメッセージのパケットが転送される。
【００３１】
リクエストメッセージを受信したＳＩＰ端末１５１では、レスポンスメッセージを生成し、自らのユーザ名、２００Ｋ及び宛先のＳＩＰ端末ＵＲＩ−Ａを含むメッセージを作成して、それをＳＩＰゲートウェイ２へ返信する。
ＳＩＰゲートウェイ２では、ＳＩＰ端末１５０へレスポンスメッセージを送信するためのメッセージの解析、及び変換処理が行われる。この処理はＵＲＩ−Ａ向けへのＵＲＩからＶＵＲＩの変換処理であり、ステップＳ５０１〜Ｓ５０７で説明したものと同様の処理である（Ｓ５１０）。つまり、送信元ＵＲＩに格納されているＶＵＲＩをＵＲＩに変更して、送信元の収容ＳＩＰサーバＩＰアドレスをＳＩＰゲートウェイのＩＰアドレスに変更する。
【００３２】
そして、ＳＩＰゲートウェイ２からＳＩＰ端末１５０へ２００ＯＫ及びＵＲＩ−Ａを含むレスポンスメッセージが送信される。以後、ＳＩＰ端末１５０と１５１との間ではＲＴＰに基づく通信が行われる（Ｓ５２０）。
【００３３】
通信の終了後におけるエントリの消去処理に関しては、ＳＩＰ端末１５０から送信される、ＢＹＥ及び宛先となるＵＲＩ−Ｂを含むメッセージをＳＩＰゲートウェイ２が受信する。ＳＩＰゲートウェイ２では、先に説明した動作と同様に、ＵＲＩを抽出し（Ｓ５３１）、抽出されたＵＲＩをＶＵＲＩに書き換えて（Ｓ５３２）、それらを該当するＳＩＰサーバ１２１へ送信する。
【００３４】
ＳＩＰサーバ１２１では、先の動作と同様に、ダイアログ処理を行い（Ｓ５３３）、その後ＳＩＰゲートウェイ２で当該ＵＲＩとＶＵＲＩとの対応関係の登録消去の処理が行われる（Ｓ５３４）。即ち、図３に示す、当該ユーザ名に関係して登録されていたＵＲＩ/ＶＵＲＩの対応が消去される。
【００３５】
本実施例では、サブドメイン分配データベース３および複数のＳＩＰサーバ１２は同一の場所にあると仮定している。しかし、これらの一部または全ては地理的に異なるロケーションに存在し、その間がネットワークで接続されている構成においても処理手順に変更はなく、同様の効果が得られることは明らかである。
【００３６】
本実施例によれば、ＳＩＰプロトコルの一部のみを解析する機能を持つＳＩＰゲートウェイ２を通常のＳＩＰサーバ１２と組み合わせることにより大容量化、サブドメイン処理のユーザに対する隠蔽が可能であるという効果がある。
【００３７】
次に図６を参照して他の実施例について説明する。
以下に示す他の実施例は、ＳＩＰ端末に関するアドレスなどの情報を動的に収容する例である。すなわち、上記実施例においては、ＳＩＰ端末に関する情報を個々のＳＩＰサーバに対応するデータベース即ちロケーションサーバに固定的に収容しているが、以下に示す実施例ではＳＩＰ端末に関する情報を負荷分散ＤＢに統合して持ち、ＳＩＰサーバはこの負荷分散ＤＢを参照してセッション制御を行うものである。以下詳細に説明する。
【００３８】
インターネット１０を介してＳＩＰ端末１５がＳＩＰロードバランサ７に接続されている。ＳＩＰロードバランサ７はＳＩＰ端末１５からのＳＩＰプロトコルパケットの内容の一部を解析することによりＳＩＰサーバ１２１〜１２３のいずれかにＳＩＰプロトコルパケットをリダイレクションする。ＳＩＰサーバ１２はリダイレクションされたＳＩＰプロトコルパケットを、ロケーションサーバ１３を参照しながら処理する。ＳＩＰロードバランサ７によるリダイレクションはロケーションサーバ１３を参照することにより行う。
【００３９】
ＳＩＰ端末１５からインターネット１０を介してＳＩＰロードバランサ７にＳＩＰプロトコルにしたがったＳＩＰプロトコルパケットが入力される。この場合、ＳＩＰ端末１５はＳＩＰロードバランサ7のＩＰアドレスを論理的なＳＩＰサーバのアドレスとしてＤＮＳあるいはＤＨＣＰ等の仕組みにより取得する。
【００４０】
ＳＩＰロードバランサ７は入力されたＳＩＰプロトコルパケットの内容の一部を解析し、たとえばＵＲＩを取得する。ＳＩＰロードバランサ７は取得したＳＩＰ-ＵＲＩをキーとしてロケーションサーバ１３を参照し、サブドメイン表記された仮想的なＵＲＩとして対応づけられたＵＲＩ（ＶＵＲＩ）を取得する。
【００４１】
図７はＳＩＰロードバランサ７の構成例を示す。
リゾルバ７１はＳＩＰプロトコルパケットのＵＲＩ部分を解析し、リダイレクタ７３に転送する。リダイレクタ７３は接続線７０４を介してロケーションサーバ１３を参照し、取得したＶＵＲＩをＳＩＰリゾルバ７１に転送する。ＳＩＰリゾルバ７１はＳＩＰプロトコルパケットのＵＲＩを得られたＶＵＲＩに変更する。またリダイレクタ７３は複数のＳＩＰサーバから成るＳＩＰサーバ群１２（１２１〜１２３）の負荷状態を負荷分散データベース７４により把握しており、各ＳＩＰサーバ１２への負荷が平滑化されるようにＳＩＰプロトコルパケットを処理するためのあるＳＩＰサーバ（例えば１２１）を選択する。ここで、ＳＩＰサーバの負荷の平滑化は、例えば各ＳＩＰサーバ１２毎に処理中のセッションＩＤの数を集計しておき、そのセッションＩＤの数をお互いに比較することで行う。
選択されたＳＩＰサーバ１２１のＩＰアドレスを基にスイッチ７２を制御し、ＳＩＰプロトコルパケットをＳＩＰサーバ１２１への接続線７０１へ出力する。ロケーションサーバ３１のデータベース構造は第３図に示したとおりである。
【００４２】
図８は負荷分散データベース７４の構造を示す。
このＤＢ７４には、セッションＩＤ６０で識別されるセッションの基本情報、即ちユーザ名６１、ＵＲＩ６２、ＶＵＲＩ６３、登録ＩＰアドレス６４、それらに対応して処理を担当するＳＩＰサーバのＩＰアドレス６５、及びＳＩＰサーバの負荷状態６６が登録されている。処理担当ＳＩＰサーバの選択はＵＲＩをキーとする、あるいはセッションＩＤをキーとすることも可能である。また各ＳＩＰサーバの負荷状態は各ＳＩＰサーバで処理中のセッションＩＤの数を集計比較することにより得られる。
【００４３】
ＳＩＰロードバランサ７はロケーションサーバ１３から得たＶＵＲＩおよび収容ＳＩＰサーバのＩＰアドレスを基に当該ＵＲＩ使用ユーザ収容すべきＳＩＰサーバ１２を選択し、ＳＩＰプロトコルパケットを転送する。その際ＳＩＰロードバランサはＵＲＩをＶＵＲＩに変換する。
選択されたＳＩＰサーバ(例えば１２１)は転送されたＳＩＰプロトコルパケットを通常のＳＩＰ処理手順に従って中継または処理する。ロケーションサーバ１３はＳＩＰプロトコルに従ってＳＩＰ端末１５の位置登録を行う。
【００４４】
ＳＩＰサーバ(例えば１２２)により中継されたＳＩＰプロトコルパケットはＶＵＲＩで特徴づけられており、これを入力されたＳＩＰロードバランサ７は再度ロケーションサーバ１３を参照して、第６図に示すデータベースからＶＵＲＩに対応するＵＲＩおよび登録ＩＰアドレスを取得する。取得したデータに基づいてＳＩＰロードバランサ７はＶＵＲＩをＵＲＩに変換し、登録ＩＰアドレスに対して送信する。
【００４５】
次に、図９を参照して、図６〜８を参照した他の実施例におけるＳＩＰ端末間の通信におけるセッション確立のための動作について説明する。
この例における動作は、上述の図５に示した動作と同様のところが多々ある。図５の例と主に相違する部分は、ＳＩＰリゾルバ７１及び負荷分散ＤＢ７４における動作である。以下の説明では、ＳＩＰリゾルバ７１及び負荷分散ＤＢ７４における動作を中心に、図５との相違するところについて説明する。
【００４６】
ＳＩＰリゾルバ７１がＳＩＰ端末１５０からリクエストメッセージを受信すると、そのメッセージからＵＲＩを抽出して（Ｓ９０１）、そのＵＲＩ−Ｂをロケーションサーバ１３へ送る。
【００４７】
ロケーションサーバ１３では、図３に示すように、ユーザ名毎にＵＲＩ/ＶＵＲＩの対応表を保持しており、この対応表のユーザ名を参照して、ＵＲＩ−Ｂに対応するＶＵＲＩを抽出して、そのＶＵＲＩ−Ｂを負荷分散ＤＢ７４へ送信する（Ｓ９０２）。
負荷分散ＤＢ７４では、当該ＵＲＩと取得されたＶＵＲＩ−Ｂ及びＳＩＰサーバＩＰアドレスの対応関係を登録する。またそれらＶＵＲＩ−Ｂ及びＳＩＰサーバＩＰアドレスをＳＩＰリゾルバ７１へ送信し、そこでＵＲＩをＶＵＲＩへ書き換える（Ｓ９０４）。
【００４８】
以後の動作は、前述した図５の動作と同様であるので、説明を省略する。尚、登録消去の処理に関して、上述した例と相違するところは、ＳＩＰリゾルバ７１及び負荷分散ＤＢ７４で、当該ＵＲＩとＶＵＲＩとの対応関係の登録消去の処理が行われることである（Ｓ９３４、９３´）。
【００４９】
この例で特徴的なことは、負荷分散ＤＢ７４の処理Ｓ９０３において、複数のＳＩＰサーバ１２の負荷状態（大〜小）に応じて、当該セッションのダイアログ処理をＳＩＰサーバに割り当てられることである。ここで、負荷状態が「大」とは、接続されているセッション数が多いことを意味し、逆にそれが「小」とはセッション数が少ないことを意味する。
【００５０】
本実施例によれば、ＳＩＰプロトコルの一部のみを解析する機能を持つＳＩＰロードバランサ７を通常のＳＩＰサーバと組み合わせることにより、ＳＩＰサーバ大容量化をＵＲＩに対して処理ＳＩＰサーバを動的に割り当てる形で可能となるという効果がある。
【００５１】
次に、図１０を参照して、他の実施例によるＳＩＰ管理サーバ１１０を用いた通信システムについて説明する。この例は、図２に示したＳＩＰケートウェイ２の機能をＳＩＰ管理サーバ１１０により実現した例である。
ＳＩＰ管理サーバ１１０は、内部バス１１８に接続されたＣＰＵ１１２と、記憶部１１４と、インタフェース部１１６を有して構成される。内部バス１１８にはＳＣＳＩインタフェース等を介してサブドメイン分配ＤＢ３が接続される。また、ネットワークインタフェース１１６には複数のＳＩＰサーバ１２（図１）が接続され、所定のプロトコルに従って通信相手とデータの送受信を行う。ＣＰＵ１１２は、プログラムの実行によりＳＩＰヘッダ解析部１１２２、ＳＩＰヘッダ変換部１１２４、データベース（ＤＢ）問合せ部１１２の機能がそれぞれ実現される。
【００５２】
ＳＩＰヘッダ解析部１１２２は、ＳＩＰ端末１５から受信したＳＩＰプロトコルパケットから宛先もしくは送信元ＵＲIを抽出し、ＤＢ問合せ部１１２６に渡す。ＤＢ問合せ部１１２６は、抽出されたＵＲＩをサブドメイン分配ＤＢ３に問合せ、対応するＶＵＲＩとＩＰアドレスを取得する。ＳＩＰヘッダ変換部１１２４は、受信したＳＩＰプロトコルパケットの宛先もしくは送信元ＵＲＩをＶＵＲＩに、また宛先ＩＰアドレスを返信されたＩＰアドレスにそれぞれ変換する。記憶部１１４は、問合せに用いたＵＲＩと、サブドメイン分配ＤＢ３から返信されたＶＵＲＩとＩＰアドレスの対応関係を含むテーブルを記憶する。
【００５３】
次に、図１１を参照して他の実施例によるＳＩＰ管理サーバ１１０´を用いた通信システムについて説明する。この例は、図７に示したＳＩＰロードバランサ７の機能をＳＩＰ管理サーバ１１０´により実現した例である。図１１において、図１０と同じ符号は同一部分を示す。図１１構成では、負荷管理部１１２８が追加され、これにより負荷分散ＤＢ７４に登録された負荷状態の情報を管理する。更に、負荷状態を管理するために、記憶部１１４には、図１２に示すような、負荷管理テーブル１２００が格納される。
【００５４】
図１２において、負荷管理テーブル１２００は、収容ＳＩＰサーバＩＰアドレス１２０１に対応して、現在のセッション数１２０２を格納しており、その現在のセッション数を基準値と比較して負荷状態のレベル１２０３が決められる。即ち、ＳＩＰサーバ１２に割り当てられるセッションの数は、時々刻々と変化しているので、ＩＰアドレスごとにセッションが１つ増えれば現在のセッション数を＋１、反対に１つ減れば−１するように、現在のセッション数１２０２を反映して保持する。図示の４桁の数字は現在のセッション数を示す。そして、ＳＩＰサーバ１２に対する仕様から例えばセッション数４０００を標準とし、セッション数を１０００単位に分割して、負荷状態を複数段階に設定できるようにしている。例えば、現在のセッション数が９９９までをレベルＩ、１０００〜１９９９迄をレベルIIの如く負荷状態のレベルをＩ〜Ｖ（図示の例）のように示す。
【００５５】
図１３は、図１１のＳＩＰ管理サーバ１１０を用いた通信システムにおける動作シーケンスを示す。図１３のシーケンス図を参照しながら、図１１の通信システムの動作について説明する。
図１３の図９の違いは、図１３のＳＩＰ管理サーバ１１０´において負荷レベル確認（Ｓ１３０１）、及び負荷レベル更新（Ｓ１３０２）のステップが追加されたことである。
【００５６】
即ち、ＳＩＰ管理サーバ１１０´がＵＲＩを抽出すると（Ｓ９０１）、負荷管理部１１２８は、負荷管理テーブル１２００の負荷状態レベル１２０３を参照し、負荷状態レベルを確認する（Ｓ１３０１）。そして、例えば負荷状態レベル１２０３の一番低いものに対応する収容ＳＩＰサーバＩＰアドレスを取得する。以後の処理は図９の場合と同様である。
【００５７】
図１３のシーケンスの一連の処理が終わり、最後の処理として、負荷管理テーブル１２００の負荷状態レベル１２０３の更新動作がある。これは、図１３の一連の処理中に各ＳＩＰサーバ１２に対するセッション数が増減して、現在のセッション数１２０２も変わっているので、それに応じて負荷状態レベル１２０３も変更するようにしたものである。
【図面の簡単な説明】
【００５８】
【図１】一実施例によるＳＩＰ端末を用いた通信システムの構成を示す図。
【図２】一実施例におけるＳＩＰゲートウェイ２の構成を示す図。
【図３】一実施例におけるサブドメイン分配データベース３の構成を示す図。
【図４】一実施例によるＳＩＰ端末間のＳＩＰメッセージの通信例を示す図。
【図５】一実施例によるＳＩＰ端末間の通信におけるセッション確立のための動作例を示すシーケンス図。
【図６】他の実施例によるＳＩＰ端末を用いた通信システムの構成を示す図。
【図７】他の実施例におけるＳＩＰロードバランサ７の構成を示す図。
【図８】他の実施例における負荷分散データベース７４の構成を示す図。
【図９】他の実施例によるＳＩＰ端末間の通信におけるセッション確立のための動作例を示すシーケンス図。
【図１０】他の実施例によるＳＩＰ管理サーバ１１０を用いた通信システムの構成を示す図。
【図１１】他の実施例によるＳＩＰ管理サーバ１１０´を用いた通信システムの構成を示す図。
【図１２】他の実施例によるＳＩＰ管理サーバ１１０´を用いた通信システムにおける負荷管理テーブル１２００の構成を示す図。
【図１３】ＳＩＰ管理サーバ１１０´を用いた他の実施例におけるＳＩＰ端末間の通信におけるセッション確立のための動作例を示すシーケンス図。
【符号の説明】
【００５９】
２：ＳＩＰゲートウェイ              １２１〜１２３：ＳＩＰサーバ
１３１〜１３３：ロケーションサーバ  ３：サブドメイン分配データベース
１５：ＳＩＰ端末                    ７：ＳＩＰロードバランサ
１１０、１１０´：ＳＩＰ管理サーバ。                
【図１】
2006303754.tif 000003
【図２】
2006303754.tif 000004
【図３】
2006303754.tif 000005
【図４】
2006303754.tif 000006
【図５】
2006303754.tif 000007
【図６】
2006303754.tif 000008
【図７】
2006303754.tif 000009
【図８】
2006303754.tif 000010
【図９】
2006303754.tif 000011
【図１０】
2006303754.tif 000012
【図１１】
2006303754.tif 000013
【図１２】
2006303754.tif 000014
【図１３】
2006303754.tif 000015