JP5447171B2

JP5447171B2 - セッション制御装置、当該セッション制御装置に適用されるソフトウェア、セッション制御方法、およびネットワークシステム

Info

Publication number: JP5447171B2
Application number: JP2010111627A
Authority: JP
Inventors: 一磨湯本; 聡史清藤; 仁美中村
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2010-05-14
Filing date: 2010-05-14
Publication date: 2014-03-19
Anticipated expiration: 2023-06-30
Also published as: JP2010183643A

Description

本発明は，ユーザや端末の状態情報を管理するプレゼンス情報管理システムに係わり，特に，セッションの制御および管理を行う装置が，ユーザまたは端末に代わり，ユーザまたは端末の状態の変更通知を行う技術に関する。

“プレゼンス”という概念は，ＩＥＴＦ（Internet Engineering Task Force）のｉｍｐｐ（Instant Messaging and Presence Protocol）ワーキンググループを中心として検討が進められ（例えば，ＲＦＣ２７７８参照），ＳＩＰ（Session Initiation Protocol）という通信プロトコルを用いたプレゼンス情報の送受信方法などが提案されている（例えば，ＲＦＣ３２６５参照）。また、このようなプレゼンスを記述する情報を専門に管理するプレゼンスサーバの開発も進められている。

一方，実装では，いわゆるＩＭ（Instant Message）にプレゼンスの概念が取り入れられており，メッセージを送信しようとする相手がオンラインになると、送信相手先にメッセージが通知される仕組みとして利用されている。

また、”プレゼンス”という一般化された概念では無いものの、プレゼンス情報の一部に相当するような情報の通知サービスが、従来のアナログ電話でも利用されている。例えば、通話相手が不在の場合に発呼側に不在メッセージ等を通知するなどのサービスである。

図９には、従来のプレゼンス情報利用システムの１例を示す。図９のプレゼンス情報利用システムにおいては、端末１にプレゼンス情報通知機能２００が実装されている。端末１は、この機能を利用して、パケット中継機能２１０を有するセッション制御サーバ３にプレゼンス情報を含むパケットを送信し，セッション制御サーバ３を経由してプレゼンス情報管理２２０機能を有するプレゼンスサーバ７に送り届けるという形態である。

図１０には、従来のプレゼンス情報利用システムの別な例を示す。この例では、プレゼンスサーバを用いずに、端末１ｃと端末１ｄの間で直接プレゼンス情報の通知および更新を行っているが、図９，図１０、いずれの場合も、端末側にプレゼンス情報の処理機能が必要となることに変わりはない。特に、図１０の形態の場合、端末にはプレゼンス情報通知機能２００の他に、表示を伴うプレゼンス情報受信管理機能２５０を実装する必要がある。

ＲＦＣ２７７８ＲＦＣ３２６５

ＩＭサービス等の従来提供されているプレゼンス情報利用システムでは，クライアント側のプログラムがプレゼンス状態の変更を通知する能力を必要とする。アナログ電話網に関しても事情は同じで、ユーザの不在情報を発呼側に通知するサービスの場合、電話機のユーザは、不在情報を電話機に登録しておかなければならない。すなわち、プレゼンス情報を相手側に通知する機能が電話機に備わっている必要がある。本発明の目的の一つは，プレゼンス情報の通知・更新機能を持たない端末を利用する場合であっても，端末ユーザがプレゼンス情報を用いたサービスを享受できるようにすることである。

上記目的を達成するためには、端末に実装されたクライアントプログラムが、プレゼンス情報の更新・通知を行わなくても，ユーザまたは端末の状態がプレゼンスサーバに反映される必要がある。このため、本発明は，端末間の通信セッションを管理する制御サーバ内に、端末の状態情報をプレゼンスサーバに通知する手段を設ける。制御サーバは、プレゼンスサーバを備える通信ネットワーク上に配置される。

また、本発明の別の観点では、ネットワークの構成要素として、少なくとも２つの通信端末間を接続する通信回線と、本通信回線上のどこかに配置された複数のサーバと、少なくとも１台のプレゼンスサーバを有するアークテクチャのネットワークにおいて、端末以外のいずれかのサーバが、端末の状態情報ないしプレゼンス情報の変化を検出し、変化後の状態情報またはプレゼンス情報をプレゼンスサーバに通知することを特徴とする。

