JP4600120B2

JP4600120B2 - 通信制御方法

Info

Publication number: JP4600120B2
Application number: JP2005097024A
Authority: JP
Inventors: 稔和小林
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2005-03-30
Filing date: 2005-03-30
Publication date: 2010-12-15
Anticipated expiration: 2025-03-30
Also published as: JP2006279653A

Description

本発明は、通信制御方法に関するものである。本発明の通信制御方法は、IP（Internet Protocol）コミュニケーションネットワークにおけるプレゼンスサービス実現方法に関するものである。

自分の状態、たとえば電話中や離席中等をリアルタイムに相手に伝えるコミュニケーションサービスとして「プレゼンスサービス」というサービスが存在する。ブロードバンドネットワークの普及にともない、IP（Internet Protocol）ネットワークのコミュニケーションツールとしてソフトフォン等に実装されるようになってきた。このサービスは、サーバ、すなわちプレゼンスサーバを用いたネットワークサービスとして定着してきている。

IPベースのプレゼンスサービスは、プロトコルにSIP（Session Initiation Protocol）を適用し、IETF（Internet Engineering Task force）-RFC（Request For Comments）3265に従って実現されているのが一般的である。

A. B. Roach、"RFC3265-Session Initiation Protocol (SIP) Specific Event Notification"、[online]、平成14年６月、Network working Group、[平成17年３月７日検索]、インターネット＜http://ftp.jaist.ac.jp/pub/Internet/RFC.pdf/rfc3265.txt.pdf＞

しかしながら、IETF-RFC3265では、実装のガイドラインを規定するだけである。実際にネットワークにおいて実現する上での、たとえばトラヒック条件、信号紛失および信号逆転等といった各種の懸念事項にまでは言及していない。また、上述した懸念事項は考慮もされてない。とくに、コネクションレス型の通信であるUDP（User Datagram Protocol）ベースで通信する場合、信号紛失/信号逆転など懸念事項は、IPネットワーク上にて十分発生する可能性がある。この懸念事項を考慮しないと、提供するサービスに影響を与えてしまう。影響としては、たとえばエラーを発生させたことをクライアントに通知して、ユーザであるクライアント端末装置の再起動が一般的に行なわれる。

本発明はこのような従来技術の欠点を解消し、プレゼンスサービスで発生するプレゼンス不整合によるサービス不可状態を軽減させることができる通信制御方法を提供することを目的とする。

本発明は上述の課題を解決するために、ネットワークに接続する管理装置により複数の端末装置間で通信されるプレゼンス情報を仲介しサービスとして提供する管理装置の通信制御方法において、この方法は、あらかじめ受信する情報とこの情報に応じた動作条件とを対応させた第１の管理テーブルを管理装置に用意し、管理装置にて端末装置の一つから供給される情報が異常を示すか否かを判断する第１の工程と、異常を示す情報の受信と判断した際に第１の管理テーブルを参照する第２の工程と、第１の管理テーブルから受信した情報に対応する動作条件で動作させる第３の工程とを含むことを特徴とする。

本発明の通信制御方法は、管理装置にて端末装置の一つから供給される情報が異常を示すか否かを判断し、異常を示す情報の受信と判断した際に、プレゼンス状態通知における応答動作を管理する第１の管理テーブルを参照し、第１の管理テーブルから受信した情報に対応する動作条件に動作を決定し、以後この決定に従って動作させることにより異常と判断した情報を正常動作にマッピングして誤動作にともなうサービスの停止を回避する。

次に添付図面を参照して本発明による通信制御方法の一実施例を詳細に説明する。

本実施例は、本発明の通信制御方法をプレゼンスサービスシステム10に適用した場合である。本発明と直接関係のない部分について図示および説明を省略する。以下の説明で、信号はその現れる接続線の参照番号で指示する。

