JP2010193124A - Ｉｍｓにおけるセッション制御システム - Google Patents

Abstract

【課題】ＩＭＳにおいて，より改善された負荷分散の仕組みを持ち，管理者の負担を減らし，ユーザへのサービスレベルを向上させるセッション制御の仕組みが求められている。
【解決手段】各々のＩ−ＣＳＣＦサーバは，ユーザ端末へのＳ−ＣＳＣＦサーバの割り当て情報を管理するユーザ管理リストを備え，一つのユーザ端末への割り当て情報は，いずれか一つのＩ−ＣＳＣＦサーバが管理するユーザ管理リストで管理され，各々のＩ−ＣＳＣＦサーバは，一つのユーザ端末への割り当て情報がいずれのＩ−ＣＳＣＦサーバが備えるユーザ管理リストで管理されているか，を特定するために用いるＩ−ＣＳＣＦ管理テーブルを備える。
【選択図】図１

Description

本発明は，インターネット通信サーバ技術に関し，ユーザ情報を，セッション制御を行う複数のＳＩＰ（Session Initiation Protocol）サーバに振り分ける技術に関する。

近年，各国の固定電話事業者や携帯電話事業者らによって，従来回線交換網で提供していた電話等のサービスを，ＩＰ（Internet Protocol）ネットワークをベースとするパケット交換網で提供するための，ＮＧＮ（Next Generation Network）と呼ばれる次世代通信システムの検討や構築といった取り組みが進められている。

ＮＧＮでは，通話先の電話番号からのＩＰアドレスの特定や，通信接続の設定や開放などの呼制御に，ＳＩＰ（Session Initiation Protocol）と呼ばれるプロトコルが用いられる。このＳＩＰをベースに様々なマルチメディアサービスを実現するための共通プラットフォームが，ＩＰマルチメディアサブシステム（IP Multimedia Subsystem，以下ＩＭＳという）と呼ばれるアーキテクチャである。（非特許文献１参照）
ＩＭＳは，主に，Ｐ−ＣＳＣＦ（Proxy-CSCF, Proxy Call Session Control Function），Ｉ−ＣＳＣＦ（Interrogating-CSCF, Interrogating Call Session Control Function），Ｓ−ＣＳＣＦ（Serving-CSCF, Serving Call Session Control Function）と呼ばれる機能を備えた基幹ＳＩＰサーバ群と，ＨＳＳ（Home Subscriber Server）と呼ばれる加入者情報管理データベースと，ＳＬＦ（Subscription Locator Function）と呼ばれる，加入者情報がどのＨＳＳに登録されているかを検索するためのデータベースを含んで構成される。

Ｐ−ＣＳＣＦは，ユーザ端末から接続され，ユーザ端末からのＳＩＰメッセージを受信し，Ｉ−ＣＳＣＦ及びＳ−ＣＳＣＦに中継する。

Ｉ−ＣＳＣＦは，ユーザ端末からのＩＰアドレス登録（REGISTER要求）時や，他のユーザ端末からのＩＰ電話着信時に，まずＳＬＦにアクセスして，対象となるユーザの加入者情報が登録されているＨＳＳを特定する。そして，特定したＨＳＳにアクセスし，格納されている加入者情報を取得する。この加入者情報の中には，Ｓ−ＣＳＣＦが複数台ある場合に，どのＳ−ＣＳＣＦが該ユーザを担当するか，という情報も含まれている。Ｉ−ＣＳＣＦは，その情報に基づき，該ユーザを担当するＳ−ＣＳＣＦに処理を引き継ぐ。

Ｓ−ＣＳＣＦは，ＳＩＰ登録サーバとして，ＨＳＳから受信した加入者情報や，ユーザ端末の現在のＩＰアドレスを管理し，また，ユーザ間のＩＰ電話におけるセッション制御を行う。

なお，ＩＭＳを構成する一つ以上のサーバ装置は，それぞれが，Ｐ−ＣＳＣＦ，Ｉ−ＣＳＣＦ，Ｓ−ＣＳＣＦの各機能のいずれか一つを備えるように，構成しても良いし，一つのサーバ装置が，任意の複数の機能を備えても良い。また，一つのサーバ装置がいずれかの機能を複数備え，負荷分散させても良い。以下では，上記各機能がそれぞれ独立したサーバ装置に備わった，Ｐ−ＣＳＣＦサーバ，Ｉ−ＣＳＣＦサーバ，ＳＣＳＣＦサーバについて説明する。

ＳＩＰによるＩＰ通信（例えば電話）の処理は次のように行われる。通話の開始する側のユーザ端末を発側，通話を受けるユーザ端末を着側と表記する。

まず，発側のユーザ端末から通話の開始を示すＳＩＰメッセージが，発側のＰ−ＣＳＣＦ，Ｓ-ＣＳＣＦ，そして着側のＩ−ＣＳＣＦを順に介して中継される。Ｉ−ＣＳＣＦは，ＳＩＰメッセージに含まれる通話先ＳＩＰ−ＵＲＩを元に，通話先のユーザ端末を担当する着側Ｓ−ＣＳＣＦがどれであるか，をＨＳＳへ問い合わせ，その着側Ｓ−ＣＳＣＦ及び着側Ｐ−ＣＳＣＦを介して通信端末へ送信する。このようにＩＭＳでは，ユーザ端末が通話するために，各種ＣＳＣＦサーバ群とＨＳＳが利用される。

ここで，ＩＭＳでは，ユーザ端末のホームネットワークに配置されている複数台のＳ−ＣＳＣＦの中から，各ユーザ端末のセッション制御を担当するＳ−ＣＳＣＦを決定する手続きが必要になる。この手続きに関して，従来の技術では，以下の方法で実現していた。

（方法１）ユーザ端末からのREGISTER要求を受信したＰ−ＣＳＣＦが，Ｉ−ＣＳＣＦに対して問い合わせを行う。問い合わせを受信したＩ−ＣＳＣＦは，まずＳＬＦにアクセスして，ユーザの加入者情報が登録されているＨＳＳを特定し，そのＨＳＳに対し，ホームネットワークに属するＳ−ＣＳＣＦリストを要求し，受信する。

Ｉ−ＣＳＣＦは，あらかじめ定めた一定の順序で，受信したリストに基づき，登録要求を送信してきたユーザ端末の登録を担当するＳ−ＣＳＣＦを決定する。（特許文献１段落0037参照）そして決定したＳ−ＣＳＣＦを，ユーザ端末に対応させて，ＨＳＳに登録する。

（方法２）方法１と異なる点は，ＨＳＳが，Ｓ−ＣＳＣＦ毎に，ユーザ端末を割り当てるための優先度情報を管理し，割り当て優先度を，各Ｓ−ＣＳＣＦにおけるユーザ端末の登録数や負荷発生状況に応じて決定する点である。（方法１）において，Ｉ−ＣＳＣＦからＳ−ＣＳＣＦリスト要求を受けてＩ−ＣＳＣＦに転送する際に，方法２では，ＨＳＳが割り当て優先度に応じて割り当てるべきＳ−ＣＳＣＦを決定し，要求元のＩ−ＣＳＣＦに応答する。Ｉ−ＣＳＣＦは，ＨＳＳが決定したＳ−ＣＳＣＦを，ユーザ端末に割り当てる。（特許文献１参照）