セッション制御サーバの内部に設けたプレゼンス状態更新手段で，通話セッションの確立や切断など状態の変更を契機として，変更された状態をプレゼンスサーバに通知することにより，ユーザまたはクライアントプログラムが意識的にプレゼンス情報の更新を行わなくても，ユーザまたはクライアントプログラムの状態がプレゼンスサーバで管理する情報に反映される。

また，プレゼンスサーバ側に設けるプレゼンス情報制御手段で通知された更新情報の整合性を制御することにより，例えば，定期通知を期待するオンライン通知が話中状態の時に送られてこなくなった場合にも，状態情報の不整合が生じない。

本発明の実施形態に係わるプレゼンス情報利用システムの構成図。セッション制御サーバ内ブロック構成図。話中通知発行手順の一例を示すシーケンス図。話中通知発行手順の別の一例を示すシーケンス図。切断通知発行手順の一例を示すシーケンス図。切断通知発行手順の別の一例を示すシーケンス図。準正常ケースの一例を示すシーケンス図。プレゼンス情報制御手段の処理手順を示すフローチャート。従来のプレゼンス情報利用システムの一例を示す方式説明図。従来のプレゼンス情報利用システムの別の一例を示す方式説明図。本発明のプレゼンス情報利用システムの一例を示す方式説明図。プレゼンス情報更新パケットのメッセージフォーマットの一例を示す図。プレゼンスサーバの機能ブロック図。

以下，プレゼンス情報利用システムの実施形態について，図面を用いて説明する。

図１は，本実施形態に係わるプレゼンス情報利用システムの一構成例を示す図である。プレゼンス情報利用システムは，ユーザおよびユーザが所有する端末１の状態情報であるプレゼンス情報を管理し，状態が更新された際の更新通知を行うプレゼンスサーバ７と，プレゼンス情報の中継と，音声や映像などを送受信するための通信セッションを確立する際のセッション制御情報の中継を行うセッション制御サーバ３と，ユーザが利用する端末１またはアプリケーションより構成される。図１中の「通話路」とは、端末1aと端末1bとを接続する通信回線である。あるいは、インターネット上に形成されたコネクションと考えてもよい。端末A（1a）から、セッション制御サーバ１（3a）、セッション制御サーバ２（3b）、セッション制御サーバ３（3c）を経由して、端末B（1b）へ延びる実線は、セッション制御のための制御信号が通過する制御信号線である。前記の通話路と物理的に同じ通信回線、論理的に同じコネクションにより制御信号用の通信経路が形成されていても別に不都合はない。なお本実施例では、「セッション」とは、通信開始のメッセージで始まり、通信終了のメッセージで終了する端末間の一連の通信動作を意味するものとする。また、「状態情報」とは、文字通り、端末ないし端末ユーザの状態を表す情報を意味するものとする。例えば、ユーザがオンライン、オフライン等、状態を示す情報である。また、「プレゼンス情報」とは、端末ないし端末ユーザの広い意味での属性情報を意味するものとする。例えば、生年月日、住所、端末が加入しているサービス等、広く属性を示す情報である。従って、本実施例においては、「プレゼンス情報」は「状態情報」を包含する概念であると定義される。

図１１には、本実施例のネットワークシステムの概念図を示した。プレゼンス情報通知機能を持たない端末１ｅ（例えば従来のＩＰ電話機など）の状態情報を，セッション制御サーバ３が代行してプレゼンスサーバ７に通知することにより，プレゼンス情報通知機能を持たない端末を利用しているユーザの状態を他のユーザが確認できるようにする。具体的には，セッション制御サーバ３にプレゼンス状態更新部１５を設け，端末のセッションを監視する中で状態の変更が発生した際に，プレゼンス状態更新部１５からプレゼンスサーバ７に通知を行うようにする。

