JP5865404B2

JP5865404B2 - Ｓｉｐを用いた企業ネットワークの生存性のためのゲートウェイ

Info

Publication number: JP5865404B2
Application number: JP2014025081A
Authority: JP
Inventors: セバスチャン・ブリュネル; ロラン・バルベロ
Original assignee: アルカテル−ルーセント
Priority date: 2011-03-15
Filing date: 2014-02-13
Publication date: 2016-02-17
Anticipated expiration: 2032-01-24
Also published as: KR101458336B1; WO2012123151A1; CN103430524B; EP2501120A1; CN103634490A; JP2014150535A; JP5636516B2; JP2014511072A; CN103634490B; KR20130121183A; US9477561B2; US9201743B2; EP2501120B1; EP2501119A1; KR101431413B1; US20130346789A1; KR20130112957A; CN103430524A; US20140012996A1; EP2501119B1

Description

本発明は、企業通信ネットワークに関する。企業通信ネットワークはしばしば複数のサイトに広がる端末にリンクされ、今日ではインターネットプロトコル（ＩＰ）およびセッション開始プロトコル（ＳＩＰ）を用いる。音声サンプル、データパケット、およびシグナリングメッセージは、公衆電話交換網（ＰＳＴＮ）とは独立のＩＰネットワークによって運ばれるが、企業ネットワークは企業の外側の世界と通信するためにゲートウェイによってＰＳＴＮにもリンクされる。

各ＳＩＰ端末はＳＩＰユーザエージェントを稼働させる。すべてのＳＩＰユーザエージェントは、電話通信をセットアップするためにレジストラサーバ、リダイレクトサーバ、プロキシサーバ、および場合によってはプレゼンスサーバとして働く少なくとも１つのＳＩＰサーバを備えるＩＰネットワークを通して相互接続され、また数多くの電話サービスをもたらす。例えば、メッセージ待機表示、プレゼンス状態表示、コンファレンスメンバシップ通知、コール統計、メッセージングなどである。一般に企業ネットワークは、企業の主サイトにある単一のＳＩＰサーバを備え、遠隔サイトの端末は、ＩＰネットワークを通じて主サイトのＳＩＰサーバと通信する。

このＩＰネットワークが故障した場合は、遠隔サイトでは、主サイト内のＳＩＰサーバによってそれまで提供されていたサービスの一部またはすべてがもはや利用できなくなる。

いくつかの解決策が知られている：
− コールはＰＳＴＮに経路再設定することができるが、このやり方では帯域外のサービス情報を伝えることはできない。
− 一部のローカルプロキシサーバは、主サイトのＳＩＰサーバとのリンクが失われた場合に特定のサービスを提供することができるが、ＩＰネットワークがダウンしている間はそれと何ら情報を交換せず、したがって遠隔サイトでは、主サイトのＳＩＰサーバにおいてホストされるすべてのサービスがもはや利用できない。
− 完全にバックアップされたインフラストラクチャを用いた、ＰＳＴＮを通じたグローバルＩＰルーティング。配備のコストおよび必要な帯域幅のコストは非常に高くなる。

米国特許第７，６１３，１７０号明細書米国特許出願公開第２００７／０４，７５１号明細書

本発明の目的は、主サイトのＳＩＰサーバへのＩＰリンクがダウンしたときに、適切なコストで遠隔サイト上に位置するＳＩＰ端末へ主サイトのＳＩＰサーバによって提供されるこれらの電話サービスの少なくとも一部を、遠隔サイト上に位置するＳＩＰ端末にもたらすことである。

本発明の目的は、セッション開始プロトコルを用いた企業ネットワークの生存性のためのゲートウェイである。このゲートウェイはバックアップサーバと協働して、バックアップリンクを確立し、バックアップリンクおよび同様なゲートウェイを通じてメインＳＩＰサーバとＳＩＰメッセージを交換する。ゲートウェイは、
構成パラメータを記憶するための管理および構成モジュールと、
ゲートウェイを公衆ネットワークのトランクに接続するためのトランクインターフェースモジュールと、
企業ネットワークに接続されたメディアサーバモジュールと、
企業ネットワーク内で用いられるメディアおよび／またはプロトコルを、前記トランクで用いられるメディアおよび／またはプロトコルに、および相互に変換するためのトランスコーダモジュールと、
コールする側の端末によって用いられるシグナル伝達のタイプに従ってコールを管理し、メディアサーバモジュール、トランスコーダモジュール、およびトランクインターフェースモジュールを駆動するためのコール制御モジュールと
を備える。
ゲートウェイは、
バックアップリンクに送られるＳＩＰパケットのサイズを低減するように、構成パラメータに従って圧縮を適用するためのデータ圧縮手段と、
プロキシモジュールであって、
ＳＩＰＲｅｑｕｅｓｔ−ＵＲＩメッセージに含まれたＩＰアドレスに従って、ゲートウェイによって受け取られた各ＳＩＰメッセージを転送する手段であって、このＩＰアドレスがゲートウェイのアドレスである場合はＳＩＰメッセージがコール制御モジュールに送られ、ＩＰアドレスがメインＳＩＰサーバのアドレスである場合はＳＩＰメッセージがデータ圧縮モジュールに送られる手段、
ＩＰアドレスがメインＳＩＰサーバのアドレスである場合は、プロキシモジュールのＩＰアドレスを、各ＳＩＰＲｅｇｉｓｔｅｒメソッド上のＰａｔｈヘッダ内に追加する手段、および
メインＳＩＰサーバに送られる他のそれぞれのＳＩＰメソッドに対しては、Ｒｏｕｔｅヘッダ内のプロキシモジュールのＩＰアドレスをＲｏｕｔｅヘッダにおいて抑制する手段
を含む、プロキシモジュールと
をさらに備えること、ならびに、
管理および構成モジュールが、
データ圧縮フラグを受け取って記憶する手段、および
バックアップリンクを確立するために用いられるレスキューコール番号を受け取って記憶する手段
を備え、
コール制御モジュールが、コールがバックアップリンクを確立するためのレスキューコールであるか通常のコールであるかのコールの性質に応じて、メディアサーバモジュールおよびトランスコーダモジュールにおけるリソースを開始および終了する手段を備えること
を特徴とする。

本発明の他の特徴および利点は、以下の本発明の実施形態の詳細な説明を添付の図面と併せ読めば、より明らかになるであろう。

本発明の実施形態の詳しい特徴および利点を示すために、以下の説明では添付の図面を参照する。図面の図および説明の全体にわたって、可能な場合は同じまたは同様な参照番号は同じまたは同様な構成要素を指す。

