JP2006345231A

JP2006345231A - Ｓｉｐ−ａｌｇ方法

Info

Publication number: JP2006345231A
Application number: JP2005169072A
Authority: JP
Inventors: Kiyoshi Amano; 潔天野; Nobuaki Tanaka; 信顕田中; Takashi Kosaka; 岳志匂坂
Original assignee: IMAGE PARTNER KK
Current assignee: IMAGE PARTNER KK
Priority date: 2005-06-09
Filing date: 2005-06-09
Publication date: 2006-12-21

Abstract

【課題】シグナリング異常時からの迅速な復旧を可能にするＳＩＰ−ＡＬＧ方法を提供する。
【解決手段】本発明は、２つのユーザエージェント（ＵＡ１、ＵＡ２）間のセッションの確立をＳＩＰ−ＡＬＧを介して行なうＳＩＰ−ＡＬＧ方法において、セッションの開始から終了までを複数のフェーズに分割し、フェーズの１つでセッションに異常が発生したとき、異常が発生したフェーズの段階に応じて、少なくとも１つのユーザエージェントとＳＩＰ−ＡＬＧとの間で復旧信号を通信させることにより初期状態に復旧させる。
【選択図】図１

Description

本発明は、ＳＩＰ−ＡＬＧ方法に関し、特に、状態正常化シグナリングを行なうＳＩＰ−ＡＬＧ方法に関する。

ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）は、双方向型セッションの開始、変更、終了を行うための呼制御（シグナリング）を実現するプロトコルである。セッションとは、関係する相手同士でのデータ交換をいう。ＳＩＰはインターネット技術の国際的な標準化組織であるＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）によって、１９９９年３月にＲＦＣ２５４３として策定された。ＲＦＣ２５４３はその後、２００２年６月にＲＦＣ３２６１として改版されている。そして現在２００４年でも、ＳＩＰは拡張仕様が検討、策定され、より実用性の高いプロトコルを目指して発展を続けている。

下記の表１に示すように、ＳＩＰの他にもＩＰ網上でのシグナリングプロトコルは複数のものが策定されている。その中でもＩＴＵ−Ｔ（ＩｎｔｅｒｎａｔｉｏｎａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓｅｃｔｏｒ）によって策定されたＨ．３２３は、策定時期が早かったことなどの理由から従来まで数多くの適用実績がある。今日Ｈ．３２３と肩を並べるまでに台頭を果たし、さらに今後主流となりつつあるＳＩＰには、Ｈ．３２３にはない次のような特長がある。
インターネットとの親和性が高い
ＳＩＰはＷｅｂコンテンツの転送に使われるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）や、メールの送信に使われるＳＭＴＰ（ＳｉｍｐｌｅＭａｉｌＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）といったプロトコルが備える特長を活かし、ＩＰ網上での動作を基本として考え出されたものである。そのためＳＩＰはＨ．３２３と比較して、インターネットで利用される様々なプロトコルとの親和性が高いものとなっている。
軽量で拡張性が高い
Ｈ．３２３が複数のプロトコルを組み合わせているため複雑になっているのに対して、ＳＩＰはシグナリングの手順をはじめシンプルな仕様であるため軽量である。またＳＩＰは他のプロトコルと組み合わせることによって機能を付加することができ、拡張性も高い。
テキストベースで抜いやすい
Ｈ．３２３がバイナリで記述されるのに対して、ＳＩＰはテキストで記述されるため、特に開発や運用保守に際してデバッグが比較的容易となっている。またテスト用の特別な機器を用意する必要もなく扱いやすい。

このような特長をもつＳＩＰは、ＩＰ綱上での音声通話（固定電話、携帯電話）をはじめ、ビデオ通信やチャットなどへ応用がなされ、普及を始めている。

ＳＩＰによる通信の構成要素
ＳＩＰはＨＴＴＰと同様、クライアント／サーバ型のトランザクションモデルを採用している。つまりＳＩＰによる通信ではクライアントからリクエストが送出され、それに対するレスポンスがサーバから返されるという形式をとる。またＳＩＰではピアツーピア型の通信を行うため、単一のセッションの間でもエンドポイントの役割は変化するのが普通である。エンドポイントは、通信の内容に応じてクライアント（リクエストを送る側）にもなれば、サーバ（レスポンスを返す側）のいずれにもなる。

ＳＩＰによる通信の構成要素は、図１に示すようにユーザエージェント１０、１２、ＳＩＰサーバ１４、ロケーションサーバ１６の大きく３つに分けられる。

ユーザエージェント１０、１２のエンドポイント間では、サーバ１４を経由して間接に、または相手同士で直接に、ＳＩＰによるシグナリングを行う。シグナリングによりセッションが確立した後、実際に音声や映像などメディアの交換が直接に行われる。
ユーザエージェント
ＳＩＰによる通信のエンドポイントに相当するのが、ユーザエージェント（ＵＡ：ＵｓｅｒＡｇｅｎｔ）である。ユーザのフロントエンドとして、セッションを確立するためのＳＩＰメッセージの送受信やメディアの送受信などの処理を行う。

ＵＡはユーザエージェントクライアント（ＵＡＣ：ＵｓｅｒＡｇｅｎｔＣｌｉｅｎｔ）とユーザエージェントサーバ（ＵＡＳ：ＵｓｅｒＡｇｅｎｔＳｅｒｖｅｒ）という２つの機能モジュールに分けられる。ＵＡＣはリクエストを開始する機能モジュールである。それに対して、ＵＡＳは受け取ったリクエストに対するレスポンスを生成する機能モジュールである。ＵＡには必ずＵＡＣとＵＡＳの両方の機能が含まれており、単一のセッションであっても、どちらの機能も利用される。

ＵＡの実装例としては、ＳＩＰ電話端末、パソコンやＰＤＡ上で動作するソフトウェア（ソフトフォン）が挙げられる。図２にソフトフォンの例を示す。
ＳＩＰサーバ
ＳＩＰサーバは、ＵＡ間で行われるシグナリングの経路上に位置し、セッション確立を仲介する処理を行う。ＳＩＰサーバ１４はさらにプロキシサーバ１４ａ、リダイレクトサーバ１４ｂ、レジストラ１４ｃの３つに分けられる。
プロキシサーバ
プロキシサーバ（ＰｒｏｘｙＳｅｒｖｅｒ）１４ａは、ＵＡの代理としてＳＩＰメッセージを中継する。プロキシサーバは、ＳＩＰメッセージを受け取るとロケーションサーバに問い合わせを行うことで宛先を判断し、リクエストをＵＡＳに、レスポンスをＵＡＣに転送する。ネットワークの構成に応じて、複数のプロキシサーバが経由されることもある。
リダイレクトサーバ
リダイレクトサーバ（ＲｅｄｉｒｅｃｔＳｅｒｖｅｒ）１４ｂは、ＵＡやプロキシサーバからリクエストを受け取ると、リダイレクトレスポンス（ステータスコードが３ｘｘのレスポンス）を返す。このレスポンスにはＵＡやプロキシサーバがリクエストを送り直すべき宛先が記述される。プロキシサーバとは異なり、リダイレクトサーバはＳＩＰメッセージを転送することはない。
レジストラ
レジストラ（Ｒｅｇｉｓｔｒａｒ）１４ｃは、ＵＡの現在位置を登録するリクエスト（ＲＥＧＩＳＴＥＲリクエスト）を受け取り、ロケーションサーバのデータベースに反映する。この情報は同一の管理ドメイン下にあるプロキシサーバやリダイレクトサーバによって、ＳＩＰメッセージの適切なルーティングを行うために利用される。
ロケーションサーバ
ロケーションサーバ（ＬｏｃａｔｉｏｎＳｅｒｖｅｒ）１６は、レジストラから登録されるＵＡの情報を保持し、それをプロキシサーバやリダイレクトサーバによって利用されるデータベースとして提供する。ＳＩＰではロケーションサーバへのアクセス方法を規定していないため、レコードに対する操作には別プロトコルが利用される。
ＳＩＰメッセージ
ＳＩＰＵＲＩ
ＳＩＰによる通信では、リソースの特定にＵＲＩ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）を利用する。ＳＩＰで新たに定義されたＵＲＩにはＳＩＰＵＲＩとＳＩＰＳＵＲＩの２つがあり、この他にもｔｅｌＵＲＩが利用できる。ここでＳＩＰＳＵＲＩとはＳＩＰのセキュアなＵＲＩであり、ＴＣＰのようなコネクション指向のトランスポートプロトコルを利用する通信に対してＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）による暗号化が施される。ＲＦＣ３２６１では、ＳＩＰのトランスポートプロトコルとしてＴＣＰとＵＤＰが必須とされている。しかし実際には、プロキシのようにシグナリングパス上のサーバにとって、長時間存続するコネクションを維持することが困難な場合がある。そのため実際には多くの場合に、ＵＤＰがトランスポートプロトコルとして利用される。このような理由から、本発明でもＳＩＰのトランスポートプロトコルとしてＵＤＰを想定する。

ＳＩＰＵＲＩとＳＩＰＳＵＲＩの形式は下記の表２のようにＲＦＣ２３９６のガイドラインに従って定義されている。ＳＩＰＵＲＩの一般的な形式は次の通りである。ＳＩＰＳＵＲＩはプロトコルスキームが、“ｓｉｐｓ”になることを除けばＳＩＰＵＲＩと同じ形式である。

