JP4513604B2

JP4513604B2 - Ｓｉｐサーバ高速化アーキテクチャ

Info

Publication number: JP4513604B2
Application number: JP2005058334A
Authority: JP
Inventors: 貴史宮本; 恵理川井
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-03-03
Filing date: 2005-03-03
Publication date: 2010-07-28
Anticipated expiration: 2025-03-03
Also published as: JP2006244099A

Description

本発明はＳＩＰ(Session Initiation Protocol)に関し、特にＳＩＰサーバにおいてＳＩＰの通信を管理するために必要な情報の格納場所に関する。

企業内通信インフラのＩＰベースへの統合、ＶｏＩＰ（Voice over ＩＰ）の台頭から、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）サーバの需要が着実に伸びてきている。この中で、ＳＩＰサーバの処理速度や安定性は当然、ＳＩＰサービスを利用する側が求めるものである。

従来のＳＩＰサーバにおいては、通信において使用する情報を全てＳＩＰサーバ内メモリに格納していた。通信において使用する情報とは、加入者情報・レジストラ情報・発信フィルタ情報・着信フィルタ情報・セッション情報を指す。

加入者情報とはＳＩＰサービスを受けることができる加入者の情報を示す。レジストラ情報とは、ＲＥＧＩＳＴＥＲというリクエストメッセージにより、加入者がＳＩＰサーバに伝える自分の情報を指す。発信フィルタ情報とは、加入者ごとに、受けることができるＳＩＰサービスを限定することができる情報である。具体的には、「受けることができるＳＩＰサービス＝受けつけるリクエストメッセージ」となり、例えば「ＶｏＩＰ（ＶｏｉｃｅＯｖｅｒＩＰ）サービスを受けることができる＝ＩＮＶＩＴＥリクエストメッセージを受け付ける」となる。着信フィルタ情報とは、加入者が、ある特定のユーザからの着信を拒否するために使用する情報である。セッション情報とは、ＳＩＰプロトコルにおいて、ＩＮＶＩＴＥリクエストメッセージによりユーザとユーザの間で確立した、ＶｏＩＰセッションの情報を指す。

次に、今まで説明してきた、通信において使用する情報のそれぞれが、通信においてどう使用されるかを説明する。加入者情報にＵｓｅｒ−Ａ・Ｕｓｅｒ−Ｂが登録されていると仮定する。Ｕｓｅｒ−ＡがＲＥＧＩＳＴＥＲリクエストを送信すると、Ｕｓｅｒ−Ａが正規のユーザであるかどうかを確認するためＤＢサーバは加入者情報を検索する。Ｕｓｅｒ−Ａの情報は存在するので、ＳＩＰサーバはレジストラ情報にＵｓｅｒ−Ａの情報を書き込む。ＳＩＰサービスを利用するために、Ｕｓｅｒ−ＢがＲＥＧＩＳＴＥＲ登録を行うと、同様にレジストラ情報に書き込まれる。次に、Ｕｓｅｒ−ＢからＵｓｅｒ−ＡにＶｏＩＰセッション確立要求をするためにＩＮＶＩＴＥリクエストメッセージを送信すると、ＳＩＰサーバはレジストラ情報にＵｓｅｒ−Ｂが存在するかを確認する。存在していない場合はエラー応答を返す。存在する場合は、宛先であるＵｓｅｒ−Ａが存在するかを確認する。存在していない場合はエラー応答を返す。存在する場合は、Ｕｓｅｒ−Ａのレジストラ情報のコンタクトアドレスから位置情報を割り出す。次に発信フィルタ情報からＵｓｅｒ−ＢがＶｏＩＰサービスを利用できるかをチェックする。利用できない場合はエラー応答を返す。利用できる場合は、処理が次に進み、着信フィルタ情報からＵｓｅｒ−ＢからＵｓｅｒ−Ａ宛のリクエストメッセージが許容されるかをチェックする。許容されない場合はエラー応答を返す。許容される場合は、上記で割り出したＵｓｅｒ−Ａの位置情報宛てに、ＩＮＶＩＴＥリクエストメッセージを転送する。Ｕｓｅｒ−Ａが２００応答をし、ＩＮＶＩＴＥリクエストに了解することでセッションが確立するが、このときＳＩＰサーバはセッション情報をメモリに書き込む。

