JP2007189610A - Ｓｉｐプロトコルにおいて実装の差分が存在するアプリケーションの相互接続に対応する方法 - Google Patents

Abstract

【課題】キャプチャリングデータの解析及び検証が短時間且つ容易に行え、実装の差分を容易に発見可能とすること。
【解決手段】登録エンジン１６は、入力インタフェース１４より供給された通信メッセージを解析して変換のルールを決定し、ＤＢマネージャ２２内に設けられた複数のＤＢに登録を行う。登録エンジンは、予め、登録モードか変換モードかのモード設定を行っておき、入力インタフェースより通信メッセージが供給された際、登録モード時には、前述のＤＢへ変換ルールの登録を行い通信メッセージを変換エンジン１８に供給し、変換モード時には何も行わず、通信メッセージを変換エンジンに供給する。変換エンジンは、通信メッセージに対して該当する変換ルールが無いかＤＢマネージャでＤＢの検索を行う。該当するルールがある場合、通信メッセージの変換を行う
【選択図】図１

Description

この発明は、ＳＩＰプロトコルを利用した通信方式において、アプリケーション間でプロトコルの実装の差分が存在する場合に、通信を行いながら差分を抽出する方法、その差分を元に実装の差分をシミュレートして接続試験を行う方法、及び実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法に関する。

ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）は、テキストベースの呼制御プロトコルであり、例えば、ＩＰネットワーク上で、電話の呼設定を実現するためのアプリケーション層プロトコルであって、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で標準化されている（例えば、非特許文献１や非特許文献２を参照）。

ＳＩＰは、非特許文献１や非特許文献２等により、通信メッセージの形式、リクエスト種別、メッセージシーケンスなどが規定されているので、これに従ってアプリケーションを開発すれば相互に通信が可能なはずである。しかし、ＲＦＣ（ＲｅｑｕｅｓｔＦｏｒ Ｃｏｍｍｅｎｔｓ：４桁の通し番号で管理された、ＩＥＴＦの公式ドキュメント）やドラフト（ＲＦＣの草稿等）に従っていても、異なる開発者によってＳＩＰが実装されたアプリケーションでは、相互接続に失敗することがある。それは、以下２つの理由で実装の差分（実装方式の差分または単に差分とも称する）が発生することが避けられないためである。

１つめの理由は、世代の問題である。すなわち、ＳＩＰは近年使われ出したプロトコルであり、仕様の策定、改善が急速に進められた結果、複数のＲＦＣやドラフトが存在する。このため、アプリケーションの開発者がＳＩＰの実装を行う時期などによって、基準とするＲＦＣやドラフトが異なってくる。このような仕様のバージョンなどの違いが原因で発生する実装の差分を“世代差”と呼ぶ。

２つめの理由は、独自仕様の問題である。すなわち、ＳＩＰは、手順や通信メッセージフォーマットの制限が少ないため（例えば、ＳＩＰメッセージは、ヘッダ部とボディ部で構成されるが、ヘッダ部には標準〈ＲＦＣ規定〉以外に開発者が独自に設定できる拡張ヘッダがあり、差分と成りうる。また、暫定応答〈電文の１ｘｘに相当〉の種別によって必須であるなしが、ベンダ（製品のメーカー等）によって異なる場合があり、これが差分となりうる。）、同一のＲＦＣを元にＳＩＰの実装をおこなっても、アプリケーション開発者によって解釈の差が生じる。このため、通信メッセージ送受信手順や通信メッセージフォーマットについて実装方法が異なる場合がある。また、ＳＩＰプロトコル（ＲＦＣ）が定義している基本機能に、開発者が必要とする機能が含まれない場合がある。その場合、開発者は、必要な機能を独自に実装することになるため、他社（他のベンダ）との互換性が損なわれてしまう。このような開発者の実装方法が原因で発生する実装の差分を“方言”と呼ぶ。

このように、２つのアプリケーション（自社アプリケーションと他社アプリケーション）間に、“世代差”や“方言”のような実装の差分が存在すると、両者のアプリケーションが、仕様（ＲＦＣ）通りに機能を実装していても、正常な条件での相互接続の失敗や、想定外の原因での通信エラーが発生する。

そのため、他社のアプリケーションと接続する場合には、事前に実装の差分に対応するためにどのような差分があるのか調査し、差分がある場合はそれに対応するためのカスタマイズを行い、正常に接続出来るか検証する必要がある。

しかし、開発の初期段階では他社アプリケーションを用意して実装の差分を調査することは、スケジュールや手間の問題から難しい。また、同様な理由でカスタマイズ後の検証も難しく、総合試験工程まで進んで、初めて不具合が発見され、アプリケーション改修などの手戻りが発生することが多い。

そこで、従来より、これらを解決するものとして、キャプチャリングソフト（データ取り込みソフト等）で取得したパケットデータを解析する方法と、動作をチェックするためにキャプチャデータを利用した疑似試験環境での検証というものがある。

すなわち、この従来技術では、事前に他社アプリケーションと接続して通信パケットデータのキャプチャリングを行い、通信データを取得する。アプリケーション開発者は、この他社アプリケーション通信データと、自社アプリケーション通信データの違い（実装方式の差分）を解析する。この解析結果を元に、実装方式の差分を推定し、自社アプリケーションのカスタマイズを行う。