この仕組みを，図２に示すセッション制御サーバ３のブロック構成図を用いて詳しく説明する。従来，音声や映像などを送受信する際には，端末と端末の間で，音声や映像の送受信を行うための通信アドレスや符号化方式などの通知を行った上で，音声データや映像データの送受信を実現している。通常，前者の通信をセッション情報の通信，後者の通信をデータ情報の通信と呼ぶが，本実施例のセッション制御サーバ３では，特に，前者のセッション情報の通信に用いるパケットの送受信を行う。

セッション制御サーバ３は，パケットの受信および解析と，中継の際に必要となるヘッダ情報の整形操作および送信を行う通信制御部１０，各セッションの状態管理を行う状態管理部１１，収容端末から登録通知されるアドレス情報を管理する端末ロケーション管理部１２，状態が更新された際に更新された内容を通知形式に整形し，プレゼンスサーバ３宛に状態更新通知を送るよう指示を出すプレゼンス状態更新部１５より構成される。状態管理部１１および端末ロケーション管理部１２は、それぞれ現在時刻を計測するための第１のタイマー、第２のタイマーを備えている（理由は後述する）。IF16は、ネットワークインターフェースであり、IF16を介してパケットが送受信される。

パケットを受信した通信制御部１０は，パケットの内容を解析して受信メッセージの内容を状態管理部１１に伝える。受信メッセージの内容が収容端末からの登録通知または削除通知の場合は，端末ロケーション管理部１２にも受信メッセージの内容を通知する。各セッションの状態管理を行う状態管理部１１では，通知された内容に基づき該当するセッションの状態を変更する。一方，登録通知を受けた端末ロケーション管理部１２は，通知されたアドレス情報を登録して，設定された期間保持する。また，削除通知を受けた端末ロケーション管理部１２は，設定期間内であっても該当する登録情報を削除する。特定の通信プロトコル、例えばＳＩＰなどを用いたい場合には、通信制御部内にＳＩＰ用のプロトコルスタックを設けて、サーバ３が、ＳＩＰのプロトコルを理解できるようにする。

以上の通信制御部１０と状態管理部１１はＳＩＰ（ＲＦＣ３２６１）のプロキシサーバ機能を実現する際に必要となる機能ブロック，端末ロケーション管理部１２はロケーションサーバ機能を実現する際に必要となる機能ブロックである。本実施例では，ここにプレゼンス状態更新部１５という機能ブロックを追加することにより，本願の目的機能を実現する。

通信制御部１０はパケットを受信した際に状態管理部１１に通知を行うが，通知した結果，状態がある特定の状態（例えば，話中状態，切断状態など）に遷移した場合に，プレゼンス状態更新部１５にも通知を行う。プレゼンス状態更新部１５に通知を発行するのは
，状態管理部１１でも，状態管理部１１から遷移した状態の報告を受ける通信制御部１０でも構わない。この時にプレゼンス状態更新通知として通知する内容は，更新された状態情報と，該当するセッションを確立しているユーザまたは端末を特定するアドレス情報を通知する。

プレゼンス状態更新通知を受けたプレゼンス状態更新部１５は，該当するセッションを確立しているユーザまたは端末が自サーバで収容している端末か否かを調べるために，端末ロケーション管理部１２に問い合せを行う。この問い合せの際に用いる検索項目には，プレゼンス状態更新通知で受信したユーザまたは端末を特定するアドレス情報を利用する。

端末ロケーション管理部１２に問い合せた結果，該当セッションが自サーバで収容しているユーザまたは端末によるものであった場合，プレゼンス状態更新部１５は，該収容ユーザまたは端末の状態がプレゼンス状態更新通知により通知された状態に更新された旨，プレゼンスサーバ７に通知するよう通信制御部１０に指示を出す。ここで通知する内容や宛先の指定は，プレゼンス状態更新部１５にて行う。

プレゼンス状態更新部１５からの指示を受けた通信制御部１０は，プレゼンス状態更新部１５から指示された内容を指定の宛先に対して送信する。すなわち，本実施例のセッション制御サーバ３は，リクエストメッセージやレスポンスメッセージの中継機能や，リクエストメッセージに対するレスポンスメッセージの発行機能に加えて，新規リクエストメッセージの発行機能も有する。