従来のＳＩＰサーバにおいては、これらの通信において使用する情報を、全てＳＩＰサーバ内のメモリに格納するという形態を取り、処理の高速化を図っていた。具体的には、全ての情報を記載した、加入者情報用ファイル・発信フィルタ情報ファイル・着信フィルタ情報ファイルをあらかじめ用意しておき、ＳＩＰサーバ起動時にそれらを全て読み込み、メモリに展開するという形態を取っている。

また、上記で説明したＳＩＰサーバのようにメモリ内に情報を持たず、外部ＤＢ（ＤａｔａＢａｓｅ）サーバを用意し、そこに通信において使用する情報を格納する形態もあった。通信において使用する情報を全てメモリ内に持とうとしたとき、登録数に限界があり、大量に登録しようとした場合、相当なスペックのサーバ機器を要求されるため、コストが非常にかかる。これらの問題を外部ＤＢサーバ化によって解決する形態である。動的に変更される可能性のあるレジストラ情報およびセッション情報のみメモリ内に格納する。特許文献１には、ロケーション情報（本明細書の「レジストラ情報」に対応）を外部ＤＢサーバに格納する形態を取っている。

以下、説明の便宜上、通信において使用する情報を全てＳＩＰサーバ内のメモリに格納する従来技術を従来技術１、通信において使用する情報を全てＳＩＰサーバ外部のＤＢサーバに格納する従来技術を従来技術２と記載する。

特開２００２−１５２８０５

上記従来技術１においては、全ての情報をメモリ内に持つため、処理の高速化は図れるが、大量情報登録を行うことはできない。従来技術１は登録数が少ないことが前提となり、そのときはリクエストメッセージ受信〜転送までの通常の処理時間は１０ｍｓであったが、登録数を増加させようとした場合はメモリ増加による処理の遅延を引き起こし、最悪の場合はＳＩＰサーバがプロセスダウンするという事象も起こりえた。登録数が多いほど、上記不具合はもっと早い段階で起こる。処理の高速化のための全情報メモリ内展開ではあったが、登録数によって処理遅延を引き起こすという結果になっていた。

また、上記従来技術２においては、外部ＤＢサーバ化によってメモリの圧迫を防いでいるが、元々の処理性能が、ＤＢアクセスにより遅くなるため、リクエストメッセージ受信〜転送までの処理時間が１００ｍｓほどかかっていた。特許文献１でも処理性能については言及されておらず、ＤＢアクセスによるリクエストメッセージ処理遅延が考えられる。

本発明において解決しようとする課題は、上記２つの従来技術がかかえていた課題を纏めて解決することである。

従来よりも大量の情報登録をするためには、メモリ圧迫を防ぐ外部ＤＢサーバ化は必須である。従って外部ＤＢサーバに格納されている情報のうちの一部であって、メモリに展開することでその後の処理の高速化が図れる情報だけをメモリ内に展開することで処理の高速化とともに使用するメモリ量の減少を実現する。

外部ＤＢサーバにアクセスすることで取得する情報と、ＳＩＰサーバのメモリに格納する情報とに二分することで、ＳＩＰサーバのメモリの増大を防ぐとともに処理の高速化を図る。

以下に、図面を参照して、本発明の実施例について説明する。

図１は、ＳＩＰサービスの発着通信制御を行うＳＩＰサーバ２を中心とした、該サービス全体のネットワーク構成を示す。ＳＩＰサーバ２およびＳＩＰ通信において使用する情報を格納した外部ＤＢサーバ３は、ＳＩＰサービスを運用する側のネットワークである運用者ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）５に接続され、運用者ＬＡＮ５はＩＰネットワーク４に接続される。また、ＳＩＰサービスを利用するユーザ端末１もＩＰネットワーク４に接続される。各ユーザ端末１は、ＲＥＧＩＳＴＥＲやＩＮＶＩＴＥといったＳＩＰリクエストメッセージをＩＰパケットでＳＩＰサーバ２に送信する。またＳＩＰサーバ２は、外部ＤＢサーバ３に格納されている情報をＳＩＰ通信において使用するために、ＩＰネットワーク４を介して外部ＤＢサーバ３にアクセスする。ＩＰネットワーク４における１ドメインにつき、１台のＳＩＰサーバ２が用意される。図１はＩＰネットワーク４の１ドメインの構成を示している。

