JP2003244191A - 呼制御サーバによる呼制御方法 - Google Patents

Abstract

(57)【要約】 【目的】 障害時における代替系への移行に際してもサ
ービスの低下を招くことのない低コストの呼制御サーバ
システムを実現する呼制御方法を提供する。 【構成】 ネットワーク内に配置された少なくとも２つ
の呼制御サーバにより呼制御をなす呼制御方法であり、
該呼制御サーバのうちの何れかを運用系サーバとし、他
を待機系サーバとする指定情報を共有記憶媒体に保持す
る。そして、該ネットワークに供給される呼の被呼アド
レスと、該被呼アドレスに対応する該運用系サーバの１
の名称と、該１における呼制御の進捗状態情報と、を含
む呼情報データを共有記憶媒体に保持し、該運用系サー
バをして、該保持された呼情報データにアクセスせしめ
て、該進捗状態情報に応じて対応する呼について呼制御
を実行せしめる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えばＩＰ（Inte
rnet Protocol）電話の如く、ネットワークに供給され
る呼の呼制御をなす呼制御方法に関する。

【０００２】

【従来の技術】従来、呼制御を行うシステムは、常に高
いアベイラビリティを維持するために幾つかの方式を用
いている。その１つは、２台の交換装置を２系統にて同
期運転する形態である。該形態では、２つの系の交換装
置が、常に、その状態が同一状態になるようにハードウ
ェア及びソフトウェアの両者で状態の一致化を行う。こ
れにより、一方の系に障害が発生した場合にも他系は常
に状態が一致していることから、他方の系に切り替える
ことによりサービスの中断又はデータの欠落無く処理を
継続することができる。該方法は、障害に起因するサー
ビス低下が殆ど発生しないものの、その構成の実現には
特殊且つ高価なハードウェア又はソフトウェアを必要と
する故にコスト的に問題があった。

【０００３】他の方式としては、運用系と待機系の２つ
の系からなる構成であり、運用系のみで通常の運用を行
い、該運用系に障害が発生した場合に、待機系に運用を
移行してサービスを継続する形態である。該方法では、
移行時にサービスの中断又はデータの欠落が一部発生す
るが、新規のサービスに対しては最小限の中断時間を保
証される。しかし、かかる方法では、新規のサービスに
対してサービスの低下は僅かであるが，切替前の呼の状
態を引き継ぐことが無くこれらの呼は全て失われてしま
い、サービスの低下が発生していた。

【０００４】

【発明が解決しようとする課題】本発明は、上記の問題
に鑑みてなされてものであり、その目的は、障害時にお
ける代替系への移行に際してもサービスの低下を招くこ
とのない低コストの呼制御サーバシステムを実現する呼
制御方法を提供することである。

【０００５】

【課題を解決するための手段】本発明による呼制御方法
は、ネットワーク内に配置された少なくとも２つの呼制
御サーバにより呼制御をなす呼制御方法であり、該呼制
御サーバのうちの何れかを運用系サーバとし、他を待機
系サーバとする指定情報を共有記憶媒体に保持する指定
情報保持ステップと、該ネットワークに供給される呼の
被呼アドレスと、該被呼アドレスに対応する該運用系サ
ーバの１の名称と、該１における呼制御の進捗状態情報
と、を含む呼情報データを共有記憶媒体に保持する呼情
報データ保持ステップと、該運用系サーバをして，該保
持された呼情報データにアクセスせしめて、該進捗状態
情報に応じて対応する呼について呼制御を実行せしめる
呼制御実行ステップと、を含むことを特徴とする。

【０００６】

【発明の実施の形態】本発明の実施例について添付の図
面を参照して詳細に説明する。図１は、本発明の実施例
であり、呼制御サーバシステムの構成を示している。呼
制御サーバシステム１は、ｎ個（ｎは２以上の整数）の
サーバ装置１０−１乃至１０−ｎと、共通記憶媒体２０
と、ゲートウェイ装置２と、これらを相互に通信可能と
するローカル網３からなる。サーバ装置１０−１乃至１
０−ｎの各々は、ＩＰネットワーク上のサーバであり、
呼制御プログラム１１−１乃至１１−ｎ及び監視プログ
ラム１２−１乃至１２−ｎを各々対応して含む。サーバ
装置１０−１乃至１０−ｎの各々は、汎用ＵＮＩＸ（登
録商標）サーバの如く、共通の基本仕様のソフトウェア
によって動作することが好ましい。

