JP5523012B2 - エンドポイントを生き残ったネットワークのコントローラのリスト内にコントローラのスライディング・ウインドウで登録する方法 - Google Patents

Description

本発明は、通信ネットワークに関し、特にサバイバルネットワークに関する。

クライアント・サーバ・システムのアーキテクチュアにおいて、クライアントは、サービスをサーバから受け取る。例えば電話機は、電話の接続とフューチャーサービスを電話会社から受ける。信頼性を高めるためにサーバは、複製され、サーバの１つのコピーが故障すると別のコピーがそれに取って代わり、同一サービスを故障の影響を受けたクライアントに提供し続ける。これは、それぞれ、リダンダンシー（redundancy）とフェール・オーバ（fail-over）と称する。

現代の通信システムは、リダンダントな（冗長な）サーバに対するフェール・オーバを、クライアントが実行するよう要求しているが、これはサーバが、クライアントの為にフェール・オーバを実行するのとは対照的である。クライアントは、自分自身をサーバに接続し通信して、サービスをそのサーバから受取らなければならない。このことは、故障したサーバから予備のサーバにフェール・オーバするために、クライアントは、故障したサーバに代えて予備のサーバに登録（代替登録）するか、或いは両方のサーバに同時に登録して（同時登録）おかなければならない。
代替登録においては、クライアントは、自分が使用できるサーバのリストを用意し、これ等のサーバの１つのサーバに登録し、そのサーバからサービスを受ける。サービスを受けているサーバが故障した時には、クライアントは、別の第２のサーバに登録し直し、同じサービスを別のサーバから受ける。更に第２のサーバが故障すると、クライアントは、第３のサーバに登録し、この第３のサーバからサービスを受ける。以下順に同様のことを繰り返す。登録には時間を要するために、別の登録を行うのには、クライアントが、別のサーバにフェール・オーバする毎に、サービスをクライアントが得るのが遅れる。

米国特許出願１２／０５６２４６号明細書 米国特許出願１２／０５６２４８号明細書 米国特許出願１２／０５６２５０号明細書 米国特許出願１２／０５６２５３号明細書

同時登録においては、クライアントは、自分が使用できるサーバのリストを具備し、クライアントは、これ等全てのサーバに一度に登録する。クライアントは、サービスを何時でもこれ等のサーバの内の１つから受け取り、そのサーバが故障した場合には、クライアントは、他のサーバ１つからサービスを直ち受領する為に、調整する。この為には、クライアントは、一時に全てのサーバとの接続を生成し維持することが必要である。この方法は、通信ネットワークの資源の無駄遣いとなる。その理由は、これ等のサーバの接続の１つのみが使われるだけだからである。

これ等の問題が発生する１つの環境は、Session Initiate Protocol（ＳＩＰ）サバイバルネットワークである。ＳＩＰは、オープンシグナリングプロトコルで、あらゆる種類のリアルタイムの通信セッションを確立する。ＳＩＰを使用して確立される通信セッションのタイプの一例は、音声、画像、ゲーム、アプリケーション、インスタントメッセージ等である。これ等の通信セッションは、あらゆる通信装置上で実行可能である。例えばパソコン、ラップトップコンピュータ、Personal Digital Assistance（ＰＤＡ）、携帯電話、ＩＭクライアント、ＩＰホーン、通常の電話、サーバアプリケーション、アプリケーション群、デスクトップアプリケーション等である。

ＳＩＰの特徴は、Address of Record（ＡＯＲ）を、エンドユーザ、アプリケーション、サービス・プロバイダ・ネットワークへの全ての通信用に、１個の統一したパブリック・アドレスとして使用することである。かくして、ＳＩＰ強化通信の世界においては、ユーザのＡＯＲは、ユーザをそのユーザに関連する全ての通信機器にリンクさせる単一のアドレスとなる。このＡＯＲを用いると、発呼者は、ユーザの通信機器の何れか１つに到達することができる。これはUser Agent（ＵＡ）と称するが、これは、唯一の装置アドレス或いは電話番号を知ることなく、行うことができる。

多くのＳＩＰアプリケーションサーバの存在目的は、ＳＩＰ環境で通信アプリケーションを可能にし、ＵＡ用のアウトバンド・プロキシ（outboud proxy）として、サービスすることである。これにより、複雑なネットワークを構築しながら、ネットワーク内に接続させる為に、装置が使用するプロキシを介するという複雑さを解消することである。このような通信アプリケーションの原理の１つは、ＳＩＰ・ＵＡの呼びの制御（call contoller）である。サバイバルＳＩＰネットワークの構築を提供する際に発生する問題点に対する解決方法は、ＳＩＰシグナリングに対し応答がない時に採用されるＳＩＰプロキシを使用することである。このＳＩＰプロキシは、シグナリングをネットワーク内の１つ或いは複数の別のルートを介して、ルーティングするために用いることができる。個別のプロキシを使用することは、高価になる。その理由は、コールコントローラ或いはゲートウエイ以外の付加的なネットワーク要素が、サバイバルさせるために、必要となるからである。

他のネットワークサーバ製品は、地理的にリダンダントな（geo-redundant）構造を提供する。その結果、例えばゲートウエイは、ネットワークサーバの高い利用性（high availability of network server）に起因して、ネットワークサーバの故障に遭遇する可能性は低い。プロキシを使用する特定の解決方法は高価となる。その理由は、利用性の高いサーバを購入しなければならず、又それをネットワーク全体に分散配置しなければならないからである。現在分かっている解決方法の更なる欠点は、ネットワーク要素（例；ゲートウエイ）は、プライマリーなＳＩＰシグナリングパスが利用できなくなった時には、別のパスを使用することが許されないからである。この解決方法は、サーバ間でデータを複製するホットスタンバイ構築を必要とする。この解決方法は、同一バージョンのＳＩＰを確実に利用するプライマリ（第１）と第２のコールコントローラを必要とし、更にＳＩＰ特徴の同一のセットをＳＩＰのエンドポイントに確実に提供しなければならない。

ネットワークの故障が発生した時点を決定するロジックは、従来はルーター内に配置されていた。そしてこのルーターが、ネットワークのＩＰレイヤーをチェックする機能を有し、様々なネットワーク要素が適正に動作しているか否かを決定する。この故障／フェールバック検出ロジックは、ルーター内に配置されて、残りのネットワーク要素にかかる処理負荷を軽減している。この構造の主な欠点は、ルーターは、ＳＩＰアプリケーションレベルで、サーバ或いは他のネットワーク要素が動作可能か否かを検出できない点である。サーバはＩＰレイヤーレベルでは動作可能であるが、ＳＩＰコノトローラは動作可能ではないような事例は沢山ある。従来のルーターと他のネットワーク要素は、これ等の状況において、このような故障条件を特定できず、このようなサーバを動作可能と登録してしまう。その結果、故障決定ロジックを、ＳＩＰが可能な通信エンドポイントに配置することが提案され、更にＳＩＰエンドポイントが、代替登録或いは同時登録を、ＳＩＰコントローラで行うことが提案されている。

本発明の一態様によれば、クライアント（例；ＳＩＰ・ＵＡ）は、クライアントがアクセスできるサーバのサブセット（例；ＳＩＰコントローラ）に、同時に登録され、このサブセット内のサーバの少なくとも１個のサーバからサービスを受ける。このサーバのサブセットは、利用可能な全てのサーバではないが、複数個のサーバを含む。サブセット内のサーバの１つが故障した場合には、クライアントは、このサブセット外にある（含まれない）サーバの１つを追加登録し、そのサーバをサブセット内に組み入れる。この技術は、代替登録と同時登録との間の中間にある。例えばサブセットのサイズ（数）は、全てのクライアントに対し同じであってもよい。別の構成としては、サブセットのサイズは、ロケーション或いは誰がそのユーザであるかによって、クライアント毎に変わってもよい。

本発明の他の態様によれば、利用可能なサーバは、順番に並んでいる。好ましくはサーバは、サービスを得る為にクライアントが使用すべき優先順位で並んでいる。最初にサーバのサブセットは、その順番の最初のＮ個のサーバを含む。このサブセット内のサーバの１つが故障すると、クライアントは、その順番の（Ｎ＋１）番目のサーバを登録する。このサーバは、シーケンス内のサブセットの直後のサーバであり、かくして、新たなサーバをサブセット内に入れる。この手順を、サブセット内のサーバの全ての故障に対し繰り返す。好ましくは、サブセット内の故障したサーバの１つが、サービス可能状態に復帰すると、クライアントは、サブセット内の最後に入れたサーバの登録を抹消し、必要に応じて回復したサーバを再登録する。かくして、このサブセットが、利用可能なサーバのシーケンス上で、スライドするウインドウを構成する。

本明細書で使用される「監視」は、要素の動作あるいは状態に何の影響も及ぼさない機器で観測したり、記録したり、検出したりするあらゆる種類の機能を含む。

本明細書で使用される「少なくとも１つ或いは複数」、「と／又は」は、それらの内の１つに限定されない。例えば「Ａ，Ｂ，Ｃの内の少なくとも１つ」は「Ａ」、「Ｂ」、「Ｃ」単独のみならず「Ａ，Ｂ或いはＢ，Ｃ更には又Ａ，Ｂ，Ｃ」のように複数のものを含んでもよい。「Ａ，Ｂ，Ｃの内の少なくとも１つ」は、Ａ，Ｂ，Ｃ単独のみならずＡ，Ｂの組合せＡ，Ｂ，Ｃの組合せでもよい。「Ａ，Ｂと／又はＣ」は、Ａ，Ｂ，Ｃ単独のみならず、Ａ，Ｂの２つ、或いはＡ，Ｂ，Ｃの全部を含んでもよい。

本明細書において単数、複数は、特に指定のない限り、その何れか或いはその両方を含む。更に本明細書において「Ａを含む」「Ａを有する」は、Ａ以外のものを含んでもよい。

「自動的」とは、人間が関与せず行われるプロセス或いは動作を指す。しかし、プロセス或いは動作の実行に、プロセス或いは動作の実行前に、サービスを受領する人間による入力を必要とする場合でも、「自動的」と称する。これは、能動的或いは非能動的でもよい。人間の入力は、このような人間の入力が、プロセス或いは動作が如何に行われるかに影響を及ぼす点では能動的である。プロセス或いは動作の実行に同意を示す人間の入力は能動的とは見なされない。

「コンピュータで読み込み可能な媒体」とは、プロセスを実行するプロセッサに指示を与える記憶装置、伝送媒体を含む。「コンピュータで読み込み可能な指示」は、ネットワーク伝送でＩＰネットワーク（例；ＳＯＡＰ）を介して符号化された一連の指示である。このような媒体は如何なるものでもよく、例えばこれに限定されるわけではないが、非揮発的媒体、揮発的媒体、伝送媒体である。非揮発的媒体は、ＮＶＲＡＭ又は磁気ディスク、光学ディスクを含む。揮発的媒体は、ＲＡＭ例えばメインメモリを含む。「コンピュータで読み込み可能な媒体」は。例えばフロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ或いはあらゆる種類の磁気媒体、或いは磁気−光学媒体、ＣＤ−ＲＯＭ或いは他の光学媒体、パンチカード、ペーパーテープ、或いは一定の穴があいた物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカードのような固体状態媒体或いは他のメモリチップ、カートリッジ、搬送波或いはコンピュータが読み込むことができるあらゆる媒体を含む。ｅ−メールに添付したデジタルファイル或いは自己保有情報のアーカイブも、記憶媒体と等価な分散媒体として認識できる。「コンピュータで読み込み可能な指示」は、データベースを構築する。データベースは、あらゆる種類のデータベース、例えば、関連データベース、階層的データベース、オブジェクト指向のデータベース等である。従って本発明は、記憶媒体、分散型の媒体或いは従来の認識可能な等価物とサクセッサー媒体を含む。これ等の媒体中に本発明のソフトウエアが記憶される。

