JP4834759B2 - メディアサーバ、セッション復旧方法及びコンピュータプログラム - Google Patents

Description

本発明は、音声自動応答中に故障が発生した際のセッションフェールオーバを行なうメディアサーバ、セッション復旧方法及びコンピュータプログラムに関する。

固定電話では、エンドユーザの電話料金は距離により変わる。そこで、音声による自動応答を行なうＩＶＲ（Interactive Voice Response）機能を全国規模で提供する場合、エンドユーザの電話料金を低く抑えるために、通信距離が短くなるようメディアサーバを全国各地に配置することが多い。しかし、全国各地にメディアサーバを配置すると、設備や保守などにかかるコストが高くなってしまうという問題が生じる。

一方、ここ１０年の間にインターネットやＩＰ（Internet Protocol）電話の普及がすすみ、また、ＶｏＩＰ（Voice over IP）やインスタントメッセージ等のリアルタイムサービスに用いられるプロトコルであるＳＩＰ（Session Initiation Protocol）の標準化が行なわれ、通信キャリアによるＩＰ電話サービス（ＶｏＩＰサービス）も広く提供されてきている。

ＶｏＩＰでは通信費が距離に依存して変化しないため、ＶｏＩＰを用いれば、各地に点在していたメディアサーバを１箇所に集約することができる。近年は、ＩＰ電話サービスの品質が安定し、信頼性も高くなってきたことから、今後、コスト削減のためＶｏＩＰを用いたメディアサーバの集約が進むと考えられる。しかし、メディアサーバを集約すると、故障時には影響が全国に及んでしまうため、メディアサーバにはこれまで以上の高い信頼性が要求されるようになる。

このように、今後はメディアサーバには高い信頼性が要求されると予想されるが、一方低価格化の圧力も大きい。そのため、例えば、ハードウェア面では、高価だが高品質・高信頼性のメインフレームから安価だが故障率の高いＩＡサーバを用いたＳＩ（システムインテグレーション）に移行する事例も増えてきた。また、ソフトウェア面では、安価なオープンソースソフトウェアを用いた開発も増えてきた。オープンソースソフトウェアはコストを抑えられるものの、ベンダー製品よりも品質が劣る場合もあり、アプリケーション側でエラーが生じる確率が高くなる場合も考えられる。

システムの信頼性については、ハードウェアの故障の問題はＦＴ（フォルトトレラント）サーバを用いることにより解決できる。ＦＴサーバではＣＰＵ（central processing unit）やメモリなどのハードウェアコンポーネントが全て２重化されており、ハードウェアコンポーネントの一方が故障してもシステムを全く止めることなく、瞬断もせずに動作を継続することができる。ＦＴサーバを導入すれば、ハードウェア故障の心配はなくなるが、非常に高価なことが導入のネックとなっている。また、ＦＴサーバはハードウェアの故障には対応できるが、アプリケーションが何らかのエラーにより落ちた場合にはサービスがストップしてしまうという問題がある。

そこで、ミッションクリティカルでないシステムでは、システムの信頼性を高めるために、システムを冗長化して障害によるシステム停止を最小限にするＨＡ（高可用性：High Availability）構成を採用することが多い。ＨＡ構成（クラスタ構成ともいう）では、現用系サーバに故障が発生した場合、クラスタ監視アプリケーションが待機系サーバの業務アプリケーションを自動で起動させる。ＨＡ構成には、データを共有ディスク上に置き、この共有ディスクを複数のサーバで利用する共有ディスクタイプと、各サーバのディスクをサーバ間でミラーするデータミラータイプがある。ＨＡ構成ならば、サービスの瞬断が発生するが、ソフトウェア／ハードウェアのいずれが故障した場合でも、現用系サーバから待機系サーバへの切り替えを行って動作を継続することができる。ＨＡ構成は世界で広く用いられている信頼性確保の方式であり、ＨＴＴＰ（Hypertext Transfer Protocol）やＤＢ（データベース）といった非リアルタイムのプロコトルにおいての使用実績は多い。しかし、現用系から待機系に切り替えるために１０秒程度かかることもあり、ＶｏＩＰのようなリアルタイムサービスにおいて用いるには適さないのが現状である。

また、ＩＶＲサービスは、エンドユーザ側のＩＰ電話端末とＳＩＰパケットを中継する中継機とＩＶＲ機能を有するメディアサーバにより構成されることが多い。中継機はキャリアが管理するサーバであり、着信先の相手を検索して通話を確立させる役割を持つ。中継機が故障すると、ＩＰ電話を使用する全てのユーザが通話不能となる。
特許文献１及び特許文献２には、現用系中継機であるＳＩＰサーバがセッションを確立する度に外部記憶装置にセッション情報を書き込んでおき、現用系中継機の故障時には待機系中継機がその故障を察知し、現用系として起動することが記載されている。特許文献１では、待機系中継機は起動時に外部記憶装置から情報を読み込んで全てのセッションを復旧させており、特許文献２では、現用系とし起動した待機系中継機が、ＳＩＰパケットを受信したときに外部記憶装置から情報を取得し、受信したセッションの情報だけを復旧している。

特開２００７−８１９３３号公報 特開２００８−１０３９５２号公報

一般に電話系のサービスは、固定電話をはじめ極めて品質の高いサービスが多く、エンドユーザもその品質が当たり前と考えていることが多い。そのため、故障時に通話が切断されることは大きな問題となる。
一方メディアサーバをＶｏＩＰにより構築しようとする企業では、これまでは、コストを優先し、ＦＴサーバではない安価なハードウェア、オープンソースソフトウェアなどの安価なソフトウェアによりＩＶＲシステムを構築することが多く、アプリケーションの故障率が高くなり信頼性が低くなる可能性が想定された。

しかし、今後は、大規模かつ高信頼性を求められるＩＶＲシステムがＶｏＩＰ上で構築される可能性が高いため、音声通話のセッションフェールオーバ機能が必要になると予想される。すなわち、アプリケーション／ハードウェアのいずれの故障時であっても通話が切断されずに現用系から待機系に処理が引継がれる、拠点集約にも耐えうる高信頼な電話システムの構成が切望されている。

中継機は、故障するとＩＰ電話を使用する全てのユーザが通話不能となるため、基本的に二重化されている。上述した特許文献１や特許文献２の技術は、中継機におけるＳＩＰセッションを復旧させる技術である。特許文献１や特許文献２の技術をメディアサーバで実現しようとした場合、メディアサーバに必要なＲＴＰ（Real-Time Transport Protocol）セッションやＩＶＲ処理を復旧させることはできないという問題があった。

また、特許文献１や特許文献２の技術をメディアサーバで実現しようとした場合、外部装置の負荷が高くなりすぎるという問題もある。特許文献１及び特許文献２では、中継機の二重化をＨＡ構成により実現している。中継機のように、リアルタイムで動作する必要のないサーバであれば、サーバが保持する情報に更新があった場合、その都度、更新内容を共有ディスクに反映させることにより、現用系の故障時には待機系サーバにおいてその共有ディスクの内容を参照して動作を継続することができる。しかし、メディアサーバはリアルタイムで動作するため、単純なＨＡ構成では二重化することはできない。

すなわち、中継機では３分ほどの通話でも５〜６パケットしか受信せず、例えば、１００人のエンドユーザが通話している状態を仮定しても、３分で５００〜６００のＳＩＰパケットを受信する程度であり、共有ディスクに変更した情報を記憶するための負荷は３．３アクセス／秒程度と想定される。また、ＳＩＰの仕様上、パケット受信後直ちに応答する必要もなく、３０秒ほどの余裕がある。

ところが、メディアサーバはリアルタイムで動作するためデータの更新が頻繁に生じる。メディアサーバでは、１つの通話で５０パケット／秒という多数の音声パケットを受信するため、例えば、１００人のエンドユーザが通話している状態を考えると、共有ディスクに対して５０００アクセス／秒程度の負荷があると予想される。これでは、共有ディスクへの書込みが間に合わなくなり、単純なＨＡ構成では対応できない可能性が高い。また、音声パケットの場合、送信に１０ミリ秒以上の遅延が生じると、音声が途切れる等の影響が発生するが、これほどの負荷をかけながら１０ミリ秒以内の遅延で音声パケットの送受信することは非常に困難である。

さらには、特許文献１では、全てのＳＩＰパケットを外部記憶装置に記憶しており、書込み及び読み出しの負荷が高い。
加えて、特許文献１及び特許文献２では、復旧に必要な情報を次々に追記し、削除しておらず、ディスクの利用効率や外部記憶装置の応答性能に影響を与える可能性がある。

このような特許文献１及び２の問題点に加え、先に述べたような拠点集約に耐えうる高い信頼性を実現すること、低価格の圧力でＦＴサーバによるハードウェア故障の回避を採用できない場合にも信頼性を確保すること、低価格の圧力からベンダー製品よりも品質が低い場合もあるオープンソースソフトウェアの使用率が向上しているためアプリケーションエラーが生じやすい可能性があること、電話系のサービスは他のサービスと比較して高品質を求められやすいことなどを勘案して、メディアサーバのセッションフェールオーバを実現する必要がある。

本発明は、上記の事情に鑑みてなされたものであり、その目的は、ＩＶＲ機能によりＩＰネットワークを介して音声データを提供している際にメディアサーバに故障が発生した場合であっても、ＳＩＰ及びＲＴＰセッションを回復し、故障発生が発生した時点から迅速にＩＶＲシナリオを再開することができるメディアサーバ、セッション復旧方法及びコンピュータプログラムを提供することにある。

上記課題を解決するため、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバであって、前記ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理部と、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理部と、を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力する音声処理部と、前記呼処理部により送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理部により実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理部により実行された音声自動応答のシナリオに応じて前記電話端末から受信した音声を認識した結果の履歴情報とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む制御部と、他のメディアサーバの故障を検出する監視部と、前記監視部により現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理部とを備え、前記音声自動応答処理部は、前記復旧処理部が読み出した前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報と前記履歴情報とを取得し、取得した前記情報と前記履歴情報とにより特定される実行位置から前記音声自動応答のシナリオを実行し、前記音声処理部は、前記復旧処理部が読み出した前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理部から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力し、前記呼処理部は、前記復旧処理部が読み出した前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう、ことを特徴とするメディアサーバである。

また、本発明は、上述したメディアサーバであって、呼の復旧に用いられる情報は、送受信した前記呼制御信号から取得した発側電話番号、着側電話番号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含むことを特徴とする。

また、本発明は、上述したメディアサーバであって、呼の復旧に用いられる情報は、前記電話端末から受信した呼制御信号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含み、前記復旧処理部は、前記外部記憶装置から読み出した前記呼処理復旧情報に設定されている前記呼制御信号を前記呼処理部に送信し、前記呼処理部は、前記復旧処理部から送信された前記呼制御信号に基づいて前記電話端末との間の呼のセッションを確立する、ことを特徴とする。