特開２００８−２３６１８３号公報

Gonzalo Camarillo and Miguel A. Garcia-martin, "The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds", John Wiley & Sons Inc., 2004.

ＩＭＳでは，ユーザ端末のホームネットワークに配置されている複数台のＳ−ＣＳＣＦの中から，各ユーザ端末のセッション制御を担当するＳ−ＣＳＣＦを決定する手続きが必要になる。しかしながら，前述の手法には，以下のような問題がある。
・方法１では，各Ｓ−ＣＳＣＦ間で，登録するユーザ端末の個数を均等に配分することができず，特定のＳ−ＣＳＣＦに負荷が集中する可能性がある。また，従来システムでは，ユーザ端末からの登録要求をＳ−ＣＳＣＦに中継するまでに，Ｉ−ＣＳＣＦはまずＳＬＦにアクセスしＨＳＳを特定し，次に，特定したＨＳＳにアクセスしてＳ−ＣＳＣＦを特定する必要がある。そのため，２回のリモートアクセスが必要となり，結果，それらのアクセスの遅延時間によって，ユーザへの応答時間が長くなってしまうという問題がある。
・方法２では，ＨＳＳが各Ｓ−ＣＳＣＦのユーザ端末登録数情報や負荷情報を一括して管理するため，ユーザ端末数が増えると，ＨＳＳ自体への問い合わせが集中し負荷が重くなってしまう。この場合，ＳＬＦが，ユーザの加入者情報が登録されているＨＳＳを応答することで，ＨＳＳを分散させることができるが，その場合でも，ＳＬＦへの問い合わせが集中し負荷が重くなってしまうため，解決にはならない。さらに，ＳＬＦ用のサーバを用意しなければならないため，設備コストが高くなってしまう，という新たな課題も生じる。

以上をまとめると，従来のＩＭＳには，解決すべき以下の課題がある。
（課題１）複数台のＳ−ＣＳＣＦで負荷を分散していても，特定のＳ−ＣＳＣＦに負荷が偏る可能性がある。
（課題２）従来システムでは，ユーザ端末からの登録要求をＳ−ＣＳＣＦに中継するまでに，２回リモートアクセスが必要なため，ユーザへの応答時間が長くなり，サービスの低下につながる。
（課題３）ユーザ端末数が増えると，どのユーザ端末がどのＳ−ＣＳＣＦに登録されているかを管理するＨＳＳへの負荷が集中し，その対策のための設備投資コストが増大したり，ユーザにとってはレスポンスが低下するなど，サービスが低下したりする。
（課題４）Ｓ−ＣＳＣＦを増設した場合，既存Ｓ−ＣＳＣＦから増設Ｓ−ＣＳＣＦへのデータの移動が必要になり，Ｓ−ＣＳＣＦに対する負担が大きい。

すなわち，ＩＭＳにおいて，より改善された負荷分散の仕組みを持ち，管理者の負担を減らし，ユーザへのサービスレベルを向上させるセッション制御の仕組みが求められている。

本発明は，以下の特徴を備えるセッション制御システムを提供する。

（特徴１）本発明のセッション制御システムにおけるＩ−ＣＳＣＦは，それぞれがシステムに含まれるＳ−ＣＳＣＦに関する情報（ＩＰアドレスなど）を管理するＳ−ＣＳＣＦ管理リストを持つ。各Ｉ−ＣＳＣＦは，その項目の一つである"登録ユーザ数"にて，各Ｓ−ＣＳＣＦに登録されているユーザ端末の数を，独自に管理する。各Ｉ−ＣＳＣＦは，新規ユーザ端末の情報を登録するＳ−ＣＳＣＦを選択する際に，自身が持つＳ−ＣＳＣＦ管理リストに登録されている，ユーザ端末の数が最も少ないＳ−ＣＳＣＦに決定する。

登録ユーザ数が少ない＝負荷が軽いと考えられることから，上記方法により，新規ユーザ端末を，負荷が軽いＳ−ＣＳＣＦに登録させることが可能になるので，負荷の偏りを防ぐことが可能になる。なお，新たに登録した新規ユーザ端末数は，他のＩ−ＣＳＣＦが管理するＳ−ＣＳＣＦの登録ユーザ数には反映させないので，各Ｉ−ＣＳＣＦが持つ管理リストの登録ユーザ数は異なる。しかしながら，各Ｉ−ＣＳＣＦにおいて登録ユーザ数が均等になるように，新規ユーザを登録させるので，全体の登録ユーザ数も，ほぼ均等になることが期待でき，負荷の偏りを防ぐことが可能になる。

また，上述のとおり，Ｉ−ＣＳＣＦは，自身が持つＳ−ＣＳＣＦ管理リストを参照することにより，登録先のＳ−ＣＳＣＦを決定するので，Ｓ−ＣＳＣＦ管理リストへのアクセスも負荷分散することが可能となる。

本特徴１により，上記課題１を解決することが可能になる。

（特徴２）本発明のセッション制御システムにおけるＩ−ＣＳＣＦは，どのユーザ端末がどのＳ−ＣＳＣＦに登録されているかを管理するユーザ管理リストを持つ。あるＳ−ＣＳＣＦに登録されたユーザ端末は，このユーザ管理リストにより管理される。これにより，Ｓ−ＣＳＣＦを増設した場合でも，増設したＳ−ＣＳＣＦへのデータ移動を行う必要が無い。また，従来ＨＳＳで管理していた「ユーザのＩＰアドレス等の情報はどのＳ−ＣＳＣＦに登録されているか」という加入者情報を，Ｉ−ＣＳＣＦだけで管理することができるので，これにより，ＳＬＦが不要になり，またＨＳＳへの問い合わせのためのアクセスが減って，負荷が軽くなり，高速応答が可能になる，という効果が得られる。

本特徴２により，上記課題４を解決することが可能になる。