【０００７】呼制御プログラム１１−１乃至１１−ｎの
各々は、呼を構成する呼制御信号及び通話信号を送受信
して呼の設定、接続及び開放の一連の交換機能を実現す
る。即ち、呼制御プログラム１１−１乃至１１−ｎの各
々は、端末からの通信先電話番号の指定、即ち指呼アド
レスの指定に応じて対応するネットワーク経路に呼の通
信路を設定し、これを介してパケット化された通話信号
を中継する。呼の通信路の設定開放は、従来の電子交換
における方法と同様に呼設定要求、接続要求及び開放要
求を指示する呼制御信号に従ってなされる。呼制御信号
は、インターネット等のＩＰネットワークを介して、端
末、他の呼制御サーバシステム、適切なゲートウェイシ
ステムが仲介する通常の電話端末との間でやり取りされ
る。通話信号は、利用者の要求及び伝送時間を勘案して
決定された帯域幅の音声信号を符号化した後、パケット
化されて送受信される。ＩＰネットワークを介したこの
ような電話通信路の確立には、幾つかのプロトコルが実
用化されているが、例えば、ＭＧＣＰ（Media Gateway
Control Protocol）或いは「H.323」等が挙げられる。
呼制御プログラム１１−１乃至１１−ｎは、又、通信時
間や回数の管理等の多様な呼制御機能を含んでも良い。

【０００８】監視プログラム１２−１乃至１２−ｎの各
々は、待機系サーバにおいて実行され、呼制御プログラ
ム１１−１乃至１１−ｎが実行されている運用系サーバ
の呼制御の正常又は異常を監視し、異常を検知した場合
には当該運用系サーバの運用を待機系サーバ自身に切り
替える機能を有する。尚、サーバ装置１０−１乃至１０
−ｎの各々は、呼制御プログラム１１−１乃至１１−ｎ
と監視プログラム１２−１乃至１２−ｎとが選択的に実
行可能であり、サーバ装置自身が運用系サーバとして動
作する場合には呼制御プログラムのみを実行し、待機系
サーバとして動作する場合には監視プログラムのみを実
行する。

【０００９】ゲートウェイ装置２は、ＩＰ基幹ネットワ
ーク、例えば、インターネットに接続され、他のＩＰノ
ード（図示せず）、例えば、ＩＰ端末、他の呼制御サー
バシステム又は公衆電話網のゲートウェイシステムとの
間の呼制御信号及び通話信号の通信を可能とする。共有
記憶媒体２０は、サーバ装置１０−１乃至１０−ｎの各
々によりローカル網３を介して共通的にアクセス可能な
記憶媒体である。共有記憶媒体２０には、各呼に対応す
る呼情報データ（以下、コールデータと称する）が書き
込み及び読み込みされるコールデータエリア２２と、運
用系サーバの名称と実際に呼制御を行う物理的なサーバ
装置１１−１乃至１１−ｎとの対応を与える論理サーバ
名−物理サーバ名変換表２１と、が保持される。

【００１０】図２は、図１に示される共有記憶媒体２０
に保持される論理サーバ名−物理サーバデータ名変換表
２１を説明している。ここで、論理サーバ名としてのｍ
（ｍは１以上の整数）個の「運用系サーバＹ１乃至Ｙ
ｍ」の各々には、物理サーバ名として「物理サーバＸ
１」乃至「物理サーバＸｎ」の何れかの名称が運用系サ
ーバであるとして指定される。よって、論理サーバ名−
物理サーバ名変換表２１は指定情報である。物理サーバ
名は、予め実際のサーバ装置１０−１乃至１０−ｎの各
々に対応付けられている。従って、運用系サーバの論理
サーバ名が付与されないサーバ装置は、待機系サーバに
指定されていることを意味する。尚、論理サーバ名−物
理サーバ名変換表２１に示されるように、運用系サーバ
の指定数は１つ以上複数設定可能であり、同様に待機系
サーバの指定数も１つ以上複数の設定が可能である。複
数の待機系サーバを指定する構成においては、同一の運
用系サーバに対して複数の待機系サーバが同時にサーバ
切替処理を開始する不適切な動作が想定されるが、共有
記憶媒体２０へのアクセスに際して適切な排他制御を施
すことによりかかる動作は回避され得る。

