JP4131954B2 - Ｓｉｐ−ａｌｇの呼状態管理方法 - Google Patents

Description

本発明は、ＩＰ通信網におけるＳＩＰ通信の呼管理方法であり、詳細には、ＮＡＴ装置と連携するＳＩＰ−ＡＬＧにおける呼状態の管理方法に関する。

ＲＦＣ３２６１（非特許文献２）の１７章などでＳＩＰ（Session Initiation Protocol）の状態管理について明記されているが、それはＳＩＰのトランザクションに関する状態遷移であり、基本的に端末やＰｒｏｘｙに適用することを目的としている。しかしながら、ＳＩＰ−ＡＬＧ（Session Initiation Protocol-Application Level Gateway、ＳＩＰアプリケーションレベルゲートウェイ）の場合、非特許文献７に示すようにＮＡＴ装置（Network Address Translation装置）やＦＷ装置（Firewall装置）と連携し取得したアドレス変換情報などの呼関連リソースを呼の開始から終了まで管理する必要があるため、ＲＦＣ３２６１（非特許文献２）の状態管理をそのまま適用することはできなかった。

そこで、本出願人による特願２００３−１５６１８８号「ＳＩＰ−ＡＬＧにおける呼状態管理方法」（本出願時点では公開されていない。）では呼の開始と終了のみに着目し、ＳＩＰ信号の中で、開始信号と終了信号を定義し、開始信号時に呼状態を作成し、終了信号時に呼状態を削除するという単純な方法を提案した。しかしながら、この方式では、例えば１つの呼の中でＩＮＶＩＴＥダイアログだけでなく、ＯＰＴＩＯＮＳトランザクションも含まれる場合、ＯＰＴＩＯＮＳトランザクションの削除契機で呼状態が削除されてしまうため、ＩＮＶＩＴＥダイアログの途中で呼状態が削除されるという問題が生じる。また、ＲＦＣ３２６５（非特許文献４）やＲＦＣ３５１５（非特許文献６）で規定されているように、１つの呼の中でＩＮＶＩＴＥダイアログ、ＲＥＦＥＲダイアログ、ＳＵＢＳＣＲＩＢＥダイアログが混在した場合において、ＩＮＶＩＴＥダイアログが終了した時に、ＲＥＦＥＲダイアログやＳＵＢＳＣＲＩＢＥダイアログが継続できないという問題があり、即ち１つの呼の中で複数トランザクションが同時に生じる場合や、複数ダイアログが同時に生じる場合、１つのトランザクション、ダイアログが削除された時点で呼状態そのものが削除される問題がある。なお、トランザクション、ダイアログについてはＲＦＣ３２６１（非特許文献２）に規定されている。

ＲＦＣ２５４３、"SIP: Session Initiation Protocol"、M. Handley外３名、March 1999、[online]、［平成１５年１２月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc2543.txt?number=2543＞

ＲＦＣ３２６１、"SIP: Session Initiation Protocol"、J. Rosenberg外７名、June 2002、[online]、［平成１５年１２月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc3261.txt?number=3261＞ ＲＦＣ３２６２、"Reliability of Provisional Responses in the Session Initiation Protocol (SIP)"、J. Rosenberg外１名、June 2002、[online]、［平成１５年１２月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc3262.txt?number=3262＞ ＲＦＣ３２６５、"Session Initiation Protocol (SIP)-Specific Event Notification"、A. B. Roach、June 2002、[online]、［平成１５年１２月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc3265.txt?number=3265＞ ＲＦＣ３４２８、"Session Initiation Protocol (SIP) Extension for Instant Messaging"、B. Campbell, Ed.外４名、December 2002、[online]、［平成１５年１２月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc3428.txt?number=3428＞ ＲＦＣ３５１５"The Session Initiation Protocol (SIP) Refer Method"、R. Sparks、April 2003、[online]、［平成１５年１２月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc3515.txt?number=3515＞ 林和仁外４名、「ＳＩＰアプリケーションレベルゲートウェイ（ＳＩＰ−ＡＬＧ）におけるアドレス変換エントリの管理方法に関する一考察」、信学技報ＮＳ２００２−１８８、ＰＳ２００２−６２（２００２−１２）、ｐ２５−２８

本発明が解決しようとする課題は、１つの呼の中において、複数のダイアログや複数のトランザクションが生じる場合にも、呼関連リソースを呼開始から呼終了まで管理できるよう、呼の開始、継続、終了状態を管理することである。

本発明の請求項１では、前記課題を解決する方法を示している。

請求項１では、呼の中で生成されるトランザクション、ダイアログ有無の状態を管理することで、１つの呼の中におけるトランザクション、ダイアログの生起状態を把握できるようにしている。具体的には、トランザクション、ダイアログが生じる毎に当該トランザクション、ダイアログ情報を登録し、それらが削除される毎に当該トランザクション情報、ダイアログ情報を削除することにより、トランザクション、ダイアログ有無の状態を管理できる。

ＳＩＰの呼は、ＲＥＧＩＳＴＥＲのように単一のトランザクションで構成されるものと、ＩＮＶＩＴＥ〜ＢＹＥの最終応答で終了する呼のように、複数のトランザクションと、ダイアログで構成されるものがあるが、いずれの場合においても、全てのトランザクション、ダイアログを削除することにより呼が終了する。

そこで、ＳＩＰ−ＡＬＧにおいて上記のトランザクション、ダイアログの状態管理を行い、１つ呼の中で１つでも存在するトランザクション、ダイアログがある場合は呼継続と判断し、また、呼継続とした場合はアドレス変換情報などの呼関連リソースを保持し、トランザクション、ダイアログが全て存在しない場合は呼終了と判断でき、その時点で呼関連リソースを削除できる。

請求項２では、請求項１の呼状態管理を実現するための方法を示している。

ＳＩＰ−ＡＬＧにおいて、アドレス変換情報など呼関連リソースを管理するキー情報を保持する呼状態管理テーブル、トランザクション状態を管理するトランザクション状態管理テーブル、ダイアログ状態を管理するダイアログ状態管理テーブルを配備し、それぞれ呼状態の生成、削除、トランザクション状態生成、削除、ダイアログ状態生成、削除を管理する。

ＳＩＰ−ＡＬＧではカプセル化ＳＩＰ信号を受信した際に、まずＩＮＶＩＴＥ要求など呼を開始する信号（開始信号）か否かを確認する。

開始信号であれば、呼関連リソースなど呼を管理する上でのキー情報を取得する。呼管理のキー情報は、ＮＡＴ装置のＩＰアドレスなど対向装置識別情報、Ｃａｌｌ−ＩＤなど呼識別情報の組であるが、カプセル化ＳＩＰ信号より前記対向装置識別情報、前記呼識別情報を取得しキー情報とし、取得したキー情報を基に呼状態管理テーブルを検索し、既に当該キー情報が登録されていれば何もせず、登録されていなければ当該キー情報を登録し後続処理に移る。なお、開始信号の処理において、既にキー情報が登録されている場合は、開始信号の再送時や、ＩＮＶＩＴＥダイアログ成立後のｒｅ−ＩＮＶＩＴＥ要求などが想定される。

また、開始信号以外の信号の場合は、カプセル化ＳＩＰ信号から前記キー情報を取得し、当該キー情報を基に呼状態管理テーブルを検索し、既に当該キー情報が登録されていれば何もせず後続処理に移り、登録されていなければ、異常状態とみなし信号を破棄し、ここで処理を終了する。

また、上記処理を行った後、トランザクションの生成、削除に関わる信号については、トランザクション状態の管理を行う。

ＳＩＰの要求信号のようにトランザクションを生成する信号であった場合、メソッド名、最上位のＶｉａヘッダのｂｒａｎｃｈ−ＩＤなどをトランザクション識別情報として取得し、前記キー情報に対するレコードとしてトランザクション状態管理テーブルに登録する。

最終応答信号のようにトランザクションを削除する信号であった場合は、メソッド名、最上位のＶｉａヘッダのｂｒａｎｃｈ−ＩＤなどをトランザクション識別情報として取得し、トランザクション状態管理テーブルにおいて、前記キー情報に対するレコードとして管理された当該トランザクション識別情報を削除する。

なお、１００ Ｔｒｙｉｎｇや１８０ Ｒｉｎｇｉｎｇなどの暫定応答時は特に何も行わない。

次に、トランザクション状態の登録、削除処理後、ダイアログ状態の管理を行う。ここでは、受信信号が、ＩＮＶＩＴＥ要求に対する２００ ＯＫ応答のようにダイアログを生成する信号か、あるいはＢＹＥ要求のようにダイアログを削除する信号かを識別する。