（特徴３）本発明のセッション制御システムは，前述のユーザ管理リストを１つのＩ−ＣＳＣＦで集中管理せず，複数Ｉ−ＣＳＣＦで分散管理する。これを実現するために，ＳＩＰ−ＵＲＩと，ユーザ管理リストを管理するＩ−ＣＳＣＦとの対応関係を，それぞれのＩ−ＣＳＣＦで管理する。対応関係を実現する方法として，例えば，以下の文献に開示されているコンシステント・ハッシュ法を応用する。
（１）米国特許第６４３０６１８号明細書
（２）"Tom White's Blog: Consistent Hashing"，［online］，［２００９年１月２２日検索］，インターネット＜URL：http://weblogs.java.net/blog/tomwhite/archive/2007/11/consistent_hash.html＞
具体的には，予め，システムの管理者は，各Ｉ−ＣＳＣＦのＩＤをハッシュ関数に入力してハッシュ値を求め，求めたハッシュ値を降順または昇順に並べたテーブルを作成しておく。アクセス元であるユーザ端末からの要求を受けたＩ−ＣＳＣＦは，ユーザＩＤとしてユーザ端末のＩＤ（例えば，ＳＩＰ−ＵＲＩ）のハッシュ値を，Ｉ−ＣＳＣＦのＩＤのハッシュ値と同じ長さのハッシュ値を出力するハッシュ関数を用いて計算し，得られたハッシュ値以上（または以下）の値でかつ最も近い値を持つＩ−ＣＳＣＦを，そのユーザ端末に関するユーザ管理リストを管理するＩ−ＣＳＣＦに決定する。ユーザ端末からの要求を受けたＩ−ＣＳＣＦは，その決定したＩ−ＣＳＣＦに対し，そのユーザ端末に関するユーザ管理リストの内容を要求する。

ユーザ管理リスト内容の要求を受信したＩ−ＣＳＣＦは，そのユーザ端末がまだいずれのＳ−ＣＳＣＦにも登録されていない場合，前述の特徴１に従ってＳ−ＣＳＣＦをユーザ端末に割り当てる。また，既に登録されている場合は，そのユーザ管理リストに登録されている，アクセス元ユーザ端末の内容を，要求元のＩ−ＣＳＣＦに応答する。この方法によれば，ユーザ端末数が増えても，ユーザ管理リストへのアクセスを各Ｉ−ＣＳＣＦに負荷分散することが可能となる。

また，ユーザ端末数の増加に伴ってＩ−ＣＳＣＦを増設する場合でも，Ｉ−ＣＳＣＦが管理するユーザ情報の内，一部の情報を移動するだけでよく，処理が簡単になる。具体的には，例えば，Ｉ−ＣＳＣＦのＩＤのハッシュ値が次に大きい（または次に小さい）Ｉ−ＣＳＣＦが管理するユーザ情報のうち，ユーザ端末ＩＤのハッシュ値が，新たなＩ−ＣＳＣＦのＩＤのハッシュ値以下（または以上）であるユーザ情報を移動すればよい。

本特徴３により，上記課題３を解決することが可能になる。また，本特徴３では，データの配置そのものを対象とするのではなく，データの管理をする情報（ユーザ管理リスト）の配置を対象としている。このため，上記文献に開示されている方法とは異なり，Ｓ−ＣＳＣＦ間でのデータの移動が発生しない。一般的に，Ｓ−ＣＳＣＦはデータベースを備える負荷の重いサーバであるから，本特徴３によれば，サービス中にデータベース上のデータを移動，削除するような重い処理の回避も可能になる。

また，上記特徴２及び特徴３を組み合わせることで，「ユーザの加入者情報がどのＩ−ＣＳＣＦに登録されているか」という情報をＩ−ＣＳＣＦだけで管理することができるようになる。したがって，ユーザ端末からの登録要求をＳ−ＣＳＣＦに中継するためには，Ｉ−ＣＳＣＦは，当該ユーザのユーザ管理リストを管理するＩ−ＣＳＣＦに１回アクセスするだけで良い。すなわち，従来ＳＬＦは不要になるため，設備コストを削減でき，かつ，リモートアクセスの遅延時間が短くなるため，ユーザへの応答時間を短縮することができる。

上記組み合わせにより，上記課題２を解決することが可能になる。

より具体的な本発明の態様は，複数のＩ−ＣＳＣＦサーバと複数のＳ−ＣＳＣＦサーバとを備え，ユーザ端末との間でＳＩＰ通信を行い，前記ユーザ端末の登録及びセッション制御を，当該ユーザ端末に割り当てられたいずれかの前記Ｓ−ＣＳＣＦサーバが担当するＩＭＳにおけるセッション制御システムであって，
当該ＩＭＳにおけるセッション制御システムは，
各々の前記Ｉ−ＣＳＣＦサーバは，前記ユーザ端末への前記Ｓ−ＣＳＣＦサーバの割り当て情報を管理するユーザ管理リストを備え，
一つの前記ユーザ端末への前記割り当て情報は，いずれか一つの前記Ｉ−ＣＳＣＦサーバが管理する前記ユーザ管理リストで管理され，
各々の前記Ｉ−ＣＳＣＦサーバは，一つの前記ユーザ端末への前記割り当て情報がいずれの前記Ｉ−ＣＳＣＦサーバが備える前記ユーザ管理リストで管理されているか，を特定するために用いるＩ−ＣＳＣＦ管理テーブルを備える，ことを特徴とする。

さらに，当該ＩＭＳにおけるセッション制御システムは，
前記ＳＩＰ通信におけるＳＩＰメソッドにおいて，ユーザ端末に割り当てられた前記Ｓ−ＣＳＣＦサーバの特定を要求された前記Ｉ−ＣＳＣＦサーバは，対象となるユーザ端末への前記割り当て情報を管理するべきＩ−ＣＳＣＦサーバを，前記Ｉ−ＣＳＣＦ管理テーブルに基づき特定し，
特定した前記Ｉ−ＣＳＣＦサーバへ，前記対象となるユーザ端末への前記割り当て情報を要求し，
要求された前記Ｉ−ＣＳＣＦサーバは，自身が管理する前記ユーザ管理リストに基づき，前記対象となるユーザ端末への前記割り当て情報を応答する，という特徴を備えても良い。

さらに，当該ＩＭＳにおけるセッション制御システムにおいて，
前記Ｉ−ＣＳＣＦ管理テーブルは，前記Ｉ−ＣＳＣＦサーバの識別子を第一のハッシュ関数に入力して得たハッシュ値と，前記Ｉ−ＣＳＣＦサーバと通信するための情報とを対応付けたものであり，
前記Ｓ−ＣＳＣＦサーバの特定を要求されたＩ−ＣＳＣＦサーバは，前記対象となるユーザ端末の識別子を，前記ハッシュ値と同じ長さのハッシュ値を出力する第二のハッシュ関数に入力して，ユーザ端末の識別子のハッシュ値を求め，
前記ユーザ端末識別子のハッシュ値と，前記Ｉ−ＣＳＣＦ管理テーブルとに基づき，要求された前記Ｓ−ＣＳＣＦサーバを特定する，という特徴を備えても良い。

さらに，当該ＩＭＳにおけるセッション制御システムにおいて，
前記ＳＩＰメソッドは，少なくとも前記ユーザ端末からの他のユーザ端末へのセッションを開始するためのINVITE要求か，もしくは，前記ユーザ端末のＩＰアドレス情報を前記Ｓ−ＣＳＣＦサーバ装置へ登録するためのREGISTER要求，であってもよい。