本発明による２つのＳＩＰゲートウェイを備える、主サイトおよび遠隔サイト上の例示の企業通信ネットワークを示すブロック図である。端末をメインＳＩＰサーバ内に登録するための、遠隔サイトにある端末のＳＩＰユーザエージェントから、主サイトにあるメインＳＩＰサーバへのＲＥＧＩＳＴＥＲメッセージの送信を示す図である。メッセージ待機表示に対してサブスクライブするための、遠隔サイトにある端末のＳＩＰユーザエージェントから、主サイトにあるメインＳＩＰサーバへのＳＵＢＳＣＲＩＢＥメッセージの送信を示す図である。メッセージが待機していることを端末に通知するための、主サイトにあるメインＳＩＰサーバから、遠隔サイトにある端末のＳＩＰユーザエージェントへのＮＯＴＩＦＹメッセージの送信を示す図である。コール統計パブリケーションをサブスクライブするための、主サイトにあるメインＳＩＰサーバから、遠隔サイトにある端末のＳＩＰユーザエージェントへのＳＵＢＳＣＲＩＢＥメッセージの送信を示す図である。遠隔サイトにある端末のＳＩＰユーザエージェントから、主サイトにあるメインＳＩＰサーバへの、コール統計を後者に通知するためのＰＵＢＬＩＳＨメッセージの送信を示す図である。バックアップＳＩＰサーバの一実施形態を示すブロック図である。この実施形態におけるリンクモニタマネージャによって行われる動作を示す図である。この実施形態におけるリンクモニタマネージャによって行われる動作の１つをより詳細に示す図である。この実施形態における転送登録マネージャの動作をより詳細に示す図である。この実施形態におけるポリシーマネージャの動作をより詳細に示す図である。バックアップＳＩＰサーバの一実施形態と協働するときの、従来型ＳＩＰ端末の動作を示す図である。本発明によるゲートウェイの一実施形態を示すブロック図である。本発明によるゲートウェイのこの実施形態によって行われる動作を示す図である。本発明によるゲートウェイのこの実施形態によって行われる他の動作を示す図である。本発明によるゲートウェイのこの実施形態によって行われる他の動作を示す図である。

図１に表される例示の企業ネットワークは、主サイト上に以下を備え：
− Ｔ２などのＳＩＰ端末
− Ｔ４などの時分割多重化（ＴＤＭ）端末
− メインＳＩＰサーバＭＳＳ
− ルータＲ２
− 本発明によるＳＩＰゲートウェイＳＩＰＧＷ２
遠隔サイト上に以下を備える：
− Ｔ１などのＳＩＰ端末
− Ｔ３などの時分割多重化（ＴＤＭ）端末
− バックアップＳＩＰサーバＢＳＳ
− ルータＲ１
− 本発明によるＳＩＰゲートウェイＳＩＰＧＷ１

主サイトのすべてのネットワーク要素は、ゲートウェイＳＩＰＧＷ２にリンクされたＴＤＭ端末を除いて、ローカルエリアネットワークＬＡＮ２にリンクされる。遠隔サイトのすべてのネットワーク要素は、ゲートウェイＳＩＰＧＷ１にリンクされたＴＤＭ端末を除いて、ローカルエリアネットワークＬＡＮ１にリンクされる。

ルータＲ１およびＲ２は、ＩＰネットワークＷＡＮを通してＩＰリンクＩＰＬによってリンクされる。ＳＩＰゲートウェイＳＩＰＧＷ１およびＳＩＰＧＷ２は、アナログまたはデジタルの場合がある公衆交換電話網ＰＳＴＮによってリンクされる。他の実施形態では、これは公衆携帯電話網によって置き換えることができる。

ＳＩＰゲートウェイＳＩＰＧＷ１およびＳＩＰＧＷ２は、ＴＤＭ端末とＩＰまたは企業ネットワークのＴＤＭ端末の間のコールのため、および企業ネットワークの端末とネットワークＰＳＴＮの端末の間のコールのために用いられる。さらにそれらは、ＩＰネットワークＷＡＮを通したＩＰリンクＩＰＬが機能しないときに、公衆網ＰＳＴＮを通じてＳＩＰシグナリングメッセージを交換するために用いられる。

通常モード：
ＩＰネットワークＷＡＮが機能しているときは、バックアップＳＩＰサーバＢＳＳはスタンバイにある。これはＩＰリンクＩＰＬが機能していることを周期的にチェックする。メインＳＩＰサーバＭＳＳは、両方のサイトのすべての端末のユーザのために、両方のサイトのすべての端末へのまたはそれらからのコールをセットアップするために、レジストラサーバ、リダイレクトサーバ、およびプロキシサーバとして働く。例えばＳＩＰ端末Ｔ１が、端末Ｔ２、Ｔ３、またはＴ４の１つとのセッションをセットアップするときは、ＳＩＰ端末Ｔ１はＳＩＰシグナリングメッセージを送り、これはローカルエリアネットワークＬＡＮ１、ルータＲ１、ＩＰネットワークＷＡＮ、ルータＲ２、およびローカルエリアネットワークＬＡＮ２を通じてメインＳＩＰサーバＭＳＳに転送される。次いでメインＳＩＰサーバＭＳＳは、ローカルエリアネットワークＬＡＮ２を通じてメッセージを宛先端末に転送する。

バックアップモード：
ネットワークＷＡＮを通したＳＩＰシグナリングリンクＩＰＬが機能していないときは、バックアップＳＩＰサーバＢＳＳ、または遠隔サイトのＳＩＰ端末の１つ例えばＴ１は、リンクＩＰＬの故障を検出する。次いでバックアップＳＩＰサーバＢＳＳは、公衆交換電話網ＰＳＴＮ（これは、公衆交換電話網ＰＳＴＮの構成によりアナログまたはデジタルトランクの場合がある）を通した、バックアップＳＩＰシグナリングリンクＢＬのセットアップを命令する。他の実施形態ではバックアップリンクＢＬは、携帯電話網例えば第３世代携帯電話網を通じてセットアップすることができる。これはまたはＩＰリンクＩＰＬの遮断の場合に、より速やかな対応性のための恒久的なリンクとすることもできる。

バックアップＳＩＰサーバＢＳＳは完全にアクティブ化されて、遠隔サイトのすべての端末のユーザのための、レジストラサーバ、リダイレクトサーバ、およびプロキシサーバとして働く。したがってそれは遠隔サイトのすべての端末の登録を受け付ける。このローカル登録は、遠隔サイトの端末がそれらの間のローカルコールをセットアップすることを可能にする。

さらにバックアップＳＩＰサーバＢＳＳは、メインＳＩＰサーバＭＳＳを更新された状態に保つために、それらの登録要求をバックアップＳＩＰシグナリングリンクＢＬを通じてメインＳＩＰサーバＭＳＳに転送する。主サイトにおけるこの登録は、遠隔サイトの端末が、公衆交換電話網ＰＳＴＮを通じた主サイトの端末および他の任意の場所へのコールをセットアップすることを可能にする。

さらにバックアップＳＩＰシグナリングリンクは、メインＳＩＰサーバＭＳＳが、通常それが遠隔サイトの端末に提供するサービスの少なくとも一部を提供しつ続けることを可能にする。バックアップＳＩＰサーバＢＳＳは、バックアップＳＩＰシグナリングリンクＢＬ上に、様々な種類のＳＩＰシグナリング情報を転送することができる。しかしこれは、バックアップＳＩＰシグナリングリンクＢＬは公衆交換通信網ＰＳＴＮの１つまたはいくつかの音声チャネルによって運ばれるので、リアルタイムシグナリングまたは高帯域幅シグナリングとすることはできない。

本発明によればバックアップＳＩＰサーバＢＳＳは、メインＳＩＰサーバＭＳＳによって遠隔サイトの端末に通常提供されるサービスのサブセットのみを許可する。これはバックアップＳＩＰシグナリングリンクＢＬと適合性のあるシグナリング情報を必要とするサービスを許可する。サービスを許可するまたは禁止するために、バックアップＳＩＰサーバＢＳＳは、遠隔サイトの端末から主サイト上のメインＳＩＰサーバに送られたＳＩＰシグナリングメッセージを構文解析し、禁止されたサービスを提供するために必要な一部の情報を削除することによって、これらのＳＩＰメッセージのいくつかのフィールドの内容を変更する。