図２は、ＳＩＰサーバ２の構成を示すブロック図である。ＳＩＰサーバ２は、ＩＰネットワーク４に繋がる各ユーザ端末１や外部ＤＢサーバ３とＩＰパケットの送受信を行うＩＰインタフェース部２１と、通信制御を行うプロセッサ２２と、プロセッサが実行する、上記通信制御用のプログラムを格納するプログラム格納メモリ２３と、上記通信制御に必要な各種テーブルを格納するためのメインメモリ２４とを備えている。プログラム格納メモリ２３には、ＲＥＧＩＳＴＥＲやＩＮＶＩＴＥなどのＳＩＰメッセージを送受信処理するＳＩＰメッセージ処理プログラム２３１と、レジストラ情報のテーブル書き込みや検索削除を行うレジストラ情報処理プログラム２３２と、セッション情報のテーブル書き込みや検索削除を行うセッション情報処理プログラム２３３と、発信フィルタ情報のテーブル書き込みや検索削除を行う発信フィルタ処理プログラム２３４と、着信フィルタ情報のテーブル書き込みや検索削除を行う着信フィルタ処理プログラム２３５と、外部ＤＢサーバ３へのテーブル検索要求などのＤＢアクセスを司るＤＢアクセスプログラム２３６が格納される。メインメモリ２４には、レジストラテーブル２４１と、セッションテーブル２４２と、発信フィルタテーブル２４３と、着信フィルタテーブル２４４が格納される。各種情報と各種テーブルについては、図４以降にて説明する。

図３は、外部ＤＢサーバ３の構成を示すブロック図である。外部ＤＢサーバ３は、ＩＰネットワーク４に繋がるＳＩＰサーバ２とＩＰパケットの送受信を行うＩＰインタフェース部３１と、ＤＢ制御を行うプロセッサ３２と、プロセッサが実行する、上記ＤＢ制御用のプログラムを格納するプログラム格納メモリ３３と、上記ＤＢ制御する対象である各種テーブルを格納するためのメインメモリ３４とを備えている。プログラム格納メモリ３３には、メインメモリ３４内のテーブル情報を検索するためのテーブル検索プログラム３３１と、外部（本実施例においてはＳＩＰサーバ２）との情報のやり取りを司る外部アクセスプログラム３３２が格納される。メインメモリ３４には、加入者テーブル３４１と、発信フィルタテーブル３４２と、着信フィルタテーブル３４３が格納されている。次に、ＳＩＰサーバ２および外部ＤＢサーバ３における各種テーブルについて説明する。

図４は、レジストラテーブル２４１の構成について示している。ＳＩＰプロトコルでは、ＲＥＧＩＳＴＥＲというリクエストメッセージにより、ユーザはＳＩＰサーバ２に自分の情報を伝えるが、その情報をレジストラ情報といい、レジストラ情報を格納するのがレジストラテーブル２４１である。ただし、以下で説明する加入者テーブルの中に存在しないユーザからのＲＥＧＩＳＴＥＲリクエストメッセージについては、ＳＩＰサーバ２はレジストラテーブル２４１への書き込みは行わず、該ユーザにはエラー応答を返す。レジストラテーブル２４１は、ＳＩＰプロトコルにおける加入者識別子であるＳＩＰ−ＵＲＩ・加入者が静的ユーザの場合はその位置情報を示すコンタクトアドレス・加入者がＳＩＰサービスを受けることができる時間を示すＥｘｐｉｒｅｓ（単位：秒）・ＳＩＰプロトコルにおけるリクエストメッセージ識別子であるＣａｌｌ−ＩＤ・同一Ｃａｌｌ−ＩＤのリクエストメッセージのカウントを示すＣｓｅｑといった情報から成る。ＳＩＰプロトコルでは、ＲＥＧＩＳＴＥＲリクエストメッセージに上記情報が全て記述されていなければならない。また、Ｅｘｐｉｒｅsに示された時間を経過すると、そのユーザのレジストラテーブル２４１はＳＩＰサーバ２により削除される。このレジストラテーブル２４１は、ＳＩＰサーバ２のメインメモリ２４で持つ。