また、本発明は、上述したメディアサーバであって、メディアセッションの復旧に用いられる前記情報は、発信側及び着信側のメディアセッション用のアドレスと、メディアセッションに特有の値が設定された情報と、音声パケットの送信に伴い値が更新される情報のメディアセッション確立時の値と、前記メディアセッションの開始時刻とを含み、前記音声処理部は、前記復旧処理部により読み出された前記音声処理復旧情報から前記開始時刻と、音声パケットの送信に伴い更新される前記情報のメディアセッション確立時の値とを取得し、前記開始時刻からの経過時間に基づいて更新される前記情報の現在の値を算出し、前記音声処理復旧情報から読み出した、発信側及び着信側のメディアセッション用の前記アドレスと、メディアセッションに特有の値が設定された前記情報と、算出した前記値を設定した、音声パケットの送信に伴い更新される前記情報とを用いて前記呼のメディアセッションを復旧する、ことを特徴とする。

また、本発明は、上述したメディアサーバであって、前記制御部は、解放された呼の呼特定情報を含む前記呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から削除する、ことを特徴とする。

また、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバに用いられるセッション復旧方法であって、呼処理部が、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、音声自動応答処理部が、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、音声処理部が、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部へ出力する音声処理ステップと、御部が、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオに応じて前記電話端末から受信した音声を認識した結果の履歴情報とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、監視部が、他のメディアサーバの故障を検出する監視ステップと、復旧処理部が、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、前記音声自動応答処理部が、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報と前記履歴情報とを取得し、取得した前記情報と前記履歴情報とにより特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、前記音声処理復旧が、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、前記呼処理部が、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、を有することを特徴とするセッション復旧方法である。

また、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバとして用いられるコンピュータに、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から音声パケットを受信する音声処理ステップと、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオに応じて前記電話端末から受信した音声を認識した結果の履歴情報とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、他のメディアサーバの故障を検出する監視ステップと、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報と前記履歴情報とを取得し、取得した前記情報と前記履歴情報とにより特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、を実行させることを特徴とするコンピュータプログラムである。

本発明によれば、音声送出中に現用系のメディアサーバが故障した場合であっても、通話がとぎれることなく、待機系のメディアサーバによって、故障が発生した時点から引き続きＩＶＲシナリオを提供することができる。このように、メディアサーバのセッションフェールオーバを実現することができるため、ＦＴサーバと比較して故障率の高いハードウェアを使用した場合や、オープンソースソフトウェアのようにベンダー製品と比較して品質の劣る可能性のあるソフトウェアを使用した場合でも、信頼性の高いシステムを実現することが可能となる。従って、安価なハードウェア、ソフトウェアを使用し、メディアサーバの集約を実現することができるため、導入、運用、保守のコストを軽減することが可能となる。

本発明の第１の実施形態によるＩＶＲシステムの機能ブロック図である。 同実施形態による電話番号設定情報のデータ構成例を示す図である。 同実施形態によるＩＶＲフローデータのデータ構成例を示す図である。 同実施形態による呼処理復旧情報のデータ構成例を示す図である。 同実施形態による音声処理復旧情報のデータ構成例を示す図である。 同実施形態によるＩＶＲ処理情報のデータ構成例を示す図である。 同実施形態による着信時のシーケンスを示す図である。 同実施形態による故障発生時のシーケンスを示す図である。 同実施形態による監視フローを示す図である。 同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。 同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。 同実施形態による現用系メディアサーバの発信時の処理フローを示す図である。 同実施形態による待機系メディアサーバの復旧処理フローを示す図である。 第２の実施形態による呼処理復旧情報のデータ構成例を示す図である。 同実施の形態による音声処理復旧情報のデータ構成例を示す図である。 同実施形態による故障発生時のシーケンスを示す図である。 同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。 同実施形態による現用系メディアサーバの発信時の処理フローを示す図である。 同実施形態による待機系メディアサーバの復旧処理フローを示す図である。

以下、図面を参照して本発明の実施形態の例について説明する。

［第１の実施形態：メモリ情報共有方式］
本実施形態では、メモリ情報共有方式による音声通話のセッションフェールオーバを実現する。メモリ情報共有方式では、ＩＶＲ（Interactive Voice Response：音声自動応答）システムにおける現用系のメディアサーバはＳＩＰ（Session Initiation Protocol）関連の情報全てを外部記憶装置に保存しておき、この現用系のメディアサーバに故障が発生した場合、待機系のメディアサーバが外部記憶装置に保存しているＳＩＰ関連の情報を用いて呼処理を継続するものである。

図１は、本発明の一実施形態によるＩＶＲシステムの機能ブロック図である。ＩＶＲとは、エンドユーザからの電話に自動で応答し、「○○の方は1番を押してください」のような音声を再生することにより、ユーザを誘導してオペレータに転送したり、エンドユーザに情報提供を提供したりする音声自動応答機能を有する音声自動応答システムをいう。

同図に示すように、ＩＶＲシステムは、電話端末１、中継サーバ２、メディアサーバ４、外部記憶装置６、発信制御装置７を備える。電話端末１及び中継サーバ２は、ＩＰ（Internet Protocol）網であるネットワークＮに接続される。同図において電話端末１は、１台のみが記載されているが、複数台がネットワークＮに接続される。２台のメディアサーバ４は、ルータ３を介してネットワークＮと接続され、メディアサーバ４、外部記憶装置６、及び、発信制御装置７は、ＬＡＮ（Local Area Network）などの私設網を介して接続される。

同図においては、メディアサーバ４として２台のメディアサーバ４ａ、４ｂが記載されているが、３台以上が備えられてもよい。ここでは、メディアサーバ４ａが現在動作している現用系、メディアサーバ４ｂが現用系の故障時に処理を引継ぐ待機系であるとする。なお、メディアサーバ４が３台以上ある場合の現用系と待機系のサーバ台数比はＮ対Ｍ（Ｎ、Ｍは１以上）である。

音声通話のセッションフェールオーバでは、現用系のメディアサーバ４が故障した場合、待機系のメディアサーバ４に動作が引継がれて通話が継続される。例えば、現用系のメディアサーバ４ａから「○○の方は1番を押してください」とのアナウンスが流れ、エンドユーザが電話端末１に「１」を入力したのち、再びメディアサーバ４ａから「△△の方は…」のようなアナウンスが流れている途中でメディアサーバ４ａの故障が発生したとする。この場合、待機系のメディアサーバ４ｂが起動して、故障が発生した途中のアナウンスから再開し、「△△の方は、２番を押してください。」とのアナウンスを流して引き続きＩＶＲ処理を行なう。現用系から待機系への切り替え時には数秒間の無音が発生してもよい。

待機系に切り替わる時に必要な情報は、ＳＩＰ関連の情報、ＲＴＰ（Real-Time Transport Protocol）関連の情報、ＩＶＲ関連の情報である。ＳＩＰとは、ＩＰ電話により電話をかける相手を探しだすために使用されることが多い呼制御用のプロコトルであり、ＲＦＣ（Request for Comments）３２６１に詳しい仕様が記載されている。ＲＴＰとは、音声データなどをリアルタイムに伝送するために用いられるプロトコルであり、ＲＴＰパケットには、アナログの音声を符号化した音声データが設定される。

本実施形態によるＩＶＲシステムに適用されるメモリ情報共有方式では、現用系のメディアサーバ４は、ＳＩＰ関連の情報全てを外部記憶装置６に保存し、基本的に現用系のメディアサーバは、自身のメモリ上に待機系のメディアサーバに引継ぐＳＩＰ関連の情報を記憶しない。よって、現用系のメディアサーバ４が故障した場合でも、待機系のメディアサーバ４は、メモリ上にＳＩＰ関連の情報を復旧させる必要はない。

また、復旧のためのＲＴＰの情報は、ＲＴＰセッションの開始時に外部記憶装置６に記憶する。そのため、現用系のメディアサーバ４が故障した場合、待機系のメディアサーバ４は外部記憶装置６に記憶されている情報を参照してＲＴＰポートオープン等の状態復帰処理を行ってセッションを引継ぐが、一部の情報については保存時の値から現在の値を推定してＲＴＰパケット送信を再度起動させる必要がある。

ＩＶＲ関連の情報は、更新があり次第、その内容を外部記憶装置６に保存していく。そのため、現用系のメディアサーバ４が故障した場合、待機系のメディアサーバ４は外部記憶装置６に記憶されている情報に基づいてＩＶＲを再度起動する。よって、故障が発生した時点からＩＶＲ処理を再開することができる。

このように、メモリ情報共有方式は、現用系のメディアサーバ４が持つメモリ情報を全て外部記憶装置６に保存しておき、故障時は待機系のメディアサーバ４が外部記憶装置６から情報を取得してメモリ情報を復旧させる方式である。本方式の場合、ブリッジ方式の転送実施時に故障が発生した場合でもセッションフェールオーバが可能となる。また、待機系に切り替わる時、メモリ上にＳＩＰ関連の情報を復旧させる必要がないため、短い停止時間で現用系から待機系に切り替わることができる。

次に、各装置の構成について説明する。
エンドユーザが保有する電話端末１は、ＩＰ電話端末であり、メディアサーバ４との間でＳＩＰにより呼を確立するとともに、ＲＴＰを用いてメディアセッションを確立して音声パケットを送受信する。
中継サーバ２は、アドレス解決などを行なって、ＳＩＰ信号の中継を行なう。

メディアサーバ４は、通信部４０、監視部４１及びメディア処理プログラム実行部４２を備える。通信部４０は、ＩＰにより他の装置との間でパケット（データ）を送受信する。通信部４０は、現用系から処理を引継ぐ場合、現用系のメディアサーバ４が使用していたＩＰアドレスを引継いで使用する。監視部４１は、他のメディアサーバ４の故障を検出する。

メディア処理プログラム実行部４２は、呼処理部４３、制御部４４、主記憶部４５、ＩＶＲ処理部４６、音声処理部４７及び復旧処理部４８を備える。主記憶部４５は、メディア処理プログラム実行部４２内の各部からアクセス可能であり、呼処理、音声処理、ＩＶＲ処理に用いられる各種データを記憶する。制御部４４は、外部記憶装置６に対して呼処理復旧情報、音声処理復旧情報、ＩＶＲ処理情報の書込みや読み出しを行なう。呼処理部４３は、ＳＩＰ信号に基づく既存と同様の呼処理を行なうが、呼処理において用いられる各種情報のうち故障時の引継が必要な情報については制御部４４を介して外部記憶装置６に書込みを行ない、適宜この外部記憶装置６内の情報を参照して呼処理を行なう。ＩＶＲ処理部４６は、ＩＶＲフローに従った音声データの出力を音声処理部４７へ指示する。音声処理部４７は、ＲＴＰによる音声データの送受信処理を行なう。