下線で示した部分は必ず指定しなくてはならない。各要素の意味は次の通りである。
ｕｓｅｒ宛先となるホストでのユーザＩＤ．ユーザＩＤを指定せずに単にホストを宛先とする場合には、’＠’までを省略することができる。宛先のホストが電話番号を扱える場合には、電話番号を指定することもできる。
ｐａｓｓｗｏｒｄユーザＩＤに関連付けられたパスワード．ただし認証情報を平文で記述することになるため、ＲＦＣ３２６１では使用を推奨していない。実装上は“ｕｓｅｒ：ｐａｓｓｗｏｒｄ”を単一の文字列として扱うことができる。
ｈｏｓｔＳＩＰリソースを提供するホスト．ＦＱＤＮ（ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ）またはＩＰアドレスのいずれでも指定することができるが、ＦＱＤＮを利用することが推奨される。
ｐｏｒｔリクエストの宛先ポート番号．ＵＤＰ、ＴＣＰ、およびＳＣＴＰ（ＳｔｒｅａｍＣｏｎｔｒｏｌＴｒａｎｓｍｉｓｓｉｏｎＰｒｏｔｏｃｏｌ）を使用する”ｓｉｐ”スキームでは５０６０、ＴＣＰ、およびＴＬＳ上のＴＣＰを利用する”ｓｉｐｓ”スキームでは５０６１がデフォルトで利用される。
ｕｒｉ−ｐａｒａｍｅｔｅｒｓＵＲＩパラメータ． ”＜パラメータ名＞＝＜パラメータ値＞”の形式で、各組を’；’で区切ることで複数指定することができる。定義済みパラメータ名にはｔｒａｎｓｐｏｒｔ、ｕｓｅｒ、ｍｅｔｈｏｄ、ｍａｄｄｒ、ｔｔｌ、１ｒなどがあり、独自に追加定義することも可能である。
ｈｅａｄｅｒｓリクエストのヘッダフィールド． ”＜ヘッダ名＞＝＜値＞”の形式で、各組を、’＆’、で区切ることで複数指定することができる。特別なヘッダ名としてｂｏｄｙが定義されており、この値はＳＩＰメッセージのボディとなる。
メッセージの構成
ＳＩＰメッセージはテキストベースのプロトコルであり、文字コードセットとしてＵＴＦ−８（Ｕｎｉ−ｖｅｒｓａｌＴｔａｎｓｆｏｒｍａｔｉｏｎＦｏｒｍａｔ、８−ｂｉｔＦｏｒｍ）を利用する。ＵＴＦ−８とは、文字コードポイント（文字の符号化用に割り当てられた整数値）を、ＡＳＣＩＩとの互換性を持たせつつ、他の文字を可変長のバイト列で符合化する方法である。ＵｎｉｃｏｄｅまたはＵＳＣ（ＵｎｉｖｅｒｓａｌＣｈａｒａｃｔｅｒＳｅｔ）で符合化された文字を、インターネットで転送する際の変換に利用される。

ＳＩＰメッセージは、クライアントからサーバへのリクエスト、またはサーバからクライアントへのレスポンスのいずれかである。これらは詳細なシンタックスは異なるが、共にＲＦＣ２８２２の基本フォーマットを利用する。これらのメッセージは下記の表３に示すように、スタートライン、複数行のヘッダフィールド、ヘッダフィールドの終了を表す空白行、およびオプションのボディからなる。メッセージ内の各行はＣＲＬＦで区切られる。

スタートラインは、メッセージがリクエストの場合に特にリクエストラインと呼ばれる。またメッセージがレスポンスの場合には特にステータスラインと呼ばれる。
リクエスト
リクエストは、メッセージの先頭行にリクエストライン（Ｒｅｑｕｅｓｔ−Ｌｉｎｅ）を持つ。リクエストラインは１つの空白文字（ＳＰ）で区切られた、メソッド名（Ｍｅｔｈｏｄ）、リクエストＵＲＩ（Ｒｅｑｕｅｓｔ−ＵＲＩ）、およびプロトコルのバージョン（ＳＩＰ−Ｖｅｒｓｉｏｎ）からなる。下記の表４にリクエストラインの一般形式を示す。

各要素の意味は次の通りである。
Ｍｅｔｈｏｄリクエストの種別を表す。ＲＦＣ３２６１では、ＵＡのコンタクト情報を登録するためのＲＥＧＩＳＴＥＲ、セッションを構築するためのＩＮＶＩＴＥ、ＡＣＫ、ＣＡＮＣＥＬ、セッションを終了するためのＢＹＥ、およびサーバに能力を問い合わせるためのＯＰＴＩＯＮＳの６種類のメソッドが定義されている。また下記の表５に示すように、これらのメソッドに加えて、付随するその他のＲＦＣでは拡張メソッドも定義されている。

Ｒｅｑｕｅｓｔ−ＵＲＩリクエストの宛先となるユーザやサービスのロケーションを表す。ＳＩＰＵＲＩ、ＳＩＰＳＵＲＩ、またはＲＦＣ２３９６で定義される一般的なＵＲＩとして記述される。
ＳＩＰ−Ｖｅｒｓｉｏｎメッセージの記述に利用するＳＩＰプロトコルのバージョンを表す。ＲＦＣ３２６１に準拠する場合は、“ＳＩＰ／２．０”となる。
レスポンス
レスポンスは、メッセージの先頭行にステータスライン（Ｓｔａｔｕｓ−Ｌｉｎｅ）を持つ。ステータスラインは１つの空白文字（ＳＰ）で区切られた、プロトコルのバージョン（ＳＩＰ−Ｖｅｒｓｉｏｎ）、ステータスコード（Ｓｔａｔｕｓ−Ｃｏｄｅ）、および関連付けられたフレーズ（Ｒｅａｓｏｎ−Ｐｈｒａｓｅ）からなる。下記の表６にステータスラインの一般形式を示す。

各要素の意味は次の通りである。
ＳＩＰ−Ｖｅｒｓｉｏｎリクエストラインの場合と同様、メッセージの記述に利用するＳＩＰプロトコルのバージョンを表す。
Ｓｔａｔｕｓ−Ｃｏｄｅｌ００番台から６００番台までの３桁の整数からなる、リクエストに対する結果を表すコード．下記の表７に、各区分のステータスコードの意味を示す。

ここで１ｘｘはプロビジョナル（暫定）レスポンス、２ｘｘ〜６ｘｘはファイナル（最終）レスポンスに分類される。
Ｒｅａｓｏｎ−Ｐｈｒａｓｅテキストからなる、リクエストに対する結果についての短い説明．Ｓｔａｔｕｓ−Ｃｏｄｅがオートマトンによる使用を意図しているのに対して、Ｒｅａｓｏｎ−Ｐｈｒａｓｅは人間のユーザによる使用を意図したものである。
シグナリングの構成単位
ＳＩＰによるシグナリングでは、連続する複数のメッセージによって意味のあるまとまりが形づくられる。本発明ではその中でも特に重要なトランザクションとダイアログについて触れる。
トランザクション
トランザクションとは、１つのリクエストとそれに村するレスポンス（ゼロ個以上の暫定レスポンス、および１つ以上の最終レスポンス）の組である。最終レスポンスが２ｘｘでない場合に限り、トランザクションにはＡＣＫも含まれる。最終レスポンスが２ｘｘである場合には、ＡＣＫはトランザクションの一部とは見なされない。
ダイアログ
ダイアログとは、トランザクション進行中に持続される、２つのＵＡ間でのピアツーピアの関係である。ＩＮＶＩＴＥリクエストに対する、１００ｔｒｙｉｎｇを除く１ｘｘレスポンス、および２ｘｘレスポンスによって構築される。前者の手続きによって構築されたダイアログはｅａｒｌｙダイアログと呼ばれ、後者の手続きによって構築されたダイアログはｃｏｎｆｉｒｍｅｄダイアログと呼ばれる。

ＳＩＰを利用した通信では、必ずしもサーバ側で状態を保持する必要がないため、端末側でそれぞれの結び付きを一意に保持しなくてはならない。ダイアログはこれを実現するためのものであり、次の３つの要素によって定義される。

・リモートｔａｇ（相手端末が作成したｔａｇ）
・ローカルｔａｇ（自端末が作成したｔａｇ）
・呼識別子
これらは、具体的には後述するＴｏｔａｇ、Ｆｒｏｍｔａｇ、およびＣａｌｌ−ＩＤに関連付けられ、３つの要素を組み合わせたものはダイアログＩＤと呼ばれる。
ヘッダフィールド
ＳＩＰメッセージには、スタートラインに続いて”＜ヘッダ名＞：＜ヘッダ値＞”の形式で複数のヘッダフィールドが続く。ヘッダフィールドは数多くの種類が定義されているが、本発明では特に利用頻度の高いものを選択して取り上げる。ヘッダフィールドの中でも、Ｔｏ、Ｆｒｏｍ、Ｖｉａ、Ｍａｘ−Ｆｏｒｗａｒｄｓ、ＣＳｅｑ、およびＣａ１１−ＩＤの６種類は、すべてのＳＩＰリクエストメッセージに必須である。
Ｔｏ
Ｔｏヘッダフィールドは、リクエストの論理的な受信者を指定する。オプションの表示名（受信者名）は、ユーザインタフェースによって表示されることを意図している。ｔａｇパラメータは、ダイアログの構築に利用される。このヘッダフィールドのコンパクトフォームはｔである。下記の表８にＴｏヘッダフィールドを示す。