ダイアログを生成する信号であった場合、ＦｒｏｍヘッダのｔａｇパラメータとＴｏヘッダのｔａｇパラメータなど、ダイアログ識別情報を収集し、前記キー情報に対するレコードとして、ダイアログ状態管理テーブルに登録を行う。

ダイアログを削除する信号であった場合は、ＦｒｏｍヘッダのｔａｇパラメータとＴｏヘッダのｔａｇパラメータなど、ダイアログ識別情報を収集し、ダイアログ状態管理テーブルにおいて、前記キー情報に対するレコードとして管理された当該ダイアログ識別情報の削除を行う。

その他の信号であれば特に何も行わない。

ダイアログ状態の登録、削除を行った後、呼を継続させるか終了させるか判断を行う。

呼を終了させる契機は、ＢＹＥ要求に対する２００ ＯＫのように呼を終了させる信号（終了信号）である。そこで終了信号か否かの確認を行い、終了信号であった場合は、前記キー情報を基にトランザクション状態管理テーブル、ダイアログ状態管理テーブルを参照し、トランザクション識別情報と、ダイアログ識別情報が存在するか否かを確認する。その結果、前記トランザクション状態管理テーブル、前記ダイアログ状態管理テーブルに当該キー情報に関わる情報が１つでも残っている場合は、それらの情報を削除するために、その後、何らかのＳＩＰ信号が送信されることが想定されるため、呼を継続するものと判断する。従って、呼状態管理テーブルの前記キー情報を削除せず保持し、信号処理を終了する。

また、前記トランザクション状態管理テーブル、前記ダイアログ状態管理テーブルに、それぞれ当該トランザクション識別情報と、当該ダイアログ識別情報が全く存在しない場合は、その後、特にＳＩＰ信号は不要なため、呼終了と判断し、呼関連リソースを削除した上で、呼状態管理テーブルのキー情報を削除し信号処理を終了する。

上記のように、呼状態テーブル、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを用いて、開始処理、継続処理判定、トランザクション状態登録、削除、ダイアログ状態、登録削除、終了処理判定を行うことにより、呼の開始、終了を適切に管理できる。

請求項３は、請求項１の処理を行う上で必要となる信号の定義と、定義信号の情報を取得する方法について示している。

呼の生成、終了、トランザクションの生成、終了、ダイアログの生成、終了については、それぞれ信号を識別しなければならない。即ち、開始信号、終了信号、トランザクション生成信号、トランザクション削除信号、ダイアログ生成信号、ダイアログ削除信号を定義しなければならない。

そこで、ＩＮＶＩＴＥ要求、ＲＥＧＩＳＴＥＲ要求、ＯＰＴＩＯＮＳ要求、ＲＥＦＥＲ要求、ＳＵＢＳＣＲＩＢＥ要求、ＭＥＳＳＡＧＥ要求を開始信号と定義し、ＡＣＫ要求、ＢＹＥ要求に対する２ｘｘ〜６ｘｘ応答、ＲＥＧＩＳＴＥＲ要求に対する２ｘｘ〜６ｘｘ応答、ＯＰＴＩＯＮＳ要求に対する２ｘｘ〜６ｘｘ応答、ＮＯＴＩＦＹ要求に対する２ｘｘ〜６ｘｘ応答、ＭＥＳＳＡＧＥ要求に対する２ｘｘ〜６ｘｘ応答、ＲＥＦＥＲ要求に対する３ｘｘ〜６ｘｘ応答、ＳＵＢＳＣＲＩＢＥ要求に対する３ｘｘ〜６ｘｘ応答を終了信号と定義する。

また、ＡＣＫ要求を除くＳＩＰの要求信号をトランザクション生成信号として定義し、ＩＮＶＩＴＥ以外の要求に対する最終応答、ＩＮＶＩＴＥ要求に対する２ｘｘ信号、ＩＮＶＩＴＥ要求に対する３ｘｘ〜６ｘｘ応答後のＡＣＫ要求をトランザクション削除信号として定義する。

さらに、ＩＮＶＩＴＥダイアログに対しては、ＩＮＶＩＴＥ要求に対する２ｘｘ応答、ＲＥＦＥＲダイアログに対しては、ＲＥＦＥＲ要求に対する２ｘｘ応答、ＳＵＢＳＣＲＩＢＥダイアログに対しては、ＳＵＢＳＣＲＩＢＥ要求に対する２ｘｘ応答を、ダイアログを生成する信号として定義し、ＩＮＶＩＴＥダイアログに対してはＢＹＥ要求、ＲＥＦＥＲダイアログやＳＵＢＳＣＲＩＢＥダイアログに対しては、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダにｔｅｒｍｉｎａｔｅｄと書かれたＮＯＴＩＦＹ要求を、ダイアログを削除する信号として定義する。

そのように定義した情報は、そのままプログラムに直接書き込むか、あるいはファイルやテーブルに格納し、プログラム起動時に読み込ませることで、開始信号、終了信号、トランザクション生成信号、トランザクション削除信号、ダイアログの生成信号、ダイアログの削除信号の判定が可能となる。

請求項４では、請求項２における呼状態と呼関連リソースの連携方法について記述している。

ＳＩＰ−ＡＬＧでは、アドレス変換情報などの呼関連リソースについても、対向装置識別情報と呼識別情報をキー情報としてそれぞれのテーブルで管理する。呼関連リソースは、呼の開始から終了まで適切に管理する必要があるが、請求項２の呼状態管理テーブルの前記キー情報の有無により、呼の継続、終了を判断する方法が利用できる。

請求項４では、請求項２の第３のステップと第４のステップの間において、必要に応じてアドレス変換要求を行い、取得した情報を、前記キー情報に対するレコードとして、それぞれの呼関連リソースの管理テーブルに登録する。

その後、請求項２の第４のステップにおいて、呼を継続するものと判断し、呼状態管理テーブルの前記キー情報を保持する場合は、呼関連リソースの当該キー情報に関わるリソースは保持し、また、呼を終了と判断し、呼状態管理テーブルの前記キー情報を削除する場合は、呼関連リソースの当該キー情報に関わるリソースを削除する。

上記により呼状態管理テーブルと呼関連リソースの同期をとることにより、呼の開始から終了まで呼関連リソースを適切に管理することが可能となる。

請求項５では、対向装置識別情報と呼識別情報をキー情報とする全てのテーブルにおいて、呼状態管理テーブルと他のテーブルの効率的な連携方法について示している。

対向装置識別情報はＮＡＴ装置のＩＰアドレスであり、呼識別情報はＣａｌｌ−ＩＤなどの情報であるが、Ｃａｌｌ−ＩＤは文字列であり、それぞれのＣａｌｌ−ＩＤ毎に文字列の長さが異なる可能性もある。また、Ｃａｌｌ−ＩＤとＩＰアドレスの２つの情報をキー情報として管理する非効率的である。そこで、呼状態テーブルに対向装置識別情報と呼識別情報を管理する際に、それらの組に対する番号を呼番号として払い出し、その呼番号をその他テーブルとキー情報として管理すると、テーブルの連携上効率化が図れる。

本発明により、ＳＩＰ−ＡＬＧにおいて、１つの呼の中で複数のダイアログ、トランザクションが存在する場合にも対応できるようになり、ＮＡＴ装置、ＳＩＰ−ＡＬＧを配備した環境においても、高度なＳＩＰサービスを提供することが可能になる。

図１〜図６６を用いて実施例を説明する。

通常ＳＩＰ通信を行う場合は、発着端末の間にＳＩＰサーバを経由することが多いが、なるべく簡単にするため、端末同士の直接ＳＩＰ通信を例に挙げている。またＳＩＰ−ＡＬＧと接続する装置としては、簡単にするためＮＡＴ装置と接続した場合を例に挙げて説明するが、ＮＡＴ装置はＦＷ（FireWall）機能を有するＮＡＴ装置すなわちＮＡＴ／ＦＷ装置でもよい。

図１はネットワーク構成を示している。プライベート網（１０）は１９２．１６８．０．０／２４のネットワークアドレスであり、その中にはＩＰアドレス＝１９２．１６８．０．１を持つ端末１（１１）が配備されている。また端末１（１１）はＳＩＰ信号受信用ポート番号として５０６０、ＲＴＰなどのメディア受信用のポート番号として１００００が設定されている。

グローバル網（２０）は１２８．０．０．０／２４のネットワークアドレスを持ち、その中にはＩＰアドレス＝１２８．０．０．１を持つ端末２（２１）が配備されている。また端末２（２１）はＳＩＰ信号受信用ポート番号として５０６０、ＲＴＰなどのメディア受信用のポート番号として１００００が設定されている。

