(57)【要約】【課題】動的にIPアドレスが付与されるネットワークにおける遠隔保守を可能にするネットワークの遠隔保守方法を提供。【解決手段】サービスネットワーク10において保守装置20は、保守用の判別情報を含むINVITE要求30を送出し、SIPプロキシサーバ18を介してINVITE要求32としてSIP-VoIPゲートウェイ12に供給し、供給された保守用の判別情報と保守対象の装置が保有する判別情報とで判定し、アドレスの取得用のINVITE要求か否かを認識し、この取得用との判定に応じてSIP-VoIPゲートウェイ12に現在設定されているアドレスを含むエラー応答38を生成し、SIPプロキシサーバ18を介して保守装置20に供給し、保守装置20で受信したエラー応答40からアドレスを抽出する。【選択図】図１
2005244306.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された保守対象の装置を特定するアドレスが動的に変動し、該保守対象の装置における保守を遠隔的に行うネットワークの遠隔保守方法において、該方法は、
保守の開始時に保守用の判別情報が設定された要求信号を保守装置からサーバに送出する第１の工程と、
該サーバから前記保守対象の装置に前記要求信号を中継する第２の工程と、
該保守対象の装置にて前記要求信号を受信し、該受信した要求信号の前記保守用の判別情報と該保守対象の装置が有する保守用の判別情報とにより判定し、該判定結果の一致に応じて該保守対象の装置に現在設定されているアドレスが設定され、かつ前記サーバのエラー応答と異なる応答信号を生成し、前記サーバに送出する第３の工程と、
該サーバから前記応答信号を前記保守装置にて受信し、該応答信号が有するアドレスを抽出する第４の工程とを含むことを特徴とするネットワークの遠隔保守方法。
【請求項２】
請求項１に記載の方法において、前記保守対象の装置は、SIP（Session Initiation Protocol）プロトコルに応じて動作することを特徴とするネットワークの遠隔保守方法。
【請求項３】
請求項１または２に記載の方法において、前記要求信号は、前記判別情報を前記SIPプロトコルに基づく記載のToヘッダフィールドに設定し、
前記応答信号は、前記保守対象の装置におけるアドレスを前記SIPプロトコルに基づく記載のContactヘッダフィールドに設定することを特徴とするネットワークの遠隔保守方法。
【請求項４】
請求項１、２または３に記載の方法において、前記判別情報は、保守用にあらかじめ設定される識別情報を用いることを特徴とするネットワークの遠隔保守方法。
【請求項５】
請求項１、２、３または４に記載の方法において、前記アドレスは、装置を特定するドメインネットワーク名を使用することを特徴とするネットワークの遠隔保守方法。
【請求項６】
ネットワークに接続された保守対象の装置を特定するアドレスが動的に変動し、該保守対象の装置における保守を遠隔的に行うネットワークの遠隔保守方法において、該方法は、
前記保守対象の装置が前記アドレスを取得した際に保守装置に対して該アドレスおよび該保守対象の装置を特定する識別情報を含む要求信号を生成し、該要求信号をサーバに送出する第１の工程と、
該サーバから前記保守装置に前記要求信号を中継する第２の工程と、
該要求信号を前記保守装置にて受信し、該要求信号から抽出した前記識別情報と該保守装置が有する前記保守対象の装置を表す内部情報とを比較し、該比較結果の一致に応じて前記要求信号に含む前記アドレスを抽出し、該アドレスを保持する第３の工程とを含むことを特徴とするネットワークの遠隔保守方法。
【請求項７】
請求項６に記載の方法において、前記保守対象の装置は、SIP（Session Initiation Protocol）プロトコルに応じて動作することを特徴とするネットワークの遠隔保守方法。
【請求項８】
請求項６または７に記載の方法において、前記要求信号は、前記識別情報を前記SIPプロトコルに基づく記載のfromヘッダフィールドに設定し、前記アドレスを前記SIPプロトコルに基づく記載のContactヘッダフィールドに設定することを特徴とするネットワークの遠隔保守方法。
【請求項９】
請求項６、７または８に記載の方法において、該方法は、前記保守対象の装置が有する時間情報に基づいて該時間情報が示す時間の経過毎に前記アドレスを前記保守装置に通知することを特徴とするネットワークの遠隔保守方法。
【請求項１０】
請求項６ないし９のいずれか一項に記載の方法において、前記アドレスは、装置を特定するドメインネットワーク名を使用することを特徴とするネットワークの遠隔保守方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの遠隔保守方法に関し、とくに、ネットワークに接続されたSIP（Session Initiation Protocol）を基に動作する装置を遠隔的に保守する方法に関するものである。
【背景技術】
【０００２】
これまでのネットワークにおける構成例を以下に記載する。このネットワークの構成は、たとえば複数のSIP装置、一つのSIPプロキシサーバおよび保守装置の構成要素とし、ネットワークに接続されている。
【０００３】
SIP装置は、この装置にSIPプロトコルに基づくプログラムを搭載しているものであり、より具体的には、SIP-VoIP（Voice over Internet Protocol）のゲートウェイ装置や電話機としてのSIPフォンがある。これらの装置のIPアドレスは、DHCP（Dynamic Host Configuration Protocol）やPPPoE（Point-to-Point Protocol over Ethernet）により動的に付与される。このようなSIP装置は、パーソナルコンピュータ接続用のローカルポートを持っている。
【０００４】
SIPのプロキシサーバは、他のクライアントに成り代わってリクエストを生成するようにサーバやクライアントの両方として動作する中間エンティティである。
【０００５】
保守装置は、SIP装置を保守する装置で、たとえば、Webソフトがインストールされたパーソナルコンピュータである。保守装置は、SIP装置のIPアドレスが動的に変化することから、SIP装置のローカルポートに保守装置を接続して、保守ソフトを起動し、保守を実施する。この場合、SIP装置がHTTPサーバとなり、Web保守を行う。
【０００６】
【非特許文献１】RFC3261 インターネット＜URL： http://www.ietf.org/rfc/rfc3261.tex＞
【非特許文献２】インターネット＜URL: http://jcp.org/aboutJava/communityprocess/final/jsr116/index.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、保守対象のSIP装置に対するIPアドレスが動的に付与されるネットワークにおいて、これらのSIP装置を遠隔的に保守する場合、保守対象のIPアドレスは不明である。保守装置は、この不明により、保守対象に接続できない。この結果、保守装置は遠隔的に保守しようとしてもできない。したがって、ネットワークに存在するSIP装置は個々に保守せざるを得ない状況にある。
【０００８】
本発明はこのような従来技術の欠点を解消し、動的にIPアドレスが付与されるネットワークにおける遠隔保守を可能にするネットワークの遠隔保守方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は上述の課題を解決するために、ネットワークに接続された保守対象の装置を特定するアドレスが動的に変動し、この保守対象の装置における保守を遠隔的に行うネットワークの遠隔保守方法において、この方法は、保守の開始時に保守用の判別情報が設定された要求信号を保守装置からサーバに送出する第１の工程と、このサーバから保守対象の装置に要求信号を中継する第２の工程と、この保守対象の装置にて要求信号を受信し、この受信した要求信号の保守用の判別情報とこの保守対象の装置が有する保守用の判別情報とにより判定し、この判定結果の一致に応じてこの保守対象の装置に現在設定されているアドレスが設定され、かつサーバのエラー応答と異なる応答信号を生成し、サーバに送出する第３の工程と、このサーバから応答信号を保守装置にて受信し、この応答信号が有するアドレスを抽出する第４の工程とを含むことを特徴とする。
【００１０】
本発明のネットワークの遠隔保守方法は、保守用の判別情報を含む要求信号を保守装置からサーバを中継して、保守対象の装置に供給し、供給された保守用の判別情報と保守対象の装置が保有する判別情報とで判定し、判定の一致か否かに応じてアドレスの取得のために供給された要求信号か否かを認識し、この取得用との判定に応じて保守対象の装置に現在設定されているアドレスを設定した応答信号を生成して、サーバに送出し、サーバにて中継された応答信号を保守装置で受信し、応答信号に含まれているアドレスを抽出することにより、常に保守対象の装置のアドレスを知ることができる。
【００１１】
また、本発明は上述の課題を解決するために、ネットワークに接続された保守対象の装置を特定するアドレスが動的に変動し、この保守対象の装置における保守を遠隔的に行うネットワークの遠隔保守方法において、この方法は、保守対象の装置がアドレスを取得した際に保守装置に対してこのアドレスおよびこの保守対象の装置を特定する識別情報を含む要求信号を生成し、この要求信号をサーバに送出する第１の工程と、このサーバから保守装置に要求信号を中継する第２の工程と、この要求信号を保守装置にて受信し、この要求信号から抽出した識別情報とこの保守装置が有する保守対象の装置を表す内部情報とを比較し、この比較結果の一致に応じて要求信号に含むアドレスを抽出し、このアドレスを保持する第３の工程とを含むことを特徴とする。
【００１２】
本発明のネットワークの遠隔保守方法は、保守対象の装置がアドレスを取得した際に、この保守対象の装置にて要求信号を生成してサーバに送出し、サーバで中継された要求信号を保守装置に供給し、保守装置で受信した要求信号から抽出した識別情報と内部情報との比較により要求信号の送信元の装置が保守対象の装置か否かを判定し、この比較結果の一致に応じて保守対象と認識し、要求信号内からアドレスを抽出し、保持することにより、保守用の判別情報が存在しない場合においても、アドレスを取得することができる。
【発明を実施するための最良の形態】
【００１３】
次に添付図面を参照して本発明によるネットワークの実施例を詳細に説明する。
【００１４】
本実施例は、本発明のネットワークをサービスネットワーク10に適用した場合である。本発明と直接関係のない部分について図示および説明を省略する。以下の説明で、信号はその現れる接続線の参照番号で指示する。
【００１５】
図２に示すサービスネットワーク10には、SIP-VoIPゲートウェイ12、SIPフォン14、SIP装置16、SIPプロキシサーバ18および保守装置20が接続されている。SIP-VoIPゲートウェイ12は、SIPとVoIPのプロトコルを相互に変換してインターフェイスを取る装置である。SIPフォン14は、たとえばSIPに基づくソフトウェアを実行させて、サービスネットワーク10を介して通話する通信機能を有する。これにより、SIPフォン14は、SIPソフトフォンとも呼ばれる。SIP装置16はSIPプロトコルに基づき設定された動作をさせる装置である。
【００１６】
上述した各装置12〜16に対するIPアドレスは、DHCPやPPPoE等により動的に付与される。また、各装置には、それぞれ装置に対するID（IDentification）が設定されている。ここで、IDはサービスネットワーク10がたとえば、VoIP電話網であれば電話番号が該当する。本実施例において、IDは、それぞれ、SIP-VoIPゲートウェイ12でID(a1)、SIPフォン14でID(a2)、SIP装置16でID(ax)が割り振られている。
【００１７】
SIPプロキシサーバ18は、他のクライアントを代理してリクエストを生成するプロキシ機能を有し、サーバおよびクライアントの両方として、動作する中間エンティティである。SIPプロキシサーバ18のIPアドレス（bbb.bbb.bbb.bbb）は固定である。
【００１８】
保守装置20は、SIP装置16を遠隔的に保守する機能を有する装置で、具体的には専用の保守コンソールソフトをインストールさせたパーソナルコンピュータである。保守装置20には、ID（c）が付与されている。
【００１９】
なお、保守用にID D(d)がある。保守ID D(d)はサービスネットワーク10において、保守対象装置のIPアドレスを取得する際に利用される特殊IDである。保守ID D(d)は、保守装置20のIDを他のSIP装置のIDと明確に区別して用意することで、保守用IDとして使用してもよい。
【００２０】
SIP-VoIPゲートウェイ12、SIPフォン14、SIP装置16および保守装置20は、装置の内部情報としてSIPプロキシサーバ18のIPアドレス（bbb.bbb.bbb.bbb）および保守用ID D(d)を図示しないメモリに保持する。これらの値はサービスネットワーク10を介して変更することができる。
【００２１】
サービスネットワーク10の各構成要素は、SIPプロキシサーバ18のIPアドレスおよび保守用IDを内部情報として有していることに特徴がある。
【００２２】
次にサービスネットワーク10における遠隔的な保守の手順について図１を参照しながら、説明する。ここで、SIP-VoIPゲートウェイ12を遠隔保守にする場合、保守装置20には何らかの方法で保守対象のIPアドレスを入手することが望まれる。本実施例では、INVITEリクエストを利用して、保守対象のIPアドレスを取得する。本実施例の保守対象は、SIP-VoIPゲートウェイ12である。
【００２３】
保守装置20は、時刻T10にてSIP-VoIPゲートウェイ12が内部に保持している装置IDとSIPプロキシサーバ18のIPアドレスを基にINVITEリクエスト30を生成し、SIPプロキシサーバ18に送信する。生成するINVITEリクエスト30は、たとえば以下に示す７行で表される。
INVITE sip:a1@bbb.bbb.bbb.bbb sip/2.0
To: <sip:d@bbb.bbb.bbb.bbb>
From: “c”<sip:c@ccc.ccc.ccc.ccc>;tag=xxxxxxxx（任意）
Call-ID: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy（任意）
CSeq: 1 INVITE
Contact: <sip:ccc.ccc.ccc.ccc>
Content-Length: 0
ここで、INVITEリクエスト30は、SIPプロトコルで許容されるならば、上述した記載に限定されない。すなわちこれらの記載以外にヘッダを付与してもよいし、記述方法が異なっても構わない。INVITEリクエスト30は、INVITEリクエストの形式を満たし、かつToヘッダに保守用ID D(d)が設定されることが記載条件である。
【００２４】
SIPプロキシサーバ18は、INVITEリクエスト30が有するRequest-URI（Uniform Resource Identifiers）に従い、該当する装置にINVITEリクエストを中継する。このとき、Toヘッダは参照されない。INVETEリクエスト30における第１行目のRequest-URIには装置ID(a1)が指定されている。SIPプロキシサーバ18は、この指定に基づきSIP-VoIPゲートウェイ12にINVITEリクエスト32を時刻T12にて送信する。この送信により、SIPプロキシサーバ18は、INVITEリクエスト30をINVITEリクエスト32として中継する。また、SIPプロキシサーバ18は中継においてToヘッダの内容を変更せず、Toヘッダの内容がSIP-VoIPゲートウェイ12まで保証される。
【００２５】
さらに、SIPプロキシサーバ18は、受信したINVITEリクエスト30に対する応答として、時刻T14にて保守装置20に暫定応答である100応答34を返している。
【００２６】
SIP-VoIPゲートウェイ12がINVITEリクエスト32を受信すると、SIP-VoIPゲートウェイ12は時刻T16にてINVITEリクエスト32の受信に対する100応答36をSIPプロキシサーバ18に出力してもよい。
【００２７】
また、SIP-VoIPゲートウェイ12は、INVITEリクエスト32の受信に応じて受信したINVITEリクエスト32内のToヘッダの内容を確認する。第２行目のToヘッダには、設定された装置IDが格納されている。SIP-VoIPゲートウェイ12は、Toヘッダの装置ID（<sip:d@bbb.bbb.bbb.bbb>の内、情報d）とSIP-VoIPゲートウェイ12に保持する内部情報、すなわち保守用ID D(d)とが一致するか否かを判定する。SIP-VoIPゲートウェイ12は、判定結果の一致を確認された場合、INVITEリクエスト32が保守装置20のIPアドレスを取得するリクエストであると認識する。
【００２８】
この認識後、SIP-VoIPゲートウェイ12はINVITEリクエスト32に対して1xx応答（暫定応答）および2xx応答（成功応答）以外の後述するエラー応答38を時刻T18にてSIPプロキシサーバに返す。
【００２９】
エラー応答38はサービスネットワーク10においてしかるべき値を設定しておくことが望ましい。これは、実際の処理を保守装置20が行うため、どの値を選択するかは保守対象の装置、本実施例のSIP-VoIPゲートウェイ12と保守装置20との間の取決めに依るからである。ただし、取決めの値は、SIPプロキシサーバ18のサーバ自身が送出するエラー応答と区別することから、「380 Alternative Service」等を使用することが好ましい。
【００３０】
SIP-VoIPゲートウェイ12は、上述した内容とともに、Contactヘッダを設定したエラー応答38を送出する。Contactヘッダには、エラー応答38を生成した装置のIPアドレス（aaa,aaa,aaa,aaa）が設定される。
【００３１】
なお、3xx応答および4xx応答において、Contactヘッダはオプションであり、通常は設定されない。
【００３２】
次に生成されるエラー応答38の具体例である380応答を以下に示す。
sip/2.0 380 Alternative Service
To: <sip:d@bbb.bbb.bbb.bbb>
From: “a1”<sip:a1@ccc.ccc.ccc.ccc.>;tag=xxxxxxxx
Call-ID: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
CSeq: 1 INVITE
Contact: <sip:aaa.aaa.aaa.aaa>
ここで、エラー応答38はエラー応答の形式を満たし、かつContactヘッダが付与されていることが条件であるが、上述した形式に限定されない。
【００３３】
送出されたエラー応答38は、時刻T20にてSIPプロキシサーバ18から保守装置20にエラー応答40として中継される。保守装置40は、エラー応答40を受信し、受信したエラー応答40内のContactヘッダを抽出し、SIP-VoIPゲートウェイ12のIPアドレス（aaa.aaa.aaa.aaa）を入手する。
【００３４】
また、保守装置20は、SIPプロキシサーバ18にACKリクエスト42を時刻T22にて送出する。SIPプロキシサーバ18は、受信したACKリクエスト42をACKリクエスト44として中継し、時刻T24にてSIP-VoIPゲートウェイ12に送出する。SIP-VoIPゲートウェイ12がACKリクエスト44を受信して、時刻T10にてINVITEリクエスト30により発生したINVITEセッションが終了する。
【００３５】
これ以降、保守装置20は取得したSIP-VoIPゲートウェイ12のIPアドレス（aaa.aaa.aaa.aaa）に基づいてSIP-VoIPゲートウェイ12を直接アクセスすることができ、遠隔保守を行う。また、遠隔保守を一旦終了し、再び遠隔保守を行う場合は、INVITEリクエスト30の送出から一連の手順を実施し、現状における保守対象のIPアドレスを取得する。
【００３６】
なお、図３に示すようにDNS（Domain Name System）サーバ22が存在するサービスネットワーク10において、SIPプロキシサーバ18に付されているドメイン名をIPアドレスに対応する情報として使用し、保守対象の装置が有するIPアドレスまたはドメイン名を保守装置20が取得するようにしてもよい。このドメイン名の利用は、後述する図４の動作においても有効であることは明らかである。
【００３７】
要約すると、このように動的にIPアドレスが変化することにより、保守装置20が遠隔の保守対象装置のIPアドレスをあらかじめ取得できないネットワークであっても、INVITEリクエスト30を利用し、保守対象に提供されたINVITEリクエストがIPアドレス要求か否かを認識し、この認識の一致に応じてエラー応答38を生成し、保守装置20に供給されたエラー応答40のContactヘッダフィールドから保守対象装置のIPアドレスを取得することができる。これにより、動的にIPアドレスを付与されるネットワークでも保守装置から遠隔的に保守することができる。
【００３８】
次に本発明のネットワークを適用したサービスネットワーク10の他の実施例について説明する。本実施例における基本的な構成は図２に示したサービスネットワーク10と同じである。ただし、本実施例のサービスネットワーク10には、内部情報として前述した保守用IDが存在しない。したがって、本実施例のSIP-VoIPゲートウェイ12、SIPフォン14およびSIP装置16は内部情報としてSIPプロキシサーバ18のIPアドレス（bbb.bbb.bbb.bbb）と保守装置20のID(c)を保持することに特徴がある。
【００３９】
本実施例でも先の実施例と同様に保守装置20は、SIP-VoIP装置12を保守対象とし、遠隔的に保守する。この遠隔保守の実現にあたり保守対象のIPアドレスを取得する手順を以下に示す図４のシーケンシャルチャートを参照しながら説明する。
【００４０】
まず、SIP-VoIPゲートウェイ12は、IPアドレスを付与されると、装置内部に保持している保守装置20のIDおよびSIPプロキシサーバアドレスから、以下の7行で示す内容のINVITEリクエスト50を生成し、時刻T30にてSIPプロキシサーバ18に送信する。本実施例は、保守対象の装置がINVITEリクエスト50を生成し、出力することに特徴がある。
【００４１】
生成したINVITEリクエスト50は、具体的に、
INVITE sip:c@bbb.bbb.bbb.bbb sip/2.0
To: <sip:c@bbb.bbb.bbb.bbb>
From: “a1”<sip:al@aaa.aaa.aaa.aaa>;tag=xxxxxxxx
Call-ID: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
CSeq: 1 INVITE
Contact: <sip:aaa.aaa.aaa.aaa>
Contact-Length: 0
と記載される。このINVITEリクエストは保守装置20に対するINVITEリクエストである。
【００４２】
ここで、SIPプロトコルで許容されるならば、上述した記載以外のヘッダを付与してもよいし、記述方法も限定されない。INVITEリクエスト50は、INVITEリクエストの形式を満たし、かつ保守対象のIPアドレスが設定されたContactヘッダフィールドが付与されていることが記載の条件である。
【００４３】
SIPプロキシサーバ18は、INVITEリクエスト50のRequest-URIに従い、該当する装置、すなわち保守装置20にINVITEリクエストを中継する。この中継でToヘッダは参照されない。INVITEリクエスト52のRequest-URIにはINVITEリクエスト50ですでに保守装置20の装置Id(c)が指定されている。したがって、SIPプロキシサーバ18は、この指定により保守装置20にINVITEリクエスト50をINVITEリクエスト52として時刻T32にて送信する。また、SIPプロキシサーバ18は、INVITEリクエスト50の受信に応じて時刻T34にて暫定応答を示す100応答54をSIP-VoIPゲートウェイ12に送信する。
【００４４】
保守装置20は、INVITEリクエスト52を受信して、受信したINVITEリクエスト52における第３行目のFromヘッダフィールドから、このINVITEリクエスト52を生成したSIP-VoIPゲートウェイ12の装置ID、すなわち「a1」を抽出する。保守装置20は、抽出した装置ID(a1)と保守装置20内部で保持されている保守対象の装置IDとを比較し、INVITEリクエスト50を生成した装置が保守対象の装置か否かを比較判定する。この比較判定結果が一致している場合、本実施例の保守対象、SIP-VoIPゲートウェイ12であると認識する。保守装置20は、さらに、第６行目のContactヘッダフィールドに記載されているIPアドレスを抽出し、SIP-VoIPゲートウェイ12のIPアドレスとして格納する。このIPアドレスは、保守装置20に現在の保守対象に関する内部情報として保持される。
【００４５】
保守装置20は、供給されたINVITEリクエスト52に対する100応答56を時刻T36にSIPプロキシサーバ18に出力してもよい。保守装置20は、1xx応答および2xx応答以外のエラー応答58を時刻T38にてSIPプロキシサーバ18に返す。エラー応答58は先の実施例の場合と同様にサービスネットワーク10においてしかるべき値を設定することが望ましい。選択する値は、保守対象のSIP装置と保守装置20と間の取決めとなる。ただし、SIPプロキシサーバ18のサーバ自身が送出するエラー応答と区別する必要性から、「380 Alternative Service」等を使用することが好ましい。エラー応答58は、SIPプロトコルにおいてINVITEリクエスト50が保守装置20に供給されたか否かを確認する上でINVITEリクエスト50の送信元の装置に返す応答信号である。
【００４６】
送出されたエラー応答58はSIPプロキシサーバ18が受信する。SIPプロキシサーバ18は、時刻T40にてエラー応答58をエラー応答60としてSIP-VoIPゲートウェイ12に送信して、中継する。
【００４７】
SIP-VoIPゲートウェイ12は、エラー応答60を受信し、この受信に応じてSIPプロキシサーバ18にACK（ACKnowledge）リクエスト62を時刻T42にて送出する。さらに、ACKリクエスト62はSIPプロキシサーバ18から時刻T44にて保守装置20にACKリクエスト64として中継され、送信される。保守装置20は、中継されたACKリクエスト64を受信してINVITEリクエスト50により発生したINVITEセッションが終了する。
【００４８】
以降、保守装置20はSIP-VoIPゲートウェイ12のIPアドレス（aaa.aaa.aaa.aaa）が得られたことにより、直接この保守対象にアクセスすることができ、遠隔的に保守することができる。
【００４９】
本実施例においても、保守対象のSIP装置がIPアドレスを付与される度に上述した一連のINVITEセッションを実施することで、保守装置20は現時点における保守対象のSIP装置が有するIPアドレスを認識することができる。
【００５０】
また、保守対象のSIP装置内部に更新時間情報Ｆを保持し、本実施例によるIPアドレス取得通知から更新時間情報Ｆの時間が経過する度に、再びIPアドレス通知処理を行う。これにより、サービスネットワーク10における保守対象のSIP装置は、たとえばパケット落ち等でIPアドレス通知が正常に行われなかった場合の対処としてこのIPアドレス通知処理を使用してもよい。とくに、エラー応答がSIPプロキシサーバ18および保守装置20のいずれによるものか明確に判断できない可能性がある場合にこの処理は、有効である。
【００５１】
このように動作させて、動的にIPアドレスが変化して、保守装置20が遠隔の保守対象装置のIPアドレスをあらかじめ取得できないネットワークであり、かつ保守対象の装置に保守用のIDがなくても、保守対象の装置からINVITEリクエスト50を発生させ、保守装置20にてINVITEリクエスト50の送信元が保守対象装置であるか否かを認識し、一致した認識に応じて供給されたINVITEリクエスト52のContactヘッダフィールドから保守対象装置のIPアドレスを抽出して、IPアドレスを取得することができる。これにより、保守用のIDを持たずに、動的に、IPアドレスが付与されるサービスネットワーク10でも、確実に、保守装置20から遠隔的に保守することができる。
【００５２】
以上のように構成することにより、保守用の判別情報を含むINVITE要求30を保守装置20からSIPプロキシサーバ18を中継して、INVITE要求32としてSIP-VoIPゲートウェイ12に供給し、供給された保守用の判別情報と保守対象の装置が保有する判別情報とで判定し、判定の一致か否かに応じてアドレスの取得のために供給されたINVITE要求か否かを認識し、この取得用との判定に応じてSIP-VoIPゲートウェイ12に現在設定されているアドレスを設定したエラー応答38を生成し、SIPプロキシサーバ18に送出し、SIPプロキシサーバ18にて中継されたエラー応答40を保守装置20で受信し、エラー応答40に含まれているアドレスを抽出することにより、常に保守対象の装置のアドレスを知ることができる。このように保守対象の装置のアドレスを知ることができるから、保守装置20は保守対象の装置を確実に保守することができる。
【００５３】
保守対象の装置は、SIPプロトコルに応じて動作することにより、判別情報およびアドレスをそれぞれのフィールドまたは領域に書き込むように規定することができ、各情報の取得を確実に行うことができる。より具体的に、INVITE要求30は、判別情報をToヘッダフィールドに書き込み、エラー応答38は、保守対象の装置であるSIP-VoIPゲートウェイ12におけるアドレスをContactヘッダフィールドに書き込んでいる。また、判別情報は、保守用にあらかじめ設定される識別情報を用いることが好ましい。さらに、アドレスは、IPアドレスに限定されるものでなく、ドメインネットワーク名を使用してもよい。
【００５４】
また、サービスネットワーク10における遠隔保守方法において、保守用の判別情報を持たない場合に、保守対象のSIP-VoIPゲートウェイ12がアドレスを取得した際に、SIP-VoIPゲートウェイ12にてINVITE要求50を生成してSIPプロキシサーバ18に送出し、SIPプロキシサーバ18で中継されたINVITE要求52を保守装置20に供給し、保守装置20で受信したINVITE要求52から抽出した識別情報と内部情報との比較によりINVITE要求50の送信元であるSIP-VoIPゲートウェイ12が保守対象の装置か否かを判定し、この比較結果の一致に応じて保守対象と認識し、受信したINVITE要求52内からアドレスを抽出し、保持することにより、保守用の判別情報を用いなくても、動的に変動するアドレスを正確に取得することができる。このアドレス取得により、保守装置20は保守対象の装置を確実に保守することができる。
【００５５】
保守対象の装置は、SIPプロトコルに応じて動作することにより、判別情報およびアドレスをそれぞれのフィールドまたは領域に書き込むように規定することができ、各情報の取得を確実に行うことができる。より具体的に、INVITE要求50は、識別情報をfromヘッダフィールドに書き込み、SIP-VoIPゲートウェイ12におけるアドレスをContactヘッダフィールドに書き込むことが望ましい。
【００５６】
保守対象の装置は、保守対象の装置が有する時間情報に基づいてこの時間情報が示す時間の経過毎にアドレスを保守装置20に通知することにより、SIPプロキシサーバ18のエラーやネットワーク10のパケット落ち等でIPアドレス通知が正常に行われなかった場合にも、一定時間が経過すれば保守装置20が保守対象のSIP装置におけるIPアドレスを取得することができることから、動的にIPアドレスが変化するネットワーク10においても、保守装置20が常に保守対象のSIP装置のIPアドレスを取得できる点で有利である。
【００５７】
また、この方法では、アドレスとしての利用はIPアドレスに限定されず、ドメインネットワーク名を使用してもよい。
【産業上の利用可能性】
【００５８】
前述した実施例では、いずれも保守対象の装置をSIP-VoIPゲートウェイ12としたが、ゲートウェイ12に限定されるものでなく、保守対象の装置はSIP装置であればよく、具体的には図２のSIPフォン14等であってもよい。
【図面の簡単な説明】
【００５９】
【図１】本発明に係るネットワークの遠隔保守方法をサービスネットワークに適用したINVITEセッションの動作を説明するシーケンシャルチャートである。
【図２】図１の動作を適用するサービスネットワークにおける概略的な構成を示す図である。
【図３】図１のサービスネットワークにDNSサーバを新たに接続させた構成を示す図である。
【図４】図１のサービスネットワークにおいて保守用のIDがない場合に行われるINVITEセッションの動作を説明するシーケンシャルチャートである。
【符号の説明】
【００６０】
10  サービスネットワーク
12  SIP-VoIPゲートウェイ
14  SIPフォン
16  SIP装置
18  SIPプロキシサーバ
20  保守装置
【図１】
2005244306.tif 000003
【図２】
2005244306.tif 000004
【図３】
2005244306.tif 000005
【図４】
2005244306.tif 000006