Ｆｒｏｍ
Ｆｒｏｍヘッダフィールドは、リクエストのイニシュータ（生成元）を示す。Ｔｏヘッダフィールド同様、オプションの表示名（送信者名）は、エーザインタフエースによって表示されることを意図している。ただしクライアントの身元が隠される場合には、表示名としで、Ａｎｏｎｙｍｏｕｓ”を使用するべきとされている。ｔａｇパラメータは、Ｔｏヘッダフィールド同様、ダイアログの構築に利用される。このヘッダフィールドのコンパクトフォームはｆである。下記の表９にＦｒｏｍヘッダフィールドを示す。

Ｖｉａ
Ｖｉａヘッダフィールドは、リクエストが経由したパスを示す。これはレスポンスが返される時にたどるべきパスとなる。”ｚ９ｈＧ４ｂＫ”（マジッククッキー）で始まるｂｒａｎｃｈパラメ一夕は、トランザクションＩＤとして、ループ検知のためにプロキシサーバによって利用される。Ｖｉａヘッダフィールドは、この他にもｍａｄｄｒ、ｔｔｌ、ｒｅｃｅｉｖｅｄなどのパラメータを含むことができる。このヘッダフィールドのコンパクトフォームはｖである。下記の表１０にＶｉａヘッダフィールドを示す。

Ｒｅｃｏｒｄ−Ｒｏｕｔｅ
Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドは、ダイアログ中のそれ以降のリクエストを、指定したプロキシを経由して転送させるために、プロキシによってリクエストに挿入される。下記の表１１にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドを示す。

Ｒｏｕｔｅ
Ｒｏｕｔｅヘッダフィールドは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドにリストされたプロキシのセットを経由してリクエストを転送させるために利用される。下記の表１２にＲｏｕｔｅヘッダフィールドを示す。

Ｍａｘ−Ｆｏｒｗａｒｄｓ
Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダフィールドは、リクエストをダウンストリームサーバに転送できるプロキシの数を制限するために利用される。Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダフィールドの値は、リクエストが転送されることを認められている残り回数を示す０〜２５５の整数である。このカウントは、そのリクエストを転送する各プロキシでデクリメントされる。推奨される初期値は７０である。下記の表１３にＭａｘ−Ｆｏｒｗａｒｄｓヘッダフィールドを示す。

Ｃｏｎｔａｃｔ
Ｃｏｎｔａｃｔヘッダフィールドは、ユーザがプロキシを経由せずに直接通信するためのＵＲＩ情報を示す。ＲＦＣ３２６１ではパラメータとして、ｑ（品質値）、およびｅｘｐｉｒｅｓ（有効期限値）を定義している。このヘッダフィールドのコンパクトフォームはｍである。下記の表１４にＣｏｎｔａｃｔヘッダフィールドを示す。

Ｅｘｐｌｒｅｓ
Ｅｘｐｉｒｅｓヘッダフィールドは、メッセージまたはコンテンツがそれ以降期限切れになる相対時間を示すが、正確な意味はメソッドに依存する。Ｅｘｐｉｒｅｓヘッダフィールドの値は、リクエストの受信時から計測された０から２^３２−１の間の、秒を表す１０進整数である。下記の表１５にＥｘｐｉｒｅｓヘッダフィールドを示す。

ＣＳｅｑ
ＣＳｅｑヘッダフィールドは、１０進数のシーケンス番号とリクエストのメソッド名の組み合わせで構成される。シーケンス番号は３２ビットの符合なし整数で表現される。ＣＳｅｑヘッダフィールドの値によって、トランザクションが順序付けられる。そのため新規リクエストとリクエストの再送を区別するために利用することができる。下記の表１６にＣＳｅｑヘッダフィールドを示す。

ＣＳｅｑシーケンス番号は、原則として新しいリクエストごとにインクリメントされる。ただし例外的にＡＣＫとＣＡＮＣＥＬリクエストに対しては、振り方が異なる。ＡＣＫリクエストのシーケンス番号は、確認応答の対象となるＩＮＶＩＴＥリクエストのそれと同じである。またＣＡＮＣＥＬリクエストのシーケンス番号は、キャンセルの村象となるリクエストのそれと同じである。

Ｃａｌｌ−ＩＤ
Ｃａｌｌ−ＩＤヘッダフィールドは、特定の招待または特定のクライアントのすべての登録を一意に識別する。Ｃａｌｌ−ＩＤの値はダイアログの構築に利用される。このヘッダフィールドのコンパクトフォームはｉである。下記の表１７にＣａｌｌ−ＩＤヘッダフィールドを示す。

Ｃｏｎｔｅｎｔ−Ｔｙｐｅ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドは、受信者に送られたメッセージボディのメディアタイプを示す。メディアタイプのエレメントはＩＡＮＡ（ＩｎｔｅｒｎｅｔＡｓｓｉｇｎｅｄＮｕｍｂｅｒｓＡｕｔｈｏｒｉｔｙ）によって登録されている。Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドは、ボディが空でない場合には必ず存在しなければならない。このヘッダフィールドのコンパクトフォームはｃである。下記の表１８にＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドを示す。

Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダフィールドは、受信者に送られたメッセージボディのサイズを、オクテット単位の１０進数で示す。ここでメッセージボディのサイズにはヘッダフィールドとボディを分けるＣＲＬＦは含まない。ボディが存在しない場合、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダフィールドの値は０に設定されなければならない。このヘッダフィールドのコンパクトフォームはｌである。下記の表１９にＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダフィールドを示す。

各種プロトコルとの連携
ＳＩＰを利用した通信では、ＳＩＰ以外にも複数のプロトコルが連携して動作する。ここではその中でも、メディアセッションのセットアップに利用されるＳＤＰ、およびメディアによる通信の際に利用されるＲＴＰ／ＲＴＣＰについて触れる。
ＳＤＰ
ＳＤＰ（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ）は、もともとマルチキャスト実験ネットワークＭＢｏｎｅ（ＭｕｌｔｉｃａｓｔＢａｃｋｂｏｎｅ）上で、ユーザをマルチメディア会議に召集したり、ユーザに対してセッションに関する情報を通知するために策定されたプロトコルである。ＳＤＰはＳＩＰと同様にテキストベースであり、次のような情報が記述される。
・セッション記述
セッションの名前、ＩＤ、目的など、セッションを識別する情報
・時間記述
開始時刻、終了時刻、繰り返し回数など、セッションの有効期間に関する情報
・メディア記述
ＩＰアドレスやポート番号、メディアの種別やコーデックなど、メディアに関する情報
ＲＴＰ／ＲＴＣＰ
ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ TｒａｎｓｐｏｆｔＰｒｏｔｏｃｏｌ）は、音声や映像のような実時間性（リアルタイム性）が要求されるデータを利用して、多人数マルチメディア会議のようなサービスをインターネットで実現することを目的に設計されたプロトコルである。現在ではＩＰネットワークでメディアをリアルタイムに転送する目的で広く利用されている。

一方、ＲＴＣＰ（ＲＴＰＣｏｎｔｒｏＩＰｒｏｔｏｃｏｌ）は、ＲＴＰを制御するプロトコルとしてＲＴＰと共に規定されているプロトコルである。ＲＴＣＰは上位アプリケーションに対する、ＲＴＰパケットのフロー制御通知や、送受信端末間でのクロック同期などを行う。

ＲＴＰ／ＲＴＣＰはいずれもトランスポートプロトコルとしてＵＤＰを利用する。また、いずれもバイナリで記述される。

前述したＳＩＰ−ＡＬＧ装置は社団法人電子通信学会信学技法ＮＳ２００３−２０８ＰＮ２００３−３６（２００３−１２）に記載されている。
社団法人電子通信学会信学技法ＮＳ２００３−２０８ＰＮ２００３−３６（２００３−１２）

シグナリング異常時からの復旧
一般にＳＩＰエンティティ（ＵＡやプロキシのようなＳＩＰによる構成要素となるホストを指す）は、トランザクション、またはセッションの開始から。また一方でエンティティの主要な動作は、シグナリングによって決定される。つまりエンティティは、シグナリングがなければ、その動作や状態を変化させることができない。

これはＳＩＰによる通信の途中で、ＵＡが強制終了したり、ユーザ端末がクラッシュするなど、メッセージの再送を行っても復旧できないエラーが発生したときに問題となる。つまりこのときＳＩＰによる適切なシグナリングがないため、パス上のエンティティは初期状態に移行するための通知を受けることができない。これによって、エンティティは復旧までの間、様々なリソースを浪費することになってしまう。

例えば図３のような場合を考える。ＵＡｌとＵＡ２との間ではセッションが確立し、メディアによる通信を開始しているとする。ここでＵＡ２がクラッシュし、セッション終了リクエストであるＢＹＥを生成せずに終了してしまうと、ＵＡｌとプロキシはこのセッションの終了を検知することができない。その結果、ＵＡｌとプロキシは、それぞれこのセッションのために確保したリソースを、無効となった後も保持し続けなければならなくなってしまう。

従来まで、この間題に対する解決策は、エンティティに対して独自にタイマを持たせることでしか実現されていなかった。そのため前述のエラーによってセッションに異常が発生してしまうと、エンティティはリソースの解放をタイムアウトまで個別に待つ必要があった。またエンティティに対して定義されているオートマトンには、タイマが設けられていない状態も存在していた。そのため特定の状態で前述のエラーが発生してしまうと、エンティティはそれを検知することができず、リソースを解放することができなかった。
異種ネットワーク間でのセッション確立
ＳＩＰによるシグナリングでは、メッセージの受信ホストがレスポンスの宛先を判断するためにＩＰおよびＴＣＰ／ＵＤＰヘッダ部分だけでなく、ペイロード部分にも送信ホストのアドレスが記述される。しかし通信を行うエンティティが、ＮＡＴを介して異なるアドレス体系に存在する場合には、図４に示すようにこれが障害となる。