また、疑似試験環境での検証は、他社アプリケーションをシミュレートするテストプログラムと、キャプチャしたデータを使ってカスタマイズした自社アプリケーションと送受信を行うことで接続の検証を行うものである。
Ｍ．Ｈａｎｄｌｅｙ， Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ， Ｅ．Ｓｃｈｏｏｌｅｒ， Ｊ．Ｒｏｓｅｎｂｅｒｇ、"ＳＩＰ ：Ｓｅｓｓｉｏｎ ＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ"、［ｏｎｌｉｎｅ］、Ｍａｒｃｈ１９９９、［平成１７年１０月３１日検索］、インターネット＜ＵＲＬ ： ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２５４３．ｔｘｔ＞ Ｊ．Ｒｏｓｅｎｂｅｒｇ， Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ， Ｇ．Ｃａｍａｒｉｌｌｏ， Ａ．Ｊｏｈｎｓｔｏｎ， Ｊ．Ｐｅｔｅｒｓｏｎ， Ｒ．Ｓｐａｒｋｓ， Ｍ．Ｈａｎｄｌｅｙ， Ｅ．Ｓｃｈｏｏｌｅｒ、"ＳＩＰ：ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ"、［ｏｎｌｉｎｅ］、Ｊｕｎｅ ２００２、［平成１７年１０月３１日検索］、インターネット＜ＵＲＬ ： ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ＞

しかしながら、上記従来技術では、以下の３つの問題がある。

１つめは、解析、検証の問題である。すなわち、キャプチャリングデータの解析は、送受信シーケンスや送信状況によって通信データ（通信メッセージ）の内容が変化することを考慮する必要があるため非常に難しい。加えて、自社と他社のアプリケーション間での送受信パターンの組み合わせが膨大となるため、非常に解析に時間がかかる。また、疑似試験環境で接続の検証を行うためには、テストプログラムを作成する必要がある。しかし、他社アプリケーション毎に、ＲＦＣや採用するドラフトが異なる可能性があるため、開発の度に新たにテストプログラムを作り込まなければならないという問題がある。

２つめは、作り込みの問題である。すなわち、接続する２つのアプリケーション（自社アプリケーションと他社アプリケーション）間に実装の差分が存在する場合、それに対応するロジックを自社アプリケーションに作り込む必要がある。しかし、この作業は正規の仕様とは無関係であり、本来は不要な作業である。また、このような作り込みは新たな障害を引き起こす原因となりやすいという問題がある。

３つめは、テストの問題である。すなわち、キャプチャデータでの解析、検証を行うには、他社アプリケーションと接続を行う必要があるが、通信データの収集を行うのに十分な時間がとれないため、基本的な送受信パターンでの通信データしか取得できない場合が多い。そのため、キャプチャした通信データを流用して検証を行う場合、正常系の単純なパターンでのテストしか出来ず、再現の難しい障害発生時や複合的な条件の試験が行えない。そのため、従来のように、実際に他社アプリケーションと接続するまでに、実装の差分を発見しきれず、手戻りの作業が発生してしまうという問題がある。

この発明は、上記問題を鑑みてなされたものであり、その目的は、キャプチャリングデータの解析及び検証が短時間且つ容易に行え、接続するアプリケーション間に実装の差分が存在する場合、それに対応するロジックを自社アプリケーションに作り込むことを不要とし、実装の差分を容易に発見可能な、ＳＩＰプロトコルを利用した通信方式において、通信を行いながら差分情報を抽出する方法、その差分情報を元に実装の差分をシミュレートして接続試験を行う方法、及び実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法を提供することである。

上述した目的を達成するため、この発明の第１の要旨のＳＩＰプロトコルを利用した通信方式において通信を行いながら差分を抽出する方法によれば、入力インタフェースにて外部よりＳＩＰプロトコルによる通信メッセージを受信し、登録エンジンにおいて、受信した通信メッセージと、ＤＢ（データベース）マネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢそれぞれが記憶するＳＩＰプロトコルの標準データとの差分を検出する。そして、登録エンジンにて、差分が検出されなかった場合、通信メッセージを変換エンジンに出力する。一方、登録エンジンにて、差分が検出された場合、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢのいずれかのＤＢに、当該差分が既に登録されているか否かを検索する。差分が登録されていなかった場合、差分を元に変換ルールを決定し、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの内の該当するＤＢに変換ルールの登録を行う。そして、変換ルールの登録後、通信メッセージを変換エンジンに出力する。さらに、変換エンジンにおいて、通信メッセージと、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶するＳＩＰプロトコルの標準データとの差分を検出する。そして、変換エンジンにて、該差分が検出されなかった場合、出力インタフェースに該通信メッセージを出力する。一方、変換エンジンにて、差分が検出された場合、通信メッセージを元に、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された変換ルールに従って、通信メッセージの変換を行う。そして、通信メッセージが変換エンジンにて変換された場合、変換された通信メッセージを、出力インタフェースに出力する。

この発明の第２の要旨のＳＩＰプロトコルを利用した通信方式において差分を元に実装の差分をシミュレートして接続試験を行う方法によれば、予め、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢに、自社アプリケーションと他社アプリケーションの双方向での変換ルールが登録されて成る、ＳＩＰプロトコルを利用した通信方式において差分を元に実装の差分をシミュレートして接続試験を行う方法であって、シナリオに記述された内容に従って疑似対向環境より出力された第１の通信メッセージを受信し、変換エンジンにおいて、受信された第１の通信メッセージと、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶するＳＩＰプロトコルの標準データとの差分を検出する。そして、変換エンジンにて、差分が検出されなかった場合、第１の通信メッセージを接続対象に出力する。一方、変換エンジンにて、差分が検出された場合、第１の通信メッセージを元に、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された変換ルールに従って、第１の通信メッセージの変換を行う。そして、第１の通信メッセージを、前記接続対象に出力する。また、接続対象より出力された第２の通信メッセージを受信する。そして、変換エンジンにおいて、受信された第２の通信メッセージと、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶するＳＩＰプロトコルの標準データとの差分を検出する。ここで、変換エンジンにて、差分が検出されなかった場合、第２の通信メッセージを疑似対向環境に出力する。一方、変換エンジンにて、差分が検出された場合、第２の通信メッセージを元に、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された変換ルールに従って、第２の通信メッセージの変換を行う。そして、第２の通信メッセージを、前記疑似対向環境に出力する。

