(57)【要約】【課題】通信装置の識別情報にセッション管理サーバの識別情報を含めることなく，セッション管理サーバの台数を柔軟に増減でき，かつ，セッション管理サーバと通信装置との間で共有情報が必要な通信を実施している場合でも，セッション管理サーバにかかるメッセージ処理の負荷を分散しながら，データ通信を実現できるデータ通信システムを提供する。【解決手段】相互にデータ通信を行う，多数の通信装置と，通信装置間のデータ通信のセッションを管理する，複数のセッション管理サーバと，事前に定めた基準にしたがって通信装置から受信したメッセージを処理するセッション管理サーバを振り分ける負荷分散装置と，を備えるデータ通信システムにおいて，セッション管理サーバに，現在ログインしている通信装置と，当該通信装置が行っている通信の状態と，を管理する手段と，通信装置と通信するために必要な情報を取得する手段と，を設ける。【選択図】  図1
2008205988.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置相互のデータ通信を管理するデータ通信システムであって，
当該通信装置間のデータ通信のセッションを管理する，複数のセッション管理サーバと，
事前に定めた基準にしたがって，通信装置１から通信装置２への通信メッセージであって，前記通信装置２を管理するセッション管理サーバを特定する情報を備えない通信メッセージを，いずれかの前記セッション管理サーバに振り分ける負荷分散装置と，
前記負荷分散装置から前記通信メッセージを受信したセッション管理サーバに，前記通信装置２と通信するために必要な情報を取得させる手段と，を備える
ことを特徴とするデータ通信システム。
【請求項２】
請求項1記載のデータ通信システムであって，
前記通信装置２と通信するために必要な情報とは，当該通信装置２がログインしているセッション管理サーバを特定するための識別情報である
ことを特徴とするデータ通信システム。
【請求項３】
請求項2記載のデータ通信システムであって，
前記通信装置２と通信するために必要な情報を取得させる手段は，
前記通信装置２がログインしているか否かを，前記セッション確立要求メッセージを受信したセッション管理サーバが他のセッション管理サーバに問い合わせる手段と，
前記通信装置２がログインしているセッション管理サーバが，当該通信装置２がログインしていることを，前記セッション確立要求メッセージを受信したセッション管理サーバに応答する手段と，を含む
ことを特徴とするデータ通信システム。
【請求項４】
請求項2記載のデータ通信システムであって，
前記通信装置２と通信するために必要な情報を取得させる手段は，
前記複数のセッション管理サーバがアクセス可能で，かつ，前記通信装置がログインしているセッション管理サーバを特定するための識別情報を記録した共有データベースと，
前記セッション確立要求メッセージを受信したセッション管理サーバが，当該共有データベースを検索する手段と，を含む
ことを特徴とするデータ通信システム。
【請求項５】
請求項２記載のデータ通信システムであって，
前記通信メッセージは，セッション確立要求メッセージまたはセッション確立応答メッセージである
ことを特徴とするデータ通信システム。
【請求項６】
請求項1記載のデータ通信システムであって，
前記通信装置２と通信するために必要な情報は，当該通信装置２と通信する際に使用する暗号化通信設定であって，
前記通信装置２と通信するために必要な情報を取得させる手段は，
当該通信装置２と通信する際に使用する暗号化通信設定を記録する，前記複数のセッション管理サーバがアクセス可能な共有データベースと，
前記セッション確立要求メッセージを受信したセッション管理サーバが，当該共有データベースを検索する手段と，を含む
ことを特徴とするデータ通信システム。
【請求項７】
請求項６記載のデータ通信システムであって，
前記通信メッセージは，呼情報検索要求メッセージまたは呼情報検索応答メッセージである
ことを特徴とするデータ通信システム。
【請求項８】
複数の通信装置相互データ通信のセッションを管理するセッション管理サーバであって，
通信装置１から通信装置２への通信メッセージであって，通信装置２を管理するセッション管理サーバを特定しない通信メッセージを，負荷分散装置から受信する手段と，
前記通信装置１または前記通信装置２と通信するために必要な情報を取得する手段と，を備える
ことを特徴とするセッション管理サーバ。
【請求項９】
請求項８記載のセッション管理サーバであって，
前記通信装置１または前記通信装置２と通信するために必要な情報とは，当該通信装置がログインしているセッション管理サーバを特定するための識別情報である
ことを特徴とするセッション管理サーバ。
【請求項１０】
請求項９記載のセッション管理理サーバであって，
前記通信装置１または前記通信装置２と通信するために必要な情報を取得する手段とは，
前記通信装置１または前記通信装置２がログインしているセッション管理サーバかどうかを他のセッション管理サーバに問い合わせる手段と，
前記通信装置１または前記通信装置２がログインしているセッション管理サーバから，当該通信装置がログインしていることを，受信する手段と，を含む
ことを特徴とするセッション管理サーバ。
【請求項１１】
請求項９記載のセッション管理サーバであって，
前記通信装置１または前記通信装置２と通信するために必要な情報を取得する手段は，
前記複数のセッション管理サーバがアクセス可能で，かつ，前記通信装置がログインしているセッション管理サーバを特定するための識別情報を記録した共有データベースを検索する手段を含む
ことを特徴とするセッション管理サーバ。
【請求項１２】
請求項８記載のデータ通信システムであって，
前記通信メッセージは，セッション確立要求メッセージまたはセッション確立応答メッセージである
ことを特徴とするセッション管理サーバ。
【請求項１３】
請求項８記載のセッション管理サーバであって，
前記通信装置２と通信するために必要な情報は，当該通信装置２と通信する際に使用する暗号化通信設定であって，
前記通信装置１または前記通信装置２と通信するために必要な情報を取得する手段は，
当該通信装置と通信する際に使用する暗号化通信設定を記録するデータベースを検索する手段を含む
ことを特徴とするセッション管理サーバ。
【請求項１４】
請求項１３記載のデータ通信システムであって，
前記通信メッセージは，呼情報検索要求メッセージまたは呼情報検索応答メッセージである
ことを特徴とするセッション管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，データ通信方法およびシステムに関し，更に詳しくは，セッション管理サーバ装置を利用して，通信装置間でのデータ通信を可能にしたデータ通信方法およびシステムに関する。
【背景技術】
【０００２】
2つのエンティティ（例えば，装置，または装置上でソフトウェアが実行されることにより具現化されるプロセス）間のデータ通信を行う場合に，当該データ通信を可能にしたり，切断したり，といったデータ通信の制御を行うため，データ通信とは独立した制御用通信プロトコルを用いることがある。例えば，IP電話では，制御用通信プロトコルとしてSIP (Session Initiation Protocol)というプロトコルが広く利用されている（SIPの詳細は非特許文献1参照）。
【０００３】
以下，SIPにおいて，セッション管理サーバを利用して第一の通信装置が第二の通信装置との間の通信セッション（以下，単にセッションともいう）を確立してデータ通信を可能にする場合の動作を簡単に説明する。
【０００４】
まず，第一の通信装置は通信セッション確立処理に先立って，当該通信装置のIPアドレスをセッション管理サーバに登録する。すなわち，当該通信装置は， セッション管理サーバにおいて当該通信装置または通信装置のユーザを一意に識別するための識別子（SIP-URIとも呼ばれる）と，当該通信装置のIPアドレスと，を含む登録要求メッセージ（REGISTERメッセージとも呼ばれる）をセッション管理サーバに送信する。セッション管理サーバは，登録要求メッセージに記載された前記識別子とIPアドレスとを対応付けて記録しておく。
【０００５】
なお，セッション管理サーバに記録されている，ある通信装置の識別子とIPアドレスとの対応付けは，対応付けが記録されたときに設定された有効期間が経過すると削除されるようになっている。また，当該通信装置から登録削除要求メッセージ（たとえば，前記REGISTERメッセージにおいて，対応付けの有効期間を0と設定するように指示する）を送信することによっても削除することができる。
【０００６】
また，本明細書では，ある通信装置（エンティティ）の識別子とIPアドレスとがセッション管理サーバに対応付けて記録されている状態を，当該通信装置はセッション管理サーバにログインしている，とも呼び，記録されていない状態を，当該通信装置はセッション管理サーバからログアウトしている，とも呼ぶ。
【０００７】
ログインすることにより，セッション管理サーバが接続元通信装置から受信したINVITEメッセージ（後述する）を接続先通信装置に送信できるようになる。逆に，接続先通信装置がINVITEメッセージ等をセッション管理サーバに受け付けてもらえるようになる。
【０００８】
同様に，第二の通信装置もセッション確立処理に先立って，セッション管理サーバにログインしておく。
【０００９】
次に，第一の通信装置が第二の通信装置とのセッションを確立する処理を行う。
【００１０】
すなわち，第一の通信装置は，セッション管理サーバに第二の通信装置とのセッション確立を要求するセッション確立要求メッセージ（以下，INVITEメッセージともいう）を送信する。当該INVITEメッセージには，第一の通信装置の識別子と第二の通信装置の識別子とが記載されている。INVITEメッセージを受信したセッション管理サーバは，当該INVITEメッセージを第二の通信装置に送信する。INVITEメッセージを受信した第二の通信装置は，セッション確立要求を受理する場合には，その旨を示す応答メッセージ（200OKメッセージとも呼ばれる）を前記セッション管理サーバに送信する。前記セッション管理サーバは，第一の通信装置に前記応答メッセージを返信する。第一の通信装置が応答メッセージを受信することにより，第二の通信装置との間で通信セッションが確立したことになる。
【００１１】
以上が，SIPにおいて，セッション管理サーバを利用して第一の通信装置が第二の通信装置との間のセッションを確立しデータ通信を可能にする場合の動作である。
【００１２】
セッション管理サーバでは，通信装置からメッセージを受信した場合に，どの通信装置が現在ログインしているのか，といった情報や，任意の通信装置間の通信の状態を適宜更新しながらメッセージの処理を行う。通信の状態とは，呼状態，とも呼び，通信中，通信確立処理中，通信切断処理中，等を示す。このため，セッション管理サーバにログインしている通信装置の数が多くなるにしたがってセッション管理サーバの負荷が重くなってしまう。
【００１３】
そこで，非特許文献1に記載されているような， 2つの通信装置間の通信セッションを制御する機能を備えるセッション管理サーバが複数連携して，を利用して，1つのセッション管理サーバで管理する通信装置を少数にすることによって，セッション管理サーバの負荷を低減する方法が知られている。すなわち，第一の通信装置は第一のセッション管理サーバにログインし，第二の通信装置は第二のセッション管理サーバにログインしているような状態で第一の通信装置が第二の通信装置との間でセッションを確立する場合には，まず，第一の通信装置は，前記INVITEメッセージを第一のセッション管理サーバに送信する。当該INVITEメッセージを受信した第一のセッション管理サーバは，当該INVITEメッセージを第二のセッション管理サーバに転送する。第二のセッション管理サーバは当該INVITEメッセージを第二の通信装置に転送する。同様に，第二の通信装置は，前記応答メッセージを第二のセッション管理サーバに送信する。応答メッセージを受信した第二のセッション管理サーバは，当該応答メッセージを第一のセッション管理サーバに転送する。第一のセッション管理サーバは，当該応答メッセージを第一の通信装置に転送する，という具合である。
【００１４】
なお，非特許文献1に記載の，複数のセッション管理サーバ同士が連携する機能を利用する場合には，通信装置のSIP-URIは当該通信装置がどのセッション管理サーバで管理されているかを示す情報を含んでいる。例えば，“USER1@SIPSERVER1.HITACHI.COM”というSIP-URIの場合には“SIPSERVER1.HITACHI.COM”がセッション管理サーバを識別する情報（通常，ドメイン，と呼ばれる）であることが一般的である。セッション管理サーバは，連携する他のセッション管理サーバの識別情報と，当該セッション管理サーバのIPアドレスを対応付けるテーブルを管理し，メッセージを送信するセッション管理サーバを決定する。
【００１５】
あるいは，複数のセッション管理サーバと，事前に定めた基準にしたがって通信装置からのメッセージを振り分ける，負荷分散装置と，を用いてセッション管理サーバの負荷を分散する方法が存在する。
【００１６】
例えば，特許文献1では，呼状態を複数のセッション管理サーバから読み書き可能なデータベースに記憶し，複数のサーバのうち利用可能なサーバが処理を実施する方法が開示されている。
【００１７】
なお，非特許文献1では，セッション管理サーバと通信装置との間の通信データの盗聴や改ざんを防ぐためにＴＬＳやＳ／ＭＩＭＥといった暗号化通信プロトコルを用いることが記載されている。
【００１８】
【特許文献１】特許3730545号明細書
【非特許文献１】IETF，RFC3261：SIP: Session Initiation Protocol，[2005年11月29日検索] ，インターネット＜URL：http://www.ietf.org/rfc/rfc3261.txt＞
【発明の開示】
【発明が解決しようとする課題】
【００１９】
今日，ドメインにはセッション管理サーバの識別情報ではなく，当該通信装置の所属組織を記載したい，という場合が多い。すなわち，同じ組織に所属する通信装置は，“USER1@HITACHI.COM”や“USER2@HITACHI.COM”等のように，同じドメインにしたいという要求がある。このようにすることで，通信装置のドメイン名を確認するだけで，当該通信装置の所属組織を一意に特定することができる。
しかしながら，複数のセッション管理サーバ同士が連携する機能を利用して負荷分散を行う場合，通信装置のSIP-URIのドメインにはセッション管理サーバを特定するための識別情報が含まれている必要があるため，上記の要求を実現することはできない，という課題がある。
【００２０】
また，複数のセッション管理サーバ同士が連携する機能を利用して負荷分散を行う場合には，管理者が通信管理装置の初期設定を行う等によって，一旦，通信装置に対してSIP-URIを割り当ててしまうと，通信装置の設定を変更することなしにはログインするセッション管理サーバを変更できない，という課題もある。このため，例えば，10台のセッション管理サーバで運用していたシステムで，通信装置の数が少なくなったために，セッション管理サーバを8台に減らす，といった運用の手間が大きくなってしまう。
【００２１】
特許文献1に記載の負荷分散方法では，通信装置のメッセージ単位で，負荷分散装置が当該メッセージを処理するセッション管理サーバを動的に選択してメッセージを振り分けるため，上記のような課題は存在しない。
【００２２】
しかしながら，特許文献1に記載の負荷分散方法は，セッション管理サーバと通信装置の間でTLS通信を使用している場合，ある通信装置は当該通信装置のREGISTERメッセージを処理したセッション管理サーバとの間で通信セッションを保持している。このため，例えば，第一の通信装置から第二の通信装置との通信を要求するINVITEメッセージを受信したセッション管理サーバが，第二の通信装置のREGISTERメッセージを処理したセッション管理サーバでなかった場合には，第二の通信装置と通信ができない，という課題がある。
【００２３】
通信セッションの保持とは，例えば，データの送信元，受信元双方が，どこまでデータを送信したか，受信したかという状態を共有することを指す。したがって，上記のような課題を持つものは，TLSだけでなく，TCPに代表される，データ送信中も，データが届いているかを確認しながら通信を行うコネクション型の通信が該当する。
【００２４】
したがって，特許文献１に記載の負荷分散方法では、信頼できる通信と，安全な通信との両立が難しい、という課題がある。
【課題を解決するための手段】
【００２５】
本発明は，通信装置の識別情報にセッション管理サーバの識別情報を含めることなく，セッション管理サーバの処理負荷を分散することができるデータ通信システムを提供する。
【００２６】
また，本発明は，セッション管理サーバの台数を柔軟に増減できるデータ通信システムを提供する。
【００２７】
さらに，本発明は，セッション管理サーバと通信装置との間で共有情報が必要な通信を実施している場合でも，セッション管理サーバにかかるメッセージ処理の負荷を分散しながら，データ通信を実現できるデータ通信システムを提供する。
【００２８】
具体的には，本発明は，相互にデータ通信を行う，複数の通信装置と，通信装置間のデータ通信のセッションを管理する，複数のセッション管理サーバと，事前に定めた基準にしたがって通信装置から受信したメッセージを処理するセッション管理サーバを振り分ける負荷分散装置と，からなるデータ通信システムにおいて，現在ログインしている通信装置と，当該通信装置が行っている通信の状態と，を管理する手段と，通信装置と通信するために必要な情報を取得する手段と，をセッション管理サーバに設けたことを主な特徴とする。
【００２９】
上記通信装置と通信するために必要な情報とは，当該通信装置を管理しているセッション管理サーバに関する情報や，通信装置との通信セッションを保持するための共有情報が該当する。
【００３０】
本発明が提供するデータ通信システムは，より具体的には，当該通信装置間のデータ通信のセッションを管理する，複数のセッション管理サーバと，事前に定めた基準にしたがって，通信装置１から通信装置２への通信メッセージであって，上記通信装置２を管理するセッション管理サーバを特定する情報を備えない通信メッセージを，いずれかの上記セッション管理サーバに振り分ける負荷分散装置と，上記負荷分散装置から上記通信メッセージを受信したセッション管理サーバに，上記通信装置２と通信するために必要な情報を取得させる手段と，を備えることを特徴とする，複数の通信装置相互のデータ通信を管理するデータ通信システムである。
【００３１】
また，上記通信装置２と通信するために必要な情報とは，当該通信装置２がログインしているセッション管理サーバを特定するための識別情報であってもよい。
【００３２】
また，上記通信装置２と通信するために必要な情報を取得させる手段は，上記通信装置２がログインしているか否かを，上記セッション確立要求メッセージを受信したセッション管理サーバが他のセッション管理サーバに問い合わせる手段と，上記通信装置２がログインしているセッション管理サーバが，当該通信装置２がログインしていることを，上記セッション確立要求メッセージを受信したセッション管理サーバに応答する手段と，を含んでもよい。
【００３３】
また，上記通信装置２と通信するために必要な情報を取得させる手段は，上記複数のセッション管理サーバがアクセス可能で，かつ，上記通信装置がログインしているセッション管理サーバを特定するための識別情報を記録した共有データベースと，上記セッション確立要求メッセージを受信したセッション管理サーバが，当該共有データベースを検索する手段と，を含んでもよい。
【００３４】
また，上記通信メッセージは，セッション確立要求メッセージまたはセッション確立応答メッセージであってもよい。
【００３５】
また，上記通信装置２と通信するために必要な情報は，当該通信装置２と通信する際に使用する暗号化通信設定であって，上記通信装置２と通信するために必要な情報を取得させる手段は，当該通信装置２と通信する際に使用する暗号化通信設定を記録する，上記複数のセッション管理サーバがアクセス可能な共有データベースと，上記セッション確立要求メッセージを受信したセッション管理サーバが，当該共有データベースを検索する手段と，を含んでもよい。
【００３６】
また，上記通信メッセージは，呼情報検索要求メッセージまたは呼情報検索応答メッセージであってもよい。
【００３７】
なお，セッション管理サーバを特定するための識別情報とは，ドメイン名、ホスト名、IPアドレス、URI等であってもよい。
【００３８】
上記態様によれば，通信装置がログインするセッション管理サーバは，通信装置がREGISTERメッセージを送信した際に負荷分散装置によって選択されるため，通信装置のSIP-URIのドメインには，セッション管理サーバの識別情報ではなく，所属組織の情報を記載することができると同時に，セッション管理サーバの数を通信装置の数に合わせて増減させる運用が可能である。
【００３９】
さらに，上記態様によれば，セッション管理サーバはメッセージの送信先である通信装置と通信するために必要な情報を取得してメッセージを送信するため，セッション管理サーバと通信装置との間で共有情報が必要な通信を実施している場合でも，セッション管理サーバにかかるメッセージ処理の負荷を分散しながら，データ通信を実現できる。
【発明の効果】
【００４０】
本発明によれば，信頼できる通信や安全な通信との両立が可能な負荷分散方法が可能になる。
【００４１】
また，同じドメインに属する複数のSIPサーバを用いる場合であっても負荷分散が可能になる。
【発明を実施するための最良の形態】
【００４２】
以下，図面を用いて本発明の実施の形態について説明する。なお，これらの実施形態によって本発明が限定されるものではない。
【００４３】
また，以下，SIPへの適用例を説明するが，SIP以外にも，通信セッションを確立する場合にセッション管理サーバを介してセッション確立要求メッセージや応答メッセージを送受するようなシステムにも，本発明は適用できる。
【００４４】
さらに，以下の各実施例における各装置は，例えば，図2にその構成例を示すような，プロセッサ（CPU）91と，プロセッサ91が実行する各種ソフトウェア(プログラム)とデータを記憶するためのメモリ92および／またはハードディスク93と，ネットワーク0（LAN1，LAN2）に接続するためのネットワークインタフェース94と，マウス，キーボードなどの入力装置，表示装置，そして外部記憶媒体の読み書き装置を含む入出力装置95とからなり，これらの構成要素がバスなどの内部通信線(バスという)16によって相互接続されている一般的な電子計算機上に実現されるものである。
【００４５】
すなわち，以下の各実施例における各装置が備える処理部とその処理は，それぞれの装置においてハードディスク93またはメモリ92に格納された必要なプログラムを必要なタイミングでプロセッサ91が実行することにより，実現される。これらのプログラムは予め，各装置のハードディスク93またはメモリ92に格納されていても良いし，必要なときに，当該装置が利用可能な媒体を介して，他の装置から上記記憶部に導入されてもよい。媒体とは，たとえば，入出力装置95にて利用可能な着脱可能な記憶媒体，またはネットワークインタフェース94を介して利用可能な通信媒体（すなわちネットワークまたはネットワークを伝搬する搬送波やディジタル信号）を指す。また，上述の各々の処理部を集積回路などのハードェアとして構成することも可能である。
【００４６】
また，以下の実施例に於いて使用しているドメイン名，URL，URI，IPアドレス等の識別子は，説明のために用いる架空のものであり，実在するものがあったとしても関係はない。
【実施例１】
【００４７】
まず，図1から図7を参照して，第一の実施例について説明する。
【００４８】
図1は，第一の実施例におけるシステム構成を示した図である。
【００４９】
ここに示したシステムは，セッション管理サーバ装置である，3台のSIPサーバ（SIPサーバ11，SIPサーバ12，SIPサーバ13）と，負荷分散装置30と，ユーザが使用してサービスとのデータ通信を実施する通信装置（ユーザ端末という）51と，サービスを提供する通信装置52と，からなり，3台のSIPサーバと負荷分散装置30とはLAN1を介して接続されており，さらに，負荷分散装置30と通信装置51と通信装置52とはネットワーク0を介して接続されている。
【００５０】
また，SIPサーバ11は192.168.10.11というIPアドレスが割り当てられており，SIPサーバ11にログインしている通信装置を管理するためのレジストラDB21と，SIPサーバ11が管理している通信セッションの情報を管理するための呼情報DB41とを備えている。SIPサーバ11のソフトウェア構造は，LAN1を介して，他のSIPサーバや負荷分散装置30と通信するためのネットワークインタフェースカード（NIC）制御部101と，SIPメッセージを処理するSIPメッセージ処理部102と，レジストラDB21への処理を制御するレジストラ処理部103と，呼情報DB41への処理を制御するセッション制御部104と，ある通信管理装置がログインしているSIPサーバを検索するSIPサーバ検索部105と，からなる。
【００５１】
また，SIPサーバ12は192.168.10.12というIPアドレスが割り当てられており，SIPサーバ12にログインしている通信装置を管理するためのレジストラDB22と，SIPサーバ12が管理している通信セッションの情報を管理するための呼情報DB42とを備え，SIPサーバ11と同様のソフトウェア構造をしている。さらに，SIPサーバ13は192.168.10.13というIPアドレスが割り当てられており，SIPサーバ13にログインしている通信装置を管理するためのレジストラDB23と，SIPサーバ13が管理している通信セッションの情報を管理するための呼情報DB43とを備え，SIPサーバ11と同様のソフトウェア構造をしている。
【００５２】
また，負荷分散装置30はネットワーク0を介した通信装置からメッセージを一元的に受信し，SIPサーバにメッセージを転送する機能を持つ装置であり，192.168.10.1というIPアドレスが割り当てられている。なお，本実施例で使用する負荷分散装置30は，あらかじめ定められた期間内に同じ通信装置からメッセージを受信した場合には，当該メッセージを直前にメッセージを転送したSIPサーバに転送する機能を備えている。
【００５３】
さらに，通信装置51は，192.168.20.11というIPアドレスと，user@hitachi.comというSIP-URIとが割り当てられている。通信装置51のソフトウェア構造は，ネットワーク0を介して，負荷分散装置30や通信装置52と通信するためのネットワークインタフェースカード（NIC）制御部511と，SIPメッセージを処理するSIPメッセージ処理部512と，通信装置52が提供するサービスを享受するサービス通信装置処理部513と，からなる。
【００５４】
また，通信装置52は，192.168.30.11というIPアドレスと，service@hitachi.comというSIP-URIとが割り当てられている。通信装置52のソフトウェア構造は，ネットワーク0を介して，負荷分散装置30や通信装置51と通信するためのネットワークインタフェースカード（NIC）制御部521と，SIPメッセージを処理するSIPメッセージ処理部522と，通信装置51にサービスを提供するサービス通信装置処理部523と，からなる。
【００５５】
以下，図1に示した通信装置51が，通信装置52とデータ通信を行う場合の通信手順を例にして，第1の実施例について説明する。
【００５６】
図3および4は，第1の実施例によるデータ通信を示すシーケンス図である。
【００５７】
まず，第一の実施例では，通信装置51および通信装置52はSIPサーバへのログイン処理を行う。
【００５８】
図3は，通信装置51および通信装置52がSIPサーバへのログイン処理を行う場合のシーケンスを示した図である。
【００５９】
まず，図3では，通信装置52がSIPサーバにログイン処理を行う。
【００６０】
すなわち，通信装置52は，負荷分散装置30を介して，SIPサーバとTLS通信のネゴシエーションを行う（S1）。このとき，通信装置52からTLS通信のネゴシエーションを要求するメッセージを受信した負荷分散装置30は，3台のSIPサーバの中からメッセージを転送するSIPサーバを選択すると，選択したSIPサーバにメッセージを転送する。図3では，SIPサーバ13が選択され，通信装置52とSIPサーバ13との間でTLS通信が確立される。
TLS通信では，通信装置52やSIPサーバ13は通信セッションが切断されていないことを確認するメッセージを定期的に送信する。このため，負荷分散装置30は，通信装置52とSIPサーバ13との間でTLS通信が確立している間は，通信装置52からのメッセージを常にSIPサーバ13に転送するようになる。
【００６１】
次に，通信装置52はロケーション登録を要求するため，負荷分散装置30にSIPメッセージの中のREGISTERメッセージを送信する（S2）。REGISTERメッセージを受信した負荷分散装置30は，当該メッセージをSIPサーバ13に転送する（S3）。
【００６２】
REGISTERメッセージを受信したSIPサーバ13は，レジストラ処理部103がレジストラDB23に，受信したREGISTERメッセージのFromヘッダが示す要求元SIP-URI（service@hitachi.com）とContactヘッダが示す要求元IPアドレス（192.168.30.11）との関係を示すロケーションデータを登録すると，SIPメッセージ処理部102がロケーション登録の成功を伝えるために通信装置52宛のSIP応答メッセージを送信する（S4）。
【００６３】
SIP応答メッセージを受信した負荷分散装置30は，当該メッセージを通信装置52に送信する（S5）。
【００６４】
以上により，通信装置52のSIPサーバにログインが完了し，通信装置52は通信装置51からのサービス提供要求を待ち受ける。
【００６５】
続いて，本実施例では，通信装置51がSIPサーバへのログイン処理を行う。
【００６６】
すなわち，通信装置51は，負荷分散装置30を介して，SIPサーバとTLS通信のネゴシエーションを行う（S6）。このとき，通信装置51からTLS通信のネゴシエーションを要求するメッセージを受信した負荷分散装置30は，3台のSIPサーバの中からメッセージを転送するSIPサーバを選択すると，選択したSIPサーバにメッセージを転送する。図3では，SIPサーバ11が選択され，通信装置51とSIPサーバ11との間でTLS通信が確立される。以降，通信装置51とSIPサーバ11との間でTLS通信が確立している間は，負荷分散装置30は通信装置51からのメッセージを常にSIPサーバ11に転送する。
【００６７】
次に，通信装置51はロケーション登録を要求するため，負荷分散装置30にREGISTERメッセージを送信する（S7）。REGISTERメッセージを受信した負荷分散装置30は，当該メッセージをSIPサーバ11に転送する（S8）。
【００６８】
REGISTERメッセージを受信したSIPサーバ11は，レジストラ処理部103がレジストラDB21に，受信したREGISTERメッセージのFromヘッダが示す要求元SIP-URI（user@hitachi.com）とContactヘッダが示す要求元IPアドレス（192.168.20.11）との関係を示すロケーションデータを登録すると，SIPメッセージ処理部102がロケーション登録の成功を伝えるために通信装置51宛のSIP応答メッセージを送信する（S9）。
【００６９】
SIP応答メッセージを受信した負荷分散装置30は，当該メッセージを通信装置51に送信する（S10）。
【００７０】
以上により，通信装置51のSIPサーバにログインが完了する。
【００７１】
ログイン処理が完了した通信装置51は通信装置52にサービス提供を要求する。
【００７２】
図4は，ログイン処理が完了した通信装置51が通信装置52にサービスの提供を受ける場合のシーケンスを示した図である。
【００７３】
まず，通信装置51が通信装置52にサービスの提供を受ける場合，通信装置51はINVITEメッセージを送信する（S11）と，負荷分散装置30は，通信装置51とTLS通信が確立しているSIPサーバ11に当該INVITEメッセージを転送する（S12）。
【００７４】
INVITEメッセージを受信したSIPサーバ11は，図5に示す処理フローにしたがって，当該INVITEメッセージを処理する。
【００７５】
すなわち，SIPサーバ11は，レジストラ処理部103がレジストラDB21にアクセスして，受信したINVITEメッセージのToヘッダが示す受信者SIP-URIのIPアドレスを検索する（ステップ1001）。
【００７６】
ここで，レジストラDB21から該当するIPアドレスが検索できた場合には，ステップ1007に遷移して，SIPサーバ11のセッション管理部104が，INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを呼情報DB41に記録する。
【００７７】
次に，検索したIPアドレスにINVITEメッセージを送信する（ステップ1008）。このとき，SIPサーバ11はINVITEメッセージのViaヘッダにSIPサーバ11の識別情報を追加する。
【００７８】
一方，ステップ1001で，レジストラDB21から該当するIPアドレスが検索できなかった場合には，当該SIP-URIが示す通信装置を管理しているSIPサーバを検索するため，SIPサーバ検索部105がSIPサーバ検索要求メッセージ81を作成し，ブロードキャスト通信によってLAN1に当該SIPサーバ検索要求メッセージ81を送信する（ステップ1003，S13）。
【００７９】
本実施例のSIPサーバ検索要求メッセージ81は，図6に示すように，検索対象SIP-URIを含むコマンドライン行（図6では「SEARCH_REQUEST sip:service@hitachi.com」と記載されているが，これは，service@hitachi.comというSIP-URIを持つ通信装置を管理しているSIPサーバを検索していることを意味する）から構成される。
【００８０】
一方，SIPサーバ検索要求メッセージ81を受信したSIPサーバは，図7に示す処理フローにしたがって，当該SIPサーバ検索要求メッセージ81を処理する。
【００８１】
すなわち，SIPサーバは，ステップ1011でSIPサーバ検索要求メッセージ81を受信すると，レジストラ処理部103がレジストラDBにアクセスして，当該SIPサーバ検索要求メッセージ81のコマンドライン行が示すSIP-URIのIPアドレスを検索する（ステップ1012）。
【００８２】
ここで，レジストラDB21から該当するIPアドレスが検索できなかった場合には，そのまま処理を終了する。
【００８３】
一方，レジストラDB21から該当するIPアドレスが検索できた場合，SIPサーバ検索部105がSIPサーバ検索応答メッセージ82を作成し，SIPサーバ検索要求メッセージ81の送信元行が示す送信先にメッセージを送信する（ステップ1014）。
【００８４】
本実施例のSIPサーバ検索応答メッセージ82は，図6に示すように，検索対象SIP-URIの検索結果を示すコマンドライン行（図6では「SEARCH_RESULT SUCCESS」と記載されているが，これは検索に成功したことを意味する）と，検索対象SIP-URIを管理しているSIPサーバを特定するための識別情報（図6では「IP_ADDRESS: 192.168.10.13」と記載されているが，これは，検索対象SIP-URIを管理しているSIPサーバのIPアドレスが192.168.10.13であることを意味する）と，から構成される。
【００８５】
図4では，通信装置52はSIPサーバ13にログインしているため，SIPサーバ13がSIPサーバ検索応答メッセージ82をSIPサーバ11に送信する（S14）。
【００８６】
SIPサーバ検索応答メッセージ82を受信したSIPサーバ11は，当該メッセージを参照して，通信装置を管理しているSIPサーバのIPアドレスを取得する（ステップ1005）。
【００８７】
SIPサーバ11は，取得したIPアドレスがSIPサーバのIPアドレスとして妥当なアドレスである（例えば，SIPサーバがローカルに全SIPサーバのIPアドレスのリストを管理しているような場合，IPアドレスが当該リストに記載されている，等）と判断する（ステップ1006）と，ステップ1007に遷移して，SIPサーバ11のセッション管理部104が，INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，当該INVITEメッセージの送信元のSIP-URIと，当該INVITEメッセージの送信先のSIP-URIと，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを呼情報DB41に記録する。
【００８８】
次に，SIPサーバ検索応答メッセージ82から取得したIPアドレス，すなわち，図4ではSIPサーバ13にINVITEメッセージを送信する（ステップ1008，S15）。このとき，SIPサーバ11はINVITEメッセージのViaヘッダにSIPサーバ11の識別情報を追加する。
【００８９】
INVITEメッセージを受信したSIPサーバ13は，図5に示す処理フローにしたがって，当該INVITEメッセージを処理する。
【００９０】
すなわち，SIPサーバ13は，ステップ1001で，レジストラ処理部103がレジストラDB23にアクセスして，受信したINVITEメッセージのToヘッダが示す受信者SIP-URIのIPアドレスを検索する。
【００９１】
ここで，SIPサーバ13は通信装置52がログインしているSIPサーバであるため，レジストラDB23から該当するIPアドレスが検索できる。
【００９２】
そこで，SIPサーバ13はステップ1007に遷移して，SIPサーバ13のセッション管理部104が，INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，Fromメッセージが示す通信元の識別情報と，Toメッセージが示す通信先の識別情報と，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを呼情報DB41に記録すると，レジストラDB23から検索したIPアドレス，すなわち，通信装置52に負荷分散装置30を介してINVITEメッセージを送信する（ステップ1008，S16，S17）。このとき，SIPサーバ13はINVITEメッセージのViaヘッダにSIPサーバ13の識別情報を追加する。
【００９３】
INVITEメッセージを受信した通信装置52は，SIPメッセージ処理部523が当該メッセージで要求されている通信が受け入れ可能かどうかを検査し，検査結果をSIP応答メッセージとして作成すると，当該メッセージを負荷分散装置30に送信する（S18）。負荷分散装置30は当該メッセージをSIPサーバ13に送信する（S19）。
【００９４】
SIP応答メッセージを受信したSIPサーバ13は，SIPメッセージ処理部102が当該メッセージの内容を確認し，「通信許可」であれば，セッション管理部104が呼情報DB43にアクセスして，当該メッセージのCall-IDヘッダが示す通信セッションの状態を「接続中」状態に更新する。
【００９５】
一方，「通信拒否」である場合には，セッション管理部104が呼情報DB43にアクセスして，当該メッセージのCall-IDヘッダが示す通信セッションに関するエントリを削除する。
【００９６】
次に，SIPサーバ13は，SIP応答メッセージのViaヘッダを確認して，SIPサーバ11に当該メッセージを送信する（S20）。
【００９７】
SIP応答メッセージを受信したSIPサーバ11は，SIPサーバ13と同様に，SIPメッセージ処理部102が当該メッセージの内容にしたがって呼情報DB41を更新すると，負荷分散装置30を介して通信装置51にSIP応答メッセージを送信する（S21，S22）。
【００９８】
SIP応答メッセージを受信した通信装置51は，SIPメッセージ処理部512が当該メッセージの内容を確認し，「通信許可」であれば，サービス通信装置処理部513が通信装置52のサービスサーバ処理部523とデータ通信を実施し（S23），サービスを享受する。
【００９９】
サービスの利用を終了すると，通信装置51は負荷分散装置30にBYEメッセージを送信する（S24）。BYEメッセージを受信した負荷分散装置30は当該メッセージをSIPサーバ11に送信する（S25）。
【０１００】
BYEメッセージを受信したSIPサーバ11は，図5の処理フローにしたがってメッセージを処理する。この結果，SIPサーバ11は，ステップ1004でSIPサーバ検索要求メッセージ81をブロードキャスト通信し（S26），SIPサーバ13からSIPサーバ検索応答メッセージ82を受信する（S27）。また，ステップ1007でセッション管理部104が呼情報DB41にアクセスして，当該BYEメッセージのCall-IDヘッダが示す通信セッションの状態を「通信切断中（受信先からの応答待ち）」に更新する。さらに，SIPサーバ11は，ステップ1008で，  SIPサーバ13に当該BYEメッセージを送信する（S28）。このとき，SIPサーバ11はBYEメッセージのViaヘッダにSIPサーバ11の識別情報を追加する。
【０１０１】
次に，BYEメッセージを受信したSIPサーバ13も，図5の処理フローにしたがってメッセージを処理する。この結果，SIPサーバ13は，ステップ1007でセッション管理部104が呼情報DB43にアクセスして，当該BYEメッセージのCall-IDヘッダが示す通信セッションの状態を「通信切断中（受信先からの応答待ち）」に更新する。
【０１０２】
さらに，SIPサーバ13は，ステップ1008で，負荷分散装置30を介して通信装置52に当該BYEメッセージを送信する（S29，S30）。このとき，SIPサーバ13はBYEメッセージのViaヘッダにSIPサーバ13の識別情報を追加する。
【０１０３】
BYEメッセージを受信した通信装置52は，SIPメッセージ処理部523が当該メッセージで要求されている通信の切断処理を実施し，SIP応答メッセージを負荷分散装置30に送信する（S31）。負荷分散装置30は当該メッセージをSIPサーバ13に送信する（S32）。
【０１０４】
SIP応答メッセージを受信したSIPサーバ13は，セッション管理部104が呼情報DB43にアクセスして，当該メッセージのCall-IDヘッダが示す通信セッションに関するエントリを削除する。
【０１０５】
次に，SIPサーバ13は，SIP応答メッセージのViaヘッダを確認して，SIPサーバ11に当該メッセージを送信する（S33）。
【０１０６】
SIP応答メッセージを受信したSIPサーバ11は，SIPサーバ13と同様に，SIPメッセージ処理部102が当該メッセージの内容にしたがって呼情報DB41を更新すると，負荷分散装置30を介して通信装置51にSIP応答メッセージを送信する（S34，S35）。
【０１０７】
なお，図5のステップ1004においてSIPサーバ検索応答メッセージ82があらかじめ定めた期間を超えても戻ってこない場合や，図5のステップ1006においてSIPサーバ検索応答メッセージ82から当該メッセージの送信元が取得できない場合には，SIPサーバはステップ1009に遷移して，SIPメッセージ処理部102がエラーの発生を意味するSIP応答メッセージを作成し，SIPメッセージの送信元に返信する。例えば，通信装置52がログアウトした後に，通信装置51が通信装置52にINVITEメッセージを送信するような場合，このような状態が発生する。
【０１０８】
以上が，本実施例に置いて，ログイン処理が完了した通信装置51が通信装置52にサービスの提供を受ける場合の動作である。
【０１０９】
なお，第一の実施例では，呼情報はセッション管理サーバが管理し，共有データベースは持っていなくてもよい。
【０１１０】
一方，特許文献1に記載の負荷分散方法は，1つのメッセージを処理する毎に共有データベースの更新が発生する。このため，非常に高い処理性能を持った共有データベースや，セッション管理サーバと共有データベースとの間に高速な通信手段が要求される，という課題がある。また，特許文献1に記載の負荷分散方法は，同一の呼情報を複数のセッション管理サーバが同時に制御しようとすると共有データベースの状態が一意に確定できなくなってしまう，という課題もある。
【０１１１】
すなわち，本実施例によれば，高性能な共有データベースや，当該共有データベースとセッション管理サーバとの間の高速な通信手段は必要ない上，共有データベースの状態が一意に確定できなくなってしまうような状態も発生しない，という効果がある。
【０１１２】
また，第一の実施例では，SIPサーバ検索応答メッセージ82に記載するSIPサーバを特定するための識別情報としてIPアドレスを用いているが、本発明はこれに限定されない。SIPサーバを特定するための識別情報として、IPアドレスの代わりに、IPアドレスとポート番号の組み合わせやドメイン名、ホスト名、URI、MACアドレス等を使用してもよい。
【０１１３】
また，第一の実施例では，INVITEメッセージやBYEメッセージの送信先の通信装置を検索するために，SIPサーバ検索メッセージをLAN1にブロードキャストするようにしているが，本発明はこれに限定されない。LAN1の管理者が複数のSIPサーバに届くマルチキャスト通信を設定し，SIPサーバは当該マルチキャスト通信を利用してSIPサーバ検索メッセージを送信するようにしても良い。すなわち，特殊なIPアドレスをマルチキャスト用のIPアドレスとして使用し，LAN1の管理者が該IPアドレス宛のパケットを受信した場合に、複数のSIPサーバにパケットを転送するよう、LAN1内のルータを設定してもよい。
【０１１４】
このようにすることで，ブロードキャスト通信を利用する場合に比べてLAN1のネットワーク負荷を低減することができる。あるいは，SIPサーバが他のSIPサーバのIPアドレスを管理しておき，個々のSIPサーバに対してSIPサーバ検索メッセージを個別に送信するようにしても良い。このようにすることで，異なるサブドメインに属するSIPサーバとの間でも負荷分散を行えるようになる。
【０１１５】
また，第一の実施例では，通信装置51が通信の切断処理を開始するようにしているが，本発明はこれに限定されない。通信装置52から切断処理を実行してもよい。
【実施例２】
【０１１６】
次に，図8から図14を参照して，第二の実施例について説明する。
【０１１７】
上述した第一の実施例では，通信装置を管理しているSIPサーバの情報を取得するためにSIPサーバ検索部105がSIPサーバ検索要求メッセージ81をブロードキャスト通信し，SIPサーバ検索要求メッセージ81を受信した，SIPサーバが自身のレジストラDBを検索し，検索に成功したSIPサーバがSIPサーバ検索応答メッセージ82を応答するようにしていた。
【０１１８】
第二の実施例では，SIPサーバからアクセス可能で，かつ，現在ログインしている通信装置がどのSIPサーバにログインしているかを管理する，管理DBを設けたことを特徴とする。
【０１１９】
図8は，第二の実施例におけるシステム構成を示した図である。
【０１２０】
ここに示したシステムは，セッション管理サーバである，3台のSIPサーバ（SIPサーバ11，SIPサーバ12，SIPサーバ13）と，負荷分散装置30と，本実施例の特徴である管理DB40と，ユーザが使用してサービスとのデータ通信を実施する通信装置（ユーザ端末ということもある）51と，サービスを提供する通信装置52と，からなり，3台のSIPサーバと負荷分散装置30とはLAN1を介して接続されており，3台のSIPサーバと管理DB40とはLAN2を介して接続されており，さらに，負荷分散装置30と通信装置51と通信装置52とはネットワーク0を介して接続されている。
【０１２１】
なお，管理DB40は，図2に示すハードウェア構成を備えた情報処理装置である。
【０１２２】
また，SIPサーバ11は192.168.10.11というIPアドレスが割り当てられており，SIPサーバ11にログインしている通信装置を管理するためのレジストラDB21と，SIPサーバ11が管理している通信セッションの情報を管理するための呼情報DB41とを備えている。SIPサーバ11のソフトウェア構造は，LAN1を介して，他のSIPサーバや負荷分散装置30と通信するためのネットワークインタフェースカード（NIC）制御部101と，SIPメッセージを処理するSIPメッセージ処理部102と，レジストラDB21への処理を制御するレジストラ処理部103と，呼情報DB41への処理を制御するセッション制御部104と，ある通信管理装置がログインしているSIPサーバを検索するSIPサーバ検索部105と，からなる。
【０１２３】
また，SIPサーバ12は192.168.10.12というIPアドレスが割り当てられており，SIPサーバ12にログインしている通信装置を管理するためのレジストラDB22と，SIPサーバ12が管理している通信セッションの情報を管理するための呼情報DB42とを備え，SIPサーバ11と同様のソフトウェア構造をしている。さらに，SIPサーバ13は192.168.10.13というIPアドレスが割り当てられており，SIPサーバ13にログインしている通信装置を管理するためのレジストラDB23と，SIPサーバ13が管理している通信セッションの情報を管理するための呼情報DB43とを備え，SIPサーバ11と同様のソフトウェア構造をしている。
【０１２４】
また，負荷分散装置30はネットワーク0を介した通信装置からメッセージを一元的に受信し，SIPサーバにメッセージを転送する機能を持つ装置であり，192.168.10.1というIPアドレスが割り当てられている。なお，実施例で使用する負荷分散装置30は，あらかじめ定められた期間内に同じ通信装置からメッセージを受信した場合には，当該メッセージを直前にメッセージを転送したSIPサーバに転送する機能を備えている。
【０１２５】
さらに，通信装置51は，192.168.20.11というIPアドレスと，user@hitachi.comというSIP-URIとが割り当てられている。通信装置51のソフトウェア構造は，ネットワーク0を介して，負荷分散装置30や通信装置52と通信するためのネットワークインタフェースカード（NIC）制御部511と，SIPメッセージを処理するSIPメッセージ処理部512と，通信装置52が提供するサービスを享受するサービス通信装置処理部513と，からなる。
【０１２６】
また，通信装置52は，192.168.30.11というIPアドレスと，service@hitachi.comというSIP-URIとが割り当てられている。通信装置52のソフトウェア構造は，ネットワーク0を介して，負荷分散装置30や通信装置51と通信するためのネットワークインタフェースカード（NIC）制御部521と，SIPメッセージを処理するSIPメッセージ処理部522と，通信装置51にサービスを提供するサービス通信装置処理部523と，からなる。
【０１２７】
以下，図8に示した通信装置51が，通信装置52とデータ通信を行う場合の通信手順を例にして，第二の実施例について説明する。
【０１２８】
図9および図10は，第二の実施例によるデータ通信を示すシーケンス図である。図3，図4と同一符号で示された第一実施例で説明済みのステップとメッセージについてはできる限り説明を省略する。
【０１２９】
まず，第二の実施例でも，通信装置51および通信装置52はSIPサーバへのログイン処理を行う。
【０１３０】
図9は，通信装置51および通信装置52がSIPサーバへのログイン処理を行う場合のシーケンスを示した図である。
【０１３１】
本実施例でも，通信装置52はSIPサーバ13とＴＬＳ通信を確立した後，REGISTERメッセージを送信して，ログイン処理を要求する（S1〜S3，S6〜S8）。
【０１３２】
このとき，SIPサーバ13は図11に示す処理フローにしたがってREGISTERメッセージを処理する。すなわち，REGISTERメッセージを受信したSIPサーバ13は，ステップ2001で，SIPサーバ検索要求メッセージ81を管理DB40に送信し（図9のS301），管理DB40にREGISTERメッセージを送信してきた通信装置，すなわち，通信装置52のSIP-URIがすでに登録済みかを検索する。管理DB40からSIPサーバ検索応答メッセージ82を受信し（図9のS302），管理DB40に通信装置52のSIP-URIがすでに登録済みであった場合，SIPサーバ13は，負荷分散装置30を介して，通信装置52にエラーを意味するSIP応答メッセージを送信する（ステップ2110）。
【０１３３】
なお，本実施例では，検索対象SIP-URIが未だ登録されていない場合，SIPサーバ検索応答メッセージ82のコマンドライン行は，検索に失敗したことを示すため，「SEARCH_RESULT FAILURE」と記載される。
【０１３４】
一方，管理DB40に通信装置52のSIP-URIが未だ登録されていなかった場合，SIPサーバ13はステップ2103で，レジストラDB23に通信装置52のSIP-URIとIPアドレスとを関連付けて保存する。
【０１３５】
次に，SIPサーバ13は，ステップ2104で，SIPサーバ登録要求メッセージ83を送信し（図9のS303），管理DB40に通信装置52のSIP-URIと，通信装置52がログインしているSIPサーバ，すなわちSIPサーバ13の情報と，を関連付けて登録する。
【０１３６】
なお，本実施例のSIPサーバ登録要求メッセージ83は，図6に示すように，登録対象SIP-URIを含むコマンドライン行（図6では「REGISTER_REQUEST sip:service@hitachi.com」と記載されているが，これは，service@hitachi.comというSIP-URIの登録を要求することを意味する）と，当該登録対象SIP-URIを管理しているSIPサーバの情報（図6では「CONTACT： 192.168.10.13:5060/UDP」と記載されているが，これは，検索対象SIP-URIを管理しているSIPサーバのIPアドレスが192.168.10.13であり，UDPの5060番ポートで通信を待ち受けていることを意味する）と，から構成される。
【０１３７】
次に，SIPサーバ13は，管理DB40からSIPサーバ登録応答メッセージ82を受信する（図9のS304）と，負荷分散装置30を介して，通信装置52にログイン成功を意味するSIP応答メッセージを送信する（ステップ2105）。
【０１３８】
なお，本実施例のSIPサーバ登録応答メッセージ84は，図6に示すように，登録対象SIP-URIの登録結果を含むコマンドライン行（図6では「REGISTER_RESULT SUCCESS」と記載されているが，これは，登録に成功したことを意味する）と，登録対象SIP-URIを示す行（図6では「SIP-URI: sip:service@hitachi.com」と記載されている）と，から構成される。
【０１３９】
以上により，通信装置52のログインが完了する。
【０１４０】
通信装置51も同様にしてログインを実施する。
【０１４１】
次に，ログイン処理が完了した通信装置51は通信装置52にサービス提供を要求する。
【０１４２】
図10は，ログイン処理が完了した通信装置51が通信装置52にサービスの提供を受ける場合のシーケンスを示した図である。
【０１４３】
図10のS11〜S12のシーケンスで通信装置51から負荷分散装置30を介してINVITEメッセージを受信したSIPサーバ11は，図12に示す処理フローにしたがって当該INVITEメッセージを処理する。
【０１４４】
すなわち，SIPサーバ11は，まず，本システムが通信装置とSIPサーバとの通信にコネクション型の通信を使用しているかどうかを判定する（ステップ2000）。
【０１４５】
ここで，コネクション型の通信を使用している場合，ステップ2006以降を実行する。
【０１４６】
一方，コネクション型の通信を使用していない場合には，ステップ2001に遷移して，レジストラDB21に上記INVITEメッセージの送信者（図10では通信装置51）のSIP-URIが登録されているかを検索する。
【０１４７】
ここで，上記INVITEメッセージの送信者のSIP-URIが登録されている場合には，ステップ2006以降を実行する。
【０１４８】
一方，上記INVITEメッセージの送信者のSIP-URIが登録されていない場合には，ステップ2003に遷移して，管理DB40にSIPサーバ検索要求メッセージ81を送信し，上記INVITEメッセージの送信者がログインしているSIPサーバを検索する。この結果，上記INVITEメッセージの送信者がログインしているSIPサーバが存在しない場合には，ステップ2020に遷移して，上記INVITEメッセージの送信者にエラーを意味するSIP応答メッセージを送信する。
【０１４９】
一方，上記INVITEメッセージの送信者がログインしているSIPサーバが存在した場合には，当該SIPサーバに関する情報が上記INVITEメッセージのViaヘッダに存在するかを確認する（ステップ2005）。ステップ2005で，上記INVITEメッセージのViaヘッダに上記INVITEメッセージの送信者がログインしているSIPサーバに関する情報が存在しなかった場合，SIPサーバ11は，上記INVITEメッセージの送信者がログインしているSIPサーバにINVITEメッセージを送信する。（なお，このときには，SIPサーバ11はINVITEメッセージのViaヘッダにSIPサーバ11の情報を含めなくても良い）
一方，ステップ2005で，上記INVITEメッセージのViaヘッダに上記INVITEメッセージの送信者がログインしているSIPサーバに関する情報が存在した場合，SIPサーバ11は，ステップ2006以降を実行する。
【０１５０】
コネクション型でない通信を使用している場合，ある通信装置がINVITEメッセージを送信した時に，負荷分散装置30が当該INVITEメッセージを上記通信装置がログインしていないSIPサーバに転送してしまうことが発生するが，ステップ2001からステップ2005までの処理を行うことにより，INVITEメッセージを上記通信装置がログインしているSIPサーバに送信することができ，上記通信装置がログインしているSIPサーバの呼情報DBを正しく更新することができる。
【０１５１】
本実施例でSIPサーバと通信装置との間の通信に使用しているTLS通信はコネクション型の通信であるため，ステップ2000の判定で，ステップ2006に遷移する。
【０１５２】
ステップ2006では，SIPサーバ11はレジストラDB21にINVITEメッセージの受信者（図10では通信装置52）のSIP-URIが登録されているかを検索する。
【０１５３】
ここで，レジストラDB21にINVITEメッセージの受信者のSIP-URIが登録されていた場合，SIPサーバ11は，セッション管理部104が，当該INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，Fromメッセージが示す通信元の識別情報と，Toメッセージが示す通信先の識別情報と，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを呼情報DB41に記録する（ステップ2010）と，当該SIP-URIに関連付けられているIPアドレスに対してINVITEメッセージを送信する（ステップ2011）。このとき，SIPサーバ11は上記INIVTEメッセージのViaヘッダにSIPサーバ11の情報を含める。
【０１５４】
一方，レジストラDB21にINVITEメッセージの受信者のSIP-URIが登録されていない場合には，SIPサーバ11はステップ2008でSIPサーバ検索要求メッセージ81を管理DB40に送信し（図10のS103），INVITEメッセージの受信者がログインしているSIPサーバを検索する。
【０１５５】
管理DB40からSIPサーバ検索応答メッセージ82を受信し（図10のS104），上記INVITEメッセージの受信者がログインしているSIPサーバ（図10ではSIPサーバ13が該当する）の情報が取得できた場合，SIPサーバ11は，セッション管理部104が，当該INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを呼情報DB41に記録する（ステップ2010）と，SIPサーバ検索応答メッセージ82から取得したSIPサーバのIPアドレスに対して上記INVITEメッセージを送信する（S15）。このとき，SIPサーバ11は上記INIVTEメッセージのViaヘッダにSIPサーバ11の情報を含める。
【０１５６】
なお，上記INVITEメッセージの受信者がログインしているSIPの情報が取得できなかった場合，SIPサーバ11は上記INVITEメッセージの送信者に，エラーを示すSIP応答メッセージを送信する（ステップ2020）。
【０１５７】
図10において，SIPサーバ11からINVITEメッセージを受信したSIPサーバ13は，SIPサーバ11と同様に図12に示す処理フローにしたがってINIVITEメッセージを処理する。この結果，SIPサーバ13は，ステップ2010で，セッション管理部104が，当該INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを呼情報DB43に記録すると，レジストラDB23から取得したIPアドレスに対して，負荷分散装置30を介して上記INVITEメッセージを送信する（S16，S17）。
【０１５８】
S17からS23までのシーケンスおよび処理は第一の実施例と同じであるため，説明を省略する。
【０１５９】
また，通信を切断する場合の処理についても，BYEメッセージを受信したSIPサーバは図12に示した処理フローにしたがってBYEメッセージを処理する以外は，第一の実施例とシーケンスおよび処理は同じであるので説明を省略する。
【０１６０】
以上が，ログイン処理が完了した通信装置51が通信装置52にサービスの提供を受ける場合の第二の実施例のシステムの動作である。
【０１６１】
次に，通信装置51や通信装置52はサービスの利用や提供が終了し，ログアウトする場合の処理について説明する。
【０１６２】
図13は，通信装置51がログアウトをする場合のシーケンスを示した図である。
【０１６３】
図13では，通信装置51がログアウトする場合の処理がS51からS57まで，のシーケンスで示されている。
【０１６４】
通信装置51がログアウトする場合，まず，通信装置51が負荷分散装置30にExpiresヘッダの値を0に設定したREGISTERメッセージを送信する（S51）。REGISTERメッセージを受信した，負荷分散装置30は，当該REGISTERメッセージをSIPサーバ11に転送する（S52）。
【０１６５】
REGISTERメッセージを受信したSIPサーバ11は，図14に示したフローにしたがってREGISTERメッセージを処理する。
【０１６６】
すなわち，SIPサーバ11は，まず，本システムが通信装置とSIPサーバとの通信にコネクション型の通信を使用しているかどうかを判定する（ステップ2200）。
【０１６７】
ここで，コネクション型の通信を使用している場合，ステップ2204以降を実行する。
【０１６８】
一方，コネクション型の通信を使用していない場合には，ステップ2201に遷移して，管理DB40にSIPサーバ検索要求メッセージ81を送信し，上記REGISTERメッセージの送信者（図13では通信装置51）がログインしているSIPサーバを検索する。この結果，上記REGISTERメッセージの送信者がログインしているSIPサーバが存在しない場合には，ステップ2230に遷移して，上記REGISTERメッセージの送信者にエラーを意味するSIP応答メッセージを送信する。
【０１６９】
一方，上記RESIGERメッセージの送信者がログインしているSIPサーバが存在した場合には，当該SIPサーバのIPアドレスが自分のIPアドレスと一致するかを確認する（ステップ2203）。ステップ2203で，IPアドレスが一致しなかった場合，SIPサーバ11は，上記REGISTERメッセージの送信者がログインしているSIPサーバにREGISTERメッセージを送信する。（なお，このときには，SIPサーバ11はREGISTERメッセージのViaヘッダにSIPサーバ11の情報を含めなくても良い）
一方，ステップ2203でIPアドレスが一致した場合，上記REGISTERメッセージのViaヘッダに上記REGISTERメッセージの送信者がログインしているSIPサーバに関する情報が存在した場合，SIPサーバ11は，ステップ2204以降を実行する。
【０１７０】
コネクション型でない通信を使用している場合，ある通信装置がREGISTERメッセージを送信した時に，負荷分散装置30が当該REGISTERメッセージを上記通信装置がログインしていないSIPサーバに転送してしまうことが発生するが，ステップ2201からステップ2203までの処理を行うことにより，REGISTERメッセージを上記通信装置がログインしているSIPサーバに送信することができ，上記通信装置がログインしているSIPサーバのレジストラDBを正しく更新することができる。
【０１７１】
ステップ2204では，SIPサーバ11は呼情報DB41を検索して，REGISTERメッセージの送信者のSIP-URIを含むようなエントリが存在するかを検索する。
【０１７２】
このとき，該当するエントリが存在しなかった場合（ステップ2205でNo）は，ステップ2207に遷移する。
【０１７３】
一方，該当するエントリが存在した場合（ステップ2205でYes），SIPサーバは該当する通信を終了させる処理を実施する。該当する通信を終了させると，ステップ2207に遷移する。
【０１７４】
ステップ2207では，SIPサーバ11はレジストラDB21にREGISTERメッセージの送信者のSIP-URIが登録されているかを検索する。
【０１７５】
このとき，該当するSIP-URIが登録されていない場合（ステップ2208でNo）は，ステップ2230に遷移して，上記REGISTERメッセージの送信者にエラーを意味するSIP応答メッセージを送信する。
【０１７６】
一方，該当するSIP-URIが登録されていた場合（ステップ2208でYes），SIPサーバ11は管理DB40にSIPサーバ削除要求メッセージ85を送信する（図13のS53）。
【０１７７】
なお，本実施例のSIPサーバ削除要求メッセージ85は，図6に示すように，削除対象SIP-URIを含むコマンドライン行（図6では「DELETE_REQUEST sip:user@hitachi.com」と記載されているが，これは，user@hitachi.comというSIP-URIの削除を要求することを意味する）から構成される。
【０１７８】
SIPサーバ削除要求メッセージ85を受信した管理DB40は，SIPサーバ削除要求メッセージ85で指定されたSIP-URIを含むエントリを削除すると，SIPサーバ削除応答メッセージ86をSIPサーバ11に送信する（図13のS54）。
【０１７９】
なお，本実施例のSIPサーバ削除応答メッセージ86は，図6に示すように，削除対象SIP-URIの削除結果を含むコマンドライン行（図6では「DELETE_RESULT SUCCESS」と記載されているが，これは，削除に成功したことを意味する）と，削除対象SIP-URIを示す行（図6では「SIP-URI: sip:user@hitachi.com」と記載されている）と，から構成される。
【０１８０】
SIPサーバ削除応答メッセージ86を受信したSIPサーバ11は，ステップ2210に遷移して，レジストラDB21から上記REGISTERメッセージの送信者のSIP-URIを含むエントリを削除する。
【０１８１】
次に，SIPサーバ11は，負荷分散装置30を介して通信装置51に，REGISTERメッセージの送信者に処理の成功を意味するSIP応答メッセージを送信する（図13のS55，S56）。
【０１８２】
以上が，REGISTERメッセージを受信したSIPサーバ11の動作である。
【０１８３】
SIP応答メッセージを受信した通信装置51は，TLS通信を終了する（S57）。
【０１８４】
以上が，通信装置51がログアウトをする場合の動作である。通信装置52がログアウトする場合も同様の動作をSIPサーバ13との間で行う。
【０１８５】
本実施例によれば，呼情報はセッション管理サーバが管理するので，管理DBには少なくとも通信装置がログインしているSIPサーバに関する情報を記録しておけばよい。
【０１８６】
このことによって，特許文献1に記載の負荷分散方法では，1つのメッセージを処理する毎に共有データベースの更新が発生するために非常に高い処理性能を持った共有データベースや，セッション管理サーバと共有データベースとの間に高速な通信手段が要求されるが，本実施例では管理DBにはそれほど高い処理性能やSIPサーバと管理DBの間で高速な通信手段は要求されない。また，同一の呼情報を複数のセッション管理サーバが同時に制御しようとしても，特許文献1に記載の負荷分散方法とは異なって，管理DBの状態が一意に確定できなくなってしまうような状態も発生しない。
【０１８７】
さらに，本実施例では，通信装置を管理しているSIPサーバの情報を取得するためにブロードキャスト通信ではなく，共有データベースを使用するため，SIPサーバ間で送受される通信量を抑えることができる，という効果がある。
【実施例３】
【０１８８】
次に，図15から図17を参照して，第三の実施例について説明する。
【０１８９】
上述した第一および第二の実施例では，SIPメッセージを受信したSIPサーバは，SIPメッセージの送信先がログインしているSIPサーバの情報を取得し，当該SIPサーバにSIPメッセージを送信するようにしていた。
【０１９０】
第三の実施例では，SIPサーバからアクセス可能で，かつ，現在ログインしている通信装置と通信するための通信設定を管理する管理DBを設け，SIPメッセージを受信したSIPサーバは，管理DBから通信設定を取得して，SIPメッセージの送信先と通信することを主な特徴とする。
【０１９１】
図15は，第三の実施例におけるシステム構成を示した図である。
【０１９２】
ここに示したシステムは，第二の実施例と同様に，3台のSIPサーバ（SIPサーバ11，SIPサーバ12，SIPサーバ13）と，負荷分散装置30と，管理DB40と，通信装置51と，通信装置52と，からなり，3台のSIPサーバと負荷分散装置30とはLAN1を介して接続されており，3台のSIPサーバと管理DB40とはLAN2を介して接続されており，さらに，負荷分散装置30と通信装置51と通信装置52とはネットワーク0を介して接続されている。
【０１９３】
また，SIPサーバ11は192.168.10.11というIPアドレスが割り当てられており，レジストラDB21を備えている。SIPサーバ12は192.168.10.12というIPアドレスが割り当てられており，レジストラDB22を備えている。さらに，SIPサーバ13は192.168.10.13というIPアドレスが割り当てられており，レジストラDB23を備えている。
【０１９４】
また，負荷分散装置30には192.168.10.1というIPアドレスが割り当てられている。なお，本実施例で使用する負荷分散装置30も，あらかじめ定められた期間内に同じ通信装置からメッセージを受信した場合には，当該メッセージを直前にメッセージを転送したSIPサーバに転送する機能を備えている。
【０１９５】
さらに，通信装置51は，192.168.20.11というIPアドレスと，user@hitachi.comというSIP-URIとが割り当てられおり，通信装置52は，192.168.30.11というIPアドレスと，service@hitachi.comというSIP-URIとが割り当てられている。通信装置51および通信装置52のソフトウェア構造は，第二の実施例の通信装置51および通信装置52のソフトウェア構造と同じである。
【０１９６】
さらに，本実施例の管理DB40は，SIPサーバ11，SIPサーバ12，SIPサーバ13が管理している呼情報を記録する呼情報テーブル401と，SIPサーバ11，SIPサーバ12，SIPサーバ13が通信装置51や通信装置52と通信するための通信設定を記録する通信共有情報テーブル402と，から構成されている。ここで，呼情報テーブル401には，ある通信セッションの識別情報であるCall-IDと，ある通信セッションの発信者のSIP-URIと，ある通信セッションの受信者のSIP-URIと，当該通信セッションの状態と，が記録されている。また，通信共有情報テーブル402には，通信装置の識別情報であるSIP-URIと，当該通信装置と通信する場合のアクセスポイント情報（すなわち，IPアドレスとポート番号とトランスポート層プロトコルの種別の組）と，当該通信装置との間での暗号化通信に使用している暗号アルゴリズムの種別と，暗号化通信に使用している鍵の値と，メッセージの順序を識別するためのシーケンス番号と，が記録されている。
【０１９７】
以下，図15に示した通信装置51が，通信装置52とデータ通信を行う場合の通信手順を例にして，第二の実施例について説明する。
【０１９８】
図16および図17は，第1の実施例によるデータ通信を示すシーケンス図である。図3，図4と同一符号で示された第一実施例で説明済みのステップとメッセージについてはできる限り説明を省略する。
【０１９９】
図16は，通信装置51がSIPサーバへのログイン処理を行う場合のシーケンスを示した図である。
【０２００】
本実施例では，通信装置51がSIPサーバ（図16ではSIPサーバ11）と暗号化通信のネゴシエーションを行って暗号化通信を確立する（S6）と，SIPサーバ11は確立した暗号化通信の通信設定を管理DB40に登録する（S401，S402）。
【０２０１】
次に，通信装置51が送信したREGISTERメッセージを受信したSIPサーバ11は，管理DB40から通信装置51との間の通信設定を取得し（S403，S404），当該設定を用いてREGISTERメッセージを復号する。ここで，正しくメッセージを復号できた場合，管理DB40に記録されている，通信装置51との間の通信設定を更新する（S405，S406）。
【０２０２】
次に，SIPサーバ11は，REGISTERメッセージに対するSIP応答メッセージを作成すると，管理DB40から通信装置51との間の通信設定を取得し（S407，S408），当該設定を用いてSIP応答メッセージを暗号化して，通信装置51に送信する（S9，S10）。ここで，メッセージの送信が完了すると，管理DB40に記録されている，通信装置51との間の通信設定を更新する（S409，S410）。
【０２０３】
以上により，通信装置51のログインが完了する。
【０２０４】
上記のように，本実施例ではSIPサーバは，ある通信装置とSIPメッセージやSIP応答メッセージを送受信する毎に管理DB40から当該通信装置との間の通信設定を取得して，暗号化や復号の処理を行うとともに，管理DB40に記録されている上記通信設定を更新する。以下では，簡単のために，管理DB40からの通信設定の取得や更新の処理は説明を省略する。
【０２０５】
図17は，通信装置51が通信装置52と通信セッションを確立する場合のシーケンスを示した図である。
【０２０６】
まず，通信装置51が通信装置52と通信セッションを確立する場合，通信装置51は，負荷分散装置30にINVITEメッセージを送信する（S501）。
【０２０７】
負荷分散装置30はINVITEメッセージを受信すると，3台のSIPサーバの中から当該INVITEメッセージを転送するSIPサーバを選択すると，選択したSIPサーバにINVITEメッセージを転送する（S502）。図17では，転送するSIPサーバとしてSIPサーバ11が選択された場合を示している。
【０２０８】
INVITEメッセージを受信したSIPサーバ11は，管理DB40の呼情報テーブル402を検索して，当該INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報を持つ呼情報が登録されているかどうかを検索する（S503，S504）。
【０２０９】
ここで，当該INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報を持つ呼情報が登録されていた場合には，負荷分散装置30を介して既に処理中であることを意味するSIP応答メッセージを通信装置51に送信する。
【０２１０】
一方，当該INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報を持つ呼情報が登録されていない場合，管理DB40の呼情報テーブル402に呼情報更新要求メッセージを送信して，呼情報テーブル402に上記INVITEメッセージのCall-IDヘッダが示す通信セッションの識別情報と，当該INVITEメッセージの送信元のSIP-URIと，当該INVITEメッセージの送信先のSIP-URIと，当該通信セッションが「確立処理中（受信先からの応答待ち）」状態であることを記録する。（S505，S506）
次に，SIPサーバ11は，負荷分散装置30を介して上記INVITEメッセージの送信先として指定された通信装置52にINVITEメッセージを送信する（S507，S508）。
【０２１１】
INVITEメッセージを受信した通信装置52は，当該INVITEメッセージに対するSIP応答メッセージを作成し，負荷分散装置30に送信する（S509）。
【０２１２】
負荷分散装置30はSIP応答メッセージを受信すると，3台のSIPサーバの中から当該SIP応答メッセージを転送するSIPサーバを選択すると，選択したSIPサーバに当該SIP応答メッセージを転送する（S510）。図17では，転送するSIPサーバとしてSIPサーバ13が選択された場合を示している。
【０２１３】
SIP応答メッセージを受信したSIPサーバ13は，管理DB40の呼情報テーブル402を検索して，当該SIP応答メッセージのCall-IDヘッダが示す通信セッションの識別情報を持つ呼情報が登録されているかどうかを検索する（S511，S512）。
【０２１４】
ここで，当該SIP応答メッセージのCall-IDヘッダが示す通信セッションの識別情報を持つ呼情報が登録されていない場合には，負荷分散装置30を介してエラーが発生したことを意味するSIP応答メッセージを通信装置52に送信する。
【０２１５】
一方，当該SIP応答メッセージのCall-IDヘッダが示す通信セッションの識別情報を持つ呼情報が登録されていた場合，SIP応答メッセージの内容が「通信許可」であれば管理DB40の呼情報テーブル402に呼情報更新要求メッセージを送信して，呼情報テーブル402に上記SIP応答メッセージのCall-IDヘッダが示す通信セッションの呼情報を削除する。一方，SIP応答メッセージの内容が「通信許可」であれば管理DB40の呼情報テーブル402に呼情報更新要求メッセージを送信して，呼情報テーブル402に上記SIP応答メッセージのCall-IDヘッダが示す通信セッションの呼情報の状態を「接続中」状態に更新する。（S513，S514）
次に，SIPサーバ13は，負荷分散装置30を介して上記SIP応答メッセージの送信先として指定された通信装置51に上記SIP応答メッセージを送信する（S515，S516）。
【０２１６】
上記のように，本実施例ではSIPサーバは，ある通信装置とINVITEメッセージやINVITEメッセージに対するSIP応答メッセージを受信する毎に管理DB40から当該通信セッションに関する呼情報を取得してメッセージを処理する。そして，処理した結果に応じて，管理DB40に記録されている上記呼情報を更新する。なお，本実施例でBYEメッセージやBYEメッセージに対するSIP応答メッセージを受信した場合にも管理DB40から当該通信セッションに関する呼情報を取得してメッセージを処理する。そして，処理した結果に応じて，管理DB40に記録されている上記呼情報を更新する。
【０２１７】
本実施例では，SIPサーバからアクセス可能な共有データベースを設け，通信装置と通信するための通信設定を当該共有データベースに記録するようにしている。このため，SIPメッセージやSIP応答メッセージを受信したSIPサーバは共有データベースを参照して通信設定を取得することによって，SIPメッセージやSIP応答メッセージの送信元がログインしたSIPサーバでなくても，当該メッセージを処理できる（例えば，暗号化通信を行っている場合には，正しく復号することができる），という効果がある。
【０２１８】
また，本実施例では，SIPメッセージやSIP応答メッセージを送信する場合にも，SIPサーバは上記共有データベースを参照して通信設定を取得するようにしている。このため，SIPメッセージやSIP応答メッセージの送信先である通信装置がログインしているSIPサーバに当該メッセージを送信することなく，直接，通信装置にメッセージを送信することができる，という効果がある。
【図面の簡単な説明】
【０２１９】
【図１】第一の実施例におけるシステム構成を例示した図。
【図２】各実施例における各装置のハードウェア構成を例示するブロック図。
【図３】図1に示した通信装置51および通信装置52がSIPサーバへのログイン処理を行う場合のシーケンスを例示した図。
【図４】図1に示した通信装置51が通信装置52にサービスの提供を受ける場合のシーケンスを例示した図。
【図５】図1に示したSIPサーバにおけるINVITEメッセージの処理フローを例示した図。
【図６】図1に示したSIPサーバが通信に必要な情報を取得するためのメッセージを例示した図。
【図７】図1に示したSIPサーバにおけるSIPサーバ検索要求メッセージの処理フローを例示した図。
【図８】第二の実施例におけるシステム構成を例示した図。
【図９】図8に示した通信装置51および通信装置52がSIPサーバへのログイン処理を行う場合のシーケンスを例示した図。
【図１０】図8に示した通信装置51が通信装置52にサービスの提供を受ける場合のシーケンスを例示した図。
【図１１】図8に示した通信装置がログインする場合のSIPサーバにおける処理フローを例示した図。
【図１２】図8に示したSIPサーバにおけるINVITEメッセージの処理フローを例示した図。
【図１３】図8に示した通信装置がログアウトをする場合のシーケンスを例示した図。
【図１４】図8に示した通信装置がログアウトをする場合のSIPサーバにおける処理フローを例示した図。
【図１５】第三の実施例におけるシステム構成を例示した図。
【図１６】図15に示した通信装置51がSIPサーバへのログイン処理を行う場合のシーケンスを例示した図。
【図１７】図15に示した通信装置51が通信装置52にサービスの提供を受ける場合のシーケンスを例示した図。
【符号の説明】
【０２２０】
0：ネットワーク，1，2：LAN，11，12，13：SIPサーバ，21，22，23：レジストラDB，30：負荷分散装置，40：管理DB，41，42，43：呼情報DB，45：共有情報管理サーバ，51，52：通信装置，81：SIPサーバ検索要求メッセージ，82：SIPサーバ検索応答メッセージ，83：SIPサーバ登録要求メッセージ，84：SIPサーバ登録応答メッセージ，85：SIPサーバ削除要求メッセージ，86：SIPサーバ削除応答メッセージ，91：CPU，92：メモリ，93：ハードディスク，94：ネットワークインタフェース，95：入出力インタフェース。
【図１】
2008205988.tif 000003
【図２】
2008205988.tif 000004
【図３】
2008205988.tif 000005
【図４】
2008205988.tif 000006
【図５】
2008205988.tif 000007
【図６】
2008205988.tif 000008
【図７】
2008205988.tif 000009
【図８】
2008205988.tif 000010
【図９】
2008205988.tif 000011
【図１０】
2008205988.tif 000012
【図１１】
2008205988.tif 000013
【図１２】
2008205988.tif 000014
【図１３】
2008205988.tif 000015
【図１４】
2008205988.tif 000016
【図１５】
2008205988.tif 000017
【図１６】
2008205988.tif 000018
【図１７】
2008205988.tif 000019