以下、メディアサーバ４ａが備えるメディアサーバ４の各部には符号にａを付加して記載し、メディアサーバ４ｂが備えるメディアサーバ４の各部には符号にｂを付加して記載する。例えば、メディアサーバ４ａの備える監視部４１は監視部４１ａ、メディアサーバ４ｂの備える監視部４１は監視部４１ｂと記載する。

外部記憶装置６は記憶部６０を備え、記憶部６０内の電話番号設定記憶部６１、ＩＶＲフロー記憶部６２、呼処理復旧情報記憶部６３、音声処理復旧情報記憶部６４、ＩＶＲ処理情報記憶部６５に記憶されているデータの読書きを行なう。
発信制御装置７は、メディアサーバ４に対して呼の発信を指示する。

次に、本実施形態による外部記憶装置６に記憶される各データについて説明する。
図２は、本実施形態による電話番号設定記憶部６１に記憶される電話番号設定情報のデータ構成例を示す図である。電話番号設定情報は、電話番号、実行すべきＩＶＲシナリオを特定するＩＶＲ ＩＤ、同時に接続可能な呼数を示す最大チャネル数、及び、現在接続されている呼数を示すアクティブチャネル数を対応づけたレコードからなる。電話番号は、電話端末１から発信し、メディアサーバ４へ着信したときの着信先電話番号、あるいは、発信制御装置７の指示を受けメディアサーバ４が発信し、電話端末１へ着信したときの発信元電話番号である。

図３は、本実施形態によるＩＶＲフロー記憶部６２に記憶されるＩＶＲフローデータのデータ構成例を示す図である。同図において、ＩＶＲフローデータは、ＩＶＲ ＩＤと、ＩＶＲフローシナリオの対応付を示す。ＩＶＲフローシナリオは、エンドユーザに対して実行するＩＶＲ処理の順番を記述したデータであり、メディアサーバ４のＩＶＲ処理部４６は、このＩＶＲフローシナリオに従って、送出する音声の再生や、受信した音声の認識等の処理を順番に実行する。受信する音声は、例えば、ＤＴＭＦ（Dual Tone Multi Frequency）やエンドユーザの発話などである。なお、ＤＴＭＦとは、１〜９までの数字と＊、＃、Ａ、Ｂ、Ｃ、Ｄの記号の１６種類の符号を低群・高群の2つの音声周波数帯域の信号音で送信する方法であり、電話端末１にプッシュした番号をメディアサーバ４に伝えることができる。

図４は、本実施形態による呼処理復旧情報記憶部６３に記憶される呼処理復旧情報のデータ構成例を示す図である。呼処理復旧情報は、電話端末１及びメディアサーバ４の間でＳＩＰのセッションを再確立するために必要な情報を保持し、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、メディアサーバのＣＳｅｑ、電話端末のＣＳｅｑ、発着信フラグ、サーバ側電話番号、端末側電話番号、各種ヘッダフィールドを対応付けたレコードからなる。各レコードは、通話単位、つまり、ダイアログ単位で生成される。ＳＩＰにおいて、ダイアログとは、電話をかけて通話が確立してから通話が終了するまでの間のことである。呼は、ｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄの組み合わせによって示される呼特定情報により一意に特定することができる。

ｔｏタグは、論理的なリクエストの送信先（ＩＰアドレスとは異なる）が記載されているＳＩＰのタグである。ｆｒｏｍタグは、論理的な（ＩＰアドレスとは異なる）リクエストの送信元が記載されているＳＩＰのタグである。ｃａｌｌｉｄは、グローバルでユニークなランダムＩＤ（識別子）であり、ＲＦＣ１７５０の方式で生成することが推奨されている。ＣＳｅｑは、新規リクエスト毎にインクリメントされる番号である。発着信フラグは呼がメディアサーバ４からの発信か、電話端末１からの着信かを判別するためのフラグである。各種ヘッダフィールドは、送受信した各ＳＩＰメッセージのヘッダの情報の全部または一部の情報である。なお、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、ＣＳｅｑ、ＳＩＰメッセージのヘッダの詳細は、ＲＦＣ３２６１に記述されている。サーバ側電話番号、端末側電話番号に代えて、メディアサーバ４のＳＩＰ ＵＲＩ（Universal Resource Identifier）、電話端末１のＳＩＰ ＵＲＩを用いるようにしてもよい。

図５は、本実施形態による音声処理復旧情報記憶部６４に記憶される音声処理復旧情報のデータ構成例を示す図である。音声処理復旧情報は、電話端末１とメディアサーバ４の間のＲＴＰによる音声通信の再確立に必要な情報を保持し、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、発着信開始時間、メディアサーバのＲＴＰシーケンスナンバ、ＳＳＲＣ、ＲＴＰポート番号及びＩＰアドレス、電話端末のＲＴＰポート番号及びＩＰアドレスを対応付けたレコードからなる。各レコードは、ダイアログ（通話）単位で生成される。

ＳＳＲＣは、ＲＴＰパケットに含まれるメディアストリームのソースＩＤであり、他のＲＴＰと識別するために使用される。ＲＴＰシーケンスナンバは、ＲＴＰパケットの順序性を保障するための番号であり、ＲＴＰパケットを送信する度に１ずつ増やしていくが、ここでは、確立したＲＴＰセッションにおいて、最初に送信したＲＴＰパケットに使用したＲＴＰシーケンスナンバを示す。
なお、ＳＳＲＣ、ＲＴＰシーケンスナンバの詳細は、ＲＦＣ３３５０に記述されている。

図６は、本実施形態によるＩＶＲ処理情報記憶部６５に記憶されるＩＶＲ処理情報のデータ構成例を示す図である。ＩＶＲ処理情報は、メディアサーバ４がエンドユーザに対して実行したコマンドの履歴ログを示し、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、コマンド実行履歴、エンドユーザ入力履歴１〜ｎを対応付けたレコードからなり、ダイアログ（通話）単位で生成される。

コマンド実行履歴は、ＩＶＲフローシナリオにより規定される一連のＩＶＲ処理において、最後に指示したガイダンス送出や音声認識などのＩＶＲ処理を特定する。エンドユーザ入力履歴１〜ｎは、ＩＶＲ処理において電話端末１から受信したエンドユーザによる入力内容を順に記述したデータであり、入力されたＤＴＭＦや、音声やＤＴＭＦにより特定される選択内容などを示す。

次に、本実施形態によるＩＶＲシステムの動作について説明する。
ＩＶＲシステムの稼動前に、電話番号設定情報が電話番号設定記憶部６１に、ＩＶＲフローデータがＩＶＲフロー記憶部６２に記憶されているものとする。ただし、電話番号設定情報のアクティブチャネル数の初期値は「０」とする。

図７は、本実施形態による電話端末１から現用系のメディアサーバ４への着信時のシーケンス例を示す図である。なお、以下、ＳＩＰのＸ信号が設定されたＩＰパケットをＸパケットと記載する。例えば、ＩＮＶＩＴＥ信号が設定されたＩＰパケットをＩＮＶＩＴＥパケットとする。

まず、電話端末１は、中継サーバ２に対してＩＮＶＩＴＥパケットを送信する（ステップＳ１０５）。ＩＮＶＩＴＥパケットには、電話端末１が使用するＲＴＰポート番号及びＩＰアドレスが設定されている。中継サーバ２は、ＩＮＶＩＴＥパケットのＴｏフィールドに設定されている電話番号を着信先のＩＰアドレスに変換し、メディアサーバ４ａへ送信する（ステップＳ１１０）。メディアサーバ４ａは、着信を許可すると判断した場合、１００Ｔｒｉｎｇメッセージを中継サーバ２に返送し（ステップＳ１１５）、続いて、１８０Ｒｉｎｇｉｎｇを中継サーバ２に送信する（ステップＳ１２０）。中継サーバ２は、１８０Ｒｉｎｇｉｎｇを電話端末１に中継し（ステップＳ１２５）、電話端末１は、リングバックトーンをエンドユーザに聞かせる。

続いて、メディアサーバ４ａの呼処理部４３ａは、２００ＯＫを中継サーバ２に送信する（ステップＳ１３０）。２００ＯＫには、メディアサーバ４ａが使用するＲＴＰポート番号及びＩＰアドレスが設定されている。中継サーバ２は、２００ＯＫを電話端末１に中継する（ステップＳ１３５）。電話端末１は、メディアサーバ４ａに対してＡＣＫを送信する（ステップＳ１４０）。ＡＣＫの送信に伴い、電話端末１とメディアサーバ４ａの音声処理部４７ａ間でＲＴＰのセッションが確立され、通話中状態に遷移すると、メディアサーバ４ａの音声処理部４７ａは、ＩＶＲの音声をＲＴＰパケットにより電話端末１へ送信し、電話端末１はエンドユーザの発話やＤＴＭＦをＲＴＰパケットによりメディアサーバ４ａへ送信する（ステップＳ１４５）。

通話中状態が長く継続する場合、定期的にメディアサーバ４ａの呼処理部４３ａまたは電話端末１からｒｅ−ＩＮＶＩＴＥパケットまたはＵＰＤＡＴＥパケットが送信され（ステップＳ１５０）、この受信した電話端末１またはメディアサーバ４ａの呼処理部４３ａは、応答を返送し、セッションの継続を確認する。

エンドユーザが呼の切断操作を行なった場合、電話端末１はメディアサーバ４ａへＢＹＥパケットを送信し（ステップＳ１５５）、メディアサーバ４ａの呼処理部４３ａは、２００ＯＫを返送する（ステップＳ１６０）。なお、メディアサーバ４ａが呼の切断を行なう場合、メディアサーバ４ａの呼処理部４３ａは、電話端末１へＢＹＥパケットを送信し、電話端末１は、２００ＯＫを返送する。

メディアサーバ４からの発信の場合、メディアサーバ４が図７に示すシーケンス中の電話端末１と同様の動作を行い、電話端末１が図７に示すメディアサーバ４と同様の動作を行なう。

図８は、本実施形態によるＩＶＲシステムにおける故障発生時のシーケンスを示す図である。
例えば、図７のステップＳ１０５〜Ｓ１４０に示す電話端末１からの発信の手順や、メディアサーバ４からの発信の手順により、電話端末１とメディアサーバ４ａの間でＳＩＰセッションが確立されると（ステップＳ２０５）、メディアサーバ４ａは外部記憶装置６の呼処理復旧情報記憶部６３に呼処理復旧情報を書き込む（ステップＳ２１０）。メディアサーバ４ａは、ＩＶＲの処理を起動し（ステップＳ２１５）、電話端末１との間でＲＴＰセッションを確立すると（ステップＳ２２０）、外部記憶装置６の音声処理復旧情報記憶部６４に音声処理復旧情報を書き込む（ステップＳ２２５）。