また、プライベート網（１０）とグローバル網（２０）をＮＡＴ装置（３０）が接続しており、またＮＡＴ装置（３０）と管理網（４０）を介し、ＳＩＰ−ＡＬＧ（５０）が接続されている。ＳＩＰ−ＡＬＧ（５０）は１７２．３０．０．２というＩＰアドレスを持ち、ＮＡＴ装置（３０）との信号受信用ポート番号として５００００が設定されており、ＮＡＴ装置（３０）は１７２．３０．０．１というＩＰアドレスを持ち、ＳＩＰ−ＡＬＧ（５０）との信号受信用ポート番号として５００００が設定されている。

ＮＡＴ装置（３０）は、ＳＩＰ信号を検出すると、自身のＩＰアドレスを被せてＳＩＰ信号をカプセル化し、転送先装置すなわちＳＩＰ−ＡＬＧ（５０）に対してカプセル化ＳＩＰ信号を送信する手段と、転送先装置から送信されたカプセル化信号を受信しデカプセル化し、ＳＩＰ信号に戻す手段を有し、また、転送先装置からアドレス変換要求されたＩＰアドレス、ポート番号に対して、変換先のＩＰアドレス、ポート番号を払い出し、変換前後のアドレス組を管理し、転送先装置に対して結果を応答する手段、および、転送先装置からのアドレス組の削除要求に対して払い出したアドレス組を削除する手段を有している。

図２はＳＩＰ−ＡＬＧ（５０）の構成を示している。ＳＩＰ−ＡＬＧ（５０）は、ＳＩＰ−ＡＬＧのプログラムを実行する呼処理機能（５１）、データを保持するテーブルとして、ネットワークアドレス管理テーブル（５２）、信号定義テーブル（５３）、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）を配備している。

図３はテーブルの連携関係を示している。ネットワークアドレス管理テーブル（５２）と、信号定義テーブル（５３）は特に他のテーブルと連携しない。トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は、呼状態管理テーブル（５４）と連携する。アドレス変換テーブル（５７）に登録される情報が呼関連リソースである。

図４はネットワークアドレス管理テーブル（５２）を示している。本テーブルは対向装置であるＮＡＴ装置（３０）が、収容するプライベート網側アドレス体系と、プライベートアドレスの変換後のグローバルアドレス体系を管理している。対向装置識別情報として、ＮＡＴ装置（３０）のＩＰアドレスの１７２．３０．０．１、プライベート網側アドレス体系として１９２．１６８．０．０／２４、グローバル網側アドレス体系として１３０．０．０．０／２４が管理されている。

図５は、ＳＩＰ−ＡＬＧの呼状態管理において必要となる信号定義を行う、信号定義テーブルについて示している。本テーブルはＩＮＶＩＴＥ要求、ＲＥＧＩＳＴＥＲ要求、ＯＰＴＩＯＮＳ要求、ＲＥＦＥＲ要求、ＳＵＢＳＣＲＩＢＥ要求、ＭＥＳＳＡＧＥ要求を開始信号として定義し、ＡＣＫ要求、ＢＹＥ要求に対する２ｘｘ〜６ｘｘ応答、ＲＥＧＩＳＴＥＲ要求に対する２ｘｘ〜６ｘｘ応答、ＯＰＴＩＯＮＳ要求に対する２ｘｘ〜６ｘｘ応答、ＮＯＴＩＦＹ要求に対する２ｘｘ〜６ｘｘ応答、ＭＥＳＳＡＧＥ要求に対する２ｘｘ〜６ｘｘ応答、ＲＥＦＥＲ要求に対する３ｘｘ〜６ｘｘ応答、ＳＵＢＳＣＲＩＢＥ要求に対する３ｘｘ〜６ｘｘ応答を終了信号として定義する。

また、ＡＣＫ要求を除くＳＩＰの要求信号をトランザクション生成信号として定義し、ＩＮＶＩＴＥ以外の要求に対する最終応答、ＩＮＶＩＴＥ要求に対する２ｘｘ信号、ＩＮＶＩＴＥ要求に対する３ｘｘ〜６ｘｘ応答後のＡＣＫ要求をトランザクション削除信号として定義する。

また、ＩＮＶＩＴＥ要求に対する２ｘｘ応答、ＲＥＦＥＲ要求に対する２ｘｘ応答、ＳＵＢＳＣＲＩＢＥ要求に対する２ｘｘ応答をダイアログ生成信号として定義し、ＩＮＶＩＴＥダイアログ対するダイアログ削除信号として、それぞれＢＹＥ要求、ＳＵＢＳＣＲＩＢＥ、ＲＥＦＥＲダイアログに対するダイアログ削除信号として、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダにｔｅｒｍｉｎａｔｅｄと記述されたＮＯＴＩＦＹ要求を定義している。なお本テーブルの内容はプログラムの中に盛り込んでもよい。本例のようにテーブルとして記述した場合は、呼処理機能のアプリケーションを立ち上げる際に読み込ませると効率がよい。

図６は、呼状態管理テーブル（５４）を示している。呼状態管理テーブル（５４）は、対向装置識別情報、呼識別情報、およびそれらの情報に対応する呼番号の情報を管理する。

図７は、トランザクション状態管理テーブル（５５）を示している。トランザクション状態管理テーブル（５５）は、呼番号、メソッド、Ｖｉａのｂｒａｎｃｈ−ＩＤを管理する。

図８は、ダイアログ状態管理テーブル（５６）を示している。ダイアログ状態管理テーブル（５６）は、呼番号、メソッド、Ｐｒｉｖａｔｅ−ｔａｇパラメータ、Ｇｌｏｂａｌ−ｔａｇパラメータを管理する。

図９はアドレス変換テーブル（５７）を示している。アドレス変換テーブルは、呼番号、プライベート網側ＩＰアドレス、ポート番号、グローバル網側ＩＰアドレス、ポート番号、変換ＩＤを管理する。

図１０〜図３３を用いて、ＩＮＶＩＴＥ／ＯＰＴＩＯＮＳの複合シーケンスの処理を説明する。

図１０〜図１２までは各装置で送受信される信号を示しており、各信号の内容、および信号処理時におけるＳＩＰ−ＡＬＧのテーブルの内容について図１３〜図３３に示している。

端末１（１１）から送信されたＩＮＶＩＴＥ（Ｓ１）をＮＡＴ装置（３０）が受信すると、自身のＩＰアドレス、ポート番号を被せてカプセル化を行い、図１３に示すようなカプセル化ＩＮＶＩＴＥ（Ｓ２）をＳＩＰ−ＡＬＧ（５０）に送信する。

図１３に示すようにカプセル化ＩＮＶＩＴＥ（Ｓ２）はＳＩＰ信号とカプセル化部分とからなり、ＳＩＰ信号はＳＩＰレイヤとＵＤＰレイヤとＩＰレイヤを有する。ＳＩＰ信号についてはＲＦＣ２５４３（非特許文献１）、ＲＦＣ３２６１（非特許文献２）で規定されている。また、カプセル化部分はＵＤＰレイヤとＩＰレイヤを有する。これは後述する他のカプセル化メッセージにおいても同様である。

ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図１３のようなカプセル化ＩＮＶＩＴＥ（Ｓ２）を受信すると、信号定義テーブル（５３）を参照し、開始信号か否かの識別を行い、受信信号がＩＮＶＩＴＥ要求であることから開始信号と判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得し、それらの組をキー情報として記録し、そのキー情報を基に、呼状態管理テーブル（５４）を参照し、何も登録されていないことを確認する。また当該キー情報に対する呼番号として１を払い出し、当該キー情報と呼番号を呼状態管理テーブル（５４）に登録する。

次にトランザクション関連の処理を行い、ＩＮＶＩＴＥ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０１を取得し、先に取得した呼番号、メソッド名（ＩＮＶＩＴＥ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行うが、ＩＮＶＩＴＥ要求はダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａ、Ｃｏｎｔａｃｔ、ＳＤＰ（Session Description Protocol）のｃ、ｍフィールドを変換対象として抽出し、それら変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。しかしながら特に当該レコードは存在しないため、Ｖｉａ、Ｃｏｎｔａｃｔに対しては図１４のようなアドレス変換要求１（Ｓ３）を行い、図１５のようなアドレス変換応答１（Ｓ４）を受信し、ＳＤＰについては図１６のようなアドレス変換要求２（Ｓ５）を行い、図１７のようなアドレス変換応答２（Ｓ６）を受信する。アドレス変換応答により取得した結果は、先に取得した呼番号をキー情報としてアドレス変換テーブル（５７）に登録する。また、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセルＩＮＶＩＴＥ（Ｓ７）を送信する。