さらに，当該ＩＭＳにおけるセッション制御システムにおいて，
前記Ｉ−ＣＳＣＦサーバは，各々の前記Ｓ−ＣＳＣＦサーバに割り当てられたユーザ端末数を管理するＳ−ＣＳＣＦサーバ管理リストを備え，
前記Ｉ−ＣＳＣＦサーバは，
前記対象となるユーザ端末への前記割り当て情報が，自身が管理する前記ユーザ管理リストで管理されていない場合，前記Ｓ−ＣＳＣＦサーバ管理リストを参照し，前記ユーザ端末の数が最も少ないＳ−ＣＳＣＦサーバを前記対象となるユーザ端末に割り当てて前記ユーザ管理リストを更新し，
更新した前記ユーザ管理リストに基づき，前記対象となるユーザ端末への前記割り当て情報を応答する，という特徴を備えても良い。

さらに，当該ＩＭＳにおけるセッション制御システムにおいて，
前記Ｉ−ＣＳＣＦサーバの識別子はＩＰアドレスであり，
前記ユーザ端末識別子はＳＩＰ−ＵＲＩであり，
前記第一のハッシュ関数と前記第二のハッシュ関数とは同一，であっても良い。

上記各特徴により，上記態様のセッション制御システムは，以下の効果を持つ。
（効果１）Ｓ−ＣＳＣＦが複数ある場合，特定のＳ−ＣＳＣＦに負荷が偏るのを防ぐことができる。
（効果２）Ｓ−ＣＳＣＦを増設した場合でも，既存Ｓ−ＣＳＣＦから増設Ｓ−ＣＳＣＦへのデータの移動を不要とすることができる。その結果，サービス中にＳ−ＣＳＣＦに対する負担を掛けずにすむ。
（効果３）どのＳ−ＣＳＣＦがどのユーザ端末を収容しているかを管理する情報を複数のＩ−ＣＳＣＦに分散して管理することで，また，ユーザ端末数の増加に伴ってＩ−ＣＳＣＦを増設する場合でも，一つのＩ−ＣＳＣＦが管理する情報の一部を移動するだけでよく，処理が簡単になるため，本システム自身の負荷分散が可能になる。
さらに，
（効果４）Ｉ−ＣＳＣＦが，ユーザ端末からの登録要求をＳ−ＣＳＣＦに中継するまでのアクセスは１回となるため，結果，アクセスの遅延時間が短くなり，ユーザへの応答時間を短縮することができる。また，サーバの台数を削減し，設備コストを低減することができる。

本発明により，管理者の負担が少なく，高いレベルのサービスをユーザへ提供できるＩＭＳ網を実現可能になる。

本実施形態におけるＩＭＳの構成を例示する図である。 Ｉ−ＣＳＣＦ管理テーブルの構成を例示する図である。 Ｓ−ＣＳＣＦ管理リストの構成を例示する図である。 ユーザ管理リストの構成を例示する図である。 本実施形態において，ユーザ端末からのREGISTER要求を受信した際の処理を例示するシーケンス図である。 図５のＳ１２〜Ｓ１４の処理の詳細を例示するシーケンス図である。 本実施形態において，新しくＳ−ＣＳＣＦが増設された際の，Ｉ−ＣＳＣＦでの追加処理を例示するシーケンス図である。 本実施形態における各サーバのハードウェア構成を例示する図である。

以下，本発明によるＳＩＰ中継装置の実施の最良の形態について，図面を参照して説明する。

図１は，本実施形態におけるＩＭＳの構成の一例を示すシステム構成図である。図１のシステムは，Ｐ−ＣＳＣＦ１１，Ｉ−ＣＳＣＦ１２，及びＳ−ＣＳＣＦ１３の各機能が，それぞれ物理的に独立したサーバ装置に備わるように構成し，これらと，ユーザ端末１０とをインターネットなどのネットワーク１４で接続した構成となっている。

ユーザ端末１０は，Ｐ−ＣＳＣＦ１１を経由して，Ｉ−ＣＳＣＦ１２と相互に通信する。Ｉ−ＣＳＣＦ１２は，Ｉ−ＣＳＣＦ管理テーブル１２１，Ｓ−ＣＳＣＦ管理リスト１２２，及びユーザ管理リスト１２３を備え，更に，公知の一般的なＩ−ＣＳＣＦと同様のＳＩＰセッションの処理を行うＳＩＰセッション処理部１２４と，他のＩ−ＣＳＣＦが管理する他のユーザ管理リスト１２３へのアクセス要求および，他のＩ−ＣＳＣＦからの要求に対する応答を行う分散データベース管理部１２５とを備えている。Ｉ−ＣＳＣＦ１２は，Ｉ−ＣＳＣＦ管理テーブル１２１を用いて，他のＩ−ＣＳＣＦ１２に接続するために必要なＩＰアドレス情報を管理する。

図２に，Ｉ−ＣＳＣＦ管理テーブル１２１の例を示す。Ｉ−ＣＳＣＦ管理テーブル１２１は，Ｉ−ＣＳＣＦ１２のＩＤ１２１１１と，Ｉ−ＣＳＣＦ１２のＩＰアドレス１２１１２と，Ｉ−ＣＳＣＦ１２のＩＤ１２１１１のハッシュ値１２１２１とを対応付けて管理するためのテーブルである。Ｉ−ＣＳＣＦ１２のＩＤ１２１１１は，Ｉ−ＣＳＣＦ１２にユニークに割り付けられた，文字列による識別子情報である。

Ｉ−ＣＳＣＦ管理テーブル１２１は，全てのＩ−ＣＳＣＦを管理するＩ−ＣＳＣＦテーブル１２１１とハッシュテーブル１２１２とを備える。Ｉ−ＣＳＣＦテーブル１２１１は，Ｉ−ＣＳＣＦのＩＤ１２１１１とＩＰアドレス１２１１２を対応付けて管理するためのリストである。

ハッシュテーブル１２１２は，Ｉ−ＣＳＣＦテーブル１２１１からＩ−ＣＳＣＦのＩＤ１２１１１をハッシュ検索するためのテーブルで，Ｉ−ＣＳＣＦのＩＤ１２１１１のハッシュ値１２１２１を管理する。この例では，Ｉ−ＣＳＣＦのＩＤ１２１１１は，Ｉ−ＣＳＣＦ１２のホスト名（ＦＱＤＮ形式）としている。Ｉ−ＣＳＣＦのＩＤ１２１１１は，ＩＰアドレス１２１１２から所定の規則に基づき生成しても良い。

Ｉ−ＣＳＣＦのＩＤ１２１１１のハッシュ値１２１２１は，Ｉ−ＣＳＣＦのＩＤ１２１１１を，ハッシュ関数に入力して算出した固定長の数値（ダイジェスト値）である。図２の例では，ハッシュ空間の大きさは３２ｂｉｔ（0x00000000〜0xFFFFFFFF）としている。ハッシュ関数には，公知のアルゴリズムを利用することが可能である。例えば，ＭＤ５（Message Digest Algorithm 5）を用いた場合は，ハッシュ空間の大きさは１２８ｂｉｔになる。