一方バックアップＳＩＰサーバＢＳＳは、以下のものなどの許可されたサービスのために必要なシグナリング情報を、バックアップＳＩＰシグナリングチャネルＢＬ上に伝達させる：
− ＳＩＰデバイス登録
− ローカルまたは遠隔ユーザからのサービスサブスクライビング、および関連する通知
− サービスメッセージング
− 関係データパブリケーション

これは、ローカルおよび外部コール、ローカルサービス、コンファレンスなどのためのルーティング機能などの、更なる能力をもつことができる。

例えば遠隔サイト上のＳＩＰ端末Ｔ１が、主サイト上の端末Ｔ２にアドレス指定されたＳＩＰメッセージを送るときは、このメッセージはバックアップＳＩＰサーバＢＳＳによって受け取られる。この後者は、いくつかのサービスのみを許可するために必要であれば、このメッセージのＡｌｌｏｗヘッダフィールドを変更し、関連するルートヘッダを挿入し、次いでゲートウェイＳＩＰＧＷ２と、公衆交換電話網ＰＳＴＮを通してバックアップシグナリングリンクＢＬと、ゲートウェイＳＩＰＧＷ１とを通じて、メッセージをメインＳＩＰサーバＭＳＳに転送する。次いでメインＳＩＰサーバＭＳＳは、メッセージを端末Ｔ２に転送する。

図２から図６は、様々なサービスに対するバックアップモードにおける、端末Ｔ１のＳＩＰユーザエージェントとメインＳＩＰサーバＭＳＳの間の異なる種類のＳＩＰシグナリングメッセージの送信、および対応する肯定応答の送信を示す。

図２は、バックアップモードにおいて、端末をメインＳＩＰサーバＭＳＳに登録するための、遠隔サイトにある端末Ｔ１のＳＩＰユーザエージェントから主サイトにあるメインＳＩＰサーバＭＳＳへの、ＲＥＧＩＳＴＥＲメッセージの送信を示す。この端末Ｔ１が、メインＳＩＰサーバとのＩＰリンクＩＰＬがもはや機能していないことを検出したときは、それはバックアップＳＩＰサーバＢＳＳに登録する。バックアップＳＩＰサーバＢＳＳは、公衆交換網ＰＳＴＮを通したバックアップＳＩＰシグナリングリンクＢＬセットアップを通じて、登録要求をメインＳＩＰサーバＭＳＳに伝達する。ＲＥＧＩＳＴＥＲメッセージにおいては、バックアップＳＩＰサーバＢＳＳは以下を行うことができる：
− 「Ｒｅｑｕｅｓｔ−ＵＲＩ」フィールドの内容を、メインＳＩＰサーバレジストラＵＲＩ（統一資源識別子）と一致するように書き換える。
− 「Ａｌｌｏｗ」ヘッダフィールド（これは、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳなどの、「ＳＩＰメソッド」のリストを含んでいる）の内容を変更する。
− その構成に従って対応するゲートウェイＵＲＩＳＩＰＧＷ１およびＳＩＰＧＷ２のルートヘッダを挿入する。

例えば：
ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍは、バックアップＳＩＰサーバＢＳＳのＵＲＩであり、
ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍは、メインＳＩＰサーバＭＳＳのＵＲＩであり、
ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍは、端末Ｔ１のＵＲＩであり、
ＳＩＰＵＡ＠ＩＰＳＩＰＵＡは、そのＩＰアドレスによって形成された端末Ｔ１のコンタクトＵＲＩである場合は、端末Ｔ１は、バックアップＳＩＰサーバＢＳＳにメッセージを送る：
Ｒｅｇｉｓｔｅｒ１：ｒｅｇｉｓｔｒａｒ．ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｃｏｎｔａｃｔ：ＳＩＰＵＡ＠ＩＰＳＩＰＵＡ
Ａｌｌｏｗ：ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳ、…
したがって端末Ｔ１はバックアップＳＩＰサーバＢＳＳに登録され、この後者はそれが、ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳなどのＳＩＰメソッドを許可することを示す。

次いでバックアップＳＩＰサーバＢＳＳは、ゲートウェイＳＩＰＧＷ１にメッセージを送る：
Ｒｅｇｉｓｔｅｒ２：ｒｅｇｉｓｔｒａｒ．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｃｏｎｔａｃｔ：ＳＩＰＵＡ＠ＩＰＳＩＰＵＡ
Ａｌｌｏｗ：ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳ、…。

メッセージＲｅｇｉｓｔｅｒ２では、「Ａｌｌｏｗ」フィールドは、端末Ｔ１によって許可されたもののいくつかのＳＩＰメソッド（ＩＮＶＩＴＥ、ＡＣＫなど）を抑制するために、バックアップＳＩＰサーバＢＳＳによって修正されている。抑制されたメソッドは、バックアップＳＩＰシグナリングリンクＢＬによってサポートすることができない、リアルタイムシグナリングまたは広帯域シグナリングを必要とするサービス（例えば、リアルタイムメディアセッションの確立、および転送などの付加されたサービスなど）に対応する。次いでバックアップＳＩＰサーバＢＳＳは、端末Ｔ１に肯定応答２００ｏｋを送る。

次いでゲートウェイＳＩＰＧＷ１は、バックアップＳＩＰシグナリングリンクＢＬを通じてゲートウェイＳＩＰＧＷ２にメッセージを送る：
Ｒｅｇｉｓｔｅｒ３：ｒｅｇｉｓｔｒａｒ．ＭａｉｎＳＩＰＡｐｐｌｉＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｃｏｎｔａｃｔ：ＳＩＰＵＡ＠ＩＰＳＩＰＵＡ
Ａｌｌｏｗ：ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳ、…
Ｐａｔｈ：ＳＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
メッセージＲｅｇｉｓｔｅｒ３ではＰａｔｈフィールドが、ＲＦＣ３３２７規格に準拠してバックアップＳＩＰサーバＢＳＳに向かう経路を示すために、ゲートウェイＳＩＰＧＷ１によって追加されている。

ゲートウェイＳＩＰＧＷ２は、メインＳＩＰサーバＭＳＳにメッセージを送る：
Ｒｅｇｉｓｔｅｒ４：ｒｅｇｉｓｔｒａｒ．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｃｏｎｔａｃｔ：ＳＩＰＵＡ＠ＩＰＳＩＰＵＡ
Ａｌｌｏｗ：ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳ、…
Ｐａｔｈ：ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ，ＳｌＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｐａｔｈフィールドは、ＲＦＣ３３２７規格に準拠してバックアップＳＩＰサーバＢＳＳに向かうフルパスを示すために、ゲートウェイＳＩＰＧＷ２によって完成されている。

次いでメインＳＩＰサーバＭＳＳは、ゲートウェイＳＩＰＧＷ２およびゲートウェイＳＩＰＧＷ１を通じて、肯定応答メッセージ「２００ｏｋ」をバックアップＳＩＰサーバＢＳＳに送る。

本発明によるバックアップＳＩＰサーバはまた、遠隔サイトからサービスをサブスクライブすることを可能にする。以下の例ではバックアップＳＩＰサーバＢＳＳは、必要なときにはＲｏｕｔｅヘッダを含む、関連するヘッダを変更することになる。