この発明の第３の要旨のＳＩＰプロトコルを利用した通信方式において実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法によれば、予め、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢに、自社アプリケーションと他社アプリケーションの双方向での変換ルールが登録されて成る、ＳＩＰプロトコルを利用した通信方式において実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法であって、他社アプリケーションより出力された第１の通信メッセージを受信し、変換エンジンにおいて、受信された第１の通信メッセージと、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶するＳＩＰプロトコルの標準データとの差分を検出する。そして、変換エンジンにて、差分が検出されなかった場合、第１の通信メッセージを自社アプリケーションに出力する。一方、変換エンジンにて、差分が検出された場合、第１の通信メッセージを元に、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された変換ルールに従って、第１の通信メッセージの変換を行う。そして、第１の通信メッセージを自社アプリケーションに出力する。また、自社アプリケーションより出力された第２の通信メッセージを受信し、変換エンジンにおいて、受信された第２の通信メッセージと、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶するＳＩＰプロトコルの標準データとの差分を検出する。そして、変換エンジンにて、差分が検出されなかった場合、第２の通信メッセージを他社アプリケーションに出力する。一方、変換エンジンにて、差分が検出された場合、第２の通信メッセージを元に、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された変換ルールに従って、第２の通信メッセージの変換を行う。そして、第２の通信メッセージを、他社アプリケーションに出力する。

この発明によれば、接続先のアプリケーション毎にテストプログラムを作成する従来技術に比べ、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの更新のみで、最新の環境を構築できるため、いちいちプログラムを作成する手間を省くことが可能となる。また、試験工程の後半で実機（実際の製品）が準備出来るまで詳細なテストが出来なかった従来技術に比べ、テストの初期段階から実機に近い疑似対向環境を用意することができ、テスト品質を向上させることができる。

また、自社アプリケーションに実装の差分を作り込まなければならない従来技術に比べて、アプリケーション本体から実装の差分への対応の処理を切り離すことが可能なため、アプリケーション本体は本来の仕様の動作を実現することに注力でき、開発の負担を軽減させることが可能となる。また、実機同士での接続で見つかった実装の差分について、アプリケーション自体を改修する必要のあった従来技術に比べ、ＤＢの変換ルールのみで対応が可能となり、手戻りの作業量を抑えることが可能となる。

以下、図面を参照して、この発明の実施形態について説明する。なお、図中、各要素は、この発明が理解できる程度に概略的に示してあるに過ぎない。また、以下に述べる条件等は、この発明の範囲内の単なる好適例に過ぎない。

（実施形態１）
図１乃至図５は、この発明の実施形態１を説明するための図であり、先ず、構成について説明し、続いて動作について説明する。

〔実施形態１の構成〕
図１は、この発明のゲートウェイ装置の構成を示したブロック図である。

図１において、ゲートウェイ装置（以降ＧＷと称する）はコンピュータからなり、入力メッセージ（通信メッセージ）を受け付ける入力インターフェース１４と、ＣＰＵ４８と、ＣＰＵ４８により変換された通信メッセージを送信する出力インタフェース２０と、入出力画面２６とにより構成される。

さらに、ＣＰＵ４８は、入力メッセージの解析及び変換ルールの登録を管理する登録エンジン１６と、変換ルールに基づいて通信メッセージの変換を行う変換エンジン１８と、と、入力メッセージを一時的に保存する記憶領域１２と、データベース（以降ＤＢと称する）マネージャ２２と、ＣＰＵ４８全体を制御する制御部５０により構成される。

入力インタフェース１４は、図示しないＳＩＰメッセージを処理可能な外部機器等からのメッセージ入力を受け付ける。登録エンジン１６は、入力インタフェース１４より供給された入力メッセージ（通信メッセージ）を解析して変換のルールを決定し、ＤＢマネージャ２２内に設けられた後述する複数のＤＢに登録を行う。登録エンジン１６は、予め、登録モードか変換モードかのモード設定を行っておき、入力インタフェース１４より入力メッセージを供給された際、登録モード時には、前述のＤＢへ変換ルールの登録を行い、入力メッセージを変換エンジン１８に供給し、変換モード時には何も行わず、入力メッセージを変換エンジン１８に供給する。

変換エンジン１８は、入力メッセージに対して該当する変換ルールが無いかＤＢマネージャ内の各ＤＢ（後述）の検索を行う。該当するルールがある場合、入力メッセージの変換を行い、出力インタフェース２０に供給する。出力インタフェース２０は、供給された入力メッセージを、前述とは別のＳＩＰメッセージを処理可能な外部機器等に出力メッセージとして出力する。

ＤＢマネージャ２２は、後述するＤＢへの各種データの登録や参照を管理する。また、登録エンジン１６から登録要求があった場合に、内部のＤＢ（後述）に変換ルールの登録等を行う。

記憶領域１２は、登録エンジン１６や変換エンジン１８が受け付けた入力メッセージを処理する上で、一時的に保持したい情報を記憶する。

入出力画面２６は、人間が手動で登録を行うためのインタフェースであり、ＤＢマネージャ２２内の登録参照管理部２４（図２参照）を介して、各ＤＢの参照、登録、変更が可能である。また、外部ファイルを用意して、データの入出力（各ＤＢの参照、登録、変更等）を行うことも可能である。

図２は、ＤＢに変換ルールの登録を行うためのＤＢマネージャの構成を示したブロック図である。