Ｉ−ＣＳＣＦ１２は，上記文献に開示されているコンシステント・ハッシュ法に基づき，あるユーザ端末１０の登録を担当するＳ−ＣＳＣＦ１３を割り当てる担当のＩ−ＣＳＣＦ１２を算出する。例えば，以下のように算出する。
（１）ユーザ端末１０のＳＩＰ−ＵＲＩをハッシュ関数に入力して，ハッシュ値を算出する。ここで，ＳＩＰメソッドとして，REGISTER要求を受信した場合は，Fromヘッダ（要求の送信元を示す領域）に記述されているＳＩＰ−ＵＲＩを対象とする。INVITE要求を受信した場合は，リクエスト行に記述されているＳＩＰ−ＵＲＩを対象とする。

この処理で用いるハッシュ関数は，ハッシュテーブル１２１２を作成するために用いるハッシュ関数と同じビット長のハッシュ値を出力するもの（同じハッシュ関数を用いても良い）であり，後述するユーザ管理リスト１２３で用いるハッシュ関数と同じである。

ハッシュ関数の性質により，入力となるＩ−ＣＳＣＦのＩＤ１２１１１とユーザ端末１０のＳＩＰ−ＵＲＩの長さが異なっていても，得られたハッシュ値は同じ長さとなる。
（２）（１）で算出したＳＩＰ−ＵＲＩのハッシュ値以上（または以下）でかつ最も近い，Ｉ−ＣＳＣＦのＩＤのハッシュ値を，Ｉ−ＣＳＣＦ管理テーブル１２１のハッシュテーブル１２１２を用いて検索する。このため，ハッシュテーブル１２１２は，ハッシュ値１２１２１の昇順または降順に，各エントリをソートしておくことが望ましい。（３）（２）の検索で得られたハッシュ値１２１２１を持つエントリに対応するＩＰアドレス１２１１２の値を，当該ユーザ端末１０を担当するＩ−ＣＳＣＦ１２のＩＰアドレスとして用いる。

また，それぞれのＩ−ＣＳＣＦ１２は，Ｓ−ＣＳＣＦ管理リスト１２２を備えている。後述するように，各Ｉ−ＣＳＣＦ１２は同じＳ−ＣＳＣＦ１３を管理対象とするが，各「Ｓ−ＣＳＣＦ１３に登録されているユーザ数」の値は，Ｉ−ＣＳＣＦ１２ごとに異なる。

図３に，Ｓ−ＣＳＣＦ管理リスト１２２の一例を示す。Ｓ−ＣＳＣＦ管理リスト１２２により，Ｓ−ＣＳＣＦのＩＤ１２２２１と，Ｓ−ＣＳＣＦ１３のＩＰアドレス１２２２２と，登録ユーザ数１２２２３とが，リスト形式で管理される。Ｓ−ＣＳＣＦのＩＤ１２２２１は，Ｓ−ＣＳＣＦ１３にユニークに割り付けられた，文字列による識別子情報である。この例では，Ｓ−ＣＳＣＦのＩＤ１２２２１は，Ｓ−ＣＳＣＦ１３のホスト名（ＦＱＤＮ形式）としている。または，ＩＰアドレス１２２２２から所定の規則に基づきに生成しても良い。登録ユーザ数１２２２３は，各Ｓ−ＣＳＣＦ１３で収容しているユーザ数である。登録ユーザ数１２２２３は，Ｓ−ＣＳＣＦ１３で収容しているユーザ数が増える毎に，Ｉ−ＣＳＣＦ１２により修正される（詳細は後述する）。

更に，Ｉ−ＣＳＣＦ１２は，ユーザ管理リスト１２３を備えている。

図４に，ユーザ管理リスト１２３の一例を示す。ユーザ管理リスト１２３は，リスト形式で管理されているユーザ管理構造体１２３３と，それをハッシュ検索するためのハッシュテーブル１２３１を備える。ハッシュテーブル１２３１は，ＳＩＰ−ＵＲＩのハッシュ値１２３１１と，ユーザ管理構造体１２３３へのポインタ情報１２３１２の欄を備える。ＳＩＰ−ＵＲＩのハッシュ値１３２１１は，ＳＩＰ−ＵＲＩを，ハッシュ関数に入力して算出した固定長の数値である。

ここで用いるハッシュ関数は，Ｉ−ＣＳＣＦのＩＤ１２１１１のハッシュ値１２１２１を算出するのに用いるハッシュ関数と同じビット長のハッシュ値を出力するもの（同じハッシュ関数を用いても良い）である。

ハッシュテーブル１２３１にハッシュ値１２３１１が無い場合は，ユーザ管理構造体１２３３が存在しないことになるので，ポインタ情報１２３１２に格納される値には，ＮＵＬＬが設定される。ハッシュ値１２３１１に該当するＳＩＰ−ＵＲＩが有る場合は，ユーザ管理構造体１２３３が存在するため，ユーザ管理構造体１２３３へのポインタが設定される。

ユーザ管理構造体１２３３は，ＳＩＰ−ＵＲＩ情報１２３３１と，ユーザ端末登録先のＳ−ＣＳＣＦ１３のＩＤ１２３３２と，エントリ状態１２３３３と，次の（ハッシュ値１２３１１が同じになるＳＩＰ−ＵＲＩ１２３３１を持つ）ユーザ管理構造体１２３３へのポインタ１２３３４を，メンバとして含む構造体である。ＳＩＰ−ＵＲＩ１２３３１は，ユーザ端末１０毎にユニークに割り付けられた，文字列によるＳＩＰ形式ユーザ識別子情報である。エントリ状態１２３３３は，エントリの状態を設定する領域である。

エントリ状態１２３３３には，「作成準備中」と「完了」の２種類がある。エントリ状態１２３３３が「完了」の場合は，Ｉ−ＣＳＣＦ１２は，Ｐ−ＣＳＣＦからの検索要求に対し，応答可能である。

一方，エントリ状態１２３３３が「作成準備中」の場合は，状態が「完了」に変化するまで，検索要求に対する処理を中断する。これにより，複数のＩ−ＣＳＣＦ１２から受信した検索要求が重なって，同じＳＩＰ−ＵＲＩのユーザ管理構造体１２３３を複数作成する事態を防ぐ。

各Ｉ−ＣＳＣＦ１２は，起動時に，他の全てのＩ−ＣＳＣＦ１２に対して，当該Ｉ−ＣＳＣＦ１２に関する情報を，それぞれのＩ−ＣＳＣＦ管理テーブル１２１に設定することを要求する。

Ｐ−ＣＳＣＦ１１，Ｉ−ＣＳＣＦ１２，及びＳ−ＣＳＣＦ１３を実現するハードウェア構成例を図８に示す。これらは，ＣＰＵ１００１，主記憶装置１００２，ＨＤＤ等の二次記憶装置１００５，ＣＤ-ＲＯＭやＤＶＤ-ＲＯＭ等の可搬性を有する記憶媒体１００８から情報を読み出す読取装置１００３，ディスプレイ，キーボードやマウスなどの入出力装置１００６，通信ネットワークに接続するためのＮＩＣ（Network Interface Card）等の通信装置１００４，及びそれらの装置をつなぐバスなどの内部通信線１００７を備えた一般的なコンピュータ１０００により実現できる。