その後、終了信号か否かの識別を行うが、ＩＮＶＩＴＥ要求は終了信号ではないため、本処理もスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図１８のようになる。

ＮＡＴ装置（３０）は、カプセル化ＩＮＶＩＴＥ（Ｓ７）を受信すると、デカプセル化しＩＮＶＩＴＥ（Ｓ８）を端末２（２１）に対して送信する。

端末２（２１）から２００ ＯＫ（Ｓ９）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ１０）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図１９のようなカプセル化２００ ＯＫ（Ｓ１０）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＩＮＶＩＴＥ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＩＮＶＩＴＥ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０ｌを取得し、先に取得した呼番号、メソッド名（ＩＮＶＩＴＥ）に該当する、トランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行い、ＩＮＶＩＴＥ要求の２００ ＯＫは、ダイアログ生成信号であるため、Ｆｒｏｍヘッダのｔａｇ、Ｔｏヘッダのｔａｇを取得する。また、この２００ ＯＫ信号がグローバル網からプライベート網に送信されていることから、ＦｒｏｍヘッダのＳＩＰ−ＵＲＩはプライベート網側、ＴｏヘッダのＳＩＰ−ＵＲＩはグローバル網側と判断し、Ｆｒｏｍヘッダより取得したｔａｇをＰｒｉｖａｔｅ−ｔａｇ、Ｔｏヘッダより取得したｔａｇをＧｌｏｂａｌ−ｔａｇとして管理する。その後、先に取得した呼番号、メソッド（ＩＮＶＩＴＥ）と共に、ダイアログ状態管理テーブル（５６）に登録する。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ１１）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行うが、ＩＮＶＩＴＥ要求の２００ ＯＫは終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図２０のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ１１）を受信すると、デカプセル化し２００ ＯＫ（Ｓ１２）を端末１（１１）に対して送信する。

端末１（１１）からＡＣＫ（Ｓ１３）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＡＣＫ（Ｓ１４）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図２１のようなカプセル化ＡＣＫ（Ｓ１４）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＡＣＫ要求であるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＩＮＶＩＴＥの２ｘｘ応答後のＡＣＫ要求はトランザクション生成、削除のいずれの信号でもないため、本処理はスキップする。

次にダイアログ関連の処理を行うが、ＡＣＫ要求は、ダイアログ生成信号でも、ダイアログ削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＡＣＫ（Ｓ１５）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行い、ＡＣＫ要求は終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが存在するため、呼継続と判断し各テーブルの状態はそのまま保持し信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図２２のようになる。

ＮＡＴ装置（３０）は、カプセル化ＡＣＫ（Ｓ１５）を受信すると、デカプセル化しＡＣＫ（Ｓ１６）を端末２（２１）に対して送信する。ここで端末１（１１）と端末２（２１）のセッションが確立される。

端末１（１１）からＯＰＴＩＯＮＳ（Ｓ１７）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＯＰＴＩＯＮＳ（Ｓ１８）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図２３のようなカプセル化ＯＰＴＩＯＮＳ（Ｓ１８）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行い、受信信号がＯＰＴＩＯＮＳ要求であるため開始信号と判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録する。そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、その際に呼番号を取得する。

次にトランザクション関連の処理を行い、ＯＰＴＩＯＮＳ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０３を取得し、先に取得した呼番号、メソッド名（ＯＰＴＩＯＮＳ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行うが、ＯＰＴＩＯＮＳ要求はダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＯＰＴＩＯＮＳ（Ｓ１９）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行うが、ＯＰＴＩＯＮＳ要求は終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図２４のようになる。

ＮＡＴ装置（３０）は、カプセル化ＯＰＴＩＯＮＳ（Ｓ１９）を受信すると、デカプセル化しＯＰＴＩＯＮＳ（Ｓ２０）を端末２（２１）に対して送信する。

端末２（２１）から２００ ＯＫ（Ｓ２１）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ２２）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図２５のようなカプセル化２００ ＯＫ（Ｓ２２）を受信すると、開始信号か否かの識別を行うが、受信信号がＯＰＴＩＯＮＳ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＯＰＴＩＯＮＳ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０３を取得し、先に取得した呼番号、メソッド名（ＯＰＴＩＯＮＳ）に該当する、トランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行うが、ＯＰＴＩＯＮＳ要求の２００ ＯＫはダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ２３）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行い、ＯＰＴＩＯＮＳ要求の２００ ＯＫは終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが存在するため、呼継続と判断し各テーブルの状態はそのまま保持し信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図２６のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ２３）を受信すると、デカプセル化し２００ ＯＫ（Ｓ２４）を端末１（１１）に対して送信する。

端末１（１１）からＢＹＥ（Ｓ２５）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＢＹＥ（Ｓ２６）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図２７のようなカプセル化ＢＹＥ（Ｓ２６）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＢＹＥ要求であるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＢＹＥ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０４を取得し、先に取得した呼番号、メソッド名（ＢＹＥ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行い、ＢＹＥ要求は、ダイアログ削除信号であるため、ＦｒｏｍヘッダのｔａｇパラメータとＴｏヘッダのｔａｇパラメータを取得する。なおＢＹＥ要求はグローバル網からプライベート網に対して送信されているため、Ｆｒｏｍヘッダより取得したｔａｇパラメータをＧｌｏｂａｌ−ｔａｇ、Ｔｏヘッダより取得したｔａｇパラメータをＰｒｉｖａｔｅ−ｔａｇとする。また、ＢＹＥ要求で削除するダイアログはＩＮＶＩＴＥダイアログであるため、メソッドとしてＩＮＶＩＴＥを指定して、先に取得した呼番号、Ｐｒｉｖａｔｅ−ｔａｇ、Ｇｌｏｂａｌ−ｔａｇに該当するレコードをダイアログ状態管理テーブル（５６）から削除する。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｒｅｑｕｅｓｔ−ＵＲＩを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＢＹＥ（Ｓ２７）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行うが、ＢＹＥ要求は終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図２８のようになる。

ＮＡＴ装置（３０）は、カプセル化ＢＹＥ（Ｓ２７）を受信すると、デカプセル化しＢＹＥ（Ｓ２８）を端末２（２１）に対して送信する。

端末２（２１）から２００ ＯＫ（Ｓ２９）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ３０）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図２９のようなカプセル化２００ ＯＫ（Ｓ３０）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＢＹＥ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＢＹＥ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０４を取得し、先に取得した呼番号、メソッド名（ＢＹＥ）に該当するトランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行うが、ＢＹＥ要求の２００ ＯＫはダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、特に変換対象が存在しないことを確認する。その後ＳＩＰレイヤのアドレス変換は特に行わず、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ３１）を送信する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図３０のようになる。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行い、ＢＹＥ要求の２００ ＯＫは終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが全く存在しないため、呼終了と判断し、アドレス変換テーブルより先に取得した呼番号に対する変換ＩＤを取得し、それらの変換ＩＤを設定し、ＮＡＴ装置（３０）に対して図３１のようなアドレス組削除要求１（Ｓ３３）を送信する。ＮＡＴ装置（３０）より図３２のようなアドレス組削除応答１（Ｓ３４）を受信すると、アドレス変換テーブル上の当該レコードを削除し、また、呼状態テーブルにおいても先に取得した呼番号に関するレコードを削除し信号処理を終了する。

その結果全ての呼関連リソース、呼状態が削除される。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図３３のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ２３）を受信すると、デカプセル化し２００ ＯＫ（Ｓ２４）を端末１（１１）に対して送信する。

図３４〜図６６を用いて、ＳＵＢＳＣＲＩＢＥ／ＩＮＶＩＴＥの複合シーケンスの処理を説明する。

図３４〜図３７までは各装置で送受信される信号を示しており、各信号の内容、および信号処理時におけるＳＩＰ−ＡＬＧのテーブルの内容について図３８〜図６６に示している。

端末１（１１）から送信されたＳＵＢＳＣＲＩＢＥ（Ｓ５１）をＮＡＴ装置（３０）で受信するとカプセル化を行い、カプセル化ＳＵＢＳＣＲＩＢＥ（Ｓ５２）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図３８のようなカプセル化ＳＵＢＳＣＲＩＢＥ（Ｓ５２）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行い、受信信号がＳＵＢＳＣＲＩＢＥ要求であることから開始信号と判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得し、それらの組をキー情報として記録し、また当該キー情報に対する呼番号として２を払い出す。また、そのキー情報を基に、呼状態管理テーブル（５４）を参照し、何も登録されていないことを確認し、当該キー情報と呼番号を呼状態管理テーブル（５４）に登録する。

