(57)【要約】【課題】プロセッサ間の呼制御処理の切り替え時における端末と呼制御プロセッサとの間の通信が不可能である時間を短縮する。【解決手段】、マルチプロセッサシステムは、端末１ａ〜１ｃ間の呼を制御する処理を実行可能な複数の呼制御プロセッサ＃０〜＃２と、複数の呼制御プロセッサ＃０〜＃２それぞれがアクセス可能な共用メモリ９と、呼制御プロセッサ＃０〜＃２のいずれか１つの障害を検知した場合に、他の呼制御プロセッサに、継続中の呼の制御処理の開始を指示する保守プロセッサ＃３とを備え、保守プロセッサ＃３から指示を受けた他の呼制御プロセッサは、障害が発生した呼制御プロセッサがアクセスしていた共用メモリ９上の領域へアクセスして呼制御データを読み出し、継続中の呼の端末に対して、呼制御プロセッサの変更を通知する。【選択図】図４
2009230702.tif 000002
【特許請求の範囲】
【請求項１】
端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサと、
前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域であって、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを記録するための領域を有する共用メモリと、
前記複数の呼制御プロセッサのいずれか１つに障害が発生した場合、前記障害を検知して、障害が発生していない他の呼制御プロセッサに、前記障害が発生した呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を指示する保守プロセッサとを備え、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記障害が発生した呼制御プロセッサがアクセスしていた共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される継続中の呼の端末に対して、呼制御プロセッサの変更を通知する、マルチプロセッサシステム。
【請求項２】
端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサと、
前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域であって、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを記録するための領域を有する共用メモリと、
前記複数の呼制御プロセッサのいずれか１つの呼制御プロセッサが実行している呼制御処理を、他の呼制御プロセッサに切り替える要求を受け付けた場合に、前記呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を、当該他の呼制御プロセッサに指示する保守プロセッサとを備え、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記呼制御プロセッサがアクセスしていた前記共用メモリ上の領域にアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される継続中の呼の端末に対して、呼制御プロセッサの変更を通知する、マルチプロセッサシステム。
【請求項３】
端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサと、
前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域であって、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを記録するための領域を有する共用メモリと、
前記複数の呼制御プロセッサのいずれか１つの呼制御プロセッサの処理量が閾値を越えたことを検知した場合、前記呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を、他の呼制御プロセッサに指示する保守プロセッサとを備え、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記処理量が閾値を越えた呼制御プロセッサがアクセスしていた前記共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される継続中の呼の端末に対して、呼制御プロセッサの変更を通知する、マルチプロセッサシステム。
【請求項４】
前記呼制御プロセッサ各々には、前記端末との通信において各呼制御プロセッサを識別するための識別データが割り振られており、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記端末に対して、呼制御プロセッサの変更を通知する際、当該他の呼制御プロセッサの識別データを前記端末へ通知することを特徴とする、請求項１〜３のいずれか１項に記載のマルチプロセッサシステム。
【請求項５】
前記複数の呼制御プロセッサは、各々ＩＰアドレスを割り当てられ、ＳＩＰによる通信の呼制御処理を実行可能であって、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記端末に対して、呼制御プロセッサの変更を通知する際、当該他の呼制御プロセッサのＩＰアドレスを前記端末に送信することを特徴とする、請求項１〜４のいずれか１項に記載のマルチプロセッサシステム。
【請求項６】
端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサおよび保守プロセッサが実行する呼制御プロセッサの切り替え方法であって、
前記複数の呼制御プロセッサは、前記複数の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データをそれぞれ記録する複数の領域に、それぞれアクセス可能であり、
前記保守プロセッサが、前記複数の呼制御プロセッサのいずれか１つに障害が発生した場合、前記障害を検知して、障害が発生していない他の呼制御プロセッサに、前記障害が発生した呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を指示する工程と、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサが、前記障害が発生した呼制御プロセッサがアクセスしていた共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される前記継続中の呼の端末に対して、呼制御プロセッサの変更を通知する工程とを含む呼制御プロセッサの切り替え方法。
【請求項７】
端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサおよび保守プロセッサに処理を実行させるプログラムであって、
前記複数の呼制御プロセッサに対して、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを、共用メモリの前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域に、それぞれ記録させる処理を、
保守プロセッサに対して、前記複数の呼制御プロセッサのいずれか１つに障害が発生した場合、前記障害を検知して、障害が発生していない他の呼制御プロセッサに、前記障害が発生した呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を指示する処理を、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサに対して、前記障害が発生した呼制御プロセッサがアクセスしていた共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される前記継続中の呼の端末に対して、呼制御プロセッサの変更を通知する処理を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、複数のプロセッサ間で呼制御処理を切り替える機能を有するマルチプロセッサシステムに関する。
【背景技術】
【０００２】
近年、通信端末間の呼の生成および終了を制御する呼制御システムとして、複数のプロセッサを備えるマルチプロセッサシステムが導入されている。例えば、マルチプロセッサで呼制御処理をすることにより、高速処理を実現する構成が提案されている（例えば、特許文献１参照）。また、マルチプロセッサにおいて、呼制御系装置に故障が発生してもその影響を抑えるための構成も提案されている（例えば、特許文献２参照）。このようなマルチプロセッサシステムは、例えば、複数のプロセッサを備える呼制御サーバにより構成される。
【０００３】
呼制御サーバの複数のプロセッサのうち１つに障害が発生した場合の対策としては、呼制御サーバをＡＣＴ系とＳＢＹ系で二重化して構成することが行われている。この場合、例えば、呼制御サーバは、実際に呼制御を行うＡＣＴサーバと、ホットスタンバイで待機するＳＢＹサーバとで構成される。ＡＣＴサーバおよびＳＢＹサーバいずれも、複数のプロセッサを備える。そして、ＡＣＴサーバのプロセッサの１つが故障すると、ＡＣＴサーバのハード障害として検出され、自動的に、ＳＢＹサーバへの切り替え（フェイルオーバー）が行われる。これにより、以降の呼制御が継続される。
【０００４】
上述のホットスタンバイ方式においては、サーバの切り替えに時間がかかる。そのため、この切り替え中は、端末と呼制御サーバとの通信が不能になる。その結果、例えば、切り替え時に、端末からの呼の切断信号が呼制御サーバで検出されず、正常な呼制御ができなくなるといった事態がおこり得る。
【特許文献１】特開２００２−１６５２３９号公報
【特許文献２】特開２０００−２５３４２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ゆえに、本発明は、切り替え時の端末と呼制御プロセッサとの間の通信が不可能である時間を短縮することができるマルチプロセッサシステム、呼制御マルチプロセッサの切り替え方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明にかかるマルチプロセッサシステムは、端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサと、前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域であって、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを記録するための領域を有する共用メモリと、前記複数の呼制御プロセッサのいずれか１つに障害が発生した場合、前記障害を検知して、障害が発生していない他の呼制御プロセッサに、前記障害が発生した呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を指示する保守プロセッサとを備え、前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記障害が発生した呼制御プロセッサがアクセスしていた共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される継続中の呼の端末に対して、呼制御プロセッサの変更を通知する。
【０００７】
上記構成により、複数の呼制御プロセッサのうち１つに障害が発生した場合でも、その呼制御プロセッサの制御対象であった継続中の呼を、他の呼制御プロセッサが引き継いで制御することができる。引き継ぎの際、他の呼制御プロセッサは、保守プロセッサからの指示を受けると、共用メモリ上の障害が発生した呼制御プロセッサが使用していた領域にアクセスし、継続中の呼の呼制御データを読み出す。これにより、他の呼制御プロセッサは、すぐに継続中の端末と通信を行うことができる。そのため、端末と呼制御プロセッサとの間の通信が不可能となる時間が短くてすむ。その結果、例えば、障害発生により呼制御のための通信が不可能な期間が生じ、それによって正常な呼制御が不能になるといった事態を防ぐことができる。
【０００８】
本発明にかかるマルチプロセッサシステムは、端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサと、前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域であって、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを記録するための領域を有する共用メモリと、前記複数の呼制御プロセッサのいずれか１つの呼制御プロセッサが実行している呼制御処理を、他の呼制御プロセッサに切り替える要求を受け付けた場合に、前記呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を、当該他の呼制御プロセッサに指示する保守プロセッサとを備え、前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記呼制御プロセッサがアクセスしていた前記共用メモリ上の領域にアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される継続中の呼の端末に対して、呼制御プロセッサの変更を通知する。
【０００９】
上記構成により、呼制御プロセッサの呼制御処理の切り替え要求に応じて、呼制御処理を他の呼制御プロセッサに切り替える場合、端末と呼制御プロセッサとの間の通信が不可能である時間が短くてすむ。そのため、切り替え時に正常な呼制御が不能になるといった事態を発生させずに、要求に応じた呼制御プロセッサの切り替えを行うことが可能になる。
【００１０】
本発明にかかるマルチプロセッサシステムは、端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサと、前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域であって、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを記録するための領域を有する共用メモリと、前記複数の呼制御プロセッサのいずれか１つの呼制御プロセッサの処理量が閾値を越えたことを検知した場合、前記呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を、他の呼制御プロセッサに指示する保守プロセッサとを備え、前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記処理量が閾値を越えた呼制御プロセッサがアクセスしていた前記共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される継続中の呼の端末に対して、呼制御プロセッサの変更を通知する。
【００１１】
上記構成により、処理量が閾値を越えた呼制御プロセッサの呼制御処理を他の呼制御プロセッサに切り替える場合に、端末と呼制御プロセッサとの間の通信が不可能である時間が短くてすむ。そのため、切り替え時に正常な呼制御が不能になるといった事態を発生させずに、処理量が閾値を越えた呼制御プロセッサの呼制御処理を切り替えることができる。
【発明の効果】
【００１２】
本願明細書に開示のマルチプロセッサシステムによれば、切り替え時の端末と呼制御プロセッサとの間の通信が不可能である時間を短縮することができる。
【発明を実施するための最良の形態】
【００１３】
本発明の実施形態において、前記呼制御プロセッサ各々には、前記端末との通信において各呼制御プロセッサを識別するための識別データが割り振られており、前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記端末に対して、呼制御プロセッサの変更を通知する際、当該他の呼制御プロセッサの識別データを前記端末へ通知する態様とすることができる。
【００１４】
上記構成により、呼制御プロセッサの切り替えに伴って、切り替え後の呼制御プロセッサの識別データが端末へ通知される。このように、識別データが端末へ通知することにより、端末側で切り替え後の呼制御プロセッサを認識することができ、切り替え後の呼制御プロセッサと端末との通信が可能になる。そのため、呼制御プロセッサ側で、例えば、切り替え後の識別データを、切り替え前と同じに設定する等の処理が不要になる。すなわち、切り替えに伴う呼制御プロセッサ側での処理が軽減されるので、切り替え時の通信不可能期間が短くなる。
【００１５】
前記複数の呼制御プロセッサは、各々ＩＰアドレスを割り当てられ、ＳＩＰによる通信の呼制御処理を実行可能であって、
前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサは、前記端末に対して、呼制御プロセッサの変更を通知する際、当該他の呼制御プロセッサのＩＰアドレスを前記端末に送信することを特徴とする、請求項１〜４のいずれか１項に記載のマルチプロセッサシステム。
【００１６】
本発明にかかる方法は、端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサおよび保守プロセッサが実行する呼制御プロセッサの切り替え方法であって、前記複数の呼制御プロセッサは、前記複数の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データをそれぞれ記録する複数の領域に、それぞれアクセス可能であり、前記保守プロセッサが、前記複数の呼制御プロセッサのいずれか１つに障害が発生した場合、前記障害を検知して、障害が発生していない他の呼制御プロセッサに、前記障害が発生した呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を指示する工程と、前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサが、前記障害が発生した呼制御プロセッサがアクセスしていた共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される前記継続中の呼の端末に対して、呼制御プロセッサの変更を通知する工程とを含む。
【００１７】
本発明にかかるプログラムは、端末間の呼を制御する処理を実行可能な複数の呼制御プロセッサおよび保守プロセッサに処理を実行させるプログラムであって、前記複数の呼制御プロセッサに対して、各々の呼制御プロセッサが制御する呼の端末を特定するデータを含む呼制御データを、共用メモリの前記複数の呼制御プロセッサそれぞれがアクセス可能な複数の領域に、それぞれ記録させる処理を、保守プロセッサに対して、前記複数の呼制御プロセッサのいずれか１つに障害が発生した場合、前記障害を検知して、障害が発生していない他の呼制御プロセッサに、前記障害が発生した呼制御プロセッサの制御対象であった継続中の呼の制御処理の開始を指示する処理を、前記保守プロセッサから前記指示を受けた前記他の呼制御プロセッサに対して、前記障害が発生した呼制御プロセッサがアクセスしていた共用メモリ上の領域へアクセスし、当該領域に記録されている前記呼制御データを読み出し、当該呼制御データで特定される前記継続中の呼の端末に対して、呼制御プロセッサの変更を通知する処理を実行させる。
【００１８】
（第１の実施形態）
（システム構成）
第１の実施形態は、本発明のマルチプロセッサシステムを、複数のＣＰＵ（central processing unit）を備えるＳＩＰサーバ（ＳＩＰソフトスイッチ）に適用する場合の例である。図１は、そのＳＩＰサーバを含むネットワークの概略構成を示す図である。図１に示す例では、端末１ａ，１ｂ，１ｃ、ＳＩＰサーバ２および振分サーバ３がネットワーク４に接続されている。ＳＩＰサーバ２は、複数のＣＰＵ＃０〜ＣＰＵ＃３を備える。本実施形態では、一例として、ネットワーク４がＩＰネットワークであり、ＳＩＰサーバ２は、ＳＩＰ（Session Initiation Protocol）を用いて、端末１ａ，１ｂ，１ｃ間の呼の生成および終了を制御する機能を持つ場合について説明する。
【００１９】
振分サーバ３は、端末１ａ〜１ｃから送信された、他の端末との呼確立を要求する初期信号（ＩＮＶＩＴＥ）を、ＳＩＰサーバ２のＣＰＵ＃０〜＃２に振り分ける。振分サーバ３は、例えば、初期信号を受信した時にＣＰＵ＃０〜ＣＰＵ＃２のいずれか１つを選択し、選択したＣＰＵに初期信号を転送する。その後、初期信号に係る呼は、そのＣＰＵで処理される。呼の処理中にそのＣＰＵに障害が発生した場合は、他のＣＰＵが呼の処理を引き継ぐことができるようになっている。そのための構成と動作の例について、以下説明する。
【００２０】
図２は、ＳＩＰサーバ２の各ＣＰＵが実現する機能部および共用メモリの構成例を示す図である。図２に示す例では、ＣＰＵ＃０、＃１および＃２は、それぞれ、呼制御部５ａ，５ｂ，５ｃおよび通信制御部６ａ，６ｂ，６ｃを備える。ＣＰＵ＃３は、監視部７および割り当て部８を備える。ＣＰＵ＃０〜＃２は、呼制御プロセッサの一例であり、ＣＰＵ＃３は保守プロセッサの一例である。
【００２１】
呼制御部５ａ〜５ｃ、通信制御部６ａ〜６ｃ、監視部７および割り当て部８の各機能部は、ＣＰＵが所定のプログラムを実行（アプリケーションを実行）することによって実現される機能ブロックであり、物理的な構造を示すものではない。そのため、前記各機能部の生成や消滅は、プログラムにより動的に制御することができる。また、ＣＰＵを、呼制御部５ａ〜５ｃ、通信制御部６ａ〜６ｃ、監視部７および割り当て部８として機能させるプログラムおよびそれを記録する記録媒体も本実施形態の一つである。
【００２２】
ＣＰＵ＃０〜＃２各々の呼制御部５ａ〜５ｃおよび通信制御部６ａ〜６ｃによって、呼処理の交換を行うためのＳＩＰソフトスイッチの機能が、各々のＣＰＵにおいて実現される。すなわち、複数のＣＰＵ＃０〜＃２各々において、ＳＩＰ呼制御処理が実行される。なお、ＳＩＰソフトスイッチは、図２に例示する機能の他に保守管理機能や課金機能などさまざまな機能を有してもよいが、ここでは、本発明と関係の薄い機能の説明は省略する。
【００２３】
ＳＩＰサーバ２は、ＣＰＵ＃０〜ＣＰＵ＃２各々がアクセス（参照および書込）可能な共用メモリ９を備えている。共用メモリ９は、ＣＰＵ＃０〜ＣＰＵ＃２それぞれが使用する領域に区切られている。共用メモリ９は、例えば、ＣＰＵ＃０〜ＣＰＵ＃２が直接データを参照および書き込みを行うことができる主記憶装置（メインメモリ）またはキャッシュメモリにより構成することができる。なお、共用メモリは、主記憶装置に限られず、ＨＤＤなどの補助記憶装置（外部記憶装置）で構成されてもよい。
【００２４】
通信制御部６ａ〜６ｃは、ＳＩＰ信号の送受信を行う。通信制御部６ａ〜６ｃは、ＳＩＰ信号を、ネットワーク４経由で受信すると、呼制御部５ａ〜５ｃへ通知する。また、通信制御部６ａ〜６ｃは、呼制御部５ａ〜５ｃからＳＩＰ信号の送信を要求されるとそのＳＩＰ信号をネットワーク４に対して送信する。
【００２５】
呼制御部５ａ〜５ｃは、ＳＩＰの呼制御を行う。例えば、ＳＩＰに準じた状態制御やＳＩＰに対応したヘッダ制御を行なう。具体的には、他の端末との呼の確立を要求するＳＩＰ信号を発信する端末（発信端末）からのＳＩＰ信号を受け取って、上記他の端末（着信端末）との呼（セッション）を生成する処理や、生成された呼の終了を要求するＳＩＰ信号を端末から受け取って、呼を終了させる処理等を実行する。
【００２６】
呼制御部５ａ〜５ｃは、主にＳＩＰにおけるプロキシサーバ（Proxy Server）として機能する場合について説明するが、呼制御部５ａ〜５ｃは、例えば、リダイレクトサーバ（Redirect Server）および登録サーバ（Register）としての機能を実現してもよい。また、本実施形態では、発信端末がＳＩＰにおけるＵＡＣ（User Agent Client）、着信端末がＳＩＰにおけるＵＡＳ（User Agent Server）として機能する場合について説明する。
【００２７】
呼制御部５ａ〜５ｃは、呼制御処理において用いられるデータ（呼制御データ）を、共用メモリ９から参照したり、共用メモリ９に書き込んだりする。呼制御データには、例えば、呼制御処理の対象となる端末を特定するデータ、各ＣＰＵ＃０〜＃２に割り当てられたネットワークにおける識別データ（本実施形態では、一例としてＩＰアドレス）等が含まれる。
【００２８】
例えば、呼制御部５ａ〜５ｃは、呼を生成すると、その呼制御データを記録するためのリソース（本実施形態では、セッションリソースと称する）を共用メモリに確保する。例えば、呼制御部５ａのセッションリソースは、呼制御部５ａのＣＰＵ＃０に割り当てられた領域に確保される。呼が終了すると、呼制御部５ａ〜５ｃは、セッションリソースを開放する。
【００２９】
ＣＰＵ＃３は、呼制御処理を実行するＣＰＵ＃０〜＃２の監視および保守機能など呼制御以外の機能を提供するために設けられるプロセッサである。ＣＰＵ＃３は、例えば、ＣＰＵ＃０〜＃２で実行されるアプリケーションを管理する。また、ＣＰＵ＃０〜ＣＰＵ＃２の故障等の障害を監視する。具体的には、ＣＰＵ＃３の監視部７が、呼制御処理を実行するＣＰＵ＃０〜＃２の障害の有無を監視する。例えば、監視部７は、ＣＰＵ間でヘルスチェック(死活監視)を行い、一定期間応答がない場合に障害と判断することができる。ＣＰＵ＃０〜ＣＰＵ＃２のうちいずれかの障害を検出すると、監視部７は、障害が発生したＣＰＵを割り当て部８に通知する。
【００３０】
割り当て部８は、障害が発生したＣＰＵの通知を受けると、そのＣＰＵの呼制御処理を、他のＣＰＵに割り当てる。例えば、割り当て部８は、障害が発生していない他のＣＰＵを、割り当て先のＣＰＵに決定する。そして、割り当て先のＣＰＵに対して、障害が発生したＣＰＵの呼制御処理の実行を引き継ぐように指示を出す。例えば、割り当て部８は、呼制御処理を開始する命令を割り当て先のＣＰＵに通知し、さらに、障害が発生したＣＰＵがアクセスしていた共用メモリ９上の領域を示すアドレスを、割り当て先のＣＰＵに通知する。これにより、割り当て先のＣＰＵは、障害が発生したＣＰＵが共用メモリ９に書き込んだ呼制御データにアクセスすることができる。そのため、呼制御処理を引き継ぎが可能になる。
【００３１】
本実施形態では、一例として、正常動作時には、ＣＰＵ＃１〜＃２のうちＣＰＵ＃０およびＣＰＵ＃１が呼制御部５ａ，５ｂ、通信制御部６ａ，６ｂを備え（すなわち、呼制御機能を提供するアプリケーションを実行し）、ＣＰＵ＃２は、予備として待機する形態を説明する。
【００３２】
この場合に、例えばＣＰＵ＃０に障害が発生すると、ＣＰＵ＃３の監視部７がこれを検出し、割り当て部８が、ＣＰＵ＃２に対して、呼制御部５ｃおよび通信制御部６ｃの生成（アプリケーション実行）を指示する。そして、呼制御部５ｃに対して、ＣＰＵ＃０に割り当てられていた共用メモリ９上の領域の先頭アドレスが通知される。呼制御部５ｃは、通知された先頭アドレスを用いて、共用メモリ９上の呼制御データにアクセスし、ＣＰＵ＃０が実行していた呼制御処理を引き続き実行する。
【００３３】
呼制御部５ｃは、共用メモリ９のＣＰＵ＃０で使用されていた領域にアクセス可能になるので、ＣＰＵ＃０の呼制御部５ａで制御されていた継続中の呼の呼制御データを読み出すことができる。呼制御部５ｃは、読み出した呼制御データで特定される継続中の呼の端末に対して、呼制御を実行するＣＰＵが変更されたことを通知する。具体的には、呼制御部５ｃは、例えば、変更後のＣＰＵ＃２へアクセスするためのデータ（ＣＰＵ＃２の識別データ）を継続中の呼の端末へ送信する。ＣＰＵ＃２の識別データとして、例えば、ＣＰＵ＃２に割り当てられたＩＰアドレスが挙げられる。
【００３４】
これにより、端末には、ＣＰＵが変更されたことが通知されるので、呼を継続中の端末は、変更後のＣＰＵに対して、継続中の呼に関わるＳＩＰ信号を送信することができる。すなわち、端末は、継続中の呼に関わる信号の送信先をＣＰＵ＃０からＣＰＵ＃２に切り替えることができる。その結果、変更後のＣＰＵ＃２は、端末から送信されるＳＩＰ信号を受信することが可能になる。
【００３５】
従来のホットスタンバイ方式の呼制御システムでは、ＡＣＴ系サーバが故障して、ＳＢＹ系サーバに切り替える際、ＡＣＴ系サーバのアドレスと切り替え後のＳＢＹ系サーバとのアドレスとが同じになるように設定する処理を行っていた。これにより、ＳＢＹ系サーバへの切り替え後も、端末は、ＡＣＴ系サーバと同じアドレスにアクセスできることになるが、この方式だと、切り替えに時間がかかっていた。これに比べて、本実施形態におけるＣＰＵの切り替え時には、端末に対して変更後のＣＰＵの識別データが送信されるので、ＳＩＰサーバ側の切り替え処理が簡単になり、切り替え処理の時間が短くて済む。
【００３６】
以上、マルチプロセッサシステムをＳＩＰサーバ２に適用する場合のシステム構成例を説明したが、マルチプロセッサシステムの構成は上記例に限られない。例えば、ＳＩＰサーバ２が備えるＣＰＵの台数は、図２に示す例に限らない。また、振分サーバ３とＳＩＰサーバ２は、１台のコンピュータで構成されてもよいし、複数のコンピュータで構成されてもよい。
【００３７】
＜ＳＩＰサーバ２の動作例＞
次に、ＳＩＰサーバ２の動作例を説明する。図３は、ＳＩＰサーバ２のＣＰＵ＃０がＳＩＰを用いて呼制御する場合の動作を示すシーケンス図である。図３では、一例として、端末１ａが発信端末（ＵＡＣ）となり、端末１ｂが着信端末（ＵＡＳ）となって、呼の確立を要求するＳＩＰ信号を送信した場合に、呼が確立される過程が示されている。まず、端末１ａが、端末１ｂとの呼の確立を要求する初期信号（ＩＮＶＩＴＥリクエスト）を送信する（Ｏｐ１）。このＩＮＶＩＴＥリクエストにおいて、ＲＲ（Record-Routeヘッダ）にはデータは記録されず、Ｃ（Contactヘッダ）には、ＵＡＣである端末１ａのＩＰアドレス「ＸＸＸ」が記録される。
【００３８】
振分サーバ３は、端末１ａからのＩＮＶＩＴＥリクエストを受信すると、呼制御を実行するためのＣＰＵをＳＩＰサーバ２のＣＰＵ＃０〜ＣＰＵ＃１の中から選択し、選択したＣＰＵへＩＮＶＩＴＥリクエストを送信する。ここでは、ＣＰＵ＃０が選択された場合について説明する。
【００３９】
ＣＰＵ＃０は、ＩＮＶＩＴＥリクエストを受け取ると、端末１ｂ（ＵＡＳ）の位置を特定し、ＩＮＶＩＴＥリクエストを端末１ｂへ送信する（Ｏｐ２）。その際、ＣＰＵ＃０は、ＩＮＶＩＴＥリクエストのＲＲに、ＣＰＵ＃０のＩＰアドレス「ＹＹＹ０」を記録してから送信する。
【００４０】
端末１ｂは、ＳＩＰサーバ２からＩＮＶＩＴＥリクエストを受信すると、ルートセットとして、ＳＩＰサーバ２のＣＰＵ＃０のＩＰアドレスおよび通信相手の端末１ａのIPアドレスのセット「ＹＹＹ０、ＸＸＸ」を端末１ｂが備える記録装置に記録する（Ｏｐ３）。そして、端末１ｂは、ＳＩＰサーバ２のＣＰＵ＃０に対して、２００ＯＫレスポンスを返信する（Ｏｐ４）。このとき、端末１ｂは、２００ＯＫレスポンスのＲＲにＣＰＵ＃０のＩＰアドレス「ＹＹＹ０」、Ｃに端末１ｂのＩＰアドレス「ＺＺＺ」を記録して送信する。
【００４１】
ＣＰＵ＃０は、端末１ｂから返信された２００ＯＫレスポンスを、ＲＲとＣは加工せずに、端末１ａに転送する（Ｏｐ５）。２００ＯＫレスポンスを受信した端末１ａは、ルートセットとして、ＣＰＵ＃０のＩＰアドレスおよび通信相手の端末１ｂのIPアドレスのセット「ＹＹＹ０、ＺＺＺ」を端末１ａが備える記録装置に記録する（Ｏｐ６）。
【００４２】
これにより、端末１ａにはルートセット「ＹＹＹ０、ＺＺＺ」、端末１ｂにはルートセット「ＹＹＹ０、ＸＸＸ」が記録される。すなわち、端末１ａおよび端末１ｂは、各々相手端末への経路（経由するＳＩＰサーバ（ＣＰＵ＃０）のＩＰアドレス「ＹＹＹ０」と相手先のＩＰアドレス）を示すルーチング情報を保持する。以後、端末１ａと端末１ｂとの間で送受信されるＳＩＰ信号にはルーチング情報が埋め込まれる。ＳＩＰ信号はこのルーチング情報に従ってルーチングされる。
【００４３】
例えば、端末１ａから送信されるＡＣＫメソッドのＲＵＲＩ（Request-URIヘッダ）には、相手先端末１ｂのＩＰアドレス「ＺＺＺ」が、Ｒ（Routeヘッダ）にはＣＰＵ＃０のＩＰアドレス「ＹＹＹ０」が記録される（Ｏｐ７）。これらのＩＰアドレス「ＺＺＺ」および「ＹＹＹ０」に従ってＡＣＫメソッドはルーチングされる。その結果、ＡＣＫメソッドは、ＳＩＰサーバ２のＣＰＵ＃０を経由し、端末１ｂに送信される（Ｏｐ８）。これにより、端末１ａと端末１ｂとの間の通話（セッション）が開始される。すなわち、呼が確立される。
【００４４】
そして、例えば端末１ｂが通話の終了を要求する場合、ＢＹＥメソッドを送信する（Ｏｐ９）。ＢＹＥメソッドのＲＵＲＩには、相手の端末１ａのＩＰアドレス「ＸＸＸ」、Ｒには経由するＣＰＵ＃０のＩＰアドレス「ＹＹＹ０」が記録される。ＢＹＥメソッドは、これらのルートセットに従ってネットワーク４でルーチングされる。その結果、ＢＹＥメソッドは、ＣＰＵ＃０を経由して端末１ａへ転送される。これにより、セッションが終了する（呼が終了する）。ＣＰＵ＃０は、ＢＹＥメソッドを受信し転送すると、共用メモリ９の、そのＢＹＥメソッドにかかるセッションのセッションリソースを開放する。
【００４５】
なお、図３には示さないが、通話中に、端末１ａまたは端末１ｂは、相手の端末へリフレッシュＩＮＶＩＴＥリクエストを送信してもよい。リフレッシュＩＮＶＩＴＥリクエストは、セッションタイマ（Session Timer）機能を用いたセッションの生存確認リクエストである。ＲＦＣ４０２８には、リフレッシュＩＮＶＩＴＥリクエストによるＳＩＰセッションの生存確認（死活監視）手順が規定されている。その手順は、呼設定時にＵＡＣとＵＡＳとの間で、任意の生存時間（セッションタイマ）をネゴシエートして決定する工程と、通話開始以降にセッションタイマの半分の時間（リフレッシュタイマと称する）で、ＵＡＳがＩＮＶＩＴＥリクエストを送信（リフレッシュ）し、相手のＵＡＣから正常レスポンスを受信することでセッションの正常性を確認する工程とを含む。正常性が確認された場合はセッションタイマが更新されて、リフレッシュ動作が繰り返される。
【００４６】
一方、通信経路で障害が発生する等の事情により、ＵＡＳが、セッションタイマが満了するまでにリフレッシュＩＮＶＩＴＥリクエストに対するレスポンスを受信できない場合は、ＵＡＳ側でリクエスト送信タイムアウトが発生する。その結果、ＵＡＳはセッションタイマ更新をできずにセッションが解放される。この場合、ＵＡＣ側は、リフレッシュＩＮＶＩＴＥを受信できずにセッションタイマが満了するので、同じくセッションが解放される。以上、図３に示した処理は、従来のＳＩＰサーバでも同様に実行される。
【００４７】
例えば、従来のように、ホットスタンバイ方式でＳＩＰサーバを構築した場合、ＳＩＰサーバ２のＣＰＵ＃０で障害が発生すると、ＳＢＹ系サーバへの切り替えに時間がかかる。その切り替えの間に、ＵＡＳからのＢＹＥリクエストが送信されてもＳＩＰサーバは受信することができない。その結果、ＵＡＳとＵＡＣとの通話は終了しているにも関わらず、ＳＩＰサーバは、呼の終了要求を検知できない。その結果、ＳＢＹ系サーバへの切り替え後も、ＳＩＰサーバ内のセッションリソースも残ったままとなる。また、ＳＩＰサーバが例えば課金処理も行っている場合には、通話が終了しているのに課金が継続されることになる。
【００４８】
また、ＳＢＹ系サーバへの切り替え中に、ＵＡＳからリフレッシュＩＮＶＩＴＥリクエストが送信されても、ＳＩＰサーバでこれを受信できずにＵＡＳ側でリクエスト送信タイムアウトが発生し、セッションが解放される。また、ＵＡＣ側でもリフレッシュＩＮＶＩＴＥを受信できないので、セッションが解放される。しかし、ＳＩＰサーバは、セッションの開放を検知できないので、セッション解放後もセッションリソースは残り、さらに、セッションが継続しているとみなされて課金等が継続されることになる。
【００４９】
本実施形態では、ＳＩＰサーバ２でＣＰＵに障害が発生しても、切り替えに要する時間を抑えることができる構成なので、上記のような事態を防ぐことができる。図４は、本実施形態のＳＩＰサーバ２においてＣＰＵ＃０に障害が発生した場合の処理の流れを示すシーケンス図である。
【００５０】
図４におけるＯｐ１〜Ｏｐ８の処理は、図３におけるＯｐ１〜Ｏｐ８とそれぞれ同様に実行される。Ｏｐ１で、端末１ａからのＩＮＶＩＴＥリクエストが、振分サーバ３によりＳＩＰサーバ２のＣＰＵ＃０に転送される。ＩＮＶＩＴＥリクエストを受信したＣＰＵ＃０の通信制御部６ａは、呼制御部５aへこれを通知する。呼制御部５ａは、共用メモリ９のＣＰＵ＃０に割り当てられた領域に、通知されたＩＮＶＩＴＥリクエストに係るセッションのためのセッションリソースを確保する。呼制御部５ａは、共用メモリ９に呼制御データを記録すると、通信制御部６ａを介して端末１ｂへＩＮＶＩＴＥリクエストを送信する。この時、呼制御部５は、呼制御データとして、例えば、ＵＡＣである端末１ａとＵＡＳである端末１ｂとを特定するためのデータ（ここではＩＰアドレス）を共用メモリ９のセッションリソースに記録する。
【００５１】
その後のＯｐ２〜Ｏｐ８で呼が生成され、セッションが開始する。ＣＰＵ＃０は、端末１ａからＡＣＫリクエストを受信したときに（Ｏｐ７）、例えば、セッションが開始されたことを示すデータと、その開始時刻とを共用メモリ９に記録することができる。
【００５２】
そして、セッション開始後、端末１ａと端末１ｂとの間で通話が行われているときに、ＣＰＵ＃０に障害が発生すると、ＣＰＵ＃３の監視部７がＣＰＵ＃０の障害を検出する（Ｏｐ２０）。監視部７は、ＣＰＵ＃０の障害を検出すると、予備ＣＰＵの割り当てを割り当て部８に対して指示する。割り当て部８は予備のＣＰＵ＃２に対して、呼制御部５ｃおよび通信制御部６ｃを機能させるためのアプリケーションの起動を指示する（Ｏｐ２１）。すなわち、ＣＰＵ＃２に呼制御処理開始を指示する。このとき、割り当て部８は、例えば、ＣＰＵ＃２の呼制御部５ｃが共用メモリ９のＣＰＵ＃０に割り当てられた領域にアクセス可能になるために必要な情報も、ＣＰＵ＃２へ通知する。例えば、ＣＰＵ＃０用の領域の先頭アドレス等がＣＰＵ＃２へ通知される。
【００５３】
ＣＰＵ＃３から指示を受けたＣＰＵ＃２は、メモリ（図示せず）から所定のプログラムを読み出して実行し、呼制御部５ｃと通信制御部６ｃを機能させる。これにより起動されたＣＰＵ＃２の呼制御部５ｃは、割り当て部８から通知された情報を基に、共用メモリ９中のＣＰＵ＃０が使用していた領域にアタッチし、ＣＰＵ＃０が使用していた領域をＣＰＵ＃２が参照／書き込みできる状態にする（Ｏｐ２２）。これにより、ＣＰＵ＃２の呼制御部５ｃは、ＣＰＵ＃０の呼制御部５ａで確保されていたセッションリソースを使うことが可能になる。すなわち、呼制御部５ｃは、呼制御部５ａが生成し、管理している継続中のセッションを引き続き管理することができる。
【００５４】
そして、呼制御部５ｃは、共用メモリ９のＣＰＵ＃０が記録し使用していた呼制御データを使用して、通信制御部６ｃを介してＵＡＣおよびＵＡＳの端末１ａ、１ｂに対して、ＳＩＰサーバとして機能するＣＰＵが、ＣＰＵ＃０からＣＰＵ＃２に変わったことを通知する（Ｏｐ２３、Ｏｐ２６）。各端末１ａ、１ｂでは、この通知を受けて、各々保持するルートセットにおけるＳＩＰサーバの情報を、ＣＰＵ＃０からＣＰＵ＃２に更新する（Ｏｐ２４、Ｏｐ２７）。これにより、各端末１ａ、１ｂから送信されるＳＩＰ信号は、ＣＰＵ＃０ではなく、ＣＰＵ＃２を経由するように、ルーチングされる。例えば、ＵＡＳである端末１ｂが呼の終了を要求するＢＹＥメソッドを送信すると、ＣＰＵ＃２がこれを受信することができる（Ｏｐ２９）。
【００５５】
上記のＯｐ２３〜Ｏｐ２８で送信されるＳＩＰ信号の具体例を、図５を参照して説明する。図５のＯｐ１〜Ｏｐ８までの処理、すなわち障害が発生するまでの処理は、図３のＯｐ１〜Ｏｐ８と同様である。ＣＰＵ＃０に障害が発生して、ＣＰＵ＃２で呼制御部５ｃおよび通信制御部６ｃが機能し始めると、呼制御部５ｃは、現在継続中のセッションのＵＡＣおよびＵＡＳの端末を特定するデータを共用メモリ９から取得する。ここでは、呼制御部５ｃは、一例として、端末１ａ、１ｂのＩＰアドレス（それぞれ「ＸＸＸ」「ＹＹＹ」）を、共用メモリ９から取得する。
【００５６】
そして、呼制御部５ｃは、端末１ａおよび端末１ｂに対して、ＣＰＵ＃２のネットワーク４における識別データ（ここでは、一例としてＩＰアドレス「ＹＹＹ２」）を通知する（Ｏｐ２３、Ｏｐ２６）。
【００５７】
例えば、呼制御部５ｃは、ＩＮＦＯリクエストのＲＲにＣＰＵ＃２のＩＰアドレス「ＹＹＹ２」を、Ｃに端末１ａ（ＵＡＣ）のＩＰアドレス「ＸＸＸ」を記録したＩＮＦＯリクエストを端末１ｂ（ＵＡＳ）に送信する（Ｏｐ２３）。各端末１ｂは、ＩＮＦＯリクエストを受信すると、保持していたルートセット「ＹＹＹ０、ＸＸＸ」を「ＹＹＹ２、ＸＸＸ」に更新し（Ｏｐ２４）、ＣＰＵ＃２へ２００ＯＫレスポンスを返信する（Ｏｐ２５）。
【００５８】
同様に、呼制御部５ｃは、ＩＮＦＯリクエストのＲＲにＣＰＵ＃２のＩＰアドレス「ＹＹＹ２」を、Ｃに端末１ｂ（ＵＡＳ）のＩＰアドレス「ＺＺＺ」を記録したＩＮＦＯリクエストを端末１ａ（ＵＡＣ）に送信する（Ｏｐ２６）。各端末１ａは、保持していたルートセット「ＹＹＹ０、ＺＺＺ」を「ＹＹＹ２、ＺＺＺ」に更新し（Ｏｐ２７）、ＣＰＵ＃２へ２００ＯＫレスポンスを返信する（Ｏｐ２８）。
【００５９】
以降、端末１ａ、１ｂから送信されるＳＩＰ信号のＲＵＲＩには相手の端末のＩＰアドレス、ＲにはＣＰＵ＃２のＩＰアドレスが記録されることになる。そのため、それらのＳＩＰ信号は、ＣＰＵ＃２に届くようになる。
【００６０】
上記の端末１ａ、１ｂへのＣＰＵ変更の通知は、ＣＰＵ＃２が呼制御処理を開始するとすぐに実行することができる。そのため、ＣＰＵ＃０からＣＰＵ＃２への切り替えにより、端末１ａ、１ｂとＳＩＰサーバ２との通信が不可能になる時間を極めて短くすることが可能になる。
【００６１】
以上、本実施形態におけるＳＩＰサーバ２の動作例を説明したが、ＳＩＰサーバ２の動作はこれに限られない。例えば、ＣＰＵ＃２の呼制御部５ｃおよび通信制御部６ｃは、ＣＰＵ＃３がＣＰＵ＃０の障害を検出する前から起動して待機しておき、ＣＰＵ＃３から指示を受けるとすぐに、共用メモリにアタッチして呼制御処理を開始するようにしてもよい。
【００６２】
＜本実施形態の変形例＞
また、本実施形態は、ＳＩＰを用いた呼制御処理について説明したが、本発明は、ＳＩＰ以外のプロトコルで呼制御処理するシステムにも適用可能である。ここで、一例として、Ｈ．３２３プロトコルを用いた呼制御処理をするシステムに、本実施形態と同様のマルチプロセッサシステムを適用する場合について説明する。
【００６３】
Ｈ．３２３プロトコルを用いた呼制御処理をするためのシステムは、図１におけるＳＩＰサーバ２をＨ．３２３の呼制御機能を持つサーバ１２に置き換えた構成となる。すなわち、サーバ１２は、ゲートキーパの機能を持つ。なお、サーバ１２も、ＳＩＰサーバ２と同様に、複数のＣＰＵ＃０〜ＣＰＵ＃３を備える。また、サーバ１２の構成は、図２と同様でよいが、本変形例では、図２における呼制御部５ａ〜５ｂは、ＳＩＰによる呼制御ではなく、Ｈ．３２３プロトコルによる呼制御処理を実行する。
【００６４】
図６は、本変形例のサーバ１２において、ＣＰＵ＃０に障害が発生した場合の処理の流れを示すシーケンス図である。Ｏｐ１において、端末１ａ（発信端末）は、セッションの開始要求であるＳＥＴＵＰメッセージをサーバ１２に対して送信する（Ｏｐ３１）。このＳＥＴＵＰメッセージには、発信端末（端末１ａ）、着信端末（端末１ｂ）のＩＰアドレス（それぞれ「ＸＸＸ」および「ＺＺＺ」）が含まれる。
【００６５】
図６は、端末１ａが送信したＳＥＴＵＰメッセージは、一例として、ＣＰＵ＃０に振り分けられ、ＣＰＵ＃０の呼制御部５aで処理される。ＣＰＵ＃０は、ＳＥＴＵＰメッセージにＣＰＵ＃０自身のＩＰアドレス「ＹＹＹ０」を追加して、着信端末（端末１ｂ）へ送信する（Ｏｐ３２）。端末１ｂは、ＳＥＴＵＰメッセージを受信すると、経路情報として、経由するサーバ１２（ＣＰＵ＃０）のＩＰアドレス「ＹＹＹ０」、相手の端末１ａのＩＰアドレス「ＸＸＸ」を端末１ｂが備える記録装置に記録する。
【００６６】
着信端末（端末１ｂ）は、呼の確立を確認するためのＣＯＮＮＥＣＴメッセージを発信端末（端末１ａ）に対して送信する（Ｏｐ３３）。そのＣＯＮＮＥＣＴメッセージには、経路を示す情報が付加されて送信される。経路を示す情報として、例えば、経由するサーバ１２のＣＰＵ＃０のＩＰアドレスがＣＯＮＮＥＣＴメッセージに含められる。
【００６７】
ＣＯＮＮＥＣＴメッセージは、サーバ１２を経由して端末１ａに送信される。端末１ａは、経路情報として、経由するサーバ１２のＩＰアドレス「ＹＹＹ０」、相手の端末１ｂのＩＰアドレス「ＺＺＺ」を端末１ａが備える記録装置に記録する。これにより、呼が生成される。その後、端末１ａと端末１ｂとは、Ｈ．２４２を用いた端末１ａの能力を示す情報を交換した後、例えば、ＲＴＰ（Real-time Transport Protocol）を用いた通話が開始される。
【００６８】
ＣＰＵ＃０で障害が発生すると、図４の場合と同様にして、ＣＰＵ＃３の監視部７が障害を検出し、割り当て部８が、予備のＣＰＵ＃２に呼制御処理の開始を指示する。ＣＰＵ＃２の呼制御部５ｃは、ＣＰＵ＃０が使用していた共用メモリの領域にアクセスし、ＣＰＵ＃０の制御対象であった呼の呼制御データを取得する。呼制御データには、例えば、継続中の呼の端末を特定するデータ（ここでは、端末１ａ、１ｂのＩＰアドレス「ＸＸＸ」「ＺＺＺ」）が含まれる。
【００６９】
ＣＰＵ＃２は、継続中の呼の端末１ａおよび端末１ｂに対して、ＣＰＵ＃２のＩＰアドレス「ＹＹＹ２」を経路情報として含むＦＡＣＩＲＩＴＹメッセージを送信する（Ｏｐ３７、Ｏｐ３９）。端末１ａは、経路情報を「ＹＹＹ０、ＸＸＸ」から「ＹＹＹ２、ＸＸＸ」に更新し、端末１ａは経路情報を「ＹＹＹ０、ＸＸＸ」から「ＹＹＹ２、ＸＸＸ」に更新する。これにより、端末１ａおよび端末１ｂから送信されるメッセージは、切り替え後のＣＰＵ＃２を経由するようになる。
【００７０】
（第２の実施形態）
図７は、第２の実施形態にかかるＳＩＰサーバの各ＣＰＵが実現する機能部および共用メモリの構成例を示す図である。図７において、図２と同じ機能部には同じ番号を付す。図７に示すＳＩＰサーバ２ａでは、保守ＣＰＵであるＣＰＵ＃３が、監視部７の代わりに交換要求受付部１３を備える。
【００７１】
交換要求受付部１３は、呼制御処理を実行中のＣＰＵを他のＣＰＵに交換することを要求する命令を受け付ける。例えば、交換要求受付部１３は、ＳＩＰサーバ２ａに接続されたキーボード、マウス等の入力装置（図示せず）により入力されるＣＰＵ交換の要求を受け付けることができる。もしくは、交換要求受付部１３は、ネットワーク４を介して、ＳＩＰサーバ２ａに対して送信されてくるＣＰＵ交換の要求を受け付けてもよい。ＣＰＵ交換の要求には、例えば、交換したいＣＰＵを識別するデータが含まれる。
【００７２】
例えば、ＳＩＰサーバ２ａの管理者が、保守点検のため、呼制御処理を実行しているＣＰＵを他のＣＰＵに交換したい場合に、ＳＩＰサーバ２ａのＣＰＵ＃３に対して、所定の保守手順でコマンドを入力することにより、呼制御処理のＣＰＵの交換を要求することができる。
【００７３】
交換要求受付部１３は、ＣＰＵの交換要求を受けると、交換が要求されているＣＰＵ（一例としてＣＰＵ＃０とする）を示すデータを割り当て部８に通知する。割り当て部８は、ＣＰＵ＃０に呼制御処理の停止を指示し、さらに、予備のＣＰＵ＃２に対して呼制御処理の開始を指示する。予備のＣＰＵ＃２に対する呼制御処理の開始の指示およびその後のＣＰＵ＃２の処理は、上記第１の実施形態と同様に実行される。
【００７４】
すなわち、割り当て部８から指示を受けたＣＰＵ＃２は、呼制御部５ｃおよび通信制御部６ｃを機能させるための処理を開始する。呼制御部５ｃは、共用メモリのＣＰＵ＃０が使用していた領域にアタッチし、呼制御データを読み出す。これにより、呼制御部５ｃは、ＣＰＵ＃０が実行していた呼制御処理を、迅速かつ適格に引き継ぐことができる。
【００７５】
本実施形態により、例えば、ＳＩＰサーバ２を保守する管理者が、必要に応じて、呼制御処理を実行するＣＰＵを、他のＣＰＵに切り替えることができる。その際、切り替え処理によって端末と通信不可能となる時間は短くて済むので、呼制御を正常に継続することができる。なお、本実施形態では、保守用のＣＰＵ＃３が監視部７の代わりに交換要求受付部１３を設ける形態であるが、例えば、監視部７に加えて、さらに交換要求受付部１３が設けられてもよい。
【００７６】
（第３の実施形態）
図８は、第３の実施形態にかかるＳＩＰサーバの各ＣＰＵが実現する機能部および共用メモリの構成例を示す図である。図８において、図２と同じ機能部には同じ番号を付す。図８に示すＳＩＰサーバ２ｂでは、保守ＣＰＵであるＣＰＵ＃３が、監視部７の代わりに負荷監視部１４を備える。また、割り当て部８ｂは、第１の実施形態における割り当て部８とは異なる機能を有する。
【００７７】
負荷監視部１４は、呼制御処理を実行するＣＰＵ＃０〜ＣＰＵ＃２の負荷を監視する。例えば、負荷監視部１４が、ＣＰＵ＃０〜ＣＰＵ＃２各々のＣＰＵ使用率が閾値を越えているか否か監視する。負荷監視部１４は、負荷が閾値を越えるＣＰＵ（一例としてＣＰＵ＃０とする）を検出すると、ＣＰＵ＃０を割り当て部８ｂに通知する。このとき、負荷監視部１４は、ＣＰＵ＃０が使用している共用メモリの領域のうち一部の領域にアクセスするための情報（例えば、前記一部の領域のアドレス等）を、割り当て部８ｂに通知する。
【００７８】
割り当て部８ｂは、通知を受けると、予備のＣＰＵ＃２に対して呼制御処理の開始を指示する。ＣＰＵ＃２は呼制御部５ｃおよび通信制御部６ｃを起動する。そして、割り当て部８ｂは、ＣＰＵ＃０に、上記一部の領域へのアクセスを禁止し、ＣＰＵ＃２に対して、上記一部の領域へのアクセスを許可する。呼制御部５ｃは、共用メモリのＣＰＵ＃０が使用していた上記一部の領域にアタッチし、呼制御データを読み出すことができる。その後のＣＰＵ＃２の処理は、上記第１の実施形態と同様に実行される。これにより、上記一部の領域に記録されていた呼制御データを用いた呼制御処理の実行主体が、ＣＰＵ＃０からＣＰＵ＃２へと変わる。
【００７９】
このようにして、高負荷がかかっていたＣＰＵ＃０の処理の一部を予備のＣＰＵ＃２へ移管することができる。さらに、ＣＰＵ＃２の呼制御部５ｃは、ＣＰＵ＃０が実行していた呼制御処理の一部を、迅速かつ適格に引き継ぐことができる。すなわち、例えば、呼制御を実行するＣＰＵの負荷が一時的に高くなる場合に、他のＣＰＵに呼制御処理の一部を切り替えることができる。その際、切り替え処理によって端末と通信不可能となる時間は短くて済むので、呼制御を正常に継続することができる。
【００８０】
なお、予備のＣＰＵが設けられず、ＣＰＵ＃０〜ＣＰＵ＃２全てが呼制御処理を実行している場合、割り当て部８ｂは、例えば、ＣＰＵの負荷が最も小さいＣＰＵに対して、ＣＰＵ＃０が実行していた呼制御処理の一部の引き継ぎを指示していもよい。
【００８１】
また、負荷監視部１４は、共用メモリ上のＣＰＵ＃０の使用領域のうち、どの領域をＣＰＵ＃２にアクセス可能とするかについては、ＣＰＵ＃０の負荷の程度により決定してもよい。
【００８２】
また、本実施形態では、保守用のＣＰＵ＃３が監視部７の代わりに負荷監視部１４を設ける形態であるが、例えば、監視部７に加えて、さらに負荷監視部１４が設けられてもよい。
【図面の簡単な説明】
【００８３】
【図１】第１の実施形態におけるＳＩＰサーバを含むネットワークの概略構成を示す図
【図２】ＳＩＰサーバの各ＣＰＵが実現する機能部および共用メモリの構成例を示す図
【図３】ＳＩＰサーバのＣＰＵ＃０が呼制御する場合の動作を示すシーケンス図
【図４】ＳＩＰサーバにおいてＣＰＵ＃０に障害が発生した場合の処理の流れを示すシーケンス図
【図５】図４に示す処理で送信されるＳＩＰ信号の具体例を示す図
【図６】第１の実施形態の変形例において、ＣＰＵ＃０に障害が発生した場合の処理の流れを示すシーケンス図
【図７】第２の実施形態にかかるＳＩＰサーバの各ＣＰＵが実現する機能部および共用メモリの構成例を示す図
【図８】第３の実施形態にかかるＳＩＰサーバの各ＣＰＵが実現する機能部および共用メモリの構成例を示す図
【符号の説明】
【００８４】
１ａ-１ｃ       端末
５ａ-５ｂ       呼制御部
５ａ-５ｃ       呼制御部
６ａ-６ｃ       通信制御部
３      振分サーバ
４      ネットワーク
５      呼制御部
６ａ，６ｂ，６ｃ        通信制御部
７      監視部
９      共用メモリ
１２    サーバ
１３    交換要求受付部
１４    負荷監視部
【図１】
2009230702.tif 000003
【図２】
2009230702.tif 000004
【図３】
2009230702.tif 000005
【図４】
2009230702.tif 000006
【図５】
2009230702.tif 000007
【図６】
2009230702.tif 000008
【図７】
2009230702.tif 000009
【図８】
2009230702.tif 000010