メディアサーバ４ａは、音声再生などのＩＶＲ処理を実行し（ステップＳ２３０）、外部記憶装置６のＩＶＲ処理情報記憶部６５にＩＶＲ処理情報を書き込む。また、ＩＶＲ処理中に呼の継続確認のためのＳＩＰパケットの送受信があった場合、メディアサーバ４ａは、外部記憶装置６の呼処理復旧情報記憶部６３に記憶されている呼処理復旧情報の読み込みや更新を行なう（ステップＳ２３５）。つまり、メディアサーバ４ａは、ＩＶＲ処理が進むたびにＩＶＲ処理情報を更新し、電話端末１からＳＩＰパケットを受信する度に呼処理復旧情報を読込んで新規ＳＩＰパケットかを確認し、既存の呼の場合には呼処理復旧情報を更新する。

ＩＶＲ処理実行中にメディアサーバ４ａが故障した場合、メディアサーバ４ｂはこれを検知し（ステップＳ２４０）、外部記憶装置６のＩＶＲ処理情報記憶部６５からＩＶＲ処理情報を読み出すと（ステップＳ２４５）、ＩＶＲシナリオの途中からＩＶＲ処理を起動する（ステップＳ２５０）。さらに、メディアサーバ４ｂは、外部記憶装置６の音声処理復旧情報記憶部６４から音声処理復旧情報を読み出し（ステップＳ２５５）、音声処理復旧情報により示されるＲＴＰポートを開き受信状態にすると同時に電話端末１に対してＲＴＰパケットの送信を再開してＲＴＰセッションを復旧し（ステップＳ２６０）、電話端末１とのＲＴＰセッションを再確立する（ステップＳ２６５）。メディアサーバ４ｂは、電話端末１からＳＩＰパケットを受信した場合（ステップＳ２７０）、外部記憶装置６の呼処理復旧情報記憶部６３から呼処理復旧情報を読み出し、受信したＳＩＰパケットがセッション確立済みのパケットかを確認する（ステップＳ２７５）。

次に、メディアサーバ４における処理フローについて説明する。
図９は、本実施形態による監視フローを示す図である。
同図において、メディアサーバ４の監視部４１は、所定の時間間隔により、他のメディアサーバ４の生死の監視を起動する（ステップＳ３０５）。つまり、メディアサーバ４ａの監視部４１ａは、メディアサーバ４ｂの生死の監視処理を起動し、メディアサーバ４ｂの監視部４１ｂは、メディアサーバ４ａの生死の監視処理を起動する。

監視が起動されると、メディアサーバ４の監視部４１は、他のメディアサーバ４の監視部４１との間で生死の監視のための情報を交換する（ステップＳ３１０）。メディアサーバ４ａの監視部４１ａは、メディアサーバ４ｂの監視部４１ｂに対して監視メッセージを送信し、監視メッセージを受信したメディアサーバ４ｂの監視部４１ｂは、メディアサーバ４ｂのハードウェアの動作やメディア処理プログラム実行部４２ｂの処理が正常である場合、正常を通知する監視応答メッセージを返送する。同様に、メディアサーバ４ｂの監視部４１ｂは、メディアサーバ４ａの監視部４１ａに対して監視メッセージを送信し、監視メッセージを受信したメディアサーバ４ａの監視部４１ａは、メディアサーバ４ａのハードウェアの動作やメディア処理プログラム実行部４２ａの処理が正常である場合、正常を通知する監視応答メッセージを返送する。

現用系、待機系のメディアサーバ４とも正常である場合、つまり、メディアサーバ４ａ、４ｂが、ステップＳ３１０において自身が送信した監視メッセージに対応して正常を通知する監視応答メッセージを受信した場合（ステップＳ３１５：故障検知なし）、現用系、待機系のメディアサーバ４ａ、４ｂともそのまま処理を継続する（ステップＳ３２０）。

待機系のメディアサーバ４ｂの故障発生が検出された場合、例えば、メディアサーバ４ａの監視部４１ａが、メディアサーバ４ｂへ監視メッセージを送信してから所定時間以内に監視応答メッセージを受信しなかった、あるいは、メディアサーバ４ｂから故障を示す監視応答メッセージを受信した場合（ステップＳ３１５：待機系の故障検知）、現用系のメディアサーバ４ａは、そのまま処理を継続する（ステップＳ３２５）。ＬＡＮによりメディアサーバ４と接続され、ＩＶＲシステム全体の動作を管理する運用サーバ（図示せず）は、管理者宛のメール等を送信し、故障を通知する。

現用系のメディアサーバ４ａの故障発生が検出された場合、例えば、メディアサーバ４ｂの監視部４１ｂが、メディアサーバ４ａへ監視メッセージを送信してから所定時間以内に監視応答メッセージを受信しなかった、あるいは、メディアサーバ４ａから故障を示す監視応答メッセージを受信したりした場合（ステップＳ３１５：現用系の故障検知）、待機系のメディアサーバ４ｂの監視部４１ｂは、通信部４０ｂに現用系のメディアサーバ４ａのＩＰアドレスを引継ぐよう指示するとともに、メディア処理プログラム実行部４２ｂに後述する故障時フローの実行を指示する（ステップＳ３３０）。

図１０及び図１１は、本実施形態による現用系のメディアサーバ４における着信時の処理フローを示す図である。
図１０において、メディアサーバ４ａの呼処理部４３ａは、図７のステップＳ１０５〜Ｓ１１０に示すように、電話端末１から送信され、中継サーバ２により中継されたＩＮＶＩＴＥパケットを受信する（ステップＳ４０５）。

メディアサーバ４ａの呼処理部４３ａは、ＩＮＶＩＴＥパケットのＴｏフィールドから着信先の電話番号を取得して主記憶部４５ａに書き込む（ステップＳ４１０）。呼処理部４３ａから指示を受けた制御部４４ａは、外部記憶装置６に取得した電話番号を通知し、最大チャネル数及びアクティブチャネル数の読み出しを指示する。制御部４４ａは、外部記憶装置６が電話番号設定記憶部６１内の電話番号設定情報から電話番号に対応して読み出した最大チャネル数及びアクティブチャネル数を受信し、呼処理部４３ａに出力する。呼処理部４３ａは、アクティブチャネル数が最大チャネル数より小さい場合に、着信を許可する（ステップＳ４１５）。
なお、電話番号に対応したアクティブチャネル数や最大チャネル数が電話番号設定情報から読み出せなかった場合、あるいは、アクティブチャネル数が最大チャネル数以上であった場合、呼処理部４３ａはダイアログを確立せず、呼を終了させる。

呼処理部４３ａは、着信を許可する場合、ＳＩＰの仕様に従ってダイアログを確立するとともに、呼の再開に必要なＳＩＰの情報を主記憶部４５ａに書き込む（ステップＳ４２０）。具体的には、以下のように動作する。

呼処理部４３ａは、受信したＩＮＶＩＴＥパケットを主記憶部４５ａに書き込むとともに、ＩＮＶＩＴＥパケットに設定されているｆｒｏｍタグ、ｃａｌｌｉｄ、各種ヘッダフィールド、電話端末１が用いるＲＴＰポート番号及びＩＰアドレス、電話端末のＣＳｅｑを読み出して主記憶部４５ａに書き込む。なお、ＲＴＰポート番号及びＩＰアドレスは、ＡＣＫパケットから取得する場合もある。

呼処理部４３ａは、例えば、図７のステップＳ１１５〜Ｓ１４０の処理に示すように、ＳＩＰの仕様に従って１８０Ｔｒｉｎｇ、Ｒｉｎｇｉｎｇ、２００ＯＫの送信、ＡＣＫの受信を行なう。呼処理部４３ａは、送受信したこれらの各ＳＩＰパケットを主記憶部４５ａに書き込むとともに、これらのＳＩＰパケットに設定されている電話端末のＣＳｅｑやメディアサーバのＣＳｅｑメディアサーバのＣＳｅｑ、各種ヘッダフィールドを主記憶部４５ａに書き込む。

なお、呼処理部４３ａは、２００ＯＫを送信する際には、２００ＯＫに設定したｔｏタグと、メディアサーバ４ａが用いるＲＴＰポート番号及びＩＰアドレスとを主記憶部４５ａに書き込む。
また、各種ヘッダフィールドには、Ｔｏ、Ｆｒｏｍ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅ、Ｖｉａヘッダフィールドがあるが、Ｒｅｃｏｒｄ−Ｒｏｕｔｅ、Ｖｉａヘッダフィールドは取得できない場合もある。

電話端末１とのダイアログ確立後、制御部４４ａは、外部記憶装置６にステップＳ４１０において取得した電話番号を通知し、アクティブチャネル数の加算を指示する。外部記憶装置６は、電話番号により電話番号設定記憶部６１内の電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数に１を加算する（ステップＳ４２５）。

次に、メディアサーバ４ａの呼処理部４３ａから指示を受けた制御部４４ａは、主記憶部４５ａに記憶されているｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、メディアサーバのＣＳｅｑ、電話端末のＣＳｅｑ、ＩＮＶＩＴＥパケットのＴｏフィールドから取得した着信側の電話番号であるサーバ側電話番号、ＩＮＶＩＴＥパケットのＦｒｏｍフィールドから取得した発信側の電話番号である端末側電話番号、各種ヘッダフィールドと、着信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置６に出力し、呼処理復旧情報への登録を指示する（ステップＳ４３０）。外部記憶装置６は、呼処理復旧情報記憶部６３内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ４ａから受信した登録呼処理復旧情報を設定する。

さらに、メディアサーバ４ａの呼処理部４３ａから指示を受けた制御部４４ａは、主記憶部４５ａに記憶されているｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、メディアサーバ４ａが用いるＲＴＰポート番号及びＩＰアドレス、電話端末１が用いるＲＴＰポート番号及びＩＰアドレスを登録音声処理復旧情報として外部記憶装置６に出力し、音声処理復旧情報への登録を指示する（ステップＳ４３５）。外部記憶装置６は、音声処理復旧情報記憶部６４内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ４ａから受信した登録音声処理復旧情報を設定する。
メディアサーバ４ａの呼処理部４３ａは、制御部４４ａにダイアログの確立を通知する。

ダイアログの確立の通知を受信した制御部４４ａは、主記憶部４５ａから着信先の電話番号を読み出すと、外部記憶装置６に読み出した電話番号を通知してＩＶＲ ＩＤ及び最大チャネル数の読み出しを指示する。メディアサーバ４ａの制御部４４ａは、外部記憶装置６が電話番号に対応して電話番号設定記憶部６１内の電話番号設定情報から読み出したＩＶＲ ＩＤ及び最大チャネル数を受信し、主記憶部４５ａに書き込む（ステップＳ４４０）。