用語「決定」、「計算」は、あらゆる種類の措置、処理、数学的な操作を含み、これ等は互換性をもって使用される。より具体的には、これ等の用語は、ＢＰＥＬ或いはルールランゲィッジ等の解釈されたルールも含む。このルールには、ロジックが記憶しづらいが読み込まれたり、解釈されたり、コンパイルされたり、実行されたりするようなルールファイルの中に表される。

「モジュール」又は「ツール」は、現在公知或いはこれから開発されるあらゆるハードウエア、ソフトウエア、ファームウエア、人工知能、ファジーロジック、これ等の要素に関連する機能を実行するハードウエアとソフトウエアの組合せも含む。

本発明の一実施例の通信システムのブロック図。 ＳＩＰコントローラの発見と登録方法を表すフローチャート図。 状態決定方法を表すフローチャート図。 リアクティブ状態決定方法を表すブロック図。 ゲートウエイ操作の方法を表すフローチャート図。 エンドポイントの状態決定方法を表すフローチャート図。 状態通知方法を表すフローチャート図。

本発明を通信システムを例に以下説明する。本発明は、サーバ又はデータベースを用いたシステムに摘要可能であるが、本発明は、特定の種類の通信システム或いはシステムの要素の構築に限定されない。更に本明細書において、用語「データベース」は、関連するデータベースシステムのみならず、コンピュータの記憶機構でハードウエアとソフトウエアの両方に利用可能なものも含み、例えばＲＡＭとハードディスクを含む。ここに開示された技術は、ＳＩＰサバイバルネットワークを維持するのに好ましい通信アプリケーションに使用できる。

本発明のシステムと方法は、解析ソフトウエアとモジュールと関連する解析ハードウエアを例に説明する。しかし以下の説明では、公知の構造、構成要素、装置は、ブロック図で示し、説明は回避或いは一般的に留めている。このような公知の構造の一例は、ＩＰインフラストラクチュウア、レイヤー２スイッチ、レイヤーＩＰルータ、ＩＰレベルファイヤーウオール、Network Address Translation（ＮＡＴ）装置、ＳＩＰセッションボーダーコントローラＳＢＣ等である。

本発明の詳細な説明は、本発明を理解するためのものであるが、本発明はここに開示した特定の実施例以外に様々な方法で実行可能である。

図１に通信システム１００を示す。通信システム１００は、第１ネットワーク１０４を有する。この第１ネットワーク１０４は、エンドポイント（ＳＩＰユーザエージェントＵＡ）１０８を複数の他の通信システムに接続する。ユーザ・エージェント（ＵＡ）１０８は、第１ネットワーク１０４に接続された他のエンドポイントと通信可能である、或いは第１ネットワーク１０４の外部にある他のエンドポイントと通信可能である。例えばユーザ・エージェント（ＵＡ）１０８は、第２ネットワーク１５２に接続されたエンドポイント１５６と通信可能である。

第１ネットワーク１０４と第２ネットワーク１５２は、あらゆるタイプの公知の通信ネットワーク又は通信要素の集合体に対応する。第１ネットワーク１０４は、ローカルネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、或いはレイヤー３レイヤー４、他のタイプのネットワーク（ＯＳＩモデル）で定義されるものを含む。

第２ネットワーク１５２は、あらゆるタイプの情報伝送媒体を含み、エンドポイント間でメッセージを送信するあらゆるタイプのプロトコールを用いることができる。インターネットは、第１ネットワーク１０４の一例である。インターネットは、世界中にある複数のコンピュータと他の通信装置から構成されるＩＰネットワークを構成する。これ等は、多くの電話システム或いは他の手段で接続される。第２ネットワーク１５２の他の一例は、従来の電話システム（ＰＯＴＳ）、ＩＳＤＮ、公衆交換電話ネットワーク（ＰＡＴＮ）、ＬＡＮ１、携帯電話ネットワーク、他の種類のパケット交換、又は回線交換ネットワークである。第１ネットワーク１０４と第２ネットワーク１５２は、有線又は無線の通信技術を含む。

ユーザ・エージェント（ＵＡ）１０８のＳＩＰ機能は、１つ或いは複数のサーバ１３６を具備する。このサーバ１３６は、第１ネットワーク１０４にも接続される。ユーザ・エージェント（ＵＡ）１０８は、第１ネットワーク１０４外の他のサーバ或いは通信装置により制御される。例えばゲートウエイ１４８は、第１ネットワーク１０４と第２ネットワーク１５２を接続するが、ユーザ・エージェント（ＵＡ）１０８用にＳＩＰ制御機能を提供する。

ＳＩＰ機能を提供することに加えて、サーバ１３６は以下のものを含む。ボイスコールソフトウエア（例；ＶｏＩＰソフトウエア）、ビデオコールソフトウエア、ＩＭソフトウエア、ボイスメッセージングソフトウエア（例；マルチメディアメッセージング、例えばオーディオビデオメッセージング、ＩＭメッセージング等）、記録用ソフトウエア、ＩＰボイスサーバ、ファックスサーバ、ウエブサーバ、ｅメールサーバ、コールセンターアプリケーション。

本発明の一実施例によれば、サーバ１３６は、他の様々なプロトコール用のインターフェイスを含む。例えばLightweight Directory Access Protocol(LDAP),H.248,H.323,Simple Mail Transfer Protocol(SMTP),Internet Message Access Protocol 4(IMAP4),Integrated Services Digital Network(ISDN),E1/T1,HTTP,SOAP,XCAP,STUNとアナログライン又はトランクである。

サーバ１３６は以下のものを含む。ＰＢＸ、オートマチックコールディストリビュータ（ＡＣＤ）、企業用の交換機、他の種類の通信システムの交換機（例；ある電話から他の電話への呼びをルーチングできる装置、例えばコンプレックスマシン或いはその中央の交換器内に配置されるコンプレックスマシン、或いは一連のマシンで、これ等は複数の回線を接続し、各回線はダイヤルされた電話番号に従って加入者電話に接続される）、サーバ、他の種類のプロセッサベースの通信制御装置（例、メディアサーバ、コンピュータ、アジャンクト等）。

ゲートウエイ１４８は、通信ネットワーク間の変換ユニット（トランスレーションユニット）として機能する。例えばＰＳＴＮ、次世代ネットワーク、２Ｇ、２．５Ｇ、３Ｇの無線アクセスネットワーク、ＰＢＸとして機能する。ゲートウエイ１４８の機能の１つは、様々なネットワーク用に、異なる伝送符号化技術を変換することである。メディアストリーミング機能、例えばエコーキャンセラー、ＤＴＭＦ、トーンセンダー等は、ゲートウエイ１４８によりサポートされている。ゲートウエイ１４８は、更に１つのネットワークオペレーションパラダイム（例；伝送プロトコール）から他のネットワークオペレーションパラダイムへ信号／メッセージを変換する。

ＳＩＰ機能をユーザ・エージェント（ＵＡ）１０８に具備させるために、サーバ１３６又はゲートウエイ１４８は、１つ或いは複数（Ｎ個）のコントローラ１４０ａ−Ｎを有する。ユーザ・エージェント（ＵＡ）１０８は、一時に複数のコントローラ１４０ａ−Ｎの内の１つ或いは複数に登録される。用語「登録する」と「登録」は、ＳＩＰ登録とネットワークアタッチメント方法とプロセスを表し、これ等は、ＳＩＰ ＲＥＧＩＳＴＥＲネットワークの送信と受領確認に限定されず、他のメカニズム、例えばＳＵＳＢＳＣＲＩＢＥメッセージ、加入用のＯＰＴＩＯＮメッセージを用いた問い合わせ、或いは他の非ＳＩＰ機構例えばファイアウオールとＮＡＴ検出（ＳＴＵＮプロトコール、ＨＴＴＰクワイアリを用いた）である。

コントローラ１４０ａ−Ｎは、サーバ１３６上にあるアプリケーション又はファームウエアに対応する。コントローラ１４０ａ−Ｎを用いて、ユーザ・エージェント（ＵＡ）１０８に向けたＳＩＰメッセージと、ユーザ・エージェント（ＵＡ）１０８からのＳＩＰメッセージを取り扱う。コントローラ１４０ａ−Ｎにより取り扱われるＳＩＰメッセージは、アウトバウンド（出発）ＳＩＰメッセージと、インバウンド（来入）ＳＩＰメッセージに対応する。アウトバウンド（出発）ＳＩＰメッセージは、ユーザ・エージェント（ＵＡ）１０８により生成され、エンドポイント１５６に向けられたものである。インバウンド（来入）ＳＩＰメッセージは、エンドポイント１５６により生成され、ユーザ・エージェント（ＵＡ）１０８に向けられたものである。コントローラ１４０ａ−Ｎは、通信システム１００のアプリケーション・レイヤーで動作する。

本発明の一実施例によれば、ユーザ・エージェント（ＵＡ）１０８は、全部ではないが複数のコントローラ１４０に同時に登録できる。ユーザ・エージェント（ＵＡ）１０８が同時に登録されている各コントローラ１４０は、異なる属性を有し、それ故にユーザ・エージェント（ＵＡ）１０８に異なるＳＩＰ機能を与えることができる。例えば、ユーザ・エージェント（ＵＡ）１０８は、第１コントローラ１４０ａと第２コントローラ１４０ｂに同時登録できる。第１コントローラ１４０ａは、延長した（即ち高級フューチャーセット：advanced feature sets）エクステンションを使用する。第２コントローラ１４０ｂは、標準のInternet Engineering Task Force（ＩＥＴＦ）に適合するＳＩＰエクステンションを使用する。これは、ＲＦＣ３２６１を含むＳＩＰプロトコール上の１つ或いは複数のＩＥＴＦＲＦＣに従って、呼びを処理するものである。

同時登録構成においては、ユーザ・エージェント（ＵＡ）１０８は、アクティブ−アクティブ登録、又はアクティブ−スタンバイ登録のいずれかが可能である。
アクティブ−アクティブ登録においては、ユーザ・エージェント（ＵＡ）１０８は、自身が登録されているあらゆるコントローラ１４０からＳＩＰメッセージを受領し、ＳＩＰメッセ−ジを自身が登録されているあらゆるコントローラ１４０に送ることができる。これは、メッセージがプライマリ・コントローラ１４０に送られたか、或いはプライマリ・コントローラ１４０から送られて来たかを決定せずに行う。
アクティブ−スタンバイ登録構成においては、ユーザ・エージェント（ＵＡ）１０８は、ＳＩＰシグナリングの為に、アクティブなコントローラ１４０のみを使用するが、但し、これはアクティブなコントローラ１４０が動作不可能でない場合に限られる。
このような構成においては、メッセージをスタンバイのコントローラ１４０から受領した場合においては、ユーザ・エージェント（ＵＡ）１０８は、対応するプライマリ・コントローラ１４０は動作可能であるとして、ＳＩＰメッセージをスタンバイのコントローラ１４０に戻し、プライマリー・コントローラ１４０を介して、メッセージを再配送する。