図５は、セッションテーブル２４２の構成について示している。ＳＩＰプロトコルにおいて、ＩＮＶＩＴＥリクエストメッセージによりユーザとユーザの間でＶｏＩＰセッションを確立するが、このセッションの情報をセッション情報といい、この情報を格納するのがセッションテーブル２４２である。セッションテーブル２４２は、ＩＮＶＩＴＥ送信者のＳＩＰ−ＵＲＩ（ｆｒｏｍＳＩＰ−ＵＲＩ）・ＩＮＶＩＴＥ受信者のＳＩＰ−ＵＲＩ（ｔｏＳＩＰ−ＵＲＩ）・ＩＮＶＩＴＥ送信者のコンタクトアドレス（ｆｒｏｍＳＩＰ−ＵＲＩ）・ＩＮＶＩＴＥ受信者のコンタクトアドレス（ｔｏＳＩＰ−ＵＲＩ）・加入者がＶｏＩＰセッションを受けることができる時間を示すＳｅｓｓｉｏｎ−Ｅｘｐｉｒｅｓ（単位：秒）・ＳＩＰプロトコルにおけるリクエストメッセージ識別子であるＣａｌｌ−ＩＤ・同一Ｃａｌｌ−ＩＤのリクエストメッセージのカウントを示すＣｓｅｑといった情報から成る。Ｓｅｓｓｉｏｎ−Ｅｘｐｉｒｅsに示された時間を経過すると、そのセッションの情報はＳＩＰサーバ２により削除される。このセッションテーブル２４２は、ＳＩＰサーバ２のメインメモリ２４で持つ。

図６は、加入者テーブル３４１の構成について示している。加入者情報を格納するのが加入者テーブル３４１であり、加入者情報とはＳＩＰサービスを受けることができる加入者の情報を示す。加入者テーブル３４１は、ＳＩＰ−ＵＲＩ・加入者が動的ユーザであるか静的ユーザであるかを識別する動的/静的ユーザ種別・コンタクトアドレスから成る。ＳＩＰプロトコルでは、ＲＥＧＩＳＴＥＲというリクエストメッセージにより、加入者が自分のコンタクトアドレス等の情報をＳＩＰサーバ２に教える形態を取るが、その形態を取る加入者を動的ユーザといい、ＲＥＧＩＳＴＥＲリクエストを行わず、ＳＩＰサービス加入前からあらかじめ固定のコンタクトアドレスをＳＩＰサーバ２運用側に伝えておき、登録してもらっている加入者を、静的ユーザという。この加入者テーブル３４１は、外部ＤＢサーバ３のメインメモリ３４で持ち、あるユーザからのＲＥＧＩＳＴＥＲリクエスト時に、ＳＩＰサーバ２が検索する。

図７は、発信テーブル３４２の構成について示している。発信フィルタ情報を格納するのが発信フィルタテーブル３４２であり、発信フィルタ情報とは、加入者ごとに、受けることができるＳＩＰサービスを限定することができる情報である。具体的には、「受けることができるＳＩＰサービス＝受けつけるリクエストメッセージ」となり、例えば「ＶｏＩＰ（ＶｏｉｃｅＯｖｅｒＩＰ）サービスを受けることができる」＝「ＩＮＶＩＴＥリクエストメッセージを受け付ける」となる。発信フィルタテーブル３４２は、リクエストメッセージ発信者のＳＩＰ−ＵＲＩ・その発信者が受けることができるサービスが何であるかを数値化して示した利用サービス種別から成る。例えば、利用サービス種別が１ならＶｏＩＰサービスのみ利用可、２ならＶｏＩＰサービスとＰｒｅｓｅｎｃｅサービスを利用可・・といった分類をする。上記例において、ユーザＡの利用サービス種別が１として、ユーザＡがＰｒｅｓｅｎｃｅサービスにおけるリクエストメッセージ（例えばＳＵＢＳＣＲＩＢＥ）を送信してきたとすると、ユーザＡはＶｏＩＰサービスしか利用できないため、ＳＩＰサーバ２はエラー応答を返す。この発信フィルタテーブル３４２は、外部ＤＢサーバ３のメインメモリ３４で持ち、あるユーザからのＲＥＧＩＳＴＥＲリクエスト時に、ＳＩＰサーバ２のメインメモリ２４内に書き込まれる。テーブル構成は発信フィルタテーブル２４３も同じである。