例えば，Ｉ−ＣＳＣＦ管理テーブル１２１や，Ｓ−ＣＳＣＦ管理リスト１２２や，ユーザ管理リスト１２３は，主記憶装置１００２または二次記憶装置１００５の一部の領域を用いて実現する。また，Ｐ−ＣＳＣＦ１１，Ｉ−ＣＳＣＦ１２，及びＳ−ＣＳＣＦ１３は，二次記憶装置１００５に記憶されている一つ以上のプログラムを主記憶装置１００２にロードしてＣＰＵ１００１で実行し，通信装置１００４を介してユーザ端末１０や他サーバとのネットワーク通信を行うことで，上述の，または，以下に説明する各種サーバ機能を実現する。

上記一つ以上のプログラムは，予め，主記憶装置１００２や二次記憶装置１００５に格納されていても良いし，必要なときに，ネットワーク１４や，可搬性を有する記憶媒体１００８を介して他の装置から導入されても良い。

図５は，本実施例のシステム構成において，ユーザ端末１０からＳＩＰメソッドとして，REGISTER要求を受信した際の処理を示すシーケンス図である。

Ｉ−ＣＳＣＦ１２ａは，ユーザ端末１０からＰ−ＣＳＣＦ１１経由でREGISTER要求を受信すると，REGISTER要求のFromヘッダにある発信者ＳＩＰ−ＵＲＩから，当該ユーザ端末１０の管理を担当するＩ−ＣＳＣＦ１２を求める。具体的には，ハッシュ関数を用いて，該発信者ＳＩＰ−ＵＲＩのハッシュ値を算出し，Ｉ−ＣＳＣＦ管理テーブル１２１のハッシュテーブル１２１２を検索し，算出したハッシュ値以上（または以下）でかつ最も近いハッシュ値１２１２１を求める。得られたエントリのポインタ１２１２２が指し示すＩ−ＣＳＣＦテーブル１２１１のエントリには，担当するＩ−ＣＳＣＦ１２の情報が格納されている（Ｓ１０）。

なお，事前準備として，システム管理者は，各Ｉ−ＣＳＣＦ１２のＩＤのハッシュ値を昇順または降順に並べたハッシュテーブル１２１２を作成し，管理端末（図示していない）を用いて設定しておく。

Ｓ１０で得られたエントリのＩＰアドレス１２１１２を持つＩ−ＣＳＣＦ１２ｂに対して，発信者（上記ユーザ端末１０のユーザ）のＳＩＰ−ＵＲＩの登録を担当しているＳ−ＣＳＣＦ１３の検索要求を送信する（Ｓ１１）。検索要求には，発信者ＳＩＰ−ＵＲＩを含み，さらにそのハッシュ値を含むことが望ましい。

Ｉ−ＣＳＣＦ１２ｂは，Ｉ−ＣＳＣＦ１２ａから発信者ＳＩＰ−ＵＲＩの検索要求を受信すると，検索要求に含まれているＳＩＰ−ＵＲＩのハッシュ値により，ユーザ管理リスト１２３のハッシュテーブル１２３１をハッシュ検索する（Ｓ１２）。

ハッシュ検索でヒットしない場合（Ｓ１３でＮ）は，Ｓ−ＣＳＣＦ１３に未割り当てのＳＩＰ−ＵＲＩとみなし，Ｓ−ＣＳＣＦ管理リスト１２２から，登録ユーザ数１２２２３の値が最も少ないＳ−ＣＳＣＦ１３を探し，得られたＳ−ＣＳＣＦに上記ＳＩＰ−ＵＲＩを持つユーザの管理を担当させることに決定し（Ｓ１４），決定したＳ−ＣＳＣＦ１３のＳ−ＣＳＣＦ管理構造体１２２２の登録ユーザ数１２２２３をカウントアップする。そして，Ｓ１４で決定したＳ−ＣＳＣＦのＩＤ１２２２１及びＩＰアドレス情報１２２２２を，検索要求元のＩ−ＣＳＣＦ１２ａに応答する（Ｓ１５）。

一方，ハッシュ検索でヒットした場合（Ｓ１３でＹ）は，Ｓ−ＣＳＣＦ１３に割り当て済みのＳＩＰ−ＵＲＩとみなし，ヒットしたユーザ管理構造体１２３３のＳ−ＣＳＣＦのＩＤ１２３３２と，そのＩＤ１２３３２からＳ−ＣＳＣＦ管理リスト１２２を検索して得られたＩＰアドレス情報１２２２２を，検索要求元のＩ−ＣＳＣＦ１２ａに応答する（Ｓ１５）。Ｓ−ＣＳＣＦ１３の情報を受信したＩ−ＣＳＣＦ１２ａは，Ｓ１５で応答されたＳ−ＣＳＣＦ１３のＩＰアドレス１２２２２に対し，REGISTER要求を転送する（Ｓ１６）。

Ｓ−ＣＳＣＦ１３は，REGISTER要求を受信すると，ＨＳＳ１３１からユーザプロファイル情報を取得し（Ｓ１７），そのプロファイル情報に従ってユーザ端末の登録処理を行い，Ｉ−ＣＳＣＦ１２ａに，正常応答を示す"２００ ＯＫ"応答を送信する（Ｓ１８）。Ｉ−ＣＳＣＦ１２ａは，Ｓ−ＣＳＣＦ１３からの正常応答を確認すると，Ｐ−ＣＳＣＦ１１経由でユーザ端末１０に"２００ ＯＫ"応答を転送する（Ｓ１９）。

図５のＳ１２〜Ｓ１４の処理の詳細を，図６を用いて説明する。

（Ｓ１２相当の処理）
Ｉ−ＣＳＣＦ１２ｂは，Ｉ−ＣＳＣＦ１２ａから発信者ＳＩＰ−ＵＲＩの検索要求を受信すると，検索要求に含まれているＳＩＰ−ＵＲＩのハッシュ値を算出する（Ｓ２０）。得られたハッシュ値から，ユーザ管理リスト１２３のハッシュテーブル１２３１の該当ハッシュ値１２３１１に対応するポインタ１２３１２が示すユーザ管理構造体１２３３を得る（Ｓ２１）。