通常のＮＡＴ（ＮｅｔｗｏｒｋＡｄｄｒｅｓｓＴｒａｎｓｌａｔｉｏｎ）では、パケットを転送する際に、ＩＰおよびＴＣＰ／ＵＤＰヘッダ部分に記述されるアドレスを書き換えるが、ペイロード部分ついては関知しない。そのため図４に示すように、リクエスト送信側のＵＡが、レスポンスの宛先としてペイロード内にローカルなアドレスを記述してしまうと、ＮＡＴで変換されないまま転送される。その結果、受信側のＵＡは適切にレスポンスを返すことができなくなってしまう。つまり、アドレス体系の異なるネットワーク内に存在する２つのエンティティは、通常のＮＡＴを経由するだけでは通信を行うことができない。

この間題の解決策として、ＳＩＰを利用した通信でＮＡＴを実現するアプローチには複数のものが存在する。それぞれにメリットやデメリットがあり、現時点（２００４年）では必ずしも完成されたものではない。本発明ではＳＩＰで採用されている手法のうちのいくつかを取り上げる。
ＵＰｎＰ
ＵＰｎＰ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ）とは、ＵＰｎＰＦｏｒｕｍで規定された規格で、ＰＣやＡＶ機器など家庭内のいろいろな機器をネットワークを通じて接続し、相互に機能を提供しあう技術である。ＵＰｎＰを利用すると、プライベートネットワーク内のホストからＵＰｎＰ対応のルータに対して、ルータのもつパブリックなＩＰアドレスの割り当てや、ポート番号のマッピングを要求することができる。

ルータに加えてＳＩＰを利用するホストでもＵＰｎＰに対応すれば、プライベートネットワークとパブリックネットワークとの間で、ＳＩＰを利用して通信することができるようになる。ただし現時点ではＵＰｎＰに対応したルータ（ＵＰｎＰサーバ）は数多く存在するものの、ＵＡやプロキシなどＳＩＰアプリケーションでＵＰｎＰに対応したもの（ＵＰｎＰクライアント）は非常に少ない。
ＳＴＵＮ
ＳＴＵＮ（ＳｉｍｐｌｅＴｒａｖｅｒｓａｌｏｆＵＤＰｔｈｒｏｕｇｈＮＡＴｓ）とは、アプリケーションがパブリックネットワークとの間のＮＡＴ、およびファイアウォールの存在とタイプを発見することを可能にする軽量プロトコルである。ＳＴＵＮは、ＮＡＴがプライベートネットワーク内のホストに割り当てたパブリックなＩＰアドレスやポート番号を、アプリケーションに通知することができる。

ただしこの方法を利用するためには、パブリックネットワーク内にＳＴＵＮサーバが必要となり、プライベートネットワーク内のＳＩＰを利用するホストでもＳＴＵＮに対応する必要がある。これに加えて、途中に介在するＮＡＴの動作がコーン型でなければならない。つまり、ＮＡＴの内側の同じＩＰアドレス、ポート番号から外側にパケットを送信する際に、ＮＡＴの外側に割り当てられるＩＰアドレス、ポート番号が常に同じである必要がある。
Ｂ２ＢＵＡ
Ｂ２ＢＵＡ（ＢａｃｋｔｏＢａｃｋＵｓｅｒＡｇｅｎｔ）とは、リクエストを受け取り、ＵＡＳとしてそれを処理する論理的なエンティティである。同時に、そのリクエストに対してどのようなレスポンスを返すかを決定するためにＵＡＣとして動作し、リクエストを生成する。つまり、プライベートなＵＡとパブリックなＵＡが結合されたもので、それぞれのネットワークに対して独立したＵＡとして動作する。プロキシとは違い、ダイアログの状態を保持し、それが確立したすべてのリクエストに関与しなければならない。動作に関する明示的な定義はされていない。

この方法を利用するメリットとしては、ＵＡやプロキシでは特別な処理を一切行う必要がない点がある。逆にデメリットとしては、Ｂ２ＢＵＡに対して負荷が集中するため、高い処理性能が求められるという点がある。
ＡＬＧ
ＡＬＧ（ＡｐｐｌｉｃａｔｉｏｎＬｅｖｅｌＧａｔｅｗａｙ）とは、ＮＡＴまたはファイアウォール上で通過するＳＩＰメッセージを解析し、メッセージ内のプライベートなアドレスとパブリックなアドレスの変換を一括して行う方法である。動作に関する明示的な定義はされていないが、多くの検討がされてきている。

ＡＬＧはＢ２ＢＵＡと同様、サーバサイドに限定したアプローチであり、これらはタスクについても多くの共通点がある。実際、この方法を利用するメリットおよびデメリットは、Ｂ２ＢＵＡの場合と同様である。ただしＢ２ＢＵＡは、ＵＡをベースとしているため、ＵＡに対して定義されているオートマトンに基づく必要がある。それに対して、ＡＬＧにはその必要がないという相違点がある。ＡＬＧを利用することによって、Ｂ２ＢＵＡよりも柔軟な実装が可能になる。

したがって、本発明の目的は、シグナリング異常時からの迅速な復旧を可能にするＳＩＰ−ＡＬＧ方法を提供することにある。

本発明は、２つのユーザエージェント（ＵＡ１、ＵＡ２）間のセッションの確立をＳＩＰ−ＡＬＧを介して行なうＳＩＰ−ＡＬＧ方法において、セッションの開始から終了までを複数のフェーズに分割し、フェーズの１つでセッションに異常が発生したとき、異常が発生したフェーズの段階に応じて、少なくとも１つのユーザエージェントとＳＩＰ−ＡＬＧとの間で復旧信号を通信させることにより初期状態に復旧させることを特徴とする。

本発明によれば、セッションの開始から終了までの個々のフェーズにおけるシグナリング異常時から迅速な復旧が可能なＳＩＰ−ＡＬＧ方法が得られる。

状態正常化シグナリングに基づくＳＩＰ−ＡＬＧ：
状態正常化シグナリング
ＳＩＰでのセッション異常時からの復旧問題を解決するために、本発明では状態正常化シグナリングに基づくＳＩＰ−ＡＬＧ装置を提案する。ここで状態正常化シグナリングとは、サーバがセッションの異常を検知したときに、適切なシグナリングを行うことによって、セッションを正常に終了させる手続きをいう。これによって、パス上のエンティティに対して、迅速かつ適切な状態遷移を促すことが可能となる。各エンティティは初期状態へ移行し、無効となったセッションのために確保されていたリソースを解放する。

本発明では、セッションを監視し、状態正常化シグナリングを行うサーバとしてＳＩＰ−ＡＬＧを利用する。この理由は、ＡＬＧではシグナリングとメディアの両方を監視することができるためである。ＡＬＧを利用することによって異種ネットワーク間接続が可能となるが、ＡＬＧはセッションを通して、シグナリングとメディアの両方が必ず経由するポイントともなる。本発明では、ＳＩＰ−ＡＬＧに対して、自律的シグナリング機能、およびメディアモニタリング機能を付加することによって、状態正常化シグナリングを実現する。
自律的シグナリング
自律的シグナリングとは、セッションの状態に応じて、適切なメッセージ（リクエストおよびレスポンス）を生成する機能モジュールである。従来までＳＩＰ−ＡＬＧは、受け取ったメッセージを適切に変換し、送り出すだけであった。そのためＡＬＧは、呼の状態を保持し、特定のオートマトンに基づいて動作する、つまりステートフルである必要はなく、ステートレスな実装で十分であった。またＡＬＧは外部からの入力を受けてはじめて、その出力としてシグナリングを行うため、自身でメッセージを生成する必要もなかった。ここで、ＡＬＧが自律的シグナリングを行えるようにするためには、次の２点で拡張が必要となる。
セッションの状態管理
対象となるセッションの状態を把握することができるようにするために、シグナリングを監視し、セッションの継続中はその状態を保持する必要がある。
トランザクションの生成
自身でシグナリングを行うことができるようにするために、メッセージ（リクエストおよびレスポンス）を動的に生成し、トランザクションを適切に処理する必要がある。
メディアモニタリング
メディアモニタリングとは、メディアセッションを監視し異常を検知した場合に、自律的シグナリングモジュールに対してそれを通知する機能モジュールである。これによりセッションを通して、シグナリングだけではなくメディアも監視の対象とすることが可能となる。
セッションを構成するシグナリングのフェーズ分割
本発明では、ＩＮＶＩＴＥ−１００Ｔｒｙｉｎｇ／１８０Ｒｉｎｇｉｎｇ−２００ＯＫ−ＡＣＫで開始し、ＢＹＥ−２００ＯＫで終了する最も一般的なセッションについて、状態正常化シグナリングのコールフローを検討する。セッションを終了しＳＩＰエンティティを初期状態に移行させるための手続きは、その時点でのセッションの状態によって異なる。そこで本発明では、一連のセッションをそれぞれ状態の異なる５つのフェーズに分割する。その上で、どのフェーズでシグナリングまたはメディアの異常が発生したかによって、その後に行うべきシグナリングを決定する。図５にセッションの各フェーズを示す。ここでＦｌ、Ｆ３、Ｆ７、Ｆ９、およびＦｌｌは、それぞれのフェーズに移行するトリガとなるメッセージである。
フェーズＩ
ＳＩＰ−ＡＬＧは初期状態（セッションが開始されていない状態）にあるとき、ＳＩＰＵＡｌからのＦ１−ＩＮＶＩＴＥを確認することによってフェーズＩに移行する。フェーズＩに移行した後、ＳＩＰＵＡ２から一定時間内にレスポンスがないことを検知すると、セッションに異常が発生したとみなし、状態の正常化シグナリングを開始する。図６にフェーズＩから復旧するコールフローを示す。