図８は、着信フィルタテーブル３４３の構成について示している。着信フィルタ情報を格納するのが着信フィルタテーブル３４３であり、着信フィルタ情報とは、加入者が、ある特定のユーザからの着信を拒否するために使用する情報である。着信フィルタ情報は、着信者のＳＩＰ−ＵＲＩ（ｔｏＳＩＰ−ＵＲＩ）・発信者のＳＩＰ−ＵＲＩ（ｆｒｏｍＳＩＰ−ＵＲＩ）・着信者がその発信者からのリクエストを許可（Ａｌｌｏｗ）するか拒否（Ｄｅｎｙ）するかを示すパーミッションフラグから成る。パーミッションフラグがＤｅｎｙの場合、記述された発信者から着信者宛てのリクエストメッセージを、ＳＩＰサーバ２はエラー応答で返す。また、それ以外の発信者から上記着信者宛てのリクエストメッセージは通過させる。パーミッションフラグがＡｌｌｏｗの場合はその逆である。この着信フィルタテーブル３４３は、外部ＤＢサーバ３のメインメモリ３４で持ち、あるユーザからのＲＥＧＩＳＴＥＲリクエスト時に、ＳＩＰサーバ２のメインメモリ２４内に書き込まれる。テーブル構成は着信フィルタテーブル２４４も同じである。

次に図９を使用して、ＲＥＧＩＳＴＥＲリクエスト時にユーザ端末１・ＳＩＰサーバ２・外部ＤＢサーバ３間でやり取りされるメッセージについて説明する。上記で説明したように、ユーザ端末１は、ＳＩＰサービス利用時にＲＥＧＩＳＴＥＲリクエストメッセージをＳＩＰサーバ２に向けて送信し、ユーザ端末１のレジストラ情報をＳＩＰサーバ２に知らせる（９０１・９０２）。ＲＥＧＩＳＴＥＲリクエストメッセージには、レジストラ情報であるＳＩＰ−ＵＲＩ・コンタクトアドレス・Ｅｘｐｉｒｅｓ・Ｃａｌｌ−ＩＤ・Ｃｓｅｑが指定してある。

ここでＳＩＰサーバ２は、外部ＤＢサーバ３に、このユーザ端末１のＳＩＰ−ＵＲＩが加入者テーブル３４１に存在するものであるかを確認するため、検索信号を送信し（９０３）、外部ＤＢサーバはこの検索信号を受信する（９０４）。例えばＳＱＬ文を発行し、外部ＤＢサーバ３に問い合わせる。外部ＤＢサーバ３はこの検索要求に対し、該ＳＩＰ−ＵＲＩが存在するかそうでないかを検索し（９０５）、応答信号を送信する（９０６）。例えばＳＱＬ文により外部ＤＢサーバ３内の加入者テーブル３４１を検索し、ＳＱＬ文によりＳＩＰサーバ２に応答する。ＳＩＰサーバ２はこの応答信号を受信し（９０７）、もし該ＳＩＰ−ＵＲＩが加入者テーブル３４１に存在すれば、ＲＥＧＩＳＴＥＲリクエストメッセージのレジストラ情報をＳＩＰサーバ２のメインメモリ２４上にあるレジストラテーブル２４１に書き込み（９０８）、２００応答をユーザ端末１に送信する（９０９・９１０）。

またＳＩＰサーバ２は、該ＳＩＰ−ＵＲＩのユーザの発信フィルタ情報および着信フィルタ情報が外部ＤＢサーバに格納されているか否かを確認するため、外部ＤＢサーバ３に検索信号を送信する（９１１）。例えばＳＱＬ文により、外部ＤＢサーバ３に問い合わせる。外部ＤＢサーバ３はこの検索要求を受信し（９１２）、発信フィルタ情報と着信フィルタ情報が存在するかそうでないかを検索して（９１３）応答信号を送信する（９１４）。例えばＳＱＬ文により外部ＤＢサーバ３内の発信フィルタテーブル３４２および着信フィルタテーブル３４３を検索し、ＳＱＬ文によりＳＩＰサーバ２に応答する。

ＳＩＰサーバ２はこの応答信号を受信し（９１５）、もし該発信フィルタ情報および着信フィルタ情報が存在すれば、ＳＩＰサーバ２内の発信フィルタテーブル２４３および着信フィルタテーブル２４４に書き込む（９１６）。なお、ＳＩＰサーバ２が２００応答を送信することと、発信フィルタ情報および着信フィルタ情報を外部ＤＢサーバ３に問い合わせることは、同期を取る必要はない。２００応答は、加入者テーブル３４１に情報がある時点で返して良いものであるからである。