（Ｓ１３相当の処理）
当該ユーザ管理構造体１２３３のＳＩＰ−ＵＲＩ１２３３１の文字列と，検索要求に含まれているＳＩＰ−ＵＲＩの文字列とを文字列比較する（Ｓ２２）。文字列が完全一致するかどうかチェックし（Ｓ２３），完全一致するならば（Ｓ２３でＹ），エントリ状態１２３３３をチェックする。エントリ状態１２３３３が「作成準備中」であれば，「完了」に変更されるまで待機する（Ｓ２４）。「完了」であれば，当該ユーザ端末１０のＳ−ＣＳＣＦは割り当て済みとみなし，Ｓ１５の処理を行う。完全一致しないならば（Ｓ２３でＮ），ユーザ管理構造体１２３３の次ポインタ１２３３４が示すアドレスを参照して，次のユーザ管理構造体１２３３を取得する（Ｓ２５）。ここで，次のユーザ管理構造体１２３３が存在していれば（Ｓ２６でＮ），Ｓ２２の処理に戻る。一方，もし存在していなければ，すなわち次ポインタ１２３３４が示すアドレスがＮＵＬＬであれば（Ｓ２６でＹ），当該ユーザ端末１０のＳ−ＣＳＣＦは未割り当てとみなし，Ｓ１４相当の処理を行う。

（Ｓ１４相当の処理）
まず，ユーザ管理構造体１２３３を新規作成し，検索要求に含まれているＳＩＰ−ＵＲＩの文字列をＳＩＰ−ＵＲＩ１２３３１に，「作成準備中」をエントリ状態１２３３３に，ＮＵＬＬを次ポインタ１２３３４に設定する。そして，今回新規作成したユーザ管理構造体１２３３のアドレスを，現在参照しているユーザ管理構造体１２３３の次ポインタ１２３３４に設定する。さらに，Ｓ−ＣＳＣＦ管理リスト１２２のヘッダ情報１２２１の先頭ポインタ１２２１１から，先頭のＳ−ＣＳＣＦ管理構造体１２２２を取得する（Ｓ２７）。その登録ユーザ数１２２２３を取得し，予め当該Ｉ−ＣＳＣＦ１２に設定した，登録ユーザ数の上限値と比較する（Ｓ２８）。上限値と同じか小さければ（Ｓ２８でＹ），Ｓ２６で新規作成したユーザ管理構造体１２３３に対し，先ほど取得したＳ−ＣＳＣＦ管理構造体１２２２のＳ−ＣＳＣＦのＩＤ１２２２１をＳ−ＣＳＣＦのＩＤ１２３３２に，「完了」をエントリ状態１２３３３に設定する。更に，登録ユーザ数１２２２３の値を＋１した後，Ｓ−ＣＳＣＦ管理リストの登録ユーザ数１２２２３をキーに，Ｓ−ＣＳＣＦ管理構造体１２２２を昇順にソート（登録ユーザ数が少ない順に，Ｓ−ＣＳＣＦ管理構造体を並べ直す）し（Ｓ２９），Ｓ１５の処理を行う。一方，上限値より多ければ（Ｓ２８でＮ），正常状態でないものとし，検索要求元Ｉ−ＣＳＣＦ１２ａにエラー応答を行う（Ｓ３０）。

ユーザ端末１０の増加によりＩ−ＣＳＣＦ１２が増設された場合は，管理者端末（図示していない）を用いて，すべてのＩ−ＣＳＣＦ１２のＩ−ＣＳＣＦ管理テーブル１２１を更新する。具体的には，新たなＩ−ＣＳＣＦ１２について，ＩＤのハッシュ値を求めてハッシュテーブル１２１２１に追加して再ソートし，ＩＤとＩＰアドレスをＩ−ＣＳＣＦテーブル１２１１に追加する。

これらの処理に伴い，管理者端末は，新たなＩ−ＣＳＣＦ１２に，新たに担当するユーザ端末のユーザ管理リスト１２３を移す。本実施例の方法によれば，新たなＩ−ＣＳＣＦ１２のＩＤのハッシュ値より次に大きな（または次に小さな）ハッシュ値を持つＩ−ＣＳＣＦ１２が管理するユーザ管理リスト１２３のうち，新たなＩ−ＣＳＣＦ１２のＩＤのハッシュ値以下（または以上）のＳＩＰ−ＵＲＩのハッシュ値を持つユーザ端末１０のハッシュテーブル１２３１とユーザ管理構造体１２３３を，新たなＩ−ＣＳＣＦ１２へ移動する。

次に，Ｓ−ＣＳＣＦ１３が増設された際の，Ｉ−ＣＳＣＦ１２での追加処理について，図７を用いて説明する。この処理は，各Ｉ−ＣＳＣＦ１２それぞれが独立して行う。

Ｓ−ＣＳＣＦ１３の追加を，管理者端末から指示された場合，Ｓ−ＣＳＣＦ管理構造体１２２２を新規に作成し，Ｓ−ＣＳＣＦのＩＤ１２２２１及びＩＰアドレス１２２２２に値を格納し，及び登録ユーザ数１２２２３を０に初期化する（Ｓ３１）。そして，ヘッダ情報１２２１の先頭ポインタ１２２１１の示す値を取得し，その値を，当該Ｓ−ＣＳＣＦ管理構造体１２２２の次構造体ポインタ１２２２４に格納する（Ｓ３２）。そして，当該Ｓ−ＣＳＣＦ管理構造体１２２２のメモリ上のアドレスを，ヘッダ情報１２２１の先頭ポインタ１２２１１に格納する（Ｓ３３）。この処理により，Ｓ−ＣＳＣＦ管理リスト１２２の先頭に，新しく追加されたＳ−ＣＳＣＦ１３のＳ−ＣＳＣＦ管理構造体１２２２が配置される。

図６のＳ２８の処理により，登録ユーザ数が最も少ないＳ−ＣＳＣＦが選択されるので，各Ｓ−ＣＳＣＦへの登録ユーザ数は，次第に平均化されることになる。

追加されたＳ−ＣＳＣＦ管理構造体１２２２の更新処理は，各Ｉ−ＣＳＣＦ１２が独自に行う。したがって，他のＩ−ＣＳＣＦ１２が管理するものとは，登録ユーザ数が異なることになる。しかしながら，上述したように，各Ｉ−ＣＳＣＦ１２が登録ユーザ数を均等にする処理を行うので，システム全体で見ても，各Ｓ−ＣＳＣＦ１３が管理する登録ユーザ数は，ほぼ均等になることが期待できる。

以上，本実施例によると，Ｉ-ＣＳＣＦは分散データベース管理部１２５を備えるので，従来のＳＬＦは不要になる。また，本実施例によると，従来のＨＳＳに格納されていた「ユーザ情報がどのＳ−ＣＳＣＦに格納されているかという情報」も，本実施例のＩ-ＣＳＣＦに格納されるので，ＨＳＳ１３１のデータ量が削減され，また，ＨＳＳ１３１へアクセスも少なくなり，システム全体の応答速度が向上する。

なお，上記図５，図６を用いて，ＳＩＰメソッドとして，REGISTER要求処理について説明したが，通信相手端末とセッションを確立するためのINVITE要求やその他の要求の処理についても，図５のＳ１０〜Ｓ１６の処理が同様に行われる。

なお，本発明は，上記実施形態に限定されず，種々の変形や応用が可能である。