図２におけるＤＢマネージャ２２は、各ＤＢへの登録、参照を管理する登録参照管理部２４と、通信メッセージ内のヘッダ種別とヘッダ種別毎に設定される値のデータを管理する辞書ＤＢ２８と、通信メッセージ種別による送受信シーケンスを管理するシーケンスパターンＤＢ３０と、通信メッセージの変換ルールを管理する変換ルールＤＢ３２とにより構成される。

登録参照管理部２４は、外部からの参照や登録の依頼に対して各ＤＢにアクセスを行い、データの入出力を管理する。また、登録参照管理部２４は、登録エンジン１６、変換エンジン１８、及び入出力画面２６からの３通りのアクセスを可能とする。

辞書ＤＢ２８は、通信メッセージ毎に設定されるヘッダ種別と、その設定値を管理し、登録参照管理部２４により、登録データの参照、追加、更新が行われる。

シーケンスパターンＤＢ３０は、２つのアプリケーション間でやり取りされる通信メッセージ種別毎の送信シーケンスパターンを管理し、登録参照管理部２４により、登録データの参照、追加、更新が行われる。

変換ルールＤＢ３２は、通信メッセージのヘッダや送信シーケンスの変換ルールを管理し、登録参照管理部２４により、登録データの参照、追加、更新が行われる。変換ルールとは、メッセージの送受信シーケンスパターンとメッセージ種別などから、ヘッダや送受信シーケンスをどのように変換するかというルールを規定したものである。

尚、辞書ＤＢ２８はＲＦＣで規定するＳＩＰ電文のヘッダ部やボディ部のデータパターンを、シーケンスパターンＤＢ３０はＲＦＣで規定する動作シーケンスのパターンを、変換ルールＤＢ３２は使用する辞書ＤＢ２８内データのパターン及びシーケンスパターンＤＢ３０内のパターンをそれぞれ標準データとして持ち、このデータと受信メッセージ（通信メッセージ）とを比較することで差分を検出する。

図３は、他社アプリケーションの実装の差分情報を収集するためのブロック図であり、この発明のＧＷ１０と、疑似対向環境装置３４と、他社／自社アプリケーション３６により構成される。

疑似対向環境装置３４は、予め取得したい通信メッセージの送受信パターンを再現可能な状態にし、ＧＷ１０を介して他社または自社アプリケーション３６と通信を行う。ＧＷ１０内のＤＢマネージャ２２内の各ＤＢには標準データを用意しておき、送受信メッセージを取得して実装の差分を判定し、ＤＢマネージャ２２内の各ＤＢに実装の差分情報の登録を行う。

送信契機が他社アプリケーションから始まるシーケンスデータを取得する場合は、他社／自社アプリケーション３６のブロックが「他社アプリケーション」になる。逆に送信契機が自社アプリケーションから始まるシーケンスデータを取得する場合は、他社／自社アプリケーション３６のブロックが「自社アプリケーション」になる。

図４は、疑似対向環境装置の構成を示したブロック図であり、ＣＰＵ５４と、テストシーケンスを記述する、記憶装置から成るシナリオ４２とから構成される。また、ＣＰＵ５４は、接続用テストプログラムの疑似テストＡＰ（アプリケーション）３８と、疑似テストＡＰ３８の動作を管理する管理マネージャ４０と、ＣＰＵ５４全体を制御する制御部５２とから構成される。

疑似テストＡＰ３８は、ＳＩＰプロトコルを実装し、自社アプリケーションと接続してメッセージの送受信が可能なインタフェースである。

管理マネージャ４０は、疑似テストＡＰ３８を利用して、後述するシナリオ４２の記述に従ってテスト用の送受信メッセージのシーケンスを再現する。

シナリオ４２は、予めユーザにより用意された、送受信テストで実施したいメッセージの送受信のやり取りを記述したものである。

〔実施形態１の動作〕
図５は、この発明の実装の差分情報の収集方法を示したフローチャートである。

〈接続時のＧＷ内での処理〉
図５をメインに図１乃至図３を適宜参照しながら本発明の実装の差分情報の収集方法について説明を行う。以下では、図３の他社／自社アプリケーション３６のブロックが「他社アプリケーション」の場合、すなわち、メッセージ送信契機が他社アプリケーションの場合について説明する。尚、以下では予め登録エンジンを１６の設定を、登録エンジンを用いるモードに設定しておく。また、ＤＢマネージャ２２内の各ＤＢには、ＳＩＰプロトコルの標準データ（例えば、ＲＦＣ３２６１準拠）が格納されているものとする。

先ず、図１の入力インタフェース１４を介して、図３の疑似対向環境装置（以降、単に疑似対向環境と称する）３４より出力された通信メッセージを受信する（ステップＳ９８）。次に、登録エンジン１６の設定が、登録エンジンを用いるモードであるため、入力インタフェース１４は、記憶領域１２に通信メッセージから得たメッセージ種別などを設定し（ステップＳ１００）、登録エンジン１６に受信した通信メッセージを送る。続いて、通信メッセージを受信した登録エンジン１６は、この通信メッセージの解析を行う（ステップＳ１０２，Ｓ１０４）。

通信メッセージの解析は、ＤＢマネージャ２２内の各ＤＢが持っている標準データと、受信メッセージ（通信メッセージ）の差分をチェックすることで行う。差分が存在しない場合には、変換エンジン１８に通信メッセージを送る（ステップＳ１０６，Ｓ１１４）。

差分が存在する場合には、図１のＤＢマネージャ２２内の各ＤＢ（辞書ＤＢ２８、シーケンスパターンＤＢ３０、変換ルールＤＢ３２）に当該差分が登録されているか否かの検索が行われ（ステップＳ１０８）、既に登録がなされている場合には、変換エンジン１８に通信メッセージを送る（ステップＳ１１０，Ｓ１１４）。