サービスの例：
（ａ）メッセージ待機表示（図３および４参照）：遠隔サイト上に位置する各ユーザは、メインＳＩＰサーバＭＳＳ内にある音声メールサービスを用いることができる。このサービスは、システムがどのモード（正常／バックアップ）にあっても、ユーザのメールボックスの状態についてユーザに通知する。この目的のために、端末の登録の後にバックアップＳＩＰサーバＢＳＳは、関連するサブスクライブ要求（メッセージ待機表示イベントパッケージ）をメインＳＩＰサーバＭＳＳに伝達する。ユーザの音声メールボックス状態に何らかの重要な変化があるとすぐに、関連する通知がメインＳＩＰサーバＭＳＳから送られ、対応するユーザに伝達される。アプリケーションまたは機器は、この通知を用いて、適当な方法（ポップアップウィンドウ、アイコン、点滅するＬＥＤ、トーンなど）によってユーザに知らせることができる。

（ｂ）リソースプレゼンス状態：遠隔サイトのＳＩＰデバイスは、グローバルリソース状態情報（遠隔ユーザプレゼンス状態、音声メールサービスなどのサービス利用可能性など）を表示することができる。この目的のためにＳＩＰユーザエージェントは、サブスクライブ要求（プレゼンスイベントパッケージ）をバックアップＳＩＰサーバＢＳＳに送る。この後者は、このような要求をメインＳＩＰサーバＭＳＳに転送し、対応するユーザエージェントへの後続する通知を処理する。

（ｃ）コンファレンスメンバシップ通知：ＳＩＰユーザエージェントは、メインＳＩＰサーバＭＳＳ内のコンファレンスサーバによってホストされるコンファレンスに参加することができ、バックアップＳＩＰサーバＢＳＳへのサブスクライブ要求（コンファレンスイベントパッケージ）を通して、すべての参加者のそれぞれのプレゼンス状態を要求することができ、バックアップＳＩＰサーバＢＳＳは、このような要求を転送し、後続する通知を処理することになる。

図３は、バックアップモードにおいて「メッセージ待機表示」と呼ばれるサービスにサブスクライブするための、遠隔サイトにある端末Ｔ１のＳＩＰユーザエージェントから主サイトにあるメインＳＩＰサーバＭＳＳへの、ＳＵＢＳＣＲＩＢＥメッセージの送信を示す。

端末Ｔ１は、バックアップＳＩＰサーバＢＳＳにメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ１：ＳＩＰＵＡ＠ｖｍａｉｌ．ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
ただし、ＳＩＰＵＡ＠ｖｍａｉｌ．ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍは、バックアップモードにおいて端末１に付加された音声メールサービスのＵＲＩであり、
ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍは、バックアップモードにおける端末１のＵＲＩである。

次いでバックアップＳＩＰサーバＢＳＳは、ゲートウェイＳＩＰＧＷ１にメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ２：ＳＩＰＵＡ＠ｖｍａｉｌ．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ，ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
メッセージＳｕｂｓｃｒｉｂｅ２では、メッセージをメインＳＩＰサーバＭＳＳにルーティングするために、ゲートウェイＳＩＰＧＷ１によってＲｏｕｔｅフィールドが追加されている。

次いでゲートウェイＳＩＰＧＷ１は、公衆交換電話網ＰＳＴＮを通じてゲートウェイＳＩＰＧＷ２にメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ３：ＳＩＰＵＡ＠ｖｍａｉｌ．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
メッセージＳｕｂｓｃｒｉｂｅ３では、Ｒｏｕｔｅヘッダフィールドは、ちょうど今横切ったＳＩＰゲートウェイＳＩＰＧＷ１のＵＲＩを抑制することにより、ゲートウェイＳＩＰＧＷ１によって変更されている。

次いでゲートウェイＳＩＰＧＷ２は、メインＳＩＰサーバＭＳＳにメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ４：ＳＩＰＵＡ＠ｖｍａｉｌ．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
メッセージＳｕｂｓｃｒｉｂｅ４では、Ｒｏｕｔｅフィールドは、ちょうど今横切ったＳＩＰゲートウェイＳＩＰＧＷ２のＵＲＩを抑制することにより、ゲートウェイＳＩＰＧＷ２によって変更されている。

次いでメインＳＩＰサーバＭＳＳは、ゲートウェイＳＩＰＧＷ２、公衆交換電話網ＰＳＴＮ、ゲートウェイＳＩＰＧＷ１、およびバックアップＳＩＰサーバＢＳＳを通じて、端末Ｔ１に肯定応答メッセージ「２００ｏｋ」を送る。

本発明によるバックアップＳＩＰサーバは、遠隔側からのパブリケーションおよび通知を可能にする。
（ａ）パブリケーション：（一例について図６を参照して以下に説明する）
− プレゼンス状態パブリケーション（ＲＦＣ３８５６およびＰＵＢＬＩＳＨメソッド）：
主サイトのデバイス（コンファレンスサーバ、メッセージングアプリケーション、ルーティングなど）は、遠隔サイトにあるユーザに対するプレゼンス状態情報が必要になり得る。これらのプレゼンスデータは、遠隔サイト内のユーザエージェントから、バックアップＳＩＰサーバＢＢＳおよびバックアップＳＩＰシグナリングリンクを通じて、メインＳＩＰサーバＭＳＳに関連付けられたプレゼンスエージェントに伝えられる。
− コール統計パブリケーション（ＰＵＢＬＩＳＨメソッド）：
主サイトのいくつかのデバイス（課金アプリケーション、コンファレンスサーバ、ルーティング、音声品質システム監視など）は、恒久的なコール統計情報を必要とする。これらのコール統計は、遠隔サイト内のユーザエージェントから、バックアップＳＩＰサーバＢＢＳおよびバックアップＳＩＰシグナリングリンクを通じて、メインＳＩＰサーバＭＳＳに関連付けられたコール統計エージェントに伝えられる。
（ｂ）通知：（一例について図４を参照して以下に説明する）
− コール統計通知：ＲＦＣ６０３５により、このようなケースにおいてサブスクライブ／通知機構を用いることもできる。
− コール終了通知：主サイト上に位置するユーザＡが遠隔サイト上に位置するユーザＢにコンタクトを試み、それがビジーであったときに、このユーザＡによってダイアログイベントパッケージ（ＲＦＣ４２３５）を用いた自動リダイアル機能を起動することができる。コール終了の通知は、ユーザＡに対して自動リダイアルを可能にするために、ユーザＢが連絡可能になったときにメインＳＩＰサーバＭＳＳに転送される。

図４は、バックアップモードにおける、主サイトにあるメインＳＩＰサーバＭＳＳから遠隔サイトにある端末Ｔ１のＳＩＰユーザエージェントへの、メッセージが待機していることを端末Ｔ１に通知するためのＮＯＴＩＦＹメッセージの送信を示す。

メインＳＩＰサーバＭＳＳは、ゲートウェイＳＩＰＧＷ２にメッセージを送る：
Ｎｏｔｉｆｙ１：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ，ＳＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
待機メッセージ：はい
メインＳＩＰサーバＭＳＳは、メッセージをバックアップＳＩＰサーバＢＳＳにルーティングするために、Ｒｏｕｔｅフィールドを追加する。

次いでゲートウェイＳＩＰＧＷ２は、公衆交換電話網ＰＳＴＮを通じてゲートウェイＳＩＰＧＷ１にメッセージを送る：
Ｎｏｔｉｆｙ２：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
待機メッセージ：はい
ゲートウェイＳＩＰＧＷ２は、ちょうど今横切ったＳＩＰゲートウェイＳＩＰＧＷ２のＵＲＩを抑制することによって、Ｎｏｔｉｆｙ２メッセージ内のＲｏｕｔｅフィールドを修正する。

