通信装置及び異常復旧方法
【課題】プログラムに異常が発生した場合に、人手を介することなく、低コストでプログラムの異常に対し効果的に対処し得る通信装置を提供する。
【解決手段】端末Ｔ１１において、発着信時に得られる制御信号を利用して機器情報を取得してＥＰＲＯＭ１１４のテーブル１１４１に記録し、プログラムの異常により起動できない場合に、ＥＰＲＯＭ１１４のテーブル１１４１に基づいて他の端末からプログラムを取得して起動するようにしている。
【解決手段】端末Ｔ１１において、発着信時に得られる制御信号を利用して機器情報を取得してＥＰＲＯＭ１１４のテーブル１１４１に記録し、プログラムの異常により起動できない場合に、ＥＰＲＯＭ１１４のテーブル１１４１に基づいて他の端末からプログラムを取得して起動するようにしている。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えばＩＰ(Internet Protocol)電話システムで用いられる通信装置、及びこの通信装置で発生する動作異常に対する異常復旧実行方法に関する。
【背景技術】
【０００２】
近年、ＩＰ電話システムが普及し始めている。このＩＰ電話システムでは、例えばＬＡＮ(Local Area Network)やインターネットを含むＩＰ網にＩＰ電話端末を接続すると共に、ＩＰ網上の交換サーバにおいてプロトコル変換及びデータのフォーマット変換等を行うことにより、ＩＰ電話端末間及びＩＰ電話端末と一般電話網との間で音声通信を可能にしている。
【０００３】
ところで、上記交換サーバやＩＰ電話端末にあっては、プログラム中の異常が発生することが十分に予想される。このような場合、保守員が異常なプログラムを正常なプログラムに書き替える等の復旧作業を行うが、プログラム変更以外に、コストアップの要因にもなる。
【０００４】
なお、従来では、電源投入時に記憶部のクライアントモジュールの状態を診断し、異常を認識したときはサーバにクライアントモジュールのダウンロードを要求する技術が提案されている（例えば、特許文献１）。
【特許文献１】２００４−７８８４９公報。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記ＩＰ電話システムにあっても、上記交換サーバやＩＰ電話端末におけるプログラム中の異常発生に伴って保守員の手作業を介することなく自動的にプログラムを修復する手法が強く望まれている。しかしながら、この手法については、まだ検討段階であって実現されていないのが現状である。
【０００６】
そこで、この発明の目的は、プログラムに異常が発生した場合に、人手を介することなく、低コストでプログラムの異常に対し効果的に対処し得る通信装置及び異常復旧方法を提供することにある。
【課題を解決するための手段】
【０００７】
この発明に係る通信装置は、第１の記録媒体に記憶されたプログラムに基づいて起動し、通信処理を実行する通信装置において、第１の記録媒体に記憶されたプログラムと同一のプログラムを有する通信機器を示す機器情報を選択的に取得して第１の記録媒体とは異なる第２の記録媒体に記録する取得手段と、第１の記録媒体に記憶されたプログラムにより起動できない場合に、第２の記録媒体に記録された機器情報に基づいて、該当する通信機器からプログラムを取得して当該プログラムに基づいて起動する障害復旧手段とを備えるようにしたものである。なお、取得手段は、機器情報を通信時に取得する。
【０００８】
この構成によれば、通信時に得られる制御信号を利用して機器情報が選択的に取得されて第２の記録媒体に記録され、プログラムの異常により起動できない場合に、第２の記録媒体中の機器情報に基づいて他の通信機器からプログラムが取得されて正常に起動される。
【０００９】
従って、プログラムのバックアップ領域を持つ必要がないため、機器のコストを抑えることができ、これによりプログラムに異常が発生した場合に、保守員の手操作を介することなく、低コストでプログラムの異常に対し効果的に対処することができる。また、予めネットワーク上にプログラムを格納するサーバを設置する必要がないため、管理コストが軽減される。
【００１０】
また、上記取得手段は、通信中に通信相手から取得する機器情報に基づいて通信相手のプログラムバージョンが第１の記録媒体に記録されるプログラムと同一であるか否かを判断し、同一である場合に、通信相手の機器情報をプログラム取得先候補として自動的に第２の記録媒体に記録することを特徴とする。
【００１１】
この構成によれば、通信中に通信相手から取得する機器情報に基づいて通信相手のプログラムバージョンが第１の記録媒体に記録されるプログラムと同一であるか否かが判断され、同一である場合のみ、通信相手の機器情報がプログラム取得先候補として自動的に第２の記録媒体に記録されるので、通信相手ごとに適切なプログラムの取得が可能となる。
【００１２】
また、上記取得手段は、プログラムバージョンが第１の記録媒体に記録されるプログラムと同一である複数候補の機器情報を第２の記録媒体に記録することを特徴とする。
【００１３】
この構成によれば、プログラムバージョンが第１の記録媒体に記録されるプログラムと同一のプログラム取得先を多く選択することができるので、プログラム取得先への接続上の信頼性をさらに高めることができる。
【００１４】
さらに、予め決められた条件に従って、第２の記録媒体上の複数候補の機器情報の選定順番を置き換える候補選定手段を備える。なお、この条件の判断に、通信時に経由するルータ数、通信相手までの往復遅延の少なくとも１つを用い、ルータ数が少ない順または通信相手までの往復遅延が短い順に第２の記録媒体上の複数候補の機器情報を置き換える。
【００１５】
この構成によれば、自装置から近い順にプログラム取得先が選択されることになり、これにより、例えば広域ネットワークをプログラム取得のために占有しなくて済む。
【発明の効果】
【００１６】
以上詳述したようにこの発明によれば、プログラムに異常が発生した場合に、人手を介することなく、低コストでプログラムの異常に対し効果的に対処し得る通信装置及び異常復旧方法を提供することができる。
【発明を実施するための最良の形態】
【００１７】
以下、この発明の実施形態について図面を参照して詳細に説明する。
（第１の実施形態）
図１は、この発明の第１の実施形態に係わるＩＰマルチメディア交換システムを示す概略構成図である。
このシステムは、映像信号やコンピュータデータ等を伝送するための広域ネットワーク１を有する。広域ネットワーク１には、ルータＲ１〜Ｒ３が接続されている。
【００１８】
また、このシステムでは、４つの拠点のローカルエリアネットワーク（ＬＡＮ）Ｌ１〜Ｌ４が、ルータＲ１〜Ｒ３を介して相互に接続され、それぞれの拠点に交換サーバＳ１〜Ｓ４と端末Ｔ１１〜Ｔ１３、Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２が配置されているものとする。ここで、交換サーバＳ１〜Ｓ４は、例えばＩＰ−ＰＢＸなどが使用される。また、端末Ｔ１１〜Ｔ１３、Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２には、音声や映像といったマルチメディアを扱うＩＰ電話機やテレビ電話機などが使用される。
【００１９】
交換サーバＳ１は、ローカルエリアネットワークＬ１上の端末Ｔ１１〜Ｔ１３相互間もしくは端末Ｔ１１〜Ｔ１３と広域ネットワーク１との間の交換制御機能を有している。交換サーバＳ２〜Ｓ４も、交換サーバＳ１と同様に、端末Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２に対する交換制御機能を有している。
【００２０】
図２は、交換サーバＳ１〜Ｓ４や端末Ｔ１１〜Ｔ１３、Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２の概略ブロック図である。ここでは、端末Ｔ１１を代表して説明する。
【００２１】
端末Ｔ１１は、ＣＰＵ１１１と、主記憶部１１２と、フラッシュメモリ１１３と、ＥＰＲＯＭ１１４とを備えている。ここで、ＥＰＲＯＭ１１４はフラッシュメモリの領域の一部を使って代用してもよい。フラッシュメモリ１１３は、主にプログラム（ファームウェア）を格納するために用いられ、また、プログラムを起動するためのブートローダーが別に格納されている。
【００２２】
図３に、一般的なフラッシュメモリ１１３のメモリ構造を示す。ここで、ブートローダー（Ｍ１）は、工場出荷時に一度だけ書き込まれ、運用中に書き換えられることはない。一方、プログラム（ファームウェア）部（Ｍ２）は、機能の追加や不具合の修正等の理由により、運用中に書き換えられることがある。
【００２３】
ＥＰＲＯＭ１１４には、図４に示すように、緊急時のプログラム取得先格納テーブル１１４１が格納される。本テーブル１１４１には、プログラムの起動に失敗した場合に、プログラムの取得先となる機器のＩＰアドレスが優先度順に格納されている。本実施形態では、第一優先度から第三優先度までとしたが、この数は任意である。このように複数の候補を持つことで、プログラムの起動失敗時に救済の可能性が高まることとなる。また、テーブルには優先度を決定するためのメトリクス情報が格納される。本実施形態では、メトリクスとして自らと、プログラム取得先候補となる機器との間のルータ段数を採用している。ここで、値０は、両者が同じＬＡＮ（ＩＰサブネット）に属しており間にルータＲ１〜Ｒ３が存在しないことを表す。
【００２４】
ＣＰＵ１１１は、通常動作モードの時に、フラッシュメモリ１１３に格納されたプログラムに基づいて当該端末Ｔ１１の各部を総括制御することで端末Ｔ１１としての動作を実現する。また、ＣＰＵ１１１は、プログラム書き換えモード時に、フラッシュメモリ１１３に格納されたブートローダに基づいてプログラムの書き換えを行う。
【００２５】
また、ＣＰＵ１１１は、本発明に係る機能として、機器情報取得部１１１１と、障害対応部１１１２と、候補選定部１１１３とを備えている。機器情報取得部１１１１は、発着信時に、通話相手となる端末Ｔ２１からの制御情報に含まれる機器情報を取得し、この機器情報から同一のプログラムバージョンであるか否かを判定し、同一のプログラムバージョンである場合に、機器情報をＥＰＲＯＭ１１４上のプログラム取得先格納テーブル１１４１に記録する。
【００２６】
障害対応部１１１２は、フラッシュメモリ１１３に格納されたプログラムにより起動できない場合に、ＥＰＲＯＭ１１４に記録されたプログラム取得先格納テーブル１１４１に基づいて、該当する端末Ｔ２１からプログラムを取得して当該プログラムに基づいて起動する。
【００２７】
候補選定部１１１３は、通信時に経由するルータＲ１〜Ｒ３の数に基づいて、ＥＰＲＯＭ１１４上のプログラム取得先格納テーブル１１４１のプログラム取得先候補の選定順番の入れ替えを行う。
【００２８】
次に、上記構成における動作について説明する。
図５は、端末Ｔ１１の起動処理手順を示すフローチャートである。端末Ｔ１１に対して電源が投入される、あるいは、リセットが実施されると（ステップＳＴ５ａ）、ＣＰＵ１１１はブートローダーが起動しフラッシュメモリ１１３のプログラム格納領域からアプリケーションプログラムを読み出し、処理をブートローダーからアプリケーションプログラムへ移す作業を行う（ステップＳＴ５ｂ）。
【００２９】
ここで、異常が発生した場合、ＣＰＵ１１１はステップＳＴ５ｃからステップＳＴ５ｄに移行してここでブートローダーがＥＰＲＯＭ１１４のテーブル１１４１にアクセスし、最も優先度の高いプログラム取得先候補のアドレスを読み出す。
【００３０】
データが取得できた場合は、ＣＰＵ１１１はステップＳＴ５ｅからステップＳＴ５ｆに移行してここで該アドレスに対して自らのバージョンのプログラム取得要求を行う。取得方法としては、ＴＦＴＰを用いるのが一般的である。そして、プログラム取得に成功した場合は、ＣＰＵ１１１はステップＳＴ５ｇからステップＳＴ５ｈに移行してここでそれをプログラム領域に書き込んだ上で起動処理を継続する（ステップＳＴ５ｉ）。
【００３１】
一方、上記ステップＳＴ５ｇにおいてプログラム取得に失敗した場合は、ＣＰＵ１１１はテーブル１１４１から次の優先度の取得先候補を読み出し（ステップＳＴ５ｊ）、該候補に対して取得要求を行う。本処理は、プログラムの取得に成功するか、あるいは、テーブル１１４１に登録された全ての候補に対する要求が失敗するまで繰り返される。
【００３２】
なお、上記ステップＳＴ５ｃにおいて、異常が発生しない場合には、ＣＰＵ１１１はステップＳＴ５ｉにそのまま移行し、さらに、上記ステップＳＴ５ｅにおいてテーブル１１４１中にデータが無い場合には、起動失敗として処理をそのまま終了する（ステップＳＴ５ｋ）。
【００３３】
図６及び図７は、端末Ｔ１１及び端末Ｔ３１がテーブル１１４１を更新する際のフローチャートである。
【００３４】
発側となる端末Ｔ１１は、発信操作時に制御信号に対して自端末のプログラムバージョンを設定し、交換サーバＳ１に対して制御パケット送信する（ステップＳＴ６ａ〜ステップＳＴ６ｃ）。
【００３５】
一方、応答側となる端末Ｔ３１は、同様に、応答操作時に応答信号に対して自端末のプログラムバージョンを設定し、交換サーバに対して制御パケットを送信する（ステップＳＴ７ａ〜ステップＳＴ７ｃ）。実現例の一つとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によるＩＰ電話相互通話を考える。発側の端末Ｔ１１は、ＳＩＰ Ｉｎｖｉｔｅメッセージを送信するが、Ｉｎｖｉｔｅメッセージに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のテキストフィールドにプログラムバージョンを含めるようにする。同様に、応答端末Ｔ３１は、ＳＩＰ ２００ ＯＫメッセージに含まれるＳＤＰのテキストフィールドにプログラムバージョンを含めるようにすればよい。
【００３６】
図８は、端末Ｔ１１と端末Ｔ３３との間の通信中にテーブル１１４１にプログラム取得先候補を登録する動作を示すシーケンス図である。
【００３７】
いま、端末Ｔ１１から端末Ｔ３３に発信し、相互に通話を行うとする。ここで、端末Ｔ１１から端末Ｔ３３までのルータ段数は２であるため、端末Ｔ１１は端末Ｔ３３に対するメトリクスとして２を得る。テーブル１１４１の登録状態から、優先度３の候補に対するメトリクスが３であるため、端末Ｔ１１は、優先度３の候補として端末Ｔ３３のＩＰアドレスを前記メトリクスと共にテーブル１１４１に登録する（書き換える）。
【００３８】
以上のように上記第１の実施形態では、端末Ｔ１１において、発着信時に得られる制御信号を利用して機器情報を取得してＥＰＲＯＭ１１４のテーブル１１４１に記録し、プログラムの異常により起動できない場合に、ＥＰＲＯＭ１１４のテーブル１１４１に基づいて他の端末Ｔ２２からプログラムを取得して起動するようにしている。
【００３９】
従って、プログラムのバックアップ領域を持つ必要がないため、機器のコストを抑えることができ、これによりプログラムに異常が発生した場合に、保守員の手操作を介することなく、低コストでプログラムの異常に対し効果的に対処することができる。また、予めネットワーク上にプログラムを格納するサーバを設置する必要がないため、管理コストが軽減される。
【００４０】
また、上記第１の実施形態では、テーブル１１４１中に多くのプログラム取得先候補を登録することができるので、プログラム異常発生時に、プログラム取得先を多く選択することができ、これによりプログラム取得先への接続上の信頼性をさらに高めることができる。
【００４１】
（第２の実施形態）
図９は、この発明の第２の実施形態として、端末Ｔ１１と端末Ｔ３１との間で通話中になった際のテーブル１１４１を更新する際のフローチャートである。
【００４２】
通話に至った後、発側と応答側の何れの端末Ｔ１１，Ｔ３１も、相手から受け取った制御パケットから相手端末のバージョン情報を取り出し（ステップＳＴ９ａ）、自端末のバージョンと一致するか比較する（ステップＳＴ９ｂ）。
【００４３】
ここで両者のバージョンが一致する場合、通話相手端末が起動失敗時のプログラム取得先候補となりうる。本発明では、ここからさらに相手端末との間のネットワーク的な近さを類推して、より近い端末を候補端末とするようルータホップ数の計測を行う（ステップＳＴ９ｃ）。これにより、より安定的にプログラムの取得が可能となる。ホップ数の計測には、ＩＣＭＰを使う。良く知られているＴｒａｃｅｒｏｕｔｅコマンドのように、ホップ上限数を１から一つずつ増やしながら、最終的に相手端末に到達するまで繰り返すことにより、両端末間のルータ段数を計測する。ここで得られたメトリクス（ルータ段数）が、既にテーブルに登録されたものより小さければ、ステップＳＴ９ｄからステップＳＴ９ｅに移行してここで段数に応じた優先度でもってテーブル１１４１を書き換える。
【００４４】
一方、得られたメトリクスが既に登録済みの候補と同じか、または、大きい場合はテーブル１１４１の更新を行わない（ステップＳＴ９ｆ）。
【００４５】
また、上記ステップＳＴ９ｂにおいて、自端末のバージョンと一致しない場合、端末Ｔ１１，Ｔ３１は、処理を行わない（ステップＳＴ９ｇ）。
【００４６】
以上のように上記第２の実施形態では、端末Ｔ１１において、通信時に経由するルータＲ１〜Ｒ３の数が小さい順にＥＰＲＯＭ１１４上のテーブル１１４１のプログラム取得先候補の選定順番を書き替えるようにしているので、自端末Ｔ１１から近い順にプログラム取得先が選択されることになり、これにより、例えば広域ネットワーク１をプログラム取得のために占有しなくて済むとともに、プログラムが第三者に漏れたり改竄されたりすることなく安全に取得することができる。
【００４７】
また、上記第２の実施形態では、端末Ｔ１１，Ｔ３１において、通信中に通信相手のプログラムバージョンがフラッシュメモリ１１３に記録されるプログラムと同一であるか否かを判定し、同一である場合のみ、通信相手をプログラム取得先候補として自動的にＥＰＲＯＭ１１４のテーブル１１４１に登録するようにしているので、通信相手ごとに適切なプログラムの取得が可能となる。
【００４８】
（その他の実施形態）
この発明は、上記各実施形態に限定されるものではない。例えば上記第１及び第２の実施形態では、通信中に経由するルータの数によりプログラム取得先候補の選定順番を書き換えるようにした。しかしこれに限ることなく、例えば通信相手までの往復遅延等、ネットワークの近さを表す情報を用いるようにしてもよい。
【００４９】
また、上記第１の実施形態では、発着信時に通信相手からバージョン情報等を取得する例について説明したが、通常運用時の例えば稼働が少ない時間に通信相手からバージョン情報を取得するようにしてもよい。また、通信時以外に、例えば汎用コンピュータまたは可搬メディアを接続した際に、この汎用コンピュータまたは可搬メディア上に登録されている各端末のバージョン情報を取得するようにしてもよい。
【００５０】
その他、ＩＰ電話システムの構成及び種類、交換サーバ及びマルチメディア端末の機能構成や種類、プログラムバージョン情報の取得手順等についても、この発明の要旨を逸脱しない範囲で種々変形して実施できる。
【図面の簡単な説明】
【００５１】
【図１】この発明の第１の実施形態に係わるＩＰマルチメディア交換システムを示す概略構成図。
【図２】上記図１に示した交換サーバ及び端末の概略ブロック図。
【図３】上記図２に示したフラッシュメモリのメモリ構造を示す図。
【図４】上記図２に示したＥＰＲＯＭに格納されるプログラム取得先格納テーブルの記憶内容の一例を示す図。
【図５】同第１の実施形態において、端末の起動処理手順を示すフローチャート。
【図６】同第１の実施形態において、発側の端末のプログラム取得先格納テーブルの更新手順を示すフローチャート。
【図７】同第１の実施形態において、着側の端末のプログラム取得先格納テーブルの更新手順を示すフローチャート。
【図８】同第１の実施形態において、端末間の通信中にプログラム取得先格納テーブルにプログラム取得先候補を登録する動作を示すシーケンス図。
【図９】この発明の第２の実施形態として、端末間で通話中になった際のプログラム取得先格納テーブルを更新する手順を示すフローチャート。
【符号の説明】
【００５２】
１…広域ネットワーク、１１１…ＣＰＵ、１１２…主記憶部、１１３…フラッシュメモリ、１１４…ＥＰＲＯＭ、１１１１…機器情報取得部、１１１２…障害対応部、１１１３…候補選定部、１１４１…プログラム取得先格納テーブル、Ｌ１〜Ｌ４…ローカルエリアネットワーク、Ｓ１〜Ｓ４…交換サーバ、Ｔ１１〜Ｔ１３，Ｔ２１〜Ｔ２３，Ｔ３１〜Ｔ３３…マルチメディア端末、Ｒ１〜Ｒ３…ルータ。
【技術分野】
【０００１】
この発明は、例えばＩＰ(Internet Protocol)電話システムで用いられる通信装置、及びこの通信装置で発生する動作異常に対する異常復旧実行方法に関する。
【背景技術】
【０００２】
近年、ＩＰ電話システムが普及し始めている。このＩＰ電話システムでは、例えばＬＡＮ(Local Area Network)やインターネットを含むＩＰ網にＩＰ電話端末を接続すると共に、ＩＰ網上の交換サーバにおいてプロトコル変換及びデータのフォーマット変換等を行うことにより、ＩＰ電話端末間及びＩＰ電話端末と一般電話網との間で音声通信を可能にしている。
【０００３】
ところで、上記交換サーバやＩＰ電話端末にあっては、プログラム中の異常が発生することが十分に予想される。このような場合、保守員が異常なプログラムを正常なプログラムに書き替える等の復旧作業を行うが、プログラム変更以外に、コストアップの要因にもなる。
【０００４】
なお、従来では、電源投入時に記憶部のクライアントモジュールの状態を診断し、異常を認識したときはサーバにクライアントモジュールのダウンロードを要求する技術が提案されている（例えば、特許文献１）。
【特許文献１】２００４−７８８４９公報。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記ＩＰ電話システムにあっても、上記交換サーバやＩＰ電話端末におけるプログラム中の異常発生に伴って保守員の手作業を介することなく自動的にプログラムを修復する手法が強く望まれている。しかしながら、この手法については、まだ検討段階であって実現されていないのが現状である。
【０００６】
そこで、この発明の目的は、プログラムに異常が発生した場合に、人手を介することなく、低コストでプログラムの異常に対し効果的に対処し得る通信装置及び異常復旧方法を提供することにある。
【課題を解決するための手段】
【０００７】
この発明に係る通信装置は、第１の記録媒体に記憶されたプログラムに基づいて起動し、通信処理を実行する通信装置において、第１の記録媒体に記憶されたプログラムと同一のプログラムを有する通信機器を示す機器情報を選択的に取得して第１の記録媒体とは異なる第２の記録媒体に記録する取得手段と、第１の記録媒体に記憶されたプログラムにより起動できない場合に、第２の記録媒体に記録された機器情報に基づいて、該当する通信機器からプログラムを取得して当該プログラムに基づいて起動する障害復旧手段とを備えるようにしたものである。なお、取得手段は、機器情報を通信時に取得する。
【０００８】
この構成によれば、通信時に得られる制御信号を利用して機器情報が選択的に取得されて第２の記録媒体に記録され、プログラムの異常により起動できない場合に、第２の記録媒体中の機器情報に基づいて他の通信機器からプログラムが取得されて正常に起動される。
【０００９】
従って、プログラムのバックアップ領域を持つ必要がないため、機器のコストを抑えることができ、これによりプログラムに異常が発生した場合に、保守員の手操作を介することなく、低コストでプログラムの異常に対し効果的に対処することができる。また、予めネットワーク上にプログラムを格納するサーバを設置する必要がないため、管理コストが軽減される。
【００１０】
また、上記取得手段は、通信中に通信相手から取得する機器情報に基づいて通信相手のプログラムバージョンが第１の記録媒体に記録されるプログラムと同一であるか否かを判断し、同一である場合に、通信相手の機器情報をプログラム取得先候補として自動的に第２の記録媒体に記録することを特徴とする。
【００１１】
この構成によれば、通信中に通信相手から取得する機器情報に基づいて通信相手のプログラムバージョンが第１の記録媒体に記録されるプログラムと同一であるか否かが判断され、同一である場合のみ、通信相手の機器情報がプログラム取得先候補として自動的に第２の記録媒体に記録されるので、通信相手ごとに適切なプログラムの取得が可能となる。
【００１２】
また、上記取得手段は、プログラムバージョンが第１の記録媒体に記録されるプログラムと同一である複数候補の機器情報を第２の記録媒体に記録することを特徴とする。
【００１３】
この構成によれば、プログラムバージョンが第１の記録媒体に記録されるプログラムと同一のプログラム取得先を多く選択することができるので、プログラム取得先への接続上の信頼性をさらに高めることができる。
【００１４】
さらに、予め決められた条件に従って、第２の記録媒体上の複数候補の機器情報の選定順番を置き換える候補選定手段を備える。なお、この条件の判断に、通信時に経由するルータ数、通信相手までの往復遅延の少なくとも１つを用い、ルータ数が少ない順または通信相手までの往復遅延が短い順に第２の記録媒体上の複数候補の機器情報を置き換える。
【００１５】
この構成によれば、自装置から近い順にプログラム取得先が選択されることになり、これにより、例えば広域ネットワークをプログラム取得のために占有しなくて済む。
【発明の効果】
【００１６】
以上詳述したようにこの発明によれば、プログラムに異常が発生した場合に、人手を介することなく、低コストでプログラムの異常に対し効果的に対処し得る通信装置及び異常復旧方法を提供することができる。
【発明を実施するための最良の形態】
【００１７】
以下、この発明の実施形態について図面を参照して詳細に説明する。
（第１の実施形態）
図１は、この発明の第１の実施形態に係わるＩＰマルチメディア交換システムを示す概略構成図である。
このシステムは、映像信号やコンピュータデータ等を伝送するための広域ネットワーク１を有する。広域ネットワーク１には、ルータＲ１〜Ｒ３が接続されている。
【００１８】
また、このシステムでは、４つの拠点のローカルエリアネットワーク（ＬＡＮ）Ｌ１〜Ｌ４が、ルータＲ１〜Ｒ３を介して相互に接続され、それぞれの拠点に交換サーバＳ１〜Ｓ４と端末Ｔ１１〜Ｔ１３、Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２が配置されているものとする。ここで、交換サーバＳ１〜Ｓ４は、例えばＩＰ−ＰＢＸなどが使用される。また、端末Ｔ１１〜Ｔ１３、Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２には、音声や映像といったマルチメディアを扱うＩＰ電話機やテレビ電話機などが使用される。
【００１９】
交換サーバＳ１は、ローカルエリアネットワークＬ１上の端末Ｔ１１〜Ｔ１３相互間もしくは端末Ｔ１１〜Ｔ１３と広域ネットワーク１との間の交換制御機能を有している。交換サーバＳ２〜Ｓ４も、交換サーバＳ１と同様に、端末Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２に対する交換制御機能を有している。
【００２０】
図２は、交換サーバＳ１〜Ｓ４や端末Ｔ１１〜Ｔ１３、Ｔ２１〜Ｔ２３、Ｔ３１〜Ｔ３３、Ｔ４１〜Ｔ４２の概略ブロック図である。ここでは、端末Ｔ１１を代表して説明する。
【００２１】
端末Ｔ１１は、ＣＰＵ１１１と、主記憶部１１２と、フラッシュメモリ１１３と、ＥＰＲＯＭ１１４とを備えている。ここで、ＥＰＲＯＭ１１４はフラッシュメモリの領域の一部を使って代用してもよい。フラッシュメモリ１１３は、主にプログラム（ファームウェア）を格納するために用いられ、また、プログラムを起動するためのブートローダーが別に格納されている。
【００２２】
図３に、一般的なフラッシュメモリ１１３のメモリ構造を示す。ここで、ブートローダー（Ｍ１）は、工場出荷時に一度だけ書き込まれ、運用中に書き換えられることはない。一方、プログラム（ファームウェア）部（Ｍ２）は、機能の追加や不具合の修正等の理由により、運用中に書き換えられることがある。
【００２３】
ＥＰＲＯＭ１１４には、図４に示すように、緊急時のプログラム取得先格納テーブル１１４１が格納される。本テーブル１１４１には、プログラムの起動に失敗した場合に、プログラムの取得先となる機器のＩＰアドレスが優先度順に格納されている。本実施形態では、第一優先度から第三優先度までとしたが、この数は任意である。このように複数の候補を持つことで、プログラムの起動失敗時に救済の可能性が高まることとなる。また、テーブルには優先度を決定するためのメトリクス情報が格納される。本実施形態では、メトリクスとして自らと、プログラム取得先候補となる機器との間のルータ段数を採用している。ここで、値０は、両者が同じＬＡＮ（ＩＰサブネット）に属しており間にルータＲ１〜Ｒ３が存在しないことを表す。
【００２４】
ＣＰＵ１１１は、通常動作モードの時に、フラッシュメモリ１１３に格納されたプログラムに基づいて当該端末Ｔ１１の各部を総括制御することで端末Ｔ１１としての動作を実現する。また、ＣＰＵ１１１は、プログラム書き換えモード時に、フラッシュメモリ１１３に格納されたブートローダに基づいてプログラムの書き換えを行う。
【００２５】
また、ＣＰＵ１１１は、本発明に係る機能として、機器情報取得部１１１１と、障害対応部１１１２と、候補選定部１１１３とを備えている。機器情報取得部１１１１は、発着信時に、通話相手となる端末Ｔ２１からの制御情報に含まれる機器情報を取得し、この機器情報から同一のプログラムバージョンであるか否かを判定し、同一のプログラムバージョンである場合に、機器情報をＥＰＲＯＭ１１４上のプログラム取得先格納テーブル１１４１に記録する。
【００２６】
障害対応部１１１２は、フラッシュメモリ１１３に格納されたプログラムにより起動できない場合に、ＥＰＲＯＭ１１４に記録されたプログラム取得先格納テーブル１１４１に基づいて、該当する端末Ｔ２１からプログラムを取得して当該プログラムに基づいて起動する。
【００２７】
候補選定部１１１３は、通信時に経由するルータＲ１〜Ｒ３の数に基づいて、ＥＰＲＯＭ１１４上のプログラム取得先格納テーブル１１４１のプログラム取得先候補の選定順番の入れ替えを行う。
【００２８】
次に、上記構成における動作について説明する。
図５は、端末Ｔ１１の起動処理手順を示すフローチャートである。端末Ｔ１１に対して電源が投入される、あるいは、リセットが実施されると（ステップＳＴ５ａ）、ＣＰＵ１１１はブートローダーが起動しフラッシュメモリ１１３のプログラム格納領域からアプリケーションプログラムを読み出し、処理をブートローダーからアプリケーションプログラムへ移す作業を行う（ステップＳＴ５ｂ）。
【００２９】
ここで、異常が発生した場合、ＣＰＵ１１１はステップＳＴ５ｃからステップＳＴ５ｄに移行してここでブートローダーがＥＰＲＯＭ１１４のテーブル１１４１にアクセスし、最も優先度の高いプログラム取得先候補のアドレスを読み出す。
【００３０】
データが取得できた場合は、ＣＰＵ１１１はステップＳＴ５ｅからステップＳＴ５ｆに移行してここで該アドレスに対して自らのバージョンのプログラム取得要求を行う。取得方法としては、ＴＦＴＰを用いるのが一般的である。そして、プログラム取得に成功した場合は、ＣＰＵ１１１はステップＳＴ５ｇからステップＳＴ５ｈに移行してここでそれをプログラム領域に書き込んだ上で起動処理を継続する（ステップＳＴ５ｉ）。
【００３１】
一方、上記ステップＳＴ５ｇにおいてプログラム取得に失敗した場合は、ＣＰＵ１１１はテーブル１１４１から次の優先度の取得先候補を読み出し（ステップＳＴ５ｊ）、該候補に対して取得要求を行う。本処理は、プログラムの取得に成功するか、あるいは、テーブル１１４１に登録された全ての候補に対する要求が失敗するまで繰り返される。
【００３２】
なお、上記ステップＳＴ５ｃにおいて、異常が発生しない場合には、ＣＰＵ１１１はステップＳＴ５ｉにそのまま移行し、さらに、上記ステップＳＴ５ｅにおいてテーブル１１４１中にデータが無い場合には、起動失敗として処理をそのまま終了する（ステップＳＴ５ｋ）。
【００３３】
図６及び図７は、端末Ｔ１１及び端末Ｔ３１がテーブル１１４１を更新する際のフローチャートである。
【００３４】
発側となる端末Ｔ１１は、発信操作時に制御信号に対して自端末のプログラムバージョンを設定し、交換サーバＳ１に対して制御パケット送信する（ステップＳＴ６ａ〜ステップＳＴ６ｃ）。
【００３５】
一方、応答側となる端末Ｔ３１は、同様に、応答操作時に応答信号に対して自端末のプログラムバージョンを設定し、交換サーバに対して制御パケットを送信する（ステップＳＴ７ａ〜ステップＳＴ７ｃ）。実現例の一つとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によるＩＰ電話相互通話を考える。発側の端末Ｔ１１は、ＳＩＰ Ｉｎｖｉｔｅメッセージを送信するが、Ｉｎｖｉｔｅメッセージに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のテキストフィールドにプログラムバージョンを含めるようにする。同様に、応答端末Ｔ３１は、ＳＩＰ ２００ ＯＫメッセージに含まれるＳＤＰのテキストフィールドにプログラムバージョンを含めるようにすればよい。
【００３６】
図８は、端末Ｔ１１と端末Ｔ３３との間の通信中にテーブル１１４１にプログラム取得先候補を登録する動作を示すシーケンス図である。
【００３７】
いま、端末Ｔ１１から端末Ｔ３３に発信し、相互に通話を行うとする。ここで、端末Ｔ１１から端末Ｔ３３までのルータ段数は２であるため、端末Ｔ１１は端末Ｔ３３に対するメトリクスとして２を得る。テーブル１１４１の登録状態から、優先度３の候補に対するメトリクスが３であるため、端末Ｔ１１は、優先度３の候補として端末Ｔ３３のＩＰアドレスを前記メトリクスと共にテーブル１１４１に登録する（書き換える）。
【００３８】
以上のように上記第１の実施形態では、端末Ｔ１１において、発着信時に得られる制御信号を利用して機器情報を取得してＥＰＲＯＭ１１４のテーブル１１４１に記録し、プログラムの異常により起動できない場合に、ＥＰＲＯＭ１１４のテーブル１１４１に基づいて他の端末Ｔ２２からプログラムを取得して起動するようにしている。
【００３９】
従って、プログラムのバックアップ領域を持つ必要がないため、機器のコストを抑えることができ、これによりプログラムに異常が発生した場合に、保守員の手操作を介することなく、低コストでプログラムの異常に対し効果的に対処することができる。また、予めネットワーク上にプログラムを格納するサーバを設置する必要がないため、管理コストが軽減される。
【００４０】
また、上記第１の実施形態では、テーブル１１４１中に多くのプログラム取得先候補を登録することができるので、プログラム異常発生時に、プログラム取得先を多く選択することができ、これによりプログラム取得先への接続上の信頼性をさらに高めることができる。
【００４１】
（第２の実施形態）
図９は、この発明の第２の実施形態として、端末Ｔ１１と端末Ｔ３１との間で通話中になった際のテーブル１１４１を更新する際のフローチャートである。
【００４２】
通話に至った後、発側と応答側の何れの端末Ｔ１１，Ｔ３１も、相手から受け取った制御パケットから相手端末のバージョン情報を取り出し（ステップＳＴ９ａ）、自端末のバージョンと一致するか比較する（ステップＳＴ９ｂ）。
【００４３】
ここで両者のバージョンが一致する場合、通話相手端末が起動失敗時のプログラム取得先候補となりうる。本発明では、ここからさらに相手端末との間のネットワーク的な近さを類推して、より近い端末を候補端末とするようルータホップ数の計測を行う（ステップＳＴ９ｃ）。これにより、より安定的にプログラムの取得が可能となる。ホップ数の計測には、ＩＣＭＰを使う。良く知られているＴｒａｃｅｒｏｕｔｅコマンドのように、ホップ上限数を１から一つずつ増やしながら、最終的に相手端末に到達するまで繰り返すことにより、両端末間のルータ段数を計測する。ここで得られたメトリクス（ルータ段数）が、既にテーブルに登録されたものより小さければ、ステップＳＴ９ｄからステップＳＴ９ｅに移行してここで段数に応じた優先度でもってテーブル１１４１を書き換える。
【００４４】
一方、得られたメトリクスが既に登録済みの候補と同じか、または、大きい場合はテーブル１１４１の更新を行わない（ステップＳＴ９ｆ）。
【００４５】
また、上記ステップＳＴ９ｂにおいて、自端末のバージョンと一致しない場合、端末Ｔ１１，Ｔ３１は、処理を行わない（ステップＳＴ９ｇ）。
【００４６】
以上のように上記第２の実施形態では、端末Ｔ１１において、通信時に経由するルータＲ１〜Ｒ３の数が小さい順にＥＰＲＯＭ１１４上のテーブル１１４１のプログラム取得先候補の選定順番を書き替えるようにしているので、自端末Ｔ１１から近い順にプログラム取得先が選択されることになり、これにより、例えば広域ネットワーク１をプログラム取得のために占有しなくて済むとともに、プログラムが第三者に漏れたり改竄されたりすることなく安全に取得することができる。
【００４７】
また、上記第２の実施形態では、端末Ｔ１１，Ｔ３１において、通信中に通信相手のプログラムバージョンがフラッシュメモリ１１３に記録されるプログラムと同一であるか否かを判定し、同一である場合のみ、通信相手をプログラム取得先候補として自動的にＥＰＲＯＭ１１４のテーブル１１４１に登録するようにしているので、通信相手ごとに適切なプログラムの取得が可能となる。
【００４８】
（その他の実施形態）
この発明は、上記各実施形態に限定されるものではない。例えば上記第１及び第２の実施形態では、通信中に経由するルータの数によりプログラム取得先候補の選定順番を書き換えるようにした。しかしこれに限ることなく、例えば通信相手までの往復遅延等、ネットワークの近さを表す情報を用いるようにしてもよい。
【００４９】
また、上記第１の実施形態では、発着信時に通信相手からバージョン情報等を取得する例について説明したが、通常運用時の例えば稼働が少ない時間に通信相手からバージョン情報を取得するようにしてもよい。また、通信時以外に、例えば汎用コンピュータまたは可搬メディアを接続した際に、この汎用コンピュータまたは可搬メディア上に登録されている各端末のバージョン情報を取得するようにしてもよい。
【００５０】
その他、ＩＰ電話システムの構成及び種類、交換サーバ及びマルチメディア端末の機能構成や種類、プログラムバージョン情報の取得手順等についても、この発明の要旨を逸脱しない範囲で種々変形して実施できる。
【図面の簡単な説明】
【００５１】
【図１】この発明の第１の実施形態に係わるＩＰマルチメディア交換システムを示す概略構成図。
【図２】上記図１に示した交換サーバ及び端末の概略ブロック図。
【図３】上記図２に示したフラッシュメモリのメモリ構造を示す図。
【図４】上記図２に示したＥＰＲＯＭに格納されるプログラム取得先格納テーブルの記憶内容の一例を示す図。
【図５】同第１の実施形態において、端末の起動処理手順を示すフローチャート。
【図６】同第１の実施形態において、発側の端末のプログラム取得先格納テーブルの更新手順を示すフローチャート。
【図７】同第１の実施形態において、着側の端末のプログラム取得先格納テーブルの更新手順を示すフローチャート。
【図８】同第１の実施形態において、端末間の通信中にプログラム取得先格納テーブルにプログラム取得先候補を登録する動作を示すシーケンス図。
【図９】この発明の第２の実施形態として、端末間で通話中になった際のプログラム取得先格納テーブルを更新する手順を示すフローチャート。
【符号の説明】
【００５２】
１…広域ネットワーク、１１１…ＣＰＵ、１１２…主記憶部、１１３…フラッシュメモリ、１１４…ＥＰＲＯＭ、１１１１…機器情報取得部、１１１２…障害対応部、１１１３…候補選定部、１１４１…プログラム取得先格納テーブル、Ｌ１〜Ｌ４…ローカルエリアネットワーク、Ｓ１〜Ｓ４…交換サーバ、Ｔ１１〜Ｔ１３，Ｔ２１〜Ｔ２３，Ｔ３１〜Ｔ３３…マルチメディア端末、Ｒ１〜Ｒ３…ルータ。
【特許請求の範囲】
【請求項１】
第１の記録媒体に記憶されたプログラムに基づいて起動し、通信処理を実行する通信装置において、
前記第１の記録媒体に記憶されたプログラムと同一のプログラムを有する通信機器を示す機器情報を選択的に取得して前記第１の記録媒体とは異なる第２の記録媒体に記録する取得手段と、
前記第１の記録媒体に記憶されたプログラムにより起動できない場合に、前記第２の記録媒体に記録された機器情報に基づいて、該当する通信機器からプログラムを取得して当該プログラムに基づいて起動する障害復旧手段とを具備したことを特徴とする通信装置。
【請求項２】
前記取得手段は、前記機器情報を通信時に取得することを特徴とする請求項１記載の通信装置。
【請求項３】
前記取得手段は、前記機器情報を発着信時に取得することを特徴とする請求項１記載の通信装置。
【請求項４】
前記取得手段は、ＩＰ(Internet Protocol)システム内で用いられる場合に、通常運用中に前記機器情報を取得することを特徴とする請求項１記載の通信装置。
【請求項５】
前記取得手段は、通信中に通信相手から取得する機器情報に基づいて通信相手のプログラムバージョンが前記第１の記録媒体に記録されるプログラムと同一であるか否かを判断し、同一である場合に、通信相手の機器情報をプログラム取得先候補として自動的に前記第２の記録媒体に記録することを特徴とする請求項４記載の通信装置。
【請求項６】
前記取得手段は、プログラムバージョンが前記第１の記録媒体に記録されるプログラムと同一である複数候補の機器情報を前記第２の記録媒体に記録することを特徴とする請求項５記載の通信装置。
【請求項７】
さらに、予め決められた条件に従って、前記第２の記録媒体上の複数候補の機器情報の選定順番を置き換える候補選定手段を備えることを特徴とする請求項６記載の通信装置。
【請求項８】
前記候補選定手段は、前記条件の判断に、通信時に経由するルータ数、通信相手までの往復遅延の少なくとも１つを用い、前記ルータ数が少ない順または通信相手までの往復遅延が短い順に前記第２の記録媒体上の複数候補の機器情報を置き換えることを特徴とする請求項７記載の通信装置。
【請求項９】
第１の記録媒体に記憶されたプログラムに基づいて起動し、通信処理を実行する通信装置で使用される異常復旧方法において、
前記第１の記録媒体に記憶されたプログラムと同一のプログラムを有する通信機器を示す機器情報を選択的に取得して前記第１の記録媒体とは異なる第２の記録媒体に記録し、
前記第１の記録媒体に記憶されたプログラムにより起動できない場合に、前記第２の記録媒体に記録された機器情報に基づいて、該当する通信機器からプログラムを取得して、当該プログラムに基づいて起動することを特徴とする異常復旧方法。
【請求項１】
第１の記録媒体に記憶されたプログラムに基づいて起動し、通信処理を実行する通信装置において、
前記第１の記録媒体に記憶されたプログラムと同一のプログラムを有する通信機器を示す機器情報を選択的に取得して前記第１の記録媒体とは異なる第２の記録媒体に記録する取得手段と、
前記第１の記録媒体に記憶されたプログラムにより起動できない場合に、前記第２の記録媒体に記録された機器情報に基づいて、該当する通信機器からプログラムを取得して当該プログラムに基づいて起動する障害復旧手段とを具備したことを特徴とする通信装置。
【請求項２】
前記取得手段は、前記機器情報を通信時に取得することを特徴とする請求項１記載の通信装置。
【請求項３】
前記取得手段は、前記機器情報を発着信時に取得することを特徴とする請求項１記載の通信装置。
【請求項４】
前記取得手段は、ＩＰ(Internet Protocol)システム内で用いられる場合に、通常運用中に前記機器情報を取得することを特徴とする請求項１記載の通信装置。
【請求項５】
前記取得手段は、通信中に通信相手から取得する機器情報に基づいて通信相手のプログラムバージョンが前記第１の記録媒体に記録されるプログラムと同一であるか否かを判断し、同一である場合に、通信相手の機器情報をプログラム取得先候補として自動的に前記第２の記録媒体に記録することを特徴とする請求項４記載の通信装置。
【請求項６】
前記取得手段は、プログラムバージョンが前記第１の記録媒体に記録されるプログラムと同一である複数候補の機器情報を前記第２の記録媒体に記録することを特徴とする請求項５記載の通信装置。
【請求項７】
さらに、予め決められた条件に従って、前記第２の記録媒体上の複数候補の機器情報の選定順番を置き換える候補選定手段を備えることを特徴とする請求項６記載の通信装置。
【請求項８】
前記候補選定手段は、前記条件の判断に、通信時に経由するルータ数、通信相手までの往復遅延の少なくとも１つを用い、前記ルータ数が少ない順または通信相手までの往復遅延が短い順に前記第２の記録媒体上の複数候補の機器情報を置き換えることを特徴とする請求項７記載の通信装置。
【請求項９】
第１の記録媒体に記憶されたプログラムに基づいて起動し、通信処理を実行する通信装置で使用される異常復旧方法において、
前記第１の記録媒体に記憶されたプログラムと同一のプログラムを有する通信機器を示す機器情報を選択的に取得して前記第１の記録媒体とは異なる第２の記録媒体に記録し、
前記第１の記録媒体に記憶されたプログラムにより起動できない場合に、前記第２の記録媒体に記録された機器情報に基づいて、該当する通信機器からプログラムを取得して、当該プログラムに基づいて起動することを特徴とする異常復旧方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００９−２７８２６０（Ｐ２００９−２７８２６０Ａ）
【公開日】平成２１年１１月２６日（２００９．１１．２６）
【国際特許分類】
【出願番号】特願２００８−１２６０７９（Ｐ２００８−１２６０７９）
【出願日】平成２０年５月１３日（２００８．５．１３）
【特許番号】特許第４３６４２８５号（Ｐ４３６４２８５）
【特許公報発行日】平成２１年１１月１１日（２００９．１１．１１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２１年１１月２６日（２００９．１１．２６）
【国際特許分類】
【出願日】平成２０年５月１３日（２００８．５．１３）
【特許番号】特許第４３６４２８５号（Ｐ４３６４２８５）
【特許公報発行日】平成２１年１１月１１日（２００９．１１．１１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]