プレゼンスサービスシステム10は、図２に示すように、プレゼンスサーバ12、ユーザ端末装置14および16を含み、IPネットワーク18にそれぞれが接続される。プレゼンスサーバ12は、SIPサーバであり、物理的なエンティティである。プレゼンスサーバ12は、購読リクエストに対してプレゼンスエージェント（PA）またはプロキシサーバとして動作する。プレゼンスサーバ12がPAとして動作する場合プレゼンスサーバ12は、何等かのプロトコル的な方法によりプレゼンティティのプレゼンス情報を把握する。プレゼンスサーバ12がプロキシとして動作する場合プレゼンスサーバ12は、PAとして働く他のエンティティに購読リクエストを転送する。プレゼンスサーバ12は、信号処理部20、ユーザ情報管理部22およびプレゼンス情報管理部24を含む。

信号処理部20は、ユーザ情報管理部22およびプレゼンス情報管理部24から読み出した情報を参照し、信号を生成しユーザ端末装置14および16に生成した信号を出力する機能を有する。

ユーザ情報管理部22は、契約加入者に関する情報および位置登録情報を管理する機能を有する。プレゼンス情報管理部22は、各契約ユーザのプレゼンス情報を管理する機能を有する。

ユーザ端末装置14および16は、ともにクライアント端末装置であり、IPネットワーク18に接続される。本実施例においてユーザ端末装置14はウォッチャ（Watcher）として機能させ、ユーザ端末装置16はプレゼンティティ（Presentity）として機能させる。ここで、ウォッチャとはあるプレゼンティティについてのプレゼンス情報を要求するものである。また、プレゼンティティとは、プレゼンス情報をプレゼンスサービスに提供するものである。

次にプレゼンスサービスシステム10の動作について説明する。図３に示すように、ユーザ端末装置14（Watcher）がユーザ端末装置16に対するウォッチャ登録の要求をプレゼンスサーバ12に出力する。プレゼンスサーバ12は、この要求を受信しユーザ情報管理部22にて位置情報等を確認後、許可が決定されると、200 OKレスポンスをユーザ端末装置14に送る。プレゼンスサーバ12は、ユーザ端末装置16に対するウォッチャ登録をSUBSCRIBEにより通知する。通知された信号を受信したユーザ端末装置16は、要求を受信した旨を“200”OKレスポンスでプレゼンスサーバ12に返す。この応答後、ユーザ端末装置16はプレゼンスサーバ12に自分の状態を通知する（Notify）。この通知メッセージには、ユーザ端末装置16の状態および購読の状態が載せられる。プレゼンスサーバ12は、受信した状態をユーザ端末14に通知し（Notify）、以降状態が変更するたびに状態を通知する。

ところで、ユーザ端末装置14がプレゼンスサーバ12からユーザ端末装置16の通知を同一ダイアログ、対話上で連続し受信すると、プレゼンスサーバ12は、たとえば時刻T10にてユーザ端末装置14に送出する信号を逆転させてしまうことが生じる。これにより、ユーザ端末装置14はCseq（Command Sequence）値が前回に受信したときより小さい通知を受信してしまう。これに対して、信号逆転等が生じない場合、Cseq値は順次インクリメントされて到着する。このような事象に遭遇すると、ユーザ端末装置14はプレゼンスサーバ12にエラー応答を返信する。エラーを受信したプレゼンスサーバ12はダイアログを終了する。

しかしながら、ユーザ端末装置14側でのダイアログは保持したままの状態にある。このエラー応答動作およびプレゼンスサーバ12側でのダイアログ終了動作は、現状のRFC（Request For Command）に従った動作ではある。ところが、ユーザ端末装置14側ではダイアログが残っているにもかかわらず、プレゼンスサーバ12側ではすでにダイアログが終了することになる。これは、状態がアンマッチになってしまう。プレゼンスサーバ12は、応答コード“481”をユーザ端末装置14に出力する。応答コード“481”は、呼またはトランザクションが存在しないことを示し、アンマッチの要求を受け取ったことを報知する。プレゼンスサービスシステム10は、この後の状態更新等が実施できなくなる。

この改善策として送信した信号の応答を待って確実に信号をやりとりしてもよい。しかしながら、プレゼンスサーバ12に与える負荷やリアルタイム性等を考慮すると、この改善策は運用上あまり有効ではない。