【００１１】図３は、図１に示される共有記憶媒体に保
持されるコールデータエリア２２を説明している。ここ
で、運用系サーバ名毎に、呼識別番号Ｃｋ（ｋは１以上
の整数）に対してコールデータＣｋ（Ｙｍ）が格納され
る。コールデータＣｋ（Ｙｍ）の各々の内容は、呼の着
信先を指すデータである被呼アドレスとしての電話番号
及びこれに対応するＩＰアドレスと、呼の状態情報とを
含む呼情報からなる。呼の状態情報は、各呼に対応して
「空き」、「非救済」及び「救済」の３つの状態情報か
らなる。「空き」は、呼が生成されていないことを示
し、「非救済」は、呼制御が安定状態にないことを示し
サーバ装置間の指定切替が発生した場合には当該呼は放
棄されるべきことを意味する。「救済」は、呼制御が既
に安定状態に達していることを示しサーバ装置間の指定
切替が発生した場合に当該呼は維持されるべきことを意
味する。これらの３つの状態は、呼制御の進捗状態に応
じて決定される。

【００１２】このように、呼制御の対象となっている呼
は、被呼アドレスに応じて何れかの運用系サーバの論理
サーバ名に対応付けられ、物理サーバ名には直接には対
応付けられない。従って、各呼は、サーバ装置の切替が
発生しても常に特定の運用系サーバの論理サーバ名に対
応付けられていることから、現在運用中の運用系サーバ
の障害発生の故に対応する待機系サーバが運用系サーバ
に指定される際、呼処理の引き継ぎが円滑になされ得
る。

【００１３】尚、コールデータＣｋ（Ｙｍ）の各々の内
容は、更に、対応する所望の帯域幅等の多様な呼情報を
含んでも良い。又、コールデータＣｋ（Ｙｍ）の各々に
おけるデータの記述形式は、呼制御上の一般化された状
態表記により記述され、サーバ装置１０−１乃至１０−
ｎの各々において実行されるプログラムの互換性の問
題、例えば、版数（バージョン）の差異の問題を解消し
ている。

【００１４】図４は、待機系サーバの監視プログラムの
処理手順を示している。尚、待機系サーバは監視プログ
ラムのみを実行する。監視プログラムの処理としては、
先ず、共有記憶媒体２０に保持されている論理サーバ名
−物理サーバ名変換表２１を読み込む（ステップＳ１
１）。これにより、現時点で運用されている運用系サー
バの論理サーバ名を持つ呼制御サーバの物理サーバ名を
認識する。次いで、認識された物理サーバ名の運用系サ
ーバの全てに対して、サービス状態を問い合わせる（ス
テップＳ１２）。この問い合わせは、ローカル網を介し
た問い合わせ信号を送信することによりなされ得る。

【００１５】次に、監視プログラムは、全ての運用系サ
ーバについてそれぞれがサービス中であるか否かを判定
する（ステップＳ１３）。この判定は、運用系サーバか
らの「サービス中」又は「異常」を示すローカル網を介
した応答信号に従って、或いは無応答状態の検知により
なされる。運用系サーバの応答信号が、「サービス中」
であることを示している場合には、当該運用系サーバの
呼制御の実行は正常動作状態であると判定される。そし
て、全ての運用系サーバが「サービス中」であると判定
されれば、所定時間だけ待ち合わせた（ステップＳ１
４）後にステップ１１に戻り、問い合わせ処理を繰り返
す。

【００１６】一方、運用系サーバの応答信号の内容が
「異常」を示している場合には、当該運用系サーバの呼
制御プログラムの実行に障害が発生し呼制御の実行の継
続がもはや不能であると判定される、応答が無応答の場
合に、当該運用系サーバのシステム自体に障害が発生
（即ち、システムダウン）し、もとより呼制御の実行の
継続が不能であると判定される。これにより、運用系サ
ーバに指定された物理サーバの待機系サーバへの指定変
更が必要であると判断される。

【００１７】待機系サーバへの指定変更が必要であると
判断された場合に、監視プログラムは、先ず、共有記憶
媒体２０に保持されている論理サーバ名−物理サーバ名
変換表の内容を変更する。即ち、障害と判断された運用
系サーバの論理サーバ名に対応する物理サーバ名を自身
の物理サーバ名に書き換える（ステップＳ１５）。この
書き換えは、共有記憶媒体に対するアクセスを適切に排
他制御することで、複数の待機系サーバよる同時変更を
回避し得る。