次にトランザクション関連の処理を行い、ＳＵＢＳＣＲＩＢＥ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０１を取得し、先に取得した呼番号、メソッド名（ＳＵＢＳＣＩＲＢＥ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行うが、ＳＵＢＳＣＲＩＢＥ要求はダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、それら変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。しかしながら特に当該レコードは存在しないため、Ｖｉａに対しては図３９のようなアドレス変換要求１（Ｓ５３）を行い、図４０のようなアドレス変換応答１（Ｓ５４）を受信する。アドレス変換応答により取得した結果は、先に取得した呼番号をキー情報としてアドレス変換テーブル（５７）に登録する。また、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＳＵＢＳＣＲＩＢＥ（Ｓ５５）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行うが、ＳＵＢＳＣＲＩＢＥ要求は終了信号ではないため、本処理もスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図４１のようになる。

ＮＡＴ装置（３０）は、カプセル化ＳＵＢＳＣＲＩＢＥ（Ｓ５５）を受信すると、デカプセル化しＳＵＢＳＣＲＩＢＥ（Ｓ５６）を端末２（２１）に対して送信する。

端末２（２１）から２００ ＯＫ（Ｓ５７）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ５８）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図４２のようなカプセル化２００ ＯＫ（Ｓ５８）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＳＵＢＳＣＲＩＢＥ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＳＵＢＳＣＲＩＢＥ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０１を取得し、先に取得した呼番号、メソッド名（ＳＵＢＳＣＲＩＢＥ）に該当する、トランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行い、ＳＵＢＳＣＲＩＢＥ要求の２００ ＯＫは、ダイアログ生成信号であるため、Ｆｒｏｍヘッダのｔａｇ、Ｔｏヘッダのｔａｇを取得する。また、この２００ ＯＫ信号がグローバル網からプライベート網に送信されていることから、ＦｒｏｍヘッダのＳＩＰ−ＵＲＩはプライベート網側、ＴｏヘッダのＳＩＰ−ＵＲＩはグローバル網側と判断し、Ｆｒｏｍヘッダより取得したｔａｇをｐｒｉｖａｔｅ−ｔａｇ、Ｔｏヘッダより取得したｔａｇをＧｌｏｂａｌ−ｔａｇとして管理する。その後、先に取得した呼番号、メソッド（ＳＵＢＳＣＲＩＢＥ）と共に、ダイアログ状態管理テーブル（５６）に登録する。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ５９）を送信する。

その後、終了信号か否かの識別を行うが、ＳＵＢＳＣＲＩＢＥ要求の２００ ＯＫは終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図４３のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ５９）を受信すると、デカプセル化し２００ ＯＫ（Ｓ６０）を端末１（１１）に対して送信する。

端末２（２１）からＮＯＴＩＦＹ（Ｓ６１）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＮＯＴＩＦＹ（Ｓ６２）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図４４のようなカプセル化ＮＯＴＩＦＹ（Ｓ６２）を受信すると、開始信号か否かの識別を行うが、受信信号がＮＯＴＩＦＹ要求であるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＮＯＴＩＦＹ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０２を取得し、先に取得した呼番号、メソッド名（ＮＯＴＩＦＹ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行い、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダを取得する。しかしながらＳｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅはａｃｔｉｖｅであることから、ダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｒｅｑｕｅｓｔ−ＵＲＩを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＮＯＴＩＦＹ（Ｓ６３）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行うが、ＮＯＴＩＦＹ要求は終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図４５のようになる。

ＮＡＴ装置（３０）は、カプセル化ＮＯＴＩＦＹ（Ｓ６３）を受信すると、デカプセル化しＮＯＴＩＦＹ（Ｓ６４）を端末１（１１）に対して送信する。

端末１（１１）から２００ ＯＫ（Ｓ６５）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ６６）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図４６のようなカプセル化２００ ＯＫ（Ｓ６６）を受信すると、開始信号か否かの識別を行うが、受信信号がＮＯＴＩＦＹ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＮＯＴＩＦＹ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０２を取得し、先に取得した呼番号、メソッド名（ＮＯＴＩＦＹ）に該当するトランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行うが、ＮＯＴＩＦＹ要求の２００ ＯＫはダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、特に変換対象が存在しないことを確認する。その後ＳＩＰレイヤのアドレス変換は特に行わず、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ６７）を送信する。

その後、終了信号か否かの識別を行い、ＮＯＴＩＦＹ要求の２００ ＯＫは終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが存在するため、呼継続と判断し各テーブルの状態はそのまま保持し信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図４７のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ６７）を受信すると、デカプセル化し２００ ＯＫ（Ｓ６８）を端末２（２１）に対して送信する。

端末１（１１）から送信されたＩＮＶＩＴＥ（Ｓ６９）をＮＡＴ装置（３０）で受信するとカプセル化を行い、カプセル化ＩＮＶＩＴＥ（Ｓ７０）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図１３のようなカプセル化ＩＮＶＩＴＥ（Ｓ７０）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行い、受信信号がＩＮＶＩＴＥ要求であることから開始信号と判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＩＮＶＩＴＥ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０３を取得し、先に取得した呼番号、メソッド名（ＩＮＶＩＴＥ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行うが、ＩＮＶＩＴＥ要求はダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａ、Ｃｏｎｔａｃｔ、ＳＤＰのｃ、ｍフィールドを変換対象として抽出し、それら変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果Ｖｉａ、Ｃｏｎｔａｃｔについては変換後のアドレスを取得することができる。しかしながらＳＤＰについて当該レコードは存在しないため、図４９のようなアドレス変換要求２（Ｓ７１）を行い、図５０のようなアドレス変換応答２（Ｓ７２）を受信する。アドレス変換応答により取得した結果は、先に取得した呼番号をキー情報としてアドレス変換テーブル（５７）に登録する。また、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＩＮＶＩＴＥ（Ｓ７３）を送信する。

その後、終了信号か否かの識別を行うが、ＩＮＶＩＴＥ要求は終了信号ではないため、本処理もスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図５１のようになる。

ＮＡＴ装置（３０）は、カプセル化ＩＮＶＩＴＥ（Ｓ７３）を受信すると、デカプセル化しＩＮＶＩＴＥ（Ｓ７４）を端末２（２１）に対して送信する。

端末２（２１）から２００ ＯＫ（Ｓ７５）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ７６）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図５２のようなカプセル化２００ ＯＫ（Ｓ７６）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＩＮＶＩＴＥ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得し、それらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＩＮＶＩＴＥ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０３を取得し、先に取得した呼番号、メソッド名（ＩＮＶＩＴＥ）に該当する、トランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行い、ＩＮＶＩＴＥ要求の２００ ＯＫは、ダイアログ生成信号であるため、Ｆｒｏｍヘッダのｔａｇ、Ｔｏヘッダのｔａｇを取得する。また、この２００ ＯＫ信号がグローバル網からプライベート網に送信されていることから、ＦｒｏｍヘッダのＳＩＰ−ＵＲＩはプライベート網側、ＴｏヘッダのＳＩＰ−ＵＲＩはグローバル網側と判断し、Ｆｒｏｍヘッダより取得したｔａｇをｐｒｉｖａｔｅ−ｔａｇ、Ｔｏヘッダより取得したｔａｇをＧｌｏｂａｌ−ｔａｇとして管理する。その後、先に取得した呼番号、メソッド（ＩＮＶＩＴＥ）と共に、ダイアログ状態管理テーブル（５６）に登録する。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ７７）を送信する。

その後、終了信号か否かの識別を行うが、ＩＮＶＩＴＥ要求の２００ ＯＫは終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図５３のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ７７）を受信すると、デカプセル化し２００ ＯＫ（Ｓ７８）を端末１（１１）に対して送信する。

端末１（１１）からＡＣＫ（Ｓ７９）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＡＣＫ（Ｓ８０）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図２１のようなカプセル化ＡＣＫ（Ｓ８０）を受信すると、開始信号か否かの識別を行うが、受信信号がＡＣＫ要求であるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＩＮＶＩＴＥの２ｘｘ応答後のＡＣＫ要求はトランザクション生成、削除のいずれの信号でもないため、本処理はスキップする。

次にダイアログ関連の処理を行うが、ＡＣＫ要求は、ダイアログ生成信号でも、ダイアログ削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＡＣＫ（Ｓ８１）を送信する。

その後、終了信号か否かの識別を行い、ＡＣＫ要求は終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが存在するため、呼継続と判断し各テーブルの状態はそのまま保持し信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図５５のようになる。