なお、図示されていないが、図２に示した制御サーバは、外部記憶装置を備えており、上述した制御を実行する制御用プログラムが格納されている。サーバが動作する際には、筐体内に設けられたメモリ上に制御用プログラムが展開され、CPUで制御用プログラムが実行される。また、本実施例では、図２に示した各機能ブロックが、全てソフトウェア処理により実現されていると仮定しているが、機能ブロックそれぞれに対応するプロセッサや信号処理回路などを用いて、ハードウェア的に図２の構成を実現しても良い。

図３は，セッション制御プロトコルとしてＳＩＰを用いた場合の，話中通知発行手順の一例を示したシーケンス図である。音声や映像の通信セッションを確立する場合，ＳＩＰではＩＮＶＩＴＥメッセージを利用する。ＩＮＶＩＴＥセッションは，図中のＦ２０からＦ３４までのシーケンスに示す流れで端末間の調整を行い，ＩＮＶＩＴＥリクエストや２００レスポンスで通知しあった内容に基づいてＲＴＰ（Real-time Transport Protocol, RFC1889）で音声データや映像データの送受信を行う。

音声や映像などを用いたセッションが確立して話中状態となった際に，セッション制御サーバ３がプレゼンスサーバ７に対し，セッションを確立したユーザ端末が話中状態となった旨を通知するケースを例にとり説明する。

図３は，話中状態に遷移する契機を２００レスポンスの受信とした場合のシーケンス例である。この例では，Ｆ２９やＦ３０の２００レスポンスの受信を契機として，プレゼンス状態更新部１５にプレゼンス状態更新通知を発行する方式を示している。

図４は，同じくＳＩＰを用いた場合の話中通知発行手順の別の一例を示したシーケンス図である。Ｆ４０からＦ５４までの手順はＦ２０からＦ３４までの手順と同様である。この例では，Ｆ５２やＦ５３のＡＣＫメッセージの受信を契機として，プレゼンス状態更新部１５にプレゼンス状態更新通知を発行する方式を示している。

ＩＮＶＩＴＥリクエストと２００レスポンスでデータ通信のために必要な情報を通知しあう場合は，図３に示す方式でも図４に示す方式でも構わないが，２００レスポンスとＡＣＫメッセージでデータ通信に必要な情報を通知しあう場合は，図４に示す方式を用いる必要がある。図４に示す方式では，単一の方式で，ＩＮＶＩＴＥリクエストと２００レスポンスでデータ通信のために必要な情報を通知しあう場合にも，２００レスポンスとＡＣＫメッセージでデータ通信に必要な情報を通知しある場合にも適用できるというメリットがある。但し，ＩＮＶＩＴＥリクエストと２００レスポンスでデータ通信のために必要な情報を通知しある場合，端末側の仕様によってはＡＣＫメッセージの送受信を待たずにデータ通信を開始するケースも考えられるが，ＡＣＫメッセージがパケットロスなどで消失した場合にも，前記仕様の端末のようにＡＣＫを待たずにデータ通信を開始する端末の状態を正しくプレゼンスサーバに反映させるためには，ＩＮＶＩＴＥリクエストと２００レスポンスでデータ通信のために必要な情報を通知しあう場合に限り，図３に示す方式を用いる必要がある。

図５と図６は，セッション制御プロトコルとしてＳＩＰを用いた場合の，切断通知発行手順の例を示したシーケンス図である。ＩＮＶＩＴＥセッションを終了してデータ通信を終了させる場合は，ＢＹＥメッセージを用いるが，ＢＹＥリクエストの受信を切断状態に遷移する契機として，プレゼンス状態更新部１５にプレゼンス状態更新通知を発行する方式を図５に，ＢＹＥリクエストに対する２００レスポンスを切断状態に遷移する契機として，プレゼンス状態更新部１５にプレゼンス状態更新通知を発行する方式を図６に示す。