本発明の更なる実施例によれば、ユーザ・エージェント（ＵＡ）１０８は、コントローラ１４０ａ−Ｎに優先登録を実行する。これにより、ユーザ・エージェント（ＵＡ）１０８は、第１のコントローラ１４０ａに登録されるが、これは、ユーザ・エージェント（ＵＡ）１０８が、第１のコントローラ１４０ａがアウトオブサービス状態か、或いはＳＩＰ機能を提供することができないと決定しない場合に限られる。この場合、ユーザ・エージェント（ＵＡ）１０８は、第２のコントローラ１４０ｂに登録される。

本発明の更なる実施例によれば、ピアツーピア（peer-to-peer）のＳＩＰネットワーク構築を採用することもできる。このネットワークの場合には、ユーザ・エージェント（ＵＡ）１０８は、別のエンドポイント或いは複数のエンドポイント上にあるコントローラ１４０に登録する。

ユーザ・エージェント（ＵＡ）１０８は、メモリ１１２とプロセッサ１２４を有する。プロセッサ１２４は、メモリ１１２内に記録されたルーチンを実行し、来入／出発ＳＩＰメッセージとメディアを処理する。メモリ１１２は、ディスカバリ・モジュール１１６とコントローラのリスト１２０とを有する。ディスカバリ・モジュール１１６は、通信システム１００内でユーザ・エージェント（ＵＡ）１０８を制御できるコントローラ１４０を含む装置を発見する機能を有する。本発明の一実施例によれば、ディスカバリ・モジュール１１６は、利用可能なコントローラ１４０が応答できるディスカバリー・リクエストを送信する。コントローラ１４０から受信した応答（又は応答の欠如）に基づいて、ディスカバリ・モジュール１１６は、コントローラのリスト１２０に複数のコントローラ１４０を入れる（登録する）。ディスカバリ・モジュール１１６は、順番リストを作る。この順番リストは、その属性１３２に基づいたコントローラ１４０の優先リストを含む。ユーザ・エージェント（ＵＡ）１０８は、どのコントローラ１４０を登録するかを、コントローラ・リスト１２８内のコントローラ１４０の順番に基づいて、決定する。

ディスカバリ・モジュール１１６は、コントローラ１４０を発見し、コントローラ１４０の間の仲裁を行う機能を提供するに加えて、更に通信システム１００の状態を監視して、現在のネットワーク１０４の故障、サーバ１３６の故障、ゲートウエイ１４８の故障、或いは他の種類の故障（例、ユーザ・エージェント（ＵＡ）１０８、そのコントローラ１４０との間の関連に影響を及ぼすような故障）があるか否かを決定する。以下に詳述するように、ディスカバリ・モジュール１１６は、通信システム１００とその構成要素の状態をプロアクティブにかつリアクティブに監視する。
通信システム１００の状態をプロアクティブに監視している間、ディスカバリ・モジュール１１６は、ノン・ダイアログのＳＩＰメッセージを所定のロジックと共に採用して、通信システム１００の状態を決定する。ユーザ・エージェント（ＵＡ）１０８は、更に別の通信システム１００の構成要素（例；ゲートウエイ１４８）により、通信システム１００の状態をリアクティブに監視するよう、促される。ユーザ・エージェント（ＵＡ）１０８に通信システム１００の状態を監視する機能を提供することにより、他の構成要素（例えばルーター）から処理負荷を取り除く。これにより、ユーザ・エージェント（ＵＡ）１０８は、通信システム１００の状態を独立して監視することができる。これにより通信システム１００をより良く監視することができ、且つユーザ・エージェント（ＵＡ）１０８は、コントローラ１４０のための個人的な記録を保持する。言い換えると、ユーザ・エージェント（ＵＡ）１０８からのインテリジェンスと通信システム１００内の他の構成要素（例、ゲートウエイ１４８またはサーバ１３６）との組合せを用いて、システム１００の状態をより正確でかつ最新の状態のピクチャを得ることができる。ユーザ・エージェント（ＵＡ）１０８が、ネットワークレイヤーの操作性（例；通信システム１００を通してＩＰパケットを送信することにより）と、ＳＩＰアプリケーションレイヤー（例；通信システム１００を通してＳＩＰメッセージを送信することにより）と、この二つの組合せを検査することができることにより、システムの健全性のピクチュアの正確性を更に増すことができる。

サーバ１３６とゲートウエイ１４８は、ディスカバリ・モジュール１４４を有し、通信システム１００の状態を評価する。より具体的には、各ディスカバリ・モジュール１４４を用いて、独立に様々なピア構成要素（例；ディスカバリ・モジュール１４４を含む装置に隣接する通信システム１００の構成要素）と遠端の構成要素（ディスカバリ・モジュール１４４を含む装置に隣接しない通信システム１００の構成要素）の状態を監視する。各ディスカバリ・モジュール１４４を用いて、通信システム１００とその構成要素の状態を独立に評価する。

ディスカバリ・モジュール１４４は、ソフトウエア・モジュールを有する。このソフトウエア・モジュールには、通信システム１００又は他のエンドポイント１５６が、集団として（slustered way：即ち、複数のサーバ１３６が、エンドポイントからの問い合わせ「どのコントローラを私（エンドポイント）は使うべきか」の質問に答える形で）、又は単独で、アクセスできる。ディスカバリ・モジュール１４４は、複数のプロトコールを用いて実現でき、更に同時に複数のプロトコールをサポートできる。より具体的には、各ディスカバリ・モジュール１４４は、ＳＯＡＰ／ＨＴＴＰと、ＳＸＡＰ（ＳＯＡＰのようなＨＴＴＰ標準を介した別のＸＭＬ）と、更には又ＳＩＰ（例；ＳＩＰメッセージの本体内にコントローラ１４０のリストを提供することにより）の中の１つ或いは複数のプロトコルをサポートする。