ＮＡＴ装置（３０）は、カプセル化ＡＣＫ（Ｓ８１）を受信すると、デカプセル化しＡＣＫ（Ｓ８２）を端末２（２１）に対して送信する。ここで端末１（１１）と端末２（２１）のセッションが確立される。

端末２（２１）からＮＯＴＩＦＹ（Ｓ８３）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＮＯＴＩＦＹ（Ｓ８４）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図５６のようなカプセル化ＮＯＴＩＦＹ（Ｓ８４）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＮＯＴＩＦＹ要求であるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＮＯＴＩＦＹ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０５を取得し、先に取得した呼番号、メソッド名（ＮＯＴＩＦＹ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行い、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダを取得する。Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅはｔｅｒｍｉｎａｔｅｄであることから、ダイアログ削除信号と判断し、ＦｒｏｍヘッダのｔａｇパラメータとＴｏヘッダのｔａｇパラメータを取得する。なおＮＯＴＩＦＹ要求はグローバル網からプライベート網に対して送信されているため、Ｆｒｏｍヘッダより取得したｔａｇパラメータをＧｌｏｂａｌ−ｔａｇ、Ｔｏヘッダより取得したｔａｇパラメータをＰｒｉｖａｔｅ−ｔａｇとする。また、ＮＯＴＩＦＹ要求で削除するダイアログはＳＵＢＳＣＲＩＢＥ、ＲＥＦＥＲダイアログの２種類あるため両者を識別する必要がある。そこでＥｖｅｎｔヘッダを取得する。Ｅｖｅｎｔヘッダはｐｒｅｓｅｎｃｅであり、ｒｅｆｅｒではないため、削除するダイアログはＳＵＢＳＣＲＩＢＥダイアログであることが分かる。

なお本例ではメソッドをダイアログ識別のパラメータとして用いているが、ＳＵＢＳＣＲＩＢＥダイアログの中でもｐｒｅｓｅｎｃｅ、ｗａｔｃｈｅｒ．ｉｎｆｏ、ｄｉａｌｏｇなどそれぞれのＥｖｅｎｔに応じてそれぞれのダイアログが生成される場合は、ダイアログ識別情報にＥｖｅｎｔ名を含めることで対応できる。

その後、メソッドとしてＳＵＢＳＣＲＩＢＥを指定して、先に取得した呼番号、Ｐｒｉｖａｔｅ−ｔａｇ、Ｇｌｏｂａｌ−ｔａｇに該当するレコードをダイアログ状態管理テーブル（５６）から削除する。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｒｅｑｕｅｓｔ−ＵＲＩを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＮＯＴＩＦＹ（Ｓ８５）を送信する。

その後、終了信号か否かの識別を行うが、ＮＯＴＩＦＹ要求は終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図５７のようになる。

ＮＡＴ装置（３０）は、カプセル化ＮＯＴＩＦＹ（Ｓ８５）を受信すると、デカプセル化しＮＯＴＩＦＹ（Ｓ８６）を端末１（１１）に対して送信する。

端末１（１１）から２００ ＯＫ（Ｓ８７）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ８８）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図５８のようなカプセル化２００ ＯＫ（Ｓ６６）を受信すると、開始信号か否かの識別を行うが、受信信号がＮＯＴＩＦＹ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＮＯＴＩＦＹ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０５を取得し、先に取得した呼番号、メソッド名（ＮＯＴＩＦＹ）に該当するトランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行うが、ＮＯＴＩＦＹ要求の２００ ＯＫはダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、特に変換対象が存在しないことを確認する。その後ＳＩＰレイヤのアドレス変換対象は特に行わず、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ８９）を送信する。

その後、終了信号か否かの識別を行い、ＮＯＴＩＦＹ要求の２００ ＯＫは終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが存在するため、呼継続と判断し各テーブルの状態はそのまま保持し信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図５９のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ８９）を受信すると、デカプセル化し２００ ＯＫ．（Ｓ９０）を端末１（１１）に対して送信する。

端末１（１１）からＢＹＥ（Ｓ９１）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化ＢＹＥ（Ｓ９２）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図６０のようなカプセル化ＢＹＥ（Ｓ９２）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＢＹＥ要求であるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＢＹＥ要求はトランザクション生成信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０６を取得し、先に取得した呼番号、メソッド名（ＢＹＥ）と共に、トランザクション状態管理テーブル（５５）に登録する。

次にダイアログ関連の処理を行い、ＢＹＥ要求は、ダイアログ削除信号であるため、ＦｒｏｍヘッダのｔａｇパラメータとＴｏヘッダのｔａｇパラメータを取得する。なおＢＹＥ要求はプライベート網からグローバル網に対して送信されているため、Ｆｒｏｍヘッダより取得したｔａｇパラメータをｐｒｉｖａｔｅ−ｔａｇ、Ｔｏヘッダより取得したｔａｇパラメータをＧｌｏｂａｌ−ｔａｇとする。また、ＢＹＥ要求で削除するダイアログはＩＮＶＩＴＥダイアログであるため、メソッドとしてＩＮＶＩＴＥを指定して、先に取得した呼番号、Ｐｒｉｖａｔｅ−ｔａｇ、Ｇｌｏｂａｌ−ｔａｇに該当するレコードをダイアログ状態管理テーブル（５６）から削除する。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１９２．１６８．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化ＢＹＥ（Ｓ９３）を送信する。

その後、信号定義テーブル（５３）を参照して終了信号か否かの識別を行うが、ＢＹＥ要求は終了信号ではないため、本処理をスキップし、信号処理を終了する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図６３のようになる。

ＮＡＴ装置（３０）は、カプセル化ＢＹＥ（Ｓ９３）を受信すると、デカプセル化しＢＹＥ（Ｓ９４）を端末２（２１）に対して送信する。

端末２（２１）から２００ ＯＫ（Ｓ９５）が送信されるとＮＡＴ装置（３０）でカプセル化を行い、カプセル化２００ ＯＫ（Ｓ９６）をＳＩＰ−ＡＬＧ（５０）に送信する。ＳＩＰ−ＡＬＧ（５０）の呼処理機能（５１）では、図６２のようなカプセル化２００ ＯＫ（Ｓ９６）を受信すると、信号定義テーブル（５３）を参照して開始信号か否かの識別を行うが、受信信号がＢＹＥ要求の２００ ＯＫであるため開始信号ではないと判断する。その後、カプセル化部分より対向装置識別情報としてＮＡＴ装置（３０）のＩＰアドレス、呼識別情報としてＳＩＰレイヤのＣａｌｌ−ＩＤを取得しそれらの組をキー情報として記録し、そのキー情報を基に呼状態管理テーブル（５４）を参照することにより、当該キー情報と呼番号が呼状態管理テーブル（５４）に登録されていることを確認し、また、呼番号を取得する。

次にトランザクション関連の処理を行い、ＢＹＥ要求の２００ ＯＫはトランザクション削除信号であるため、最上位のＶｉａヘッダよりｂｒａｎｃｈ−ＩＤとしてｚ９ｈＧ４ｂＫ０６を取得し、先に取得した呼番号、メソッド名（ＢＹＥ）に該当するトランザクション状態管理テーブル（５５）のレコードを削除する。

次にダイアログ関連の処理を行うが、ＢＹＥ要求の２００ ＯＫはダイアログ生成信号でも削除信号でもないため、本処理はスキップする。

次に必要となるアドレス変換を行い、ネットワークアドレス管理テーブル（５２）を参照し、１３０．０．０．０／２４が変換対象となるアドレス体系であることを確認する。その結果、Ｖｉａを変換対象として抽出し、変換対象が既にアドレス変換テーブル（５７）に登録されているか参照する。その結果既に登録されているため、変換後のアドレスを取得することができ、ＳＩＰレイヤのアドレス変換を行い、ＮＡＴ装置（３０）に対してアドレス変換後のカプセル化２００ ＯＫ（Ｓ９７）を送信する。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図６３のようになる。

その後、終了信号か否かの識別を行い、ＢＹＥ要求の２００ ＯＫは終了信号であるため、呼番号をキー情報として、トランザクション状態管理テーブル、ダイアログ状態管理テーブルを検索する。その結果、ダイアログ状態管理テーブルに当該レコードが全く存在しないため、呼終了と判断し、アドレス変換テーブルより先に取得した呼番号に対する変換ＩＤを取得し、それらの変換ＩＤを設定し、ＮＡＴ装置（３０）に対して図６４のようなアドレス組削除要求１（Ｓ９９）を送信する。ＮＡＴ装置（３０）より図６５のようなアドレス組削除応答１（Ｓ１００）を受信すると、アドレス変換テーブル上の当該レコードを削除し、また、呼状態テーブルにおいても先に取得した呼番号に関するレコードを削除し信号処理を終了する。