差分が登録されていない場合には、当該差分を元に変換ルールを決定し、図１のＤＢマネージャ２２内の各ＤＢへ登録を行う（変換ルールは後述）。登録後、受信メッセージ（通信メッセージ）を変換エンジン１８に送信する（ステップＳ１１２，Ｓ１１４）。

変換エンジン１８が、通信メッセージを受信すると、標準データとの差分をチェックする（ステップＳ１１４）。差分が無い場合は、図１の出力インタフェース２０に通信メッセージを送信する（ステップＳ１１６，Ｓ１２０）。

差分がある場合、変換エンジン１８は、受信した直近（現在）の通信メッセージと、図１の記憶領域１２に登録されている、それまでに受信した過去の通信メッセージを元に、図１のＤＢマネージャ２２内の各ＤＢを検索し、その変換ルールに従って、通信メッセージの変換を行い、変換された通信メッセージを、図１の出力インタフェース２０に送信する（ステップＳ１１６，Ｓ１１８，Ｓ１２０）。

変換エンジン１８から通信メッセージを受信した出力インタフェース２０は、外部の他社／自社アプリケーション３６（この場合、他社アプリケーション）に対して通信メッセージを出力する。

以上、図３の通信メッセージ送信契機が他社アプリケーションの場合について説明したが、通信メッセージ送信契機が自社アプリケーションの場合は、図３の他社／自社アプリケーション３６のブロックが、自社アプリケーションに置き換えられる以外は、上述の処理（手順）と同様であるので、説明は省略する。

〈ヘッダの変換ルールの自動取り込み〉
次に、変換ルールについて説明する。以下では、通信メッセージのヘッダ情報についての変換ルールの取り込みについて説明する。辞書ＤＢ２８では、予めベース（標準データ）となるヘッダ情報を持ち、送信するメッセージ種別毎のヘッダの種類と設定されるヘッダデータから構成される。受信した通信メッセージのヘッダ情報と標準データとの間に差分があった場合、以下の手順で辞書ＤＢ２８への取り込みを行う。

(1)図３の構成において、疑似対向環境３４を使って対象アプリケーション（例えば、他社アプリケーション）と通信を行う。

(2)図３の他社アプリケーションからの通信メッセージをＧＷ１０が受信すると、図１の入力インタフェース１４は、登録エンジン１６に通信メッセージを送る。

(3)登録エンジン１６は、既に登録されている辞書ＤＢ２８のヘッダ情報を検索し、ヘッダ種別の登録とヘッダ設定値の登録を検索する。

(4)登録エンジン１６は、ヘッダ種別の登録がなかった場合、またはヘッダ設定値の登録が無かった場合には、その状態に応じて変換ルールを自動的に設定する。変換ルールの詳細は、表１及び表２の通りである。

変換ルールは、他社アプリケーションから受信時に自社アプリケーション向けに変換する受信時変換ルール（表１）と、受信に対して他社にレスポンスを返すときのレスポンス変換ルール（表２）の２種類がある。尚、表中のデフォルト値の設定や、例外的なルールを指定したい場合や、条件によって設定値を変えたい場合には、ＧＷ１０内の入出力画面２６から手動で設定を変更することが可能である。

〈シーケンスパターンの変換ルールの自動取り込み〉
以下では、シーケンスパターンの変換ルールの自動取り込みについて説明する。すなわち、上述の〈接続時のＧＷ内での処理〉と同様に、他社アプリケーションと接続を行い、受信メッセージ（通信メッセージ）への応答に関する実装の差分情報を収集し、シーケンスパターンＤＢ３０に登録を行う。

(1)図３の構成において、対象アプリケーションとの通信を行う。

(2)記憶領域１２に登録されたメッセージのシーケンスを元に、標準のシーケンスパターンとの突き合わせを行う。

(3)他社アプリケーションからの受信メッセージ（通信メッセージ）種別が、標準のシーケンスパターンと一致しない場合、登録エンジン１６は、差分の内容に応じて変換ルールを変換ルールＤＢ３２に登録する。変換ルールの詳細は、表３の通りである。

(4)自社アプリケーションの送信メッセージ（通信メッセージ）が、他社アプリケーションで受け付けてもらえない場合は、ＧＷ１０内の入出力画面２６から手動で変換ルールの設定を行う。

尚、表中のデフォルト値の設定や、例外的なルールを指定したい場合や、条件によって設定値を変えたい場合には、ＧＷ１０内の入出力画面２６から手動で設定を変更することが可能である。

〔実施形態１の作用効果〕
従って、この発明によれば、以下に述べる作用効果を奏する。

すなわち、ＧＷで受信情報と標準データとの比較を行うことで、自動的に実装の差分を検出することができる。その結果、キャプチャしたデータを人間が手動で解析する従来技術に比べ、リアルタイムに解析が行えるため、差分情報の効率的な解析が可能となる。

また、ＧＷの変換エンジンで、検出した相互に実装差分が存在するアプリケーションの変換ルールを自動的に設定することが可能となる。その結果、人間が変換ルールを検討する従来技術に比べ、人間の作業負担を減らすことが出来る。

さらに、ＧＷの登録エンジンで、検出した差分情報や変換ルールを各ＤＢに取り込むことで、自社アプリケーションに実装差分に対応する処理を作り込む従来技術に比べて、取り込んだ情報の流用や応用を容易に行うことが出来る。

（実施形態２）
図６及び図７は、この発明の第２実施形態を説明するための図であり、先ず、構成について説明し、続いて動作について説明する。