続いて、制御部４４ａは、外部記憶装置６に受信したＩＶＲ ＩＤを通知してＩＶＲフローシナリオの読み出しを指示する。制御部４４ａは、外部記憶装置６がＩＶＲ ＩＤに対応してＩＶＲフロー記憶部６２内のＩＶＲフローデータから読み出したＩＶＲフローシナリオを受信し、主記憶部４５ａに書き込む（ステップＳ４４５）。

次に、制御部４４ａは、外部記憶装置６に主記憶部４５ａから取得したｔｏタグ、ｆｒｏｍタグ、及び、ｃａｌｌｉｄを通知してコマンド実行履歴の読み出しを指示する。制御部４４ａは、外部記憶装置６がｔｏタグ、ｆｒｏｍタグ、及び、ｃａｌｌｉｄに対応してＩＶＲ処理情報記憶部６５内のＩＶＲ処理情報から読み出したコマンド実行履歴を受信し、主記憶部４５ａに書き込む（ステップＳ４５０）。なお、コマンド実行履歴が読み出せなかった場合は、初期状態であると判断する。

図１１において、制御部４４ａは、ＩＶＲ処理部４６ａに主記憶部４５ａに書き込んだＩＶＲシナリオとコマンド実行履歴を出力し、ＩＶＲフローの実行を指示する。ＩＶＲ処理部４６ａは、コマンド実行履歴がなく、初期状態であると判断した場合、ＩＶＲシナリオを最初から実行する。コマンド実行履歴に実行したコマンドが設定されている場合、そのコマンドにより示される途中のＩＶＲ処理からＩＶＲシナリオを実行する（ステップＳ５０５）。

音声処理部４７ａは、制御部４４ａの指示を受け、自メディアサーバ４ａが使用するＳＳＲＣ及びＲＴＰシーケンスナンバを生成すると、主記憶部４５ａから自メディアサーバ４ａが用いるＲＴＰポート番号及びＩＰアドレスと、電話端末１が用いるＲＴＰポート番号及びＩＰアドレスを読み出し、これらの情報を用いて電話端末１との間のＲＴＰセッションを確立し、ＲＴＰパケットの送受信を開始する（ステップＳ５１０）。制御部４４ａは、メディアサーバのＳＳＲＣ、最初に送信したＲＴＰパケットに設定したＲＴＰシーケンスナンバ、ＲＴＰセッションを開始した時間を示す発着信開始時間を主記憶部４５ａに書き込む。

制御部４４ａは、ＲＴＰセッションが確立され、ＲＴＰパケットの送受信が行なわれると、主記憶部４５ａからｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、メディアサーバのＳＳＲＣ、メディアサーバ４ａが電話端末１とのＲＴＰセッションにおいて最初に使用したＲＴＰシーケンスナンバ、当該ＲＴＰセッションにおいて最初にＲＴＰパケットを送信した時刻である発着開始時間を外部記憶装置６に通知し、音声処理復旧情報の更新を指示する（ステップＳ５１５）。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄにより音声処理復旧情報記憶部６４内の音声処理復旧情報のレコードを特定し、特定したレコードにメディアサーバ４のＳＳＲＣ及びＲＴＰシーケンスナンバと、発着開始時間とを書き込む。なお、ｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄに対応したレコードが音声処理復旧情報に登録されていない場合、新たなレコードを追加し、追加したレコードにメディアサーバ４のＳＳＲＣ及びＲＴＰシーケンスナンバと、発着開始時間とを書き込む。

メディアサーバ４ａは、ＩＶＲシナリオを実行していく。具体的には、音声処理部４７ａは、ＩＶＲ処理部４６ａからの指示により、電話端末１に対して再生音声のＲＴＰパケットを送信し、エンドユーザにガイダンスを聞かせたり、電話端末１から受信したＲＴＰパケットにより示されるＤＴＭＦや発話内容などをＩＶＲ処理部４６ａが認識したりする。ＩＶＲ処理部４６ａは、ＤＴＭＦやエンドユーザの発話などの音声を認識する度にその認識結果をＩＶＲ処理情報に追加するよう制御部４４ａに指示する。また、ＩＶＲ処理部４６ａは、音声認識や音声再生などコマンドをひとつ実行する度に、現在実行しているＩＶＲフローの位置を特定する情報をコマンド実行履歴としてＩＶＲ処理情報記憶部６５に書き込むよう制御部４４ａに指示する。具体的には、制御部４４ａは、現在処理中の呼のｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄと、認識結果あるいはコマンド実行履歴を通知して、ＩＶＲ処理情報の更新を外部記憶装置６に指示する（ステップＳ５２０）。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄによりＩＶＲ処理情報記憶部６５内のＩＶＲ処理情報のレコードを特定し、特定したレコードに認識結果あるいはコマンド履歴を書き込む。

メディアサーバ４ａは、１５０秒以上など所定の時間以上通話が継続する場合（ステップＳ５２５：ＹＥＳ）、ＩＶＲフローを実行の合間に、セッションの継続確認処理を行なう。つまり、メディアサーバ４ａの呼処理部４３ａは、所定の時間以上通話が継続していることを検出した場合、定期的にｒｅ−ＩＮＶＩＴＥパケットあるいはＵＰＤＡＴＥパケットを電話端末１に送信する（ステップＳ５３０）。
制御部４４ａは、呼処理部４３ａがｒｅ−ＩＮＶＩＴＥパケットあるいはＵＰＤＡＴＥパケットを送信することにより更新されたメディアサーバのＣＳｅｑにより呼処理復旧情報を更新する。つまり、制御部４４ａは、現在処理中の呼のｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄと、更新されたメディアサーバのＣＳｅｑを外部記憶装置６に通知して、呼処理復旧情報の更新を指示する。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄにより呼処理復旧情報記憶部６３内の呼処理復旧情報のレコードを特定し、特定したレコードに記述されているメディアサーバのＣＳｅｑを、受信したＣＳｅｑにより更新する。

また、メディアサーバ４ａの呼処理部４３ａが、電話端末１からｒｅ−ＩＮＶＩＴＥパケットあるいはＵＰＤＡＴＥパケットを受信する場合もある。この場合、呼処理部４３ａは、受信したｒｅ−ＩＮＶＩＴＥパケットあるいはＵＰＤＡＴＥパケットのパケットからｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、及び、電話端末のＣＳｅｑを読み出して、制御部４４ａに出力する。制御部４４ａは、呼処理部４３ａから受信したｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ及び電話端末のＣＳｅｑを外部記憶装置６に通知して、呼処理復旧情報の更新を指示する。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄにより呼処理復旧情報記憶部６３内の呼処理復旧情報のレコードを特定し、特定したレコードに記述されている電話端末のＣＳｅｑを、受信した電話端末のＣＳｅｑにより更新する。

電話端末１からの通信断により通話が終了する場合、電話端末１からＢＹＥパケットがメディアサーバ４ａに送信される（ステップＳ５２５：ＮＯ、ステップＳ５３０：エンドユーザからの通信断）。メディアサーバ４ａの呼処理部４３ａは、電話端末１から送信されたＢＹＥパケットを受信すると、このパケットからｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄを取得して制御部４４ａに出力する。
制御部４４ａは、呼処理部４３ａから受信したｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄをＩＶＲ処理部４６ａに出力し、ＩＶＲ処理の終了を指示する。制御部４４ａは、呼処理部４３ａから受信したｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄにより特定される呼に対して実行していたＩＶＲフローシナリオの実行を終了する（ステップＳ５４０）。
さらに、制御部４４ａは、呼処理部４３ａから受信したｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄを音声処理部４７ａに出力し、ＲＴＰセッションの終了を指示する。音声処理部４７ａは、呼処理部４３ａから受信したｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄにより特定される呼について確立していたセッションを終了する（ステップＳ５４５）。
呼処理部４３ａは、ＢＹＥパケットの応答として電話端末１に２００ＯＫを返送する（ステップＳ５５０）。

あるいは、ＩＶＲフローが最後まで実行された場合、メディアサーバ４ａからの通信断により通話が終了する（ステップＳ５２５：ＮＯ、ステップＳ５３０：メディアサーバからの通信断）。ＩＶＲ処理部４６ａは、制御部４４ａに対してＩＶＲフロー実行終了を通知する。
制御部４４ａが呼処理部４３ａにＩＶＲフロー実行終了を通知すると、呼処理部４３ａは、電話端末１にＢＹＥパケットを送信し（ステップＳ５５５）、電話端末１に通話終了を指示する。さらに、制御部４４ａは、音声処理部４７ａに停止命令を出力し、ＲＴＰセッションの終了を指示する。音声処理部４７ａは、電話端末１との間で確立していたセッションを終了する（ステップＳ５６０）。最後に、呼処理部４３ａは、電話端末１からＢＹＥパケットの応答として２００ＯＫを受信する（ステップＳ５６５）。

上記のいずれかにより通話が終了したことを認識したメディアサーバ４ａの制御部４４ａは、ステップＳ５５０またはＳ５６５の後、主記憶部４５ａから終了した呼のｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄを読み出して外部記憶装置６へ送信し、呼処理復旧情報、音声処理復旧情報、及び、ＩＶＲ処理情報の削除を指示する。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄにより特定される呼処理復旧情報のレコード、音声処理復旧情報のレコード、及び、ＩＶＲ処理情報のレコードを削除する（ステップＳ５７０）。

さらに、メディアサーバ４ａの制御部４４ａは、終了した呼に対して実行していたＩＶＲフローシナリオのＩＶＲ ＩＤを外部記憶装置６へ送信し、アクティブチャネル数の減算を指示する（ステップＳ５７５）。外部記憶装置６は、ＩＶＲ ＩＤにより電話番号設定記憶部６１が記憶している電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数を、１を減算した数に更新する。

図１２は、本実施形態による現用系のメディアサーバ４における発信時の処理フローを示す図である。
メディアサーバ４ａの制御部４４ａは、発信制御装置７から発信指示を受信する（ステップＳ６０５）。発信指示には、サーバ側電話番号及び端末側電話番号が設定される。

メディアサーバ４ａの呼処理部４３ａは、発信指示から取得したサーバ側電話番号を外部記憶装置６に通知し、最大チャネル数及びアクティブチャネル数の読み出しを指示する（ステップＳ６１０）。制御部４４ａは、外部記憶装置６が電話番号に対応して電話番号設定記憶部６１内の電話番号設定情報から読み出した最大チャネル数及びアクティブチャネル数を受信すると、これらを比較する。制御部４４ａは、アクティブチャネル数が最大チャネル数より小さい場合に着信を許可し、呼処理部４３ａに発信を指示する。
なお、サーバ側電話番号が電話番号設定情報に設定されていない場合、あるいは、アクティブチャネル数が最大チャネル数以上であった場合、制御部４４ａは発信を指示せず、処理を終了する。