次いでゲートウェイＳＩＰＧＷ１は、バックアップＳＩＰサーバＢＳＳにメッセージを送る
Ｎｏｔｉｆｙ３：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
待機メッセージ：はい
ゲートウェイＳＩＰＧＷ１は、ちょうど今横切ったＳＩＰゲートウェイＳＩＰＧＷ１のＵＲＩを抑制することによって、メッセージＮｏｔｉｆｙ３におけるＲｏｕｔｅフィールドを修正する。

次いでバックアップＳＩＰサーバＢＳＳは、端末Ｔ１にメッセージを送る
Ｎｏｔｉｆｙ４：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：メッセージサマリ
待機メッセージ：はい

次いで端末Ｔ１は、バックアップＳＩＰサーバＢＳＳ、ゲートウェイＳＩＰＧＷ１、公衆交換電話網ＰＳＴＮ、およびゲートウェイＳＩＰＧＷ２を通じて、メインＳＩＰサーバＭＳＳに肯定応答メッセージ「２００ｏｋ」を送る。

本発明によるバックアップＳＩＰサーバは、主サイトからのサブスクリプションを可能にする。
図５は、バックアップモードにおいて、コール統計パブリケーションにサブスクライブするための、主サイトにあるメインＳＩＰサーバＭＳＳから遠隔サイトにある端末Ｔ１のＳＩＰユーザエージェントへの、ＳＵＢＳＣＲＩＢＥメッセージの送信を示す。
メインＳＩＰサーバＭＳＳは、ゲートウェイＳＩＰＧＷ２にメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ１：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ｃａｌｌＳｔａｔ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ，
ＳＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ
メッセージＳｕｂｓｃｒｉｂｅ１ではメインＳＩＰサーバＭＳＳは、メッセージをバックアップＳＩＰサーバＢＳＳにルーティングするために、Ｒｏｕｔｅフィールドを追加する。

次いでゲートウェイＳＩＰＧＷ２は、公衆交換電話網ＰＳＴＮを通じてゲートウェイＳＩＰＧＷ１にメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ２：ＳＩＰＵＡ＠ＭａｉｎＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ｃａｌｌＳｔａｔ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ
ただし、ｃａｌｌＳｔａｔ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍは、コール統計パブリケーションサービスのＵＲＩである。

次いでゲートウェイＳＩＰＧＷ１は、バックアップＳＩＰサーバＢＳＳにメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ３：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ｃａｌｌＳｔａｔ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ

次いでバックアップＳＩＰサーバＢＳＳは、端末Ｔ１にメッセージを送る：
Ｓｕｂｓｃｒｉｂｅ４：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ｃａｌｌＳｔａｔ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ

次いで端末Ｔ１は、バックアップＳＩＰサーバＢＳＳ、ゲートウェイＳＩＰＧＷ１、公衆交換電話網ＰＳＴＮ、およびゲートウェイＳＩＰＧＷ２を通じてメインＳＩＰサーバＭＳＳに肯定応答メッセージ「２００ｏｋ」を送る。

本発明によるバックアップＳＩＰサーバは、遠隔側からのパブリケーションを可能にする。
図６は、バックアップモードにおける、遠隔サイトにある端末Ｔ１のＳＩＰユーザエージェントから主サイトにあるメインＳＩＰサーバＭＳＳへの、後者にコール統計を通知するためのＰＵＢＬＩＳＨメッセージの送信を示す。
端末Ｔ１は、バックアップＳＩＰサーバＢＳＳにメッセージを送る：
Ｐｕｂｌｉｓｈ１：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＢａｃｋｕｐＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ

次いでバックアップＳＩＰサーバＢＳＳは、ゲートウェイＳＩＰＧＷ１にメッセージを送る
Ｐｕｂｌｉｓｈ２：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＩＰＧＷ１．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ，
ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ
バックアップＳＩＰサーバＢＳＳは、メッセージをメインＳＩＰサーバＭＳＳにルーティングするためにＲｏｕｔｅフィールドを追加する。

次いでゲートウェイＳＩＰＧＷ１は、公衆交換電話網ＰＳＴＮを通じてゲートウェイＳＩＰＧＷ２にメッセージを送る：
Ｐｕｂｌｉｓｈ３：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｒｏｕｔｅ：ＳＩＰＧＷ２．ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ

次いでＳＩＰゲートウェイＳＩＰＧＷ２は、メインＳＩＰサーバＭＳＳにメッセージを送る：
Ｐｕｂｌｉｓｈ４：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｆｒｏｍ：ＳＩＰＵＡ＠ＭａｉｎＳＩＰＳｅｒｖｅｒ．ｃｏｍ
Ｅｖｅｎｔ：ｖｑ−ｒｔｃｐｘｒ

図７は、本発明によるバックアップＳＩＰサーバの一実施形態ＢＳＳを示すブロック図である。これは以下を備える：
− 管理および構成モジュールＭＭＣ
− 従来型ＳＩＰサーバＣＳＳ
− および本発明によるバックアップ動作を実行するためのバックアップアプリケーションサーバＢＡＳ

従来型ＳＩＰサーバＣＳＳは、レジストラモジュールＲＧＭおよびプロキシサーバＰＲＸを備える。バックアップアプリケーションサーバＢＡＳは以下を備える：
− レジストラモジュールＲＧＭに書き込まれる登録データを複製し、プロキシＰＲＸを通じてメインＳＩＰサーバＭＳＳに送る、転送登録マネージャＦＲＭ
− 端末によって送られているメッセージ内に示される「ＳＩＰメソッド」（ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＰＵＢＬＩＳＨ、ＯＰＴＩＯＮＳなど）をチェックし、メッセージをメインＳＩＰサーバＭＳＳに転送する前に、メッセージ内のこれらのメソッドのそれぞれを保持または削除する、ポリシーマネージャＰＯＭ
− およびＩＰネットワークＷＡＮによって運ばれるＩＰリンクＩＰＬを監視する、リンクモニタマネージャＬＭＭ。これはＩＰリンクＩＰＬの故障を検出した場合は、ローカル端末を登録するためにバックアップＳＩＰサーバＢＳＳのレジストラモジュールＲＧＭをイネーブルし、公衆交換電話網ＰＳＴＮを通じてバックアップＳＩＰシグナリングチャネルＢＬをセットアップする。サービスに関するシグナリング情報はメインＳＩＰサーバＭＳＳに転送され、音声に関するシグナリングはバックアップＳＩＰサーバＢＳＳによって扱われる。

ポリシーマネージャＰＯＭによって選択されるメソッドの例：
− ＩＮＶＩＴＥ
・非メディアセッション（ＣａｓｅＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダ＜＞ｓｄｐ：Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダに依存）：メディアタイプ記述と比較（ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ａｓｓｉｇｎｍｅｎｔｓ／ｍｅｄｉａ−ｔｙｐｅｓ）
・メディアセッション（Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ：ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ）：いいえ
・Ｃｏｎｔｅｎｔ−Ｔｙｐｅなし：いいえ（ＡｃｋにおいてＳＤＰと想定される、など）
− ＣＡＮＣＥＬ：
− ＢＹＥ：
− ＡＣＫ：
・非メディアセッションからの場合：はい
・それ以外：いいえ
− ＲＥＦＥＲ：いいえ
− ＲＥＧＩＳＴＥＲ：はい
− ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ：Ｅｖｅｎｔヘッダの内容に依存し、またＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ値にも依存し得る
・メッセージサマリ：はい（ｒｆｃ３８４２）
・ｖｑ−ｒｔｃｐｘｒ：はい（ｒｆｃ６０３５）
・プレゼンス：はい（ｒｆｃ３８５６）
・ｗｉｎｆｏ：はい（ｒｆｃ３８５７）
・ダイアログ：はい（ｒｆｃ４２３５）
・コンファレンス：はい（ｒｆｃ４５７５）
・他、（リストは網羅的ではない）
− ＭＥＳＳＡＧＥ：Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値（およびレート：トラフィックがより重要な場合はすべてのデータは送信されない場合がある）に依存する
− ＯＰＴＩＯＮＳ：はい
− ＩＮＦＯ：Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値およびレートに依存する
− ＰＵＢＬＩＳＨ：Ｅｖｅｎｔヘッダが受け付けられた場合（ｒｆｃ３９０３）