図６及び図７において、第１実施形態と同一構成かつ同一機能であるものについては同一の符号を付し説明を省略もしくは簡略にする。以下、各図面（実施形態１の説明で使用した図面を含む）を用いて、この発明の第２実施形態について、詳細に説明する。

〔実施形態２の構成〕
〈試験シミュレータ〉
図６は、この発明のＧＷを他社アプリケーションのシミュレータとして適用した場合における構成を示したブロック図である。

図６の試験シミュレータは、自社ＡＰ（アプリケーション）４４と、この発明のＧＷ１０と、疑似対向環境３４とにより構成される。

疑似対向環境３４には、予めテストを行いたいシナリオ４２（図４参照）を用意しておき、疑似対向環境３４と自社ＡＰ４４の間にＧＷ１０を配置し、疑似対向環境３４及び自社ＡＰ４４間にて通信を行うように構成されている。

事前に、ＧＷ１０内の登録エンジン等により、他社アプリケーションの変換ルールを、図２のＤＢマネージャ２２内の各ＤＢに設定しておく。このＧＷ１０の設定により、疑似対向環境３４は、他社アプリケーション４６の動作を再現し、自社ＡＰ４４との疑似接続試験を可能とする。

〈実機接続〉
図７は、この発明のＧＷを中間接続インタフェースとして適用した場合における接続形態を示したブロック図である。

この発明のＧＷ１０は、自社ＡＰ４４と他社ＡＰ４６の中間に接続されて構成される。この場合の接続形態は、ＬＡＮ上での接続（図７（Ａ））と、インターネットを介した遠隔での接続（図７（Ｂ））とがある。

〔実施形態２の動作〕
以下、この発明によるＧＷ１０を用いた、他社の実装に差分のあるアプリケーションの動作のシミュレート方法と、他社／自社アプリケーション間の通信方法について説明する。

〈接続時のＧＷ内での処理〉
ここでは、シミュレーション時、及びアプリケーション接続時のＧＷ１０の動作について、図５を参照して説明する。シミュレート時の接続形態は、図６、図７に従う。ＧＷ１０は、予め変換エンジンを用いるモードに設定されているものとする。

先ず、図１の入力インタフェース１４を介して通信メッセージを受信する（ステップＳ９８）。次に、登録エンジン１６の設定が、変換エンジンを用いるモードであるため、入力インタフェース１４は、記憶領域１２に通信メッセージから得たメッセージ種別などを設定し（ステップＳ１００）、変換エンジン１８に受信した通信メッセージを送る（ステップＳ１０２，Ｓ１１４）。

変換エンジン１８が、通信メッセージを受信すると、標準データとの差分をチェックする（ステップＳ１１４）。差分が無い場合は、図１の出力インタフェース２０に通信メッセージを送信する（ステップＳ１１６，Ｓ１２０）。

変換エンジン１８において、差分がある場合、受信した直近（現在）の通信メッセージと、図１の記憶領域１２に登録されているそれまでに受信した過去の通信メッセージを元に、図２のＤＢマネージャ２２内の各ＤＢを検索し、その変換ルールに従って、通信メッセージの変換を行い、変換した通信メッセージを、図１の出力インタフェース２０に送信する（ステップＳ１１６，Ｓ１１８，Ｓ１２０）。

変換エンジン１８から通信メッセージを受信した出力インタフェース２０は、外部に対して通信メッセージを出力する。

〈他社アプリケーションのシミュレータ環境〉
ここでは、この発明のＧＷ１０で、他社アプリケーションの動作をシミュレートして、接続試験を行う場合について、図６を参照して説明を行う。尚、ＤＢマネージャ２２内の各ＤＢには、予め、他社及び自社アプリケーションの変換ルールが登録されていることを前提とする。また、疑似対向環境３４には、ＳＩＰスタックを実装しているものとする。

他社アプリケーション（＝疑似対向環境３４）から送信を行う場合は、以下の動作となる。

(1)先ず、図６の構成において、疑似対向環境３４からリクエストメッセージ（通信メッセージ）の送信をＧＷ１０に対して行う。疑似対向環境３４では、図４の管理マネージャ４０が、シナリオ４２を読み込み、記述された内容に従って、疑似テストＡＰ３８にて、通信メッセージの送信を行う。

(2)次に、通信メッセージを受けた図６のＧＷ１０は、ＤＢマネージャ２２内の各ＤＢにアクセスし、変換ルールを検索する。ＧＷ１０は、受信した通信メッセージを該当する変換ルールに従って実際の接続対象（＝自社アプリケーション）と同じ形式に変換して、自社アプリケーション４４に送信する。

(3)自社アプリケーション４４は、ＧＷ１０からメッセージを受信する。ユーザは、自社アプリケーション４４が受信したメッセージに対応する処理を行うか、または確認することで接続試験を行う。

尚、自社アプリケーションから送信を行う場合も、上記と同様にＧＷ１０でメッセージ変換を行い疑似対向環境３４に対して送信を行う。

〈他社アプリケーションとの接続〉
ここでは、この発明を用いて、実装の差分が存在する２つのアプリケーションを接続する方法について説明する。

図７の構成において、自社アプリケーション４４と他社アプリケーション４６の中間にＧＷ１０を設置し通信を行う。両アプリケーションは、ＧＷ１０を介することで、双方のアプリケーションの有する実装の差分に関わりなく、互いに通信することが可能となる。尚、図２を参照して説明した、差分情報の収集方法で、ＤＢマネージャ２２内の各ＤＢには、自社アプリケーション４４と他社アプリケーション４６の双方向での変換ルールが登録されているものとする。

(1)先ず、図７の構成において、他社アプリケーション４６から、通信メッセージの送信を行う。