【００１８】次に、監視プログラムは、当該運用系サー
バの論理サーバ名に対応するコールデータを共有記憶媒
体２０から順次読み込む（ステップＳ１６）。次いで、
読み込まれた１つのコールデータの状態情報を調べ、当
該呼が救済を要する呼であるか否かを判定する（ステッ
プＳ１７）。もし、コールデータの状態情報が「非救
済」である場合には、当該呼は放棄されるべき呼である
として当該呼に対応するネットワーク接続を開放する
（ステップＳ１８）。一方、コールデータの状態情報が
「救済」である場合には、当該呼は救済されるべき呼で
あるとして当該呼をそのまま維持する。ここで、全ての
コールデータについて調べ終わったか否かを判定し、残
っていればステップ１６の処理を繰り返し次の呼につい
て調べる（ステップＳ１９）。もし、終了していれば、
監視プログラムの実行を停止し、待機系サーバ自身は、
以後、運用系サーバとして呼制御プログラムを実行継続
する。又、呼制御の通常の運用を引き続いて行う。

【００１９】図５は、運用系サーバの呼制御プログラム
におけるサーバ状態監視応答処理の処理手順を示してい
る。運用系サーバの呼制御プログラムは、待機系サーバ
からの状態問い合わせを受信する（ステップＳ２１）。
運用系サーバの呼制御プログラムは、各呼に対する呼制
御のサービス状態がサービス中であるか否かを自己判定
する（ステップＳ２２）。もし、サービスが中断してい
ると判定される場合には待機系サーバに「異常」の応答
信号を返却する（ステップＳ２３）。一方、正常にサー
ビスを継続していると判定されれば、待機系サーバに
「サービス中」の応答信号を返却する（ステップＳ２
４）。以上のサーバ状態監視応答処理は、待機系サーバ
からの状態問い合わせに応じて随時行われる。

【００２０】図６は、運用系サーバの呼制御プログラム
における呼制御処理の処理手順を示している。ここで、
運用系サーバの呼制御プログラムは、先ず、ゲートウェ
イシステムを介して入力される呼制御信号の内容、即
ち、発呼要求、接続要求或いは開放要求の何れかである
かに応じて処理を振り分ける（ステップＳ３０）。も
し、呼制御信号の内容が発呼要求の場合には、呼制御プ
ログラムは、当該呼に対して「呼識別番号」を割り当
て、コールデータとの対応付けを行う（ステップＳ３
１）。そして、その呼の状態を「非救済」とする（ステ
ップＳ３２）。次いで、自身の論理サーバ名及び当該呼
に対応するコールデータの呼状態情報（非救済）を含む
呼情報を書き換える（ステップＳ３３）。次いで、該呼
設定要求に基づく呼制御上の呼の設定制御及び対応する
信号出力を行う（ステップＳ３４）。該信号出力は、ゲ
ートウェイを介して外部のＩＰネットワークに送出され
る。

【００２１】一方、呼制御信号の内容が接続要求の場合
には、呼制御プログラムは、呼の状態を「救済」とする
（ステップＳ３５）。次いで、自身の論理サーバ名及び
当該呼に対応するコールデータの呼状態情報を含む呼情
報を書き換える（ステップＳ３６）。次いで、該接続要
求に基づく呼制御上の接続制御及び対応する信号出力を
行う（ステップＳ３７）。該信号出力は、ゲートウェイ
を介して外部のＩＰネットワークに送出される。

【００２２】更に、呼制御信号の内容が開放要求の場合
には、呼制御プログラムは、呼の状態を「非救済」とす
る（ステップＳ３８）。次いで、自身の論理サーバ名及
び当該呼に対応するコールデータの呼状態情報を含む呼
情報を書き換える（ステップＳ３９）。次いで、該開放
要求に基づく呼制御上の呼の開放制御及び対応する信号
出力を行う（ステップＳ４０）。該信号出力は、ゲート
ウェイを介して外部のＩＰネットワークに送出される。
次いで、「呼識別番号」を開放、即ち、呼とコールデー
タとの割り当てを解き、呼の状態を「空」とする（ステ
ップＳ４１）。次いで、自身の論理サーバ名及び当該呼
に対応するコールデータの呼状態情報を含む呼情報を書
き換える（ステップＳ４２）。