ＡＬＧはＵＡｌに対して、まずリクエストＦｌに対する最終エラーレスポンスＦ３を返す。続いてＵＡｌからのＦ４によって、ＡＬＧとＵＡｌ間のトランザクションが正常形で終了する。

またＡＬＧはＵＡ２に対しては、シグナリングを行わない。これはＡＬＧとＵＡ２との間でダイアログが確立されていないことに基づいている。この状態ではＣＡＮＣＥＬによるリクエストのキャンセルや、ＢＹＥによるダイアログの終了は、ＲＦＣ３２６１では認められていない。
フェーズＩＩ
ＳＩＰ−ＡＬＧはフェーズＩにあるとき、ＳＩＰＵＡ２からのＦ３−１００Ｔｒｙｉｎｇ、およびその他の暫定レスポンスを確認することによってフェーズＩＩに移行する。フェーズＩＩに移行した後、ＵＡ２から一定時間内に最終レスポンスがないことを検知すると、セッションに異常が発生したとみなし、状態の正常化シグナリングを開始する。図７にフェーズＩＩから復旧するコールフローを示す。

ＡＬＧはＵＡｌに対して、フェーズＩと同様のシグナリングを行う。またＡＬＧはＵＡ２に対しては、Ｆ８によってリクエストＦｌのキャンセルを試みる。もしもＵＡ２からのレスポンスがあればＦｌ０〜Ｆ１２によって、ＡＬＧとＵＡ２間のトランザクションが正常形で終了する。
フェーズＩＩＩ
ＳＩＰ−ＡＬＧはフェーズＩまたはフェーズＩＩにあるとき、ＳＩＰＵＡ２からのＦ７−２００ＯＫを確認することによってフェーズＩＩＩに移行する。フェーズＩＩＩに移行した後、ＳＩＰＵＡｌから一定時間内にトランザクションを終了するＡＣＫリクエストがないことを検知すると、セッションに異常が発生したとみなし、状態の正常化シグナリングを開始する。図８にフェーズＩＩＩから復旧するコールフローを示す。

まずＡＬＧはリクエストＦｌおよびレスポンスＦ７によって構築されたトランザクションを終了させる。ＡＬＧはあたかもＵＡｌからのメッセージであるかのようにしてＦ９を生成し、ＵＡ２に対してトランザクションが正常形で終了したように見せる。

次にＡＬＧはＵＡｌ、ＵＡ２に村してそれぞれＦｌ０、Ｆｌｌによって、確立したセッションを終了させる。ＡＬＧはこれらをそれぞれあたかもＵＡ２、ＵＡｌからのメッセージであるかのようにして生成する。ここでＵＡｌはＡＣＫを送り出す前にＢＹＥを受け取ることになるが、ＲＦＣ３２６１では、ＵＡＳはｃｏｎｆｉｒｍｅｄダイアログ上ではＢＹＥを送ることが認められている。

最後にＡＬＧはＵＡｌ、ＵＡ２からの最終成功レスポンスＦ１２、Ｆ１３を傍受する。これにより、Ｆｌ０、Ｆｌｌによって開始されたトランザクションがそれぞれ正常形で終了する。ただしこのときＵＡｌはシグナリングが行えない状態にあると考えられるため、Ｆ１２は実際には行われない可能性が高い。
フェーズＩＶ
ＳＩＰ−ＡＬＧはフェーズＩＩＩにあるとき、ＳＩＰＵＡｌからのＦ９−ＡＣＫを確認することによってフェーズＩＶに移行する。フェーズＩＶに移行した後、片方向または両方向からメディアが一定時間ないことを検知すると、セッションに異常が発生したとみなし、状態の正常化シグナリングを開始する。図９にフェーズＩＶから復旧するコールフローを示す。

ＡＬＧによって行われるシグナリングＦｌｌ〜Ｆ１４は、フェーズＩＩＩからの復旧でのＦｌ０〜Ｆ１３と同様である。ただしこのときＵＡｌまたはＵＡ２はシグナリングが行えない状態にあると考えられるため、Ｆ１３またはＦ１４は実際には行われない可能性が高い。
フェーズＶ
ＳＩＰ−ＡＬＧはフェーズＩＶにあるとき、ＳＩＰＵＡｌ（またはＳＩＰＵＡ２）からのＦｌｌ−ＢＹＥを確認することによってフェーズＶに移行する。フェーズＶに移行した後、ＵＡ２（またはＵＡｌ）から一定時間内に最終レスポンスがないことを検知すると、セッションに異常が発生したとみなし、状態の正常化シグナリングを開始する。図１０にフェーズＶから復旧するコールフローを示す。

ここでは、ＡＬＧはリクエストＦｌｌによって開始されたトランザクションを終了させるだけである。ＡＬＧはあたかもＵＡ２からのメッセージであるかのようにしてＦ１３を生成し、ＵＡｌに対してトランザクションが正常形で終了したように見せる。

実施例環境
本発明では提案方式に基づいて状態正常化シグナリングを行うＳＩＰ−ＡＬＧを実装し、図１１のような環境で検証実施例を行った。ＳＩＰＵＡにはソフトフォンとして、ＳＪｐｈｏｎｅを利用した。

実施例では、ＵＡｌとＵＡ２との間でＡＬＧを介してＳＩＰによる通信を行い、そこでフェーズＩからＶまでの異常を発生させた。本発明では各フェーズにおいて、ＡＬＧによって適切に現在の状態を正常化するシグナリングが行われていることを検証する。
各フェーズからの復旧
フェーズＩ
フェーズＩでの異常は、図６においてＦ２が行われた時点で、ＵＡ２が存在しないか、またはシグナリングが行えない状態になっているときに発生する。本発明では、ＵＡ２上でＳＩＰフォンが稼働していないときに、ＵＡｌからセッション開始リクエストを生成することによって、この状況を発生させる。

このフェーズについてのＡＬＧの実装では、ＵＡｌから最後に送られたＦｌを転送した後、２秒以内にＵＡ２からの何らかのレスポンスがない場合に、状態正常化シグナリングを開始する。図６において、ＡＬＧによって状態の正常化が開始された後に行われるシグナリングのメッセージＦ３、およびＦ４を下記の表２０、２１に示す。

フェーズＩからの復旧では、以上のシグナリングによってＵＡｌおよびＡＬＧが初期状態に遷移し、セッションが正常に終了することを確認した。
フェーズＩＩ
フェーズＩＩでの異常は、図７においてＦ３またはＦ５が行われた後に、ＵＡ２がシグナリングを行えない状態になったか、またはユーザが時間内に応答しなかったときに発生する。前者からの復旧は、後者からの復旧の一部分であるため、ここでは後者の状態を想定する。本発明では、まずＵＡｌからセッション開始リクエストを生成する。次にＵＡ２上でユーザが時間内に応答しないことによって、この状況を発生させる。

このフェーズについてのＡＬＧの実装では、ＵＡ２から最後に送られたＦ３の後、または最後に送られたＦ５を転送した後、１０秒以内にＵＡ２からの最終レスポンスがない場合に、状態正常化シグナリングを開始する。図７において、ＡＬＧによって状態の正常化が開始された後に行われるシグナリングのメッセージＦ７〜Ｆ１２を下記の表２２〜２７に示す。

フェーズＩＩからの復旧では、以上のシグナリングによって各ＵＡおよびＡＬＧが初期状態に遷移し、セッションが正常に終了することを確認した。

フェーズＩＩＩ
フェーズＩＩＩでの異常は、図８においてＦ８が行われた時点で、ＵＡｌがシグナリングを行えない状態になっているときに発生する。本発明では、まずＵＡｌからセッション開始リクエストを生成し、その直後にＵＡｌ上でＳＩＰフォンを強制終了させる。次にＵＡ２上でユーザが時間内に応答することによって、この状況を発生させる。

このフェーズについてのＡＬＧの実装では、ＵＡ２から最後に送られたＦ７を転送した後、２秒以内にＵＡｌからのＡＣＫがない場合に、状態正常化シグナリングを開始する。図８において、ＡＬＧによって状態の正常化が開始された後に行われるシグナリングのメッセージＦ９〜Ｆｌｌ、およびＦ１３を下記の表２８〜３１に示す。

フェーズＩＶ
フェーズＩＶでの異常は、図９においてＦｌ０が行われた後に、セッション終了リクエストを伴わずにＵＡｌまたはＵＡ２からのメディアが一定時間以上なくなったときに発生する。本発明では、まずＵＡｌとＵＡ２との間でメディア通信を確立する。次にＵＡ２上でＳＩＰフォンを強制終了させ、セッション終了リクエストを伴わずにメディア通信を終了することによって、この状況を発生させる。