(2)通信メッセージを受信した、図７のＧＷ１０は、ＤＢマネージャ２２内の各ＤＢにアクセスし、変換ルールを検索する。ＧＷ１０は、受信した通信メッセージを該当する変換ルールに従って実際の接続対象（この場合、自社アプリケーション）と同じ形式に変換して、自社アプリケーション４４に送信する。

(3)ＧＷ１０が、自社アプリケーション４４からの通信メッセージを受信した場合も同様に、(1)、(2)の処理を行って他社アプリケーション４６向けのメッセージ形式に変換して送信する。

〔実施形態２の作用効果〕
従って、この発明によれば、それぞれの状況において、以下のような作用効果を奏する。

〈シミュレート〉
ＧＷの変換データを使うことで、他社アプリケーションとの間に発生するＳＩＰプロトコルの実装の差分を擬似的に再現できる。その結果、接続先のアプリケーション毎にテストプログラムを作成する従来技術に比べ、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの更新のみで、最新の環境を構築できるため、いちいちプログラムを作成する手間を省くことが可能となる。

また、ＧＷと疑似環境を組み合わせて接続試験を行うことにより、他社アプリケーションの実機を準備しなくても、実機に近い条件で接続テストが可能となる。その結果、試験工程の後半で実機が準備出来るまで詳細なテストが出来なかった従来技術に比べ、テストの初期段階から実機に近い疑似対向環境を用意することができ、テスト品質を向上させることができる。

〈実機接続〉
ＧＷの変換ルールにより、メッセージ送受信の実装の差分をＧＷのみで対応することが可能となる。その結果、自社アプリケーションに実装の差分を作り込まなければならない従来技術に比べて、アプリケーション本体から仕様差分への対応の処理を切り離すことが可能なため、アプリケーション本体は本来の仕様の動作を実現することに注力でき、開発の負担を軽減させることが可能となる。

また、実装の差分をＤＢ化することで、実装の差分への対応をＤＢだけで対応することが可能となる。その結果、実機同士での接続で見つかった実装の差分について、アプリケーション自体を改修する必要のあった従来技術に比べ、ＤＢの変換ルールのみで対応が可能となり、手戻りの作業量を抑えることが可能となる。

（実施形態の変形）
なお、この発明は前述の実施形態に限定されるものではなく、この発明の目的を達成できる範囲での変形、改良等もこの発明に含まれるものである。

例えば、この発明を実施するための最良の構成などは、以上の記載で開示されているが、この発明は、これに限定されるものではない。すなわち、この発明は、主に特定の実施形態に関して特に図示され、かつ、説明されているが、この発明の技術的思想および目的の範囲から逸脱することなく、以上述べた実施形態に対し、構成、動作、数量、その他の詳細な構成において、当業者が様々な変形を加えることができるものである。

したがって、上記に開示した構成、動作などを限定した記載は、この発明の理解を容易にするために例示的に記載したものであり、この発明を限定するものではないから、それらの構成、動作などの限定の一部若しくは全部の限定を外した構成の名称での記載は、この発明に含まれるものである。

実施形態１によれば、差分情報取得のために、直接通信を行う方法について説明したが、接続を行わずに通信時のログデータを元にＤＢへの登録を行うことで、同様に差分情報の収集が可能である。

また、他社アプリケーションにて、将来実装予定であるが、現在は実装されていない機能について、入力インタフェースから独自に作り込むことが可能である。

また、障害が発生したときに、この発明の差分を見つけ出す機能を利用することで、想定外のデータが設定されていることを効率的に見つけ出すことが可能である。

実施形態２によれば、シミュレートの場合に、疑似対向環境のシナリオにレアケースのシナリオを用意し、実機では行いにくい試験を実施することが可能である。

また、ＤＢマネージャで、意図的に誤った値やシーケンスパターンを設定することで、異常系の試験を簡単に実施することが可能である。

また、実機で発生した障害のログを元にシナリオを作成し、障害時の動作を再現することが可能である。

また、Ａ社アプリケーションとＢ社アプリケーションの変換データ、及び、Ｂ社アプリケーションとＣ社アプリケーションの変換データのように、既に生成されたＤＢデータから、Ａ社アプリケーションとＣ社アプリケーションの変換データのように、新たな組み合わせの変換データを作成することが可能である。

また、実機接続の場合には、実装の差分を持つ複数社のアプリケーションをマルチに接続する場合に、ＧＷに変換ルールを集約することで、各社のアプリケーション自体は接続先のアプリケーションとの実装の差分に関係なく接続することが可能である。

この発明のゲートウェイ装置の構成を示したブロック図である。 ＤＢに変換ルールの登録を行うためのＤＢマネージャの構成を示したブロック図である。 他社アプリケーションの実装の差分情報を収集するためのブロック図である。 疑似対向環境装置の構成を示したブロック図である。 この発明の実装の差分情報の収集方法を示したフローチャートである。 この発明のＧＷを他社アプリケーションのシミュレータとして適用した場合における構成を示したブロック図である。 この発明のＧＷを中間接続インタフェースとして適用した場合における接続形態を示したブロック図である。

符号の説明

１０…ＧＷ（ゲートウェイ装置）
１２…記憶領域
１４…入力インターフェース
１６…登録エンジン
１８…変換エンジン
２０…出力インターフェース
２２…ＤＢマネージャ
２４…登録参照管理部
２６…入出力画面
２８…辞書ＤＢ
３０…シーケンスパターンＤＢ
３２…変換ルールＤＢ
３４…疑似対向環境装置
３６…他社／自社アプリケーション
３８…疑似テストＡＰ
４０…管理マネージャ
４２…シナリオ
４４…自社ＡＰ（アプリケーション）
４６…他社ＡＰ（アプリケーション）
４８，５４…ＣＰＵ
５０，５２…制御部