【００２３】以上の処理手順により、運用系サーバ障害
時において、呼の呼制御の進捗に応じた待機系サーバの
異なる対応が実現され得る。尚、運用系サーバは、呼制
御プログラムにおけるサーバ状態監視応答処理（図５参
照）と、呼制御処理（図６参照）とを並行して実行す
る。又、複数の待機系サーバが用意出来る場合（ｎ−ｍ
≧２の場合）には、待機系サーバについて優先順位を与
えて、優先順位の最も高い１つの待機系サーバが、監視
動作をすることとし、当該サーバが運用系サーバに指定
された場合、次の優先順位の待機系サーバが監視動作を
することとする。

【００２４】本実施例における呼制御サーバシステム
は、特殊で高価なハードウェア又はソフトウェアを用い
ることなく汎用的なサーバ、例えば、ＵＮＩＸ（登録商
標）サーバを用いて実現され得る。これにより、常に高
いアベイラビリティを維持する呼制御サーバシステムが
低コストにて提供され得る。又、コールデータが共通仕
様に従った形式により保存され得ることから、複数のサ
ーバ間で搭載された呼制御プログラムの版数が異なった
場合にも、これら複数のサーバ間の切替及び呼の引継ぎ
が可能となる。このことは、旧バージョンの呼制御プロ
グラムが実行されてい運用系サーバの停止を保守者が手
動で行って新しい呼制御バージョンのプログラムが実行
される待機系サーバへの切替を強制的に行うことで、呼
制御プログラムのバージョンアップを容易に行えるとい
う付随的な利点がある。

【００２５】

【発明の効果】以上のように、本発明による呼制御方法
により、障害時における代替系への移行に際してもサー
ビスの低下を招くことのない低コストの呼制御サーバシ
ステムを提供できる。

【図面の簡単な説明】

【図１】本発明の実施例であり、呼制御サーバシステム
の構成を示しているブロック図である。

【図２】図１に示される共有記憶媒体に保持される論理
サーバ名−物理サーバデータ名変換表を説明している説
明図である。

【図３】図１に示される共有記憶媒体に保持されるコー
ルデータを説明している説明図である。

【図４】待機系サーバの監視プログラムの処理手順を示
しているフローチャートである。

【図５】運用系サーバの呼制御プログラムにおけるサー
バ状態監視応答処理の処理手順を示しているフローチャ
ートである。

【図６】運用系サーバの呼制御プログラムにおける呼制
御処理の処理手順を示しているフローチャートである。

【符号の説明】

１ 呼制御サーバシステム ２ ゲートウェイ装置 ３ ローカル網 １０ サーバ装置 １１ 呼制御プログラム １２ 監視プログラム ２０ 共有記憶媒体 ２１ 論理サーバ名−物理サーバ名変換表 ２２ コールデータエリア

Claims (3)

【特許請求の範囲】
1. 【請求項１】 ネットワーク内に配置された少なくとも
   ２つの呼制御サーバにより呼制御をなす呼制御方法であ
   って、 前記呼制御サーバのうちの何れかを運用系サーバとし、
   他を待機系サーバとする指定情報を共有記憶媒体に保持
   する指定情報保持ステップと、 前記ネットワークに供給される呼の被呼アドレスと、前
   記被呼アドレスに対応する前記運用系サーバの１の名称
   と、前記１における呼制御の進捗状態情報と、 を含む呼情報データを共有記憶媒体に保持する呼情報デ
   ータ保持ステップと、 前記運用系サーバをして、前記保持された呼情報データ
   にアクセスせしめて、前記進捗状態情報に応じて対応す
   る呼について呼制御を実行せしめる呼制御実行ステップ
   と、 を含むことを特徴とする呼制御方法。
2. 【請求項２】 前記運用系サーバの呼制御動作の異常を
   検知し、前記指定情報の指定内容の変更をなす指定情報
   変更ステップを更に含むことを特徴とする請求項１記載
   の呼制御方法。
3. 【請求項３】 前記進捗状態情報は、前記被呼アドレス
   に対応する呼を、前記指定情報変更ステップの実行時に
   維持するか又は放棄するかの状態情報を含むことを特徴
   とする請求項２記載の呼制御方法。