(57)【要約】【課題】たとえば登録における障害発生後の復旧時に生じる障害を確実に防ぎ、また、一般的な障害からの復旧に対応して構成要素を変更することなく、容易に行うことができるシステム障害対策方法を提供。【解決手段】SIPサーバシステム10は、SIPソフトフォン26, 28のメモリ30, 32にそれぞれ登録情報を格納し、障害の復旧後にたとえば、障害のあったSIPソフトフォン26から保存していた登録情報を送出して、登録情報（Register）に基づき登録を管理するSIPシステム12のSIPサーバ16における障害発生前の登録情報との不一致を防止して、正常に再登録する。【選択図】図１
2005148794.tif 000002
【特許請求の範囲】
【請求項１】
クライアント-サーバシステムにおけるクライアント端末装置に発生した障害の復旧に際して生じるシステム障害を回避する対策方法であって、
前記クライアント端末装置は、前記サーバヘの登録情報を保持し、
該クライアント端末装置に生じた障害の復旧後に、保持していた登録情報により前記サーバに登録することを特徴とするシステム障害対策方法。
【請求項２】
請求項１に記載の方法において、前記登録情報は、前記クライアント端末装置に対する登録識別情報およびシーケンス番号であることを特徴とするシステム障害対策方法。
【請求項３】
異なる通信プロトコルの環境により構築されたサーバシステムに接続するクライアント端末装置のそれぞれと情報を通信するサービスシステムにおいて一方の通信プロトコルに基づいて動作するクライアント端末装置の障害発生にともなうシステム障害対策方法において、該方法は、
前記障害発生したクライアント端末装置を再起動する第１の工程と、
該クライアント端末装置を前記一方の通信プロトコルにより構築された第１のサーバシステムに接続する前に、他方の通信プロトコルにより構築された第２のサーバシステムに接続されているクライアント端末装置に対して、第１のサーバシステムに接続される前記障害発生したクライアント端末装置の登録情報をリセットする要求情報を前記障害発生したクライアント端末装置から出力する第２の工程と、
前記第２のサーバシステムに接続されているクライアント端末装置から第２のサーバシステムに前記要求情報を指示として出力する第３の工程と、
第２のサーバシステムにて第２のサーバシステムと第１のサーバシステムとの間の情報を共有し、通信する所定の通信プロトコルを起動させる第４の工程と、
前記要求情報を前記所定の通信プロトコルで処理して、第１のサーバシステムに送出する第５の工程と、
第１のサーバシステムにて前記所定の通信プロトコルにされた要求情報を第１のサーバシステムで用いる通信プロトコルで表される要求情報に処理する第６の工程と、
該処理した要求情報を基に第１のサーバシステムに登録されている該当の登録情報をリセットする第７の工程と、
該リセット後に、前記障害発生したクライアント端末装置から再登録する第８の工程とを含むことを特徴とするシステム障害対策方法。
【請求項４】
請求項３に記載の方法において、前記所定のプロトコルは、SOAP（Simple Object Access Protocol）およびCORBA (Common Object Request Broker Architecture）のいずれか一方であることを特徴とするシステム障害対策方法。
【請求項５】
請求項３または４に記載の方法において、前記サービスシステムは、第１のサーバシステムおよび第２のサーバシステムを同一のサーバに収容して、前記要求情報に対する処理を行うことを特徴とするシステム障害対策方法。
【請求項６】
請求項５に記載の方法において、前記所定の通信プロトコルは、該通信プロトコルの処理としてプログラム言語により記載された所定の関数呼出しプログラムにより前記要求情報を処理することを特徴とするシステム障害対策方法。
【請求項７】
請求項３または４に記載の方法において、第５の工程は、第２のサーバシステムからの前記要求情報を前記所定の通信プロトコルに処理し、該所定の通信プロトコルに基づくネットワークを介して第１のサーバシステムに供給することを特徴とするシステム障害対策方法。
【請求項８】
請求項３、４、５または７に記載の方法において、第１のサーバシステムは、通信環境をSIP（Session Initiation Protocol）環境であり、第２のサーバシステムは、通信環境をWeb（world wide Web)環境であることを特徴とするシステム障害対策方法。
【請求項９】
請求項３、４、５または７に記載の方法において、第１のサーバシステムは、通信環境をSIP（Session Initiation Protocol）環境であり、第２のサーバシステムは、通信環境をFTP（File Transfer Protocol)環境であることを特徴とするシステム障害対策方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システム障害対策方法に関し、とくに、あるシステムの端末装置に生じた障害後の復旧にともない生じる障害を回避して、通信サービスの端末装置等とこのシステムとの接続性を確保する端末登録におけるシステム障害対策方法に関するものである。
【背景技術】
【０００２】
従来、たとえばSIP（Session Initiation Protocol）環境下の通信でプロキシサーバを使用したシーケンスでは、まず、登録（REGISTER）メッセージを用いて端末をプロキシサーバに登録する。この登録に際し、リクエスト中のコマンドシーケンス（Cseq： Command sequence）ヘッダには、トランザクションを一意に決定するためダイアログ内のトランザクションに順番が付与される。これにより、新規のリクエストと再送されているリクエストの区別等が可能になる。
【０００３】
【非特許文献１】RFC3261、インターネット＜URL：http://www.ietf.org/rfc/rfc3261.txt＞
【非特許文献２】インターネット＜URL：http://jcp.org/aboutJava/communityprocess/final/jsr116/index.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、SIP環境下でSIPソフトフォント等を用いたサービスを実施する場合において、エンドユーザの使用する端末装置が突然異常となる場合やアクセスラインが異常になることがある。前者の場合は、たとえば、パーソナルコンピュータ（Personal Computer）の異常現象の一つであるブルーバック等がある。また、後者の場合には、別のアクセスラインとして、たとえば、ADSL（Asymmetric Digital Subscriber Line）からホットスポットを使用するとき、最初にサーバと接続したクライアントが存在し、この後に接続したクライアントがサーバと接続することを許容しないサービス形態がある。この場合、リクエスト中のコマンドシーケンス（Cseq）フィールドの制御が不能なことから、端末装置の復旧後の登録を行うことができない。すなわち、サーバヘの端末登録が行えない。
【０００５】
具体的には、一方の端末装置からプロキシサーバに登録メッセージを送信し、このサーバヘの端末登録が正常に行われると、プロキシサーバは一方の端末装置に対してメッセージ（200 OK）を返信する。この登録後は、上述したように後から接続したクライアントがサーバと接続することを許容しないサービス形態では、他方の端末装置が登録メッセージをプロキシサーバに送信しても、この後からのトランザクションに対する順番には、先のシーケンスのトランザクションに対してCseqヘッダに付与された順番とは異なる順番が付与されている。これにより、他方の端末装置は、プロキシサーバにログインすることができない。プロキシサーバは、他方の端末装置にメッセージ（403 NG）を出力する。
【０００６】
端末装置がログインできない現象はこのような場合だけに限定されるものでない。たとえば、一方の端末装置に障害が発生し、復旧後にこの端末装置から再度登録メッセージをプロキシサーバに送信し、プロキシサーバヘの端末登録を行う場合も、この端末装置は、プロキシサーバにログインができない。復旧後に送出するCseqヘッダに付与された順番が先の順番と異なるからである。プロキシサーバは、障害の発生した端末装置にメッセージ（403 NG）を返信する。このように一方の端末装置を使用するユーザは、自分がログインしていたにもかかわらず、障害復旧後にはログインできないことになる。
【０００７】
また、異常になった端末装置のユーザが保守者に電話連絡し、サービス管理者がWeb画面等を見ながら、サーバを遠隔操作して、サーバのデータベースを更新または変更して、このユーザのログインを実行しようとしても、サービス管理者は、Webブラウザの表示画面を基にサーバのデータベースを更新できない。これは、サービス管理者が扱うWeb環境とSIP環境にある端末装置との融合が図られていないことが原因である。従来のWeb-AP環境は、企業の情報システムや国際標準化プロファイル（International Standardized Profile: ISP）が提供する情報提供型のAPサービスの構築に用いられ、一方のSIP-AP環境は電話系サービスの構築に用いられ、異なる用途に利用されていた。
【０００８】
本発明はこのような従来技術の欠点を解消し、たとえば登録における障害発生後の復旧時に生じる障害を確実に防ぎ、また、一般的な障害からの復旧に対応して構成要素を変更することなく、容易に行うことができるシステム障害対策方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は上述の課題を解決するために、クライアント-サーバシステムにおけるクライアント端末装置に発生した障害の復旧に際して生じるシステム障害を回避する対策方法であって、クライアント端末装置は、サーバヘの登録情報を保持し、このクライアント端末装置に生じた障害の復旧後に、保持していた登録情報によりサーバに登録することを特徴とする。
【００１０】
本発明のシステム障害対策方法は、クライアント端末装置に登録情報を格納し、障害の復旧後にクライアント端末装置から登録情報を送出することにより、登録情報に基づき登録を管理するサーバにおける障害発生前の登録情報との不一致を避けることができ、正常に再登録することができる。
【００１１】
また、本発明は上述の課題を解決するために、異なる通信プロトコルの環境により構築されたサーバシステムに接続するクライアント端末装置のそれぞれと情報を通信するサービスシステムにおいて一方の通信プロトコルに基づいて動作するクライアント端末装置の障害発生にともなうシステム障害対策方法において、この方法は、障害発生したクライアント端末装置を再起動する第１の工程と、このクライアント端末装置を一方の通信プロトコルにより構築された第１のサーバシステムに接続する前に、他方の通信プロトコルにより構築された第２のサーバシステムに接続されているクライアント端末装置に対して、第１のサーバシステムに接続される障害発生したクライアント端末装置の登録情報をリセットする要求情報を障害発生したクライアント端末装置から出力する第２の工程と、第２のサーバシステムに接続されているクライアント端末装置から第２のサーバシステムに要求情報を指示として出力する第３の工程と、第２のサーバシステムにて第２のサーバシステムと第１のサーバシステムとの間の情報を共有し、通信する所定の通信プロトコルを起動させる第４の工程と、要求情報を所定の通信プロトコルで処理して、第１のサーバシステムに送出する第５の工程と、第１のサーバシステムにて所定の通信プロトコルにされた要求情報を第１のサーバシステムで用いる通信プロトコルで表される要求情報に処理する第６の工程と、この処理した要求情報を基に第１のサーバシステムに登録されている該当の登録情報をリセットする第７の工程と、このリセット後に、障害発生したクライアント端末装置から再登録する第８の工程とを含むことを特徴とする。
【００１２】
本発明のシステム障害対策方法は、障害発生したクライアント端末装置を再起動し、このクライアント端末装置を第１のサーバシステムに接続する前に、第２のサーバシステムに接続されているクライアント端末装置に対して障害発生したクライアント端末装置の登録情報をリセットする要求情報を出力し、第２のサーバシステムに接続されているクライアント端末装置から第２のサーバシステムに要求情報を指示として出力し、第２のサーバシステムにて所定の通信プロトコルを起動させ、要求情報を所定の通信プロトコルで処理して、第１のサーバシステムに送出し、この要求情報を第１のサーバシステムで用いる要求情報に処理し、この要求情報を基に第１のサーバシステムに登録されている該当の登録情報だけをリセットして、このリセット後に、障害発生したクライアント端末装置から再登録することにより、障害発生後の登録拒否を回避して、このクライアント端末装置が接続する第１のサーバシステムにクライアント端末装置を正常にログインさせることができる。
【発明を実施するための最良の形態】
【００１３】
次に添付図面を参照して本発明によるサービス提供システムの実施例を詳細に説明する。図１を参照すると、本発明によるサービス提供システムの実施例は、SIPサービスシステム10に適用した場合であり、SIP単一環境下で障害復旧時のサーバヘの端末登録方法を実現するシステム構成を示すものである。本発明と直接関係のない部分について図示および説明を省略する。以下の説明で、信号はその現れる接続線の参照番号で指示する。
【００１４】
SIPサービスシステム10は、SIP環境のシステムとしてSIPシステム12およびSIPクライアント14を含む。SIPシステム12は、１つのサーバ計算機内または同じドメイン内のLAN環境に配置する構成をとるものである。SIPシステム12は、SIPサーバ16、SIPデータベース（SIP-DB）18、SIPアプリケーションサーバ（SIP-APサーバ）20、SIPアプリケーションインタフェース（SIP-API）22およびSIPアプリケーション（SIP−AP）24を含む。
【００１５】
SIPサーバ16は、エンド・ツー・エンドでやりとりするクライアント-サーバモデルのプロトコルであるSIPに基づいてクライアントの要求に応じて応答するサーバであり、とくにIETF（International Engineering Task Force）で規定される、たとえばRFC（Request For Comments)3261に準拠したSIPをハンドリング・管理する機能を有している。この管理機能のうち、SIPサーバ16には、一般的に３つのサーバ機能、すなわちSIPプロキシサーバ機能、SIPレジストラサーバ機能およびSIPロケーションサーバ機能が含まれている。第１に、SIPプロキシサーバ機能はクライアントの代理として、SIPメッセージの中継を行う機能である。第２に、SIPレジストラサーバ機能はクライアントの登録を管理する機能である。第３に、SIPロケーションサーバ機能は登録されたクライアントのアドレス情報等を管理する機能を有している。SIPサーバ16は、たとえばSIPクライアント14の構成要素であるSIPソフトフォン26, 28に接続され、SIP-APサーバ20から提供される情報をSIPメッセージによりやりとりしている。
【００１６】
SIP-DB 18は、SIPサーバ16が管理する、たとえばユーザ情報、プレゼンス情報等を相互に関連付けて格納するストレージで、SIPサーバ16に接続され、SIPサーバ16の検索要求に応じて情報を提供する機能を有するものもある。SIP-DB 18においてユーザ情報は、クライアントのアドレス情報や認証を行うための情報である。また、プレゼンス情報は、クライアントがSIPシステム12に接続されているか否か、クライアントが起動・利用されているか否か、さらに別のクライアントと接続中であるか否か等の情報であり、これらの情報からわかるように、SIP-DB 18は、クライアントの状態を表わす情報を格納している。
【００１７】
SIP-APサーバ20は、SIPプロトコルに基づいてSIPサーバ16により管理されるアプリケーションを操作に応じて稼動するサーバである。SIP-APサーバ20は、SIPサーバ16およびSIP-API 22にそれぞれ接続されている。SIP-API 22は、SIPサーバ16で受信するSIPリクエストに応じてアプリケーションを操作する機能およびSIPサーバ16ヘのリクエストを発行する機能を有する。SIPリクエストには、セッション確立、確認応答、通話終了およびプレゼンス変更等がある。
【００１８】
SIP-API 22は、SIP-APサーバ20が提供するアプリケーションインタフェースである。SIP-APサーバ20は、SIP-API 22を介してSIP-AP 24に接続されている。SIP-API 22には、代表的なものとして、JCP（Java（登録商標）Community Process）において標準化作業が進められているSIP Servlet アプリケーションインタフェースがある。
【００１９】
SIP-AP 24は、接続するSIP-API 22により構築され、SIP-APサーバ20上で稼動するアプリケーションである。SIP-AP 24には、図示しないがUA（User Agent）生成アプリケーションが含まれている。UA生成アプリケーションとは、UA、すなわちアプリケーションソフト等のようなエンドシステムが持つ機能で、SIPリクエストの生成に際してUAクライアントとして動作し、リクエストの処理後においてレスポンスの生成に際してUAS（UA Server）として動作する機能を有するものである。アプリケーションには、たとえばIP電話、インスタントメッセージ、TV（TeleVision）電話、プレゼンスコミュニケーション等がある。
【００２０】
SIPクライアント14は、SIPサーバ16と接続し、SIP-AP 24が提供する機能を利用するクライアント環境を備えた端末装置である。代表的なものには、前述したSIPソフトフォン26, 28がある。SIPソフトフォン26, 28には、それぞれメモリ30, 32が含まれ、たとえばハードディスク装置（Hard Disk Drive: HDD）等のように記憶保持できるものであればよい。メモリ30, 32は、情報としてたとえば呼出し番号（Call-ID）およびコマンドシーケンス（Cseq）を保持する。メモリ30, 32は、障害が発生したSIPソフトフォン26, 28を復旧させた後、メモリ30, 32に蓄積しているCall-IDおよびCseqを読み出してSIPサーバ16に端末として登録する。
【００２１】
このようにSIPサービスシステム10は、SIPクライアント14の端末装置個々にSIPサーバ16への登録に用いる情報を格納するメモリ30, 32を配設して障害発生前の情報を保持することにより、障害復旧前後の情報を一致させることができる。
【００２２】
次にSIPサービスシステム10における端末装置の登録処理について図２を参照しながら、簡単に説明する。本実施例のSIPサービスシステム10は、前述したように一つのクライアント（端末装置）を登録した後に接続したクライアントがSIPサーバ16との接続を許容しないサービス形態である。
【００２３】
まず、SIPソフトフォン26は、プロキシサーバとして機能するSIPサーバ162-4に登録メッセージ（Register）34を時刻T10にて送信する。SIPサーバ16は、登録メッセージ34を基にSIPソフトフォン26を登録する。SIPサーバ16は、SIPソフトフォン26の登録が正常に行われた場合、時刻T12にて応答メッセージ（Response）36をSIPソフトフォン26に出力する。この場合、応答メッセージの内容は、200 OKである。SIPソフトフォン26は、応答メッセージ36を受けてメモリ30にCall-IDおよびCseqを保持する。
【００２４】
次に他のクライアントである、SIPソフトフォン28が時刻T14にて登録メッセージ（Register）38をSIPサーバ16に送信する。ここで、この登録シーケンスのトランザクションでは、時刻T10での登録シーケンスのトランザクションに対してCseqヘッダに付与された順番とは異なる順番が付与される。これにより、SIPサーバ16はSIPソフトフォン28からの登録を受け付けず、応答メッセージ（Response）40をSIPソフトフォン28に出力する。この場合、応答メッセージ40の内容は、403 NGである。このような登録排除を受けて、SIPソフトフォン28は、SIPサーバ16にログインすることができない。
【００２５】
この後、時刻T18にてSIPソフトフォン26に障害が発生する。SIPソフトフォン26を再起動して復旧させる。障害復旧後、SIPソフトフォン26は、メモリ30に蓄積しているCall-IDおよびCseqを用いて、SIPサーバ16に登録メッセージ（Register）42を時刻T20にて送信する。登録メッセージ42は、障害発生前のCall-IDおよびCseqに基づく情報である。したがって、SIPサーバ16は、障害発生前の情報を受けることにより、SIPソフトフォン26の登録を正常に処理し、SIPソフトフォン26に応答メッセージ44を時刻T22にて出力する。応答メッセージ44は、200 OKである。
【００２６】
なお、本実施例は、単なる障害復旧だけに限定されるものでなく、SIPクライアント14の個々に登録情報を保持することにより、アクセスライン異常時に同一端末装置/同一ユーザIDによる他アクセスラインからの登録も可能にする。
【００２７】
このように動作させることにより、SIPクライアント14の障害対策として、SIPソフトフォン26, 28にて、Call-IDおよびCseqをメモリに保存することにより、障害復旧後の登録を確実に行わせることができる。
【００２８】
次に本発明の他の実施例として図３に示すサービス提供システム50を基に説明する。サービス提供システム50は、SIPシステム12とWebシステム52とが異なるネットワークドメインに属するネットワーク環境上に配置する構成をとる。また、SIPシステム12、Webシステム52は、それぞれ１つのサーバ計算機内または同じドメイン内のLAN環境に配置する構成をとるものとする。
【００２９】
ネットワーク54は、本実施例においてSOAP (Simple Object Access Protocol)/CORBA (Common Object Request Broker Architecture)ネットワークであり、SIPシステム12とWebシステム52との情報を仲介する役割を担っている。SOAPは、Webサービス間で交換されるメッセージのデータフォーマットやメッセージの処理ルールを規定した通信プロトコルである。ネットワーク16は、この規定に従ったSOAPメッセージをサービス要求者、サービス提供者およびサービス仲介者が相互にやりとりする。CORBAは、OMG（Object Management Group）が策定した分散オブジェクト技術である。
【００３０】
SIPシステム12は、先の実施例と同じ構成要素を含み、同じ構成要素に対して同じ参照符号を付して、説明の煩雑さを避けるため説明を省略する。本実施例のSIPシステム12は、先の実施例の構成要素に加えて、Webアクセッサコンポーネント56を含む。また、Webシステム52は、Web環境としてWebサーバ58、Webデータベース（Web-DB）60、Webアプリケーションサーバ（Web-APサーバ）62、Webアプリケーションインタフェース（Web-API）64、Webアプリケーション（Web-AP）66、SIPアクセッサコンポーネント68およびWebクライアント70を含む。図３および後述する図６のWebシステム52やFTPシステム110は、便宜上、１つの計算機内に配設する構成要素群を表している。以下に、これらの構成要素についてそれぞれ簡単に説明する。
【００３１】
SIPシステム12内のWebアクセッサコンポーネント56は、SIP-AP 24がWebシステム52と連携するコンポーネント群の総称であり、コンポーネントのそれぞれはライブラリソフトウェア部品を表している。したがって、Webアクセッサコンポーネント56は、SIP-AP 24が動作する際に呼び出され、Webシステム52の後述するSIPアクセッサコンポーネント68と交信する際に利用される。Webアクセッサコンポーネント56には、連携管理部72およびコンポーネントAPI 74を含む。
【００３２】
連携管理部70はWebシステム52内の対応する連携管理部76と連携し、Webシステム52側からのアクセスまたはWebシステム52側へのアクセスを行う通信環境を管理する機能を有している。具体的に説明すると、連携管理部70は、SIPクライアント14のリセット要求をWebサーバ58に送信し、また、Webサーバ58からのリセット指示をSIPシステム12で受信し、SIPクライアント14に送信する通信環境調整機能を有する。連携管理環境には、たとえば、SOAPやCORBAのプロトコルに対応する環境設定等がある。コンポーネントAPI 74は、対応するコンポーネントをSIP-AP 24が利用するためのインタフェースである。
【００３３】
SIPクライアント14は、SIPソフトフォン26, 28を含む。ただし、SIPソフトフォン26, 28は、それぞれ、先のSIPサービスシステム10の場合と多少構成要素に相違点がある。この相違点は、SIPソフトフォン26, 28は、メモリ30, 32を持っていないということである。
【００３４】
次にWebシステム52について説明する。Webサーバ58は、HTTP（Hyper Text Transfer Protocol）を基にハンドリング・管理するサーバである。Webサーバ58は、Webクライアント70の構成要素であるWebブラウザ78, 80に接続されている。また、Webサーバ58は、Web-DB 60およびWeb-APサーバ62と接続してこれらを管理している。
【００３５】
Web-DB 60は、Webサーバ58が管理する情報を格納するストレージであり、Webサーバ58の検索要求に応じて情報を提供する機能を有するものもある。格納する管理情報には、クライアントの課金情報および利用ログ等がある。Web-DB 60は、Webサーバ58だけでなく、Web-APサーバ62にもデータを提供できるように接続されている。
【００３６】
Web-APサーバ62は、常時起動状態にあって、WebプロトコルであるHTTPに基づいてWebサーバ58により管理されるアプリケーションを操作に応じて稼動するサーバである。Web-APサーバ62には、たとえば、オープンソースのTOMCAT、BEAシステム社のWebLogic（商標）等が挙げられる。Web-APサーバ62は、Web-API 64を介してWeb-AP 66に接続されている。Web-APサーバ62は、Web-DB 60の情報を基にアプリケーションを動作させてもよい。
【００３７】
Web-API 64は、Web-APサーバ62が提供するアプリケーションインタフェースである。Web-API 64は、代表的なAPIとして、J2EE（Java2 Enterprise Edition）環境で規定されているHTTP Servlet APIやEJB（Enterprise Java（商標） Beans）等がある。Web-API 64は、Web-APサーバ62とWeb-AP 66との情報のやりとりを可能にしている。
【００３８】
Web-AP 66は、接続するWeb-API 64により構築され、Web-APサーバ62上で稼動するWebアプリケーションであり、SIPアクセッサコンポーネント68にも接続されている。Web-AP 66には、たとえば、インターネットショッピングモール、企業ポータルおよびコンテンツ配信等のAPがある。本実施例のWeb-AP 66は、SIPクライアント14側からのリセット要求を受けた保守者がSIP-APサーバ20ヘのリセット指示を生成する。この他、Web-AP 66は、たとえば図示しないがマッチングAPおよびDB検索APを含むようにしてもよい。マッチングAPは、UAの位置情報変更にともない、位置情報に関連するUAの登録情報と更新位置の情報、時間または季節で表される更新時期情報および過去情報等をそれぞれ照合し、適合した情報をUAヘメッセージとして送信するアプリケーションである。また、DB検索APは、位置情報に関連するUAの登録情報、更新位置の情報、更新時期情報および過去情報等をWeb-DB 60より抽出するアプリケーションである。
【００３９】
SIPアクセッサコンポーネント68は、Web-AP 66がSIPシステム12と連携するコンポーネント群の総称であり、Web-AP 66が動作する際に呼び出されるライブラリソフトウェアである。たとえば、以下のコンポーネンおよびAPIが存在する。SIPアクセッサコンポーネント68は、Web-AP 66がSIPシステム12上のWebアクセッサコンポーネント56と交信する際に利用される。この場合も、Webアクセッサコンポーネント56と同様に、Web-AP 66は、SIP-AP 24と連携したどのような機能を実現するかに応じてWeb-AP 66側から組合せて利用できるものである。SIPアクセッサコンポーネント68は、用途に応じて随時拡張することが可能で、このコンポーネントの追加・拡張により、SIPシステム12との連携のバリエーションも追加・拡張されることになる。
【００４０】
SIPアクセッサコンポーネント68には、連携管理部76およびコンポーネントAPI 82を含む。連携管理部76は、SIPシステム12内の対応する連携管理部72と連携し、SIPシステム12側へのアクセスまたはSIPシステム12側からWebシステム52側へのアクセスを行う通信環境の管理機能を有している。具体的には、SIPクライアント14からのリセット要求を受信し、またWebサーバ58からのリセット指示をSIPシステム12に送信する通信環境が設定されている。連携管理環境には、たとえば、SOAPやCORBAのプロトコルに対応する環境設定等を含む。本実施例では、連携にCORBAを用いるときCORBAのスタブ、SOAPを用いる場合SOAPアクセス用のスタブを利用している。
【００４１】
コンポーネントAPI 78は、対応するコンポーネントをWeb-AP 40が利用するためのインタフェースである。
【００４２】
Webクライアント70は、Webサーバ58と接続し、Web-AP 66が提供する機能を利用するクライアント環境を有している。代表的なWebクライアントには、Webブラウザがある。
【００４３】
このように構成してWeb環境上に構築されるAPと、SIP環境上に構築されるAPが相互に連携可能となり、WebとVoIPの融合型APの構築・実行・運用が容易に実現される。
【００４４】
次にサービス提供システム50の動作について図４を参照しながら、簡単に説明する。SIPソフトフォン26は、SIPサーバ16に登録メッセージ（Register）84を時刻T30にて送信する。SIPサーバ16は、登録メッセージ84によりSIPソフトフォン26を登録する。SIPサーバ16は、時刻T32にて正常な登録処理の完了を示す応答メッセージ（Response）86をSIPソフトフォン26に出力する。この場合、SIPサーバ16は、応答メッセージの内容として200 OKメッセージを返信する。
【００４５】
次に時刻T34にてたとえばSIPソフトフォン26に障害が発生し、その後復旧処理によりSIPソフトフォン26を再起動する。この再起動にともないSIPソフトフォン26のユーザは、時刻T36にてたとえば、SIPソフトフォン26からキャリア保守対応者に対して登録情報（Call-IDおよびCseq）が異なることにより再接続が不能となることを回避すべく、Webサーバ58からSIPサーバ16のクライアント登録情報のリセットを依頼する（Reset_REQ. 88）。
【００４６】
リセット依頼を受けたキャリア保守対応者は、Webブラウザ78を利用して時刻T38にて“リセット指示”（Reset_INST.)90をWebサーバ58/Web-APサーバ62に通知する。Webサーバ58/Web-APサーバ62は、供給された“RESET指示”を基にこの指示を含む起動信号（Launching）92を生成し、時刻T40にて連携管理部76に出力する。連携管理部76は、起動信号92を受信して起動する。
【００４７】
連携管理部76は、Webシステム52およびSIPシステム12において共通に扱えるたとえばSOAPおよびCORBAのいずれか一方を選択する。連携管理部76は、時刻T42にて本実施例でHTTPプロトコルに基づく“リセット指示”をSOAPプロトコルの情報にしてネットワーク54上の別ドメイン内に存在する連携管理部70に出力し、通信する。この通信により、Webシステム52は、SIPシステム12にSIPソフトフォン26の登録情報をリセットするSOAPプロトコルに基づく“リセット指示”情報を伝える。連携管理部72は、図示しないがSOAPプロトコルの“リセット指示”94内に含む情報をSIPプロトコルにして、SIP-APサーバ20に供給する。
【００４８】
SIP-APサーバ20は、供給されるリセット指示94を受信する。SIP−APサーバ20は、SIPソフトフォン26の登録情報を含む場合この指示に基づき障害発生前の登録情報をリセットする。また、SIP-APサーバ20は、SIPサーバ16がSIPソフトフォン26の登録情報を含む場合、リセット信号（Reset）96を生成し、時刻T44にて障害発生前の登録情報を供給し、リセットする。
【００４９】
SIPソフトフォン26は、時刻T46にて再度登録メッセージ（Register）98をSIPサーバ16に送る。SIPサーバ16は、リセット後に供給される登録を正常に処理して、登録され、時刻T48にて応答メッセージ（Response）100を出力する。この場合、応答メッセージ100の内容は、200 OKである。SIPソフトフォン26は、SIPシステムのSIPサーバ16にログインすることができる。
【００５０】
先の実施例と異なり、SIPソフトフォン26に登録情報を保持せずに、SIPサーバ16上の登録情報がWebシステム52を経由してリセットする保守インタフェースを設け、障害発生前に登録されたCall-IDおよびCseqの影響を受けないようにSIPサーバ16/SIP-APサーバ20の登録情報をリセットすることにより、このリセット以後の登録処理に対して正常に行うことができる。具体的には、ブルーバック時やアクセスライン異常時に同一、すなわち該当ユーザだけの登録情報をリセットし、この後は同一ユーザからのログインを行うことができる。このようにWeb環境とSIP環境が相互に連携可能となり、WebとVoIPを融合した端末の再登録が可能となる。
【００５１】
次に本発明を適用したサービス提供システム50の第１変形例を図５に示す。サービス提供システム50は、SIPシステム10とWebシステム52とが１つの計算機環境上に配置され、同一計算機上のプロセス連携により接続されている。この接続から明らかなように本実施例のサービス提供システム10は、ネットワーク54を介さない。また、図３に示した連携管理部72, 76は、あえて構成要素として配設するのではなく、Webアクセッサコンポーネント56とSIPアクセッサコンポーネント68にそれぞれ、連携管理を行う関数呼出し機能部102により異なるシステム間をつなぐ。関数呼出し機能部102は、たとえば、C言語やC++言語の関数呼出しやJava（商標）言語のメソッドコールを用いたプログラムを配するとよい。動作手順は先の実施例と同じである。
【００５２】
このように構成しても、他の実施例と同様に、Web環境上に構築されるAPとSIP環境上に構築されるAPとを相互に連携することが可能になる。これにより、WebとVoIPの融合型APの構築・実行・運用が容易に実現されることになる。また、本実施例では、単一計算機環境上にシステムを構築することにより、小規模な計算機環境下でのWeb-APとVoIP-APの融合が実現することができる。
【００５３】
次に本発明を適用したサービス提供システム10の第２変形例について図６を参照しながら説明する。本実施例のサービス提供システム10は、SIPシステム12とFTP（File Transfer Protocol）システム110とが、ネットワーク54により接続されている。ここで、SIPシステム12とFTPシステム110は異なるネットワークドメインに属するネットワーク環境上に配置されている。また、SIPシステム12およびFTPシステム110は、それぞれ、他の実施例と同様に１つのサーバ計算機内または同じドメイン内のLAN環境に配置する構成にしている。
【００５４】
SIPシステム12は、図３に示した他の実施例とまったく同じ構成を用い、同じ参照符号を付して説明を省略している。ただし、本実施例の場合、SIPシステム12におけるアクセッサコンポーネントの機能は、Webアクセッサコンポーネント28とまったく同じであるが、Web対応でなく、FTPであることから、名称をFTPアクセッサコンポーネント104としている。
【００５５】
もう一方のシステムであるFTPシステム110は、FTPサーバ112、FTPデータベース（FTP-DB）114、FTPアプリケーションサーバ（FTP-APサーバ）116、FTPアプリケーションインタフェース（FTP-API）118、FTPアプリケーション（FTP-AP）120、SIPアクセッサコンポーネント112およびFTPクライアント124を含む。以下に、各構成要素について簡単に説明する。
【００５６】
FTPサーバ112はFTPをハンドリング・管埋するサーバである。FTP-DB 114はFTPサーバ112が管理する情報を格納するストレージで、データベースである。格納する情報は、FTPにより転送されたファイル情報等である。FTP-APサーバ116はFTPサーバ112により管理されるファイル転送プロトコル（FTP）を操作するAPを稼動するサーバである。FTP-API 118はFTP-APサーバ120が提供するAPインタフェースである。FTP-AP 120は、FTP-API 118により構築され、FTP-APサーバ116上で稼動するFTP-APである。APには、たとえば２者間でのピア・ツー・ピア型のファイル交換、ファイル共有等のAPがある。
【００５７】
SIPアクセッサコンポーネント122は、FTP-AP 120がSIPシステム12と連携するコンポーネント群（ソフトウェア部品）の総称である。SIPアクセッサコンポーネント122は、前述したWebシステム14のSIPアクセッサコンポーネント68と同じものである。すなわち、連携管理部76およびコンポーネントAPI 82を含む。各構成要素の機能は、前述した最初の実施例と同じである。
【００５８】
FTPクライアント124はFTPサーバ112と接続し、FTP-AP 120が提供する機能を利用する環境に設定されているクライアントである。FTPクライアント124には複数のFTPクライアント端末126, 128を有してもよい。FTPクライアント124は一般的にテキスト表示画面を有する。
【００５９】
この構成により、異なるシステムにもかかわらず、得られた情報を要求のあったクライアントに提供するアプリケーションを構築することができる。すなわち、FTPシステム110上に構築されるAPとSIPシステム12上に構築されるAPが相互に連携可能となり、FTPとVoIPの融合型APの構築・実行・運用が容易に実現される。この構築により各システムの情報を共有して、スムーズに利用することができるようになる。また、FTPアクセッサコンポーネント104上とSIPアクセッサコンポーネント122上の各種コンポーネントを増設することにより、FTPとVoIPの融合タイプを拡張することができる。実装するSIP-APとFTP-APの種類とともに、このコンポーネントの種類を増やすことにより、様々なFTPとVoIPの融合型APを実現することができる。
【００６０】
次にサービス提供システム50におけるクライアントの登録動作について説明する。この場合、時刻T10から時刻T12の動作は図４に示したように、まったく同じで、説明を省略する。時刻T50にて障害がサービス提供システム50のSIPソフトフォン26に発生し、その後復旧処理によりSIPソフトフォン26を再起動する。この再起動にともないSIPソフトフォン26のユーザは、時刻T52にてたとえば、SIPソフトフォン26からキャリア保守対応者に対して登録情報（Call-IDおよびCseq）が異なることにより再接続が不能となることを回避すべく、FTPサーバ58からSIPサーバ16のクライアント登録情報のリセットを依頼する（Reset_REQ. 88）。
【００６１】
リセット依頼を受けたキャリア保守対応者は、FTPクライアント端末126を利用して時刻T54にて“リセット指示”（Reset_INST.)130をFTPサーバ112/FTP-APサーバ116に通知する。Webサーバ112/Web-APサーバ116は、供給された“RESET指示”を基にこの指示を含む起動信号（Launching）132を生成し、時刻T56にて連携管理部76に出力する。連携管理部76は、起動信号132を受信して起動する。
【００６２】
連携管理部76は、FTPシステム110およびSIPシステム12において共通に扱えるたとえばSOAPおよびCORBAのいずれか一方を選択する。連携管理部76は、時刻T58にて本実施例でHTTPプロトコルに基づく“リセット指示”をSOAPプロトコルの情報にしてネットワーク54上の別ドメイン内に存在する連携管理部70に出力し、通信する。この通信により、FTPシステム110は、SIPシステム12にSIPソフトフォン26の登録情報をリセットするSOAPプロトコルに基づく“リセット指示”情報を伝える。連携管理部72は、図示しないがSOAPプロトコルの“リセット指示”134内に含む情報をSIPプロトコルにして、SIP-APサーバ20に供給する。
【００６３】
SIP-APサーバ20は、供給されるリセット指示134を受信する。SIP−APサーバ20は、SIPソフトフォン26の登録情報を含む場合この指示に基づき障害発生前の登録情報をリセットする。また、SIP-APサーバ20は、SIPサーバ16がSIPソフトフォン26の登録情報を含む場合、リセット信号（Reset）136を生成し、時刻T60にて障害発生前の登録情報を供給し、リセットする。
【００６４】
SIPソフトフォン26は、時刻T62にて再度登録メッセージ（Register）138をSIPサーバ16に送る。SIPサーバ16は、リセット後に供給される登録を正常に処理して、登録され、時刻T64にて応答メッセージ（Response）140を出力する。この場合、応答メッセージ100の内容は、200 OKである。SIPソフトフォン26は、SIPシステムのSIPサーバ16にログインすることができる。
【００６５】
このように動作させることにより、SIPサーバ16上の登録情報がFTPシステム110を経由してリセットする保守インタフェースを設け、障害発生前に登録されたCall-IDおよびCseqの影響を受けないようにSIPサーバ16/SIP-APサーバ20の登録情報をリセットすることにより、このリセット以後の登録処理に対して正常に行うことができる。具体的には、ブルーバック時やアクセスライン異常時に同一ユーザだけの登録情報をリセットし、この後は同一ユーザからのログインを行うことができる。このようにFTP環境とSIP環境が相互に連携可能となり、FTPとVoIPを融合した端末の再登録が可能となる。
【００６６】
以上のように構成することにより、SIPサーバシステム10は、SIPソフトフォン26, 28のメモリ30, 32にそれぞれ登録情報を格納し、障害の復旧後にたとえば、障害のあったSIPソフトフォン26から保存していた登録情報を送出することにより、登録情報に基づき登録を管理するSIPシステム12のSIPサーバ16における障害発生前の登録情報との不一致を避けることができ、正常に再登録することができる。
【００６７】
登録情報をクライアント端末装置に対する登録識別情報およびシーケンス番号にすることにより、単にユーザの識別だけでなく、処理における順序も考慮して不正アクセスがないように登録管理することができる。
【００６８】
本発明のシステム障害対策方法は、サービス提供システム50において障害発生したSIPソフトフォン26を再起動し、SIPソフトフォン26をSIPシステム12に接続する前に、Webシステム52に接続されているWebブラウザ78に対して障害が発生したSIPソフトフォン26の登録情報をリセットする要求情報（Reset_REQ.）88を出力し、Webシステム52に接続されているWebブラウザ78からWebサーバ58に要求情報の指示（Reset_INST.）130を出力し、SOAP/CORBAのいずれか一方の通信プロトコルを起動させ、要求情報（Reset_INST.）134を選択した通信プロトコルで処理して、SIPシステム12に送出し、この要求情報をSIPシステム12で用いる要求情報（Reset）136に処理し、この要求情報を基にSIPサーバ16に登録されている該当の登録情報だけをリセットして、このリセット後に、SIPソフトフォン26から再登録することにより、障害発生後の登録拒否を回避して、SIPソフトフォン26をSIPサーバ16にログインさせることができる。
【００６９】
所定のプロトコルは、SOAPおよびCORBAのいずれか一方を用いることにより、SIPプロトコルとHTTPプロトコルとの間における情報通信を可能にしている。また、サービス提供システム50は、SIPシステム12およびWebシステム52を同一のサーバに収容して、要求情報、すなわちリセット要求に対する処理を行っても、リセット要求を異なる経路からアクセスして該当の登録情報だけをリセットすることができる。
【００７０】
通信プロトコルの処理としては、プログラム言語により記載された所定の関数呼出しプログラムにより要求情報を処理することにより、専用の構成要素を設けずに対応することができる。これは構成の小型化を図る上で有利である。
【００７１】
Webシステム52からの要求情報をSOAP/CORBAのいずれかにより処理し、この通信プロトコルに基づくネットワークを介してSIPシステム12に供給することにより、サービス提供システム50に配置上の柔軟性をもたらすことができ、かつシステム障害にも対応することができる。
【００７２】
サービス提供システム50は、SIP環境とWeb環境またはSIP環境とFTP環境を用いることにより、障害の発生したクライアント端末装置の登録情報をリセットする要求を、Web環境またはFTP環境のクライアント端末装置に対して行い、融合したシステムを介して該当する登録情報だけリセットし、再登録を可能にする。このとき、システム構成に変更を加えることなく、構成要素を有効に利用することができる。
【産業上の利用可能性】
【００７３】
本発明を利用することにより、様々な異なるプロトコル間の融合に適用することが可能である。
【図面の簡単な説明】
【００７４】
【図１】本発明が適用されるSIPサービスシステムにおける概略的な構成を示すブロック図である。
【図２】SIPサービスシステムにおける登録の動作手順を説明するシーケンスチャートである。
【図３】本発明が適用される他の実施例であるサービス提供システムにおける概略的な構成を示すブロック図である。
【図４】図３のサービス提供システムにおける障害復旧にともなう登録の動作手順を説明するシーケンスチャートである。
【図５】図３のサービス提供システムにおける第１変形例の概略的な構成を示すブロック図である。
【図６】図３のサービス提供システムにおける第２変形例の概略的な構成を示すブロック図である。
【図７】図６のサービス提供システムにおける障害復旧にともなう登録の動作手順を説明するシーケンスチャートである。
【符号の説明】
【００７５】
10  SIPサービスシステム
12  SIPシステム
14  SIPクライアント
16  SIPサーバ
18  SIP-DB
20  SIP-APサーバ
22  SIP-API
24  SIP-AP
26, 28 SIPソフトフォン
30, 32 メモリ
52  Webシステム
54  SOAP/COARBAネットワーク
56  Webアクセッサコンポーネント
58  Webサーバ
60  Web-DB
62  Web-APサーバ
64  Web-API
66  Web-AP
68  SIPアクセッサコンポーネント
78, 80 Webブラウザ
【図１】
2005148794.tif 000003
【図２】
2005148794.tif 000004
【図３】
2005148794.tif 000005
【図４】
2005148794.tif 000006
【図５】
2005148794.tif 000007
【図６】
2005148794.tif 000008
【図７】
2005148794.tif 000009