値およびバックアップシグナリングリンクの能力に応じて、メソッド、イベント、またはユーザにはある優先度を関連付けることができ（ＳＤＰｉｎｖｉｔｅは定められたユーザに対して、または定められた低い優先度で認可され得る）、転送は保証される場合もあり保証されない場合もある。

図８は、バックアップアプリケーションサーバＢＡＳ内のリンクモニタマネージャＬＭＭによって行われる動作を示す：
ステップ８１：初期化においては、バックアップＳＩＰサーバＢＳＳはスタンバイにあり、すなわちそのポートは閉じられる。
ステップ８２：リンクモニタマネージャＬＭＭは、ネットワークＷＡＮを通したＩＰリンクの可能なデフォルトを検出するために、ＩＰネットワークＷＡＮを通じてメインＳＩＰサーバＭＳＳに周期的にキープアライブメッセージを送る。
ステップ８３：次いでリンクモニタマネージャＬＭＭは、それがＩＰネットワークＷＡＮを通じてメインＳＩＰサーバＭＳＳから応答を受け取ったかどうかをチェックする。応答を受け取った場合は、バックアップＳＩＰサーバＢＳＳをスタンバイに保ち続ける（ステップ８１に戻る）。
ステップ８４：リンクモニタマネージャＬＭＭは、応答を受け取らなかった場合は、登録要求をメインＳＩＰサーバＭＳＳに転送するためにバックアップＳＩＰサーバＢＳＳをアクティブ化する。
ステップ８５：次いでリンクモニタマネージャＬＭＭは、ＩＰネットワークＷＡＮの回復を待つ：リンクモニタマネージャＬＭＭは、ＩＰネットワークＷＡＮを通じてメインＳＩＰサーバＭＳＳにキープアライブメッセージを周期的に送る。
ステップ８６：次いでリンクモニタマネージャＬＭＭは、それがＩＰネットワークＷＡＮを通じてメインＳＩＰサーバＭＳＳから応答を受け取ったかどうかをチェックする。応答を受け取らなかった場合は、バックアップＳＩＰサーバはアクティブのままとなる（ステップ８４に戻る）。
ステップ８７：リンクモニタマネージャＬＭＭがＩＰネットワークＷＡＮを通じてメインＳＩＰサーバＭＳＳから応答を受け取った場合、すなわちＩＰネットワークＷＡＮによって運ばれるＩＰリンクＩＰＬが再び機能している場合は、それがローカルに登録したＳＩＰユーザエージェントの登録を取り消し、次いでバックアップＳＩＰサーバＢＳＳをスタンバイ状態に戻す（ステップ８１に戻る）。

図９は、バックアップアプリケーションサーバＢＡＳ内のリンクモニタマネージャＬＭＭによって行われるステップ８４をより詳細に示す。リンクモニタマネージャＬＭＭは、応答を受け取らなかった場合は、バックアップＳＩＰサーバＢＳＳをアクティブ化する。
ステップ９１：リンクモニタマネージャＬＭＭは、登録を要求する遠隔サイトの端末のユーザの登録を受け付けるように、登録モジュールＲＧＭをアクティブ化する。
ステップ９２：次いでそれは、バックアップＳＩＰシグナリングリンクＢＬをセットアップするために、公衆網ＰＳＴＮを通じてゲートウェイＳＩＰＧＷ２へのコールをセットアップするように要求するために、ＳＩＰメッセージＩＮＶＩＴＥをゲートウェイＳＩＰＧＷ１に送る。
ステップ９３：ゲートウェイＳＩＰＧＷ１が否定的に応答した場合、または応答しない場合は、リンクモニタマネージャＬＭＭは再び試行する（ステップ９２に戻る）。
ステップ９４：ゲートウェイＳＩＰＧＷ１が肯定的に応答した場合は、この時点でバックアップＳＩＰシグナリングリンクＢＬは、公衆交換電話網ＰＳＴＮを通じて利用可能である。次いでリンクモニタマネージャＬＭＭは、ステップ８５に進む。

図１０は、転送登録マネージャＦＲＭの動作をより詳細に示す：
遠隔サイトにあるＳＩＰ端末のＳＩＰユーザエージェントが、プロキシＰＲＸを通じてＳＩＰ登録要求ＲＲＱ１を送ったときは、この要求は転送登録マネージャＦＲＭによってローカルに扱われる。バックアップＳＩＰサーバＢＳＳがアクティブ化された場合は：
− 転送登録マネージャＦＲＭは登録要求を、プロキシＰＲＸを通じてＳＩＰ登録要求メッセージＲＲＱ２をメインＳＩＰサーバＭＳＳに送ることによって転送する。次いでメインＳＩＰサーバＭＳＳは、それがユーザを登録した旨の肯定応答を行う。次いで転送登録マネージャＦＲＭは、レジストラモジュールＲＧＭの一部であるデータベースＤに、メインＳＩＰサーバＭＳＳがユーザを登録した旨の表示を記憶する。
− 転送登録マネージャＦＲＭは、レジストラモジュールＲＧＭの一部であるレジストラメモリＲＭにおいてローカル登録を許可し、登録要求ＲＲＱ１を送った端末に肯定応答メッセージＲＯＫ、２００ｏｋを送ることを許可する。

図１１は、ポリシーマネージャＰＯＭの動作をより詳細に示す：
プロキシＰＲＸを通過するすべての要求は、ポリシーマネージャＰＯＭによって扱われる。遠隔サイトにあるＳＩＰ端末のＳＩＰユーザエージェントが、プロキシＰＲＸを通じてＳＩＰ要求ＲＲＱ１を送ったときは、ポリシーマネージャＰＯＭは応答ＲＳをプロキシＰＲＸに供給し、これは所定の規則による以下の１つとすることができる：
− 修正せずに扱いを継続する（例えばローカルコール、または単なる公衆網ＰＳＴＮを通じた電話の呼び出しの場合）。
− 否定応答（例えば、利用可能な帯域幅が不十分なので公衆交換電話網ＰＳＴＮを通じたビデオコールを拒否する、または公衆交換電話網ＰＳＴＮがサポートできないリアルタイムシグナリングを必要とするサービスを拒否する）。
− 要求をその宛先に転送する（ヘッダ修正を有する）。
− アクションなし（例えば図２上で、バックアップＳＩＰサーバＢＳＳがメッセージ２００ｏｋを受け取ったときは、メッセージＲｅｇｉｓｔｅｒ１は前に端末Ｔ１にメッセージ２００ｏｋを送ることによってすでに肯定応答をされているので、アクションはない）。

従来型ＳＩＰ端末は、本発明によるバックアップＳＩＰサーバが企業ネットワーク内に設置されたときはこれらのＳＩＰ端末を修正せずに、用いることが可能である。