図５の方式では，Ｆ６０のＢＹＥリクエストの受信を契機として，端末１ａの切断通知が端末１ａを収容しているセッション制御サーバ３ａからプレゼンスサーバ７に送信され，Ｆ６１のＢＹＥリクエスト受信を契機として，端末１ｂの切断通知が端末１ｂを収容しているセッション制御サーバ３ｃからプレゼンスサーバ７に送信される。

一方，図６の方式では，Ｆ７３の２００レスポンスの受信を契機として，端末１ｂの切断通知が端末１ｂを収容しているセッション制御サーバ３ｃからプレゼンスサーバ７に送信され，Ｆ７４の２００レスポンス受信を契機として，端末１ａの切断通知が端末１ａを収容しているセッション制御サーバ３ａからプレゼンスサーバ７に送信される。図５に示す方式は，ＢＹＥメッセージに対する２００レスポンスの受信を待たずに，ＢＹＥメッセージの送受信を契機としてデータ通信を終える仕様の端末を利用する場合に，２００レスポンスがパケットロスなどで消失したとしても，端末の状態を正確にプレゼンスサーバに反映できるというメリットがある。一方，図６に示す方式は，セッション通信が完了する時点を契機とするため，より精度の高いタイミングで状態変更をプレゼンスサーバに反映できるというメリットがある。

図５および図６に示した方式は，メッセージの受信を切断状態に遷移する契機とみなす方式であったが，他の方式としては，リクエストメッセージで指定される有効期限に基づき，有効期限が経過した時を状態遷移の契機とみなす方式がある。具体的な例としては，ＩＮＶＩＴＥリクエストで指定されるセッションタイマーの有効期限が経過した時を，切断状態への遷移契機とみなしたり，ＳＵＢＳＣＲＩＢＥリクエストで指定される有効期限が経過した時を，プレゼンスサービス利用終了への遷移契機とみなす。ここで上記のような有効期限の監視は，例えば，状態管理部１１や端末ロケーション管理部１２などで行う。すなわち、状態管理部１１や端末ロケーション管理部１２が、現在時刻をカウントするタイマーと、それぞれのメッセージに記載された有効期限に関する情報を読み出す手段とを備え、有効期限が過ぎていないかどうかを監視する。

図７は，準正常ケースの一例を示すシーケンス図である。ここでは，端末の状態通知としてオンライン通知，オフライン通知を行う場合の方式についても併せて説明する。本方式では，Ｆ８０やＦ８１のようなＲＥＧＩＳＴＥＲ登録を契機として，プレゼンス状態更新部１５にプレゼンス状態更新通知を発行し，プレゼンスサーバ７にオンライン通知を行う（Ｆ８６，Ｆ８７）。

ＲＥＧＩＳＴＥＲ登録は有効期限が設定されて扱われるため，この特性を用いて端末の生存確認用途で利用されることもある。この場合は，Ｆ８０やＦ８１で登録した情報の有効期限が切れる前に，Ｆ８２やＦ８３のようにＲＥＧＩＳＴＥＲ登録を再発行することにより有効期限の更新を行うが，この時に再びプレゼンスサーバ７にＦ８８やＦ８９のような通知を発行するか否かは，プレゼンスサーバ７で管理する情報内容にも依存する。プレゼンスサーバ７でも有効期限を管理する場合は，Ｆ８８やＦ８９のような通知は必須であるが，逆に，プレゼンスサーバ７ではオンライン状態かオフライン状態かという状態のみを管理して有効期限は管理しない場合，Ｆ８８やＦ８９のような通知は省略しても構わない。後者の場合は，例えば，新規登録時にはプレゼンスサーバ７に通知を行い，登録済で有効期限の更新だけを行う際にはプレゼンスサーバ７への通知は行わないという判定をセッション制御サーバ３側で行う。

