(57)【特許請求の範囲】
【請求項１】
ＳＩＰによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、
前記現用系装置により、
通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにＵＡによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップと、
更新された前記救済情報に基づいて、その状態遷移通知を前記予備系装置に送信するステップと、を有し、
前記予備系装置により、
前記現用系装置から前記状態遷移通知が送信される毎に、当該状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存するステップと、
前記接続断により前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に基づいて、前記予備系救済データ管理に保存された前記救済情報を用いてダイアログデータを生成し、前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、
を有することを特徴とするダイアログ救済方法。
【請求項２】
ＳＩＰによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、
前記現用系装置により、
通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにＵＡによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップを有し、
前記予備系装置により、
前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存し、前記状態遷移通知に基づいてダイアログデータを生成するステップと、
前記ダイアログデータが生成された後に前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、
を有することを特徴とするダイアログ救済方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰによるネットワークを介した通信中に生じる意図しない切断においてダイアログを救済するためのダイアログ救済方法に関する。
【背景技術】
【０００２】
従来において、ＩＳＤＮ回線における通話中において、常用系交換機のシステムダウンによる接続の切断についてダイアログを救済するためのダイアログ救済が行われている。このダイアログ救済方法として、通話スイッチと制御装置および他の装置からなる交換機に関し、通話パスを保存したまま制御装置のデータおよび他の装置を初期化することが行われている。
【０００３】
その構成として、制御装置内にハードウェア初期設定手段とデータ初期設定手段と救済パス判定手段と非救済初期設定手段とを設け、制御装置内の通話パスに関する全てのデータ（前記のコールデータも含む）を初期設定し、しかしながら通話スイッチ装置は初期設定せずに状態をそのまま保存する（特許文献１参照）。
【特許文献１】特開平７−２２１８４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のダイアログ救済方法においては、ＳＩＰ（Session Initiation Protocol）特有の救済タイミングは考慮されておらず、システム再開／切替方式毎に異なる救済方式であり、効率の良いダイアログ救済方法とは決して言えなかった。
【０００５】
本発明の目的は、上記に鑑みてなされたものであり、ＳＩＰ通信システムの再開／切替時における通信中セッション救済が効率的に構築可能なダイアログ救済方法を提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために請求項１に記載の本発明は、ＳＩＰによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、前記現用系装置により、通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにＵＡによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップと、更新された前記救済情報に基づいて、その状態遷移通知を前記予備系装置に送信するステップと、を有し、前記予備系装置により、前記現用系装置から前記状態遷移通知が送信される毎に、当該状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存するステップと、前記接続断により前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に基づいて、前記予備系救済データ管理に保存された前記救済情報を用いてダイアログデータを生成し、前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、を有する。
【０００７】
また、請求項２に記載の本発明は、ＳＩＰによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、前記現用系装置により、通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにＵＡによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップを有し、前記予備系装置により、前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存し、前記状態遷移通知に基づいてダイアログデータを生成するステップと、前記ダイアログデータが生成された後に前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、を有する。
【発明の効果】
【０００８】
本発明によれば、ＳＩＰ通信システムの再開／切替時における通信中セッション救済が効率的に構築可能なダイアログ救済方法を提供できる。
【発明を実施するための最良の形態】
【０００９】
図１には、本発明のダイアログ救済方法における処理を説明するための概要図を示す。
【００１０】
この図１は、ＳＩＰ（Session Initiation Protocol）スタックにおけるダイアログ救済処理において、救済データ復元方式についての処理の概要を示しており、図１（ａ）は処理フローの概要を示し、図１（ｂ）はＳＩＰスタックの構成を示している。
【００１１】
まず、図１（ａ）に示すように、スタックインスタンスの生成が行われる（Ｓ１）。次に、上位より救済データが設定され、次に救済データオブジェクトが生成され、そしてダイアログオブジェクトの生成が実行され、このステップを繰り返す（Ｓ２）。これにより実データまでの復旧が行われる。
【００１２】
次に、ダイアログオブジェクトをＵＡに登録する。ここで同期処理として全データを登録してリターンする（Ｓ３）。ここまでのＳ１〜Ｓ３は初期状態である。そしてサービス開始状態に移行し、起動状態となる（Ｓ４）。
【００１３】
次に、このＳ１〜Ｓ４の処理をＳＩＰスタックの構成図を参照して説明する。図１（ｂ）において、救済データ管理２と、ＳＩＰスタック１１と、ＵＡ３が示されている。Ｓ５において救済データ管理２には救済データとダイアログデータが保管されている。一方、ＵＡ３には何も保管されていない。この状態は図１（ａ）におけるＳ２の状態に該当する。
【００１４】
次に、Ｓ６において救済データ管理２からＵＡ３へダイアログデータが移動する。この状態は図１（ａ）におけるＳ３の状態に該当する。
【００１５】
そしてＳ７において、ＵＡ３にはダイアログデータが格納され、起動状態となる。この状態は図１（ａ）におけるＳ４の状態に該当している。
【００１６】
図２には、本発明のダイアログ救済方法における救済データの取得処理を説明するためのシーケンス図を示す。
【００１７】
この図２には、ＡＰＬ１と、救済データ管理２と、ＵＡ３と、トランスポート４が示されている。まず、ＡＰＬ１からＵＡ３へメッセージ送信（ＡＣＫ）が行われる（Ｓ１０）。ＵＡ３はトランスポート４メッセージ送信（ＡＣＫ）を行う（Ｓ１１）。トランスポート４は図示しないネットワークに接続している（Ｓ１８）。ＵＡ３はトランスポート４を介してネットワークから救済情報を取得する（Ｓ１２）。
【００１８】
次に、ＵＡ３と救済データ管理２の間で救済情報の保存が実行される（Ｓ１３、Ｓ１４）。これにより救済データ管理２における救済データが更新される。ＵＡ３からはＡＰＬ１へ状態遷移通知が送信され（Ｓ１５）、救済データ管理２はＡＰＬ１から通話時間や累計通話時間を取得するためのＧｅｔＣａｌｌＩｎｆｏに要する通信を行う（Ｓ１６、Ｓ１７）。
【００１９】
図３には、本発明のダイアログ救済方法におけるダイアログ救済処理を説明するためのシーケンス図を示す。
【００２０】
この図３には、ＡＰＬ１と、救済データ管理２と、ＵＡ３と、トランスポート４が示されている。
【００２１】
まず、ＡＰＬ１と救済データ管理２の間でスタックインスタンスの生成が行われている（new、Ｓ２０）。次に、ＡＰＬ１と救済データ管理２との間で救済データ・ダイアログインデックスを生成する（Ｓ２２、Ｓ２３）。この生成は図１中のＳ２に該当する。
【００２２】
次に、ＡＰＬ１から救済データ管理２へＣｏｍｍｉｔＣａｌｌＩｎｆｏが発せられ（Ｓ２４、Ｓ２５）、救済データ管理２からはＵＡ３へダイアログインスタンス登録が実行処理されて、ＵＡ３にダイアログインスタンスが登録される（Ｓ２６、Ｓ２７）。
【００２３】
そしてＡＰＬ１と救済データ管理２間でＳｔａｒｔが通信され起動状態となり、サービスが開始される（Ｓ２８、Ｓ２９）。サービス開始によりＡＰＬ１からはＵＡ３に対しＧｅｔＥｖｅｎｔが要求され（Ｓ３０）、ＵＡ３はトランスポート４を介して図示しないネットワークからメッセージ受信をする（Ｓ３３、Ｓ３２、Ｓ３１）。
【００２４】
図４には、本発明のダイアログ救済方法におけるホットスタンバイ方式を説明するためのシーケンス図を示す。
【００２５】
この図４には、ＡＰＬ（ＡＣＴ）５と、ＳＴＡＣＫ（ＡＣＴ）６と、クラスタ７と、ＳＴＡＣＫ（ＳＴＢ）８と、ＡＰＬ（ＡＣＴ）９が示されている。ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６は、クラスタ７を介して、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８に接続して通信を行っている。なお、クラスタ７はクラスタ構成を実現するためのクラスタサーバである。
【００２６】
まず、ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６の間でスタックインスタンスの生成が行われている（new、Ｓ４０、Ｓ４１）。次に、両者間でＳｔａｒｔが通信されて起動状態になる（Ｓ４２、Ｓ４３）。
【００２７】
次に、ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６の間でＧｅｔＣａｌｌＩｎｆｏが繰り返される（Ｓ４４〜Ｓ４６）。これによる状態遷移通信（Ｓ６０、Ｓ６１）によりＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間でＳｅｔＣａｌｌＩｎｆｏが繰り返される（Ｓ５０〜Ｓ５３）。
【００２８】
そして、ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６の間でＧｅｔＣａｌｌＩｎｆｏ（Ｓ４８、Ｓ４９）が機器のダウンなどにより切断するとダイアログがＳＴＡＣＫ（ＡＣＴ）６にて消滅する。このときの状態遷移通信Ｓ６２により、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間ではＤｅｌｅｔｅＣａｌｌＩｎｆｏが実行され（Ｓ５４、Ｓ５５）、ＳＴＡＣＫ（ＳＴＢ）８でのダイアログも消滅する。
【００２９】
その後、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間でＣｏｍｍｉｔＣａｌｌＩｎｆｏが実行されて（Ｓ５６、Ｓ５７）、ダイアログオブジェクトがＵＡ３に登録される。このＳ５６とＳ５７の処理時間がダウンタイムＤとなり、このダウンタイムＤが通信切断時間となる。このダウンタイムＤが経過した後に、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間でＳｔａｒｔが通信されて起動状態になる（Ｓ５８、Ｓ５９）。
【００３０】
以上の処理方式をホットスタンバイ方式と呼び、システムの稼動に対して比較的に負荷が多くなる。しかしながら、通信が切断されている時間のダウンタイムＤは比較低に短いので、このダウンタイムＤが短いものが要求される用途の通信システムに適用することが好ましい。
【００３１】
図５には、本発明のダイアログ救済方法におけるコールドスタンバイ方式を説明するためのシーケンス図を示す。
【００３２】
この図５には、ＡＰＬ（ＡＣＴ）５と、ＳＴＡＣＫ（ＡＣＴ）６と、クラスタ７と、ＳＴＡＣＫ（ＳＴＢ）８と、ＡＰＬ（ＡＣＴ）９が示されている。ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６は、クラスタ７を介して、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８に接続して通信を行っている。なお、クラスタ７はクラスタ構成を実現するためのクラスタサーバである。
【００３３】
まず、ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６の間でスタックインスタンスの生成が行われている（new、Ｓ７０、Ｓ７１）。次に、両者間でＳｔａｒｔが通信されて起動状態になる（Ｓ７２、Ｓ７３）。
【００３４】
次に、ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６の間でＧｅｔＣａｌｌＩｎｆｏが繰り返される（Ｓ７４〜Ｓ７７）。
【００３５】
そして、ＡＰＬ（ＡＣＴ）５とＳＴＡＣＫ（ＡＣＴ）６の間でＧｅｔＣａｌｌＩｎｆｏ（Ｓ７８、Ｓ７９）が機器のダウンなどにより切断するとダイアログがＳＴＡＣＫ（ＡＣＴ）６にて消滅する。このときの状態遷移通信Ｓ８０により、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間ではＳｅｔＣａｌｌＩｎｆｏが繰り返し実行され（Ｓ８１〜Ｓ８４）、ＳＴＡＣＫ（ＳＴＢ）８にダイアログが生成される。
【００３６】
その後、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間でＣｏｍｍｉｔＣａｌｌＩｎｆｏが実行されて（Ｓ８５、Ｓ８６）、ダイアログオブジェクトがＵＡ３に登録される。この図５に示した処理の場合、Ｓ８１〜Ｓ８６までの処理時間がダウンタイムＤＤとなり、このダウンタイムＤＤが通信切断時間となる。このダウンタイムＤＤが経過した後に、ＡＰＬ（ＡＣＴ）９とＳＴＡＣＫ（ＳＴＢ）８の間でＳｔａｒｔが通信されて起動状態になる（Ｓ８７、Ｓ８８）。
【００３７】
以上の処理方式をコールドスタンバイ方式と呼び、システムの稼動に対して負荷を少なくすることができる。ただし通信が切断されている時間のダウンタイムＤＤが比較的に長いので、このダウンタイムＤＤを許容可能な通信システムに適用することが好ましい。
【００３８】
図６には、本発明のダイアログ救済方法における救済データ更新契機（ＵＡＣ）を説明するためのシーケンス図を示す。
【００３９】
この図６には、救済ＤＢ１０と、ＡＰＬ１と、ＳＩＰスタック１１と、対向１２が示されている。対向１２はクラスタ７などを介して接続されたＡＰＬやＳＩＰスタックによる構成を示している。
【００４０】
まず、ＡＰＬ１とＳＩＰスタック１１と対向１２との間で通信が行われている（Ｓ９０〜Ｓ９４、Ｓ１１０〜Ｓ１１４）。ここでＡＰＬ１から確認応答のためにＡＣＫがＳＩＰスタック１１を介して対向１２へ送信されると（Ｓ９４、Ｓ１１４）、ＳＩＰスタック１１からＡＰＬ１へ状態遷移通知（Ｓ９５）が送信される。ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ９６）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ９７）。ＡＰＬ１は救済データを救済ＤＢ１０へ書き込みする（Ｓ１２１）。
【００４１】
また、ＡＰＬ１からセッションの変更を要求するためのre-INVITEがＳＩＰスタック１１を介して対向１２へ送信され（Ｓ９８、Ｓ１１５）、ＳＩＰスタック１１からはＡＰＬ１へ状態遷移通知が送信される（Ｓ９９）。ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ１００）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ１０１）。ＡＰＬ１は救済データを救済ＤＢ１０へ書き込みする（Ｓ１２２）。
【００４２】
また、対向１２から暫定応答として１００ＴｒｙｉｎｇがＳＩＰスタック１１を介してＡＰＬ１へ送信される（Ｓ１１６、Ｓ１０２）。さらに対向１２からＳＩＰスタック１１を介して２００ＯＫの応答がＡＰＬ１へ送信される（Ｓ１１７、Ｓ１０３）。その後、ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ１０４）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ１０５）。ＡＰＬ１は救済データを救済ＤＢ１０へ書き込みする（Ｓ１２３）。
【００４３】
また、ＡＰＬ１からはＳＩＰスタック１１を介して対向１２へ確認応答のためにＡＣＫを送信する（Ｓ１０６、Ｓ１１８）。そしてＡＰＬ１からはＳＩＰスタック１１を介して通信終了のためにＢＹＥが送信される（Ｓ１０７、Ｓ１１９）。ここで、ＳＩＰスタック１１からＡＰＬ１へ状態遷移通知が送信されると（Ｓ１０８）、救済ＤＢ１０内の救済データは削除される（Ｓ１２４）。そして、対向１２からは２００ＯＫの応答がＳＩＰスタック１１を介してＡＰＬ１へ送信される（Ｓ１２０、Ｓ１０９）。
【００４４】
図７には、本発明のダイアログ救済方法における救済データ更新契機（ＵＡＳ）を説明するためのシーケンス図を示す。
【００４５】
この図７には、救済ＤＢ１０と、ＡＰＬ１と、ＳＩＰスタック１１と、対向１２が示されている。対向１２はクラスタ７などを介して接続されたＡＰＬやＳＩＰスタックによる構成を示している。
【００４６】
まず、ＡＰＬ１とＳＩＰスタック１１と対向１２との間で通信が行われている（Ｓ１３０〜Ｓ１３３、Ｓ１４８〜Ｓ１５２）。ここで対向１２から確認応答のためにＡＣＫがＳＩＰスタック１１を介してＡＰＬ１へ送信されると（Ｓ１５２、Ｓ１３３）、ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ１３４）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ１３５）。ＡＰＬ１は救済データを救済ＤＢ１０へ書き込みする（Ｓ１５９）。
【００４７】
また、対向１２からセッションの変更を要求するためのre-INVITEがＳＩＰスタック１１を介してＡＰＬ１へ送信され（Ｓ１５３、Ｓ１３６）、ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ１３７）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ１３８）。ＡＰＬ１は救済データを救済ＤＢ１０へ書き込みする（Ｓ１６０）。
【００４８】
また、ＡＰＬ１からＳＩＰスタック１１を介して２００ＯＫの応答が対向１２へ送信される（Ｓ１３９、Ｓ１５５）。ＳＩＰスタック１１からはＡＰＬ１へ状態遷移通知が送信される（Ｓ１４０）。その後、ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ１４１）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ１４２）。ＡＰＬ１は救済データを救済ＤＢ１０へ書き込みする（Ｓ１６１）。
【００４９】
また、対向１２からはＳＩＰスタック１１を介してＡＰＬ１へ確認応答のためにＡＣＫを送信する（Ｓ１５６、Ｓ１４３）。そして対向１２からはＳＩＰスタック１１を介して通信終了のためにＢＹＥがＡＰＬ１へ送信される（Ｓ１５７、Ｓ１４４）。ここで、ＡＰＬ１はＳＩＰスタック１１に対して救済データ取得を要求し（Ｓ１４５）、ＳＩＰスタック１１はＡＰＬ１へ救済データを送信する（Ｓ１４６）。ＡＰＬ１は該当する救済データを救済ＤＢ１０から削除する（Ｓ１６２）。そして、ＡＰＬ１からは２００ＯＫの応答がＳＩＰスタック１１を介して対向１２へ送信される（Ｓ１４７、Ｓ１５８）。
【００５０】
なお、この図１〜図７を参照して説明した実施の形態においては、救済対象は確立済みセッションとし、トランザクション救済は行わない。また、救済データの更新契機は、セッション確立後、ダイアログ内リクエスト送受信後、ターゲットリフレッシュリクエストの２ｘｘ応答の送受信後としている。救済方法は、フォアグランド救済のみとして、救済データは初期状態にて上位から全て設定される。また、ダウンタイムを短縮したい場合には、ホットスタンバイ方式にて上位で実装する。
【００５１】
このように本実施の形態によれば、ＳＩＰ通信システムの装置異常等によるシステム再開／切替において、通信中のセッションが切断されないためのダイアログ毎のダイアログ状態保持及び復元について、システム再開／切替時の切替方式に応じ汎用的に利用可能なダイアログ救済方法を実現することができる。
【００５２】
また、本実施の形態によれば、ＳＩＰ通信システムの再開／切替時における通信中セッション救済が効率的に構築可能なダイアログ救済方法を提供することができる。
【図面の簡単な説明】
【００５３】
【図１】本発明のダイアログ救済方法における処理を説明するための概要図を示す。
【図２】本発明のダイアログ救済方法における救済データの取得処理を説明するためのシーケンス図を示す。
【図３】本発明のダイアログ救済方法におけるダイアログ救済処理を説明するためのシーケンス図を示す。
【図４】本発明のダイアログ救済方法におけるホットスタンバイ方式を説明するためのシーケンス図を示す。
【図５】本発明のダイアログ救済方法におけるコールドスタンバイ方式を説明するためのシーケンス図を示す。
【図６】本発明のダイアログ救済方法における救済データ更新契機（ＵＡＣ）を説明するためのシーケンス図を示す。
【図７】本発明のダイアログ救済方法における救済データ更新契機（ＵＡＳ）を説明するためのシーケンス図を示す。
【符号の説明】
【００５４】
１…ＡＰＬ
２…救済データ管理
３…ＵＡ
４…トランスポート
５、９…ＡＰＬ（ＡＣＴ）
６…ＳＴＡＣＫ（ＡＣＴ）
７…クラスタ
８…ＳＴＡＣＫ（ＳＴＢ）
９…ＰＳＴＮ網
１０…救済ＤＢ
１１…ＳＩＰスタック
１２…対向
【図１】
0004800270.tif 000002
【図２】
0004800270.tif 000003
【図３】
0004800270.tif 000004
【図４】
0004800270.tif 000005
【図５】
0004800270.tif 000006
【図６】
0004800270.tif 000007
【図７】
0004800270.tif 000008