次に図１０を使用して、ＩＮＶＩＴＥリクエスト時に発側ユーザ端末１a・ＳＩＰサーバ２・着側ユーザ端末１b間でやり取りされるメッセージについて説明する。このやり取りにおいて、外部ＤＢサーバ３は登場しない。上記で説明したように、発側ユーザ端末１aは、ＳＩＰのＶｏＩＰサービス利用時にＩＮＶＩＴＥリクエストメッセージをＳＩＰサーバ２に向けて送信する（１００１・１００２）。ＩＮＶＩＴＥリクエストメッセージには宛先が示されているため、それを元に、ＳＩＰサーバ２のメインメモリ２４上にあるレジストラテーブル２４１・発信フィルタテーブル２４３・着信フィルタテーブル２４４を検索し、ＶｏＩＰ相手の着側ユーザ端末１bに転送する。

具体的には、ＩＮＶＩＴＥリクエストメッセージには、セッション情報であるｆｒｏｍＳＩＰ−ＵＲＩ・ｔｏＳＩＰ−ＵＲＩ・ｆｒｏｍコンタクトアドレス・ｔｏコンタクトアドレス・Ｓｅｓｓｉｏｎ−Ｅｘｐｉｒｅｓ・Ｃａｌｌ−ＩＤ・Ｃｓｅｑが指定してある。ＳＩＰサーバ２はＩＮＶＩＴＥを受信すると、ｆｒｏｍＳＩＰ−ＵＲＩが存在するかを確認する。これは、該ＳＩＰ―ＵＲＩがレジストラテーブル２４１に登録されているか（ＲＥＧＩＳＴＥＲ済みであるか）を確認するためである。されていない場合は、エラー応答を発側ユーザ端末１aに送信する。

次に、ｔｏＳＩＰ−ＵＲＩの位置情報を割り出すため、ｔｏＳＩＰ−ＵＲＩをキーに、レジストラテーブル２４１を検索する。レジストラテーブル２４１に該情報がない場合は、エラー応答を発側ユーザ端末１aに送信する。ある場合は、ｔｏＳＩＰ-ＵＲＩのコンタクトアドレスを記憶しておく。次に、ＳＩＰサーバ２内の発信フィルタテーブル２４３を検索する。利用サービス種別からｆｒｏｍＳＩＰ-ＵＲＩがＩＮＶＩＴＥサービス利用可能ユーザであるかを確認するためである。ＩＮＶＩＴＥサービス利用可能ユーザでない場合は、エラー応答を発側ユーザ端末１aに送信する。ある場合は、サービス利用可能と判断し、次の処理に進む。

次に、ＳＩＰサーバ２内の着信フィルタテーブル２４４を検索する。該ＩＮＶＩＴＥリクエストメッセージのｆｒｏｍＳＩＰ-ＵＲＩ・ｔｏＳＩＰ−ＵＲＩの組み合わせが、パーミッションフラグ「ｄｅｎｙ」として着信フィルタテーブル２４４に登録されている場合は、エラー応答を発側ユーザ端末１aに送信する。ない場合は、上記で記憶したｔｏＳＩＰ-ＵＲＩのコンタクトアドレス宛て、つまり着側ユーザ端末１b宛てにＩＮＶＩＴＥを転送する（１００３・１００４・１００５）。ＩＮＶＩＴＥを受信した着側ユーザ端末１bは、２００応答を返して（１００６）ＳＩＰサーバ２がそれを受信（１００７）、ＳＩＰサーバ２は２００応答を発側ユーザ端末１aに転送して（１００８）発側ユーザ端末１aはそれを受信する（１００９）。ＳＩＰサーバ２は２００応答転送後、セッションテーブル２４２にセッション情報を書き込む（１０１０）。