制御部４４ａから発信指示を受けた呼処理部４３ａは、ＳＩＰの仕様に従って電話端末１とのダイアログを確立するとともに、呼の再開に必要なＳＩＰの情報を主記憶部４５ａに書き込む（ステップＳ６１５）。具体的には、以下のように動作する。

呼処理部４３ａは、ＩＮＶＩＴＥパケットを生成し、電話端末１に送信する。ＩＮＶＩＴＥパケットのＴｏフィールドには発信制御装置７から受信した端末側電話番号が、Ｆｒｏｍフィールドには発信制御装置７から受信したサーバ側電話番号と、生成したｆｒｏｍタグが設定される。
制御部４４ａは、ＩＮＶＩＴＥパケットを主記憶部４５ａに書き込むとともに、ＩＮＶＩＴＥパケットに設定したｆｒｏｍタグ、ｃａｌｌｉｄ、各種ヘッダフィールド、メディアサーバ４のＲＴＰポート番号及びＩＰアドレス、メディアサーバのＣＳｅｑを読み出して主記憶部４５ａに書き込む。なお、ＲＴＰポート番号及びＩＰアドレスは、ＡＣＫパケットに設定される場合もある。

呼処理部４３ａは、一般的なＳＩＰの仕様に従って、１８０Ｔｒｉｎｇ、Ｒｉｎｇｉｎｇ、２００ＯＫの受信、ＡＣＫの送信を行ない、電話端末１とのダイアログを確立する。呼処理部４３ａは、送受信したこれらの各ＳＩＰパケットを主記憶部４５ａに書き込むとともに、これらのＳＩＰパケットに設定されている電話端末のＣＳｅｑやメディアサーバのＣＳｅｑ、各種ヘッダフィールドを主記憶部４５ａに書き込む。
なお、呼処理部４３ａは、電話端末１から受信した２００ＯＫから、ｔｏタグと、電話端末１が用いるＲＴＰポート番号及びＩＰアドレスを取得して主記憶部４５ａに書き込む。
また、各種ヘッダフィールドには、Ｔｏ、Ｆｒｏｍ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅ、Ｖｉａヘッダフィールドがあるが、Ｒｅｃｏｒｄ−Ｒｏｕｔｅ、Ｖｉａヘッダフィールドは取得できない場合もある。

電話端末１とのダイアログ確立後、制御部４４ａは、ステップＳ６１０において受信した発信指示から取得した電話番号を外部記憶装置６に通知し、アクティブチャネル数の加算を指示する。外部記憶装置６は、電話番号により電話番号設定記憶部６１内の電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数に１を加算する（ステップＳ６２０）。

以降、メディアサーバ４ａは、図１０のステップＳ４３０以降と同様の処理を行なう。ただし、ステップＳ４３０において、登録呼処理復旧情報には、発信を示す発着信フラグ、ＩＮＶＩＴＥのＦｒｏｍフィールドから取得した発信側の電話番号であるサーバ側電話番号、ＩＮＶＩＴＥパケットのＴｏフィールドから取得した着信側の電話番号である端末側電話番号が設定される。

図１３は、本実施形態による現用系のメディアサーバ４の故障が検出されたときに待機系のメディアサーバ４が実行する復旧処理フローを示す図である。
ＩＶＲ処理中にメディアサーバ４ａの故障が発生した場合、図９に示すように待機系のメディアサーバ４ｂの監視部４１ｂが現用系の故障を検出する。メディアサーバ４ｂの監視部４１ｂは、復旧処理部４８を起動する（ステップＳ７０５）。復旧処理部４８ｂは、通信部４０ｂにメディアサーバ４ａの通信部４０ａが使用していたＩＰアドレスを引継がせ、メディアサーバ４ｂは現用系として起動する。

メディアサーバ４ｂの復旧処理部４８ｂは、外部記憶装置６の呼処理復旧情報記憶部６３に記憶されている呼処理復旧情報を１レコードずつ特定し、特定したレコードを読み出して主記憶部４５ｂに書き込むとともに、当該レコードからｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄを読み出して（ステップＳ７１０）、以下の処理を行なう。なお、外部記憶装置６からｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄのみを読み出すことでもよい。

制御部４４ｂは、ステップＳ７１０において取得したｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄの組を外部記憶装置６に通知し、音声処理復旧情報、及び、ＩＶＲ処理情報の読み出しを指示する（ステップＳ７１５）。制御部４４ｂは、外部記憶装置６が各ｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄの組に対応して読み出した音声処理復旧情報記憶部６４内の音声処理復旧情報のレコード、及び、ＩＶＲ処理情報記憶部６５内のＩＶＲ処理情報内のレコードを受信し、主記憶部４５ｂに書き込む。

さらに、制御部４４ｂは、ステップＳ７１０において主記憶部４５ｂに保存した呼処理復旧情報記のレコードからサーバ側電話番号を取得すると、外部記憶装置６に取得したサーバ側電話番号を通知してＩＶＲ ＩＤの読み出しを指示する。制御部４４ｂは、外部記憶装置６がサーバ側電話番号に対応して電話番号設定記憶部６１内の電話番号設定情報から読み出したＩＶＲ ＩＤを受信する。まだこのＩＶＲ ＩＤに対応したＩＶＲフローを読み出していない場合、制御部４４ｂは、外部記憶装置６に受信したＩＶＲ ＩＤを通知してＩＶＲフローシナリオの読み出しを指示する。制御部４４ｂは、外部記憶装置６がＩＶＲ ＩＤに対応してＩＶＲフロー記憶部６２内のＩＶＲフローデータから読み出したＩＶＲフローシナリオを受信し、主記憶部４５ｂに書き込む。

なお、コマンドの番号によりＩＶＲフローシナリオが特定可能な場合、メディアサーバ４ｂの制御部４４ｂは、ステップＳ７１５において主記憶部４５ｂに保存したＩＶＲ処理情報のレコード内のコマンド実行履歴からコマンドを読み出して外部記憶装置６に通知し、ＩＶＲフローシナリオの読み出しを指示する。外部記憶装置６は、ＩＶＲフロー記憶部６２内のＩＶＲフローデータから、コマンドに対応したＩＶＲ処理が含まれているＩＶＲフローを読み出してメディアサーバ４ｂへ出力する。

メディアサーバ４ｂの音声処理部４７ｂは、ステップＳ７１５において主記憶部４５ｂに保存したＩＶＲ処理情報のレコード内のコマンド実行履歴からコマンドを読み出す。ＩＶＲ処理部４７ｂは、主記憶部４５ｂに記憶されているＩＶＲシナリオを、読み出したコマンドにより特定されるＩＶＲ処理から実行することによって、ＩＶＲ処理を途中から再開する（ステップＳ７２０）。

音声処理部４７ｂは、ステップＳ７１５において制御部４４ｂが特定したＩＶＲ処理情報のレコードに設定されている値を用いて、電話端末１との間のＲＴＰセッションを再開する（ステップＳ７２５）。
具体的には、制御部４４ｂが、ステップＳ７１５において読み出した音声処理復旧情報のレコードから発着信開始時間とメディアサーバ４のＲＴＰシーケンスナンバを読み出す。制御部４４ｂは、発着信開始時間から現在の時間までの経過時間を算出すると、この経過時間をＲＴＰパケットの送出間隔で除算することにより、ＲＴＰシーケンスナンバの増加分を算出する。ＲＴＰの受信側では、ＲＴＰシーケンスナンバが１ずつ増加しているかの検証を行なっているため、算出した増加分に所定の定数を加算するなどし、エラーとならない範囲の値としてもよい。制御部４４ｂは、音声処理復旧情報のレコードから読み出したＲＴＰシーケンスナンバに、算出した増加分を加算して、音声処理部４７ｂから送信する最初のＲＴＰパケットに設定すべきＲＴＰシーケンスナンバを算出すると、音声処理部４７ｂへ通知する。また、制御部４４ｂは、通信部４０ｂに指示し、読み出した音声処理復旧情報のレコードで示されるメディアサーバのＲＴＰポートとＩＰアドレスをオープンする。

音声処理部４７ｂは、ＩＶＲ処理による音声をＲＴＰパケットにより電話端末１へ送信するとともに、電話端末１から送信されたＲＴＰパケットを受信する。電話端末１に送信されるＲＴＰパケットには、ステップＳ７１５において読み出したＩＶＲ処理情報のレコードに設定されているメディアサーバ４のＳＳＲＣと、電話端末１のＲＴＰポート番号及びＩＰアドレスが用いられる。最初にメディアサーバ４ｂから送信するＲＴＰパケットには、制御部４４ｂから通知されたＲＴＰシーケンスナンバを用いる。また、音声処理部４７ｂは、ステップＳ７１５において読み出したＩＶＲ処理情報のレコードに設定されているメディアサーバ４のＲＴＰポート番号及びＩＰアドレスを用いたＲＴＰパケットを電話端末１から受信する。

続いて復旧処理部４８ｂは、外部記憶装置６の呼処理復旧情報記憶部６３に記憶されている呼処理復旧情報の中で、まだ読み出していないレコードがあるかを判断し（ステップＳ７３０）、まだ読み出していないレコードがあれば（ステップＳ７３０：ＹＥＳ）、ステップＳ７１０からの処理を行う。一方、全てのレコードについて読み出しを行なったならば（ステップＳ７３０：ＮＯ）、メディアサーバ４ｂにおいて、以降、メディアサーバ４ａが行なっていたステップＳ５２０からの処理を行なう。つまり、各部の符号の最後記載されている「ａ」を「ｂ」に置き換えればよい。

なお、本実施形態のメモリ情報共有方式は、基本的には全てのデータを外部記憶装置６に保持する。そのため、電話端末１からＳＩＰ信号を受信すると、メディアサーバ４の呼処理部４３は、受信したＳＩＰ信号から取得したｔｏタグ、ｆｒｏｍタグ、及び、ｃａｌｌｉｄタグにより特定される外部記憶装置６内の呼処理復旧情報、音声処理復旧情報のレコードに対して情報の参照や書込みを行い、呼処理を実行する。ただし、処理の高速化のために外部記憶装置６と同様の情報をメディアサーバ４の主記憶部４５上に保持し、データを読むだけの場合は主記憶部４５から情報を取得し、データに更新があった場合のみ外部記憶装置６にアクセスして情報を更新するようにしてもよい。