そこで、プレゼンスサービスシステム10は、上述した現状の動作を基に図４に示すように、改善する。ユーザ端末装置14はプレゼンスサーバ12にSUBSCRIBEを供給しウォッチャすることを通知する。プレゼンスサーバ12は、ユーザ端末装置16にSUBSCRIBEを供給する。SUBSCRIBEは、ユーザ端末装置14がウォッチャすることを通知する。

ユーザ端末装置16は、プレゼンスサーバ12に状態通知をNOTIFYにより通知する。プレゼンスサーバ12は、ユーザ端末装置16から２つの状態変更通知AおよびBを連続して受信する。プレゼンスサ一バ12は、ユーザ端末装置16から２つの状態変更通知AおよびBをユーザ端末装置14に通知する。２つの状態変更通知AおよびBの信号は、ユーザ端末装置14に到達する。

ところで、プレゼンスサ一バ12は送信した状態通知Aを時刻T10にて送信し時系列に応じて順次送信するが、たとえば信号すれ違い等のような何らかの要因によりユーザ端末装置14が状態通知Bの信号を時刻T12にて先に受信してしまうことがある。

このときユーザ端末装置14は状態通知Bに対する処理を正常に処理する。ユーザ端末装置14は正常応答コード“200”をプレゼントサーバ12に出力する。時刻T14にてユーザ端末装置14は受信した状態通知Aの信号分析をする。この分析において、信号上のシーケンス番号（Cseq値）が先に受信したときの値より小さい値の信号を受信していることが確認される。このため、ユーザ端末装置14はエラー応答をプレゼンスサーバ12に対して送る。

プレゼンスサーバ12は、受信したエラー応答内容を分析する。分析は、該当応答コードとプレゼンス状態通知応答動作管理テーブルとを比較し、動作条件に従う処理を決定する。本実施例では、該当ケース条件を正常応答動作扱いとするように決定することから正常な振る舞いとする。

したがって、プレゼンスサーバ12は、正常動作の振る舞いになることから、以降の時刻T16におけるユーザ端末装置14から供給されるSUBSCRIBEの更新動作に対しても問題なく動作し正常コード200を出力する。

さらに、プレゼンスサーバ12におけるエラー処理について図１を参照しながら簡単に説明する。ここで、プレゼンスサーバ12がどのエラーコードを正常動作にマッピングするかの設定はサービス提供事業者のクライアント条件によって左右される。この設定および判断についての手順を図１に示す。プレゼンスサーバ12におけるエラー処理では、供給された応答受信が異常か否かを判断する（ステップS10）。応答受信が異常と判断した場合（YES）、応答動作管理テーブルの参照に進む（ステップS12へ）。また、応答受信が正常と判断した場合（NO）、ダイアログの継続に進む（ステップS14へ）。ステップS14では、ダイアログを継続させ、エラー処理を終了する。

次に応答動作管理テーブル26を参照する（ステップS12）。この参照処理は、プレゼンス情報管理部22に格納するプレゼンス状態通知における応答動作管理テーブル26にアクセスして参照する。応答動作管理テーブル26を具体的に図５に示す。プレゼンスサーバ12は、応答コードに対応する動作条件で動作するように決定する。応答動作管理テーブル26は、受信した応答コードと動作条件とが対応して格納されたテーブルである。本実施例では、応答コード“400”および“480”に対してRFCに準拠した動作条件を設定する。また、応答コード“500”に対しては応答コード“200”応答と同じ動作条件を設定する。これらの応答コードと動作条件をTYPE1とする。

この参照の後、プレゼンスサ一バ12は該当する動作条件で動作する（ステップS16）。このようにプレゼンスサーバ12は、たとえば応答コード“400”が供給されると、応答コードに対応するRFCに準拠した動作を行なわせるように決定する。

したがって、プレゼンスサービスシステム10において、IPネットワーク18で提供されるプレゼンスサービスを信号遅延などの要因にて発生する状態不整合に起因したWatcher更新不可および状態通知不可当のサービス停止を、プレゼンスサーバ12側にてエラー時の動作条件を管理し実際のエラー時にはテーブルの条件で判断することによりサービスの停止を容易に防止することができる。