このフェーズについてのＡＬＧの実装では、ＵＡ間でメディア通信が確立した後、セッション終了リクエストを伴わず、ＵＡｌまたはＵＡ２からのメディアが１秒以上なかった場合に、状態正常化シグナリングを開始する。図９において、ＡＬＧによって状態の正常化が開始された後に行われるシグナリングのメッセージＦｌｌ〜Ｆ１３を下記の表３２〜３４に示す。

フェーズＩＶからの復旧では、以上のシグナリングによってＵＡｌおよびＡＬＧが初期状態に遷移し、セッションが正常に終了することを確認した。
フェーズＶ
フェーズＶでの異常は、図１０においてＦ１２が行われた時点で、ＵＡ２がシグナリングを行えない状態になっているときに発生する。本発明では、まずＵＡｌとＵＡ２との間でメディア通信を確立する。次にメディアモニタリングの機能を無効とした状態で、ＵＡ２上でＳＩＰフォンを強制終了させる。最後にＵＡｌからセッション終了リクエストを生成することによって、この状況を発生させる。

このフェーズについてのＡＬＧの実装では、ＵＡｌから最後に送られたＦｌｌを転送した後、２秒以内にＵＡ２からの最終レスポンスがない場合に、状態正常化シグナリングを開始する。図１０において、ＡＬＧによって状態の正常化が開始された後に行われるシグナリングのメッセージＦ１３を下記の表３５に示す。

フェーズＶからの復旧では、以上のシグナリングによってＵＡｌおよびＡＬＧが初期状態に遷移し、セッションが正常に終了することを確認した。
検証結果についての評価：
実施例により、すべてのフェーズにおいて、ＡＬＧによる状態正常化シグナリングが、パス上のＵＡに対して作用することを確認した。次に、各フェーズにおける状態正常化シグナリングの有効性について評価し、その上で最も効率的な状態正常化の手法について考察する。検討のために、ＲＦＣ３２６１でＵＡに対して定義されているオートマトンを利用する。
フェーズＩ
フェーズＩでは、ＩＮＶＩＴＥを生成したＵＡ（ＵＡＣ）に村して、状態正常作シグナリングが作用する。ここではＩＮＶＩＴＥトランザクションにおけるＵＡＣのオートマトン（図１２）を利用して、ＵＡＣに対する状態正常化の効果を検討する。本発明で提案した、フェーズＩにおける状態正常化シグナリングでは、ＵＡＣに対して、ＣａｌｌｉｎｇステートからＣｏｍｐｌｅｔｅｄステートへの遷移を促すことが可能になる。フェーズＩでセッションに異常が発生する場合、図１２において、ＵＡＣはＣａｌｌｉｎｇステートにある。ここでＵＡＣを迅速にＴｅｒｍｉｎａｔｅｄステートに遷移させる必要がある。

フェーズＩにおける状態正常化シグナリングを行わないとき、ＵＡＣはＴｉｍｅｒＢ（以下Ｔ（Ｂ））が切れることによって、ＣａｌｌｉｎｇステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ（Ｂ）ｓｅｃである。

それに対して、フェーズＩにおける状態正常化シグナリングを行うとき、ＵＡＣはまずＡＬＧによってフェーズＩの状態正常化が開始されるまで待機する必要がある。この時間、すなわちＡＬＧのもつフェーズＩ状態正常化タイマのタイムアウトをＴ‘１ｓｅｃとする。状態正常化シグナリングによって、ＵＡＣはＣａｌｌｉｎｇステートからＣｏｍｐｌｅｔｅｄステートに移行する。これに続いて、ＵＡＣはＴｉｍｅｒＤ（以下Ｔ（Ｄ））が切れることによって、ＣｏｍｐｌｅｔｅｄステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ’１＋Ｔ（Ｄ）ｓｅｃである。

以上のことから、状態正常化シグナリングを行う場合、Ｔ‘１＋Ｔ（Ｄ）＜Ｔ（Ｂ）となるようにＴ’１を決定することで、ＵＡＣの迅速な状態遷移が可能となる。しかしここでＳＩＰのトランスポートプロトコルとしてＵＤＰを利用する場合、必ずＴ（Ｄ）＞Ｔ（Ｄ）が成立する。そのためどのようにＴ‘１を決定しても、状態正常化シグナリングによって、デフォルトのタイムアウトよりも復旧が早くなることはない。したがって、フェーズＩにおいては状態正常化シグナリングを行わず、ＵＡにおいてデフォルトのタイムアウトを発生させるほうが効率的である。
フェーズＩＩ
フェーズＩＩでは、ＩＮＶＩＴＥを生成し、それに対する１ｘｘを受け取ったＵＡ（ＵＡＣ）に対して、状態正常化シグナリングが作用する。またユーザが時間内に応答しなかった場合には、ＩＮＶＩＴＥに対する１ｘｘを生成したＵＡ（ＵＡＳ）に対しても、状態正常化シグナリングが作用する。
ＵＡＣに対する効果
ここではフェーズＩからの復旧の場合と同様に、ＩＮＶＩＴＥトランザクションにおけるＵＡＣのオートマトン（図１２）を利用して、ＵＡＣに対する状態正常化の効果を検討する。本発明で提案した、フェーズＩＩにおける状態正常化シグナリングでは、ＵＡＣに対して、ＰｒｏｃｅｅｄｉｎｇステートからＣｏｍｐｌｅｔｅｄステートへの遷移を促すことが可能になる。フェーズＩＩでセッションに異常が発生する場合、図１２において、ＵＡＣはＰｒｏｃｅｅｄｉｎｇステートにある。ここでＵＡＣを迅速にＴｅｒｍｉｎａｔｅｄステートに遷移させる必要がある。

フェーズＩＩにおける状態正常化シグナリングを行わないとき、ＵＡＣはＰｒｏｃｅｅｄｉｎｇステートからどのステートにも移行することができない。これはＰｒｏｃｅｅｄｉｎｇステートにはタイマが全く設けられていないためである。したがって、このとき復旧することは不可能である。

それに対して、フェーズＩＩにおける状態正常化シグナリングを行うとき、ＵＡＣはまずＡＬＧによってフェーズＩＩの状態正常化が開始されるまで待機する必要がある。この時間、すなわちＡＬＧのもつフェーズＩＩ状態正常化タイマのタイムアウトをＴ’２ｓｅｃとする。状態正常化シグナリングによって、ＵＡＣはＰｒｏｃｅｅｄｉｎｇステートからＣｏｍｐｌｅｔｅｄステートに移行する。これに続いて、ＵＡＣはＴ（Ｄ）が切れることによって、ＣｏｍｐｌｅｔｅｄステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ’２＋Ｔ（Ｄ）ｓｅｃである。

以上のことから、従来までのオートマトンでは、フェーズＩＩにおいてセッションに異常が発生した場合、ＵＡＣはＰｒｏｃｅｅｄｉｎｇステートから遷移できないため、復旧が不可能であった。しかし、本発明で提案した状態正常化シグナリングによって、ＵＡＣはＰｒｏｃｅｅｄｉｎｇステートからの状態遷移が、Ｔ’２＋Ｔ（Ｄ）ｓｅｃの時間で必ず可能となる。したがって、フェーズＩＩにおいてはＵＡＣに対する状態正常化シグナリングが有効である。
ＵＡＳに対する効果
ここではＩＮＶＩＴＥトランザクションにおけるＵＡＳのオートマトン（図１３）を利用して、ＵＡＳに対する状態正常化の効果を検討する。本発明で提案した、フェーズＩＩにおける状態正常化シグナリングでは、ＵＡＳに村して、ＰｒｏｃｅｅｄｉｎｇステートからＣｏｍｐｌｅｔｅｄステートへの遷移を促すことが可能になる。フェーズＩＩでユーザが時間内に応答しなかった場合、図１３において、ＵＡＳはＰｒｏｃｅｅｄｉｎｇステートにある。ここでＵＡＳを迅速にＴｅｒｍｉｎａｔｅｄステートに遷移させる必要がある。ユーザが応答しないことはセッションの異常ではないが、リソースの浪費となる可能性がある。公衆電話の場合、一定回数の呼出音が鳴ることで、留守番電話やＦＡＸへの自動切り替えが行われることを考慮すれば、ＳＩＰでもこのような措置は安当であると考えられる。

フェーズＩＩにおける状態正常化シグナリングが行われないとき、ＵＡＳはＰｒｏｃｅｅｄｉｎｇステートからどのステートにも移行することができない。これはＰｒｏｃｅｅｄｉｎｇステートにはタイマが全く設けられていないためである。したがって、このときＵＡＣからセッションの取消を行わない限り、ＵＡＳでは時間の制限なくユーザの呼出を継続する。

それに対して、フェーズＩＩにおける状態正常化シグナリングを行うとき、ＵＡＳはまずＡＬＧによってフェーズＩＩの状態正常化が開始されるまで、Ｔ’２ｓｅｃ待機する必要がある。状態正常化シグナリングによって、はじめにＵＡＳはＰｒｏｃｅｅｄｉｎｇステートからＣｏｍｐｌｅｔｅｄステートに移行する。これに続いて、ＡＬＧからＡＣＫを受け取ることによって、ＵＡＳはＣｏｍｐｌｅｔｅｄステートからＣｏｎｆｉｒｍｅｄステートに移行する。最後に、ＵＡＳはＴｉｍｅｒＩ（以下Ｔ（Ｉ））が切れることによって、ＣｏｎｆｉｒｍｅｄステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ’２＋Ｔ（Ｉ）ｓｅｃである。