［第２の実施形態：メモリ情報再構築方式］
次に、本発明の第２の実施形態によるＩＶＲシステムについて説明する。
本実施形態では、メモリ情報再構築方式によるフェールオーバを実現する。メモリ情報再構築方式では、メディアサーバ４は、ＳＩＰの処理を実行するための情報を自サーバ内のメモリに保持しており、受信したＩＮＶＩＴＥパケットや２００ＯＫパケット等のパケット自体を外部記憶装置６に記憶しておく。そして、現用系のメディアサーバ４が故障時した時には、待機系のメディアサーバ４が外部記憶装置６からＩＮＶＩＴＥパケットやＡＣＫパケットを読み込み、自らに当該パケットを送信して現用系が故障前に保持していたメモリの内容を待機系のメモリに再構築して状態復帰処理を行う。なお、待機系のメディアサーバ４は、自身が送信した状態復帰用のパケットに暫定応答を返さない等の特別なロジックを実装する必要がある。なお、ＲＴＰ関連の情報及びＩＶＲ関連の情報の保存や復旧については、メモリ情報共有方式と同様である。

上記のように、メモリ情報再構築方式は、現用系のメディアサーバ４の故障時は現用系が受信したパケットを待機系のメディアサーバ４に送信することで、待機系のメディアサーバ４が保持するメモリ情報を、現用系のメディアサーバ４と同じように復旧させる方式であり、メモリ情報共有方式に比べて改修範囲が少ないため、実装が比較的容易である。
以下では、第１の実施形態との差分について説明する。

本実施形態によるＩＶＲシステムの構成は、図１に示す第１の実施形態によるＩＶＲシステムの構成と同様である。
また、本実施形態による外部記憶装置６に記憶されるＩＶＲフローデータ、電話番号設定情報、及び、ＩＶＲ処理情報は、第１の実施形態と同様である。

図１４は、本実施形態による呼処理復旧情報記憶部６３に記憶される呼処理復旧情報のデータ構成例を示す図である。同図に示すように、呼処理復旧情報は、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、ＩＮＶＩＴＥパケット、ＡＣＫパケット、２００ＯＫパケット、メディアサーバのＣＳｅｑ、電話端末のＣＳｅｑ、発着信フラグ、サーバ側電話番号、端末側電話番号を対応付けたレコードからなり、各レコードは通話単位で生成される。メディアサーバ４への着信時にＩＮＶＩＴＥパケット、ＡＣＫパケットが保存され、メディアサーバ４からの発信時に２００ＯＫパケットが保存される。

図１５は、本実施形態による音声処理復旧情報記憶部６４に記憶される音声処理復旧情報のデータ構成例を示す図である。同図に示すように、音声処理復旧情報は、ｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、発着信開始時間、メディアサーバ４のＲＴＰシーケンスナンバ、ＳＳＲＣ、ＲＴＰポート番号及びＩＰアドレスを対応付けたレコードからなり、各レコードは通話単位で生成される。なお、電話端末のＲＴＰポート番号及びＩＰアドレスは呼処理復旧情報に記録されているＳＩＰメッセージ中に記述される。

図１６は、本実施形態によるＩＶＲシステムにおける故障発生時のシーケンスを示す図である。
同図において、ステップＳ８０５〜Ｓ8４０までの処理は、図８のステップＳ２０５〜Ｓ２４０の処理と同様である。
メディアサーバ４ｂはメディアサーバ４ａの故障を検知すると、外部記憶装置６から呼処理復旧情報を読み出す（ステップＳ８４５）。メディアサーバ４ｂは、読込んだ呼処理復旧情報を用い、電話端末１から受信したものと同じＳＩＰパケットを内部的に自メディアサーバ４ｂ宛に送信する。ただし、この内部的に受信したＳＩＰパケットに対する応答は電話端末１へは送信しない。これにより、メディアサーバ４ｂは、ＳＩＰ処理に必要な情報を構築して主記憶部４５ｂに記憶する（ステップＳ８５０）。
以降、ステップＳ８５５〜Ｓ８８０までの処理は、図８のステップＳ２４５〜Ｓ２７０の処理と同様である。
ステップＳ８８５において、電話端末１からＳＩＰパケットを受信すると、メディアサーバ４ｂは、ステップＳ８５０において構築し、内部に記憶している情報を参照して、すでに確立済みのセッションのＳＩＰパケットかを確認する（ステップＳ８８５）。

次に、本実施形態によるメディアサーバ４における処理フローについて説明する。本実施形態による監視フローは、図１２に示す第１の実施形態と同様である。

図１７は、本実施形態による電話端末１から現用系のメディアサーバ４への着信時のシーケンス例を示す図である。
同図において、ステップＳ９０５〜Ｓ９２５までの処理は、図１０に示すＳ４０５〜Ｓ４２５までの処理と同様である。
ステップＳ９３０において、メディアサーバ４ａの呼処理部４３ａから指示を受けた制御部４４ａは、主記憶部４５ａに記憶されているｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、ＩＮＶＩＴＥパケット、ＡＣＫパケット、メディアサーバのＣＳｅｑ、電話端末のＣＳｅｑと、着信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置６に出力し、呼処理復旧情報への登録を指示する（ステップＳ９３０）。外部記憶装置６は、呼処理復旧情報記憶部６３内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ４ａから受信した登録呼処理復旧情報を設定する。

さらに、メディアサーバ４ａの呼処理部４３ａから指示を受けた制御部４４ａは、主記憶部４５ａに記憶されているｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、メディアサーバ４ａが用いるＲＴＰポート番号及びＩＰアドレスを登録音声処理復旧情報として外部記憶装置６に出力し、音声処理復旧情報への登録を指示する（ステップＳ９３５）。外部記憶装置６は、音声処理復旧情報記憶部６４内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ４ａから受信した登録音声処理復旧情報を設定する。
メディアサーバ４ａの呼処理部４３ａは、制御部４４ａにダイアログの確立を通知する。以降は、図１０のステップＳ４４０からの処理を行う。

図１８は、本実施形態による現用系のメディアサーバ４における発信時の処理フローを示す図である。
同図において、ステップＳ１００５〜Ｓ１０２０までの処理は、図９に示すＳ６０５〜Ｓ６２０までの処理と同様である。
ステップＳ１０２５において、メディアサーバ４ａの呼処理部４３ａから指示を受けた制御部４４ａは、主記憶部４５ａに記憶されているｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、２００ＯＫパケット、メディアサーバのＣＳｅｑ、電話端末のＣＳｅｑ、サーバ側電話番号、端末側電話番号と、発信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置６に出力し、呼処理復旧情報への登録を指示する（ステップＳ１０２５）。外部記憶装置６は、呼処理復旧情報記憶部６３内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ４ａから受信した登録呼処理復旧情報を設定する。

さらに、メディアサーバ４ａの呼処理部４３ａから指示を受けた制御部４４ａは、主記憶部４５ａに記憶されているｔｏタグ、ｆｒｏｍタグ、ｃａｌｌｉｄ、メディアサーバ４ａが用いるＲＴＰポート番号及びＩＰアドレスを登録音声処理復旧情報として外部記憶装置６に出力し、音声処理復旧情報への登録を指示する（ステップＳ１０３０）。外部記憶装置６は、音声処理復旧情報記憶部６４内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ４ａから受信した登録音声処理復旧情報を設定する。
メディアサーバ４ａの呼処理部４３ａは、制御部４４ａにダイアログの確立を通知する。以降は、図１０のステップＳ４４０からの処理を行う。

図１９は、本実施形態による現用系のメディアサーバ４の故障が検出されたときに待機系のメディアサーバ４が実行する復旧処理フローを示す図である。
ＩＶＲ処理中にメディアサーバ４ａの故障が発生した場合のステップＳ１１０５〜Ｓ１１１５におけるメディアサーバ４ｂの処理は、図１３のステップＳ７０５〜Ｓ７１５までの処理と同じである。ただし、ステップＳ１１１０において、復旧処理部４８ｂは、特定した外部記憶装置６から、呼処理復旧情報のレコードから読み出したｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄと、発着信フラグとを受信する。

ステップＳ１１１０において読み出した発着信フラグが着信を示している場合（ステップＳ１１２０：着信）、復旧処理部４８ｂからの指示を受けた制御部４４ｂは、ステップＳ１１１０において読み出したｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄを外部記憶装置６に出力し、ＩＮＩＶＩＴＥパケット及びＡＣＫパケットの読み出しを指示する（ステップＳ１１２５）。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄにより呼処理復旧情報記憶部６３内の呼処理復旧情報のレコードを特定し、特定したレコードからＩＮＶＩＴＥパケット及びＡＣＫパケットを読み出してメディアサーバ４ｂに出力する。

復旧処理部４８ｂは、外部記憶装置６から読み出したＩＮＶＩＴＥパケットを呼処理部４３ｂに対して内部的に送信する。これにより、呼処理部４３ｂは、ＩＮＶＩＴＥパケット受信時の処理と同様の処理を行なう（ステップＳ１１３０）。呼処理部４３ｂは、図１０のステップＳ４２０における処理と同様に、ＩＮＶＩＴＥパケットを主記憶部４５ｂに書き込むとともに、ＩＮＶＩＴＥパケットに設定されているｆｒｏｍタグ、ｃａｌｌｉｄ、各種ヘッダフィールド、電話端末１が用いるＲＴＰポート番号及びＩＰアドレス、電話端末のＣＳｅｑを読み出して主記憶部４５ｂに書き込む。

続いて、呼処理部４３ｂは、ステップＳ１１３０において内部的に送信されたＩＮＶＩＴＥパケットに対する２００ＯＫパケットを生成し、２００ＯＫパケットを送信した場合と同様の処理を行なう（ステップＳ１１３５）。２００ＯＫのメディアサーバ４のＲＴＰポート番号及びＩＰアドレスには、ステップＳ１１１５において読み出した音声処理復旧情報のレコード内のＲＴＰポート番号及びＩＰアドレスが設定される。また、２００ＯＫパケットのＴｏフィールドには、ステップＳ１１１０において読み出したｔｏタグを使用する。なお、実際には２００ＯＫパケットの送信は行なわない。これにより、図１０のステップＳ４２０における処理と同様に、呼処理部４３ｂは、この生成した２００ＯＫパケットを主記憶部４５ｂに書き込むとともに、２００ＯＫに設定したｔｏタグと、メディアサーバ４ｂが用いるＲＴＰポート番号及びＩＰアドレス、メディアサーバのＣＳｅｑ、各種ヘッダフィールドを主記憶部４５ｂに書き込む。

続いて、復旧処理部４８ｂは、ステップＳ１１２５において外部記憶装置６から読み出したＡＣＫパケットを呼処理部４３ｂに対して内部的に送信する。これにより、呼処理部４３ｂは、ＡＣＫパケット受信時の処理と同様の処理を行なう（ステップＳ１１４０）。呼処理部４３ｂは、図１０のステップＳ４２０における処理と同様に、送信したこのＡＣＫパケットを主記憶部４５ｂに書き込むとともに、各種ヘッダフィールドを主記憶部４５ｂに書き込む。
上記処理により、メディアサーバ４ｂは、図１７のステップＳ９２０と同じ状態になる。