ディスカバリ・モジュール１４４は、あるユーザ・エージェント（ＵＡ）１０８に対し、自分自身のコントローラのリスト（どのコントローラが、リクエストによりユーザ・エージェント（ＵＡ）１０８に最終的に提供されるかを決めるリスト）を、ルールプロセッシングを介して、決定する。このルールプロセッシングは、ハード・コーディッド（hard coded)( ＪＡＶＡ（登録商標） code）されるか、ルールエンジンを有する。このルールエンジンは、スクリプト（例、ＸＭＬ）を取り出し、それを解析して、それを所定の時に実行する。所定の時とは、スクリプトが、コントローラのリストを要求しているユーザ・エージェント（ＵＡ）１０８に対し、どれが最も適切なコントローラ１４０であるかを決定することを望んだ時である。アルゴリズムに含まれるルールの種類は、以下のものが含まれる。
（１） ネットワークの局地性検査
このネットワーク局地性検査は、現実のネットワークトポロジーを解析し（ネットワークを介して送信されたＩＰパケットを解析することにより）、ユーザ・エージェント（ＵＡ）１０８に対し最も適切なコントローラ１４０を決定する。このルール・セットは、バンド幅管理機能を有する。このバンド幅管理機能により、ディスカバリ・モジュール１４４は、ユーザ・エージェント（ＵＡ）１０８を要求したＩＰを検査し、その後最も利用可能なバンド幅をリストアップしているバンド幅の記憶リストをルックアップし、その後ユーザ・エージェント（ＵＡ）１０８にベスト・マッチするコントローラ１４０を選択する。この場合、ベスト・マッチするものは、ユーザ・エージェント（ＵＡ）１０８に最も近く利用可能なバンド幅を有するコントローラ１４０を含むサーバ１３６である。
（２）セキュリティ検査アルゴリズム
このアルゴリズムがルールの含まれる理由は、ユーザ・エージェント（ＵＡ）１０８が、セキュリティのために、特定のサーバ１３６／コントローラ１４０に接続すべき場合が存在するからである。例えばＣＥＯの電話は、セキュリティの最も高いサーバにのみ接続される。この最も高いセキュリティは、常に監視され数秒で接続チされる。他方技術サポート部門の電話は、サーバ群を構成するサーバ１３６の組のどれにでも接続することが許される。このサーバ群では、セキュリティ監視が２４時間以内に行われる。
（３）ユーザ割り当てアルゴリズム
ユーザ割り当てアルゴリズムにより、ディスカバリ・モジュール１４４は、どのサーバ１３６が特定のユーザにサービスを提供するかを決めるマッピングを検査する。複数のサーバがある場合（例、georedundancyの構築がある場合）には、複数のコントローラ１４０が応答して戻される。
（４）ビジネスルールアルゴリズム
ビジネスルールアルゴリズムにより、ディスカバリ・モジュール１４４は、スクリプト内で、顧客にフック（Hook）を具備させる。このスクリプトでは、全てのセールスマンはあるサーバ１３６を使い。全ての技術サポート部隊は別のサーバを使うと規定する。
（５）装置のモード・アルゴリズム（device modality algorithum）
これは、ユーザ・エージェント（ＵＡ）１０８が、コントローラ１４０に対し要求しているモード（例；音声、インスタントメッセージ（ＩＭ）、画像等）を表す時に、開始する。このアルゴリズムを採用すると、ディスカバリ・モジュール１４４は、内部の資格アサイメント（internal capabiltiy assignment）をルックアップし、ユーザに最適のタイプのモードを提供するのにベストなコントローラ１４０を選択する。音声とインスタントメッセージを提供できるユーザ・エージェント（ＵＡ）１０８は、ボイス用のサーバだけよりもこれらの機能の両方をサポートできるサーバ１３６を好む。
（６）プロトコール適合性アルゴリズム
プロトコール適合性アルゴリズムは、要求しているユーザ・エージェント（ＵＡ）１０８が、それが特定のプロトコールのセットをサポートしていることを認識した時に、開始する。これは特にＳＩＰの場合に有用である。その理由は、ＳＩＰは、複数のプロトコール・エクステンションだからである。要求しているユーザ・エージェント（ＵＡ）１０８が、コントローラ１４０に問い合わせると、コントローラ１４０は、それがサポートするプロトコール特徴（例、presence subscription又はsubscription全般）を表し、サーバは、そのユーザ・エージェント（ＵＡ）１０８に対しベストマッチを見出すことができる。

図２を参照すると、ＳＩＰコントローラ１４０の発見方法と登録方法を、本発明の一実施例で説明する。この方法は、システム１００内のエンドポイント（例、ユーザ・エージェント（ＵＡ）１０８）で実行される。システム１００内のユーザ・エージェント（ＵＡ）１０８は、様々なコントローラ１４０を発見し登録する。この方法が開始されるのは、エンドポイントが、ディスカバリ・メッセージを送信した時（ステップ２０４）である。ディスカバリ・メッセージは、本発明の一実施例によれば、ＳＩＰメッセージ（例、ＯＰＴＩＯＮメッセージ、ＮＯＴＩＦＹメッセージ、ＳＵＢＳＣＲＩＢＥメッセージ）を含む公知のディスカバリ・メッセージを含む。このディスカバリ・メッセージは、システム１００内の１つ或いは複数の構成要素に送信され、その構成要素のＳＩＰ機能をテスト或いは問い合わせをする。

ディスカバリメッセージを、コントローラ１４０を含む通信システム１００の他の構成要素（例；サーバ１３６又はゲートウエイ１４８）が受領すると、この他の構成要素は、ディスカバリメッセージに対し応答メッセージで応答する。別の構成として、どの構成要素もディスカバリメッセージに対し応答ができない時には、応答メッセージは、開始したエンドポイントには戻されない。コントローラ１４０の応答メッセージは、その後開始したエンドポイントが、受領する（ステップ２０８）。エンドポイントが、ディスカバリメッセージに対する応答を受領すると、或いは応答が無いことが判ると、エンドポイントは、そのディスカバリ・モジュール１１６を採用して、コントローラのリスト１２０に入れる。

応答メッセージは、応答したコントローラ１４０の属性１３２を含む。応答メッセージに含まれる属性情報の一例は、サーバ１３６又はゲートウエイ１４８の処理能力と、コントローラ１４０により提供されるＳＩＰエクステンション（即ち、ＳＩＰ機能）と、コントローラ１４０に現在登録してあるＵＡの数と、コントローラ１４０とエンドポイントとの間の距離（即ちエンドポイントと対応する装置との間のホップ数）等である。エンドポイントのディスカバリ・モジュール１１６は、この属性情報を用いて、コントローラのリスト１２８内のコントローラ１４０の順番を調整して、順番の付いたコントローラのリスト１２８を構成する（ステップ２１２）。ディスカバリ・モジュール１１６は、あらゆる種類の公知の属性アルゴリズムを用いて、コントローラ１４０の順番を決定することができる。例えばディスカバリ・モジュール１１６は、コントローラ１４０のリストアップされた属性の全てを最適化しようとする。別の構成として、ディスカバリ・モジュール１１６は、エンドポイントのニーズに最も適した選択された属性を有するコントローラ１４０を、順番リスト１２８の最高位に、置く。

エンドポイントの１６０がコントローラ・リスト（順番リスト）１２８を生成した後、ディスカバリ・モジュール１１６は、エンドポイントが登録されるコントローラ１４０の数Ｎをを決定する（ステップ２１４）。即ち、ディスカバリ・モジュール１１６は、コントローラ・リスト１２８内の「ウインドウ」のサイズを選択する。本発明によれば、数Ｎは管理しながら予め決定される。本発明によれば、数Ｎは、ディスカバリ・モジュール１１６が採用するルール・セットに従って、決定される。この決定は、コントローラ・リスト１２８内のコントローラ１４０の属性１３２のような基準を考慮に入れて行われる。その後ディスカバリ・モジュール１１６は、登録されたＮ個のコントローラを選択する（ステップ２１６）。数Ｎは、２以上の整数であるが、コントローラ・リスト１２８内のコントローラ１４０の全数未満である。コントローラ１４０は、コントローラ・リスト１２８内のそれぞれの順番に基づいて、選択される。本発明の一実施例によれば、ディスカバリ・モジュール１１６は、サーバ１３６からコントローラ１４０を、ゲートウエイ１４８からコントローラ１４０を選択して、同時に登録する。アクティブ−スタンバイ構成においては、エンドポイントは、１個のサーバ１３６のコントローラ１４０を、プラマリ・コントローラとして選択し、他のサーバ１３６又はゲートウエイ１４８のコントローラ１４０を第２の即ちバックアップ・コントローラとして選択する。

コントローラ１４０の選択の後、エンドポイントは、選択されたコントローラ１４０に登録できる（ステップ２２０）。本発明の一実施例によれば、エンドポイントは、異なる様々な機能／仕様あるいは様々なＳＩＰ特徴を有するコントローラ１４０に登録される。例えばエンドポイントは、拡張したＳＩＰエクステンション（extended SIP extension）を用いて第１のコントローラ１４０に、標準のＳＩＰエクステンション（standard SIO extension）を用いて第２のコントローラ１４０に同時に登録することができる。拡張したＳＩＰエクステンションは、第１のコントローラ１４０が用いるが、第２のコントローラ１４０では得られない追加的な特徴を提供する。

ＳＩＰ ＲＥＧＩＳＴＥＲ，ＳＵＢＳＣＲＩＢＥ，ＯＰＴＩＯＮメッセージ或いは他のＳＩＰシグナリングは、プライマリ・コントローラ１４０が依然としてオンライン中であり、ＳＩＰメッセージを促進するか否かを決定するために、送信される。例えばＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、エンドポイントが選択したコントローラ１４０に送られて、登録プロセスを開始する。ＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、エンドポイントにそのコントローラ１４０の登録する機能を与えることに加えて、コントローラ１４０に対するheartbeat（同期信号）として用いられる。ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの伝送周期は、システムの要求に基づいて、ユーザにより構築可能である。言い換えると、エンドポイントは、リフレッシュ登録信号を登録されているコントローラ１４０に送る。

アクティブ−スタンバイ構成とアクティブ−アクティブ構成の両方において、エンドポイントは、選択されたコントローラ１４０の全てに同時に登録する（登録される）。この操作の間、エンドポイントは、コントローラ１４０と同時のアクティブ登録を維持しようとする（例、付属のＳＩＰ ＲＥＧＩＳＴＥＲメッセージの周期的伝送を介して）。アクティブ−アクティブ構成において、エンドポイントは、それが登録されたどのコントローラ１４０との間でもＳＩＰメッセージの送受信が許される。この構成において、エンドポイントは、複数のコントローラ１４０に同時に登録できる。この二重登録により、インバウンド（来入）ＳＩＰリクエスト（例；ＳＩＰ ＩＮＶＩＴＥメッセージ）を、エンドポイントが登録されたコントローラ１４０のいずれか１つ（例、第１のコントローラ１４０ａと第２のコントローラ１４０ｂと第３のコントローラ１４０ｃ等）から受信できる。エンドポイントが、アクティブ−アクティブ・コントローラモデルを用いるポリシーで構築された場合には、エンドポイントは、前に故障したコントローラ１４０からの来入呼びを、サービス中のコントローラ１４０から入ってきたものと見なす。これが起きると、エンドポイントは、アルゴリズムに再度トライして、故障したサーバがサービスに戻ったか否かを検出する。エンドポイントは、あらゆるコントローラ１４０からこのＳＩＰメッセージが受信できるよう構成される。本発明の一実施例においては、エンドポイントは、登録を独立登録として取り扱い、ここで述べた登録ロジックで、それ等のおのおのを維持する。より具体的には、エンドポイントは、同一のＡＯＲを各コントローラに登録することが許されるが、エンドポイントの実行は、別のＡＯＲを収納することもできる。このことは、アクティブ−スタンバイ構成についても当てはまる。

他方、アクティブ−スタンバイ構成においては、エンドポイントは、アウトバンウドコール（発呼）をルーティングし、そのプライマリ・コントローラ１４０からのインバウンドコール（来入呼び）を受領する。操作中において、このプライマリ・コントローラ１４０は、アクティブなコール・コントローラ１４０と称する。エンドポイントが登録した他のコントローラ１４０は、インアクティブ即ちスタンバイのコントローラと称する。

アクティブ−スタンバイ構成において、エンドポイントは、プライマリ・モードにある（即ち、エンドポイントは、プライマリ・コントローラ１４０は活性状態にあると考えている）間、エンドポイントが、第２の即ちスタンバイのコントローラ１４０からインバウンドコールを受信すると、エンドポイントは、次のことを行う。
（１）第２のコントローラ１４０に対し、１００Tryingメッセージで応答する。
（２）ＲＥＧＩＳＴＲＡＴＩＯＮrefreshを、プライマリ・コントローラ１４０に送り、プライマリ・コントローラ１４０が、依然としてオンラインにあり、ＳＩＰメッセージングを促進できるか否かを見る。
（３）プライマリ・コントローラ１４０が依然としてオンラインにある場合には、エンドポイントは、３０５リダイレクト応答（305 redirect resonse）（即ち、Ｕｓｅ Ｐｒｏｘｙ）を第２のコントローラ１４０に送る。この３０５リダイレクト応答は、呼びを第２の呼びコントローラを介して拒否し、第２のコントローラ１４０が、シグナリングをプライマリ・コントローラ１４０を介して再ルートすることを、要求する。
（４）プライマリ・コントローラがオンラインにない場合には、エンドポイントは受信した呼びに対し標準の呼び処理を提供する。このプロセスの一部として、エンドポイントは、第２のコントローラ１４０にプライマリ・コントローラ１４０からフェール・オーバし、その第２のコントローラ１４０での登録をリフレッシュする。

アクティブ−スタンバイ構成において、エンドポイントは、フェール・オーバモードで動作している（即ち、プライマリ・コントローラ１４０は、アウトオフサービスの状態であり、第２のコントローラ１４０を活性状態のあるコントローラとして用いると仮定する）間、エンドポイントは、プライマリ・コントローラ１４０からインバウンドコールを受領するが、その間呼びは拒絶される。

故障状態の間、或いはエンドポイントが、通信システム１００の構成要素がアウトオフサービスの状態にいる見なしている間は、エンドポイントは、プライマリ・コントローラ１４０とのリアルタイムの通信セッションを確立しようとはしない。さらにエンドポイントは、コントローラ・リスト１２８上の第２の即ち次のコントローラ１４０に、フェール・オーバする。生き残った（即ち、第２の、第３の或いはバックアップの）コントローラ１４０を介してルーティングされたコールシグナリングにより、エンドポイントのユーザは、故障の間、新たな呼びを発信しまた受領することができる。

フェール・オーバ／フェールバック・プロセスの一部として、エンドポイントは、活性状態にあるコントローラ１４０のアドレスを特定し、更にコントローラ１４０によりサポートされている属性と関連する特徴を引き出す。言い換えると、エンドポイントは、エンドポイントが登録されているコントローラ１４０が「拡張された／所有の」として又は「ベーシックなＳＩＰ」として指定されているか否かに関わらず、引き出す。エンドポイントのディスカバリ・モジュール１１６は、コントローラが、拡張したＳＩＰ、或いはベーシックなＳＩＰを使用しているかを、以下のロジックを用いて発見する。
（１）フェール・オーバ又はフェールバックすると、エンドポイントは、各コントローラ１４０に対し登録をリフレッシュ或いは更新する。
（２）このプロセスの一部として、エンドポイントは、第２のコントローラ１４０で、全てのプライマリ・コントローラ１４０の特徴のパッケージに再度登録しようと試みる。
（３）エンドポイントが、ＳＵＢＳＣＲＩＢＥリクエストを第２のコントローラ１４０に送ると、第２のコントローラ１４０は、それがベーシックなＳＩＰオペレーションだけをサポートしている場合には、特徴加入リクエストを認識しない。
（４）単一の第２のコントローラ１４０は、Client Error 405 Method Not Allowedで応答する。

エンドポイントは、この情報を用いて、第２のコントローラ１４０は、標準のＩＥＴＦ ＳＩＰ適合するコントローラ１４０であると認定する。その後エンドポイントは、フェール・オーバモードで動作している間、そのユーザインターフェイス（ＵＩ）上にベーシックＳＩＰフューチャのみを表示する。活性状態にあるコントローラ１４０が、「エクステンドした」（例、それが、適切にＳＵＢＳＣＲＩＢＥリクエストに応答しているので）と指定されると、エンドポイントは、呼びと特徴処理用の拡張エクステンションのＳＩＰを使用し、適合したＵＩを表示する。

アクティブ−スタンバイ構成で提供される更なる特徴は、次のものを含む。
（１）エンドポイントは、アウトバウンドコールを非活性状態のコントローラ１４０には送らない。
（２）エンドポイントが、活性状態のコントローラ１４０からスタンバイのコントローラ１４０にフェール・オーバした時には、前に活性状態にあったコントローラ１４０は、非活性状態として指定され、前に非活性状態にあったコントローラは、活性状態として指定される。
（３）エンドポイントは、指定されたコントローラ１４０にフェール・オーバする前に、全ての活性状態にある呼びが完了するまで待機する。言い換えると、新たに指定された活性状態にあるコントローラ１４０からの新たなインバウンドの呼びは、アクティブな呼びが完了する（即ち、エンドポイントがアクティブな呼びに対するネットワーク１０４からのＢＹＥメッセージを受領するか或いは発呼者が電話を切るかの何れか）までは、エンドポイントは受領しない。同様に新たなアウトバウンドの呼びは、フェール・オーバが完了するまで、許されない。
（４）エンドポイントが、プライマリの（しかしアウトオブサービスの）コントローラ１４０からシグナリングメッセージを受領すると、その間エンドポイントは、第２のコントローラ１４０を用いているが、第１のコントローラ１４０からのアウトオブサービスとしてマークされたシグナリングメッセージは、無視される。このルールに対しては１つの例外がある。即ち、エンドポイントが、プライマリ・コントローラ１４０からＮＯＴＩＦＹメッセージ（再レジスタを通知する）を受領すると、エンドポイントは、その登録をリフレッシュする為にリフレッシュするか、それを試みることを開始する。この場合、エンドポイントは、ＮＯＴＩＦＹメッセージに標準のＳＩＰプロセッシングを用いて応答する。

エンドポイントが、それぞれのコントローラ１４０で登録した後は、本発明の方法は終了する（ステップ２２４）。

図３を参照して、本発明の一実施例による通信システム１００の状態決定方法を次に説明する。サバイバル構成において、ゲートウエイ１４８を搭載して、コールシグナリングを、プライマリのシグナリングパス又は第２のシグナリングパスを介して、ルーティングする時を決定することが重要である。この方法は、ゲートウエイ１４８が、ＳＩＰ ＯＰＴＩＯＮメッセージを、通信システム１００内の別の構成要素に送る時に開始する（ステップ３０４）。このような構成要素は、ＳＩＰがイネーブルある構成要素に対応する。この構成要素は、ピア構成要素（即ち、ゲートウエイ１４８に隣接する構成要素）と／又は遠端構成要素（即ち、構成要素とゲートウエイ１４８との間の少なくとも一個の中間構成要素を有する構成要素）に対応する。ＳＩＰの遠端構成要素のプロアクティブなモニタリングは、予備的に（sparingly）実行しなければならない。通常これは、通信システム１００のアドミニストレータが中間構成要素がそれ等のピアを監視することができないと決定した場合である。ゲートウエイ１４８は、ＳＩＰ ＯＰＴＩＯＮメッセージをＭａｘ−Ｆｏｒｗａｒｄｓ＝０に設定して送る。これにより、ＯＰＴＩＯＮメッセージが、複数のホップを横切らないようにする（即ち、ピア構成要素の方向を目標とする）。

当業者に明らかなように、ＳＩＰ ＯＰＴＩＯＮメッセージを採用するモニタリング技術をここでは説明するが、非ダイアログ型のＳＩＰトランザクションの他の種類の技術を用いて、通信システム１００とその中の構成要素の状態をモニタすることもできる。より具体的には、一般的なＳＩＰメッセージ（例；ＩＮＦＯ ＭＥＴＨＯＤメッセージ，ＭＥＳＳＡＧＥＭＥＴＨＯＤメッセージ、更にはボイドＳＩＰメッセージ）を送信して、あらゆるタイプのＳＩＰベースの応答を引き起こすこともできる。ゲートウエイ１４８により送信されたＳＩＰメッセージは、メッセージ受領者が実行する指示を含む。例えばＳＩＰメッセージは、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）を含むよう生成してもよい。このＸＭＬメッセージは、ゲートウエイ１４８の正常状態と、ゲートウエイ１４８により監視される他の構成要素（例えばピア構成要素）と、更にはゲートウエイ１４８の報告された健全状態に基づいて受領者により執られるアクションを報告する。

ゲートウエイ１４８が、ＳＩＰ ＯＰＴＩＯＮメッセージを送りだした後、ゲートウエイ１４８は、その応答を待つ（ステップ３０８と３１２）。ゲートウエイ１４８が応答を待つ時間は、通信システム１００の特性により変わる。本発明の一実施例によれば、ゲートウエイ１４８が待つ時間の長さは、ＳＩＰタイマー機能を実行することにより決定される。例えば、ＳＩＰタイマーＢ又はＳＩＰタイマーＦ（ＳＩＰタイマーＢとＦは、ＲＦＣ３２６１で定義される標準のＳＩＰタイマーである）である。このタイマーは、リクエスト送信した後所定の秒数内にＳＩＰ応答を受領しない場合には、ＳＩＰシグナリングトランザクション（例；ＳＩＰ ＩＮＶＩＴＥメッセージ）をキャンセルする。タイマーＢ又はタイマーＦは、、ＳＩＰ応答（更には１００回のトライでも）を受領した場合には、キャンセルされる或いは短絡される。しかし、タイマーＢが起動すると、ゲートウエイ１４８は、攻撃的なＳＩＰトランザクションをキャンセルすることが要求され、別のルートを用いてリクエストをルーティングするよう試みる。ゲートウエイ１４８が知っている全てのルーティングアドレスを使い尽くすと、ＳＩＰのゲートウエイ１４８は、元のＳＩＰシグナリングトランザクションに、４０８リクエスト タイムアウトで応答する。

応答（例、実際の応答、又は応答を所定の時間内に受領しなかったという決定）を受領すると、本発明の方法は、ディスカバリ・モジュール１４４を採用するゲートウエイ１４８で継続し、応答が故障状態に対応するか否かを決定する（ステップ３１６）。応答は、第１ネットワーク１０４又は通信システム１００の構成要素が、以下の状態の何れかになった時には、故障しているとする。
（１）ＯＰＴＩＯＮモニタリング・リクエストがタイムアウトにより失効する時。
（２）ＳＩＰリクエストトランザクションの連続して失敗する回数が。トランザクションタイムアウトと／又はＳＩＰタイマーＢのタイムアウト（ＩＮＶＩＴＥトランザクション）に起因して発生した時。
（３）ＯＰＴＩＯＮモニタリングリクエストに対する４００又は５００クラスの応答をＲｅｔｒｙ−Ａｆｔｅｒ ｈｅａｄｅｒで受領した時。但し、これは、モニタリングがホップ・バイ・ホップ（即ち、Ｍａｘ−Ｆｏｒｗａｒｄ＝１）を実行し、エンド・トゥ・エンド（即ち、Ｍａｘ−Ｆｏｒｗａｒｄ＞１）ではなく、更には又アドレスが、Ｒｅｔｒｙ−Ａｆｔｅｒ ｈｅａｄｅｒに指定された少なくともその期間の間「過負荷」としてマークされた時にのみ起こる。

条件（３）に関しては、アドレスのＩＰアドレスを含む既存のダイアログは、故障が起きない限り、そのアドレスを使用し続けなければならない。しかし、エンドポイントは、それが復活するまで、新たなダイアログに対するそのアドレスの使用してはならない。既存のダイアログが、ＩＰアドレスの代わりにホストネームを使用している場合には、各トランザクションのホストメールのリゾリューションが発生し、戻されたアドレスが利用可能な最高優先度のアドレスとなる。ホストネームのみが単一のＩＰアドレスにｒｅｓｏｌｖｅする時には、そのアドレスはオーバロード（過負荷）としてマークされ、リクエストを送らなければならない。条件（３）の実際の効果は、ゲートウエイ１４８のディスカバリ・モジュール１４４は、３つの状態（即ち利用可能、オウトオブサービス、過負荷）を知らなければならない。過負荷としてマークされたアドレスは、ダイアログ内でその後のリクエストを受領し続けるが、新たなダイアログリクエストは受領しない。

ＯＰＴＩＯＮメッセージの応答に基づいて、ゲートウエイ１４８のディスカバリ・モジュール１４４は、故障状態が存在しないと、通信システム１００が通常の動作状態にあると決定すると、ディスカバリ・モジュール１４４は、インストラクションが応答中に含まれているか否かを決定することにより、継続する（ステップ３２０）。ディスカバリ・モジュール１４４は、応答に付属した又は応答内（即ち、メッセージのヘッダー又はフッター）に含まれる実行可能なインストラクションに対する応答を解析する。インストラクションが応答中に含まれると、インストラクションが実行される（ステップ３２４）。その後又は応答がインストラクションを含まない場合には、ディスカバリ・モジュール１４４は、通信システム１００の状態に対するその記録の更新を継続し、応答中の構成要素（例、サーバ１３６）の動作を反映する（ステップ３２８）。ネットワークの状態が更新されると、本発明の方法は、ディスカバリ・モジュール１４４で継続し、新たなメッセージを送信する時間か否かを決定する（ステップ３３２）。より特殊な場合には、ゲートウエイ１４８は、ＳＩＰ ＯＰＴＩＯＮメッセージの他のＳＩＰサーバ１３６への周期的な送信を、ハートビートメカニズム（同期メカニズム）として使用し、ＳＩＰサーバ１３６が活性状態か否かを決定する。ＯＰＴＩＯＮメッセージは、所定のインターバルで、通信システム１００の構成要素に送られる。所定のインターバルの長さは、ＳＩＰタイマーＢ又はその変形例を実現することにより決定される。より具体的には、ＯＰＴＩＯＮの監視は、ゲートウエイ１４８が故障状態を検出するか否かに応じて、様々なインターバルで実行することができる。

例として、ＳＩＰ ＯＰＴＩＯＮメッセージに対するプロアクティブなモニタリング・インターバルは、６０秒から１０万秒の間で構築可能であり、後続のモニタリングの試みの間の値の７５％と１２５％の間の均一なランダムな時間を用いるべきである。例えば、プロアクティブなモニタリングインターバルを６０秒に設定すると、ＯＰＴＩＯＮメッセージの送信の間の実際のインターバルは、４５秒と７５秒の間で均一に分布する。プロアクティブなモニタリングプロセスにジターを意図的に導入することにより、リクエストを同期しないように維持し、これにより、モニタされた構成要素（即ち、サーバ１３６）に時間的に負荷を拡散することさえできる。本発明の一実施例においては、プロアクティブなモニタリングインターバルは、９００秒即ち１５分である。

例として、ＳＩＰ ＯＰＴＩＯＮメッセージに対するリアクティブなモニタリング・インターバルは、１０秒から３６００秒の間で構築可能であり、後続のモニタリングの試みの間の値の７５％と１２５％の間の均一なランダムな時間を用いてもよい。リアクティブなモニタリング（プロアクティブなモニタリングとは対照的に）に対する個別にタイマーを設けることにより、ゲートウエイ１４８は、現在アウトオブサービスにあるモニタ中の構成要素が再び利用可能となる時間をより早く検出できる。本発明の一実施例においては、リアクティブなモニタリング・インターバルは１２０秒に設定される。

上記の説明は、ＳＩＰタイマーＢの使用に関連するが、如何なる範囲の値も、その値が均一でランダムな時間の有無に関わらず、本発明の原理から離れることなく実現できる。更にモニタリングインターバルは、外部ビジネスロジックフックに基づいて、修正可能である。例えば、モニタリング機構が、バンド幅のマネジメントシステム内にフックしている時には、モニタリングシステムは、更にモニタリングインターバルを調整できるが、これは、ネットワーク内の利用可能なバンド幅を表すある係数を用いて行う。
ステップ３６０に戻って、ディスカバリ・モジュール１４４が、応答が故障状態に対応すると決定すると、ディスカバリ・モジュール１４４は、通信システム１００の状態の記録を更新して故障を反映する（ステップ３３６）。この構成要素の故障を検出した結果、ゲートウエイ１４８は、フェール・オーバし、フェール・オーバ状態で動作を開始する。特に故障した構成要素が主通信パス上にある場合にはそうである。

フェール・オーバの間、ゲートウエイ１４８のディスカバリ・モジュール１４４は通信システム１００内の構成要素のリアクティブなモニタリングを開始する。これは、ＯＰＴＩＯＮメッセージをアウトオブサービスとして認定された構成要素に送り続けることにより、行われる（ステップ３４０）。このリアクティブなモニタリングにより、ゲートウエイ１４８のディスカバリ・モジュール１４４は、構成要素がオンラインにいつ戻ったかを決定できる。リアクティブなモニタリングが開始すると、ゲートウエイ１４８は、構成要素をプロアクティブにモニタリングすることを中止し、リアクティブなモニタリングルールを適用する。より具体的には、リアクティブなモニタリングの間、ゲートウエイ１４８のディスカバリ・モジュール１４４は、メンテナンステストを開始して、モニタされた構成要素が、利用可能か或いはアウトオブサービスかを決定する（ステップ３４４）。メンテナンス・テストは、プロアクティブなモニタリングアルゴリズムに類似するモニタリングアルゴリズムを採用してもよい。ゲートウエイ１４８のディスカバリ・モジュール１４４は、このメンテナンステストを、フェールバックする（即ち、構成要素の状態がアウトオブサービスから利用可能になる）まで適用し続ける（ステップ３４８）。メンテナンステストの間、ゲートウエイ１４８は、あらゆる種類のＳＩＰリクエスト（例；ＩＮＶＩＴＥ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ等）を、現在アウトオブサービスとしてマークされている構成要素に送る。以下の条件の１つ或いは複数が適用されると、ゲートウエイ１４８のディスカバリ・モジュール１４４は、構成要素をアウトオブサービスとしてマークし続ける。
（１）ＩＮＶＩＴＥメッセージが送信された後、ＳＩＰタイマーＢが開始する。
（２）ゲートウエイ１４８が、４０８リクエストタイムアウト応答を受領する。
（３）ＳＩＰリクエスト・トランザクションがタイムアウトとなる。
（４）リクエストを送信しようとした時に、ネットワーク１０４或いはトランスポートレイヤーのエラーが発生する。

メインテナンス・テストの間、上記の条件が適合されない場合は、ゲートウエイ１４８のディスカバリ・モジュール１４４は、フェールバックが発生したと決定し、本発明の方法はステップ３２８に進む。本発明の一実施例においては、リアクティブなモニタリングとメインテナンス・テストは、モニタされている構成要素が、２つの連続するＯＰＴＩＯＮリクエストの試みに対するあらゆるＳＩＰ応答（５０３Servei Unavailableを除いて）で返事をするまで、適用され続ける。これらの条件が適合すると、ゲートウエイ１４８は、構成要素はサービスに戻り、プロアクティブなモニタリングアルゴリズムに戻り、適宜のSimple Network Mangement Protocol （ＳＮＭＰ）事象を生成し、適用可能ならば、現在活性中の構成要素の利用を開始する。

当業者には明らかなように、ゲートウエイ１４８は、パスの再割り当て情報を有する通信システム１００の構成要素の唯一のものではない。ＳＩＰネットワーク要素は、パス再割り当て情報を含むよう調整される。例えばエンドポイント（ユーザ・エージェント（ＵＡ）１０８）は、パス再割り当てテーブルを有する。このパス再割り当てテーブルは、ある構成要素はアウトオブサービスとして指定された時に、使用することができる通信パスをリストアップする。

図４を参照してリアクティブモニタリング方法を説明する。この方法は、ゲートウエイ１４８がサーバ１３６又は通信システム１００の類似する構成要素からリクエストを受領した時に開始する（ステップ４０４）。ゲートウエイ１４８は、受領したリクエストを通常の方法で処理する（ステップ４０８）。具体的には、ゲートウエイ１４８は、送信中の構成要素はサービス中であるかのようにリクエストを処理するが、これは構成要素が実際にサービスしているかどうかを最初に決定することなく行う。

その後、ゲートウエイ１４８は、送信中の構成要素が実際にアウトオブサービスとしてマークされているかを、最初に維持した状態テーブルに基づいて、決定する（ステップ４１２）。この構成要素がアウトオブサービスとしてマークされていない場合には、本発明の方法は終了する（ステップ４２４）。それ以外は、ゲートウエイ１４８は、メンテナンス・テストを開始するが、これは、ＳＩＰ ＯＰＴＩＯＮメッセージを構成要素に送ることにより行う（ステップ４１６）。その後、ゲートウエイ１４８は、構成要素の状態お記録を更新する（ステップ４２０）。このメンテナンステストと状態更新プロセスは、構成要素がサービスに戻るまで、繰り返し行われ、その時点で、本発明の方法は終了する（ステップ４２４）。

図５を参照して、フェールオーバ状態の間とフェールバック状態の間のゲートウエイ１４８の動作について説明する。以下の方法においては、ゲートウエイ１４８に関連するコントローラ１４０は、サバイバルエンドポイント用の第２の即ちバックアップ用のコントローラ１４０に対応する。この方法は、ゲートウエイ１４８がサバイバル可能なエンドポイントの来入の呼びを受領することにより、開始する（ステップ５０４）。その後ゲートウエイ１４８は、プライマリなシグナリングパスが利用可能かを決定する（ステップ５０８）。本発明の一実施例によれば、ゲートウエイ１４８は、このステップの間、内部構成要素の状態テーブルを参照する。

プライマリ・シグナリングパスが動作可能であると決定すると、ゲートウエイ１４８は、受信した信号を目標のエンドポイントに、プライマリ・シグナリングパスを介してルーティングする（ステップ５１２）。その後この方法は終了する（ステップ５３６）。ゲートウエイ１４８が、プライマリ・シグナリングパスが何らかの理由で利用不可能な場合（プライマリ・シグナリングパス上のネットワーク１０４，サーバ１３６又は他の構成要素がアウトオブサービスの場合）、本発明の方法は、ゲートウエイ１４８で継続し、この信号を目標のエンドポイントに第２のシグナリングパスを介して送信する（ステップ５１６）。このステップは、第２のシグナリングパスは利用不可能ではないという前提の元に行われる。ゲートウエイが、第２のシグナリングパスも利用不可能であると決定すると、故障した構成要素をバイパスする他のバックアップ用シグナリングパスが選択され、それを用いて、信号をエンドポイントに送る。

コールシグナルが目標のエンドポイントに第２のシグナリングパスを介して送信された後、ゲートウエイ１４８は、３０５リダイレクト応答（プロキシを用いた）メッセ−ジを、エンドポイントから受領したか否かを決定する（ステップ５２０）。アクティブ−スタンバイ構成においては、呼び信号を第２パスを介して受信したエンドポイントは、３０５リダイレクト応答を送信する。これは、エンドポイントが第１信号パスが動作可能であると確信した場合である。この確信は、ゲートウエイ１４８ではなくエンドポイントで行われた状態モニタリング動作に基づいて、行われる。かくして、通信システム１００の様々な特徴に基づいて、エンドポイントは、通信システム１００内の構成要素に対しマークされた様々な状態を有する。従って、３０５リダイレクト応答をゲートウエイ１４８が、呼び信号を第２パスを介して再度方向付けることに基づいて受信すると、ゲートウエイ１４８は、呼び信号を、プライマリなシグナリングパスを介して、再度方向付けようとする（ステップ５２４）。プライマリなシグナリングパスが、呼び信号の成功裏の伝送に起因して利用可能であると決定される（ステップ５２８）と、本発明の方法は、ステップ５３６で終了する。呼びが、プライマリなシグナリングパスが利用不可能であることを理由に、拒絶されると、呼びは、リジェクトされるか第２のシグナリングパスを介して送り返される（ステップ５３２）。更に、ゲートウエイ１４８は、ＮＯＴＩＦＹメッセージを目標エンドポイントに送り、エンドポイントに対し、プライマリなシグナリングパスの状態を再度チェックするよう、指示する。その後再度方向付けられた応答メッセージをエンドポイントから受領しない場合には、本発明の方法は終了する（ステップ５３６）。

図６を参照して、通信システム１００の状態決定のエンドポイントの方法を、本発明の第１実施例を参照して説明する。最初に、エンドポイント（生き残ったユーザ・エージェント（ＵＡ）１０８）は、通常の状態で動作する（ステップ６０４）。その後、エンドポイントは、そのディスカバリ・モジュール１１６のロジックを採用して、ネットワークの故障が検知されたか否かを決定する（ステップ６０８）。このサバイバル構成においては、エンドポイントはフェ−ルオーバ又はフェ−ルバックが起きた時を検出できる。エンドポイントにより使用されるディスカバリ・モジュール１１６のロジックは、ネットワークの故障は、以下の事象の１つ或いは複数発生した時に、発生したと決定する。
（１）エンドポイントが、ＳＩＰ Ｒｅｇｉｓｔｅｒメッセージへの応答を全てのコントローラ１４０からのハートビートとして受領しない。これにより登録を試みようとする（例；プライマリと第２のコントローラ１４０）。
（２）エンドポイントは、ＳＩＰ ＩＮＶＩＴＥメッセージに対する応答を受領しない。ここで、ＳＩＰ ＩＮＶＩＴＥメッセージは、アウトバウンドコールを設定しようとする通常のプロセスで送信される。
（３）エンドポイントは、如何なるＳＩＰシグナリングメッセージへの応答も受領しない。このメッセージは、新たなＳＩＰダイアログ変化又は中間ダイアログ変化の通常の創設用に送信される。
（４）エンドポイントは、クリティカルなリクエストに対する成功裏の応答を受領しない。このクリティカルなリクエストは、ＴＣＰ／ＩＰ，ＨＴＴＰ，ＸＭＬ，又はＳＯＡＰのような様々な種類のプロトコールにより搬送され、コンフィギュレーションサーバから或いは他のアウトオブバンドの非通信サービス（例、故障に関連したデータを取り出すのに用いられるデータサービス）から送られる。

エンドポイントが故障そのものを検出しない場合には、本発明の方法は、エンドポイントが、故障が通知されたか否かを決定する（ステップ６１２）。この通知は、ＳＩＰ ＮＯＴＩＦＹメッセージの形態で、エンドポイントが受領する。このメッセージは、ゲートウエイ１４８，サーバ１３６，通信システム１００の状態を監視できる通信システム１００の他の構成要素から送信される。このＳＩＰ ＮＯＴＩＦＹメッセージは、エンドポイントはフェールオーバすべきか、rebootすべきか、或いは全てのコントローラ１４０の登録をリフレッシュ或いはリニューアルすべきかを示す。これによりエンドポイントのロジックを迂回する。通知を受領しない場合、本発明の方法はステップ６０４に戻る。

エンドポイントに通信システム１００内の故障が通知（例；ＳＩＰ ＮＯＴＩＦＹメッセージの受領を介して）されると、エンドポイントは故障通知が正しいか否かを決定する（ステップ６１６）。より具体的には、エンドポイントは、コントローラのリスト１２０，１２８をチェックして、何れかのコントローラ１４０が、インアクティブ或いはアウトオブサービスとしてマークされているか否かを決定する。大部分の時間、エンドポイントは、ＮＯＴＩＦＹメッセージの方向に単に適合しているだけである。このような状況下において、エンドポイントは、通信システム１００のそのビューは正しいビューであり、ＮＯＴＩＦＹメッセージに再度方向付けられた応答メッセージで応答する（ステップ６２０）。この再度方向付けられたメッセージにより、ＮＯＴＩＦＹメッセージの開始構成要素は通信システム１００のビューをチェックする。本発明の方法はステップ６０４に戻る。

エンドポイントが、故障通知が正しいと決定する又はＮＯＴＩＦＹメッセージの方向に合っていると決定すると、エンドポイントは、ＮＯＴＩＦＹメッセージがインストラクションを含むか否かを決定する（ステップ６２４）。このインストラクションは、比較的一般的なインストラクションであり、例えば全てのコントローラ１４０に再度登録することのような試みである。別の構成として、インストラクションは、特定のコントローラ１４０にトライしたり再度登録することをエンドポイントに要求するようなインストラクションの組である。このエンドポイントは、長期インターバル又は短期インターバルのいずれかで、コントローラ１４０にリフレッシュ或いは登録しようとする。リフレッシュ／登録インターバルの間隔は、前記のインストラクションの組内に含まれるインストラクション或いは他ののファクターに依存して、変わる。インストラクションは、通信システム１００全体の正常状態情報を含むが、これは、ＮＯＴＩＦＹメッセージを送信した構成要素により検知される。メッセージがインストラクションを含まない場合には、エンドポイントがインストラクションを実行する（ステップ６２８）。

エンドポイントそのものが故障を検出した場合（ステップ６０８）、或いはインストラクションが、エンドポイントにより実行された後（ステップ６２８）、或いはメッセージがインストラクションを含まない場合（ステップ６２４）、エンドポイントは、コントローラ・リスト１２８内にある次のコントローラ１４０に登録され、登録された動作可能なコントローラ１４０の数Ｎを保持する。登録は、図２のステップ２２０で記載したのと同様な方法で行われる。その後この方法は、フェールオーバを実行するエンドポイントで継続され、その結果、エンドポイントは、バックアップ状態で動作を開始する（ステップ６３２）。フェールオーバモードにおける動作の間、エンドポイントは、バックアップのコントローラ１４０を利用するか、第２のシグナリングパスを利用する。フェールオーバモードで動作することに加えて、エンドポイントは、通信システム１００のフェールバックを監視する（ステップ６３６）。エンドポイントは、ディスカバリ・モジュール１１６が、プライマリなコントローラ１４０が利用可能で、活性コントローラとして再開したことを検出した時に、フェールバックが行われたと決定する。この内部エンドポイントロジックは、ハートビート／ＳＩＰ ＲＥＧＩＳＴＥＲメッセージで支配される。このメッセージは、全てのコントローラ１４０に周期的に送信され、このコントローラ１４０にエンドポイントが登録される。これは、コントローラ１４０がある時点で活性状態にあるか否かに無関係に、行われる。

エンドポイントが、それ自身のフェールバックを検出しない場合（ステップ６３６）、この方法は、それが別の構成要素により、フェールバックが通知されたか否かを決定するエンドポイントで継続する（例、ＮＯＴＩＦＹメッセージを、ゲートウエイ１４８，サーバ１３６等から受信することにより）（ステップ６４０）。エンドポイントにフェールバックが通知されない場合には、この方法はステップ６３２に戻る。エンドポイントがフェールバックを示すＮＯＴＩＦＹメッセージを受領した場合には、この方法は、ＮＯＴＩＦＹメッセージがエンドポイントの実行用の指示を含むか否かを決定する事により、継続する（ステップ６４４）。インストラクションがＮＯＴＩＦＹメッセージに含まれる場合には、インストラクションはエンドポイントで実行される（ステップ６４８）。インストラクションを実行した後（ステップ６４８）、インストラクションが無い場合（ステップ６４４）、或いはフェールバックがエンドポイント自体自身により検出された場合（ステップ６３６）、エンドポイントは、ステップ６３４で最後に登録されたコントローラ１４０の登録を外される。これにより、動作可能なコントローラ１４０の数Ｎを保持する（ステップ６５０）。登録を外す動作により、ＳＩＰ ｕｎ−ｒｅｇｉｓｔｅｒとネットワークの取り外しアルゴリズムの両方を起動する。このアルゴリズムは、ＳＩＰ イベントパッケージと可能ならば他のノン−ＳＩＰ（アウトオブバンドの）データインターラクションの加入外しを含む。その後この方法は、ステップ６０４に戻る。

ディスカバリ・モジュール１１６は、構築可能なパラメータを含む。このパラメータは、プライマリ・コントローラ１４０から第２のコントローラ１４０へのフェールオーバ又はフェールバックが、自動化されたエンドポイント検出によりトリガされるか、或いは手動（即ち、ＳＩＰ ＮＯＴＩＦＹメッセージを受領することにより）でトリガーされるかを支配する。ディスカバリ・モジュール１１６のより採用されるハートビート（同期）モニタリングメカニズムは、様々なインターバルで実行されるが、このインターバルは、エンドポイントが故障状態を検出するか否かに依存する。

図７を参照して状態通知方法を説明する。この方法は、通信システム１００のコンポーネント（サーバ１３６、ゲートウエイ１４８，ディスカバリ・モジュール１４４を含む他のデバイス）が、エンドポイント（例、ＵＳ１０８）に通信システム１００に関して通知をするか否かを決定することで、開始する。通常構成要素は、ＮＯＴＩＦＹメッセージをエンドポイントに送り、エンドポイントに通信システム１００の状態のある態様が変化したことを通知する。例えばＮＯＴＩＦＹメッセージは、エンドポイントに対し、システム内の構成要素はアウトオブサービスとして登録されたことを通知する。別の構成として、ＮＯＴＩＦＹメッセージは、エンドポイントに対し送信中の構成要素の健全状態を通知する。

この方法は、ステップ７０４に、それが通知メッセージがエンドポイントに送信されなければならないと決定されるまで、留まる。このような決定がなされた後、本発明の方法は、メッセージ（ＮＯＴＩＦＹメッセージ）を生成する構成要素で継続する（ステップ７０８）。当業者に明らかなように、あらゆる種類のＳＩＰ又は非ＳＩＰのメッセージは、エンドポイントに通知するために、構成要素により採用される。この通知により、構成要素は、エンドバックに対し、通信システム１００の故障又は再生状態に、フェールオーバ又はフェールバックさせるよう起動する。エンドポイントは、コントローラ・リスト１２８を保持しているので、またエンドポイントは、これ等のコントローラの全てで活性状態、活性登録を保持することができるので、通信システム１００の構成要素は、エンドポイントに対し、それが通信システム１００の故障状態を検出した時、動作を執るよう指示する。このアクションは、標準の通知メッセージ（例；標準のＳＩＰ ＩＥＴＦ適合のＮＯＴＩＦＹメッセージ）又は特定のインストラクションセットを含む拡張メッセージを通知する事により、開始する。それに応じて、本発明の方法は、通知メッセージがその中にインストラクションを含むか否かを決定する構成要素で継続する（ステップ７１２）。

特定のインストラクションが必要であると決定されない時には、構成要素は、エンドポイントに対しコントローラ・リスト１２８内のＮ個のコントローラ１４０に再登録するよう伝え、一般的な通知メッセージをエンドポイントに送る（ステップ７２０）。かくして、このような通知を受け取ったどのエンドポイントも、リスト上のＮ個のコントローラ１４０に再登録しようとする。この再登録の成功に基づいて、エンドポイントは、どのコントローラ１４０がＳＩＰトランザクション（例；インバウンドとアウトバウンドのＳＩＰの呼びをサポートする）を処理できるかを抽出（決定）する。その後、エンドポイントは、この事故決定情報に従って、コントローラのリスト１２０内の最も高い優先度のコントローラ１４０をそのプライマリのコントローラとして用いて、行動する。この特定のアルゴリズムは、標準のＳＩＰ ＩＥＦＴに適合したＮＯＴＩＦＹメッセージを利用する。このメッセージは、ＮＯＴＩＦＹパラメータ「ｅｖｅｎｔ」＝「ｐｒｏｂａｔｉｏｎ」でＮＯＴＩＦＹメッセージ用のＳＩＰ標準に従う。このようなＮＯＴＩＦＹメッセージの一例を次に示す。

<registration aor="sip:joe@example.com"id="a7"state="active">
<contact id="76"state="active"event="probation"
expirs="0"
q="0.8"retry=after="0">

構成要素が、特定のインストラクションは通知メッセージに含まれるべきであると決定した場合には、構成要素は、１つ或いは複数のインストラクションセットをメッセ−ジに追加し（ステップ７１６）、その後、メッセージをエンドポイントに送信する（ステップ７２０）。インストラクションを通知メッセージ内に組み込むことにより、構成要素は、エンドポイントに対し、コントローラ１４０のコントローラのリスト１２０上の特定のコントローラ１４０を用いて、開始するよう告げる。このようなシナリオにおいては、エンドポイントは、どのコントローラ１４０を使用すべきかを、それに告げる構成要素に依存するが、それ自身のインテリジェンス（情報）には依存しない。この特定のメカニズムは拡張されたエクステンションの標準のＳＩＰ ＮＯＴＩＦＹメッセージを用いる。ＮＯＴＩＦＹメッセージは、ＮＯＴＩＦＹメッセージ用のＳＩＰ標準に従う。更に事象名目（例、<eventName>changeServer</eventname>）の代表的なプロファイル・イベント・パッケージフォーマットを使用する。これは、エンドポイントがフェールオーバ或いはフェールバックする場合である。このメッセージは、特定のコントローラ１４０を含むサーバ１３６のタイムスタンプとアドレスを含む。この特定のコントローラ１４０にエンドポイントはフェールオーバ又はフェールバックをする。このような拡張したＳＩＰ ＮＯＴＩＦＹメッセージの一例は、以下のＸＭＬインストラクションセットで、次に示す。

NOTIFY sip:1111@10.0.75.2 SIP/2.0
Call-ID:cid-1@10.0.75.2
CSeq:2NOTIFY
From:<sip:1111@atler.com.;tag=random2
To:<sip:1111@atler.com.;tag=random1
Via:SIP/2.0/UDP 10.0.0.100;branch-id=z9hG4bK-random- the primary call
controller
SIP/2.0/TLS 10.0.0.200;branch-id=z9hG4bK-random-cm1
Content-Length:22
Content-Type:application/profile+xml
Contact:<sip1111@10.0.0.200;transport=tls/
Max-Forwards:69
User-Agent:Communication Manager v1.0
Event:ccs-profile
Subscription-State:active;expires=3600
Record-Route:<sip:10.0.0.100:5060;lr;transport=UDP>

<?xml version="1.0">
<event>
<eventName.changeServer</eventName>
<eventTime>{time stamp}</eventTime>
<eventData>{ip adress}</eventData>
</event>

当業者にも明らかなように、インストラクションは、ＸＭＬインストラクションセット以外の様々な形態をとりうる。例えば、インストラクションは、所定のトリガーを含む。このトリガーは、エンドポイントのメモリ１１２内に既に記憶されたアルゴリズム又はアプリケーションに対応する或いは実行する。さらにＮＯＴＩＦＹメッセージは、メッセージ本体内にインストラクションセットを含む。このインストラクションセットは、通知メッセージのヘッダー或いはトレイラーに配置される。これは採用される通知メッセージの種類に依存する。このインストラクションを用いて様々な動作を実行する。例えば送信側の構成要素の健全状態と通信システム１００の残りの構成要素の状態情報及び特定のタスクを実行するために実行するようエンドポイントにエンドポイントを介させるものである。

上記のフローチャートは特定の事象のシーケンスについて理論したものであるが、このシーケンスに対する変更は本発明の動作に影響を及ぼすことなく可能である。更に事象の正確なシーケンスはこの実施例の中には必ずしも述べていない。ここに開示した代表的な技術は特定の実施例のみに関わるものではなく、他の実施例でも用いることができ、ここに開示した特徴はクレイムに記載されている。

本発明のシステムと方法とプロトコールは特殊目的の特殊なコンピュータ上、更には上記の通信装置、プログラムを内蔵したマイクロプロセッサー、マイクロコントローラ、周辺集積回路、ＡＳＩＣ或いは他の集積回路、ＤＳＰ、有線電子機器、ロジック回路、ディスクリート回路、プログラム可能な論理回路、例えばＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬ、通信装置、例えばサーバ、パソコン、或いは他のそれの交換手段等で実現される。一般的に状態機械を実現できるあらゆるデバイスを用いて本発明の様々な通信方法、プロトコール、技術を実現できる。

更にここに開示された方法は、サブルーチンソフトウエア或いはオブジェクト指向のソフトウエア環境を用いたソフトウエアで実現できる。これは様々なコンピュータ或いはワークステーションプラットホームで使用されるポータブルなソースコードを提供する。別の構成としてここに開示されたシステムは、一部或いは全部を、標準の論理回路ＶＬＳＩ設計を用いたハードウエアで実現できる。本発明のシステムを実行するのにソフトウエアを用いるかハードウエアを用いるかは、システムの速度と効率の要件、特定の機能、特定のソフトウエア又はハードウエアシステム、マイクロプロセッサー、マイクロコンピュータ等に依存する。解析システムと工法とプロトコールは、ハードウエア又はソフトウエアで実現できる。当業者

更にここに開示された方法は、記憶媒体に記憶され汎用コンピュータ上で実行されるソフトウエアで実現できる。但しコントローラとメモリー或いは、特殊目的のコンピュータ、マイクロプロセッサーを使用してもよい。この実施例においては、本発明のシステムと方法は、アプレット、ＪＡＶＡ（登録商標）R、、ＣＧＩスクリプトのようなパソコン上に記憶されたプログラムとして、或いはサーバ、コンピュータワークステーション上にあるリソースとして、或いは専用の通信システム、システム構成要素に記憶ルーチンで実現できる。本発明のシステムは、システムと方法をソフトウエア又はハードウエアシステムに組み込むことにより実現できる。

以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。

１００ 通信システム
１０４ 第１ネットワーク
１０８ ユーザ・エージェント（ＵＡ）
１１２ メモリ
１１６ ディスカバリ・モジュール
１２０ コントローラのリスト
１２４ プロセッサ
１２８ コントローラ
１３２ 属性
１３６ サーバ
１４０ コントローラ
１４０ａ 第１コントローラ
１４０ｂ 第２コントローラ
１４４ ディスカバリ・モジュール
１４８ ゲートウエイ
１５２ 第２ネットワーク
１５６ エンドポイント
図２
ステップ
２０４ エンドポイントがディスカバリーメッセージを送る
２０８ ディスカバリメッセージに対する応答を受領する
２１２ コントローラの属性に基づいてコントローラの順番を調整する
２１４ 登録すべきコントローラの数Ｎを選択する
２１６ 登録すべきＮ個のコントローラを選択する
２２０ 選択されたコントローラを登録する
２２４ 終了
図３
３０４ ゲートウエイがＳＩＰ ＯＰＴＩＯＮメッセージを送信する
３０８ 応答を待つ
３１２ 応答を受領したか？
３１６ 応答は故障条件／状態に対応しているか？
３２０ 応答内にインストラクションがあるか？
３２４ インストラクションを実行する
３２８ ネットワークの状態を更新してサーバの動作を反映する
３３２ 新たなメッセージを送信する時間か？
３３６ ネットワークの状態を更新して故障を反映する
３４０ ネットワークの反応性監視を開始する
３４４ メンテナンス・テストを開始する
３４８ ネットワークの状態は変わったか？
図４
４０４ ゲートウエイがリクエストをサーバから受領する
４０８ リクエストを通常の方法で処理する
４１２ サーバを「アウトオブサービス」としてマークされたか？
４１６ メンテナンステストを開始する
４２０ ネットワークの状態を更新する
４２４ 終了
図５
５０４ ゲートウエイがサバイバルしたエンドポイント用の来入呼びを受領する
５０８ 第１のシグナリングパスは利用可能か？
５１２ 信号を第１パスを介して送信する
５１６ 信号を第２パスを介して送る
５２０ エンドポイントから受領した応答を再度方向付けるか？
５２４ 信号を第１パスを介して送信する
５２８ 第１のシグナリングパスは利用可能か？
５３２ 呼びをリジェクトする
５３６ 終了
図６
６０４ エンドポイントを通常の状態で動作させる
６０８ ネットワークの故障を検出したか？
６１２ ネットワークの故障を通知したか？
６１６ 故障通知は正しいか？
６２０ 再度方向付けたメッセージで応答する
６２４ 通知はインストラクションを含むか？
６２８ インストラクションを実行する
６３０ リスト内の次のコントローラを登録する
６３２ エンドポイントをバックアップ状態で動作させる
６３６ ネットワークのフェールバックを検出したか？
６４０ ネットワークのフェールバックを通知したか？
６４４ 通知はインストラクションを含むか？
６４８ インストラクションを実行する
６５０ リスト上の最後に登録されたコントローラの登録を外す
図７
７０４ ＮＯＴＩＦＹメッセージをエンドポイントに送信したか？
７０８ ＮＯＴＩＦＹメッセージを生成する
７１２ ＮＯＴＩＦＹメッセージ内にインストラクションが含まれるか？
７１６ インストラクションをメッセージに追加する
７２０ メッセージをエンドポイントに送信する

Claims (9)

1. （Ｘ）クライアントが、複数のサーバのリストを創設するステップと、
   （Ｙ）前記クライアントが、前記複数のサーバの全サーバ数より少ない数の登録すべき複数のサーバからなる小サーバグループを決定するステップと、
   （Ａ）前記クライアントが、自身を前記小サーバグループ内の複数のサーバに登録するステップと、
   （Ｂ）クライアントが、前記小サーバグループ内の少なくとも１つのサーバからサービスを得るステップと、
   （Ｃ１）前記小サーバグループ内の第１サーバがクライアントにとって利用不可能になったことに応答して、前記クライアントが、登録すべきサーバからなる第２小サーバグループを決定するステップと、
   （Ｃ２）前記クライアントが、第１サーバがクライアントにとって利用不可能になったことに応答して、自身を前記第２小サーバグループのサーバに追加登録するステップと、
   を有し、
   少なくとも前記第２小サーバグループの一部の第２サーバは前記小サーバグループに含まれており、
   これにより、前記第２サーバは前記小サーバグループのサーバに追加される
   ことを特徴とする方法。
2. 前記の利用不可能であった第１サーバが、前記クライアントにとって再び利用可能となったことに応答して、
   （Ｄ）前記クライアントは、自身を前記第２サーバの登録から抹消するステップ
   これにより、前記第２サーバを前記第２小サーバグループから外す
   を更に有する
   ことを特徴とする請求項１記載の方法。
3. 前記の利用不可能であった第１サーバが、前記クライアントにとって再び利用可能となったことに応答して、
   （Ｅ）前記クライアントは、自身を前記第１サーバに再登録するステップを更に有し、
   これにより、前記第１サーバを前記第２小サーバグループに追加する
   ことを特徴とする請求項２記載の方法。
4. 前記複数のサーバの内のサーバは、順番に並んでおり、
   前記（Ａ）ステップは、
   （Ａ１）前記クライアントが、前記クライアントに利用可能な順番の最初のＮ（整数）個のサーバに登録するステップ
   を含み、
   前記（Ｃ１）ステップは、
   （Ｃ１１）前記クライアントが、前記クライアントに利用可能な順番の（Ｎ＋１）番目のサーバに登録するステップ
   を含む
   ことを特徴とする請求項１記載の方法
5. 前記サーバへの登録は、アクティブーアクティブの構成、又はアクティブースタンバイの構成のいずれかを有すことを特徴とする請求項１記載の方法。
6. （Ａ）複数のサーバと、
   前記複数のサーバの各サーバは、コントローラを有し、少なくとも１つのサーバは、プロセッサとメモリとを有し、
   （Ｂ）前記複数のサーバの全サーバ数より少ない数の登録すべき全てのサーバからなる小サーバグループサーバに登録されるクライアントと、
   を有し、
   前記小サーバグループのサーバの内の少なくとも１つのサーバからサービスを得る為に、前記クライアントは、
   前記小サーバグループのサーバの内の少なくとも１つのサーバが利用不可能であると決定し、
   前記小サーバグループのサーバの内の少なくとも１つのサーバがクライアントにとって利用不可能になったことに応答して、登録すべきサーバからなる第２小サーバグループを決定し、
   少なくとも前記第２小サーバグループの一部の第２サーバは前記小サーバグループに含まれており、
   自身を、第１サーバがクライアントにとって利用不可能になったことに応答して、前記第２小サーバグループの複数のサーバに追加登録する
   ことを特徴とする装置。
7. 前記の利用不可能であった第２サーバが、クライアントにとって再び利用可能となったことに応答して、
   前記クライアントは、前記第１サーバの登録を抹消し、前記第１サーバを前記第２小サーバグループから外す
   ことを特徴とする請求項６記載の装置。
8. 前記サーバへの登録は、アクティブーアクティブの構成、又はアクティブースタンバイの構成のいずれかを有すことを特徴とする請求項６記載の装置。
9. 前記複数のサーバの内のサーバは、順番に並んでおり、
   前記小サーバグループのサーバが、前記クライアントに利用可能な順番の最初のＮ（整数）個のサーバを有し、
   前記第１サーバは、前記クライアントに利用可能な順番の（Ｎ＋１）番目のサーバとなる
   ことを特徴とする請求項６記載の装置。
   

Images