以上のことから、従来までのオートマトンでは、フェーズＩＩにおいてユーザが応答しなかった場合、ＵＡＳはＰｒｏｃｅｅｄｉｎｇステートから遷移できないため、時間の制限なくユーザの呼出が継続していた。しかし、本発明で提案した状態正常化シグナリングによって、ＵＡＳはＰｒｏｃｅｅｄｎｇステートからの状態遷移が、Ｔ’２＋Ｔ（Ｉ）ｓｅｃの時間で必ず可能となる。したがって、フェーズＩＩにおいてはＵＡＳに対する状態正常化シグナリングが有効である。

ただしこの場合、どのような呼であっても、リソースの浪費を抑制するために、呼出のための最長時間がＴ’２ｓｅｃとして決定される。しかし各ＵＡ（ＵＡＣとＵＡＳ）では、状態正常化によって初期状態に移行した後であれば、再発信することも、またしないこともできる。そのためユーザに対して選択肢を与えることができ、利便性にも影響はないと考えられる。
フェーズＩＩＩ
フェーズＩＩＩでは、ＩＮＶＩＴＥに対する２ｘｘを生成したＵＡ（ＵＡＳ）に対して、状態正常化シグナリングが作用する・ただしここでＩＮＶＩＴＥトランザクションにおけるＵＡＳオートマトン（図１３）において、ＵＡＳは既にＴｅｒｍｉｎａｔｅｄステートにある。

しかしメディア通信は確立しているため、開始したセッションを終了するために、新しくＢＹＥトランザクションが生成される・これによって、ＩＮＶＩＴＥトランザクションにおけるＵＡＳは、新たにＢＹＥトランザクションにおけるＵＡＳとなる。そのため、ここでは非ＩＮＶＩＴＥトランザクションにおけるＵＡＳのオートマトン（図１４）を利用して、ＵＡＳに対する状態正常化の効果を検討する。本発明で提案した、フェーズＩＩＩにおける状態正常化シグナリングでは、ＵＡＳに対して、初期状態（ＢＹＥトランザクションが開始されていない状態）からＴｒｙｉｎｇステートへの遷移を促すことが可能になる。フェーズＩＩＩでセッションに異常が発生する場合、図１４において、ＵＡＳは初期状態にある。ここでＵＡＳを迅速にＴｅｒｍｉｎａｔｅｄステートに遷移させる必要がある。

フェーズＩＩＩにおける状態正常化シグナリングを行わないとき、ＵＡＳは、ＩＮＶＩＴＥトランザクションを終了し、メディア通信を開始する。しかしこのときＵＡは特定のオートマトンに基づいて動作することはない。そのためＵＡＳはセッションの異常を検知することができず、メディア通信を終了することができない。したがって、このとき復旧することは不可能である。ここで、ＲＦＣ３２６１では、「ＵＡＳが２ｘｘを生成したのにいつまでもＡＣＫを受け取らない場合、ＵＡＳはダイアログを終了するためにＢＹＥを生成するべきである」とされている。しかし実装は必須ではないため、すべてのＵＡに対して期待できる機能ではない。

それに対して、フェーズＩＩＩにおける状態正常化シグナリングを行うとき、ＵＡＳはまずＡＬＧによってフェーズＩＩＩの状態正常化が開始されるまで待機する必要がある。この時間、すなわちＡＬＧのもつフェーズＩＩＩ状態正常化タイマのタイムアウトをＴ’３ｓｅｃとする。状態正常化シグナリングによって、ＵＡＳはＡＬＧからのＢＹＥを受け取る。それを契機として、はじめにＵＡＳはＴｒｙｉｎｇステートに入る。これに続いて、ＢＹＥに対する２ｘｘを生成することによって、ＵＡＳはＴｒｙｉｎｇステートからＣｏｍｐｌｅｔｅｄステートに移行する。最後に、ＵＡＳはＴｉｍｅｒＪ（以下Ｔ（Ｊ））が切れることによって、ＣｏｍｐｌｅｔｅｄステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ’３＋Ｔ（Ｊ）ｓｅｃである。

以上のことから、従来までのオートマトンでは、フェーズＩＩＩにおいてセッションに異常が発生した場合、ＵＡＳはメディア通信を終了できない。しかし、本発明で提案した状態正常化シグナリングによって、ＵＡＳはこの状態からの復旧が、Ｔ’３＋Ｔ（Ｊ）ｓｅｃの時間で可能となる。したがって、フェーズＩＩＩにおいてはＵＡＳに対する状態正常化シグナリングが有効である。またＵＡＳが独自にＢＹＥを生成する場合、復旧に要する時間はＴ（Ｂ）＋Ｔ（Ｊ）ｓｅｃである。そのためＴ’３＋Ｔ（Ｊ）＜Ｔ（Ｂ）＋Ｔ（Ｊ）、つまりＴ’３＜Ｔ（Ｂ）となるようにＴ’３を決定することで、この場合でもＵＡＳの迅速な状態遷移が可能となる。
フェーズＩＶ
フェーズＩＶでは、異常が発生したセッションで、メディア通信を継続しているＵＡに対して、状態正常化シグナリングが作用する。一般にＵＡは、通信相手であるＵＡからのメディアをモニタリングすることはない。

フェーズＩＶにおける状態正常化シグナリングを行わないとき、メディア通信を継続しているＵＡは、通信相手であるＵＡからのメディアがなくなっても、セッションの異常とみなすことはなく、メディア通信を終了することができない。したがって、このとき復旧することは不可能である。フェーズＩＩＩとの決定的な相違点として、ＩＮＶＩＴＥトランザクションにおけるＵＡＳが、独自にＢＹＥを生成することはないということがある。

それに対して、フェーズＩＶにおける状態正常化シグナリングを行うとき、メディア通信を継続しているＵＡは、まずＡＬＧによってフェーズＩＶの状態正常化が開始されるまで待機する必要がある。この時間、すなわちＡＬＧのもつフェーズＩＶ状態正常化タイマのタイムアウトをＴ’４ｓｅｃとする。この後行われる状態正常化シグナリングの流れと、その効果は、フェーズＩＩＩからの復旧の場合と同様である。したがって、このとき復旧に要する時間はＴ’４＋Ｔ（Ｊ）ｓｅｃである。

以上のことから、従来までのメディア通信では、フェーズＩＶにおいてセッションに異常が発生した場合、ＵＡは復旧が不可能であった。しかし、本発明で提案した状態正常化シグナリングによって、ＵＡはこの状態からの復旧が、Ｔ’４＋Ｔ（Ｊ）ｓｅｃの時間で可能となる。したがって、フェーズＩＶにおいてはＵＡに対する状態正常化シグナリングが有効である。
フェーズＶ
フェーズＶでは、ＢＹＥを生成したＵＡ（ＵＡＣ）に対して、状態正常化シグナリングが作用する。ここでは非ＩＮＶＩＴＥトランザクションにおけるＵＡＣのオートマトン（図１５）を利用して、ＵＡＣに対する状態正常化の効果を検討する。本発明で提案した、フェーズＶにおける状態正常化シグナリングでは、ＵＡＣに村して、ＴｒｙｉｎｇステートからＣｏｍｐｌｅｔｅｄステート、またはＰｒｏｃｅｅｄｉｎｇステートからＣｏｍｐｌｅｔｅｄステートへの遷移を促すことが可能になる。フェーズＶでセッションに異常が発生する場合、図１５において、ＵＡＣはＴｒｙｉｎｇステートにある。ここでＵＡＣを迅速にＴｅｒｍｉｎａｔｅｄステートに遷移させる必要がある。

フェーズＶにおける状態正常化シグナリングを行わないとき、ＵＡＣはＴｉｍｅｒＦ（以下Ｔ（Ｆ））が切れることによって、ＴｒｙｉｎｇステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ（Ｆ）ｓｅｃである。

それに対して、フェーズＶにおける状態正常化シグナリングを行うとき、ＵＡＣはまずＡＬＧによってフェーズＶの状態正常化が開始されるまで待機する必要がある。この時間、すなわちＡＬＧのもつフェーズＶ状態正常化タイマのタイムアウトをＴ’５ｓｅｃとする。状態正常化シグナリングによって、ＵＡＣはＴｒｙｉｎｇステートからＣｏｍｐｌｅｔｅｄステートに移行する。これに続いて、ＵＡＣはＴｉｍｅｒＫ（以下Ｔ（Ｋ））が切れることによって、ＣｏｍｐｌｅｔｅｄステートからＴｅｒｍｉｎａｔｅｄステートに移行する。したがって、このとき復旧に要する時間はＴ’５＋Ｔ（Ｋ）ｓｅｃである。

以上のことから、状態正常化シグナリングを行う場合、Ｔ’５＋Ｔ（Ｋ）＜Ｔ（Ｆ）となるようにＴ’５を決定することで、ＵＡＣの迅速な状態遷移が可能となる。したがって、フェーズＶにおいてはＵＡＣに対する状態正常化シグナリングが有効である。
フェーズＩからの復旧の別の実施例討
フェーズＩからの復旧では、図６において提案したシグナリングとはまた別の実施例で、状態正常化を実現することができる。図１６はこの実施例におけるフェーズＩからの復旧するコールフローを示す。
シグナリングの詳細
ＡＬＧはＵＡｌに対して、まずリクエストＦｌに対する最終成功レスポンスＦ３を返す。続いてＵＡｌからのＦ４によって、ＡＬＧとＵＡｌ間のＩＮＶＩＴＥトランザクションが正常形で終了する。ここでＡＬＧとＵＡｌ間でメディア通信が確立する。次にＡＬＧはＵＡｌに対して、Ｆ５によって、確立したメディア通信を終了させる。ＡＬＧはＦ５をあたかもＵＡ２からのメッセージであるかのようにして生成する。最後にＡＬＧはＵＡｌからの最終成功レスポンスＦ６を傍受する。これにより、Ｆ５によって開始されたＢＹＥトランザクションが正常形で終了する。