図９と図１０を比較して分かるように、ＲＥＧＩＳＴＥＲのときのみ、ＳＩＰサーバ２から外部ＤＢサーバ３へのアクセスがあり、ＳＩＰサービス利用時、例えばＶｏＩＰサービス（ＩＮＶＩＴＥ）利用時では、ＳＩＰサーバ２から外部ＤＢサーバ３へのアクセスがなくメモリ内の情報を検索するため、処理が高速である。ＲＥＧＩＳＴＥＲは、ＳＩＰサービスを利用したいユーザ側が最初に実施するものである（例えばユーザ端末１のＳＩＰアプリケーションを立ち上げたときにＲＥＧＩＳＴＥＲ送信）。最初の１回のみＤＢアクセスが発生するため処理が若干遅くなるが、それ以降はメモリ内の情報を検索するために処理が高速だということである。また、ＲＥＧＩＳＴＥＲ時に、そのＲＥＧＩＳＴＥＲを送信してきたユーザの分のみのフィルタ情報をメモリに読むため、必要な情報のみをメモリ内に持つことができ、リソースの効率的な活用ができている。

次に図１１を使用して、ＳＩＰサーバ２および外部ＤＢサーバ３の処理フローチャートについて説明する。ＳＩＰプロトコルにはＳＵＢＳＣＲＩＢＥやＭＥＳＳＡＧＥなどのリクエストも存在するが、説明の便宜上、ＲＥＧＩＳＴＥＲとＩＮＶＩＴＥのみとして以下説明する。ユーザ端末１がリクエストメッセージを送信すると、ＳＩＰサーバ２はＩＰインタフェース部２１を介してパケットを受信し（１１０１）、ＲＥＧＩＳＴＥＲかＩＮＶＩＴＥかのパケット種別を判別する。

ＲＥＧＩＳＴＥＲの場合は、外部ＤＢサーバ３に、ＲＥＧＩＳＴＥＲリクエストメッセージに記述されるＳＩＰ−ＵＲＩが加入者テーブル３４１に登録されているかを検索するために、外部ＤＢサーバ３にＩＰインタフェース部２１を介して要求し、該ＳＩＰ−ＵＲＩが加入者テーブル３４１に加入者として登録されているかを、外部ＤＢサーバ３からＩＰインタフェース部２１を介して応答を受ける（１１０２）。ここで、該ＳＩＰ−ＵＲＩが加入者テーブル３４１に存在していなかった場合は、ユーザ端末１にエラー応答を送信する（１１０４）。存在していた場合は、ＲＥＧＩＳＴＥＲリクエストメッセージに記述されたレジストラ情報をレジストラテーブル２４１に書き込み（１１０３）、ユーザ端末１に２００応答を送信する（１１０５）。次にＳＩＰサーバ２は、ＩＰインタフェース部２１を介して外部ＤＢサーバ３に、該ＳＩＰ−ＵＲＩのフィルタ情報（発信フィルタ情報・着信フィルタ情報）を問い合わせ、外部ＤＢサーバ３内部のフィルタテーブル（発信フィルタテーブル３４２・着信フィルタテーブル３４３）に該ＳＩＰ−ＵＲＩの情報があればその情報を、ない場合はその旨、外部ＤＢサーバ３からＩＰインタフェース部２１を介して応答を受ける（１１０６）。ＳＩＰサーバ２は、フィルタ情報がない場合は何も書き込まず（１１０８）、フィルタ情報がある場合は内部のフィルタテーブル（発信フィルタテーブル２４３・着信フィルタテーブル２４４）に書き込みを行う（１１０７）。

ＩＮＶＩＴＥの場合は、外部ＤＢサーバ３へのアクセスはなく、全てＳＩＰサーバ２内部の処理となる。ＩＮＶＩＴＥのｆｒｏｍＳＩＰ−ＵＲＩをキーとして、レジストラテーブル２４１に該ｆｒｏｍＳＩＰ−ＵＲＩの情報があるかないかを検索する（１１０９）。ない場合は、ユーザ端末１にエラー応答を送信する（１１１１）。ある場合は、ｔｏＳＩＰ−ＵＲＩをキーとして、レジストラテーブル２４１を検索する（１１１０）。ない場合は、ユーザ端末１にエラー応答を送信する（１１１３）。ある場合は、該ｔｏＳＩＰ−ＵＲＩのコンタクトアドレスを、ＩＮＶＩＴＥ転送処理のために記憶しておく（１１１２）。