一方，オフライン通知は，端末１側からＲＥＧＩＳＴＥＲメッセージで明示的に登録削除を要求された場合と，登録済みの情報の有効期限が切れた場合に行う。図２ではＩＮＶＩＴＥセッションを例にとり，プレゼンス状態更新部１５に通知を発行するのは，状態管理部１１または通信制御部１０として説明を行ったが，オンライン通知やオフライン通知の発行要求をプレゼンス状態更新部１５に指示するのは，端末ロケーション管理部１２でも構わない。以上で説明した図３〜図７に示す通信シーケンスにおいて、制御サーバ側が行なう動作は全て制御プログラム化されて、サーバに接続された外部記憶装置に格納されている。プログラムのアルゴリズムは、図３〜図７のシーケンスに応じてそれぞれ異なるが、以下のステップは共通に含まれている。
（１）通信セッションを監視して状態情報の変化を検出するステップ、
（２）変化の検出を契機として、状態情報の更新要求メッセージを生成するステップ、
（３）生成した更新要求メッセージをネットワークインタフェースに送信するステップ。

例えば、図５のシーケンスのSIP Server１（3a）においては、端末Ａ（a）より、F60 BYEのメッセージを受信したステップが、端末Ａの状態情報の変化を検出したステップに相当し、プレゼンスサーバ7にF67のメッセージを送信するステップが、状態情報の更新要求を生成してネットワークインタフェースに送信するステップに相当する。このステップは、実際には、プレゼンスサーバ7への送信動作だが、SIPサーバの内部動作だけを見れば、生成したメッセージをインタフェースに送信する動作に等しい。SIP Server３（3c）の動作も同様である。また、図３，図４，図６、図７に示したシーケンスにおいても、各SIPサーバーの動作ステップと上記（１）〜（３）のステップとを対応づけることができる。

上記のように，セッション制御サーバ３からプレゼンスサーバ７へのプレゼンス状態更新通知において，話中／切断通知とオンライン／オフライン通知とを独立に処理する場合
，下記のような状況ではプレゼンスサーバ７側で管理する状態情報に不整合が生じる恐れがある。

例えば，端末をホットスポットのような無線環境で利用し，端末の生存確認のために端末からは定期的にＲＥＧＩＳＴＥＲ登録の更新を行いながら音声通信を行っている際に，端末が無線圏外に暫く出てしまった場合。圏外に出ている間にＲＥＧＩＳＴＥＲ登録した内容の有効期限が切れると，有効期限内に更新が行われなかった（更新のためのＲＥＧＩＳＴＥＲメッセージが届かなかった，Ｆ８５）ということで，セッション制御サーバ３はＦ９１に示すようにプレゼンスサーバ７にオフライン通知を送信する。一方，通話も圏外に出ている間は通じなくなるものの，音が通じなくなったことで諦めた他方のユーザから明示的にＦ７０のような切断命令が発行されない限り，話中状態は継続される。（通話セッションも端末の生存確認と同様に定期的な通知を要求し，セッションの継続通知が無い場合は自動的にセッションを切断するという用法もあるが，この場合でもタイムアウトするまでは話中状態が継続される。）また，再びタイムアウト時間内に圏内に戻った場合は，通話も復旧して実質的に話中状態が継続されることも有り得る。このような場合，プレゼンスサーバ７側で管理する状態が「オフライン」だが「話中」といったように，状態に不整合が生じる恐れがある。

上記のような状態の不整合を解消するために，プレゼンスサーバ７にはプレゼンス状態更新通知に基づき状態遷移を制御するプレゼンス情報制御手段を設ける。

次に、図８を用いて，プレゼンス情報制御手段について説明する。プレゼンス情報更新通知のパケットを受信した（ステップ１００）プレゼンスサーバ７は通知内容を確認して，通知内容がオンライン通知であった場合には（ステップ１０１），端末状態を管理するプレゼンス情報の値を「オンライン」に変更し（ステップ１０２），通知内容がオフライン通知であった場合には（ステップ１０３），通話状態を管理するプレゼンス情報を参照し，状態が「話中」であった場合には（ステップ１０５）端末状態を「オフライン待ち」というオンライン状態とオフライン状態の中間状態に遷移させる。一方，ステップ１０５における参照結果が話中ではなくアイドル状態であった場合は，端末状態を「オフライン」に変更する。