１０：ユーザ端末，１１：Ｐ−ＣＳＣＦ，１２：Ｉ−ＣＳＣＦ，１３：Ｓ−ＣＳＣＦ，１２１：Ｉ−ＣＳＣＦ管理テーブル，１２２：Ｓ−ＣＳＣＦ管理リスト，１２３：ユーザ管理リスト，１２４：ＳＩＰセッション処理部，１２５：分散データベース管理部，１２１１：Ｉ−ＣＳＣＦテーブル，１２１２：Ｉ−ＣＳＣＦテーブルのハッシュテーブル，１２１１１：Ｉ−ＣＳＣＦのＩＤ，１２１１２：Ｉ−ＣＳＣＦのＩＰアドレス，１２１２１：Ｉ−ＣＳＣＦのＩＤのハッシュ値，１２１２２：Ｉ−ＣＳＣＦテーブルのエントリへのポインタ，１２２１：Ｓ−ＣＳＣＦ管理リストのヘッダ情報，１２２１１：先頭のＳ−ＣＳＣＦ管理構造体へのポインタ，１２２１２：最後尾のＳ−ＣＳＣＦ管理構造体へのポインタ，１２２２１：Ｓ−ＣＳＣＦのＩＤ，１２２２２：Ｓ−ＣＳＣＦのＩＰアドレス，１２２２３：Ｓ−ＣＳＣＦの登録ユーザ数，１２２２４：次のＳ−ＣＳＣＦ管理構造体へのポインタ，１２３１：ユーザ管理構造体のハッシュテーブル，１２３３：ユーザ管理構造体，１２３１１：ＳＩＰ−ＵＲＩのハッシュ値，１２３１２：ユーザ管理構造体へのポインタ，１３３３１：ＳＩＰ−ＵＲＩ，１３３３２：割り当てＳ−ＣＳＣＦサーバのＩＤ，１３３３３：エントリ状態，１３３３４：次のユーザ管理構造体へのポインタ，１０００：コンピュータ，１００１：ＣＰＵ，１００２：主記憶装置，１００３：読取装置，１００４：通信装置，１００５：二次記憶装置，１００６：入出力装置，１００７：内部通信線，１００８：可搬性を有する記憶媒体。

Claims (6)

1. 複数のＩ−ＣＳＣＦサーバと複数のＳ−ＣＳＣＦサーバとを備え，ユーザ端末との間でＳＩＰ通信を行い，前記ユーザ端末の登録及びセッション制御を，当該ユーザ端末に割り当てられたいずれかの前記Ｓ−ＣＳＣＦサーバが担当するＩＭＳにおけるセッション制御システムであって，
   各々の前記Ｉ−ＣＳＣＦサーバは，前記ユーザ端末への前記Ｓ−ＣＳＣＦサーバの割り当て情報を管理するユーザ管理リストを備え，
   一つの前記ユーザ端末への前記割り当て情報は，いずれか一つの前記Ｉ−ＣＳＣＦサーバが管理する前記ユーザ管理リストで管理され，
   各々の前記Ｉ−ＣＳＣＦサーバは，一つの前記ユーザ端末への前記割り当て情報がいずれの前記Ｉ−ＣＳＣＦサーバが備える前記ユーザ管理リストで管理されているか，を特定するために用いるＩ−ＣＳＣＦ管理テーブルを備える
   ことを特徴とするＩＭＳにおけるセッション制御システム。
2. 請求項１に記載のＩＭＳにおけるセッション制御システムにおいて，
   前記ＳＩＰ通信におけるＳＩＰメソッドにおいて，ユーザ端末に割り当てられた前記Ｓ−ＣＳＣＦサーバの特定を要求された前記Ｉ−ＣＳＣＦサーバは，対象となるユーザ端末への前記割り当て情報を管理するべきＩ−ＣＳＣＦサーバを，前記Ｉ−ＣＳＣＦ管理テーブルに基づき特定し，
   特定した前記Ｉ−ＣＳＣＦサーバへ，前記対象となるユーザ端末への前記割り当て情報を要求し，
   要求された前記Ｉ−ＣＳＣＦサーバは，自身が管理する前記ユーザ管理リストに基づき，前記対象となるユーザ端末への前記割り当て情報を応答する
   ことを特徴とするＩＭＳにおけるセッション制御システム。
3. 請求項２に記載のＩＭＳにおけるセッション制御システムにおいて，
   前記Ｉ−ＣＳＣＦ管理テーブルは，前記Ｉ−ＣＳＣＦサーバの識別子を第一のハッシュ関数に入力して得たハッシュ値と，前記Ｉ−ＣＳＣＦサーバと通信するための情報とを対応付けたものであり，
   前記Ｓ−ＣＳＣＦサーバの特定を要求されたＩ−ＣＳＣＦサーバは，前記対象となるユーザ端末の識別子を，前記ハッシュ値と同じ長さのハッシュ値を出力する第二のハッシュ関数に入力して，ユーザ端末の識別子のハッシュ値を求め，
   前記ユーザ端末識別子のハッシュ値と，前記Ｉ−ＣＳＣＦ管理テーブルとに基づき，要求された前記Ｓ−ＣＳＣＦサーバを特定する
   ことを特徴とするＩＭＳにおけるセッション制御システム。
4. 請求項２に記載のＩＭＳにおけるセッション制御システムにおいて，
   前記ＳＩＰメソッドは，少なくとも前記ユーザ端末からの他のユーザ端末へのセッションを開始するためのINVITE要求か，もしくは，前記ユーザ端末のＩＰアドレス情報を前記Ｓ−ＣＳＣＦサーバ装置へ登録するためのREGISTER要求，である
   ことを特徴とするＩＭＳにおけるセッション制御システム。
5. 請求項２に記載のＩＭＳにおけるセッション制御システムにおいて，
   前記Ｉ−ＣＳＣＦサーバは，各々の前記Ｓ−ＣＳＣＦサーバに割り当てられたユーザ端末数を管理するＳ−ＣＳＣＦサーバ管理リストを備え，
   前記Ｉ−ＣＳＣＦサーバは，
   前記対象となるユーザ端末への前記割り当て情報が，自身が管理する前記ユーザ管理リストで管理されていない場合，前記Ｓ−ＣＳＣＦサーバ管理リストを参照し，前記ユーザ端末の数が最も少ないＳ−ＣＳＣＦサーバを前記対象となるユーザ端末に割り当てて前記ユーザ管理リストを更新し，
   更新した前記ユーザ管理リストに基づき，前記対象となるユーザ端末への前記割り当て情報を応答する
   ことを特徴とするＩＭＳにおけるセッション制御システム。
6. 請求項３に記載のＩＭＳにおけるセッション制御システムにおいて，
   前記Ｉ−ＣＳＣＦサーバの識別子はＩＰアドレスであり，
   前記ユーザ端末識別子はＳＩＰ−ＵＲＩであり，
   前記第一のハッシュ関数と前記第二のハッシュ関数とは，同一である
   ことを特徴とするＩＭＳにおけるセッション制御システム。

Images