図１２は、遠隔サイトにある従来型ＳＩＰ端末Ｔ１について、それが本発明によるバックアップＳＩＰサーバの一実施形態と協働するときの動作を示す。この端末は、メインＳＩＰサーバのアドレスおよびバックアップＳＩＰサーバのアドレスを記憶する。
ステップ１２１：端末はその初期状態にある。一般にこの初期状態では、端末はその前にメインＳＩＰサーバ上に登録されている。
ステップ１２２：端末は、任意のＳＩＰサーバ上への登録を要求する、ＳＩＰメッセージＲＥＧＩＳＴＥＲを周期的に送る。
ステップ１２３：次いでそれは、メインＳＩＰサーバが応答することをチェックする。メインＳＩＰサーバが応答した場合は、端末はその初期状態のままとなり（ステップ１２１に戻る）、またはコールが継続している場合はコールの通常のステップを継続する。
ステップ１２２’：メインＳＩＰサーバとのＩＰリンクがもはや機能しない間は、端末のユーザは、２つの周期的自動チェックの間にコールを行うことを試みることができる。この試みは、メインＳＩＰサーバにアドレス指定されたＳＩＰメッセージＩＮＶＩＴＥの送出を引き起こす。
ステップ１２３’：次いで端末は、メインＳＩＰサーバが応答することをチェックする。メインＳＩＰサーバが応答する場合は、端末はコールの通常のステップを継続する。
ステップ１２４：メインＳＩＰサーバが応答しない場合は端末は、バックアップＳＩＰサーバ（例えば上述のバックアップＳＩＰサーバＢＳＳ）上に登録されるようにするために、ＳＩＰメッセージＲＥＧＩＳＴＥＲを送る。
ステップ１２５：次いでそれはＳＩＰサーバが応答するかどうかをチェックする。バックアップＳＩＰサーバが所定の時間間隔内に応答した場合は、端末はその初期状態に戻って（ステップ１２１に戻る）、メインＳＩＰサーバ上への登録を要求するＳＩＰメッセージＲＥＧＩＳＴＥＲを周期的に送り続ける。
ステップ１２６：端末を登録したことをバックアップＳＩＰサーバが応答した場合は、端末は、新しい状態「バックアップＳＩＰサーバ上に登録済み」に入る。これは、メインＳＩＰサーバによってホストされるサービスを用いるためにバックアップＳＩＰサーバから恩恵を受けることができる。

図１３は、本発明によるゲートウェイの一実施形態ＳＩＰＧＷ１を示すブロック図である。主サイトにあるピアゲートウェイＳＩＰＧＷ２も同様である。この実施形態ＳＩＰＧＷ１は、従来型ゲートウェイＣＧＷ、プロキシＰＲＯ、およびデータ圧縮モジュールＤＣを備える。従来型ゲートウェイＣＧＷは以下を備える：
− ＩＰインターフェース、ＳＩＰおよびトランクレイヤ、およびルート構成のパラメータなどのパラメータを記憶する、管理および構成モジュールＭＣ。
− ゲートウェイを公衆網ＰＳＴＮのトランクに接続するための、アナログまたはデジタルトランクインターフェースモジュールＴＩ。そのタイプはトランクのタイプに依存する。
− 企業ネットワークに接続されたメディアサーバモジュールＭＳ：これはＩＰネットワーク側にあり、ＲＴＰ／ＲＴＣＰ／Ｔ３８などの流れを管理する。
− トランスコーダモジュールＴＣ：これはデータペイロードに対して、企業ＩＰネットワークプロトコルにおいて用いられるプロトコルを公衆網ＰＳＴＮのトランクにおいて用いられるプロトコルに、および相互に変換するために、音声コーダ、ＨＤＬＣ（ハイレベルデータリンク制御）トランスコーダ、およびモデムなどの、いくつかのタイプのトランスコーディングリソースを備える。
− コール制御モジュールＣＣ：これはコールする側の端末よって用いられるシグナル伝達（ＳＩＰ、Ｑ９３１、アナログなど）のタイプに従ってコールを管理し、メディアサーバモジュールＭＳ、トランスコーダモジュールＴＭ、およびトランクモジュールＴＭを駆動する。

バックアップＳＩＰサーバＢＳＳの使用は、管理および構成モジュールＭＣ、および従来型ゲートウェイＣＧＷのコール制御モジュールＣＣの修正を意味する。管理および構成モジュールＭＣは、以下のパラメータを受け取り、記憶するように修正される：
− バックアップリンクＢＬを確立するために用いられるレスキューコール番号
− データ圧縮フラグ（圧縮をイネーブル／ディスエーブルする）
− バックアップリンクＢＬの帯域幅の値（任意選択）
コール制御モジュールＣＣは、コールされた番号がレスキューコール番号と一致した場合は、（通常任意の他のコールに対して行われるように、メディアサーバＭＳのリソース、およびトランスコーダモジュールＴＣの音声コーダリソースを開始（または終了）する代わりに）トランスコーダモジュールＴＣの関連するＨＤＬＣリソースをそれぞれ開始（または終了）するように修正される。

プロキシモジュールＰＲＯは、ＳＩＰＲｅｑｕｅｓｔ−ＵＲＩに含まれたＩＰアドレスに従って、各ＳＩＰメッセージを転送する。ＳＩＰメッセージは、そのＩＰアドレスがゲートウェイＳＩＰＧＷ１のアドレスである場合（通常のＩＳＤＮコール）はコール制御モジュールＣＣに送られ、ＩＰアドレスがメインＳＩＰサーバＭＳＳのアドレスである場合はデータ圧縮モジュールＤＣに送られる。後者の場合はプロキシは、それ自体のＩＰアドレスを各登録メソッド上のＰａｔｈヘッダ内に追加する。メインＳＩＰサーバＭＳＳに送られるそれぞれの他のＳＩＰメソッドに対しては、プロキシＰＲＯはＲｏｕｔｅヘッダ内のそれ自体のＩＰアドレスを抑制する。

データ圧縮モジュールＤＣＭは、ＳＩＰパケットのサイズを低減し、それによりバックアップリンクＢＬ上の最大シグナリングデータレートを増加させるために、構成パラメータに従って圧縮を適用する。

図１４は、ＳＩＰゲートウェイＳＩＰＧＷ１（およびＳＩＰＧＷ２）上のコール確立のために、本発明によるゲートウェイのこの実施形態によって行われる動作を示す。ゲートウェイＳＩＰＧＷ１によって管理される２つのタイプのコールがある：
− 音声コールを行うためのローカル電話機からまたはそれに対して用いられる基本の発信／着信コール
− コール制御モジュールＣＣＭがＳＩＰシグナリングデータのためのバックアップリンクＢＬを確立しなければならないときに、レスキューコール番号に基づいた、発信レスキューコール
ゲートウェイＳＩＰＧＷ２によって管理される２つのタイプのコールがある：
− 音声コールを行うためのローカル電話機からまたはそれに対して用いられる基本の発信／着信コール
− ＳＩＰＧＷ１のコール制御モジュールＣＣＭがＳＩＰシグナリングデータのためのバックアップリンクＢＬを確立しなければならないときに、レスキューコール番号に基づいた、着信レスキューコール
− ステップ１４０：コール制御モジュールＣＣは、公衆網ＰＳＴＮへのまたはそれからの発信コール（ＳＩＰＧＷ１）／着信コール（ＳＩＰＧＷ２）をセットアップするための要求を受け取る。
− ステップ１４１：コール制御モジュールＣＣは、発信／着信コール確立要求上の、コールされた番号をチェックする。
− ステップ１４２：番号がレスキューコール番号と一致した場合は、コール制御モジュールＣＣは、ＨＤＬＣプロトコルをサポートするバックアップリンクＢＬをセットアップする。
− ステップ１４３：番号がレスキューコール番号と一致しなかった場合は、コール制御モジュールＣＣは、企業ネットワークの側でのＲＴＰ（リアルタイム転送）プロトコルをサポートする従来型の音声リンクをセットアップし、トランスコーダモジュールＴＣにおけるデータトランスコーディングを開始する。