プレゼンス情報更新通知による通知内容が話中通知であった場合には（ステップ１１１），通話状態を「話中」に変更する（ステップ１１２）。図７に示した例のように，通話セッションを開始する前，例えば起動と同時にオンライン通知が行われる場合（Ｆ８８，Ｆ８９）には必要の無い処理であるが，通話セッションを開始する前にオンライン通知が行われない場合には，ステップ１１２の処理の中で同時に端末状態を「オンライン」に変更する。

プレゼンス情報更新通知による通知内容が切断通知であった場合には（ステップ１１４），通話状態を「切断」に変更した上で，更に，端末状態を管理するプレゼンス情報を参照し，状態が「オフライン待ち」であった場合には（ステップ１１５）端末状態を「オフライン」に変更する（ステップ１１６）。このような状態遷移制御をプレゼンスサーバ７で行うことにより，プレゼンス状態の不整合が起こらないようにする。このため、プレゼンスサーバ7は、プレゼンス情報更新パケットに含まれているプレゼンス情報と、当該プレゼンス情報に関連する情報で、既にプレゼンスサーバに格納されているプレゼンス情報とに矛盾が生じていないか検出する手段と、新たに受信したプレゼンス情報に対する矛盾が解消されるように、既に格納されたプレゼンス情報を変更する手段とを有する。これにより、例えば，何らかの障害で，生存確認のための通知が到達しなくなった場合などに，ユーザまたは端末に代わりセッション制御サーバが通知を行う情報（オフライン通知）が，既にプレゼンスサーバに格納されているプレゼンス情報（話中）と齟齬が生じないようにすることを目的としている。

図１３には、登録されたプレゼンス情報間の不整合を解消する機能を有するプレゼンスサーバの機能ブロック図を示した。IF400は、ネットワークインターフェースであり、受信パケットに対して、TCP/IPレイヤまでのヘッダ処理を行なう。420は、通信制御部であり、通信プロトコルのプロトコルスタックを内包している。例えば，SIPパケットを処理するためには、通信制御部420にSIPのプロトコルスタックを含ませる。情報送受信部422は、受信パケットのTCPまたはUDPレイヤとの間でSIPパケットの送受信を行うブロックである。IF420で受信された受信パケットは、受信情報抽出部424に転送され、情報が取り出される。

IF400で、セッション管理サーバからの状態情報の更新要求メッセージを受信すると、受信したメッセージは、受信情報抽出部424で所定の情報が引き出された後、プレゼンス情報管理部430に転送される。「所定の情報」とは、例えば、端末や端末ユーザのプレゼンス情報などである。また、「プレゼンス情報管理部」とは、プレゼンス情報の管理を行うブロック群の総称であり、プレゼンス情報の管理に関わる種々の処理を行なう複数の機能ブロックからなる。受信パケットから抽出されたプレゼンス情報は、最終的に設定内容記録部438に記録される。設定内容記録部438は、例えば、サーバの筐体内部に設けられた記憶手段（例えば、HDD装置やメモリ等）や，サーバの筐体外部に設けられたDB等により構成される。

受信情報抽出部424で抽出されたプレゼンス情報は、設定内容整合部436に送信される。設定内容整合部436は、設定内容記録部438を参照して、受信したプレゼンス情報と、記憶されたプレゼンス情報との整合性を比較する。矛盾が無ければ、受信したプレゼンス情報を設定内容入力部432に入力する。また、矛盾があった場合には、記録されたプレゼンス情報が書き換えられるべき情報を生成し、受信したプレゼンス情報とともに設定内容入力部432に入力する。設定内容入力部432は、設定内容記録部に対して、プレゼンス情報の登録動作を行うブロックである。設定内容出力部434は、設定内容記録部438に記録されたプレゼンス情報を取り出すブロックである。送信情報構築部426は、送信すべき情報をSIPパケットの構造に整形する機能ブロックであり、実際に送信パケットを生成するブロックと考えてよい。生成された送信パケットは情報送受信部422へ転送され、IF400を介して外部に送信される。