次に、発信フィルタテーブル２４３を、ｆｒｏｍＳＩＰ−ＵＲＩをキーとして検索する（１１１４）。該ｆｒｏｍＳＩＰ−ＵＲＩの利用サービス種別がＩＮＶＩＴＥを制限するものの場合は、ユーザ端末１にエラー応答を送信する（１１１６）。そうでない場合は、着信フィルタテーブル２４４を、ｆｒｏｍＳＩＰ−ＵＲＩとｔｏＳＩＰ−ＵＲＩをキーとして検索する（１１１５）。着信フィルタテーブル２４４に、該ｆｒｏｍＳＩＰ−ＵＲＩからｔｏＳＩＰ−ＵＲＩへのリクエストを制限するような情報があった場合、ユーザ端末１にエラー応答を送信する（１１１８）。ない場合、上記で記憶しておいた該ｔｏＳＩＰ−ＵＲＩのコンタクトアドレス宛てに、ＩＮＶＩＴＥを転送する（１１１７）。なお、着信側のユーザ端末１が２００応答を送信してきた場合は、その２００応答を発信側ユーザ端末１に転送し、かつセッションテーブル２４２に該セッション情報を書き込む処理が入るが、本発明の本質ではないため、図１１および１２には記載していない。

以上の実施例のような構成を取ることにより、加入者情報・発信フィルタ情報・着信フィルタ情報について、現在ＳＩＰサービス利用者の情報のみをメモリ内に持つため、従来技術１のようにＳＩＰサーバが使用しない、無駄な情報をメモリ内に持たず、メモリの有効活用を実現している。従来のように全てをメモリ内に持とうとしたときに要求されるハイスペックなサーバ機器も必要なく、コストパフォーマンスも良いといえる。

また、ＲＥＧＩＳＴＥＲリクエストメッセージ処理時のみ、加入者ＳＩＰ−ＵＲＩの参照のためのＤＢアクセスが行われ、処理速度が落ちるが、それ以外のＩＮＶＩＴＥ・ＳＵＢＳＣＲＩＢＥリクエストメッセージや発信/着信フィルタ処理は、メモリ内に必要な情報を持つため、処理が高速になる。従来技術２のように、外部ＤＢサーバ化を行っただけの構成では、メモリの低減は狙えても、ＤＢアクセスによる性能劣化が起こる問題が残ってしまっていたが、その問題をも解決する。具体的には、加入者情報８００００件登録、レジストラ情報８０００件登録、発信/着信フィルタ情報８００００件登録、セッション情報４０００件登録をおこない、リクエストメッセージ受信〜転送までの処理時間１０ｍｓを実現している。

ネットワーク全体構成図の一実施例を示す図である。ＳＩＰサーバの機能ブロックの一実施例を示す図である。ＤＢサーバの機能ブロックの一実施例を示す図である。レジストラテーブルの一実施例を示す図である。セッションテーブルの一実施例を示す図である。加入者テーブルの一実施例を示す図である。発信フィルタテーブルの一実施例を示す図である。着信フィルタテーブルの一実施例を示す図である。ＲＥＧＩＳＴＥＲ処理の一実施例を示す図である。ＩＮＶＩＴＥ処理の一実施例を示す図である。ＳＩＰサーバの処理フローチャートの一実施例を示す図である。

符号の説明

２ＳＩＰサーバ
３外部ＤＢサーバ
２４１レジストラテーブル
２４２セッションテーブル
２４３、３４２発信フィルタテーブル
２４４、３４３着信フィルタテーブル
３４１加入者テーブル

Claims

通信端末間のセッションの開始と終了を管理するＳＩＰサーバと、
前記通信端末間のセッションの設定に使用する情報を保持する外部ＤＢサーバとを有し、
前記ＳＩＰサーバは、通信端末から登録を要求するメッセージを受信した場合に、当該通信端末の加入者情報を前記外部ＤＢサーバに問い合わせて取得し、当該取得した加入者情報を自装置のメモリに保持し、前記通信端末に登録応答を送信し、
当該登録応答と非同期で、当該通信端末の加入者ごとに受けることができるＳＩＰサービスを限定する発信フィルタ情報、及び、加入者が特定のユーザからの着信を拒否するために使用する着信フィルタ情報を前記外部ＤＢサーバに問い合わせて取得し、取得した前記発信フィルタ情報および前記着信フィルタ情報を自装置のメモリに保持することを特徴とするセッション管理システム。
請求項１に記載のセッション管理システムにおいて、
前記登録を要求するメッセージはＲＥＧＩＳＴＥＲメッセージであることを特徴とする
セッション管理システム。