(57)【要約】【課題】  従来のＰＢＸなどの機能を提供するＩＰセントレックスサーバに障害が発生しても、拠点内部の端末相互間の通話を可能とする。【解決手段】  サーババックアップ装置１が、ＩＰセントレックスサーバの障害を検出する手段２と、障害発生期間中に拠点内の端末間の通話のために端末側から送られた所定のメッセージの宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、そのメッセージをＩＰセントレックスサーバを経由することなく、相手端末側に直接に転送する手段３とを備える。【選択図】図１
2005229273.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数の電話端末と、該ネットワークの内部の端末相互間、および外部との通話の切換接続を行うサーバとの間に位置し、該サーバのバックアップを行うサーババックアップ装置であって、
前記サーバの障害を検出するサーバ障害検出手段と、
該障害の発生の期間中に、前記ネットワーク内の端末間の通信のために端末側から送られる所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、該メッセージを前記サーバを経由することなく、相手側端末に直接に転送するメッセージ転送手段とを備えることを特徴とするサーババックアップ装置。
【請求項２】
前記バックアップ装置において、前記複数の電話端末のそれぞれに対応して、端末の識別子としてのエンド・ポイントの名称と、端末のアドレスとを記憶するエンド・ポイント記憶手段をさらに備え、
前記メッセージ転送手段が、該エンド・ポイント記憶手段の記憶内容に基いてメッセージの転送を行うことを特徴とする請求項１記載のサーババックアップ装置。
【請求項３】
前記所定のメッセージが、前記端末側から通信相手端末側に呼の確立を要求するために送信されるインバイトメッセージであることを特徴とする請求項１記載のサーババックアップ装置。
【請求項４】
ネットワークに接続された複数の電話端末と、該ネットワークの内部の端末相互間、および外部との通話の切換接続を行うサーバとの間に位置し、該サーバのバックアップを行うサーババックアップ装置であって、
前記サーバの障害を検出するサーバ障害検出手段と、
該障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメッセージに対応して該メッセージに対する応答メッセージを生成し、該応答メッセージを前記所定のメッセージの送信元端末に送信するメッセージ生成手段とを備えることを特徴とするサーババックアップ装置。
【請求項５】
前記サーババックアップ装置において、同一端末からの前記所定のメッセージの受信回数を記憶する所定メッセージ受信回数記憶手段をさらに備え、
前記サーバ障害検出手段が、該記憶されたメッセージの受信回数があらかじめ定められた数を超えたとき、前記サーバの障害を検出することを特徴とする請求項１、または４記載のサーババックアップ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は例えば有線通信方式としての電話システムに係り、さらに詳しくはＩＰ化された音声電話信号に対して従来のＰＢＸなどの機能を提供するセントレックスサーバに障害が発生した場合のバックアップ装置に関する。
【背景技術】
【０００２】
最近、インターネットサービス機能を提供するＬＡＮシステムと、従来のＰＢＸなどの音声交換サービス機能とを統合して提供するＩＰセントレックスサーバが広範に用いられている。
【０００３】
このようなシステムでは、セントレックスサーバの配下の全ての電話端末は電話をかける際に必ずそのサーバにアクセスする必要がある。そのためセントレックスサーバ自体に障害が発生したり、セントレックスサーバまでの通信路に障害が起きた場合には、サーバに正常にアクセスできなくなり、サーバ配下の全てのＩＰ電話端末は従来のＰＢＸの範囲に相当する拠点内部の端末相互間でも電話サービスを利用することができなくなってしまうという問題点があった。
【０００４】
このような場合に、例えばＬＡＮケーブルが抜けたことなどを検出して、それに対応することが可能な端末も存在する。このような端末はＩＰセントレックスサーバへのアクセスができないときにユーザが電話サービスを利用しようとすると、ＰＳＴＮ（パブリック・スイッチド・テレフォン・ネットワーク、公衆電話交換網）に対する接続を試みる機能をもっており、緊急時にはＰＳＴＮを用いて電話を掛けることができる。しかしながら拠点内部での通話を行う場合には１つの拠点に対して複数の電話回線が必要であり、さらに通常通話料金を必要としない拠点内部での通信においてＰＳＴＮへの接続を行うことによって、不必要な通話料金がかかってしまうという問題点がある。
【０００５】
さらに電話端末によってはＩＰセントレックスサーバにアクセスできないことを検出した場合には特別のルータに接続を試み、この特別のルータが別の経路を用いてセントレックスサーバへのアクセスを試みることができるものが存在する。このような端末を用いると、ユーザはセントレックスサーバへの経路に障害が起きている場合にもＩＰ電話サービスを用いることができる。
【０００６】
このような特別なルータを用いる場合には、この特別のルータがＩＰ電話端末からの通話が内線通話であるか外線通話であるかを認識し、内線通話であればそのルータ自身がＩＰセントレックスサーバの代わりに動作し、内線通話を可能にすることができる。しかしながらこの機能を用いるためには、ＩＰ電話端末自体がＩＰセントレックスサーバにアクセスできないことを検出する必要がある。このような機能を持っている機器は実際にはかなり限定されており、この機能に対応していない端末を用いる場合には、ＩＰセントレックスサーバの障害発生時に電話サービスを利用することができないという問題点があった。
【０００７】
またこのような電話システムにおける停電などの障害に対処するための従来技術として次の文献がある。
【特許文献１】特開２００２−１５２２５０号公報「音声スイッチシステム」
【０００８】
この文献には、ＩＰ化した音声信号にキーテレフォン、ＰＢＸ、セントレックス等のサービスを提供し、同時にインターネットアクセスを提供する音声スイッチシステムにおいて、停電などの障害に対応するために、停電時にはバックアップ電源から給電を継続し、そのバックアップ電源による給電の停止時には電話機を公衆回線に切換接続する切換接続機能、ＬＡＮへのインタフェース機能を有するラインカードを備え、障害時や災害時にも容易に対処することができるシステムが開示されている。しかしながらこの文献の技術においても、電話機に電源を供給する給電機能停止時にバックアップ電源から給電を継続し、バックアップ電源による給電の停止時には電話機を公衆回線に切換接続するための特別のラインカードを必要とするという問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の課題は、上述の問題点に鑑み、ＩＰセントレックスサーバに障害が発生し、その機能が有効で無い時にも拠点の内部の端末相互間の通話に関しては電話サービスを利用できるようにするためのサーババックアップ装置を提供することである。
【課題を解決するための手段】
【００１０】
図１は本発明のサーババックアップ装置の原理構成ブロック図である。同図はネットワークに接続された複数の電話端末、例えばＩＰ電話端末と、そのネットワークの内部の端末相互間の通話、および外部との通話の切換接続を行うサーバとの間に位置し、そのサーバのバックアップを行うサーババックアップ装置の原理構成を示し、サーババックアップ装置１は、少なくともサーバ障害検出手段２、およびメッセージ転送手段３を備える。
【００１１】
サーバ障害検出手段２はサーバの障害を検出するものであり、例えば後述する呼状態管理部とＳＩＰメッセージ読取部に相当する。メッセージ転送手段３は障害の発生期間中にネットワーク内での端末間の通信のために端末側から送られる所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、そのメッセージをサーバを経由することなく相手側端末に直接に転送するものであり、例えばＳＩＰメッセージ書き換え部に相当する。
【００１２】
発明の実施の形態においては、バックアップ装置１が複数のＩＰ電話端末のそれぞれに対応して、端末の識別子としてのエンド・ポイント名称とＩＰアドレスとを記憶するエンド・ポイント記憶手段、例えばエンド・ポイント・テーブルをさらに備え、メッセージ転送手段３がエンド・ポイント記憶手段の記憶内容に基いてメッセージの転送を行うこともできる。また所定のメッセージは、相手端末側に呼の確立を要求するために送られるインバイトメッセージであることもできる。
【００１３】
また本発明のサーババックアップ装置は、サーバ障害検出手段と、サーバ障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメッセージに対応して該メッセージに対する応答メッセージを生成し、該応答メッセージを前記所定のメッセージの送信元端末に送信するメッセージ生成手段、例えばＳＩＰメッセージ生成部とを備える。実施の形態においては、所定のメッセージは端末側から自端末の登録のために送信されるレジスタメッセージであることもできる。
【００１４】
また実施の形態においては、サーババックアップ装置が、同一端末からの前記所定のメッセージの受信回数を記憶する所定メッセージ受信回数記憶手段、例えばアクティブ・コール・テーブルをさらに備え、前記サーバ障害検出手段が、該記憶されたメッセージの受信回数があらかじめ定められた数を超えたとき、前記サーバの障害を検出することもできる。
【００１５】
次に本発明においてネットワークに接続された複数の電話端末と、該ネットワーク内部の端末相互間、および外部との通話の切換接続を行うサーバのバックアップを行う方法として、同一端末からの所定のメッセージの受信回数を監視してサーバの障害を検出し、該サーバ障害の発生期間中に、前記ネットワーク内の端末間の通信のために端末側から送られる所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、該メッセージを前記サーバを経由することなく相手側端末に直接に転送する方法が用いられる。
【００１６】
次にネットワークに接続された複数の電話端末と、該ネットワーク内部の端末相互間、および外部との通話の切換接続を行うサーバのバックアップを行う方法として、同一端末からの所定のメッセージの受信回数を監視してサーバの障害を検出し、該サーバ障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメッセージに対応して、該メッセージに対する応答メッセージを生成し、該応答メッセージを前記所定のメッセージの送信元端末に送信する方法が用いられる。
【００１７】
以上のように本発明によれば、端末相互間、および外部との通話の切換接続を行うサーバに障害が発生した場合にも、バックアップ装置によって所定のメッセージ内の転送先アドレスの書換えや、転送元端末への応答メッセージの生成が行われる。
【発明の効果】
【００１８】
本発明によれば、ＩＰセントレックスサーバの障害発生時にも、拠点内部の端末相互間ではＰＳＴＮに接続を行うことなく通話を行うことが可能となる。これによってユーザは通話料金を不必要に負担することなく、拠点内部の電話を確保することが可能となり、ＩＰ電話システムの実用性の向上に寄与するところが大きい。
【発明を実施するための最良の形態】
【００１９】
図２は、本発明のバックアップ装置、すなわちＩＰセントレックスサーバ（Ｃｅｎｔｒｅｘ  Ｓｅｒｖｅｒ）の障害発生時のバックアップを行うバックアップ装置を含む全体システムの構成ブロック図である。同図において本発明のバックアップ装置１０は、１つの拠点１１、例えばＡの内部のＩＰ電話端末の全て１２1、１２2．．をネットワーク、例えばローカルエリアネットワーク１３を介して終端し、またこのネットワーク１３は、ルータ１４、ＩＰネットワーク１５を介して、ＩＰセントレックスサーバ１６に接続されている。拠点内部の電話端末１２は、ルータ１４やＩＰセントレックスサーバ１６などを介して拠点外部との通話が可能となっている。
【００２０】
図３は、図２のシステムにおけるＩＰセントレックスサーバの正常時の動作と、障害時の動作の説明図である。正常時においては、例えば端末１２2から端末１２1への通話はバックアップ装置１０、ルータ１４、ＩＰネットワーク１５、ＩＰセントレックスサーバ１６に至り、さらにＩＰネットワーク１５、ルータ１４、バックアップ装置１０を介する経路によって端末１２1に接続され、通話が行われる。
【００２１】
これに対して、ＩＰセントレックスサーバ１６の障害発生時には、その障害発生がバックアップ装置１０によって検出され、端末１２2からの通話はバックアップ装置１０から直接に端末１２1に至る経路を用いて接続されることになる。
【００２２】
図４は、セントレックスサーバ正常動作時のシステム内動作のさらに詳細な説明図である。ここでは端末１２1からの発呼によって端末１２2との間で通話が行われるものとする。なおここでバックアップ装置１０のＩＰアドレスは１１１．１．１．１０、端末１２1のＩＰアドレスは１１１．１．１．１、端末１２2のＩＰアドレスは１１１．１．１．２、またＩＰセントレックスサーバ１６のＩＰアドレスは１３３．１．１．１とする。
【００２３】
図４において、端末１２1から送られる、セッションの確立、維持、終了を行うためのセッション・イニシエーション・プロトコル（ＳＩＰ）メッセージ、例えば後述するレジスタメッセージ、インバイトメッセージなどは、（１）でＬＡＮ１３を介してバックアップ装置１０に至り、バックアップ装置１０からＬＡＮ１３、ルータ１４、ＩＰネットワーク１５を経由してＩＰセントレックスサーバ１６に至る経路によって（２）で転送され、その後（３）でＩＰセントレックスサーバ１６からＩＰネットワーク１５、ルータ１４、ＬＡＮ１３を介してバックアップ装置１０に至る経路によってバックアップ装置１０に転送され、さらにバックアップ装置１０からＬＡＮ１３を介して端末１２2に転送される。なお端末間で呼の接続が完了した後の実際の音声信号、すなわちリアルタイム・トランスポート・プロトコル（ＲＴＰ）によるメディアストリームのやりとりは、バックアップ装置１０を介することなく、ＬＡＮ１３を介して直接に端末間で行われる。ＩＰセントレックスサーバ１６の正常動作時にも、実際の音声信号は同様に端末間で直接にやり取りされる。
【００２４】
図５はセントレックスサーバ障害発生時の動作の詳細説明図である。図４におけると同様に、端末１２1からＬＡＮ１３を介して（１）でバックアップ装置１０に対して呼確立のための、例えばインバイトメッセージが転送されると、バックアップ装置１０は後述するようにＩＰセントレックスサーバ１６の障害発生を検出しており、そのためバックアップ装置１０はそのメッセージをＩＰセントレックスサーバ１６側に転送することなく直接に相手側のＩＰ電話端末１２2に（２）で転送し、２つの端末間の通話が可能となる。なお端末間で呼の接続が完了した後の実際の音声信号、すなわちリアルタイム・トランスポート・プロトコルによるメディアストリームのやりとりは、バックアップ装置１０を介することなく、ＬＡＮ１３を介して直接に端末間で行われる。ＩＰセントレックスサーバ１６の正常動作時にも、実際の音声信号は同様に端末間で直接にやり取りされる。
【００２５】
図６は、図２におけるバックアップ装置１０の詳細構成ブロック図である。同図においてバックアップ装置１０は、呼状態管理部２１、アクティブ・コール・テーブル（Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ）２２、エンド・ポイント・テーブル（Ｅｎｄ  Ｐｏｉｎｔ  Ｔａｂｌｅ）２３、ＳＩＰメッセージ読取部２４、ＳＩＰメッセージ書換え部２５、およびＳＩＰメッセージ生成部２６を備えている。
【００２６】
図６においてバックアップ装置１０に入力されるすべてのＳＩＰメッセージは、まず呼状態管理部２１に与えられ、メッセージの種類が判別され、その扱い方が決定され、また呼の状態が管理される。アクティブ・コール・テーブル２２には、現在通話中の呼に関する情報が記述されており、呼状態管理部２１がＳＩＰメッセージの扱い方を決定するにあたって、その情報が用いられる。エンド・ポイント・テーブル２３には、拠点の内部のＩＰ電話端末に関する情報が格納されている。ここでエンド・ポイントとは、一般的にエンティティ内に物理的、または論理的に存在するデータのソース、またはシンクを意味する。
【００２７】
ＳＩＰメッセージ読取部２４は、呼状態管理部２１を介して入力されるＳＩＰメッセージに対応して、エンド・ポイント・テーブル２３の格納内容などを用いてそのメッセージの送信先が存在するか否か、あるいはその送信先にメッセージを転送可能であるか否かを判断し、送信先が存在して転送可能である場合にはそのメッセージをＳＩＰメッセージ書換え部２５に出力し、送信先が存在しないか、例えばＩＰセントレックスサーバ１６に障害が発生し、拠点の外部に存在する送信先にメッセージを転送できない場合には、例えばメッセージの送信元に対して応答を行うための新しいＳＩＰメッセージの生成をＳＩＰメッセージ生成部２６に指示する。
【００２８】
図６の呼状態管理部２１は、入力されたＳＩＰメッセージを４つの種類に分類する。第１はＩＰ電話端末側から送信される呼の確立に関係するＳＩＰメッセージ、例えばＩＰセントレックスサーバ１６に自端末の登録を要求するレジスター（ＲＥＧＩＳＴＥＲ）メッセージであり、第２の種類はＩＰセントレックスサーバ１６から送られる呼の確立に関係するＳＩＰメッセージであり、第３の種類は呼の終了に関係するＳＩＰメッセージ、例えばセッション開放要求ＢＹＥに対する２００ＯＫメッセージ、エラーメッセージ、例えば４ｘｘなどに対するＡＣＫメッセージであり、第４の種類はこれらの３種類以外の全てのＳＩＰメッセージである。
【００２９】
呼状態管理部２１は、ＳＩＰメッセージの分類結果に応じてアクティブ・コール・テーブル２２における新しいエントリの作成、データの更新、エントリの削除などの処理を行う。図７は、このアクティブ・コール・テーブル２２の格納内容の例である。このアクティブ・コール・テーブル２２には、現在通話中の呼に関するデータが格納される。１つの呼に対してアクティブ・コール・テーブル２２に１つのエントリーが作成される。例えば呼の転送が行われる場合には、転送前に存在する、保留中の呼と、通話中の呼は別のものとして扱われ、異なるエントリーが作成される。
【００３０】
Ｃａｌｌ  Ｌｅｇは呼を判別するために用いられる識別子としてのデータであり、後述するようにメッセージの内部のＦｒｏｍヘッダのタグの値、およびＣａｌｌ−ＩＤの値を示し、Ｃａｌｌｅｒは発呼者、すなわち発呼端末の電話番号などを示している。Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値は、発呼端末から同一メッセージが連続的に送られてきた回数に対応し、Ｔｉｍｅはその呼の中で最新のメッセージが送信されてきた時刻を示す。この時刻は、対応する呼に関するＳＩＰメッセージが長時間送られてこない場合にアクティブ・コール・テーブル２３からその呼に関連するデータを削除するために用いられる。
【００３１】
本実施形態においては、例えば図２においてＩＰセントレックスサーバ１６が障害発生状態にあるか否かの判定は、同一の端末から同一のＳＩＰメッセージがバックアップ装置１０に送られてきた回数によって行うものとする。バックアップ装置１０は、例えば端末１２1から送られてきた、例えばレジスタメッセージを前述のようにＩＰセントレックスサーバ１６に転送するが、それに対するＩＰセントレックスサーバ１６からの応答が端末１２1に届かない場合には、端末１２1はレジスタメッセージの再送を行う。
【００３２】
このためＩＰセントレックスサーバ１６からの応答が得られない場合には端末１２1は例えばレジスタメッセージのバックアップ装置１０に対する送信を繰り返すことになり、その繰り返し回数は図７のＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値に反映される。ＳＩＰメッセージ読取部２４は、その値が５を超えた場合、すなわち例えばレジスタメッセージのＩＰセントレックスサーバ１６への転送が５回行われたにもかかわらず応答がない場合に、ＩＰセントレックスサーバ１６は障害状態にあるものと判定し、端末１２1からの６回目のレジスタメッセージの送信に対して、例えば２００ＯＫというコードと、レジスタメッセージ送信元アドレスとの値をＳＩＰメッセージ生成部２６に与え、ＳＩＰメッセージ生成部２６はレジスタメッセージへの応答を示す２００ＯＫメッセージをレジスタメッセージの送信元に対して送信すると共に、バックアップ装置１０は、例えば同一発呼端末からのその後の呼制御のためのメッセージをＩＰセントレックスサーバ１６に転送することなく、直接に拠点内の相手側ＩＰ電話端末、例えば１２2に転送することになる。
【００３３】
本実施形態においては、同一端末からの送信繰り返しの回数によってＩＰセントレックスサーバ１６の障害検出が行われるＳＩＰメッセージとしては、前述のレジスタメッセージ以外に、通信相手端末側に呼（セッション）の確立を要求するインバイトメッセージがあるものとする。
【００３４】
このようなメッセージは一般にイニシャル・インバイトメッセージと呼ばれる。インバイトメッセージにはイニシャル・インバイトメッセージの他に、呼の転送を行う場合に用いられるｒｅ−ＩＮＶＩＴＥメッセージがあるが、本実施形態においてはレジスタメッセージとイニシャル・インバイトメッセージのそれぞれに対応してアクティブ・コール・テーブル２３にエントリが作成されるものとし、以後イニシャル・インバイトメッセージを単にインバイトメッセージと呼ぶことにする。
【００３５】
また、ＴＣＰ／ＩＰの規格としてのリクエスト・フォー・コメンツ（ＲＦＣ）の勧告によると、ＩＰ電話端末はＳＩＰメッセージの再送を、例えば７回以上行うものとしているが、本実施形態では同一ＳＩＰメッセージの受信が６回行われた時点でＩＰセントレックスサーバ１６の障害発生と見なすことにする。
【００３６】
図８は、エンド・ポイント・テーブル２３の格納内容の例である。このエンド・ポイント・テーブル２３は、図２では拠点Ａの内部に存在し、着信が可能なＩＰ電話端末に関するデータを格納する。Ｅｎｄ  Ｐｏｉｎｔ  ＮａｍｅはＩＰ電話端末に対して設定されているＳＩＰ  ＵＲＩのユーザパート部を示すものであり、ＩＰ  ＡｄｄｒｅｓｓはＩＰ電話端末のアドレスであり、Ｅｘｐｉｒｅはそのエントリのデータに対する有効期限を示す。これらのデータは呼状態管理部２１によって管理される。またエンド・ポイント・テーブル２３はＳＩＰメッセージをＩＰ電話端末に送信する場合にも用いられ、ＳＩＰメッセージ読取部２４はエンド・ポイント・テーブル２３の格納内容を用いてＳＩＰメッセージの送信先を設定する。
【００３７】
続いて具体的なメッセージの例を用いて呼状態管理部２１、ＳＩＰメッセージ読取部２４などの動作についてさらに詳細に説明する。図９は、端末が自身のＩＰアドレスをＩＰセントレックスサーバに登録する際に利用されるＳＩＰメッセージであるレジスタメッセージの具体例である。
【００３８】
図９に示したようなメッセージをＩＰセントレックスサーバ１６に転送するか、あるいは直接拠点内の端末に転送するかなどの判定には、前述のようにアクティブ・コール・テーブル２２内のＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値が用いられる。呼状態管理部２１は、同一のＳＩＰメッセージが同一端末から繰り返し送信されてくるたびに、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値をインクリメントし、その値がメッセージと共にＳＩＰメッセージ読取部２４に与えられる。ＳＩＰメッセージ読取部２４はその値を基として、メッセージをＩＰセントレックスサーバ１６に転送するか、端末に転送するかの判定を行う。またこのようなメッセージには端末についての情報が含まれており、呼状態管理部２１は２つの情報、すなわちＥｎｄ  Ｐｏｉｎｔ  Ｎａｍｅ、ＩＰ  Ａｄｄｒｅｓｓを示すデータを取り出し、メッセージを受信した時間と共にエンド・ポイント・テーブル２３にそのデータを反映させる。
【００３９】
つづいて前述のメッセージの４つの種類にそれぞれ対応させて、呼状態管理部２１の動作についてさらに詳細に説明する。まず端末側から送信されてきた呼の確立に関係するＳＩＰメッセージ、例えば図９に示したレジスタメッセージなどに対応して、呼状態管理部２１によって行われる動作は次のようになる。
１．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用の情報として、ＳＩＰメッセージからＣａｌｌｅｒ値を取り出す。ＦｒｏｍヘッダのＳＩＰ  ＵＲＩのユーザ部をＣａｌｌｅｒとして読みとる。図９の例の場合、０５０１１１１０００１となる。
２．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用に、ＳＩＰメッセージからＦｒｏｍ−ｔａｇ、Ｃａｌｌ−ＩＤをＣａｌｌ  Ｌｅｇとして読みとる。図９の例の場合、Ｃａｌｌ  Ｌｅｇ＝０００１１０２９３４９１９２；１０６１ｂ０５ｃ−ｅ０ｃ２１１０ａ−１３ｃ４−３ｅｃ４ｃ５ｅ６＠１０．１．１．１となる。
３．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２からＣａｌｌ  Ｌｅｇを検索し、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値を読みとる。
４．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２にＣａｌｌ  Ｌｅｇが存在しない場合は、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値は０として読みとり、Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２にＣａｌｌ  Ｌｅｇ、Ｃａｌｌｅｒを登録する。
５．Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値をインクリメントし、Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２に内容を反映させる。
６．Ｅｎｄ  Ｐｏｉｎｔ  Ｔａｂｌｅ２３からＥｎｄ  Ｐｏｉｎｔ  Ｎａｍｅを検索し、あったらＩＰ  Ａｄｄｒｅｓｓ、Ｅｘｐｉｒｅ値を上書きする。
７．Ｅｎｄ  Ｐｏｉｎｔ  Ｔａｂｌｅ２３にＥｎｄ  Ｐｏｉｎｔ  Ｎａｍｅが無いときにはＥｎｄ  Ｐｏｉｎｔ  Ｎａｍｅ、ＩＰ  Ａｄｄｒｅｓｓ、Ｅｘｐｉｒｅ値を追加する。
８．現在の時間に２時間を加えてＥｎｄ  Ｐｏｉｎｔ  Ｔａｂｌｅ２３のＥｘｐｉｒｅ値として登録する。
９．ＳＩＰメッセージ読取部２４に、送信元アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値、ＳＩＰメッセージを渡す。
【００４０】
次に第２の種類としてのＩＰセントレックスサーバ１６から送信されてきた呼の確立に関係するＳＩＰメッセージの取り扱いについて説明する。この場合には呼状態管理部２１、はアクティブ・コール・テーブル２２に新しい呼としてのこの呼に関するデータを新しいエントリに登録し、ＳＩＰメッセージ読取部２４にＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値とＳＩＰメッセージとを渡す動作を行う。この動作は以下のようになる。
１．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用の情報として、ＳＩＰメッセージからＣａｌｌｅｒ値を取り出す。ＦｒｏｍヘッダのＳＩＰ  ＵＲＩのユーザ部をＣａｌｌｅｒとして読みとる。
２．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用に、ＳＩＰメッセージからＦｒｏｍ−ｔａｇ、Ｃａｌｌ−ＩＤをＣａｌｌ  Ｌｅｇとして読みとる。
３．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２にＣａｌｌ  Ｌｅｇ、Ｃａｌｌｅｒ、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値を登録する。このときＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値は０とする。
４．ＳＩＰメッセージ読取部２４に、送信元アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値、ＳＩＰメッセージを渡す。
【００４１】
次に第３の種類としての呼の終了に関係するＳＩＰメッセージの入力に対して、呼状態管理部２１はＳＩＰメッセージ読取部２４にその呼に関するＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値とＳＩＰメッセージを渡し、その後アクティブ・コール・テーブル２２からその呼に関するデータが格納されているエントリの削除を行う。この動作は次のようになる。
１．送信元アドレスをパケットのＩＰ部より読みとる。
２．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用の情報として、ＳＩＰメッセージからＣａｌｌｅｒ値を取り出す。ＦｒｏｍヘッダのＳＩＰ  ＵＲＩのユーザ部をＣａｌｌｅｒとして読みとる。
３．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用に、ＳＩＰメッセージからＦｒｏｍ−ｔａｇ、Ｃａｌｌ−ＩＤをＣａｌｌ  Ｌｅｇとして読みとる。
４．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２からＣａｌｌ  Ｌｅｇを検索し、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値を読みとる。例えばエラーのために存在しないときには、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値を０として読みとる。
５．ＳＩＰメッセージ読取部２４に、送信元アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値、ＳＩＰメッセージを渡す。
６．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２に呼情報が載っていた場合は、その呼情報をＡｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２から削除する。
【００４２】
最後に第４の種類としての呼の確立や終了に関係のない一般的なＳＩＰメッセージの入力に対応する呼状態管理部２１の動作は、その呼に対応するＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値とＳＩＰメッセージをＳＩＰメッセージ読取部２４に渡すだけである。その動作は以下のようになる。
１．送信元アドレスをパケットのＩＰ部より読みとる。
２．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用の情報として、ＳＩＰメッセージからＣａｌｌｅｒ値を取り出す。ＦｒｏｍヘッダのＳＩＰ  ＵＲＩのユーザ部をＣａｌｌｅｒとして読みとる。
３．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２用に、ＳＩＰメッセージからＦｒｏｍ−ｔａｇ、Ｃａｌｌ−ＩＤをＣａｌｌ  Ｌｅｇとして読みとる。
４．Ａｃｔｉｖｅ  Ｃａｌｌ  Ｔａｂｌｅ２２からＣａｌｌ  Ｌｅｇを検索し、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値を読みとる。存在しないときには、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値を０として読みとる。
５．ＳＩＰメッセージ読取部２４に、送信元アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅ値、ＳＩＰメッセージを渡す。
【００４３】
次にＳＩＰメッセージ読取部２４の動作についてさらに説明する。ＳＩＰメッセージ読取部２４は、呼状態管理部２１からメッセージの送信元アドレスと同時にその呼に対応するＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値、およびＳＩＰメッセージを受け取る。そしてまず送信元アドレスの値によってＳＩＰメッセージの送信元がＩＰセントレックスサーバ１６であるか、それ以外のＩＰ電話端末であるかを判定し、その判定結果に応じて処理を行う。なお、ＩＰセントレックスサーバ１６のＩＰアドレスは、図４で説明したように当然既知であるものとする。
【００４４】
ＩＰセントレックスサーバ１６からのメッセージを受け取った場合、ＳＩＰメッセージ読取部２４は、まずＳＩＰメッセージの種類が、Ｒｅｑｕｅｓｔメッセージであるか、Ｒｅｓｐｏｎｓｅメッセージであるかの判断を行う。Ｒｅｑｕｅｓｔメッセージは端末が新しい動作を起こそうとするときに送信されるもので、例えば呼の確立要求であるＩＮＶＩＴＥがこれにある。ＲｅｓｐｏｎｓｅメッセージはＲｅｑｕｅｓｔメッセージを受け取った端末が、そのメッセージに対する応答を返す際に送信されるものである。
【００４５】
Ｒｅｑｕｅｓｔメッセージの場合、ＳＩＰメッセージの中の後述するリクエストＵＲＩのユーザパートを参照し、その値をエンド・ポイント・テーブル２３に格納されているＥｎｄ  Ｐｏｉｎｔ  Ｎａｍｅの値と比較する。リクエストＵＲＩと一致するものが存在する場合には、エンド・ポイント・テーブル２３のそのエントリからＩＰアドレスを送信先アドレスとして読取り、ＳＩＰメッセージ書き換え部２５に送信先アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値、およびＳＩＰメッセージを渡す。これに対応してＳＩＰメッセージ書換え部２５によってメッセージの送信先アドレスがバックアップ装置１０のアドレスから拠点内部の電話端末のアドレスに書き換えられ、拠点内部の端末、あるいは拠点の外部から送られてきたＳＩＰメッセージの転送が行われる。
【００４６】
エンド・ポイント・テーブル２２の中にリクエストＵＲＩと一致するＥｎｄ  Ｐｏｉｎｔ  Ｎａｍｅが存在しない場合には、ＳＩＰメッセージ読取部２４からＳＩＰメッセージ生成部２６にＳＩＰメッセージと共に、送信先アドレスとしてのＩＰセントレックスサーバ１６のＩＰアドレスと、転送先が存在しないことを示す４０４Ｎｏｔ  Ｆｏｕｎｄというコードが渡され、転送先が存在しないことを示す新しいメッセージが生成されてＩＰセントレックスサーバ１６に送られることになる。
【００４７】
Ｒｅｓｐｏｎｓｅメッセージの場合、ＳＩＰメッセージのＶｉａヘッダの２行目からＩＰアドレスを読取り、ＳＩＰメッセージ書き換え部２５に送信先アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値、およびＳＩＰメッセージを渡す。これに対応してＳＩＰメッセージ書換え部２５によってメッセージの送信先アドレスがバックアップ装置１０のアドレスから拠点内部の電話端末のアドレスに書き換えられ、拠点内部の端末、あるいは拠点の外部から送られてきたＳＩＰメッセージの転送が行われる。
【００４８】
Ｖｉａヘッダには、Ｒｅｑｕｅｓｔメッセージを送信した装置のＩＰアドレスが含まれる。図９の例では、ＩＰアドレスは１０．１．１．１である。ＲｅｑｕｅｓｔメッセージがＳＩＰ  Ｐｒｏｘｙサーバを経由する際には、ＳＩＰ  ＰｒｏｘｙサーバがＳＩＰ  ＰｒｏｘｙサーバのＩＰアドレスを含むＶｉａヘッダを一行追加し、ＳＩＰメッセージを転送する。
【００４９】
このＲｅｑｕｅｓｔメッセージを受け取った端末が応答としてＲｅｓｐｏｎｓｅメッセージを送信する際には、このＶｉａヘッダのＩＰアドレスがＲｅｓｐｏｎｓｅメッセージの送信先として扱われる。なお、端末がＲｅｓｐｏｎｓｅメッセージを作成する際にはＲｅｑｕｅｓｔメッセージに挿入されていたＶｉａヘッダをＲｅｓｐｏｎｓｅメッセージにそのまま記述する。このため、ＳＩＰ読取部が受信するＲｅｓｐｏｎｓｅメッセージのＶｉａヘッダの２行目には、Ｒｅｓｐｏｎｓｅメッセージの送信先アドレスが記述されており、ＳＩＰメッセージ読取部２４はＩＰアドレスを送信先アドレスとしてＶｉａヘッダの２行目を読取る。
【００５０】
次にＩＰセントレックスサーバ１６以外のＩＰ電話端末から送信されてきたＳＩＰメッセージを受け取った場合には、ＳＩＰメッセージ読取部２４がそのメッセージがレジスタメッセージか否かの判定を行う。レジスタメッセージであり、かつ呼状態管理部２１から受け取ったＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値が５を超えている場合には、呼状態管理部２１から渡された送信元アドレスの値を送信先アドレスとしてセットし、ＳＩＰメッセージと共に、その送信先アドレスとエンド・ポイントの登録が終了したことを示す２００  ＯＫというコードがＳＩＰメッセージ生成部２６に渡される。これによってエンド・ポイントの登録終了を示す新しいメッセージが生成され、レジスタメッセージの送信元端末に送られることになる。
【００５１】
これに対してレジスタメッセージであり、かつＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値が５以下であれば、送信先アドレスとしてＩＰセントレックスサーバ１６のＩＰアドレスを設定し、ＳＩＰメッセージと共にその送信先アドレスがＳＩＰメッセージ書換え部２５に渡され、メッセージ内の送信先アドレスの書換えなどが行われ、そのメッセージがＩＰセントレックスサーバ１６に送られることになる。
【００５２】
ＩＰセントレックスサーバ１６以外の端末からレジスタメッセージ、およびイニシャル・インバイトメッセージ以外のＳＩＰメッセージを受け取った場合、ＳＩＰメッセージ読取部２４は、まずＳＩＰメッセージの種類が、Ｒｅｑｕｅｓｔメッセージであるか、Ｒｅｓｐｏｎｓｅメッセージであるかの判断を行う。
【００５３】
Ｒｅｑｕｅｓｔメッセージの場合、ＳＩＰメッセージ読取部２４はその呼に対応するＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値が６以上であるときにはＳＩＰメッセージの中のリクエストＵＲＩのユーザパート部を参照し、その値をエンド・ポイント・テーブル２３の内部に格納されているエンド・ポイント・ネームの値と比較する。一致する値が存在する場合には、エンド・ポイント・テーブル２３からＩＰアドレスを読みとり、それを送信先アドレスとしてＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値、およびＳＩＰメッセージと共にＳＩＰメッセージ書き換え部２５に渡す。
【００５４】
これに対してエンド・ポイント・テーブル２３内のエンド・ポイント・ネームの値と一致しなかった場合には、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値を参照し、その値が６以上であれば、例えば外部との通話ができないことを示す４０４Ｎｏｔ  Ｆｏｕｎｄというコードを生成し、ＳＩＰメッセージの送信元アドレスを送信先アドレスとしてセットし、ＳＩＰメッセージ生成部２６にその送信先アドレス、コード、およびＳＩＰメッセージを渡す。ＳＩＰメッセージ生成部２６により、ＳＩＰメッセージの送信元の端末に、通信相手側端末との接続ができないことを示すメッセージが生成されて送信される。
【００５５】
Ｒｅｓｐｏｎｓｅメッセージの場合、ＳＩＰメッセージのＶｉａヘッダの２行目からＩＰアドレスを読取り、ＳＩＰメッセージ書き換え部２５に送信先アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値、およびＳＩＰメッセージを渡す。
【００５６】
参照したＳｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値が５以下である場合には、ＳＩＰメッセージ読取部２４は送信先アドレスとしてＩＰセントレックスサーバ１６のアドレスを設定し、その送信先アドレス、Ｓｅｒｖｅｒ  Ｋｅｅｐ  Ａｌｉｖｅの値、およびＳＩＰメッセージをＳＩＰメッセージ書き換え部２５に渡し、ＳＩＰメッセージ書き換え部２５によってアドレスの書き換えが行われ、そのメッセージがＩＰセントレックスサーバ１６に向けて送信される。
【００５７】
つづいてＳＩＰメッセージ書換え部２５の動作についてさらに説明する。ＳＩＰメッセージ書換え部２５は、ＳＩＰメッセージ読取部２４から渡されるＳＩＰメッセージ、および送信先アドレスを用いて、例えばメッセージの送信先アドレスや送信元アドレスの書換えを行い、渡された送信先アドレスを宛先として書換え後のＳＩＰメッセージを送信する。このときＳＩＰメッセージの送信元アドレスとしては、ＩＰセントレックスサーバ１６、およびＩＰ電話端末に対してバックアップ装置１０が送信元であるようにみせるために、自装置のＩＰアドレス、例えば図４では１１１．１．１．１０を送信元アドレスとするようにＳＩＰメッセージの書換えを行う。なお、例えば図９のレジスタメッセージでは、さらにセッション情報の記述方法を規定するセッション・デスクリプション・プロトコル（ＳＤＰ）についての部分が続くが、このＳＤＰ部分の書き換えは行われない。
【００５８】
図１０から図１２はＳＩＰメッセージ書換え部２５によるメッセージの書換えの具体例の説明図である。図１０はバックアップ装置１０からＩＰセントレックスサーバ１６に送られるインバイトメッセージの書換え例の説明図であり、ＩＰセントレックスサーバ１６が正常に動作している場合の書換えを示している。
【００５９】
図１０においては、まず先頭の送信元アドレス（Ｓｒｃ、ソースアドレス）がバックアップ装置１０のアドレスとドメイン名に、また送信先アドレス（Ｄｓｔ、デスティネーションアドレス）がＩＰセントレックスサーバ１６のＩＰアドレスに書き換えられると共に、ＩＮＶＩＴＥメッセージとしての最初の行のリクエストＵＲＩ（１０．１．１．１０）がＩＰセントレックスサーバ１６のＩＰアドレスに書換えられ、Ｖｉａヘッダについてはバックアップ装置１０のＩＰアドレスを示す１行が追加され、ＦｒｏｍヘッダとＴｏヘッダのホスト部がＩＰセントレックスサーバ１６のＩＰアドレスに書き換えられ、さらにＣｏｎｔａｃｔヘッダのホスト部がバックアップ装置１０のＩＰアドレスに書き換えられている。なお、ここでＶｉａヘッダが１行追加される理由は、このメッセージに対する応答メッセージを受け取った時点で処理を容易にするためであり、例えばこの応答メッセージを受け取った時点で、追加されたＶｉａヘッダは削除される。
【００６０】
図１１は、セントレックスサーバが正常動作を行っている場合の書換えの具体例の説明図である。ここではＩＰセントレックスサーバ１６から送られ、拠点内部のＩＰ電話端末に送信されるべきインバイトメッセージの書換えの具体例が示されている。すなわちソースアドレスはＩＰセントレックスサーバ１６のＩＰアドレスからバックアップ装置１０のアドレスに書き換えられ、またデスティネーションアドレスはバックアップ装置１０のアドレスから電話端末１２2のアドレスに書き換えられている。同様にリクエストＵＲＩは端末１２2のアドレスに書き換えられ、Ｖｉａヘッダの１行目以下ではバックアップ装置１０のＩＰアドレスが用いられている。
【００６１】
図１２はセントレックスサーバの障害発生時におけるＩＰ電話端末１２1から送られたインバイトメッセージの書換えの具体例であり、ＩＰセントレックスサーバ１６に障害が発生していない図１１の書換え結果と全く同じになっている。従ってこのメッセージを受け取ったＩＰ電話端末１２2側ではＩＰセントレックスサーバ１６の障害発生を意識することなく、拠点内部の他の端末からのインバイトメッセージを受け取ることが可能となる。
【００６２】
次に図６のＳＩＰメッセージ生成部２６の動作についてさらに説明する。ＳＩＰメッセージ生成部２６は、ＳＩＰメッセージ読取部２４からＳＩＰメッセージと共に、メッセージの送信先アドレスと新しいメッセージに格納すべきＳＩＰのコードとを受け取り、これらのデータを用いて新たなＳＩＰメッセージを生成し、そのメッセージを送信先アドレスに対して送信するものである。これによって前述のように拠点の外部からＩＰセントレックスサーバ１６を介して入力されたＳＩＰメッセージの送信先が拠点内に存在しない場合には、それを示すコードが格納された新しいＳＩＰメッセージが生成されてＩＰセントレックスサーバ１６に送信され、またＩＰセントレックスサーバ１６に障害が発生し、例えば同一端末からの５回以上の連続的なレジスタメッセージの送信に対応する応答がＩＰセントレックスサーバ１６から行われないような場合に、そのレジスタメッセージに対応するエンド・ポイントの登録が行われたことを示す新たなメッセージが作成されて、そのレジスタメッセージの送信元のＩＰ電話端末に送られることになる。
【００６３】
最後に本実施形態におけるメッセージの転送シーケンスについて図１３から図１５を用いて説明する。図１３はセントレックスサーバが正常動作を行っている場合の、インバイトメッセージに対応するメッセージ転送シーケンスの説明図である。同図において端末１２1から新たなセッションの開始を要求するインバイトメッセージがバックアップ装置１０を介してＩＰセントレックスサーバ１６に送られると、それに対する応答としての１００ＴＲＹＩＮＧメッセージがＩＰセントレックスサーバ１６からバックアップ装置１０に、さらにバックアップ装置１０から端末１２1に送られると共に、ＩＰセントレックスサーバ１６からバックアップ装置１０に対してインバイトメッセージが送られる。このインバイトメッセージに対応してバックアップ装置１０から端末１２2に対してインバイトメッセージが送られ、そのインバイトメッセージに対する応答としての１００ＴＲＹＩＮＧメッセージが端末１２2からバックアップ装置１０に対してと、さらにバックアップ装置１０からＩＰセントレックスサーバ１６に送られて新たなセッションが正常に開始されることになる。
【００６４】
ただし、ＳＩＰメッセージをＩＰ電話端末に転送するためには、その電話端末に関するデータが必要となる。このデータはＩＰ電話端末の電源投入時にＩＰセントレックスサーバ１６側に送信されるレジスタメッセージや、呼の開始のために送信されるインバイトメッセージの内容から得られ、前述のようにエンド・ポイント・テーブル２３に端末に関するデータが登録される。この登録されたデータを用いて図１３に説明した動作が実行される。
【００６５】
図１４、および図１５はＩＰセントレックスサーバ１６に障害が発生した場合のＳＩＰメッセージの転送シーケンスの説明図である。図１４は、セッションに対する（イニシャル）インバイトメッセージの転送シーケンスの説明図である。本実施形態においては前述のように、レジスタメッセージだけでなく、セッションに対するインバイトメッセージが５回以上連続してセントレックスサーバに送られ、セントレックスサーバ側から応答がない場合には、ＩＰセントレックスサーバ１６に障害が発生したものとして、バックアップ装置１０は端末１２1から送られたメッセージを直接に通信相手側の端末１２2に送信する。
【００６６】
すなわち図１４においてインバイトメッセージが５回連続してバックアップ装置１０を介してＩＰセントレックスサーバ１６に転送され、ＩＰセントレックスサーバ１６側から応答がない場合には６回目のインバイトメッセージに対応して、バックアップ装置１０から通信相手側の端末１２2にインバイトメッセージが直接に送られ、端末１２2からそれに対する応答としての１００ＴＲＹＩＮＧメッセージがバックアップ装置１０を介して端末１２1側に送られてセッションが開始される。
【００６７】
そしてこの呼については、図６のアクティブ・コール・テーブル２２に呼に関するデータが保持されているためにインバイト、あるいはレジスタ以外のＳＩＰメッセージについてはＩＰセントレックスサーバ１６を経由することなく、直接に通信相手側の電話端末１２2との間でメッセージの転送が行われることになる。
【００６８】
図１５はレジスタメッセージの転送シーケンスの説明図である。同図においては、端末１２1からレジスタメッセージがＩＰセントレックスサーバ１６に対して５回送信されたにもかかわらず、応答が得られないため６回目のレジスタメッセージの送信に対して、バックアップ装置１０はエンド・ポイントの登録が終了したことを示す２００ＯＫのコードを持つメッセージを生成して端末１２1に送信することにより、端末１２1側では少なくともその後の拠点内部での端末相互間の通話が可能であることを認識することができる。
【００６９】
一般にＩＰ電話端末は、このレジスタメッセージを定期的に送信する機能を持つ。例えばその送信間隔は３６００秒とされている。端末によってはこのレジスタメッセージの処理が正常に行われない場合には動作が不可能となるものもある。ＩＰセントレックスサーバ１６に障害が発生した場合に、バックアップ装置１０が２００ＯＫというコードを持つＳＩＰメッセージを新たに生成し、ＩＰ電話端末に対して応答することによってＩＰ電話端末の動作の保証も行われることになる。
【００７０】
（付記１）  ネットワークに接続された複数の電話端末と、該ネットワークの内部の端末相互間、および外部との通話の切換接続を行うサーバとの間に位置し、該サーバのバックアップを行うサーババックアップ装置であって、
前記サーバの障害を検出するサーバ障害検出手段と、
該障害の発生の期間中に、前記ネットワーク内の端末間の通信のために端末側から送られる所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、該メッセージを前記サーバを経由することなく、相手側端末に直接に転送するメッセージ転送手段とを備えることを特徴とするサーババックアップ装置。
【００７１】
（付記２）  前記バックアップ装置において、前記複数の電話端末のそれぞれに対応して、端末の識別子としてのエンド・ポイントの名称と、端末のアドレスとを記憶するエンド・ポイント記憶手段をさらに備え、
前記メッセージ転送手段が、該エンド・ポイント記憶手段の記憶内容に基いてメッセージの転送を行うことを特徴とする付記１記載のサーババックアップ装置。
【００７２】
（付記３）  前記所定のメッセージが、前記端末側から通信相手端末側に呼の確立を要求するために送信されるインバイトメッセージであることを特徴とする付記１記載のサーババックアップ装置。
【００７３】
（付記４）  ネットワークに接続された複数の電話端末と、該ネットワークの内部の端末相互間、および外部との通話の切換接続を行うサーバとの間に位置し、該サーバのバックアップを行うサーババックアップ装置であって、
前記サーバの障害を検出するサーバ障害検出手段と、
該障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメッセージに対応して該メッセージに対する応答メッセージを生成し、該応答メッセージを前記所定のメッセージの送信元端末に送信するメッセージ生成手段とを備えることを特徴とするサーババックアップ装置。
【００７４】
（付記５）  前記所定のメッセージは、端末側から自端末の登録のために送信されるレジスタメッセージであることを特徴とする付記４記載のサーババックアップ装置。
（付記６）  前記サーババックアップ装置において、同一端末からの前記所定のメッセージの受信回数を記憶する所定メッセージ受信回数記憶手段をさらに備え、
前記サーバ障害検出手段が、該記憶されたメッセージの受信回数があらかじめ定められた数を超えたとき、前記サーバの障害を検出することを特徴とする付記１、または４記載のサーババックアップ装置。
【００７５】
（付記７）  ネットワークに接続された複数の電話端末と、該ネットワーク内部の端末相互間、および外部との通話の切換接続を行うサーバのバックアップを行う方法であって、
同一端末からの所定のメッセージの受信回数を監視してサーバの障害を検出し、
該サーバ障害の発生期間中に、前記ネットワーク内の端末間の通信のために端末側から送られる所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレスに書き換えて、該メッセージを前記サーバを経由することなく相手側端末に直接に転送することを特徴とするサーババックアップ方法。
【００７６】
（付記８）  ネットワークに接続された複数の電話端末と、該ネットワーク内部の端末相互間、および外部との通話の切換接続を行うサーバのバックアップを行う方法であって、
同一端末からの所定のメッセージの受信回数を監視してサーバの障害を検出し、
該サーバ障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメッセージに対応して、該メッセージに対する応答メッセージを生成し、該応答メッセージを前記所定のメッセージの送信元端末に送信することを特徴とするサーババックアップ方法。
【産業上の利用可能性】
【００７７】
本発明は、例えばセントレックスサービスを提供する通信事業者は当然のこととして、そのようなサービスを享受するすべての産業において利用可能である。
【図面の簡単な説明】
【００７８】
【図１】本発明のサーババックアップ装置の原理構成ブロック図である。
【図２】本発明のバックアップ装置が用いられるシステムの全体構成を示すブロック図である。
【図３】図２におけるサーバ正常時、および障害時の動作の説明図である。
【図４】セントレックスサーバ正常動作時の端末相互間通話の説明図である。
【図５】セントレックスサーバ障害時の端末相互間通話の説明図である。
【図６】図２のバックアップ装置の詳細構成ブロック図である。
【図７】アクティブ・コール・テーブルの格納内容の説明図である。
【図８】エンド・ポイント・テーブルの格納内容の説明図である。
【図９】レジスタメッセージの具体例を示す図である。
【図１０】セントレックスサーバ正常動作時のメッセージの書換えの具体例（その１）の説明図である。
【図１１】セントレックスサーバ正常動作時のメッセージの書換えの具体例（その２）の説明図である。
【図１２】セントレックスサーバ障害発生時のメッセージ書き換え例の説明図である。
【図１３】セントレックスサーバ正常動作時のインバイトメッセージに対するメッセージ転送シーケンスの説明図である。
【図１４】セントレックスサーバ障害発生時のインバイトメッセージに対するメッセージ転送シーケンスの説明図である。
【図１５】セントレックスサーバ障害発生時のレジスタメッセージに対するメッセージ転送シーケンスの説明図である。
【符号の説明】
【００７９】
１、１０  サーババックアップ装置
２  サーバ障害検出手段
３  メッセージ転送手段
１１  拠点Ａ
１２1、１２2．．  ＩＰ電話端末
１３  ローカルエリアネットワーク
１４  ルータ
１５  ＩＰネットワーク
１６  ＩＰセントレックスサーバ
２１  呼状態管理部
２２  アクティブ・コール・テーブル
２３  エンド・ポイント・テーブル
２４  ＳＩＰメッセージ読取部
２５  ＳＩＰメッセージ書換え部
２６  ＳＩＰメッセージ生成部
【図１】
2005229273.tif 000003
【図２】
2005229273.tif 000004
【図３】
2005229273.tif 000005
【図４】
2005229273.tif 000006
【図５】
2005229273.tif 000007
【図６】
2005229273.tif 000008
【図７】
2005229273.tif 000009
【図８】
2005229273.tif 000010
【図９】
2005229273.tif 000011
【図１０】
2005229273.tif 000012
【図１１】
2005229273.tif 000013
【図１２】
2005229273.tif 000014
【図１３】
2005229273.tif 000015
【図１４】
2005229273.tif 000016
【図１５】
2005229273.tif 000017