一方、ステップＳ１１１０において読み出した発着信フラグが発信を示している場合（ステップＳ１１２０：発信）、ステップＳ１１１０において読み出したｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄを外部記憶装置６に出力し、呼処理復旧情報の読み出しを指示する（ステップＳ１１４５）。外部記憶装置６は、ｔｏタグ、ｆｒｏｍタグ及びｃａｌｌｉｄにより呼処理復旧情報記憶部６３内の呼処理復旧情報のレコードを特定し、特定したレコードを読み出してメディアサーバ４ｂに出力する。

復旧処理部４８ｂからの指示を受け呼処理部４３ｂは、外部記憶装置６から読み出した呼処理復旧情報のレコードからＩＮＶＩＴＥパケットを生成する。これにより、呼処理部４３ｂは、ＩＮＶＩＴＥパケット送信時の処理と同様の処理を行なうが、実際には送信を行なわない（ステップＳ１１５０）。ＩＮＶＩＴＥ信号のＴｏフィールドには読み出した呼処理復旧情報のレコード内の端末側電話番号が、Ｆｒｏｍフィールドには当該呼処理復旧情報のレコード内のサーバ側電話番号とｆｒｏｍタグが、ｃａｌｌｉｄには読み出した当該呼処理復旧情報のレコード内のｃａｌｌｉｄが、メディアサーバのＣＳｅｑには１が、メディアサーバ４のＲＴＰポート及びアドレスにはステップＳ１１１５において読み出した音声処理復旧情報のレコードから読み出したＲＴＰポート番号及びＩＰアドレスが設定される。呼処理部４３ｂは、図１２のステップＳ６１５における処理と同様に、呼処理部４３ｂは、ＩＮＶＩＴＥパケットを主記憶部４５ｂに書き込むとともに、ＩＮＶＩＴＥパケットに設定されているｆｒｏｍタグ、ｃａｌｌｉｄ、各種ヘッダフィールド、メディアサーバ４ｂが用いるＲＴＰポート番号及びＩＰアドレス、メディアサーバのＣＳｅｑを読み出して主記憶部４５ｂに書き込む。

続いて、復旧処理部４８ｂは、ステップＳ１１５０において読み出した呼処理復旧情報のレコードに設定されている２００ＯＫを呼処理部４３ｂに対して内部的に送信する。これにより、呼処理部４３ｂは、２００ＯＫパケット受信時の処理と同様の処理を行なう（ステップＳ１１５５）。呼処理部４３ｂは、図１２のステップＳ６１５における処理と同様に、受信した２００ＯＫパケットを主記憶部４５ｂに書き込むとともに、ｔｏタグ、電話端末１が用いるＲＴＰポート番号及びＩＰアドレス、電話端末のＣＳｅｑ、各種ヘッダフィールドを主記憶部４５ｂに書き込む。

続いて、復旧処理部４８ｂは、ＡＣＫパケットを生成するとともに、ＡＣＫパケットを送信した場合と同様の処理を行なう（ステップＳ１１６０）。ＡＣＫパケットには、ＩＮＶＩＴＥ信号と同様のＴｏフィールド、Ｆｒｏｍフィールド、ｃａｌｌｉｄ、メディアサーバのＣＳｅｑが設定される。ただし、実際にはＡＣＫパケットの送信は行なわない。これにより、図１２のステップＳ６１５における処理と同様に、呼処理部４３ｂは、このＡＣＫパケットを主記憶部４５ｂに書き込むとともに、ＡＣＫに設定したｆｒｏｍタグと、メディアサーバのＣＳｅｑを主記憶部４５ｂに書き込む。
上記により、メディアサーバ４ｂは、図１８のステップＳ１０１５と同じ状態になる。

メディアサーバ４ｂの音声処理部４７ｂは、図１３のステップＳ７２０と同様の処理により主記憶部４５ｂに保存されたＩＶＲ処理情報のレコードを用いてＩＶＲ処理を途中から再開し（ステップＳ１１６５）、音声処理部４７ｂは、図１３のステップＳ７２５と同様の処理により、ステップＳ１１１５において制御部４４ｂが特定したＩＶＲ処理情報のレコードに設定されている値を用いて、電話端末１との間のＲＴＰセッションを再開する（ステップＳ１１７０）。

続いて復旧処理部４８ｂは、外部記憶装置６の音声処理復旧情報記憶部６４に記憶されている音声処理復旧情報の中で、まだ読み出していないレコードがあるかを判断し（ステップＳ１１７５）、まだ読み出していないレコードがあれば（ステップＳ１１７５：ＹＥＳ）、ステップＳ１１１０からの処理を行う。一方、全てのレコードについて読み出しを行なったならば（ステップＳ１１７５：ＮＯ）、メディアサーバ４ｂにおいて、以降、メディアサーバ４ａが行なっていたステップＳ５２０からの処理を行なう。つまり、各部の符号の最後に記載されている「ａ」を「ｂ」に置き換えればよい。

上述したように、本実施形態によれば、現用系のメディアサーバは、セッションが確立したときにＳＩＰ、ＲＴＰの復旧に必要な情報を外部記憶装置に書込み、ＩＶＲ処理が開始されると、外部記憶装置にＩＶＲ処理の更新状況をリアルタイムに書込み、ＲＴＰに関する情報は書き込まない。よって、外部記憶装置に対するアクセスの負荷をかけすぎることなく、メディアサーバは故障が発生した際に引継ぎが必要な情報を外部記憶装置に書き込むことができ、音声パケットに遅延を発生させることもない。なお、ＳＩＰの更新情報はセッション確立後も外部記憶装置へ書込む場合がある。通話中に現用系のメディアサーバが故障した場合も、通話がとぎれることなく、待機系のメディアサーバは、故障が発生した時点から引続きＩＶＲシナリオを提供することができる。このように、メディアサーバのセッションフェールオーバを実現することができるため、信頼性の高いシステムを実現することが可能となる。

上述の電話端末１、中継サーバ２、メディアサーバ４、外部記憶装置６、及び、発信制御装置７は、内部にコンピュータシステムを有している。そして、電話端末１、中継サーバ２、メディアサーバ４の監視部４１及びメディア処理プログラム実行部４２、外部記憶装置６、ならびに、発信制御装置７の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

なお、本発明は、上記において説明した実施形態に限定されるものではなく、その主旨を逸脱しない範囲において種々変更可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

１…電話端末
２…中継サーバ
３…ルータ
４、４ａ、４ｂ…メディアサーバ
４０、４０ａ、４０ｂ…通信部
４１、４１ａ、４１ｂ…監視部
４２、４２ａ、４２ｂ…メディア処理プログラム実行部
４３、４３ａ、４３ｂ…呼処理部
４４、４４ａ、４４ｂ…制御部
４５、４５ａ、４５ｂ…主記憶部
４６、４６ａ、４６ｂ…ＩＶＲ処理部
４７、４７ａ、４７ｂ…音声処理部
４８、４８ａ、４８ｂ…復旧処理部
６…外部記憶装置
６０…記憶部
６１…電話番号設定記憶部
６２…ＩＶＲフロー記憶部
６３…呼処理復旧情報記憶部
６４…音声処理復旧情報記憶部
６５…ＩＶＲ処理情報記憶部
７…発信制御装置

Claims (7)

1. ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバであって、
   前記ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理部と、
   音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理部と、
   呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力する音声処理部と、
   前記呼処理部により送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理部により実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理部により実行された音声自動応答のシナリオに応じて前記電話端末から受信した音声を認識した結果の履歴情報とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む制御部と、
   他のメディアサーバの故障を検出する監視部と、
   前記監視部により現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理部とを備え、
   前記音声自動応答処理部は、前記復旧処理部が読み出した前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報と前記履歴情報とを取得し、取得した前記情報と前記履歴情報とにより特定される実行位置から前記音声自動応答のシナリオを実行し、
   前記音声処理部は、前記復旧処理部が読み出した前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理部から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力し、
   前記呼処理部は、前記復旧処理部が読み出した前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう、
   ことを特徴とするメディアサーバ。
2. 呼の復旧に用いられる情報は、送受信した前記呼制御信号から取得した発側電話番号、着側電話番号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含むことを特徴とする請求項１に記載のメディアサーバ。
3. 呼の復旧に用いられる情報は、前記電話端末から受信した呼制御信号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含み、
   前記復旧処理部は、前記外部記憶装置から読み出した前記呼処理復旧情報に設定されている前記呼制御信号を前記呼処理部に送信し、
   前記呼処理部は、前記復旧処理部から送信された前記呼制御信号に基づいて前記電話端末との間の呼のセッションを確立する、
   ことを特徴とする請求項１に記載のメディアサーバ。
4. メディアセッションの復旧に用いられる前記情報は、発信側及び着信側のメディアセッション用のアドレスと、メディアセッションに特有の値が設定された情報と、音声パケットの送信に伴い値が更新される情報のメディアセッション確立時の値と、前記メディアセッションの開始時刻とを含み、
   前記音声処理部は、前記復旧処理部により読み出された前記音声処理復旧情報から前記開始時刻と、音声パケットの送信に伴い更新される前記情報のメディアセッション確立時の値とを取得し、前記開始時刻からの経過時間に基づいて更新される前記情報の現在の値を算出し、前記音声処理復旧情報から読み出した、発信側及び着信側のメディアセッション用の前記アドレスと、メディアセッションに特有の値が設定された前記情報と、算出した前記値を設定した、音声パケットの送信に伴い更新される前記情報とを用いて前記呼のメディアセッションを復旧する、
   ことを特徴とする請求項１から請求項３のいずれかの項に記載のメディアサーバ。
5. 前記制御部は、解放された呼の呼特定情報を含む前記呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から削除する、
   ことを特徴とする請求項１から請求項４のいずれかの項に記載のメディアサーバ。
6. ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバに用いられるセッション復旧方法であって、
   呼処理部が、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、
   音声自動応答処理部が、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、
   音声処理部が、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部へ出力する音声処理ステップと、
   制御部が、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオに応じて前記電話端末から受信した音声を認識した結果の履歴情報とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、
   監視部が、他のメディアサーバの故障を検出する監視ステップと、
   復旧処理部が、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、
   前記音声自動応答処理部が、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報と前記履歴情報とを取得し、取得した前記情報と前記履歴情報とにより特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、
   前記音声処理復旧が、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、
   前記呼処理部が、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、
   を有することを特徴とするセッション復旧方法。
7. ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバとして用いられるコンピュータに、
   ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、
   音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、
   呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から音声パケットを受信する音声処理ステップと、
   前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオに応じて前記電話端末から受信した音声を認識した結果の履歴情報とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、
   他のメディアサーバの故障を検出する監視ステップと、
   前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、
   前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報と前記履歴情報とを取得し、取得した前記情報と前記履歴情報とにより特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、
   前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、
   前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、
   を実行させることを特徴とするコンピュータプログラム。

Images