またＡＬＧはＵＡ２に対しては、シグナリングを行わない。これは本発明で利用した前述の実施例に基づくフェーズＩからの復旧と同様である。

この実施例に基づくフェーズＩ状態正常化シグナリングでは、はじめにＩＮＶＩＴＥトランザクションにおけるＵＡＣ（図１２）に対して、ＣａｌｌｉｎｇステートからＴｅｒｍｉｎａｔｅｄステートへの遷移を促す。続いて開始したメディア通信を終了させるため、ＡＬＧによって新しくＢＹＥトランザクションが生成される。これによって、ＩＮＶＩＴＥトランザクションにおけるＵＡＳは、新たにＢＹＥトランザクションにおけるＵＡＳ（図１４）となる。ＢＹＥトランザクションにおけるＵＡＳはこのときＴｒｙｉｎｇステートにあり、自身で２ｘｘを生成することによって、Ｔｅｒｍｉｎａｔｅｄステートに移行する。このとき復旧に要する時間はＴ’１＋Ｔ（Ｊ）ｓｅｃである。
フェーズＩＩからの復旧の別の実施例
図１７に、本発明で利用した手法とは別の実施例に基づいて、フェーズＩＩから復旧するコールフローを示す。ただしここでＡＬＧとＵＡｌ間、およびＡＬＧとＵＡ２間のシグナリングは、いずれも図１７の順序であればよく、同期する必要はない。
シグナリングの詳細
ＡＬＧとＵＡｌ間での状態正常化シグナリングは、別の実施例に基づくフェーズＩからの復旧と同様である。つまりＦ７、Ｆ９、Ｆｌｌ、Ｆ１３はこの順序で、図１６でのＦ３、Ｆ４、Ｆ５、Ｆ６に対応する。

またＡＬＧとＵＡ２間の状態正常化シグナリングは、本発明で利用した前述の実施例に基づくフェーズＩＩからの復旧と同様である。つまりＦ８、Ｆｌ０、Ｆ１２、Ｆ１４はこの順序で、図７でのＦ８、Ｆｌ０、Ｆｌｌ、Ｆ１２に対応する。

別の実施例に基づくフェーズＩｉ状態正常化シグナリングでは、ＩＮＶＩＴＥトランザクションにおけるＵＡＣ（図１２）に対して、ＰｒｏｃｅｅｄｉｎｇステートからＴｅｒｍｉｎａｔｅｄステートへの遷移を促す。開始したメディア通信を終了させる手続きは、別手法に基づくフェーズＩからの復旧の場合と同様である。このとき復旧に要する時間はＴ’２＋Ｔ（Ｊ）ｓｅｃである。

ＳＩＰによる通信の構成要素を示すブロック図である。ＳＩＰ電話端末、パソコンやＰＤＡ上で動作するソフトウェア（ソフトフォン）を示す図である。シグナリング異常時の一例を示すコールフローである。異種ネットワーク間のシグナリング異常時の一例を説明するための図である。一連のセッションの各フェーズを示すコールフローである。フェーズＩから復旧するコールフローを示す。フェーズＩＩから復旧するコールフローを示すフェーズＩＩＩから復旧するコールフローを示す。フェーズＩＶから復旧するコールフローを示す。フェーズＶから復旧するコールフローを示す。検証実施例を行なう環境を示すブロック図である。オートマトンを示す図である。オートマトンを示す図である。オートマトンを示す図である。オートマトンを示す図である。別の実施例のフェーズＩから復旧するコールフローを示す。別の実施例のフェーズＩＩから復旧するコールフローを示す。

符号の説明

１０ユーザエージェント（ＵＡ）
１２ユーザエージェント（ＵＡ）
１４ＳＩＰサーバ
１４ａプロキシサーバ
１４ｂリダイレクトサーバ
１４ｃレジストラサーバ
１６ロケーションサーバ

Claims

２つのユーザエージェント（ＵＡ１、ＵＡ２）間のセッションの確立をＳＩＰ−ＡＬＧを介して行なうＳＩＰ−ＡＬＧ方法において、セッションの開始から終了までを複数のフェーズに分割し、フェーズの１つでセッションに異常が発生したとき、異常が発生したフェーズの段階に応じて、少なくとも１つのユーザエージェントとＳＩＰ−ＡＬＧとの間で復旧信号を通信させることにより初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項１記載のＳＩＰ−ＡＬＧ方法において、前記フェーズは、ＵＡ１からＳＩＰ−ＡＬＧを介してＵＡ２へ“ＩＮＶＩＴＥ”信号を送るフェーズＩと、ＵＡ２からＳＩＰ−ＡＬＧを介してＵＡ１へ“Ｔｒｙｉｎｇ”および“Ｒｉｎｇｉｎｇ”信号を送るフェーズＩＩと、ＵＡ２からＳＩＰ−ＡＬＧを介してＵＡ１へ“ＯＫ”信号を送るフェーズＩＩＩと、
ＵＡ１からＳＩＰ−ＡＬＧを介してＵＡ２へ“ＡＣＫ”信号を送るフェーズＩＶと、ＵＡ１からＳＩＰ−ＡＬＧを介してＵＡ２へ“ＢＹＥ”信号を送るフェーズＶのうちの少なくとも１つのフェーズを含むことを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、フェーズＩの段階でＵＡ２からのレスポンスがない異常が発生したとき、ＳＩＰ−ＡＬＧからＵＡ１へ“ＲｅｑｕｅｓｔＴｉｍｅｏｕｔ”信号を送り、ＵＡ１からＳＩＰ−ＡＬＧへ“ＡＣＫ”信号を返すことにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、フェーズＩＩの段階でＵＡ２からの最終レスポンスがない異常が発生したとき、ＳＩＰ−ＡＬＧからＵＡ１へ“ＲｅｑｕｅｓｔＴｉｍｅｏｕｔ”信号を送るともにＳＩＰ−ＡＬＧからＵＡ２へ“ＣＡＮＣＥＬ”信号を送り、ＵＡ１からＳＩＰ−ＡＬＧへ“ＡＣＫ”信号を返し、ＵＡ２からＳＩＰ−ＡＬＧへ“ＯＫ”および“ＲｅｑｕｅｓｔＴｉｍｅｏｕｔ”信号を返し、ＳＩＰ−ＡＬＧからＵＡ２へ“ＡＣＫ”信号を返すことにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、フェーズＩＩＩの段階でＵＡ１からＡＣＫがない異常が発生したとき、ＳＩＰ−ＡＬＧからＵＡ２へ“ＡＣＫ”信号を送り、さらにＳＩＰ−ＡＬＧからＵＡ１およびＵＡ２へ“ＢＹＥ”信号を送り、ＵＡ１およびＵＡ２からＳＩＰ−ＡＬＧへ“ＯＫ”信号を返すことにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、フェーズＩＶの段階でＭｕｌｔｉｍｅｄｉａＣｏｍｍｕｎｉｃａｔｉｏｎエラーが発生したとき、ＳＩＰ−ＡＬＧからＵＡ１およびＵＡ２へ“ＢＹＥ”信号を送り、ＵＡ１およびＵＡ２からＳＩＰ−ＡＬＧへ“ＯＫ”信号を返すことにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、ＵＡ２からの最終レスポンスがない異常が発生したとき、ＳＩＰ−ＡＬＧからＵＡ１へ“ＯＫ”信号を送ることにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、フェーズＩの段階でＵＡ２からのレスポンスがない異常が発生したとき、ＳＩＰ−ＡＬＧからＵＡ１へ“ＯＫ”信号を送り、ＵＡ１からＳＩＰ−ＡＬＧへ“ＡＣＫ”信号を返し、さらに、ＳＩＰ−ＡＬＧからＵＡ１へ“ＢＹＥ”信号を送り、ＵＡ１からＳＩＰ−ＡＬＧへ“ＯＫ”信号を返すことにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。
請求項２記載のＳＩＰ−ＡＬＧ方法において、フェーズＩＩの段階でＵＡ２からの最終レスポンスがない異常が発生したとき、ＳＩＰ−ＡＬＧからＵＡ１へ“ＯＫ”信号を送るともにＳＩＰ−ＡＬＧからＵＡ２へ“ＣＡＮＣＥＬ”信号を送り、ＵＡ１からＳＩＰ−ＡＬＧへ“ＡＣＫ”信号を返し、ＵＡ２からＳＩＰ−ＡＬＧへ“ＯＫ”および“ＲｅｑｕｅｓｔＴｉｍｅｏｕｔ”信号を返し、ＳＩＰ−ＡＬＧからＵＡ１へ“ＢＹＥ”信号を送り、ＵＡ１からＳＩＰ−ＡＬＧへ“ＯＫ”信号を返し、ＳＩＰ−ＡＬＧからＵＡ２へ“ＡＣＫ”信号を返すことにより、初期状態に復旧させることを特徴とするＳＩＰ−ＡＬＧ方法。