その結果全ての呼関連リソース、呼状態が削除される。その時点での、呼状態管理テーブル（５４）、トランザクション状態管理テーブル（５５）、ダイアログ状態管理テーブル（５６）、アドレス変換テーブル（５７）は図６６のようになる。

ＮＡＴ装置（３０）は、カプセル化２００ ＯＫ（Ｓ９７）を受信すると、デカプセル化し２００ ＯＫ（Ｓ９８）を端末１（１１）に対して送信する。

上記のような処理を行うことで、呼の開始から終了までの呼状態を的確に判断でき、また、呼状態とアドレス変換情報など呼関連リソースを同期させることで、呼開始から呼終了まで呼関連リソースを保持し、呼終了時に削除することが可能となる。

また、対向装置識別情報と呼識別情報の組のように、それぞれの組で異なる長さを持つ文字列情報を、呼状態管理テーブルにより呼番号とすることで、他のテーブルの登録、参照、削除を効率化することが可能となる。

以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

実施例のネットワーク構成を示す図である。 実施例のＳＩＰ−ＡＬＧの構成を示す図である。 実施例のテーブルの連携関係を示す図である。 実施例のネットワークアドレス管理テーブル（５２）を示す図である。 実施例の信号定義テーブル（５３）を示す図である。 実施例の呼状態管理テーブル（５４）を示す図である。 実施例のトランザクション状態管理テーブル（５５）を示す図である。 実施例のダイアログ状態管理テーブル（５６）を示す図である。 実施例のアドレス変換テーブル（５７）を示す図である。 実施例のＩＮＶＩＴＥ／ＯＰＴＩＯＮＳ複合シーケンス（１／３）を示す図である。 実施例のＩＮＶＩＴＥ／ＯＰＴＩＯＮＳ複合シーケンス（２／３）を示す図である。 実施例のＩＮＶＩＴＥ／ＯＰＴＩＯＮＳ複合シーケンス（３／３）を示す図である。 実施例のカプセル化ＩＮＶＩＴＥ（Ｓ２）を示す図である。 実施例のアドレス変換要求１（Ｓ３）を示す図である。 実施例のアドレス変換応答１（Ｓ４）を示す図である。 実施例のアドレス変換要求２（Ｓ５）を示す図である。 実施例のアドレス変換応答２（Ｓ６）を示す図である。 実施例のアドレス変換応答２（Ｓ６）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ１０）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ１０）受信後のテーブル内容を示す図である。 実施例のカプセル化ＡＣＫ（Ｓ１４）を示す図である。 実施例のカプセル化ＡＣＫ（Ｓ１４）受信後のテーブル内容を示す図である。 実施例のカプセル化ＯＰＴＩＯＮＳ（Ｓ１８）を示す図である。 実施例のカプセル化ＯＰＴＩＯＮＳ（Ｓ１８）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ２２）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ２２）受信後のテーブル内容を示す図である。 実施例のカプセル化ＢＹＥ（Ｓ２６）を示す図である。 実施例のカプセル化ＢＹＥ（Ｓ２６）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ３０）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ３０）受信後のテーブル内容を示す図である。 実施例のアドレス組削除要求１（Ｓ３３）を示す図である。 実施例のアドレス組削除応答１（Ｓ３４）を示す図である。 実施例のアドレス組削除応答１（Ｓ３４）受信後のテーブル内容を示す図である。 実施例のＳＵＢＳＣＲＩＢＥ／ＩＮＶＩＴＥ複合シーケンス（１／４）を示す図である。 実施例のＳＵＢＳＣＲＩＢＥ／ＩＮＶＩＴＥ複合シーケンス（２／４）を示す図である。 実施例のＳＵＢＳＣＲＩＢＥ／ＩＮＶＩＴＥ複合シーケンス（３／４）を示す図である。 実施例のＳＵＢＳＣＲＩＢＥ／ＩＮＶＩＴＥ複合シーケンス（４／４）を示す図である。 実施例のカプセル化ＳＵＢＳＣＲＩＢＥ（Ｓ５２）を示す図である。 実施例のアドレス変換要求１（Ｓ５３）を示す図である。 実施例のアドレス変換応答１（Ｓ５４）を示す図である。 実施例のアドレス変換応答１（Ｓ５４）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ５８）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ５８）受信後のテーブル内容を示す図である。 実施例のカプセル化ＮＯＴＩＦＹ（Ｓ６２）を示す図である。 実施例のカプセル化ＮＯＴＩＦＹ（Ｓ６２）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ６６）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ６６）受信後のテーブル内容を示す図である。 実施例のカプセル化ＩＮＶＩＴＥ（Ｓ７０）を示す図である。 実施例のアドレス変換要求２（Ｓ７１）を示す図である。 実施例のアドレス変換応答２（Ｓ７２）を示す図である。 実施例のアドレス変換応答２（Ｓ７２）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ７６）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ７６）受信後のテーブル内容を示す図である。 実施例のカプセル化ＡＣＫ（Ｓ８０）を示す図である。 実施例のカプセル化ＡＣＫ（Ｓ８０）受信後のテーブル内容を示す図である。 実施例のカプセル化ＮＯＴＩＦＹ（Ｓ８４）を示す図である。 実施例のカプセル化ＮＯＴＩＦＹ（Ｓ８４）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ８８）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ８８）受信後のテーブル内容を示す図である。 実施例のカプセル化ＢＹＥ（Ｓ９２）を示す図である。 実施例のカプセル化ＢＹＥ（Ｓ９２）受信後のテーブル内容を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ９６）を示す図である。 実施例のカプセル化２００ ＯＫ（Ｓ９６）受信後のテーブル内容を示す図である。 実施例のアドレス組削除要求１（Ｓ９９）を示す図である。 実施例のアドレス組削除応答１（Ｓ１００）を示す図である。 実施例のアドレス組削除応答１（Ｓ１００）受信後のテーブル内容を示す図である。

符号の説明

１０…プライベート網、１１…端末１、２０…グローバル網、２１…端末２、３０…ＮＡＴ装置、４０…管理網、５０…ＳＩＰ−ＡＬＧ、５１…呼処理機能、５２…ネットワークアドレス管理テーブル、５３…信号定義テーブル、５４…呼状態管理テーブル、５５…トランザクション状態管理テーブル、５６…ダイアログ状態管理テーブル、５７…アドレス変換テーブル

Claims (5)

1. ＩＰ通信網において、ネットワークアドレス変換機能を備えたＮＡＴ装置があり、
   前記ＮＡＴ装置は、ＳＩＰ信号を検出すると、自身のＩＰアドレスを被せて前記ＳＩＰ信号をカプセル化し、ＳＩＰ−ＡＬＧに対してカプセル化ＳＩＰ信号を送信する手段と、前記ＳＩＰ−ＡＬＧから送信されたカプセル化信号を受信しデカプセル化し、ＳＩＰ信号に戻す手段を有し、また、前記ＳＩＰ−ＡＬＧからアドレス変換要求されたＩＰアドレス、ポート番号に対して、変換先のＩＰアドレス、ポート番号を払い出し、変換前後のアドレス組を管理し、前記ＳＩＰ−ＡＬＧに対してアドレス変換の結果を応答する手段と、前記ＳＩＰ−ＡＬＧからの前記アドレス組の削除要求に対して払い出したアドレス組を削除する手段を有しており、
   前記ＮＡＴ装置を跨いだネットワーク間に置かれた端末同士のＳＩＰ通信について、ＳＩＰの呼の開始時または継続時において、前記ＮＡＴ装置と連携しＳＩＰレイヤのアドレス変換およびアドレス変換情報の保持を行い、また、ＳＩＰの呼終了時において、先に保持したアドレス変換情報の削除を行い、前記ＮＡＴ装置に対してもアドレス変換情報の削除要求を行うＳＩＰ−ＡＬＧにおけるＳＩＰの呼状態を管理する方法であって、
   ＳＩＰの呼開始時より呼終了時まで１つの呼の中でトランザクション、ダイアログが生成される毎に、当該トランザクション、ダイアログの情報を登録し、また、トランザクション、ダイアログが削除される毎に、当該トランザクション、ダイアログの情報を削除することで、トランザクション、ダイアログの有無の状態を管理し、
   トランザクションとダイアログが少なくとも１つでも存在する場合は呼継続と判断し、前記アドレス変換情報を含む呼関連リソースを保持し、トランザクション、ダイアログが全て存在しなくなった場合に呼終了と判断し、ＳＩＰ−ＡＬＧ上の前記アドレス変換情報を含む呼関連リソースの削除と、前記ＮＡＴ装置で管理されているアドレス変換情報の削除要求を行うＳＩＰ−ＡＬＧの呼状態管理方法。