図１５は、ＳＩＰ要求および応答を主サイトに送るための、本発明によるゲートウェイのこの実施形態ＳＩＰＧＷ１によって行われる動作を示す：
− ステップ１５０：遠隔サイトから生じたＳＩＰメッセージは、ゲートウェイＳＩＰＧＷ１のプロキシＰＲＯによって受け取られる。
− ステップ１５１：プロキシＰＲＯは、その宛先ＵＲＩ（Ｒｅｑｕｅｓｔ−ＵＲＩ、またはＳＩＰ応答メッセージに対する識別された宛先）の内容をチェックする。
− ステップ１５２：ＵＲＩ＝ＸＸＸ＠ＳＩＰＧＷＡｄｄｒｅｓｓである場合は、プロキシＰＲＯは、メッセージをゲートウェイＳＩＰＧＷ１のコール制御モジュールＣＣに直接転送する。
− ステップ１５３：ＵＲＩ＝ＸＸＸ＠ＭａｉｎＳＩＰＧＳｅｒｖｅｒＡｄｄｒｅｓｓである場合は、プロキシＰＲＯは、バックアップリンクＢＬ上の帯域幅を節約するために、メッセージをデータ圧縮モジュールＤＣに転送する。
− ステップ１５４：次いで圧縮されたメッセージは、ＰＳＴＮネットワークを通じて圧縮されたメッセージをバックアップリンクＢＬ上に送信するために、ゲートウェイＳＩＰＧＷ１のトランスコーダモジュールＴＣ（ＨＤＬＣコーダ）に送られる。

図１６は、ＳＩＰ退出トラフィックを処理するために、遠隔サイト内のＳＩＰＧＷ１と、主サイト内のピアゲートウェイＳＩＰＧＷ２との両方によって行われる動作を示す。プロキシは、ローカルネットワークから、または公衆網ＰＳＴＮを通じて遠隔の構成要素（主サイト内またはローカルサイト内の）から、ＳＩＰ要求または応答を受け取ることができる。
− ステップ１６０：ゲートウェイＳＩＰＧＷ１／ＳＩＰＧＷ２は、ローカルネットワークからＳＩＰ要求または応答を受け取る。
− ステップ１６１：ゲートウェイＳＩＰＧＷ１／ＳＩＰＧＷ２は、公衆網ＰＳＴＮを通じて遠隔サイトからＳＩＰ要求または応答を受け取る。
− ステップ１６２：後者の場合はＨＤＬＣドライバは、圧縮されたデータを受け取り、それらを解凍モジュールに転送する。解凍モジュールはデータを解凍してＳＩＰメッセージを再構成し、ＳＩＰメッセージをゲートウェイのプロキシに送信する。
− ステップ１６３：プロキシはＳＩＰメッセージを受け取る。
− ステップ１６４：プロキシは、ＳＩＰメッセージをそのローカルネットワーク（ＳＩＰＧＷ１の場合はＢＳＳ、およびＳＩＰＧＷ２の場合はメインＳＩＰサーバＭＳＳ）内のその宛先に転送する。

Claims

セッション開始プロトコルＳＩＰを用いた企業ネットワークの生存性のためのゲートウェイであって、このネットワークが主サイトおよび少なくとも１つの遠隔サイトを備え、主サイトがメインＳＩＰサーバ（ＭＳＳ）を備え、遠隔サイトがバックアップＳＩＰサーバ（ＢＳＳ）を備え、これら２つのサイトがインターネットプロトコルネットワーク（ＷＡＮ）を通してインターネットプロトコルリンク（ＩＰＬ）を通じてＳＩＰシグナリングメッセージを交換し、前記ゲートウェイが、
構成パラメータを記憶するための管理および構成モジュール（ＭＣ）と、
ゲートウェイを公衆ネットワーク（ＰＳＴＮ）のトランクに接続するためのトランクインターフェースモジュール（ＴＩ）と、
企業ネットワークに接続されたメディアサーバモジュール（ＭＳ）と、
企業ネットワーク内で用いられるメディアおよび／またはプロトコルを、前記トランクで用いられるメディアおよび／またはプロトコルに、および相互に変換するためのトランスコーダモジュール（ＴＣ）と、
コールする側の端末によって用いられるシグナル伝達のタイプに従ってコールを管理し、メディアサーバモジュール（ＭＳ）、トランスコーダモジュール（ＴＣ）、およびトランクインターフェースモジュール（ＴＩ）を駆動するためのコール制御モジュール（ＣＣ）と
を備える、ゲートウェイにおいて、
バックアップリンク（ＢＬ）に送られるＳＩＰパケットのサイズを低減するために、構成パラメータに従って圧縮を適用するためのデータ圧縮手段（ＤＣ）と、
プロキシモジュール（ＰＲＯ）であって、
ＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩフィールドに含まれたＩＰアドレスに従って、ゲートウェイによって受け取られた各ＳＩＰメッセージを転送する手段であって、このＩＰアドレスがゲートウェイのアドレスである場合はＳＩＰメッセージがコール制御モジュール（ＣＣ）に送られ、ＩＰアドレスがメインＳＩＰサーバ（ＭＳＳ）のアドレスである場合はＳＩＰメッセージがデータ圧縮モジュール（ＤＣ）に送られる手段、
ＩＰアドレスがメインＳＩＰサーバ（ＭＳＳ）のアドレスである場合は、プロキシモジュールのＩＰアドレスを、各ＳＩＰＲｅｇｉｓｔｅｒメソッド上のＰａｔｈヘッダ内に追加する手段、および
メインＳＩＰサーバ（ＭＳＳ）に送られる、ＳＩＰＲｅｇｉｓｔｅｒメソッド以外のそれぞれのＳＩＰメソッドに対しては、Ｒｏｕｔｅヘッダ内のプロキシモジュールのＩＰアドレスをＲｏｕｔｅヘッダにおいて削除する手段
を含む、プロキシモジュール（ＰＲＯ）と
をさらに備えること、ならびに、
管理および構成モジュール（ＭＣ）が、
データ圧縮フラグを受け取って記憶する手段、および
バックアップリンク（ＢＬ）を確立するために用いられるレスキューコール番号を受け取って記憶する手段
を備え、
コール制御モジュール（ＣＣ）が、コールがバックアップリンクを確立するためのレスキューコールであるか通常のコールであるかのコールの性質に応じて、メディアサーバモジュール（ＭＳ）およびトランスコーダモジュール（ＴＣ）におけるリソースを開始および終了する手段を備え、
前記トランスコーダモジュール（ＴＣ）におけるリソースの開始および終了は、トランスコーダモジュール（ＴＣ）におけるリソースのそれぞれのタイプにさらに依存すること
を特徴とする、ゲートウェイ。
管理および構成モジュール（ＭＣ）が、バックアップリンク（ＢＬ）の帯域幅の値を受け取って記憶する手段をさらに備える、請求項１に記載のゲートウェイ。