また、図１のフローチャートにおける異常応答（ステップS10）とテーブルの参照判断（ステップS12）との間にて契約加入者における管理テーブル28を参照するようにしてもよい（ステップS18）。管理テーブル28を図６に示す。この動作条件は、加入者毎にこのような事象でのクライアント動作条件が異なることから、あらかじめクライアント種別を加入者情報として管理する。この管理は、ユーザ情報管理部24のユーザ情報も参照することが望ましい。プレゼンスサーバ12は、ユーザ情報、契約ID（IDentification）およびクライアント種別の対応を参照することにより確実に誤動作を回避させる。この中で、クライアント種別は、プレゼンス状態通知における応答動作管理テーブルの種類、すなわちTYPE1、TYPE2およびTYPExによって表される。具体例として、図７にプレゼンス状態通知における応答動作管理テーブルのTYPE2を示す。この場合、応答コード“400”および“500”に対してRFCに準拠した動作条件を設定する。また、応答コード“480”に対しては応答コード“200”応答と同じ動作条件を設定する。

このようにユーザ情報管理部24でクライアントの契約IDを収集し、プレゼンス情報管理部22のクライアント種別毎に用意された管理テーブル28を参照し、利用する応答動作管理テーブルを決定する。この後、前述したようにこの決定に対応する応答動作管理テーブルを参照し（ステップS12）、動作条件に応じた動作をさせる（ステップS16）。これにより、複数のクライアントに対して動作を柔軟に対応させた上で、プレゼンスサービスを信号遅延などの要因にて発生する状態不整合に起因するサービス停止を防止できる。一般的に、クライアントは複数のベンダにて開発されることが多く、エラーにおける応答コードの条件等も異なることが多いことから、このような参照によって対応させることでサービスを非常に柔軟にすることができる。

なお、動作の振る舞い条件は管理テーブル上で管埋するイメージで記載したが、クライアントからの応答条件が一意に決定できている場合、とくに、データとして管埋しなくてもよい。本実施例は、信号遅延だけに限定されるものでなく、クライアントの内部処理遅延等のような類似した事象のケースにおいても適用できることは言うまでもない。

本発明の通信制御方法を適用した実施例のプレゼンスサーバにおけるエラー処理の手順を説明するフローチャートである。図１のエラー処理の動作を実現するプレゼンスサービスシステムの概略的な構成を示す図である。図２の構成における従来の動作を説明するシーケンシャルチャートである。図２の構成において本発明の通信制御方法を適用した際のシーケンシャルチャートである。図１の参照処理において参照する応答動作管理テーブルの一例を示す図である。図１の参照処理において参照する契約加入における管理テーブルの一例を示す図である。図１の参照処理において参照する応答動作管理テーブルの他の一例を示す図である。

符号の説明

10 プレゼンスサービスシステム
12 プレゼンスサーバ
14、16 ユーザ端末装置
18 IPネットワーク
20 信号処理部
22 プレゼンス情報管理部
24 ユーザ情報管理部

Claims

ネットワークに接続する管理装置により複数の端末装置間で通信されるプレゼンス情報を仲介しサービスとして提供する前記管理装置の通信制御方法において、該方法は、
あらかじめ受信する情報と該情報に応じた動作条件とを対応させた第１の管理テーブルを前記管理装置に用意し、
前記管理装置にて前記端末装置の一つから供給される情報が異常を示すか否かを判断する第１の工程と、
前記異常を示す情報の受信と判断した際に第１の管理テーブルを参照する第２の工程と、
第１の管理テーブルから受信した情報に対応する動作条件で動作させる第３の工程とを含み、
前記管理装置は、さらに、前記端末装置を利用するクライアントの識別と該クライアント毎に設定する第１の管理テーブルの種別とを関連付けした第２の管理テーブルを設け、
第３の工程は、前記クライアントそれぞれに応じた動作を決定して、動作させることを特徴とする通信制御方法。
請求項１に記載の方法において、該方法は、前記プレゼンス情報の通信制御にセッション開始プロトコルを用いることを特徴とする通信制御方法。