2. 請求項１に記載のＳＩＰ−ＡＬＧの呼状態管理方法であって、
   前記ＳＩＰ−ＡＬＧは、前記呼関連リソースを管理するためのキー情報を格納する呼状態管理テーブルと、トランザクション状態を管理するトランザクション状態管理テーブルと、ダイアログ状態を管理するダイアログ状態管理テーブルと、アドレス変換情報を格納するアドレス変換テーブルを備え、
   前記ＳＩＰ−ＡＬＧが前記ＮＡＴ装置からカプセル化ＳＩＰ信号を受信した時に、呼を開始する信号（開始信号）であった場合は、カプセル化部分の送信元アドレスよりＮＡＴ装置のＩＰアドレスを対向装置識別情報として取得し、さらにＳＩＰ信号のＳＩＰレイヤより呼を識別するための情報を呼識別情報として取得し、それらをＳＩＰ−ＡＬＧにおける呼関連リソースを管理するためのキー情報とし、呼状態管理テーブルを参照し、既に当該キー情報が登録されていれば何もせず後続処理に移し、未登録であった場合は呼状態管理テーブルに登録し後続処理に移し、開始信号以外の信号であった場合は、受信したカプセル化ＳＩＰ信号より前記キー情報を取得し、呼状態管理テーブルを参照し、当該キー情報が存在していれば呼状態管理テーブルに対して何もせず後続処理に移し、当該キー情報が存在していなければ異常状態とみなし、受信信号を破棄し処理を終了する第１のステップと、
   前記第１のステップで処理を継続した場合、トランザクションを生成する信号か、トランザクションを削除する信号か、トランザクションの生成削除に関わらない信号かを識別し、トランザクション生成信号であった場合は、ＳＩＰレイヤよりトランザクションを識別するための情報であるトランザクション識別情報を収集し、トランザクション状態管理テーブルに対し、前記呼状態管理テーブルに登録したキー情報と連携させて、収集したトランザクション識別情報の登録を行い、トランザクション削除信号であった場合は、トランザクション生成信号の場合と同様にトランザクション識別情報を収集し、前記トランザクション状態管理テーブルから、収集したトランザクション識別情報の削除を行うことで、当該呼のトランザクションの有無を管理し、トランザクションの生成削除に関わらない信号であった場合は、トランザクション状態管理テーブルに対して何も行わず、既存の状態を保持する第２のステップと、
   前記第１のステップで処理を継続した場合、ダイアログを生成する信号か、ダイアログを削除する信号か、それ以外かを識別し、ダイアログを生成する信号であった場合は、ＳＩＰレイヤよりダイアログを識別するための情報であるダイアログ識別情報を収集し、ダイアログ状態管理テーブルに対し、前記呼状態管理テーブルに登録したキー情報と連携させて、収集したダイアログ識別情報の登録を行い、ダイアログを削除する信号であった場合は、ダイアログ識別情報を取得し、前記ダイアログ状態管理テーブルから、収集したダイアログ識別情報の削除を行い、それ以外の信号であった場合は、ダイアログ状態管理テーブルに対して何も行わず、既存の状態を保持する第３のステップと、
   前記第２および第３のステップの後、呼を終了させる信号（終了信号）であった場合、前記トランザクション状態管理テーブルおよび前記ダイアログ状態管理テーブルを検索し、前記トランザクション状態管理テーブル、前記ダイアログ状態管理テーブルに、当該終了信号より収集したキー情報に関わる情報が１つでも残っている場合は、前記呼状態管理テーブルの前記キー情報を削除せず、呼は継続するものと判断し、それらの情報を保持したままで処理を終了し、前記トランザクション状態管理テーブルと、前記ダイアログ状態管理テーブルに、それぞれ当該トランザクション識別情報と、当該ダイアログ識別情報が全く存在しない場合は、呼の終了とみなし、前記呼状態管理テーブルのキー情報を削除した上で処理を終了する第４のステップと、
   を有するＳＩＰ−ＡＬＧの呼状態管理方法。
3. 請求項２に記載のＳＩＰ−ＡＬＧの呼状態管理方法であって、
   ＩＮＶＩＴＥ要求、ＲＥＧＩＳＴＥＲ要求、ＯＰＴＩＯＮＳ要求、ＲＥＦＥＲ要求、ＳＵＢＳＣＲＩＢＥ要求、ＭＥＳＳＡＧＥ要求を開始信号と定義し、
   ＡＣＫ要求、ＢＹＥ要求に対する２ｘｘ〜６ｘｘ応答、ＲＥＧＩＳＴＥＲ要求に対する２ｘｘ〜６ｘｘ応答、ＯＰＴＩＯＮＳ要求に対する２ｘｘ〜６ｘｘ応答、ＮＯＴＩＦＹ要求に対する２ｘｘ〜６ｘｘ応答、ＭＥＳＳＡＧＥ要求に対する２ｘｘ〜６ｘｘ応答、ＲＥＦＥＲ要求に対する３ｘｘ〜６ｘｘ応答、ＳＵＢＳＣＲＩＢＥ要求に対する３ｘｘ〜６ｘｘ応答を終了信号と定義し、
   ＡＣＫ要求を除くＳＩＰの要求信号をトランザクション生成信号として定義し、
   ＩＮＶＩＴＥ以外の要求に対する最終応答、ＩＮＶＩＴＥ要求に対する２ｘｘ信号、ＩＮＶＩＴＥ要求に対する３ｘｘ〜６ｘｘ応答後のＡＣＫ要求をトランザクション削除信号として定義し、
   ＩＮＶＩＴＥダイアログに対してはＩＮＶＩＴＥ要求に対する２ｘｘ応答、ＲＥＦＥＲダイアログに対してはＲＥＦＥＲ要求に対する２ｘｘ応答、ＳＵＢＳＣＲＩＢＥダイアログに対してはＳＵＢＳＣＲＩＢＥ要求に対する２ｘｘ応答を、ダイアログを生成する信号として定義し、
   ＩＮＶＩＴＥダイアログに対してはＢＹＥ要求、ＲＥＦＥＲダイアログまたはＳＵＢＳＣＲＩＢＥダイアログに対してはＳｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダにｔｅｒｍｉｎａｔｅｄと書かれたＮＯＴＩＦＹ要求を、ダイアログを削除する信号として定義し、
   定義した情報を、プログラムに直接書き込むか、または定義ファイルもしくはテーブルに格納し、前記定義した情報を参照して、開始信号、終了信号、トランザクションの生成信号、トランザクションの削除信号、ダイアログの生成信号、ダイアログの削除信号を判定するＳＩＰ−ＡＬＧの呼状態管理方法。
4. 請求項２に記載のＳＩＰ−ＡＬＧの呼状態管理方法であって、
   前記キー情報を基に、アドレス変換情報を含む呼関連リソースを管理するテーブルを配備した状態において、
   前記第３のステップと第４のステップの間で、アドレス変換の必要がある場合は前記ＮＡＴ装置に対しアドレス変換要求を行い、前記キー情報に対するレコードとして、前記アドレス変換テーブルに登録し、
   前記第４のステップにおいて、呼を継続し呼状態管理テーブルのキー情報を保持する場合は、呼関連リソースにおける当該キー情報に関わるレコードも保持し、呼を終了し呼状態管理テーブルのキー情報を削除する場合は、呼関連リソースにおける当該キー情報に関わるレコードも削除し、
   呼状態管理テーブルのキー情報の有無と、当該キー情報に関わる呼関連リソースの有無の同期をとることにより、呼の開始から終了までの期間、呼関連リソースを管理するＳＩＰ−ＡＬＧの呼状態管理方法。
5. 請求項２に記載のＳＩＰ−ＡＬＧの呼状態管理方法であって、
   対向装置識別情報と呼識別情報の組をキー情報としているＳＩＰ−ＡＬＧが備える全てのテーブルについて、
   呼状態管理テーブルに対向装置識別情報と呼識別情報の組をキー情報として登録する時に、各キー情報に対する呼番号を払い出し、呼状態管理テーブルにおいて、対向装置識別情報と呼識別情報の組と呼番号の関連を管理し、
   対向装置識別情報と呼識別情報の組をキー情報としている、その他のテーブルに情報を登録、参照、削除する際に、対向装置識別情報と呼識別情報の組を基に呼状態テーブルを検索し、得られた呼番号を用いて各情報を管理するＳＩＰ−ＡＬＧの呼状態管理方法。

Images