Claims (6)

1. 入力インタフェースにて外部よりＳＩＰプロトコルによる通信メッセージを受信するステップと、
   登録エンジンにおいて、受信した前記通信メッセージと、ＤＢ（データベース）マネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢそれぞれが記憶する前記ＳＩＰプロトコルの標準データとの差分を検出するステップと、
   前記登録エンジンにて、前記差分が検出されなかった場合、前記通信メッセージを変換エンジンに出力するステップと、
   前記登録エンジンにて、前記差分が検出された場合、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢのいずれかのＤＢに、当該差分が既に登録されているか否かを検索するステップと、
   該差分が登録されていなかった場合、該差分を元に変換ルールを決定し、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの内の該当するＤＢに前記変換ルールの登録を行うステップと、
   前記変換ルールの登録後、前記通信メッセージを変換エンジンに出力するステップと、
   前記変換エンジンにおいて、前記通信メッセージと、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶する前記ＳＩＰプロトコルの標準データとの差分を検出するステップと、
   前記変換エンジンにて、該差分が検出されなかった場合、出力インタフェースに該通信メッセージを出力するステップと、
   前記変換エンジンにて、該差分が検出された場合、該通信メッセージを元に、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された前記変換ルールに従って、前記通信メッセージの変換を行うステップと、
   該通信メッセージが前記変換エンジンにて変換された場合、該変換された通信メッセージを、前記出力インタフェースに出力するステップと、
   を含むことを特徴とするＳＩＰプロトコルを利用した通信方式において通信を行いながら差分を抽出する方法。
2. 前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された各内容の変更、更新、新規登録を必要に応じて手動にて行うステップを新たに含むことを特徴とする請求項１に記載のＳＩＰプロトコルを利用した通信方式において通信を行いながら差分を抽出する方法。
3. 予め、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢに、自社アプリケーションと他社アプリケーションの双方向での変換ルールが登録されて成る、ＳＩＰプロトコルを利用した通信方式において差分情報を元に実装の差分をシミュレートして接続試験を行う方法であって、
   シナリオに記述された内容に従って疑似対向環境より出力された第１の通信メッセージを受信するステップと、
   変換エンジンにおいて、前記受信された第１の通信メッセージと、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶するＳＩＰプロトコルの標準データとの差分を検出するステップと、
   前記変換エンジンにて、該差分が検出されなかった場合、前記第１の通信メッセージを接続対象に出力するステップと、
   前記変換エンジンにて、該差分が検出された場合、前記第１の通信メッセージを元に、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された前記変換ルールに従って、前記第１の通信メッセージの変換を行うステップと、
   前記第１の通信メッセージを、前記接続対象に出力するステップと、
   前記接続対象より出力された第２の通信メッセージを受信するステップと、
   前記変換エンジンにおいて、受信された前記第２の通信メッセージと、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶する前記ＳＩＰプロトコルの標準データとの差分を検出するステップと、
   前記変換エンジンにて、該差分が検出されなかった場合、前記第２の通信メッセージを前記疑似対向環境に出力するステップと、
   前記変換エンジンにて、該差分が検出された場合、前記第２の通信メッセージを元に、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された前記変換ルールに従って、前記第２の通信メッセージの変換を行うステップと、
   前記第２の通信メッセージを、前記疑似対向環境に出力するステップと、
   を含むことを特徴とするＳＩＰプロトコルを利用した通信方式において差分を元に実装の差分をシミュレートして接続試験を行う方法。
4. 前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された各内容の変更、更新、新規登録を必要に応じて手動にて行うステップを新たに含むことを特徴とする請求項３に記載のＳＩＰプロトコルを利用した通信方式において差分を元に実装の差分をシミュレートして接続試験を行う方法。
5. 予め、ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢに、自社アプリケーションと他社アプリケーションの双方向での変換ルールが登録されて成る、ＳＩＰプロトコルを利用した通信方式において実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法であって、
   他社アプリケーションより出力された第１の通信メッセージを受信するステップと、
   変換エンジンにおいて、受信された前記第１の通信メッセージと、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶する前記ＳＩＰプロトコルの標準データとの差分を検出するステップと、
   前記変換エンジンにて、該差分が検出されなかった場合、前記第１の通信メッセージを自社アプリケーションに出力するステップと、
   前記変換エンジンにて、該差分が検出された場合、前記第１の通信メッセージを元に、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された前記変換ルールに従って、前記第１の通信メッセージの変換を行うステップと、
   前記第１の通信メッセージを自社アプリケーションに出力するステップと、
   該自社アプリケーションより出力された第２の通信メッセージを受信するステップと、
   前記変換エンジンにおいて、受信された前記第２の通信メッセージと、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢの各ＤＢが記憶する前記ＳＩＰプロトコルの標準データとの差分を検出するステップと、
   前記変換エンジンにて、該差分が検出されなかった場合、前記第２の通信メッセージを前記他社アプリケーションに出力するステップと、
   前記変換エンジンにて、該差分が検出された場合、前記第２の通信メッセージを元に、前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された前記変換ルールに従って、前記第２の通信メッセージの変換を行うステップと、
   前記第２の通信メッセージを、前記他社アプリケーションに出力するステップと、
   を含むことを特徴とするＳＩＰプロトコルを利用した通信方式において実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法。
6. 前記ＤＢマネージャ内部の、辞書ＤＢ、シーケンスパターンＤＢ、及び変換ルールＤＢに記憶された各内容の変更、更新、新規登録を必要に応じて手動にて行うステップを新たに含むことを特徴とする請求項５に記載のＳＩＰプロトコルを利用した通信方式において実装に差分のあるアプリケーション間をメッセージ形式を変換して正常に接続する方法。