図１２は，本実施例のプレゼンス情報更新メッセージのメッセージフォーマットの一例を示す図である。本実施例では、プレゼンス情報更新通知にＳＩＰのＲＥＧＩＳＴＥＲメッセージを利用している。ＳＩＰのメッセージは，開始行３００，ヘッダ３１０，空行３２０，ボディ３３０より構成される。一般的なＲＥＧＩＳＴＥＲメッセージでは、図１２に示したメッセージフォーマットでは、ボディ部をＸＭＬ（eXtensible Markup Language）で記述している。ボディの内容が存在しないが，本実施例では、ボディ部に通知する情報を乗せて送る。原理的には、ヘッダ部に状態情報を含めて通知を行なうことも可能であるが、ＳＩＰの仕様により、ヘッダ部に含めることが可能な情報には制限がある。例えば、セッション制御に直接関連しない状態情報の場合、ヘッダ部に含めることのできる状態情報は、ユーザのハンドルネーム、端末の種別（phone/pc/PDA等の情報）、ユーザが使用しているブラウザソフトの種類等々の関連情報程度である。

一方、ボディ部には多様な情報を含めることが可能であり、従って、ボディ部に状態情報を含めることにより、ヘッダ情報に状態情報を含める方式に比べて、より多様な状態情報の通知が可能となる。書式に関しても，ヘッダ部の中で種別指定を行うことにより，色々な形式を利用することが可能であり，図１２に示したＸＭＬ以外の形式の書式で記述することも可能である。

また、ボディ部に含める情報の内容に関しても，状態情報だけでなく，種々のプレゼンス情報を含めることが可能である。例えば、端末のアドレスや種別などセッションを確立している端末に関する情報や，利用している符号化方式の情報などセッションの詳細に関わる情報を共に含めて通知することができる。セッション種別なども，接続先のアドレスを検証することにより，例えば，ストリーミングサービスを利用しているのか，ボイスメールを利用しているのかを判定して通知を行うことが可能である。

１…端末，３…セッション制御サーバ，７…プレゼンスサーバ，１０…通信制御部，１１…状態管理部，１２…端末ロケーション管理部，１５…プレゼンス状態更新部。

Claims

複数の端末間でのネットワークを介する通信を管理する管理方法であって、
少なくとも二つの上記端末間において送受信される、セッションに係る要求または応答メッセージに基づき、前記二つの端末間における通信状態の変化を検出するステップと、
変化した上記通信状態が示す上記端末の状態を、上記端末の状態情報に反映するステップと、を有し、
上記状態情報には、上記端末が利用しているサービスの種別が含まれており、
上記通信状態の変化を検出するステップは、上記端末の接続先のアドレスに基づき、上記端末が利用しているサービスの種別を判定するステップを有する
ことを特徴とする管理方法。
請求項１記載の管理方法であって、
上記状態情報を更新するステップは、さらに、上記判定されたサービスの種別を上記状態情報に更新するステップを有する
ことを特徴とする管理方法。
請求項１または２に記載の管理方法であって、
上記通信状態の変化を検出するステップは、上記端末間で送受信される前記セッションに係る要求または応答メッセージに基づいてセッションの状態の変化を検出するステップを有する
ことを特徴とする管理方法。
請求項１から３のいずれか一に記載の管理方法であって、
さらに、上記状態情報には、上記端末が利用しているセッションの種別が含まれており、
上記通信状態の変化を検出するステップは、上記端末の接続先のアドレスに基づき、上記端末が利用しているセッションの種別を判定するステップを有する
ことを特徴とする管理方法。
複数の端末間でのネットワークを介する通信を管理する管理方法であって、
少なくとも二つの上記端末間において送受信される、セッションに係る要求または応答メッセージに基づき、前記二つの端末間における通信状態の変化を検出するステップと、
変化した上記通信状態が示す上記端末の状態を、上記端末の状態情報に反映するステップと、を有し、
上記状態情報には、上記端末が利用しているセッションの種別が含まれており、
上記通信状態の変化を検出するステップは、上記端末の接続先のアドレスに基づき、上記端末が利用しているセッションの種別を判定するステップを有する
ことを特徴とする管理方法。
請求項１から５のいずれか一に記載の管理方法であって、
前記セッションに係る要求または応答メッセージは、SIP(Session Initiation Protocol)メッセージである
ことを特徴とする管理方法。