メディアサーバ、セッション復旧方法及びコンピュータプログラム
【課題】IVRシナリオの実行中に故障が発生した場合であってもSIP及びRTPセッションを回復し、故障発生が発生した時点から迅速にIVRシナリオを再開する。
【解決手段】現用系のメディアサーバ4aは、電話端末1とのSIPセッションを確立すると外部記憶装置6に呼処理復旧情報を書き込むとともに、IVRの処理を起動して電話端末1との間でRTPセッションを確立し、外部記憶装置6に音声処理復旧情報を書込み、IVR処理の実行に伴いIVR処理情報を書き込む。現用系が故障した場合、待機系のメディアサーバ4bはこれを検知し、外部記憶装置6からIVR処理情報、音声処理復旧情報を読み出し、IVRシナリオの途中からIVR処理を再開するとともに、音声処理復旧情報によりRTPセッションを復旧する。SIPパケットを受信した場合、外部記憶装置6内の呼処理復旧情報を参照してセッション確立済みのパケットか確認する。
【解決手段】現用系のメディアサーバ4aは、電話端末1とのSIPセッションを確立すると外部記憶装置6に呼処理復旧情報を書き込むとともに、IVRの処理を起動して電話端末1との間でRTPセッションを確立し、外部記憶装置6に音声処理復旧情報を書込み、IVR処理の実行に伴いIVR処理情報を書き込む。現用系が故障した場合、待機系のメディアサーバ4bはこれを検知し、外部記憶装置6からIVR処理情報、音声処理復旧情報を読み出し、IVRシナリオの途中からIVR処理を再開するとともに、音声処理復旧情報によりRTPセッションを復旧する。SIPパケットを受信した場合、外部記憶装置6内の呼処理復旧情報を参照してセッション確立済みのパケットか確認する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、音声自動応答中に故障が発生した際のセッションフェールオーバを行なうメディアサーバ、セッション復旧方法及びコンピュータプログラムに関する。
【背景技術】
【0002】
固定電話では、エンドユーザの電話料金は距離により変わる。そこで、音声による自動応答を行なうIVR(Interactive Voice Response)機能を全国規模で提供する場合、エンドユーザの電話料金を低く抑えるために、通信距離が短くなるようメディアサーバを全国各地に配置することが多い。しかし、全国各地にメディアサーバを配置すると、設備や保守などにかかるコストが高くなってしまうという問題が生じる。
【0003】
一方、ここ10年の間にインターネットやIP(Internet Protocol)電話の普及がすすみ、また、VoIP(Voice over IP)やインスタントメッセージ等のリアルタイムサービスに用いられるプロトコルであるSIP(Session Initiation Protocol)の標準化が行なわれ、通信キャリアによるIP電話サービス(VoIPサービス)も広く提供されてきている。
【0004】
VoIPでは通信費が距離に依存して変化しないため、VoIPを用いれば、各地に点在していたメディアサーバを1箇所に集約することができる。近年は、IP電話サービスの品質が安定し、信頼性も高くなってきたことから、今後、コスト削減のためVoIPを用いたメディアサーバの集約が進むと考えられる。しかし、メディアサーバを集約すると、故障時には影響が全国に及んでしまうため、メディアサーバにはこれまで以上の高い信頼性が要求されるようになる。
【0005】
このように、今後はメディアサーバには高い信頼性が要求されると予想されるが、一方低価格化の圧力も大きい。そのため、例えば、ハードウェア面では、高価だが高品質・高信頼性のメインフレームから安価だが故障率の高いIAサーバを用いたSI(システムインテグレーション)に移行する事例も増えてきた。また、ソフトウェア面では、安価なオープンソースソフトウェアを用いた開発も増えてきた。オープンソースソフトウェアはコストを抑えられるものの、ベンダー製品よりも品質が劣る場合もあり、アプリケーション側でエラーが生じる確率が高くなる場合も考えられる。
【0006】
システムの信頼性については、ハードウェアの故障の問題はFT(フォルトトレラント)サーバを用いることにより解決できる。FTサーバではCPU(central processing unit)やメモリなどのハードウェアコンポーネントが全て2重化されており、ハードウェアコンポーネントの一方が故障してもシステムを全く止めることなく、瞬断もせずに動作を継続することができる。FTサーバを導入すれば、ハードウェア故障の心配はなくなるが、非常に高価なことが導入のネックとなっている。また、FTサーバはハードウェアの故障には対応できるが、アプリケーションが何らかのエラーにより落ちた場合にはサービスがストップしてしまうという問題がある。
【0007】
そこで、ミッションクリティカルでないシステムでは、システムの信頼性を高めるために、システムを冗長化して障害によるシステム停止を最小限にするHA(高可用性:High Availability)構成を採用することが多い。HA構成(クラスタ構成ともいう)では、現用系サーバに故障が発生した場合、クラスタ監視アプリケーションが待機系サーバの業務アプリケーションを自動で起動させる。HA構成には、データを共有ディスク上に置き、この共有ディスクを複数のサーバで利用する共有ディスクタイプと、各サーバのディスクをサーバ間でミラーするデータミラータイプがある。HA構成ならば、サービスの瞬断が発生するが、ソフトウェア/ハードウェアのいずれが故障した場合でも、現用系サーバから待機系サーバへの切り替えを行って動作を継続することができる。HA構成は世界で広く用いられている信頼性確保の方式であり、HTTP(Hypertext Transfer Protocol)やDB(データベース)といった非リアルタイムのプロコトルにおいての使用実績は多い。しかし、現用系から待機系に切り替えるために10秒程度かかることもあり、VoIPのようなリアルタイムサービスにおいて用いるには適さないのが現状である。
【0008】
また、IVRサービスは、エンドユーザ側のIP電話端末とSIPパケットを中継する中継機とIVR機能を有するメディアサーバにより構成されることが多い。中継機はキャリアが管理するサーバであり、着信先の相手を検索して通話を確立させる役割を持つ。中継機が故障すると、IP電話を使用する全てのユーザが通話不能となる。
特許文献1及び特許文献2には、現用系中継機であるSIPサーバがセッションを確立する度に外部記憶装置にセッション情報を書き込んでおき、現用系中継機の故障時には待機系中継機がその故障を察知し、現用系として起動することが記載されている。特許文献1では、待機系中継機は起動時に外部記憶装置から情報を読み込んで全てのセッションを復旧させており、特許文献2では、現用系とし起動した待機系中継機が、SIPパケットを受信したときに外部記憶装置から情報を取得し、受信したセッションの情報だけを復旧している。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2007−81933号公報
【特許文献2】特開2008−103952号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
一般に電話系のサービスは、固定電話をはじめ極めて品質の高いサービスが多く、エンドユーザもその品質が当たり前と考えていることが多い。そのため、故障時に通話が切断されることは大きな問題となる。
一方メディアサーバをVoIPにより構築しようとする企業では、これまでは、コストを優先し、FTサーバではない安価なハードウェア、オープンソースソフトウェアなどの安価なソフトウェアによりIVRシステムを構築することが多く、アプリケーションの故障率が高くなり信頼性が低くなる可能性が想定された。
【0011】
しかし、今後は、大規模かつ高信頼性を求められるIVRシステムがVoIP上で構築される可能性が高いため、音声通話のセッションフェールオーバ機能が必要になると予想される。すなわち、アプリケーション/ハードウェアのいずれの故障時であっても通話が切断されずに現用系から待機系に処理が引継がれる、拠点集約にも耐えうる高信頼な電話システムの構成が切望されている。
【0012】
中継機は、故障するとIP電話を使用する全てのユーザが通話不能となるため、基本的に二重化されている。上述した特許文献1や特許文献2の技術は、中継機におけるSIPセッションを復旧させる技術である。特許文献1や特許文献2の技術をメディアサーバで実現しようとした場合、メディアサーバに必要なRTP(Real-Time Transport Protocol)セッションやIVR処理を復旧させることはできないという問題があった。
【0013】
また、特許文献1や特許文献2の技術をメディアサーバで実現しようとした場合、外部装置の負荷が高くなりすぎるという問題もある。特許文献1及び特許文献2では、中継機の二重化をHA構成により実現している。中継機のように、リアルタイムで動作する必要のないサーバであれば、サーバが保持する情報に更新があった場合、その都度、更新内容を共有ディスクに反映させることにより、現用系の故障時には待機系サーバにおいてその共有ディスクの内容を参照して動作を継続することができる。しかし、メディアサーバはリアルタイムで動作するため、単純なHA構成では二重化することはできない。
【0014】
すなわち、中継機では3分ほどの通話でも5〜6パケットしか受信せず、例えば、100人のエンドユーザが通話している状態を仮定しても、3分で500〜600のSIPパケットを受信する程度であり、共有ディスクに変更した情報を記憶するための負荷は3.3アクセス/秒程度と想定される。また、SIPの仕様上、パケット受信後直ちに応答する必要もなく、30秒ほどの余裕がある。
【0015】
ところが、メディアサーバはリアルタイムで動作するためデータの更新が頻繁に生じる。メディアサーバでは、1つの通話で50パケット/秒という多数の音声パケットを受信するため、例えば、100人のエンドユーザが通話している状態を考えると、共有ディスクに対して5000アクセス/秒程度の負荷があると予想される。これでは、共有ディスクへの書込みが間に合わなくなり、単純なHA構成では対応できない可能性が高い。また、音声パケットの場合、送信に10ミリ秒以上の遅延が生じると、音声が途切れる等の影響が発生するが、これほどの負荷をかけながら10ミリ秒以内の遅延で音声パケットの送受信することは非常に困難である。
【0016】
さらには、特許文献1では、全てのSIPパケットを外部記憶装置に記憶しており、書込み及び読み出しの負荷が高い。
加えて、特許文献1及び特許文献2では、復旧に必要な情報を次々に追記し、削除しておらず、ディスクの利用効率や外部記憶装置の応答性能に影響を与える可能性がある。
【0017】
このような特許文献1及び2の問題点に加え、先に述べたような拠点集約に耐えうる高い信頼性を実現すること、低価格の圧力でFTサーバによるハードウェア故障の回避を採用できない場合にも信頼性を確保すること、低価格の圧力からベンダー製品よりも品質が低い場合もあるオープンソースソフトウェアの使用率が向上しているためアプリケーションエラーが生じやすい可能性があること、電話系のサービスは他のサービスと比較して高品質を求められやすいことなどを勘案して、メディアサーバのセッションフェールオーバを実現する必要がある。
【0018】
本発明は、上記の事情に鑑みてなされたものであり、その目的は、IVR機能によりIPネットワークを介して音声データを提供している際にメディアサーバに故障が発生した場合であっても、SIP及びRTPセッションを回復し、故障発生が発生した時点から迅速にIVRシナリオを再開することができるメディアサーバ、セッション復旧方法及びコンピュータプログラムを提供することにある。
【課題を解決するための手段】
【0019】
上記課題を解決するため、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバであって、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理部と、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理部と、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力する音声処理部と、前記呼処理部により送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理部により実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理部が前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む制御部と、他のメディアサーバの故障を検出する監視部と、前記監視部により現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理部とを備え、前記音声自動応答処理部は、前記復旧処理部が読み出した前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行し、前記音声処理部は、前記復旧処理部が読み出した前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理部から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力し、前記呼処理部は、前記復旧処理部が読み出した前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう、ことを特徴とするメディアサーバである。
【0020】
また、本発明は、上述したメディアサーバであって、呼の復旧に用いられる情報は、送受信した前記呼制御信号から取得した発側電話番号、着側電話番号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含むことを特徴とする。
【0021】
また、本発明は、上述したメディアサーバであって、呼の復旧に用いられる情報は、前記電話端末から受信した呼制御信号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含み、前記復旧処理部は、前記外部記憶装置から読み出した前記呼処理復旧情報に設定されている前記呼制御信号を前記呼処理部に送信し、前記呼処理部は、前記復旧処理部から送信された前記呼制御信号に基づいて前記電話端末との間の呼のセッションを確立する、ことを特徴とする。
【0022】
また、本発明は、上述したメディアサーバであって、メディアセッションの復旧に用いられる前記情報は、発信側及び着信側のメディアセッション用のアドレスと、メディアセッションに特有の値が設定された情報と、音声パケットの送信に伴い値が更新される情報のメディアセッション確立時の値と、前記メディアセッションの開始時刻とを含み、前記音声処理部は、前記復旧処理部により読み出された前記音声処理復旧情報から前記開始時刻と、音声パケットの送信に伴い更新される前記情報のメディアセッション確立時の値とを取得し、前記開始時刻からの経過時間に基づいて更新される前記情報の現在の値を算出し、前記音声処理復旧情報から読み出した、発信側及び着信側のメディアセッション用の前記アドレスと、メディアセッションに特有の値が設定された前記情報と、算出した前記値を設定した、音声パケットの送信に伴い更新される前記情報とを用いて前記呼のメディアセッションを復旧する、ことを特徴とする。
【0023】
また、本発明は、上述したメディアサーバであって、前記制御部は、解放された呼の呼特定情報を含む前記呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から削除する、ことを特徴とする。
【0024】
また、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバに用いられるセッション復旧方法であって、呼処理部が、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、音声自動応答処理部が、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、音声処理部が、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部へ出力する音声処理ステップと、制御部が、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、監視部が、他のメディアサーバの故障を検出する監視ステップと、復旧処理部が、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、前記音声自動応答処理部が、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、前記音声処理復旧が、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、前記呼処理部が、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、を有することを特徴とするセッション復旧方法である。
【0025】
また、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバとして用いられるコンピュータに、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から音声パケットを受信する音声処理ステップと、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、他のメディアサーバの故障を検出する監視ステップと、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、を実行させることを特徴とするコンピュータプログラムである。
【発明の効果】
【0026】
本発明によれば、音声送出中に現用系のメディアサーバが故障した場合であっても、通話がとぎれることなく、待機系のメディアサーバによって、故障が発生した時点から引き続きIVRシナリオを提供することができる。このように、メディアサーバのセッションフェールオーバを実現することができるため、FTサーバと比較して故障率の高いハードウェアを使用した場合や、オープンソースソフトウェアのようにベンダー製品と比較して品質の劣る可能性のあるソフトウェアを使用した場合でも、信頼性の高いシステムを実現することが可能となる。従って、安価なハードウェア、ソフトウェアを使用し、メディアサーバの集約を実現することができるため、導入、運用、保守のコストを軽減することが可能となる。
【図面の簡単な説明】
【0027】
【図1】本発明の第1の実施形態によるIVRシステムの機能ブロック図である。
【図2】同実施形態による電話番号設定情報のデータ構成例を示す図である。
【図3】同実施形態によるIVRフローデータのデータ構成例を示す図である。
【図4】同実施形態による呼処理復旧情報のデータ構成例を示す図である。
【図5】同実施形態による音声処理復旧情報のデータ構成例を示す図である。
【図6】同実施形態によるIVR処理情報のデータ構成例を示す図である。
【図7】同実施形態による着信時のシーケンスを示す図である。
【図8】同実施形態による故障発生時のシーケンスを示す図である。
【図9】同実施形態による監視フローを示す図である。
【図10】同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。
【図11】同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。
【図12】同実施形態による現用系メディアサーバの発信時の処理フローを示す図である。
【図13】同実施形態による待機系メディアサーバの復旧処理フローを示す図である。
【図14】第2の実施形態による呼処理復旧情報のデータ構成例を示す図である。
【図15】同実施の形態による音声処理復旧情報のデータ構成例を示す図である。
【図16】同実施形態による故障発生時のシーケンスを示す図である。
【図17】同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。
【図18】同実施形態による現用系メディアサーバの発信時の処理フローを示す図である。
【図19】同実施形態による待機系メディアサーバの復旧処理フローを示す図である。
【発明を実施するための形態】
【0028】
以下、図面を参照して本発明の実施形態の例について説明する。
【0029】
[第1の実施形態:メモリ情報共有方式]
本実施形態では、メモリ情報共有方式による音声通話のセッションフェールオーバを実現する。メモリ情報共有方式では、IVR(Interactive Voice Response:音声自動応答)システムにおける現用系のメディアサーバはSIP(Session Initiation Protocol)関連の情報全てを外部記憶装置に保存しておき、この現用系のメディアサーバに故障が発生した場合、待機系のメディアサーバが外部記憶装置に保存しているSIP関連の情報を用いて呼処理を継続するものである。
【0030】
図1は、本発明の一実施形態によるIVRシステムの機能ブロック図である。IVRとは、エンドユーザからの電話に自動で応答し、「○○の方は1番を押してください」のような音声を再生することにより、ユーザを誘導してオペレータに転送したり、エンドユーザに情報提供を提供したりする音声自動応答機能を有する音声自動応答システムをいう。
【0031】
同図に示すように、IVRシステムは、電話端末1、中継サーバ2、メディアサーバ4、外部記憶装置6、発信制御装置7を備える。電話端末1及び中継サーバ2は、IP(Internet Protocol)網であるネットワークNに接続される。同図において電話端末1は、1台のみが記載されているが、複数台がネットワークNに接続される。2台のメディアサーバ4は、ルータ3を介してネットワークNと接続され、メディアサーバ4、外部記憶装置6、及び、発信制御装置7は、LAN(Local Area Network)などの私設網を介して接続される。
【0032】
同図においては、メディアサーバ4として2台のメディアサーバ4a、4bが記載されているが、3台以上が備えられてもよい。ここでは、メディアサーバ4aが現在動作している現用系、メディアサーバ4bが現用系の故障時に処理を引継ぐ待機系であるとする。なお、メディアサーバ4が3台以上ある場合の現用系と待機系のサーバ台数比はN対M(N、Mは1以上)である。
【0033】
音声通話のセッションフェールオーバでは、現用系のメディアサーバ4が故障した場合、待機系のメディアサーバ4に動作が引継がれて通話が継続される。例えば、現用系のメディアサーバ4aから「○○の方は1番を押してください」とのアナウンスが流れ、エンドユーザが電話端末1に「1」を入力したのち、再びメディアサーバ4aから「△△の方は…」のようなアナウンスが流れている途中でメディアサーバ4aの故障が発生したとする。この場合、待機系のメディアサーバ4bが起動して、故障が発生した途中のアナウンスから再開し、「△△の方は、2番を押してください。」とのアナウンスを流して引き続きIVR処理を行なう。現用系から待機系への切り替え時には数秒間の無音が発生してもよい。
【0034】
待機系に切り替わる時に必要な情報は、SIP関連の情報、RTP(Real-Time Transport Protocol)関連の情報、IVR関連の情報である。SIPとは、IP電話により電話をかける相手を探しだすために使用されることが多い呼制御用のプロコトルであり、RFC(Request for Comments)3261に詳しい仕様が記載されている。RTPとは、音声データなどをリアルタイムに伝送するために用いられるプロトコルであり、RTPパケットには、アナログの音声を符号化した音声データが設定される。
【0035】
本実施形態によるIVRシステムに適用されるメモリ情報共有方式では、現用系のメディアサーバ4は、SIP関連の情報全てを外部記憶装置6に保存し、基本的に現用系のメディアサーバは、自身のメモリ上に待機系のメディアサーバに引継ぐSIP関連の情報を記憶しない。よって、現用系のメディアサーバ4が故障した場合でも、待機系のメディアサーバ4は、メモリ上にSIP関連の情報を復旧させる必要はない。
【0036】
また、復旧のためのRTPの情報は、RTPセッションの開始時に外部記憶装置6に記憶する。そのため、現用系のメディアサーバ4が故障した場合、待機系のメディアサーバ4は外部記憶装置6に記憶されている情報を参照してRTPポートオープン等の状態復帰処理を行ってセッションを引継ぐが、一部の情報については保存時の値から現在の値を推定してRTPパケット送信を再度起動させる必要がある。
【0037】
IVR関連の情報は、更新があり次第、その内容を外部記憶装置6に保存していく。そのため、現用系のメディアサーバ4が故障した場合、待機系のメディアサーバ4は外部記憶装置6に記憶されている情報に基づいてIVRを再度起動する。よって、故障が発生した時点からIVR処理を再開することができる。
【0038】
このように、メモリ情報共有方式は、現用系のメディアサーバ4が持つメモリ情報を全て外部記憶装置6に保存しておき、故障時は待機系のメディアサーバ4が外部記憶装置6から情報を取得してメモリ情報を復旧させる方式である。本方式の場合、ブリッジ方式の転送実施時に故障が発生した場合でもセッションフェールオーバが可能となる。また、待機系に切り替わる時、メモリ上にSIP関連の情報を復旧させる必要がないため、短い停止時間で現用系から待機系に切り替わることができる。
【0039】
次に、各装置の構成について説明する。
エンドユーザが保有する電話端末1は、IP電話端末であり、メディアサーバ4との間でSIPにより呼を確立するとともに、RTPを用いてメディアセッションを確立して音声パケットを送受信する。
中継サーバ2は、アドレス解決などを行なって、SIP信号の中継を行なう。
【0040】
メディアサーバ4は、通信部40、監視部41及びメディア処理プログラム実行部42を備える。通信部40は、IPにより他の装置との間でパケット(データ)を送受信する。通信部40は、現用系から処理を引継ぐ場合、現用系のメディアサーバ4が使用していたIPアドレスを引継いで使用する。監視部41は、他のメディアサーバ4の故障を検出する。
【0041】
メディア処理プログラム実行部42は、呼処理部43、制御部44、主記憶部45、IVR処理部46、音声処理部47及び復旧処理部48を備える。主記憶部45は、メディア処理プログラム実行部42内の各部からアクセス可能であり、呼処理、音声処理、IVR処理に用いられる各種データを記憶する。制御部44は、外部記憶装置6に対して呼処理復旧情報、音声処理復旧情報、IVR処理情報の書込みや読み出しを行なう。呼処理部43は、SIP信号に基づく既存と同様の呼処理を行なうが、呼処理において用いられる各種情報のうち故障時の引継が必要な情報については制御部44を介して外部記憶装置6に書込みを行ない、適宜この外部記憶装置6内の情報を参照して呼処理を行なう。IVR処理部46は、IVRフローに従った音声データの出力を音声処理部47へ指示する。音声処理部47は、RTPによる音声データの送受信処理を行なう。
【0042】
以下、メディアサーバ4aが備えるメディアサーバ4の各部には符号にaを付加して記載し、メディアサーバ4bが備えるメディアサーバ4の各部には符号にbを付加して記載する。例えば、メディアサーバ4aの備える監視部41は監視部41a、メディアサーバ4bの備える監視部41は監視部41bと記載する。
【0043】
外部記憶装置6は記憶部60を備え、記憶部60内の電話番号設定記憶部61、IVRフロー記憶部62、呼処理復旧情報記憶部63、音声処理復旧情報記憶部64、IVR処理情報記憶部65に記憶されているデータの読書きを行なう。
発信制御装置7は、メディアサーバ4に対して呼の発信を指示する。
【0044】
次に、本実施形態による外部記憶装置6に記憶される各データについて説明する。
図2は、本実施形態による電話番号設定記憶部61に記憶される電話番号設定情報のデータ構成例を示す図である。電話番号設定情報は、電話番号、実行すべきIVRシナリオを特定するIVR ID、同時に接続可能な呼数を示す最大チャネル数、及び、現在接続されている呼数を示すアクティブチャネル数を対応づけたレコードからなる。電話番号は、電話端末1から発信し、メディアサーバ4へ着信したときの着信先電話番号、あるいは、発信制御装置7の指示を受けメディアサーバ4が発信し、電話端末1へ着信したときの発信元電話番号である。
【0045】
図3は、本実施形態によるIVRフロー記憶部62に記憶されるIVRフローデータのデータ構成例を示す図である。同図において、IVRフローデータは、IVR IDと、IVRフローシナリオの対応付を示す。IVRフローシナリオは、エンドユーザに対して実行するIVR処理の順番を記述したデータであり、メディアサーバ4のIVR処理部46は、このIVRフローシナリオに従って、送出する音声の再生や、受信した音声の認識等の処理を順番に実行する。受信する音声は、例えば、DTMF(Dual Tone Multi Frequency)やエンドユーザの発話などである。なお、DTMFとは、1〜9までの数字と*、#、A、B、C、Dの記号の16種類の符号を低群・高群の2つの音声周波数帯域の信号音で送信する方法であり、電話端末1にプッシュした番号をメディアサーバ4に伝えることができる。
【0046】
図4は、本実施形態による呼処理復旧情報記憶部63に記憶される呼処理復旧情報のデータ構成例を示す図である。呼処理復旧情報は、電話端末1及びメディアサーバ4の間でSIPのセッションを再確立するために必要な情報を保持し、toタグ、fromタグ、callid、メディアサーバのCSeq、電話端末のCSeq、発着信フラグ、サーバ側電話番号、端末側電話番号、各種ヘッダフィールドを対応付けたレコードからなる。各レコードは、通話単位、つまり、ダイアログ単位で生成される。SIPにおいて、ダイアログとは、電話をかけて通話が確立してから通話が終了するまでの間のことである。呼は、toタグ、fromタグ及びcallidの組み合わせによって示される呼特定情報により一意に特定することができる。
【0047】
toタグは、論理的なリクエストの送信先(IPアドレスとは異なる)が記載されているSIPのタグである。fromタグは、論理的な(IPアドレスとは異なる)リクエストの送信元が記載されているSIPのタグである。callidは、グローバルでユニークなランダムID(識別子)であり、RFC1750の方式で生成することが推奨されている。CSeqは、新規リクエスト毎にインクリメントされる番号である。発着信フラグは呼がメディアサーバ4からの発信か、電話端末1からの着信かを判別するためのフラグである。各種ヘッダフィールドは、送受信した各SIPメッセージのヘッダの情報の全部または一部の情報である。なお、toタグ、fromタグ、callid、CSeq、SIPメッセージのヘッダの詳細は、RFC3261に記述されている。サーバ側電話番号、端末側電話番号に代えて、メディアサーバ4のSIP URI(Universal Resource Identifier)、電話端末1のSIP URIを用いるようにしてもよい。
【0048】
図5は、本実施形態による音声処理復旧情報記憶部64に記憶される音声処理復旧情報のデータ構成例を示す図である。音声処理復旧情報は、電話端末1とメディアサーバ4の間のRTPによる音声通信の再確立に必要な情報を保持し、toタグ、fromタグ、callid、発着信開始時間、メディアサーバのRTPシーケンスナンバ、SSRC、RTPポート番号及びIPアドレス、電話端末のRTPポート番号及びIPアドレスを対応付けたレコードからなる。各レコードは、ダイアログ(通話)単位で生成される。
【0049】
SSRCは、RTPパケットに含まれるメディアストリームのソースIDであり、他のRTPと識別するために使用される。RTPシーケンスナンバは、RTPパケットの順序性を保障するための番号であり、RTPパケットを送信する度に1ずつ増やしていくが、ここでは、確立したRTPセッションにおいて、最初に送信したRTPパケットに使用したRTPシーケンスナンバを示す。
なお、SSRC、RTPシーケンスナンバの詳細は、RFC3350に記述されている。
【0050】
図6は、本実施形態によるIVR処理情報記憶部65に記憶されるIVR処理情報のデータ構成例を示す図である。IVR処理情報は、メディアサーバ4がエンドユーザに対して実行したコマンドの履歴ログを示し、toタグ、fromタグ、callid、コマンド実行履歴、エンドユーザ入力履歴1〜nを対応付けたレコードからなり、ダイアログ(通話)単位で生成される。
【0051】
コマンド実行履歴は、IVRフローシナリオにより規定される一連のIVR処理において、最後に指示したガイダンス送出や音声認識などのIVR処理を特定する。エンドユーザ入力履歴1〜nは、IVR処理において電話端末1から受信したエンドユーザによる入力内容を順に記述したデータであり、入力されたDTMFや、音声やDTMFにより特定される選択内容などを示す。
【0052】
次に、本実施形態によるIVRシステムの動作について説明する。
IVRシステムの稼動前に、電話番号設定情報が電話番号設定記憶部61に、IVRフローデータがIVRフロー記憶部62に記憶されているものとする。ただし、電話番号設定情報のアクティブチャネル数の初期値は「0」とする。
【0053】
図7は、本実施形態による電話端末1から現用系のメディアサーバ4への着信時のシーケンス例を示す図である。なお、以下、SIPのX信号が設定されたIPパケットをXパケットと記載する。例えば、INVITE信号が設定されたIPパケットをINVITEパケットとする。
【0054】
まず、電話端末1は、中継サーバ2に対してINVITEパケットを送信する(ステップS105)。INVITEパケットには、電話端末1が使用するRTPポート番号及びIPアドレスが設定されている。中継サーバ2は、INVITEパケットのToフィールドに設定されている電話番号を着信先のIPアドレスに変換し、メディアサーバ4aへ送信する(ステップS110)。メディアサーバ4aは、着信を許可すると判断した場合、100Tringメッセージを中継サーバ2に返送し(ステップS115)、続いて、180Ringingを中継サーバ2に送信する(ステップS120)。中継サーバ2は、180Ringingを電話端末1に中継し(ステップS125)、電話端末1は、リングバックトーンをエンドユーザに聞かせる。
【0055】
続いて、メディアサーバ4aの呼処理部43aは、200OKを中継サーバ2に送信する(ステップS130)。200OKには、メディアサーバ4aが使用するRTPポート番号及びIPアドレスが設定されている。中継サーバ2は、200OKを電話端末1に中継する(ステップS135)。電話端末1は、メディアサーバ4aに対してACKを送信する(ステップS140)。ACKの送信に伴い、電話端末1とメディアサーバ4aの音声処理部47a間でRTPのセッションが確立され、通話中状態に遷移すると、メディアサーバ4aの音声処理部47aは、IVRの音声をRTPパケットにより電話端末1へ送信し、電話端末1はエンドユーザの発話やDTMFをRTPパケットによりメディアサーバ4aへ送信する(ステップS145)。
【0056】
通話中状態が長く継続する場合、定期的にメディアサーバ4aの呼処理部43aまたは電話端末1からre−INVITEパケットまたはUPDATEパケットが送信され(ステップS150)、この受信した電話端末1またはメディアサーバ4aの呼処理部43aは、応答を返送し、セッションの継続を確認する。
【0057】
エンドユーザが呼の切断操作を行なった場合、電話端末1はメディアサーバ4aへBYEパケットを送信し(ステップS155)、メディアサーバ4aの呼処理部43aは、200OKを返送する(ステップS160)。なお、メディアサーバ4aが呼の切断を行なう場合、メディアサーバ4aの呼処理部43aは、電話端末1へBYEパケットを送信し、電話端末1は、200OKを返送する。
【0058】
メディアサーバ4からの発信の場合、メディアサーバ4が図7に示すシーケンス中の電話端末1と同様の動作を行い、電話端末1が図7に示すメディアサーバ4と同様の動作を行なう。
【0059】
図8は、本実施形態によるIVRシステムにおける故障発生時のシーケンスを示す図である。
例えば、図7のステップS105〜S140に示す電話端末1からの発信の手順や、メディアサーバ4からの発信の手順により、電話端末1とメディアサーバ4aの間でSIPセッションが確立されると(ステップS205)、メディアサーバ4aは外部記憶装置6の呼処理復旧情報記憶部63に呼処理復旧情報を書き込む(ステップS210)。メディアサーバ4aは、IVRの処理を起動し(ステップS215)、電話端末1との間でRTPセッションを確立すると(ステップS220)、外部記憶装置6の音声処理復旧情報記憶部64に音声処理復旧情報を書き込む(ステップS225)。
【0060】
メディアサーバ4aは、音声再生などのIVR処理を実行し(ステップS230)、外部記憶装置6のIVR処理情報記憶部65にIVR処理情報を書き込む。また、IVR処理中に呼の継続確認のためのSIPパケットの送受信があった場合、メディアサーバ4aは、外部記憶装置6の呼処理復旧情報記憶部63に記憶されている呼処理復旧情報の読み込みや更新を行なう(ステップS235)。つまり、メディアサーバ4aは、IVR処理が進むたびにIVR処理情報を更新し、電話端末1からSIPパケットを受信する度に呼処理復旧情報を読込んで新規SIPパケットかを確認し、既存の呼の場合には呼処理復旧情報を更新する。
【0061】
IVR処理実行中にメディアサーバ4aが故障した場合、メディアサーバ4bはこれを検知し(ステップS240)、外部記憶装置6のIVR処理情報記憶部65からIVR処理情報を読み出すと(ステップS245)、IVRシナリオの途中からIVR処理を起動する(ステップS250)。さらに、メディアサーバ4bは、外部記憶装置6の音声処理復旧情報記憶部64から音声処理復旧情報を読み出し(ステップS255)、音声処理復旧情報により示されるRTPポートを開き受信状態にすると同時に電話端末1に対してRTPパケットの送信を再開してRTPセッションを復旧し(ステップS260)、電話端末1とのRTPセッションを再確立する(ステップS265)。メディアサーバ4bは、電話端末1からSIPパケットを受信した場合(ステップS270)、外部記憶装置6の呼処理復旧情報記憶部63から呼処理復旧情報を読み出し、受信したSIPパケットがセッション確立済みのパケットかを確認する(ステップS275)。
【0062】
次に、メディアサーバ4における処理フローについて説明する。
図9は、本実施形態による監視フローを示す図である。
同図において、メディアサーバ4の監視部41は、所定の時間間隔により、他のメディアサーバ4の生死の監視を起動する(ステップS305)。つまり、メディアサーバ4aの監視部41aは、メディアサーバ4bの生死の監視処理を起動し、メディアサーバ4bの監視部41bは、メディアサーバ4aの生死の監視処理を起動する。
【0063】
監視が起動されると、メディアサーバ4の監視部41は、他のメディアサーバ4の監視部41との間で生死の監視のための情報を交換する(ステップS310)。メディアサーバ4aの監視部41aは、メディアサーバ4bの監視部41bに対して監視メッセージを送信し、監視メッセージを受信したメディアサーバ4bの監視部41bは、メディアサーバ4bのハードウェアの動作やメディア処理プログラム実行部42bの処理が正常である場合、正常を通知する監視応答メッセージを返送する。同様に、メディアサーバ4bの監視部41bは、メディアサーバ4aの監視部41aに対して監視メッセージを送信し、監視メッセージを受信したメディアサーバ4aの監視部41aは、メディアサーバ4aのハードウェアの動作やメディア処理プログラム実行部42aの処理が正常である場合、正常を通知する監視応答メッセージを返送する。
【0064】
現用系、待機系のメディアサーバ4とも正常である場合、つまり、メディアサーバ4a、4bが、ステップS310において自身が送信した監視メッセージに対応して正常を通知する監視応答メッセージを受信した場合(ステップS315:故障検知なし)、現用系、待機系のメディアサーバ4a、4bともそのまま処理を継続する(ステップS320)。
【0065】
待機系のメディアサーバ4bの故障発生が検出された場合、例えば、メディアサーバ4aの監視部41aが、メディアサーバ4bへ監視メッセージを送信してから所定時間以内に監視応答メッセージを受信しなかった、あるいは、メディアサーバ4bから故障を示す監視応答メッセージを受信した場合(ステップS315:待機系の故障検知)、現用系のメディアサーバ4aは、そのまま処理を継続する(ステップS325)。LANによりメディアサーバ4と接続され、IVRシステム全体の動作を管理する運用サーバ(図示せず)は、管理者宛のメール等を送信し、故障を通知する。
【0066】
現用系のメディアサーバ4aの故障発生が検出された場合、例えば、メディアサーバ4bの監視部41bが、メディアサーバ4aへ監視メッセージを送信してから所定時間以内に監視応答メッセージを受信しなかった、あるいは、メディアサーバ4aから故障を示す監視応答メッセージを受信したりした場合(ステップS315:現用系の故障検知)、待機系のメディアサーバ4bの監視部41bは、通信部40bに現用系のメディアサーバ4aのIPアドレスを引継ぐよう指示するとともに、メディア処理プログラム実行部42bに後述する故障時フローの実行を指示する(ステップS330)。
【0067】
図10及び図11は、本実施形態による現用系のメディアサーバ4における着信時の処理フローを示す図である。
図10において、メディアサーバ4aの呼処理部43aは、図7のステップS105〜S110に示すように、電話端末1から送信され、中継サーバ2により中継されたINVITEパケットを受信する(ステップS405)。
【0068】
メディアサーバ4aの呼処理部43aは、INVITEパケットのToフィールドから着信先の電話番号を取得して主記憶部45aに書き込む(ステップS410)。呼処理部43aから指示を受けた制御部44aは、外部記憶装置6に取得した電話番号を通知し、最大チャネル数及びアクティブチャネル数の読み出しを指示する。制御部44aは、外部記憶装置6が電話番号設定記憶部61内の電話番号設定情報から電話番号に対応して読み出した最大チャネル数及びアクティブチャネル数を受信し、呼処理部43aに出力する。呼処理部43aは、アクティブチャネル数が最大チャネル数より小さい場合に、着信を許可する(ステップS415)。
なお、電話番号に対応したアクティブチャネル数や最大チャネル数が電話番号設定情報から読み出せなかった場合、あるいは、アクティブチャネル数が最大チャネル数以上であった場合、呼処理部43aはダイアログを確立せず、呼を終了させる。
【0069】
呼処理部43aは、着信を許可する場合、SIPの仕様に従ってダイアログを確立するとともに、呼の再開に必要なSIPの情報を主記憶部45aに書き込む(ステップS420)。具体的には、以下のように動作する。
【0070】
呼処理部43aは、受信したINVITEパケットを主記憶部45aに書き込むとともに、INVITEパケットに設定されているfromタグ、callid、各種ヘッダフィールド、電話端末1が用いるRTPポート番号及びIPアドレス、電話端末のCSeqを読み出して主記憶部45aに書き込む。なお、RTPポート番号及びIPアドレスは、ACKパケットから取得する場合もある。
【0071】
呼処理部43aは、例えば、図7のステップS115〜S140の処理に示すように、SIPの仕様に従って180Tring、Ringing、200OKの送信、ACKの受信を行なう。呼処理部43aは、送受信したこれらの各SIPパケットを主記憶部45aに書き込むとともに、これらのSIPパケットに設定されている電話端末のCSeqやメディアサーバのCSeqメディアサーバのCSeq、各種ヘッダフィールドを主記憶部45aに書き込む。
【0072】
なお、呼処理部43aは、200OKを送信する際には、200OKに設定したtoタグと、メディアサーバ4aが用いるRTPポート番号及びIPアドレスとを主記憶部45aに書き込む。
また、各種ヘッダフィールドには、To、From、Record−Route、Viaヘッダフィールドがあるが、Record−Route、Viaヘッダフィールドは取得できない場合もある。
【0073】
電話端末1とのダイアログ確立後、制御部44aは、外部記憶装置6にステップS410において取得した電話番号を通知し、アクティブチャネル数の加算を指示する。外部記憶装置6は、電話番号により電話番号設定記憶部61内の電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数に1を加算する(ステップS425)。
【0074】
次に、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバのCSeq、電話端末のCSeq、INVITEパケットのToフィールドから取得した着信側の電話番号であるサーバ側電話番号、INVITEパケットのFromフィールドから取得した発信側の電話番号である端末側電話番号、各種ヘッダフィールドと、着信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置6に出力し、呼処理復旧情報への登録を指示する(ステップS430)。外部記憶装置6は、呼処理復旧情報記憶部63内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録呼処理復旧情報を設定する。
【0075】
さらに、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバ4aが用いるRTPポート番号及びIPアドレス、電話端末1が用いるRTPポート番号及びIPアドレスを登録音声処理復旧情報として外部記憶装置6に出力し、音声処理復旧情報への登録を指示する(ステップS435)。外部記憶装置6は、音声処理復旧情報記憶部64内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録音声処理復旧情報を設定する。
メディアサーバ4aの呼処理部43aは、制御部44aにダイアログの確立を通知する。
【0076】
ダイアログの確立の通知を受信した制御部44aは、主記憶部45aから着信先の電話番号を読み出すと、外部記憶装置6に読み出した電話番号を通知してIVR ID及び最大チャネル数の読み出しを指示する。メディアサーバ4aの制御部44aは、外部記憶装置6が電話番号に対応して電話番号設定記憶部61内の電話番号設定情報から読み出したIVR ID及び最大チャネル数を受信し、主記憶部45aに書き込む(ステップS440)。
【0077】
続いて、制御部44aは、外部記憶装置6に受信したIVR IDを通知してIVRフローシナリオの読み出しを指示する。制御部44aは、外部記憶装置6がIVR IDに対応してIVRフロー記憶部62内のIVRフローデータから読み出したIVRフローシナリオを受信し、主記憶部45aに書き込む(ステップS445)。
【0078】
次に、制御部44aは、外部記憶装置6に主記憶部45aから取得したtoタグ、fromタグ、及び、callidを通知してコマンド実行履歴の読み出しを指示する。制御部44aは、外部記憶装置6がtoタグ、fromタグ、及び、callidに対応してIVR処理情報記憶部65内のIVR処理情報から読み出したコマンド実行履歴を受信し、主記憶部45aに書き込む(ステップS450)。なお、コマンド実行履歴が読み出せなかった場合は、初期状態であると判断する。
【0079】
図11において、制御部44aは、IVR処理部46aに主記憶部45aに書き込んだIVRシナリオとコマンド実行履歴を出力し、IVRフローの実行を指示する。IVR処理部46aは、コマンド実行履歴がなく、初期状態であると判断した場合、IVRシナリオを最初から実行する。コマンド実行履歴に実行したコマンドが設定されている場合、そのコマンドにより示される途中のIVR処理からIVRシナリオを実行する(ステップS505)。
【0080】
音声処理部47aは、制御部44aの指示を受け、自メディアサーバ4aが使用するSSRC及びRTPシーケンスナンバを生成すると、主記憶部45aから自メディアサーバ4aが用いるRTPポート番号及びIPアドレスと、電話端末1が用いるRTPポート番号及びIPアドレスを読み出し、これらの情報を用いて電話端末1との間のRTPセッションを確立し、RTPパケットの送受信を開始する(ステップS510)。制御部44aは、メディアサーバのSSRC、最初に送信したRTPパケットに設定したRTPシーケンスナンバ、RTPセッションを開始した時間を示す発着信開始時間を主記憶部45aに書き込む。
【0081】
制御部44aは、RTPセッションが確立され、RTPパケットの送受信が行なわれると、主記憶部45aからtoタグ、fromタグ、callid、メディアサーバのSSRC、メディアサーバ4aが電話端末1とのRTPセッションにおいて最初に使用したRTPシーケンスナンバ、当該RTPセッションにおいて最初にRTPパケットを送信した時刻である発着開始時間を外部記憶装置6に通知し、音声処理復旧情報の更新を指示する(ステップS515)。外部記憶装置6は、toタグ、fromタグ及びcallidにより音声処理復旧情報記憶部64内の音声処理復旧情報のレコードを特定し、特定したレコードにメディアサーバ4のSSRC及びRTPシーケンスナンバと、発着開始時間とを書き込む。なお、toタグ、fromタグ及びcallidに対応したレコードが音声処理復旧情報に登録されていない場合、新たなレコードを追加し、追加したレコードにメディアサーバ4のSSRC及びRTPシーケンスナンバと、発着開始時間とを書き込む。
【0082】
メディアサーバ4aは、IVRシナリオを実行していく。具体的には、音声処理部47aは、IVR処理部46aからの指示により、電話端末1に対して再生音声のRTPパケットを送信し、エンドユーザにガイダンスを聞かせたり、電話端末1から受信したRTPパケットにより示されるDTMFや発話内容などをIVR処理部46aが認識したりする。IVR処理部46aは、DTMFやエンドユーザの発話などの音声を認識する度にその認識結果をIVR処理情報に追加するよう制御部44aに指示する。また、IVR処理部46aは、音声認識や音声再生などコマンドをひとつ実行する度に、現在実行しているIVRフローの位置を特定する情報をコマンド実行履歴としてIVR処理情報記憶部65に書き込むよう制御部44aに指示する。具体的には、制御部44aは、現在処理中の呼のtoタグ、fromタグ、callidと、認識結果あるいはコマンド実行履歴を通知して、IVR処理情報の更新を外部記憶装置6に指示する(ステップS520)。外部記憶装置6は、toタグ、fromタグ、callidによりIVR処理情報記憶部65内のIVR処理情報のレコードを特定し、特定したレコードに認識結果あるいはコマンド履歴を書き込む。
【0083】
メディアサーバ4aは、150秒以上など所定の時間以上通話が継続する場合(ステップS525:YES)、IVRフローを実行の合間に、セッションの継続確認処理を行なう。つまり、メディアサーバ4aの呼処理部43aは、所定の時間以上通話が継続していることを検出した場合、定期的にre−INVITEパケットあるいはUPDATEパケットを電話端末1に送信する(ステップS530)。
制御部44aは、呼処理部43aがre−INVITEパケットあるいはUPDATEパケットを送信することにより更新されたメディアサーバのCSeqにより呼処理復旧情報を更新する。つまり、制御部44aは、現在処理中の呼のtoタグ、fromタグ、callidと、更新されたメディアサーバのCSeqを外部記憶装置6に通知して、呼処理復旧情報の更新を指示する。外部記憶装置6は、toタグ、fromタグ、callidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードに記述されているメディアサーバのCSeqを、受信したCSeqにより更新する。
【0084】
また、メディアサーバ4aの呼処理部43aが、電話端末1からre−INVITEパケットあるいはUPDATEパケットを受信する場合もある。この場合、呼処理部43aは、受信したre−INVITEパケットあるいはUPDATEパケットのパケットからtoタグ、fromタグ、callid、及び、電話端末のCSeqを読み出して、制御部44aに出力する。制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callid及び電話端末のCSeqを外部記憶装置6に通知して、呼処理復旧情報の更新を指示する。外部記憶装置6は、toタグ、fromタグ、callidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードに記述されている電話端末のCSeqを、受信した電話端末のCSeqにより更新する。
【0085】
電話端末1からの通信断により通話が終了する場合、電話端末1からBYEパケットがメディアサーバ4aに送信される(ステップS525:NO、ステップS530:エンドユーザからの通信断)。メディアサーバ4aの呼処理部43aは、電話端末1から送信されたBYEパケットを受信すると、このパケットからtoタグ、fromタグ、callidを取得して制御部44aに出力する。
制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callidをIVR処理部46aに出力し、IVR処理の終了を指示する。制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callidにより特定される呼に対して実行していたIVRフローシナリオの実行を終了する(ステップS540)。
さらに、制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callidを音声処理部47aに出力し、RTPセッションの終了を指示する。音声処理部47aは、呼処理部43aから受信したtoタグ、fromタグ、callidにより特定される呼について確立していたセッションを終了する(ステップS545)。
呼処理部43aは、BYEパケットの応答として電話端末1に200OKを返送する(ステップS550)。
【0086】
あるいは、IVRフローが最後まで実行された場合、メディアサーバ4aからの通信断により通話が終了する(ステップS525:NO、ステップS530:メディアサーバからの通信断)。IVR処理部46aは、制御部44aに対してIVRフロー実行終了を通知する。
制御部44aが呼処理部43aにIVRフロー実行終了を通知すると、呼処理部43aは、電話端末1にBYEパケットを送信し(ステップS555)、電話端末1に通話終了を指示する。さらに、制御部44aは、音声処理部47aに停止命令を出力し、RTPセッションの終了を指示する。音声処理部47aは、電話端末1との間で確立していたセッションを終了する(ステップS560)。最後に、呼処理部43aは、電話端末1からBYEパケットの応答として200OKを受信する(ステップS565)。
【0087】
上記のいずれかにより通話が終了したことを認識したメディアサーバ4aの制御部44aは、ステップS550またはS565の後、主記憶部45aから終了した呼のtoタグ、fromタグ、callidを読み出して外部記憶装置6へ送信し、呼処理復旧情報、音声処理復旧情報、及び、IVR処理情報の削除を指示する。外部記憶装置6は、toタグ、fromタグ、callidにより特定される呼処理復旧情報のレコード、音声処理復旧情報のレコード、及び、IVR処理情報のレコードを削除する(ステップS570)。
【0088】
さらに、メディアサーバ4aの制御部44aは、終了した呼に対して実行していたIVRフローシナリオのIVR IDを外部記憶装置6へ送信し、アクティブチャネル数の減算を指示する(ステップS575)。外部記憶装置6は、IVR IDにより電話番号設定記憶部61が記憶している電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数を、1を減算した数に更新する。
【0089】
図12は、本実施形態による現用系のメディアサーバ4における発信時の処理フローを示す図である。
メディアサーバ4aの制御部44aは、発信制御装置7から発信指示を受信する(ステップS605)。発信指示には、サーバ側電話番号及び端末側電話番号が設定される。
【0090】
メディアサーバ4aの呼処理部43aは、発信指示から取得したサーバ側電話番号を外部記憶装置6に通知し、最大チャネル数及びアクティブチャネル数の読み出しを指示する(ステップS610)。制御部44aは、外部記憶装置6が電話番号に対応して電話番号設定記憶部61内の電話番号設定情報から読み出した最大チャネル数及びアクティブチャネル数を受信すると、これらを比較する。制御部44aは、アクティブチャネル数が最大チャネル数より小さい場合に着信を許可し、呼処理部43aに発信を指示する。
なお、サーバ側電話番号が電話番号設定情報に設定されていない場合、あるいは、アクティブチャネル数が最大チャネル数以上であった場合、制御部44aは発信を指示せず、処理を終了する。
【0091】
制御部44aから発信指示を受けた呼処理部43aは、SIPの仕様に従って電話端末1とのダイアログを確立するとともに、呼の再開に必要なSIPの情報を主記憶部45aに書き込む(ステップS615)。具体的には、以下のように動作する。
【0092】
呼処理部43aは、INVITEパケットを生成し、電話端末1に送信する。INVITEパケットのToフィールドには発信制御装置7から受信した端末側電話番号が、Fromフィールドには発信制御装置7から受信したサーバ側電話番号と、生成したfromタグが設定される。
制御部44aは、INVITEパケットを主記憶部45aに書き込むとともに、INVITEパケットに設定したfromタグ、callid、各種ヘッダフィールド、メディアサーバ4のRTPポート番号及びIPアドレス、メディアサーバのCSeqを読み出して主記憶部45aに書き込む。なお、RTPポート番号及びIPアドレスは、ACKパケットに設定される場合もある。
【0093】
呼処理部43aは、一般的なSIPの仕様に従って、180Tring、Ringing、200OKの受信、ACKの送信を行ない、電話端末1とのダイアログを確立する。呼処理部43aは、送受信したこれらの各SIPパケットを主記憶部45aに書き込むとともに、これらのSIPパケットに設定されている電話端末のCSeqやメディアサーバのCSeq、各種ヘッダフィールドを主記憶部45aに書き込む。
なお、呼処理部43aは、電話端末1から受信した200OKから、toタグと、電話端末1が用いるRTPポート番号及びIPアドレスを取得して主記憶部45aに書き込む。
また、各種ヘッダフィールドには、To、From、Record−Route、Viaヘッダフィールドがあるが、Record−Route、Viaヘッダフィールドは取得できない場合もある。
【0094】
電話端末1とのダイアログ確立後、制御部44aは、ステップS610において受信した発信指示から取得した電話番号を外部記憶装置6に通知し、アクティブチャネル数の加算を指示する。外部記憶装置6は、電話番号により電話番号設定記憶部61内の電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数に1を加算する(ステップS620)。
【0095】
以降、メディアサーバ4aは、図10のステップS430以降と同様の処理を行なう。ただし、ステップS430において、登録呼処理復旧情報には、発信を示す発着信フラグ、INVITEのFromフィールドから取得した発信側の電話番号であるサーバ側電話番号、INVITEパケットのToフィールドから取得した着信側の電話番号である端末側電話番号が設定される。
【0096】
図13は、本実施形態による現用系のメディアサーバ4の故障が検出されたときに待機系のメディアサーバ4が実行する復旧処理フローを示す図である。
IVR処理中にメディアサーバ4aの故障が発生した場合、図9に示すように待機系のメディアサーバ4bの監視部41bが現用系の故障を検出する。メディアサーバ4bの監視部41bは、復旧処理部48を起動する(ステップS705)。復旧処理部48bは、通信部40bにメディアサーバ4aの通信部40aが使用していたIPアドレスを引継がせ、メディアサーバ4bは現用系として起動する。
【0097】
メディアサーバ4bの復旧処理部48bは、外部記憶装置6の呼処理復旧情報記憶部63に記憶されている呼処理復旧情報を1レコードずつ特定し、特定したレコードを読み出して主記憶部45bに書き込むとともに、当該レコードからtoタグ、fromタグ及びcallidを読み出して(ステップS710)、以下の処理を行なう。なお、外部記憶装置6からtoタグ、fromタグ及びcallidのみを読み出すことでもよい。
【0098】
制御部44bは、ステップS710において取得したtoタグ、fromタグ及びcallidの組を外部記憶装置6に通知し、音声処理復旧情報、及び、IVR処理情報の読み出しを指示する(ステップS715)。制御部44bは、外部記憶装置6が各toタグ、fromタグ及びcallidの組に対応して読み出した音声処理復旧情報記憶部64内の音声処理復旧情報のレコード、及び、IVR処理情報記憶部65内のIVR処理情報内のレコードを受信し、主記憶部45bに書き込む。
【0099】
さらに、制御部44bは、ステップS710において主記憶部45bに保存した呼処理復旧情報記のレコードからサーバ側電話番号を取得すると、外部記憶装置6に取得したサーバ側電話番号を通知してIVR IDの読み出しを指示する。制御部44bは、外部記憶装置6がサーバ側電話番号に対応して電話番号設定記憶部61内の電話番号設定情報から読み出したIVR IDを受信する。まだこのIVR IDに対応したIVRフローを読み出していない場合、制御部44bは、外部記憶装置6に受信したIVR IDを通知してIVRフローシナリオの読み出しを指示する。制御部44bは、外部記憶装置6がIVR IDに対応してIVRフロー記憶部62内のIVRフローデータから読み出したIVRフローシナリオを受信し、主記憶部45bに書き込む。
【0100】
なお、コマンドの番号によりIVRフローシナリオが特定可能な場合、メディアサーバ4bの制御部44bは、ステップS715において主記憶部45bに保存したIVR処理情報のレコード内のコマンド実行履歴からコマンドを読み出して外部記憶装置6に通知し、IVRフローシナリオの読み出しを指示する。外部記憶装置6は、IVRフロー記憶部62内のIVRフローデータから、コマンドに対応したIVR処理が含まれているIVRフローを読み出してメディアサーバ4bへ出力する。
【0101】
メディアサーバ4bの音声処理部47bは、ステップS715において主記憶部45bに保存したIVR処理情報のレコード内のコマンド実行履歴からコマンドを読み出す。IVR処理部47bは、主記憶部45bに記憶されているIVRシナリオを、読み出したコマンドにより特定されるIVR処理から実行することによって、IVR処理を途中から再開する(ステップS720)。
【0102】
音声処理部47bは、ステップS715において制御部44bが特定したIVR処理情報のレコードに設定されている値を用いて、電話端末1との間のRTPセッションを再開する(ステップS725)。
具体的には、制御部44bが、ステップS715において読み出した音声処理復旧情報のレコードから発着信開始時間とメディアサーバ4のRTPシーケンスナンバを読み出す。制御部44bは、発着信開始時間から現在の時間までの経過時間を算出すると、この経過時間をRTPパケットの送出間隔で除算することにより、RTPシーケンスナンバの増加分を算出する。RTPの受信側では、RTPシーケンスナンバが1ずつ増加しているかの検証を行なっているため、算出した増加分に所定の定数を加算するなどし、エラーとならない範囲の値としてもよい。制御部44bは、音声処理復旧情報のレコードから読み出したRTPシーケンスナンバに、算出した増加分を加算して、音声処理部47bから送信する最初のRTPパケットに設定すべきRTPシーケンスナンバを算出すると、音声処理部47bへ通知する。また、制御部44bは、通信部40bに指示し、読み出した音声処理復旧情報のレコードで示されるメディアサーバのRTPポートとIPアドレスをオープンする。
【0103】
音声処理部47bは、IVR処理による音声をRTPパケットにより電話端末1へ送信するとともに、電話端末1から送信されたRTPパケットを受信する。電話端末1に送信されるRTPパケットには、ステップS715において読み出したIVR処理情報のレコードに設定されているメディアサーバ4のSSRCと、電話端末1のRTPポート番号及びIPアドレスが用いられる。最初にメディアサーバ4bから送信するRTPパケットには、制御部44bから通知されたRTPシーケンスナンバを用いる。また、音声処理部47bは、ステップS715において読み出したIVR処理情報のレコードに設定されているメディアサーバ4のRTPポート番号及びIPアドレスを用いたRTPパケットを電話端末1から受信する。
【0104】
続いて復旧処理部48bは、外部記憶装置6の呼処理復旧情報記憶部63に記憶されている呼処理復旧情報の中で、まだ読み出していないレコードがあるかを判断し(ステップS730)、まだ読み出していないレコードがあれば(ステップS730:YES)、ステップS710からの処理を行う。一方、全てのレコードについて読み出しを行なったならば(ステップS730:NO)、メディアサーバ4bにおいて、以降、メディアサーバ4aが行なっていたステップS520からの処理を行なう。つまり、各部の符号の最後記載されている「a」を「b」に置き換えればよい。
【0105】
なお、本実施形態のメモリ情報共有方式は、基本的には全てのデータを外部記憶装置6に保持する。そのため、電話端末1からSIP信号を受信すると、メディアサーバ4の呼処理部43は、受信したSIP信号から取得したtoタグ、fromタグ、及び、callidタグにより特定される外部記憶装置6内の呼処理復旧情報、音声処理復旧情報のレコードに対して情報の参照や書込みを行い、呼処理を実行する。ただし、処理の高速化のために外部記憶装置6と同様の情報をメディアサーバ4の主記憶部45上に保持し、データを読むだけの場合は主記憶部45から情報を取得し、データに更新があった場合のみ外部記憶装置6にアクセスして情報を更新するようにしてもよい。
【0106】
[第2の実施形態:メモリ情報再構築方式]
次に、本発明の第2の実施形態によるIVRシステムについて説明する。
本実施形態では、メモリ情報再構築方式によるフェールオーバを実現する。メモリ情報再構築方式では、メディアサーバ4は、SIPの処理を実行するための情報を自サーバ内のメモリに保持しており、受信したINVITEパケットや200OKパケット等のパケット自体を外部記憶装置6に記憶しておく。そして、現用系のメディアサーバ4が故障時した時には、待機系のメディアサーバ4が外部記憶装置6からINVITEパケットやACKパケットを読み込み、自らに当該パケットを送信して現用系が故障前に保持していたメモリの内容を待機系のメモリに再構築して状態復帰処理を行う。なお、待機系のメディアサーバ4は、自身が送信した状態復帰用のパケットに暫定応答を返さない等の特別なロジックを実装する必要がある。なお、RTP関連の情報及びIVR関連の情報の保存や復旧については、メモリ情報共有方式と同様である。
【0107】
上記のように、メモリ情報再構築方式は、現用系のメディアサーバ4の故障時は現用系が受信したパケットを待機系のメディアサーバ4に送信することで、待機系のメディアサーバ4が保持するメモリ情報を、現用系のメディアサーバ4と同じように復旧させる方式であり、メモリ情報共有方式に比べて改修範囲が少ないため、実装が比較的容易である。
以下では、第1の実施形態との差分について説明する。
【0108】
本実施形態によるIVRシステムの構成は、図1に示す第1の実施形態によるIVRシステムの構成と同様である。
また、本実施形態による外部記憶装置6に記憶されるIVRフローデータ、電話番号設定情報、及び、IVR処理情報は、第1の実施形態と同様である。
【0109】
図14は、本実施形態による呼処理復旧情報記憶部63に記憶される呼処理復旧情報のデータ構成例を示す図である。同図に示すように、呼処理復旧情報は、toタグ、fromタグ、callid、INVITEパケット、ACKパケット、200OKパケット、メディアサーバのCSeq、電話端末のCSeq、発着信フラグ、サーバ側電話番号、端末側電話番号を対応付けたレコードからなり、各レコードは通話単位で生成される。メディアサーバ4への着信時にINVITEパケット、ACKパケットが保存され、メディアサーバ4からの発信時に200OKパケットが保存される。
【0110】
図15は、本実施形態による音声処理復旧情報記憶部64に記憶される音声処理復旧情報のデータ構成例を示す図である。同図に示すように、音声処理復旧情報は、toタグ、fromタグ、callid、発着信開始時間、メディアサーバ4のRTPシーケンスナンバ、SSRC、RTPポート番号及びIPアドレスを対応付けたレコードからなり、各レコードは通話単位で生成される。なお、電話端末のRTPポート番号及びIPアドレスは呼処理復旧情報に記録されているSIPメッセージ中に記述される。
【0111】
図16は、本実施形態によるIVRシステムにおける故障発生時のシーケンスを示す図である。
同図において、ステップS805〜S840までの処理は、図8のステップS205〜S240の処理と同様である。
メディアサーバ4bはメディアサーバ4aの故障を検知すると、外部記憶装置6から呼処理復旧情報を読み出す(ステップS845)。メディアサーバ4bは、読込んだ呼処理復旧情報を用い、電話端末1から受信したものと同じSIPパケットを内部的に自メディアサーバ4b宛に送信する。ただし、この内部的に受信したSIPパケットに対する応答は電話端末1へは送信しない。これにより、メディアサーバ4bは、SIP処理に必要な情報を構築して主記憶部45bに記憶する(ステップS850)。
以降、ステップS855〜S880までの処理は、図8のステップS245〜S270の処理と同様である。
ステップS885において、電話端末1からSIPパケットを受信すると、メディアサーバ4bは、ステップS850において構築し、内部に記憶している情報を参照して、すでに確立済みのセッションのSIPパケットかを確認する(ステップS885)。
【0112】
次に、本実施形態によるメディアサーバ4における処理フローについて説明する。本実施形態による監視フローは、図12に示す第1の実施形態と同様である。
【0113】
図17は、本実施形態による電話端末1から現用系のメディアサーバ4への着信時のシーケンス例を示す図である。
同図において、ステップS905〜S925までの処理は、図10に示すS405〜S425までの処理と同様である。
ステップS930において、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、INVITEパケット、ACKパケット、メディアサーバのCSeq、電話端末のCSeqと、着信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置6に出力し、呼処理復旧情報への登録を指示する(ステップS930)。外部記憶装置6は、呼処理復旧情報記憶部63内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録呼処理復旧情報を設定する。
【0114】
さらに、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバ4aが用いるRTPポート番号及びIPアドレスを登録音声処理復旧情報として外部記憶装置6に出力し、音声処理復旧情報への登録を指示する(ステップS935)。外部記憶装置6は、音声処理復旧情報記憶部64内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録音声処理復旧情報を設定する。
メディアサーバ4aの呼処理部43aは、制御部44aにダイアログの確立を通知する。以降は、図10のステップS440からの処理を行う。
【0115】
図18は、本実施形態による現用系のメディアサーバ4における発信時の処理フローを示す図である。
同図において、ステップS1005〜S1020までの処理は、図9に示すS605〜S620までの処理と同様である。
ステップS1025において、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、200OKパケット、メディアサーバのCSeq、電話端末のCSeq、サーバ側電話番号、端末側電話番号と、発信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置6に出力し、呼処理復旧情報への登録を指示する(ステップS1025)。外部記憶装置6は、呼処理復旧情報記憶部63内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録呼処理復旧情報を設定する。
【0116】
さらに、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバ4aが用いるRTPポート番号及びIPアドレスを登録音声処理復旧情報として外部記憶装置6に出力し、音声処理復旧情報への登録を指示する(ステップS1030)。外部記憶装置6は、音声処理復旧情報記憶部64内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録音声処理復旧情報を設定する。
メディアサーバ4aの呼処理部43aは、制御部44aにダイアログの確立を通知する。以降は、図10のステップS440からの処理を行う。
【0117】
図19は、本実施形態による現用系のメディアサーバ4の故障が検出されたときに待機系のメディアサーバ4が実行する復旧処理フローを示す図である。
IVR処理中にメディアサーバ4aの故障が発生した場合のステップS1105〜S1115におけるメディアサーバ4bの処理は、図13のステップS705〜S715までの処理と同じである。ただし、ステップS1110において、復旧処理部48bは、特定した外部記憶装置6から、呼処理復旧情報のレコードから読み出したtoタグ、fromタグ及びcallidと、発着信フラグとを受信する。
【0118】
ステップS1110において読み出した発着信フラグが着信を示している場合(ステップS1120:着信)、復旧処理部48bからの指示を受けた制御部44bは、ステップS1110において読み出したtoタグ、fromタグ及びcallidを外部記憶装置6に出力し、INIVITEパケット及びACKパケットの読み出しを指示する(ステップS1125)。外部記憶装置6は、toタグ、fromタグ及びcallidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードからINVITEパケット及びACKパケットを読み出してメディアサーバ4bに出力する。
【0119】
復旧処理部48bは、外部記憶装置6から読み出したINVITEパケットを呼処理部43bに対して内部的に送信する。これにより、呼処理部43bは、INVITEパケット受信時の処理と同様の処理を行なう(ステップS1130)。呼処理部43bは、図10のステップS420における処理と同様に、INVITEパケットを主記憶部45bに書き込むとともに、INVITEパケットに設定されているfromタグ、callid、各種ヘッダフィールド、電話端末1が用いるRTPポート番号及びIPアドレス、電話端末のCSeqを読み出して主記憶部45bに書き込む。
【0120】
続いて、呼処理部43bは、ステップS1130において内部的に送信されたINVITEパケットに対する200OKパケットを生成し、200OKパケットを送信した場合と同様の処理を行なう(ステップS1135)。200OKのメディアサーバ4のRTPポート番号及びIPアドレスには、ステップS1115において読み出した音声処理復旧情報のレコード内のRTPポート番号及びIPアドレスが設定される。また、200OKパケットのToフィールドには、ステップS1110において読み出したtoタグを使用する。なお、実際には200OKパケットの送信は行なわない。これにより、図10のステップS420における処理と同様に、呼処理部43bは、この生成した200OKパケットを主記憶部45bに書き込むとともに、200OKに設定したtoタグと、メディアサーバ4bが用いるRTPポート番号及びIPアドレス、メディアサーバのCSeq、各種ヘッダフィールドを主記憶部45bに書き込む。
【0121】
続いて、復旧処理部48bは、ステップS1125において外部記憶装置6から読み出したACKパケットを呼処理部43bに対して内部的に送信する。これにより、呼処理部43bは、ACKパケット受信時の処理と同様の処理を行なう(ステップS1140)。呼処理部43bは、図10のステップS420における処理と同様に、送信したこのACKパケットを主記憶部45bに書き込むとともに、各種ヘッダフィールドを主記憶部45bに書き込む。
上記処理により、メディアサーバ4bは、図17のステップS920と同じ状態になる。
【0122】
一方、ステップS1110において読み出した発着信フラグが発信を示している場合(ステップS1120:発信)、ステップS1110において読み出したtoタグ、fromタグ及びcallidを外部記憶装置6に出力し、呼処理復旧情報の読み出しを指示する(ステップS1145)。外部記憶装置6は、toタグ、fromタグ及びcallidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードを読み出してメディアサーバ4bに出力する。
【0123】
復旧処理部48bからの指示を受け呼処理部43bは、外部記憶装置6から読み出した呼処理復旧情報のレコードからINVITEパケットを生成する。これにより、呼処理部43bは、INVITEパケット送信時の処理と同様の処理を行なうが、実際には送信を行なわない(ステップS1150)。INVITE信号のToフィールドには読み出した呼処理復旧情報のレコード内の端末側電話番号が、Fromフィールドには当該呼処理復旧情報のレコード内のサーバ側電話番号とfromタグが、callidには読み出した当該呼処理復旧情報のレコード内のcallidが、メディアサーバのCSeqには1が、メディアサーバ4のRTPポート及びアドレスにはステップS1115において読み出した音声処理復旧情報のレコードから読み出したRTPポート番号及びIPアドレスが設定される。呼処理部43bは、図12のステップS615における処理と同様に、呼処理部43bは、INVITEパケットを主記憶部45bに書き込むとともに、INVITEパケットに設定されているfromタグ、callid、各種ヘッダフィールド、メディアサーバ4bが用いるRTPポート番号及びIPアドレス、メディアサーバのCSeqを読み出して主記憶部45bに書き込む。
【0124】
続いて、復旧処理部48bは、ステップS1150において読み出した呼処理復旧情報のレコードに設定されている200OKを呼処理部43bに対して内部的に送信する。これにより、呼処理部43bは、200OKパケット受信時の処理と同様の処理を行なう(ステップS1155)。呼処理部43bは、図12のステップS615における処理と同様に、受信した200OKパケットを主記憶部45bに書き込むとともに、toタグ、電話端末1が用いるRTPポート番号及びIPアドレス、電話端末のCSeq、各種ヘッダフィールドを主記憶部45bに書き込む。
【0125】
続いて、復旧処理部48bは、ACKパケットを生成するとともに、ACKパケットを送信した場合と同様の処理を行なう(ステップS1160)。ACKパケットには、INVITE信号と同様のToフィールド、Fromフィールド、callid、メディアサーバのCSeqが設定される。ただし、実際にはACKパケットの送信は行なわない。これにより、図12のステップS615における処理と同様に、呼処理部43bは、このACKパケットを主記憶部45bに書き込むとともに、ACKに設定したfromタグと、メディアサーバのCSeqを主記憶部45bに書き込む。
上記により、メディアサーバ4bは、図18のステップS1015と同じ状態になる。
【0126】
メディアサーバ4bの音声処理部47bは、図13のステップS720と同様の処理により主記憶部45bに保存されたIVR処理情報のレコードを用いてIVR処理を途中から再開し(ステップS1165)、音声処理部47bは、図13のステップS725と同様の処理により、ステップS1115において制御部44bが特定したIVR処理情報のレコードに設定されている値を用いて、電話端末1との間のRTPセッションを再開する(ステップS1170)。
【0127】
続いて復旧処理部48bは、外部記憶装置6の音声処理復旧情報記憶部64に記憶されている音声処理復旧情報の中で、まだ読み出していないレコードがあるかを判断し(ステップS1175)、まだ読み出していないレコードがあれば(ステップS1175:YES)、ステップS1110からの処理を行う。一方、全てのレコードについて読み出しを行なったならば(ステップS1175:NO)、メディアサーバ4bにおいて、以降、メディアサーバ4aが行なっていたステップS520からの処理を行なう。つまり、各部の符号の最後に記載されている「a」を「b」に置き換えればよい。
【0128】
上述したように、本実施形態によれば、現用系のメディアサーバは、セッションが確立したときにSIP、RTPの復旧に必要な情報を外部記憶装置に書込み、IVR処理が開始されると、外部記憶装置にIVR処理の更新状況をリアルタイムに書込み、RTPに関する情報は書き込まない。よって、外部記憶装置に対するアクセスの負荷をかけすぎることなく、メディアサーバは故障が発生した際に引継ぎが必要な情報を外部記憶装置に書き込むことができ、音声パケットに遅延を発生させることもない。なお、SIPの更新情報はセッション確立後も外部記憶装置へ書込む場合がある。通話中に現用系のメディアサーバが故障した場合も、通話がとぎれることなく、待機系のメディアサーバは、故障が発生した時点から引続きIVRシナリオを提供することができる。このように、メディアサーバのセッションフェールオーバを実現することができるため、信頼性の高いシステムを実現することが可能となる。
【0129】
上述の電話端末1、中継サーバ2、メディアサーバ4、外部記憶装置6、及び、発信制御装置7は、内部にコンピュータシステムを有している。そして、電話端末1、中継サーバ2、メディアサーバ4の監視部41及びメディア処理プログラム実行部42、外部記憶装置6、ならびに、発信制御装置7の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、CPU及び各種メモリやOS、周辺機器等のハードウェアを含むものである。
【0130】
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0131】
なお、本発明は、上記において説明した実施形態に限定されるものではなく、その主旨を逸脱しない範囲において種々変更可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【符号の説明】
【0132】
1…電話端末
2…中継サーバ
3…ルータ
4、4a、4b…メディアサーバ
40、40a、40b…通信部
41、41a、41b…監視部
42、42a、42b…メディア処理プログラム実行部
43、43a、43b…呼処理部
44、44a、44b…制御部
45、45a、45b…主記憶部
46、46a、46b…IVR処理部
47、47a、47b…音声処理部
48、48a、48b…復旧処理部
6…外部記憶装置
60…記憶部
61…電話番号設定記憶部
62…IVRフロー記憶部
63…呼処理復旧情報記憶部
64…音声処理復旧情報記憶部
65…IVR処理情報記憶部
7…発信制御装置
【技術分野】
【0001】
本発明は、音声自動応答中に故障が発生した際のセッションフェールオーバを行なうメディアサーバ、セッション復旧方法及びコンピュータプログラムに関する。
【背景技術】
【0002】
固定電話では、エンドユーザの電話料金は距離により変わる。そこで、音声による自動応答を行なうIVR(Interactive Voice Response)機能を全国規模で提供する場合、エンドユーザの電話料金を低く抑えるために、通信距離が短くなるようメディアサーバを全国各地に配置することが多い。しかし、全国各地にメディアサーバを配置すると、設備や保守などにかかるコストが高くなってしまうという問題が生じる。
【0003】
一方、ここ10年の間にインターネットやIP(Internet Protocol)電話の普及がすすみ、また、VoIP(Voice over IP)やインスタントメッセージ等のリアルタイムサービスに用いられるプロトコルであるSIP(Session Initiation Protocol)の標準化が行なわれ、通信キャリアによるIP電話サービス(VoIPサービス)も広く提供されてきている。
【0004】
VoIPでは通信費が距離に依存して変化しないため、VoIPを用いれば、各地に点在していたメディアサーバを1箇所に集約することができる。近年は、IP電話サービスの品質が安定し、信頼性も高くなってきたことから、今後、コスト削減のためVoIPを用いたメディアサーバの集約が進むと考えられる。しかし、メディアサーバを集約すると、故障時には影響が全国に及んでしまうため、メディアサーバにはこれまで以上の高い信頼性が要求されるようになる。
【0005】
このように、今後はメディアサーバには高い信頼性が要求されると予想されるが、一方低価格化の圧力も大きい。そのため、例えば、ハードウェア面では、高価だが高品質・高信頼性のメインフレームから安価だが故障率の高いIAサーバを用いたSI(システムインテグレーション)に移行する事例も増えてきた。また、ソフトウェア面では、安価なオープンソースソフトウェアを用いた開発も増えてきた。オープンソースソフトウェアはコストを抑えられるものの、ベンダー製品よりも品質が劣る場合もあり、アプリケーション側でエラーが生じる確率が高くなる場合も考えられる。
【0006】
システムの信頼性については、ハードウェアの故障の問題はFT(フォルトトレラント)サーバを用いることにより解決できる。FTサーバではCPU(central processing unit)やメモリなどのハードウェアコンポーネントが全て2重化されており、ハードウェアコンポーネントの一方が故障してもシステムを全く止めることなく、瞬断もせずに動作を継続することができる。FTサーバを導入すれば、ハードウェア故障の心配はなくなるが、非常に高価なことが導入のネックとなっている。また、FTサーバはハードウェアの故障には対応できるが、アプリケーションが何らかのエラーにより落ちた場合にはサービスがストップしてしまうという問題がある。
【0007】
そこで、ミッションクリティカルでないシステムでは、システムの信頼性を高めるために、システムを冗長化して障害によるシステム停止を最小限にするHA(高可用性:High Availability)構成を採用することが多い。HA構成(クラスタ構成ともいう)では、現用系サーバに故障が発生した場合、クラスタ監視アプリケーションが待機系サーバの業務アプリケーションを自動で起動させる。HA構成には、データを共有ディスク上に置き、この共有ディスクを複数のサーバで利用する共有ディスクタイプと、各サーバのディスクをサーバ間でミラーするデータミラータイプがある。HA構成ならば、サービスの瞬断が発生するが、ソフトウェア/ハードウェアのいずれが故障した場合でも、現用系サーバから待機系サーバへの切り替えを行って動作を継続することができる。HA構成は世界で広く用いられている信頼性確保の方式であり、HTTP(Hypertext Transfer Protocol)やDB(データベース)といった非リアルタイムのプロコトルにおいての使用実績は多い。しかし、現用系から待機系に切り替えるために10秒程度かかることもあり、VoIPのようなリアルタイムサービスにおいて用いるには適さないのが現状である。
【0008】
また、IVRサービスは、エンドユーザ側のIP電話端末とSIPパケットを中継する中継機とIVR機能を有するメディアサーバにより構成されることが多い。中継機はキャリアが管理するサーバであり、着信先の相手を検索して通話を確立させる役割を持つ。中継機が故障すると、IP電話を使用する全てのユーザが通話不能となる。
特許文献1及び特許文献2には、現用系中継機であるSIPサーバがセッションを確立する度に外部記憶装置にセッション情報を書き込んでおき、現用系中継機の故障時には待機系中継機がその故障を察知し、現用系として起動することが記載されている。特許文献1では、待機系中継機は起動時に外部記憶装置から情報を読み込んで全てのセッションを復旧させており、特許文献2では、現用系とし起動した待機系中継機が、SIPパケットを受信したときに外部記憶装置から情報を取得し、受信したセッションの情報だけを復旧している。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2007−81933号公報
【特許文献2】特開2008−103952号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
一般に電話系のサービスは、固定電話をはじめ極めて品質の高いサービスが多く、エンドユーザもその品質が当たり前と考えていることが多い。そのため、故障時に通話が切断されることは大きな問題となる。
一方メディアサーバをVoIPにより構築しようとする企業では、これまでは、コストを優先し、FTサーバではない安価なハードウェア、オープンソースソフトウェアなどの安価なソフトウェアによりIVRシステムを構築することが多く、アプリケーションの故障率が高くなり信頼性が低くなる可能性が想定された。
【0011】
しかし、今後は、大規模かつ高信頼性を求められるIVRシステムがVoIP上で構築される可能性が高いため、音声通話のセッションフェールオーバ機能が必要になると予想される。すなわち、アプリケーション/ハードウェアのいずれの故障時であっても通話が切断されずに現用系から待機系に処理が引継がれる、拠点集約にも耐えうる高信頼な電話システムの構成が切望されている。
【0012】
中継機は、故障するとIP電話を使用する全てのユーザが通話不能となるため、基本的に二重化されている。上述した特許文献1や特許文献2の技術は、中継機におけるSIPセッションを復旧させる技術である。特許文献1や特許文献2の技術をメディアサーバで実現しようとした場合、メディアサーバに必要なRTP(Real-Time Transport Protocol)セッションやIVR処理を復旧させることはできないという問題があった。
【0013】
また、特許文献1や特許文献2の技術をメディアサーバで実現しようとした場合、外部装置の負荷が高くなりすぎるという問題もある。特許文献1及び特許文献2では、中継機の二重化をHA構成により実現している。中継機のように、リアルタイムで動作する必要のないサーバであれば、サーバが保持する情報に更新があった場合、その都度、更新内容を共有ディスクに反映させることにより、現用系の故障時には待機系サーバにおいてその共有ディスクの内容を参照して動作を継続することができる。しかし、メディアサーバはリアルタイムで動作するため、単純なHA構成では二重化することはできない。
【0014】
すなわち、中継機では3分ほどの通話でも5〜6パケットしか受信せず、例えば、100人のエンドユーザが通話している状態を仮定しても、3分で500〜600のSIPパケットを受信する程度であり、共有ディスクに変更した情報を記憶するための負荷は3.3アクセス/秒程度と想定される。また、SIPの仕様上、パケット受信後直ちに応答する必要もなく、30秒ほどの余裕がある。
【0015】
ところが、メディアサーバはリアルタイムで動作するためデータの更新が頻繁に生じる。メディアサーバでは、1つの通話で50パケット/秒という多数の音声パケットを受信するため、例えば、100人のエンドユーザが通話している状態を考えると、共有ディスクに対して5000アクセス/秒程度の負荷があると予想される。これでは、共有ディスクへの書込みが間に合わなくなり、単純なHA構成では対応できない可能性が高い。また、音声パケットの場合、送信に10ミリ秒以上の遅延が生じると、音声が途切れる等の影響が発生するが、これほどの負荷をかけながら10ミリ秒以内の遅延で音声パケットの送受信することは非常に困難である。
【0016】
さらには、特許文献1では、全てのSIPパケットを外部記憶装置に記憶しており、書込み及び読み出しの負荷が高い。
加えて、特許文献1及び特許文献2では、復旧に必要な情報を次々に追記し、削除しておらず、ディスクの利用効率や外部記憶装置の応答性能に影響を与える可能性がある。
【0017】
このような特許文献1及び2の問題点に加え、先に述べたような拠点集約に耐えうる高い信頼性を実現すること、低価格の圧力でFTサーバによるハードウェア故障の回避を採用できない場合にも信頼性を確保すること、低価格の圧力からベンダー製品よりも品質が低い場合もあるオープンソースソフトウェアの使用率が向上しているためアプリケーションエラーが生じやすい可能性があること、電話系のサービスは他のサービスと比較して高品質を求められやすいことなどを勘案して、メディアサーバのセッションフェールオーバを実現する必要がある。
【0018】
本発明は、上記の事情に鑑みてなされたものであり、その目的は、IVR機能によりIPネットワークを介して音声データを提供している際にメディアサーバに故障が発生した場合であっても、SIP及びRTPセッションを回復し、故障発生が発生した時点から迅速にIVRシナリオを再開することができるメディアサーバ、セッション復旧方法及びコンピュータプログラムを提供することにある。
【課題を解決するための手段】
【0019】
上記課題を解決するため、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバであって、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理部と、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理部と、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力する音声処理部と、前記呼処理部により送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理部により実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理部が前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む制御部と、他のメディアサーバの故障を検出する監視部と、前記監視部により現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理部とを備え、前記音声自動応答処理部は、前記復旧処理部が読み出した前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行し、前記音声処理部は、前記復旧処理部が読み出した前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理部から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力し、前記呼処理部は、前記復旧処理部が読み出した前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう、ことを特徴とするメディアサーバである。
【0020】
また、本発明は、上述したメディアサーバであって、呼の復旧に用いられる情報は、送受信した前記呼制御信号から取得した発側電話番号、着側電話番号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含むことを特徴とする。
【0021】
また、本発明は、上述したメディアサーバであって、呼の復旧に用いられる情報は、前記電話端末から受信した呼制御信号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含み、前記復旧処理部は、前記外部記憶装置から読み出した前記呼処理復旧情報に設定されている前記呼制御信号を前記呼処理部に送信し、前記呼処理部は、前記復旧処理部から送信された前記呼制御信号に基づいて前記電話端末との間の呼のセッションを確立する、ことを特徴とする。
【0022】
また、本発明は、上述したメディアサーバであって、メディアセッションの復旧に用いられる前記情報は、発信側及び着信側のメディアセッション用のアドレスと、メディアセッションに特有の値が設定された情報と、音声パケットの送信に伴い値が更新される情報のメディアセッション確立時の値と、前記メディアセッションの開始時刻とを含み、前記音声処理部は、前記復旧処理部により読み出された前記音声処理復旧情報から前記開始時刻と、音声パケットの送信に伴い更新される前記情報のメディアセッション確立時の値とを取得し、前記開始時刻からの経過時間に基づいて更新される前記情報の現在の値を算出し、前記音声処理復旧情報から読み出した、発信側及び着信側のメディアセッション用の前記アドレスと、メディアセッションに特有の値が設定された前記情報と、算出した前記値を設定した、音声パケットの送信に伴い更新される前記情報とを用いて前記呼のメディアセッションを復旧する、ことを特徴とする。
【0023】
また、本発明は、上述したメディアサーバであって、前記制御部は、解放された呼の呼特定情報を含む前記呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から削除する、ことを特徴とする。
【0024】
また、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバに用いられるセッション復旧方法であって、呼処理部が、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、音声自動応答処理部が、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、音声処理部が、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部へ出力する音声処理ステップと、制御部が、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、監視部が、他のメディアサーバの故障を検出する監視ステップと、復旧処理部が、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、前記音声自動応答処理部が、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、前記音声処理復旧が、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、前記呼処理部が、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、を有することを特徴とするセッション復旧方法である。
【0025】
また、本発明は、ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバとして用いられるコンピュータに、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から音声パケットを受信する音声処理ステップと、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、他のメディアサーバの故障を検出する監視ステップと、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、を実行させることを特徴とするコンピュータプログラムである。
【発明の効果】
【0026】
本発明によれば、音声送出中に現用系のメディアサーバが故障した場合であっても、通話がとぎれることなく、待機系のメディアサーバによって、故障が発生した時点から引き続きIVRシナリオを提供することができる。このように、メディアサーバのセッションフェールオーバを実現することができるため、FTサーバと比較して故障率の高いハードウェアを使用した場合や、オープンソースソフトウェアのようにベンダー製品と比較して品質の劣る可能性のあるソフトウェアを使用した場合でも、信頼性の高いシステムを実現することが可能となる。従って、安価なハードウェア、ソフトウェアを使用し、メディアサーバの集約を実現することができるため、導入、運用、保守のコストを軽減することが可能となる。
【図面の簡単な説明】
【0027】
【図1】本発明の第1の実施形態によるIVRシステムの機能ブロック図である。
【図2】同実施形態による電話番号設定情報のデータ構成例を示す図である。
【図3】同実施形態によるIVRフローデータのデータ構成例を示す図である。
【図4】同実施形態による呼処理復旧情報のデータ構成例を示す図である。
【図5】同実施形態による音声処理復旧情報のデータ構成例を示す図である。
【図6】同実施形態によるIVR処理情報のデータ構成例を示す図である。
【図7】同実施形態による着信時のシーケンスを示す図である。
【図8】同実施形態による故障発生時のシーケンスを示す図である。
【図9】同実施形態による監視フローを示す図である。
【図10】同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。
【図11】同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。
【図12】同実施形態による現用系メディアサーバの発信時の処理フローを示す図である。
【図13】同実施形態による待機系メディアサーバの復旧処理フローを示す図である。
【図14】第2の実施形態による呼処理復旧情報のデータ構成例を示す図である。
【図15】同実施の形態による音声処理復旧情報のデータ構成例を示す図である。
【図16】同実施形態による故障発生時のシーケンスを示す図である。
【図17】同実施形態による現用系メディアサーバの着信時の処理フローを示す図である。
【図18】同実施形態による現用系メディアサーバの発信時の処理フローを示す図である。
【図19】同実施形態による待機系メディアサーバの復旧処理フローを示す図である。
【発明を実施するための形態】
【0028】
以下、図面を参照して本発明の実施形態の例について説明する。
【0029】
[第1の実施形態:メモリ情報共有方式]
本実施形態では、メモリ情報共有方式による音声通話のセッションフェールオーバを実現する。メモリ情報共有方式では、IVR(Interactive Voice Response:音声自動応答)システムにおける現用系のメディアサーバはSIP(Session Initiation Protocol)関連の情報全てを外部記憶装置に保存しておき、この現用系のメディアサーバに故障が発生した場合、待機系のメディアサーバが外部記憶装置に保存しているSIP関連の情報を用いて呼処理を継続するものである。
【0030】
図1は、本発明の一実施形態によるIVRシステムの機能ブロック図である。IVRとは、エンドユーザからの電話に自動で応答し、「○○の方は1番を押してください」のような音声を再生することにより、ユーザを誘導してオペレータに転送したり、エンドユーザに情報提供を提供したりする音声自動応答機能を有する音声自動応答システムをいう。
【0031】
同図に示すように、IVRシステムは、電話端末1、中継サーバ2、メディアサーバ4、外部記憶装置6、発信制御装置7を備える。電話端末1及び中継サーバ2は、IP(Internet Protocol)網であるネットワークNに接続される。同図において電話端末1は、1台のみが記載されているが、複数台がネットワークNに接続される。2台のメディアサーバ4は、ルータ3を介してネットワークNと接続され、メディアサーバ4、外部記憶装置6、及び、発信制御装置7は、LAN(Local Area Network)などの私設網を介して接続される。
【0032】
同図においては、メディアサーバ4として2台のメディアサーバ4a、4bが記載されているが、3台以上が備えられてもよい。ここでは、メディアサーバ4aが現在動作している現用系、メディアサーバ4bが現用系の故障時に処理を引継ぐ待機系であるとする。なお、メディアサーバ4が3台以上ある場合の現用系と待機系のサーバ台数比はN対M(N、Mは1以上)である。
【0033】
音声通話のセッションフェールオーバでは、現用系のメディアサーバ4が故障した場合、待機系のメディアサーバ4に動作が引継がれて通話が継続される。例えば、現用系のメディアサーバ4aから「○○の方は1番を押してください」とのアナウンスが流れ、エンドユーザが電話端末1に「1」を入力したのち、再びメディアサーバ4aから「△△の方は…」のようなアナウンスが流れている途中でメディアサーバ4aの故障が発生したとする。この場合、待機系のメディアサーバ4bが起動して、故障が発生した途中のアナウンスから再開し、「△△の方は、2番を押してください。」とのアナウンスを流して引き続きIVR処理を行なう。現用系から待機系への切り替え時には数秒間の無音が発生してもよい。
【0034】
待機系に切り替わる時に必要な情報は、SIP関連の情報、RTP(Real-Time Transport Protocol)関連の情報、IVR関連の情報である。SIPとは、IP電話により電話をかける相手を探しだすために使用されることが多い呼制御用のプロコトルであり、RFC(Request for Comments)3261に詳しい仕様が記載されている。RTPとは、音声データなどをリアルタイムに伝送するために用いられるプロトコルであり、RTPパケットには、アナログの音声を符号化した音声データが設定される。
【0035】
本実施形態によるIVRシステムに適用されるメモリ情報共有方式では、現用系のメディアサーバ4は、SIP関連の情報全てを外部記憶装置6に保存し、基本的に現用系のメディアサーバは、自身のメモリ上に待機系のメディアサーバに引継ぐSIP関連の情報を記憶しない。よって、現用系のメディアサーバ4が故障した場合でも、待機系のメディアサーバ4は、メモリ上にSIP関連の情報を復旧させる必要はない。
【0036】
また、復旧のためのRTPの情報は、RTPセッションの開始時に外部記憶装置6に記憶する。そのため、現用系のメディアサーバ4が故障した場合、待機系のメディアサーバ4は外部記憶装置6に記憶されている情報を参照してRTPポートオープン等の状態復帰処理を行ってセッションを引継ぐが、一部の情報については保存時の値から現在の値を推定してRTPパケット送信を再度起動させる必要がある。
【0037】
IVR関連の情報は、更新があり次第、その内容を外部記憶装置6に保存していく。そのため、現用系のメディアサーバ4が故障した場合、待機系のメディアサーバ4は外部記憶装置6に記憶されている情報に基づいてIVRを再度起動する。よって、故障が発生した時点からIVR処理を再開することができる。
【0038】
このように、メモリ情報共有方式は、現用系のメディアサーバ4が持つメモリ情報を全て外部記憶装置6に保存しておき、故障時は待機系のメディアサーバ4が外部記憶装置6から情報を取得してメモリ情報を復旧させる方式である。本方式の場合、ブリッジ方式の転送実施時に故障が発生した場合でもセッションフェールオーバが可能となる。また、待機系に切り替わる時、メモリ上にSIP関連の情報を復旧させる必要がないため、短い停止時間で現用系から待機系に切り替わることができる。
【0039】
次に、各装置の構成について説明する。
エンドユーザが保有する電話端末1は、IP電話端末であり、メディアサーバ4との間でSIPにより呼を確立するとともに、RTPを用いてメディアセッションを確立して音声パケットを送受信する。
中継サーバ2は、アドレス解決などを行なって、SIP信号の中継を行なう。
【0040】
メディアサーバ4は、通信部40、監視部41及びメディア処理プログラム実行部42を備える。通信部40は、IPにより他の装置との間でパケット(データ)を送受信する。通信部40は、現用系から処理を引継ぐ場合、現用系のメディアサーバ4が使用していたIPアドレスを引継いで使用する。監視部41は、他のメディアサーバ4の故障を検出する。
【0041】
メディア処理プログラム実行部42は、呼処理部43、制御部44、主記憶部45、IVR処理部46、音声処理部47及び復旧処理部48を備える。主記憶部45は、メディア処理プログラム実行部42内の各部からアクセス可能であり、呼処理、音声処理、IVR処理に用いられる各種データを記憶する。制御部44は、外部記憶装置6に対して呼処理復旧情報、音声処理復旧情報、IVR処理情報の書込みや読み出しを行なう。呼処理部43は、SIP信号に基づく既存と同様の呼処理を行なうが、呼処理において用いられる各種情報のうち故障時の引継が必要な情報については制御部44を介して外部記憶装置6に書込みを行ない、適宜この外部記憶装置6内の情報を参照して呼処理を行なう。IVR処理部46は、IVRフローに従った音声データの出力を音声処理部47へ指示する。音声処理部47は、RTPによる音声データの送受信処理を行なう。
【0042】
以下、メディアサーバ4aが備えるメディアサーバ4の各部には符号にaを付加して記載し、メディアサーバ4bが備えるメディアサーバ4の各部には符号にbを付加して記載する。例えば、メディアサーバ4aの備える監視部41は監視部41a、メディアサーバ4bの備える監視部41は監視部41bと記載する。
【0043】
外部記憶装置6は記憶部60を備え、記憶部60内の電話番号設定記憶部61、IVRフロー記憶部62、呼処理復旧情報記憶部63、音声処理復旧情報記憶部64、IVR処理情報記憶部65に記憶されているデータの読書きを行なう。
発信制御装置7は、メディアサーバ4に対して呼の発信を指示する。
【0044】
次に、本実施形態による外部記憶装置6に記憶される各データについて説明する。
図2は、本実施形態による電話番号設定記憶部61に記憶される電話番号設定情報のデータ構成例を示す図である。電話番号設定情報は、電話番号、実行すべきIVRシナリオを特定するIVR ID、同時に接続可能な呼数を示す最大チャネル数、及び、現在接続されている呼数を示すアクティブチャネル数を対応づけたレコードからなる。電話番号は、電話端末1から発信し、メディアサーバ4へ着信したときの着信先電話番号、あるいは、発信制御装置7の指示を受けメディアサーバ4が発信し、電話端末1へ着信したときの発信元電話番号である。
【0045】
図3は、本実施形態によるIVRフロー記憶部62に記憶されるIVRフローデータのデータ構成例を示す図である。同図において、IVRフローデータは、IVR IDと、IVRフローシナリオの対応付を示す。IVRフローシナリオは、エンドユーザに対して実行するIVR処理の順番を記述したデータであり、メディアサーバ4のIVR処理部46は、このIVRフローシナリオに従って、送出する音声の再生や、受信した音声の認識等の処理を順番に実行する。受信する音声は、例えば、DTMF(Dual Tone Multi Frequency)やエンドユーザの発話などである。なお、DTMFとは、1〜9までの数字と*、#、A、B、C、Dの記号の16種類の符号を低群・高群の2つの音声周波数帯域の信号音で送信する方法であり、電話端末1にプッシュした番号をメディアサーバ4に伝えることができる。
【0046】
図4は、本実施形態による呼処理復旧情報記憶部63に記憶される呼処理復旧情報のデータ構成例を示す図である。呼処理復旧情報は、電話端末1及びメディアサーバ4の間でSIPのセッションを再確立するために必要な情報を保持し、toタグ、fromタグ、callid、メディアサーバのCSeq、電話端末のCSeq、発着信フラグ、サーバ側電話番号、端末側電話番号、各種ヘッダフィールドを対応付けたレコードからなる。各レコードは、通話単位、つまり、ダイアログ単位で生成される。SIPにおいて、ダイアログとは、電話をかけて通話が確立してから通話が終了するまでの間のことである。呼は、toタグ、fromタグ及びcallidの組み合わせによって示される呼特定情報により一意に特定することができる。
【0047】
toタグは、論理的なリクエストの送信先(IPアドレスとは異なる)が記載されているSIPのタグである。fromタグは、論理的な(IPアドレスとは異なる)リクエストの送信元が記載されているSIPのタグである。callidは、グローバルでユニークなランダムID(識別子)であり、RFC1750の方式で生成することが推奨されている。CSeqは、新規リクエスト毎にインクリメントされる番号である。発着信フラグは呼がメディアサーバ4からの発信か、電話端末1からの着信かを判別するためのフラグである。各種ヘッダフィールドは、送受信した各SIPメッセージのヘッダの情報の全部または一部の情報である。なお、toタグ、fromタグ、callid、CSeq、SIPメッセージのヘッダの詳細は、RFC3261に記述されている。サーバ側電話番号、端末側電話番号に代えて、メディアサーバ4のSIP URI(Universal Resource Identifier)、電話端末1のSIP URIを用いるようにしてもよい。
【0048】
図5は、本実施形態による音声処理復旧情報記憶部64に記憶される音声処理復旧情報のデータ構成例を示す図である。音声処理復旧情報は、電話端末1とメディアサーバ4の間のRTPによる音声通信の再確立に必要な情報を保持し、toタグ、fromタグ、callid、発着信開始時間、メディアサーバのRTPシーケンスナンバ、SSRC、RTPポート番号及びIPアドレス、電話端末のRTPポート番号及びIPアドレスを対応付けたレコードからなる。各レコードは、ダイアログ(通話)単位で生成される。
【0049】
SSRCは、RTPパケットに含まれるメディアストリームのソースIDであり、他のRTPと識別するために使用される。RTPシーケンスナンバは、RTPパケットの順序性を保障するための番号であり、RTPパケットを送信する度に1ずつ増やしていくが、ここでは、確立したRTPセッションにおいて、最初に送信したRTPパケットに使用したRTPシーケンスナンバを示す。
なお、SSRC、RTPシーケンスナンバの詳細は、RFC3350に記述されている。
【0050】
図6は、本実施形態によるIVR処理情報記憶部65に記憶されるIVR処理情報のデータ構成例を示す図である。IVR処理情報は、メディアサーバ4がエンドユーザに対して実行したコマンドの履歴ログを示し、toタグ、fromタグ、callid、コマンド実行履歴、エンドユーザ入力履歴1〜nを対応付けたレコードからなり、ダイアログ(通話)単位で生成される。
【0051】
コマンド実行履歴は、IVRフローシナリオにより規定される一連のIVR処理において、最後に指示したガイダンス送出や音声認識などのIVR処理を特定する。エンドユーザ入力履歴1〜nは、IVR処理において電話端末1から受信したエンドユーザによる入力内容を順に記述したデータであり、入力されたDTMFや、音声やDTMFにより特定される選択内容などを示す。
【0052】
次に、本実施形態によるIVRシステムの動作について説明する。
IVRシステムの稼動前に、電話番号設定情報が電話番号設定記憶部61に、IVRフローデータがIVRフロー記憶部62に記憶されているものとする。ただし、電話番号設定情報のアクティブチャネル数の初期値は「0」とする。
【0053】
図7は、本実施形態による電話端末1から現用系のメディアサーバ4への着信時のシーケンス例を示す図である。なお、以下、SIPのX信号が設定されたIPパケットをXパケットと記載する。例えば、INVITE信号が設定されたIPパケットをINVITEパケットとする。
【0054】
まず、電話端末1は、中継サーバ2に対してINVITEパケットを送信する(ステップS105)。INVITEパケットには、電話端末1が使用するRTPポート番号及びIPアドレスが設定されている。中継サーバ2は、INVITEパケットのToフィールドに設定されている電話番号を着信先のIPアドレスに変換し、メディアサーバ4aへ送信する(ステップS110)。メディアサーバ4aは、着信を許可すると判断した場合、100Tringメッセージを中継サーバ2に返送し(ステップS115)、続いて、180Ringingを中継サーバ2に送信する(ステップS120)。中継サーバ2は、180Ringingを電話端末1に中継し(ステップS125)、電話端末1は、リングバックトーンをエンドユーザに聞かせる。
【0055】
続いて、メディアサーバ4aの呼処理部43aは、200OKを中継サーバ2に送信する(ステップS130)。200OKには、メディアサーバ4aが使用するRTPポート番号及びIPアドレスが設定されている。中継サーバ2は、200OKを電話端末1に中継する(ステップS135)。電話端末1は、メディアサーバ4aに対してACKを送信する(ステップS140)。ACKの送信に伴い、電話端末1とメディアサーバ4aの音声処理部47a間でRTPのセッションが確立され、通話中状態に遷移すると、メディアサーバ4aの音声処理部47aは、IVRの音声をRTPパケットにより電話端末1へ送信し、電話端末1はエンドユーザの発話やDTMFをRTPパケットによりメディアサーバ4aへ送信する(ステップS145)。
【0056】
通話中状態が長く継続する場合、定期的にメディアサーバ4aの呼処理部43aまたは電話端末1からre−INVITEパケットまたはUPDATEパケットが送信され(ステップS150)、この受信した電話端末1またはメディアサーバ4aの呼処理部43aは、応答を返送し、セッションの継続を確認する。
【0057】
エンドユーザが呼の切断操作を行なった場合、電話端末1はメディアサーバ4aへBYEパケットを送信し(ステップS155)、メディアサーバ4aの呼処理部43aは、200OKを返送する(ステップS160)。なお、メディアサーバ4aが呼の切断を行なう場合、メディアサーバ4aの呼処理部43aは、電話端末1へBYEパケットを送信し、電話端末1は、200OKを返送する。
【0058】
メディアサーバ4からの発信の場合、メディアサーバ4が図7に示すシーケンス中の電話端末1と同様の動作を行い、電話端末1が図7に示すメディアサーバ4と同様の動作を行なう。
【0059】
図8は、本実施形態によるIVRシステムにおける故障発生時のシーケンスを示す図である。
例えば、図7のステップS105〜S140に示す電話端末1からの発信の手順や、メディアサーバ4からの発信の手順により、電話端末1とメディアサーバ4aの間でSIPセッションが確立されると(ステップS205)、メディアサーバ4aは外部記憶装置6の呼処理復旧情報記憶部63に呼処理復旧情報を書き込む(ステップS210)。メディアサーバ4aは、IVRの処理を起動し(ステップS215)、電話端末1との間でRTPセッションを確立すると(ステップS220)、外部記憶装置6の音声処理復旧情報記憶部64に音声処理復旧情報を書き込む(ステップS225)。
【0060】
メディアサーバ4aは、音声再生などのIVR処理を実行し(ステップS230)、外部記憶装置6のIVR処理情報記憶部65にIVR処理情報を書き込む。また、IVR処理中に呼の継続確認のためのSIPパケットの送受信があった場合、メディアサーバ4aは、外部記憶装置6の呼処理復旧情報記憶部63に記憶されている呼処理復旧情報の読み込みや更新を行なう(ステップS235)。つまり、メディアサーバ4aは、IVR処理が進むたびにIVR処理情報を更新し、電話端末1からSIPパケットを受信する度に呼処理復旧情報を読込んで新規SIPパケットかを確認し、既存の呼の場合には呼処理復旧情報を更新する。
【0061】
IVR処理実行中にメディアサーバ4aが故障した場合、メディアサーバ4bはこれを検知し(ステップS240)、外部記憶装置6のIVR処理情報記憶部65からIVR処理情報を読み出すと(ステップS245)、IVRシナリオの途中からIVR処理を起動する(ステップS250)。さらに、メディアサーバ4bは、外部記憶装置6の音声処理復旧情報記憶部64から音声処理復旧情報を読み出し(ステップS255)、音声処理復旧情報により示されるRTPポートを開き受信状態にすると同時に電話端末1に対してRTPパケットの送信を再開してRTPセッションを復旧し(ステップS260)、電話端末1とのRTPセッションを再確立する(ステップS265)。メディアサーバ4bは、電話端末1からSIPパケットを受信した場合(ステップS270)、外部記憶装置6の呼処理復旧情報記憶部63から呼処理復旧情報を読み出し、受信したSIPパケットがセッション確立済みのパケットかを確認する(ステップS275)。
【0062】
次に、メディアサーバ4における処理フローについて説明する。
図9は、本実施形態による監視フローを示す図である。
同図において、メディアサーバ4の監視部41は、所定の時間間隔により、他のメディアサーバ4の生死の監視を起動する(ステップS305)。つまり、メディアサーバ4aの監視部41aは、メディアサーバ4bの生死の監視処理を起動し、メディアサーバ4bの監視部41bは、メディアサーバ4aの生死の監視処理を起動する。
【0063】
監視が起動されると、メディアサーバ4の監視部41は、他のメディアサーバ4の監視部41との間で生死の監視のための情報を交換する(ステップS310)。メディアサーバ4aの監視部41aは、メディアサーバ4bの監視部41bに対して監視メッセージを送信し、監視メッセージを受信したメディアサーバ4bの監視部41bは、メディアサーバ4bのハードウェアの動作やメディア処理プログラム実行部42bの処理が正常である場合、正常を通知する監視応答メッセージを返送する。同様に、メディアサーバ4bの監視部41bは、メディアサーバ4aの監視部41aに対して監視メッセージを送信し、監視メッセージを受信したメディアサーバ4aの監視部41aは、メディアサーバ4aのハードウェアの動作やメディア処理プログラム実行部42aの処理が正常である場合、正常を通知する監視応答メッセージを返送する。
【0064】
現用系、待機系のメディアサーバ4とも正常である場合、つまり、メディアサーバ4a、4bが、ステップS310において自身が送信した監視メッセージに対応して正常を通知する監視応答メッセージを受信した場合(ステップS315:故障検知なし)、現用系、待機系のメディアサーバ4a、4bともそのまま処理を継続する(ステップS320)。
【0065】
待機系のメディアサーバ4bの故障発生が検出された場合、例えば、メディアサーバ4aの監視部41aが、メディアサーバ4bへ監視メッセージを送信してから所定時間以内に監視応答メッセージを受信しなかった、あるいは、メディアサーバ4bから故障を示す監視応答メッセージを受信した場合(ステップS315:待機系の故障検知)、現用系のメディアサーバ4aは、そのまま処理を継続する(ステップS325)。LANによりメディアサーバ4と接続され、IVRシステム全体の動作を管理する運用サーバ(図示せず)は、管理者宛のメール等を送信し、故障を通知する。
【0066】
現用系のメディアサーバ4aの故障発生が検出された場合、例えば、メディアサーバ4bの監視部41bが、メディアサーバ4aへ監視メッセージを送信してから所定時間以内に監視応答メッセージを受信しなかった、あるいは、メディアサーバ4aから故障を示す監視応答メッセージを受信したりした場合(ステップS315:現用系の故障検知)、待機系のメディアサーバ4bの監視部41bは、通信部40bに現用系のメディアサーバ4aのIPアドレスを引継ぐよう指示するとともに、メディア処理プログラム実行部42bに後述する故障時フローの実行を指示する(ステップS330)。
【0067】
図10及び図11は、本実施形態による現用系のメディアサーバ4における着信時の処理フローを示す図である。
図10において、メディアサーバ4aの呼処理部43aは、図7のステップS105〜S110に示すように、電話端末1から送信され、中継サーバ2により中継されたINVITEパケットを受信する(ステップS405)。
【0068】
メディアサーバ4aの呼処理部43aは、INVITEパケットのToフィールドから着信先の電話番号を取得して主記憶部45aに書き込む(ステップS410)。呼処理部43aから指示を受けた制御部44aは、外部記憶装置6に取得した電話番号を通知し、最大チャネル数及びアクティブチャネル数の読み出しを指示する。制御部44aは、外部記憶装置6が電話番号設定記憶部61内の電話番号設定情報から電話番号に対応して読み出した最大チャネル数及びアクティブチャネル数を受信し、呼処理部43aに出力する。呼処理部43aは、アクティブチャネル数が最大チャネル数より小さい場合に、着信を許可する(ステップS415)。
なお、電話番号に対応したアクティブチャネル数や最大チャネル数が電話番号設定情報から読み出せなかった場合、あるいは、アクティブチャネル数が最大チャネル数以上であった場合、呼処理部43aはダイアログを確立せず、呼を終了させる。
【0069】
呼処理部43aは、着信を許可する場合、SIPの仕様に従ってダイアログを確立するとともに、呼の再開に必要なSIPの情報を主記憶部45aに書き込む(ステップS420)。具体的には、以下のように動作する。
【0070】
呼処理部43aは、受信したINVITEパケットを主記憶部45aに書き込むとともに、INVITEパケットに設定されているfromタグ、callid、各種ヘッダフィールド、電話端末1が用いるRTPポート番号及びIPアドレス、電話端末のCSeqを読み出して主記憶部45aに書き込む。なお、RTPポート番号及びIPアドレスは、ACKパケットから取得する場合もある。
【0071】
呼処理部43aは、例えば、図7のステップS115〜S140の処理に示すように、SIPの仕様に従って180Tring、Ringing、200OKの送信、ACKの受信を行なう。呼処理部43aは、送受信したこれらの各SIPパケットを主記憶部45aに書き込むとともに、これらのSIPパケットに設定されている電話端末のCSeqやメディアサーバのCSeqメディアサーバのCSeq、各種ヘッダフィールドを主記憶部45aに書き込む。
【0072】
なお、呼処理部43aは、200OKを送信する際には、200OKに設定したtoタグと、メディアサーバ4aが用いるRTPポート番号及びIPアドレスとを主記憶部45aに書き込む。
また、各種ヘッダフィールドには、To、From、Record−Route、Viaヘッダフィールドがあるが、Record−Route、Viaヘッダフィールドは取得できない場合もある。
【0073】
電話端末1とのダイアログ確立後、制御部44aは、外部記憶装置6にステップS410において取得した電話番号を通知し、アクティブチャネル数の加算を指示する。外部記憶装置6は、電話番号により電話番号設定記憶部61内の電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数に1を加算する(ステップS425)。
【0074】
次に、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバのCSeq、電話端末のCSeq、INVITEパケットのToフィールドから取得した着信側の電話番号であるサーバ側電話番号、INVITEパケットのFromフィールドから取得した発信側の電話番号である端末側電話番号、各種ヘッダフィールドと、着信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置6に出力し、呼処理復旧情報への登録を指示する(ステップS430)。外部記憶装置6は、呼処理復旧情報記憶部63内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録呼処理復旧情報を設定する。
【0075】
さらに、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバ4aが用いるRTPポート番号及びIPアドレス、電話端末1が用いるRTPポート番号及びIPアドレスを登録音声処理復旧情報として外部記憶装置6に出力し、音声処理復旧情報への登録を指示する(ステップS435)。外部記憶装置6は、音声処理復旧情報記憶部64内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録音声処理復旧情報を設定する。
メディアサーバ4aの呼処理部43aは、制御部44aにダイアログの確立を通知する。
【0076】
ダイアログの確立の通知を受信した制御部44aは、主記憶部45aから着信先の電話番号を読み出すと、外部記憶装置6に読み出した電話番号を通知してIVR ID及び最大チャネル数の読み出しを指示する。メディアサーバ4aの制御部44aは、外部記憶装置6が電話番号に対応して電話番号設定記憶部61内の電話番号設定情報から読み出したIVR ID及び最大チャネル数を受信し、主記憶部45aに書き込む(ステップS440)。
【0077】
続いて、制御部44aは、外部記憶装置6に受信したIVR IDを通知してIVRフローシナリオの読み出しを指示する。制御部44aは、外部記憶装置6がIVR IDに対応してIVRフロー記憶部62内のIVRフローデータから読み出したIVRフローシナリオを受信し、主記憶部45aに書き込む(ステップS445)。
【0078】
次に、制御部44aは、外部記憶装置6に主記憶部45aから取得したtoタグ、fromタグ、及び、callidを通知してコマンド実行履歴の読み出しを指示する。制御部44aは、外部記憶装置6がtoタグ、fromタグ、及び、callidに対応してIVR処理情報記憶部65内のIVR処理情報から読み出したコマンド実行履歴を受信し、主記憶部45aに書き込む(ステップS450)。なお、コマンド実行履歴が読み出せなかった場合は、初期状態であると判断する。
【0079】
図11において、制御部44aは、IVR処理部46aに主記憶部45aに書き込んだIVRシナリオとコマンド実行履歴を出力し、IVRフローの実行を指示する。IVR処理部46aは、コマンド実行履歴がなく、初期状態であると判断した場合、IVRシナリオを最初から実行する。コマンド実行履歴に実行したコマンドが設定されている場合、そのコマンドにより示される途中のIVR処理からIVRシナリオを実行する(ステップS505)。
【0080】
音声処理部47aは、制御部44aの指示を受け、自メディアサーバ4aが使用するSSRC及びRTPシーケンスナンバを生成すると、主記憶部45aから自メディアサーバ4aが用いるRTPポート番号及びIPアドレスと、電話端末1が用いるRTPポート番号及びIPアドレスを読み出し、これらの情報を用いて電話端末1との間のRTPセッションを確立し、RTPパケットの送受信を開始する(ステップS510)。制御部44aは、メディアサーバのSSRC、最初に送信したRTPパケットに設定したRTPシーケンスナンバ、RTPセッションを開始した時間を示す発着信開始時間を主記憶部45aに書き込む。
【0081】
制御部44aは、RTPセッションが確立され、RTPパケットの送受信が行なわれると、主記憶部45aからtoタグ、fromタグ、callid、メディアサーバのSSRC、メディアサーバ4aが電話端末1とのRTPセッションにおいて最初に使用したRTPシーケンスナンバ、当該RTPセッションにおいて最初にRTPパケットを送信した時刻である発着開始時間を外部記憶装置6に通知し、音声処理復旧情報の更新を指示する(ステップS515)。外部記憶装置6は、toタグ、fromタグ及びcallidにより音声処理復旧情報記憶部64内の音声処理復旧情報のレコードを特定し、特定したレコードにメディアサーバ4のSSRC及びRTPシーケンスナンバと、発着開始時間とを書き込む。なお、toタグ、fromタグ及びcallidに対応したレコードが音声処理復旧情報に登録されていない場合、新たなレコードを追加し、追加したレコードにメディアサーバ4のSSRC及びRTPシーケンスナンバと、発着開始時間とを書き込む。
【0082】
メディアサーバ4aは、IVRシナリオを実行していく。具体的には、音声処理部47aは、IVR処理部46aからの指示により、電話端末1に対して再生音声のRTPパケットを送信し、エンドユーザにガイダンスを聞かせたり、電話端末1から受信したRTPパケットにより示されるDTMFや発話内容などをIVR処理部46aが認識したりする。IVR処理部46aは、DTMFやエンドユーザの発話などの音声を認識する度にその認識結果をIVR処理情報に追加するよう制御部44aに指示する。また、IVR処理部46aは、音声認識や音声再生などコマンドをひとつ実行する度に、現在実行しているIVRフローの位置を特定する情報をコマンド実行履歴としてIVR処理情報記憶部65に書き込むよう制御部44aに指示する。具体的には、制御部44aは、現在処理中の呼のtoタグ、fromタグ、callidと、認識結果あるいはコマンド実行履歴を通知して、IVR処理情報の更新を外部記憶装置6に指示する(ステップS520)。外部記憶装置6は、toタグ、fromタグ、callidによりIVR処理情報記憶部65内のIVR処理情報のレコードを特定し、特定したレコードに認識結果あるいはコマンド履歴を書き込む。
【0083】
メディアサーバ4aは、150秒以上など所定の時間以上通話が継続する場合(ステップS525:YES)、IVRフローを実行の合間に、セッションの継続確認処理を行なう。つまり、メディアサーバ4aの呼処理部43aは、所定の時間以上通話が継続していることを検出した場合、定期的にre−INVITEパケットあるいはUPDATEパケットを電話端末1に送信する(ステップS530)。
制御部44aは、呼処理部43aがre−INVITEパケットあるいはUPDATEパケットを送信することにより更新されたメディアサーバのCSeqにより呼処理復旧情報を更新する。つまり、制御部44aは、現在処理中の呼のtoタグ、fromタグ、callidと、更新されたメディアサーバのCSeqを外部記憶装置6に通知して、呼処理復旧情報の更新を指示する。外部記憶装置6は、toタグ、fromタグ、callidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードに記述されているメディアサーバのCSeqを、受信したCSeqにより更新する。
【0084】
また、メディアサーバ4aの呼処理部43aが、電話端末1からre−INVITEパケットあるいはUPDATEパケットを受信する場合もある。この場合、呼処理部43aは、受信したre−INVITEパケットあるいはUPDATEパケットのパケットからtoタグ、fromタグ、callid、及び、電話端末のCSeqを読み出して、制御部44aに出力する。制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callid及び電話端末のCSeqを外部記憶装置6に通知して、呼処理復旧情報の更新を指示する。外部記憶装置6は、toタグ、fromタグ、callidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードに記述されている電話端末のCSeqを、受信した電話端末のCSeqにより更新する。
【0085】
電話端末1からの通信断により通話が終了する場合、電話端末1からBYEパケットがメディアサーバ4aに送信される(ステップS525:NO、ステップS530:エンドユーザからの通信断)。メディアサーバ4aの呼処理部43aは、電話端末1から送信されたBYEパケットを受信すると、このパケットからtoタグ、fromタグ、callidを取得して制御部44aに出力する。
制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callidをIVR処理部46aに出力し、IVR処理の終了を指示する。制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callidにより特定される呼に対して実行していたIVRフローシナリオの実行を終了する(ステップS540)。
さらに、制御部44aは、呼処理部43aから受信したtoタグ、fromタグ、callidを音声処理部47aに出力し、RTPセッションの終了を指示する。音声処理部47aは、呼処理部43aから受信したtoタグ、fromタグ、callidにより特定される呼について確立していたセッションを終了する(ステップS545)。
呼処理部43aは、BYEパケットの応答として電話端末1に200OKを返送する(ステップS550)。
【0086】
あるいは、IVRフローが最後まで実行された場合、メディアサーバ4aからの通信断により通話が終了する(ステップS525:NO、ステップS530:メディアサーバからの通信断)。IVR処理部46aは、制御部44aに対してIVRフロー実行終了を通知する。
制御部44aが呼処理部43aにIVRフロー実行終了を通知すると、呼処理部43aは、電話端末1にBYEパケットを送信し(ステップS555)、電話端末1に通話終了を指示する。さらに、制御部44aは、音声処理部47aに停止命令を出力し、RTPセッションの終了を指示する。音声処理部47aは、電話端末1との間で確立していたセッションを終了する(ステップS560)。最後に、呼処理部43aは、電話端末1からBYEパケットの応答として200OKを受信する(ステップS565)。
【0087】
上記のいずれかにより通話が終了したことを認識したメディアサーバ4aの制御部44aは、ステップS550またはS565の後、主記憶部45aから終了した呼のtoタグ、fromタグ、callidを読み出して外部記憶装置6へ送信し、呼処理復旧情報、音声処理復旧情報、及び、IVR処理情報の削除を指示する。外部記憶装置6は、toタグ、fromタグ、callidにより特定される呼処理復旧情報のレコード、音声処理復旧情報のレコード、及び、IVR処理情報のレコードを削除する(ステップS570)。
【0088】
さらに、メディアサーバ4aの制御部44aは、終了した呼に対して実行していたIVRフローシナリオのIVR IDを外部記憶装置6へ送信し、アクティブチャネル数の減算を指示する(ステップS575)。外部記憶装置6は、IVR IDにより電話番号設定記憶部61が記憶している電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数を、1を減算した数に更新する。
【0089】
図12は、本実施形態による現用系のメディアサーバ4における発信時の処理フローを示す図である。
メディアサーバ4aの制御部44aは、発信制御装置7から発信指示を受信する(ステップS605)。発信指示には、サーバ側電話番号及び端末側電話番号が設定される。
【0090】
メディアサーバ4aの呼処理部43aは、発信指示から取得したサーバ側電話番号を外部記憶装置6に通知し、最大チャネル数及びアクティブチャネル数の読み出しを指示する(ステップS610)。制御部44aは、外部記憶装置6が電話番号に対応して電話番号設定記憶部61内の電話番号設定情報から読み出した最大チャネル数及びアクティブチャネル数を受信すると、これらを比較する。制御部44aは、アクティブチャネル数が最大チャネル数より小さい場合に着信を許可し、呼処理部43aに発信を指示する。
なお、サーバ側電話番号が電話番号設定情報に設定されていない場合、あるいは、アクティブチャネル数が最大チャネル数以上であった場合、制御部44aは発信を指示せず、処理を終了する。
【0091】
制御部44aから発信指示を受けた呼処理部43aは、SIPの仕様に従って電話端末1とのダイアログを確立するとともに、呼の再開に必要なSIPの情報を主記憶部45aに書き込む(ステップS615)。具体的には、以下のように動作する。
【0092】
呼処理部43aは、INVITEパケットを生成し、電話端末1に送信する。INVITEパケットのToフィールドには発信制御装置7から受信した端末側電話番号が、Fromフィールドには発信制御装置7から受信したサーバ側電話番号と、生成したfromタグが設定される。
制御部44aは、INVITEパケットを主記憶部45aに書き込むとともに、INVITEパケットに設定したfromタグ、callid、各種ヘッダフィールド、メディアサーバ4のRTPポート番号及びIPアドレス、メディアサーバのCSeqを読み出して主記憶部45aに書き込む。なお、RTPポート番号及びIPアドレスは、ACKパケットに設定される場合もある。
【0093】
呼処理部43aは、一般的なSIPの仕様に従って、180Tring、Ringing、200OKの受信、ACKの送信を行ない、電話端末1とのダイアログを確立する。呼処理部43aは、送受信したこれらの各SIPパケットを主記憶部45aに書き込むとともに、これらのSIPパケットに設定されている電話端末のCSeqやメディアサーバのCSeq、各種ヘッダフィールドを主記憶部45aに書き込む。
なお、呼処理部43aは、電話端末1から受信した200OKから、toタグと、電話端末1が用いるRTPポート番号及びIPアドレスを取得して主記憶部45aに書き込む。
また、各種ヘッダフィールドには、To、From、Record−Route、Viaヘッダフィールドがあるが、Record−Route、Viaヘッダフィールドは取得できない場合もある。
【0094】
電話端末1とのダイアログ確立後、制御部44aは、ステップS610において受信した発信指示から取得した電話番号を外部記憶装置6に通知し、アクティブチャネル数の加算を指示する。外部記憶装置6は、電話番号により電話番号設定記憶部61内の電話番号設定情報のレコードを特定し、特定したレコードに設定されているアクティブチャネル数に1を加算する(ステップS620)。
【0095】
以降、メディアサーバ4aは、図10のステップS430以降と同様の処理を行なう。ただし、ステップS430において、登録呼処理復旧情報には、発信を示す発着信フラグ、INVITEのFromフィールドから取得した発信側の電話番号であるサーバ側電話番号、INVITEパケットのToフィールドから取得した着信側の電話番号である端末側電話番号が設定される。
【0096】
図13は、本実施形態による現用系のメディアサーバ4の故障が検出されたときに待機系のメディアサーバ4が実行する復旧処理フローを示す図である。
IVR処理中にメディアサーバ4aの故障が発生した場合、図9に示すように待機系のメディアサーバ4bの監視部41bが現用系の故障を検出する。メディアサーバ4bの監視部41bは、復旧処理部48を起動する(ステップS705)。復旧処理部48bは、通信部40bにメディアサーバ4aの通信部40aが使用していたIPアドレスを引継がせ、メディアサーバ4bは現用系として起動する。
【0097】
メディアサーバ4bの復旧処理部48bは、外部記憶装置6の呼処理復旧情報記憶部63に記憶されている呼処理復旧情報を1レコードずつ特定し、特定したレコードを読み出して主記憶部45bに書き込むとともに、当該レコードからtoタグ、fromタグ及びcallidを読み出して(ステップS710)、以下の処理を行なう。なお、外部記憶装置6からtoタグ、fromタグ及びcallidのみを読み出すことでもよい。
【0098】
制御部44bは、ステップS710において取得したtoタグ、fromタグ及びcallidの組を外部記憶装置6に通知し、音声処理復旧情報、及び、IVR処理情報の読み出しを指示する(ステップS715)。制御部44bは、外部記憶装置6が各toタグ、fromタグ及びcallidの組に対応して読み出した音声処理復旧情報記憶部64内の音声処理復旧情報のレコード、及び、IVR処理情報記憶部65内のIVR処理情報内のレコードを受信し、主記憶部45bに書き込む。
【0099】
さらに、制御部44bは、ステップS710において主記憶部45bに保存した呼処理復旧情報記のレコードからサーバ側電話番号を取得すると、外部記憶装置6に取得したサーバ側電話番号を通知してIVR IDの読み出しを指示する。制御部44bは、外部記憶装置6がサーバ側電話番号に対応して電話番号設定記憶部61内の電話番号設定情報から読み出したIVR IDを受信する。まだこのIVR IDに対応したIVRフローを読み出していない場合、制御部44bは、外部記憶装置6に受信したIVR IDを通知してIVRフローシナリオの読み出しを指示する。制御部44bは、外部記憶装置6がIVR IDに対応してIVRフロー記憶部62内のIVRフローデータから読み出したIVRフローシナリオを受信し、主記憶部45bに書き込む。
【0100】
なお、コマンドの番号によりIVRフローシナリオが特定可能な場合、メディアサーバ4bの制御部44bは、ステップS715において主記憶部45bに保存したIVR処理情報のレコード内のコマンド実行履歴からコマンドを読み出して外部記憶装置6に通知し、IVRフローシナリオの読み出しを指示する。外部記憶装置6は、IVRフロー記憶部62内のIVRフローデータから、コマンドに対応したIVR処理が含まれているIVRフローを読み出してメディアサーバ4bへ出力する。
【0101】
メディアサーバ4bの音声処理部47bは、ステップS715において主記憶部45bに保存したIVR処理情報のレコード内のコマンド実行履歴からコマンドを読み出す。IVR処理部47bは、主記憶部45bに記憶されているIVRシナリオを、読み出したコマンドにより特定されるIVR処理から実行することによって、IVR処理を途中から再開する(ステップS720)。
【0102】
音声処理部47bは、ステップS715において制御部44bが特定したIVR処理情報のレコードに設定されている値を用いて、電話端末1との間のRTPセッションを再開する(ステップS725)。
具体的には、制御部44bが、ステップS715において読み出した音声処理復旧情報のレコードから発着信開始時間とメディアサーバ4のRTPシーケンスナンバを読み出す。制御部44bは、発着信開始時間から現在の時間までの経過時間を算出すると、この経過時間をRTPパケットの送出間隔で除算することにより、RTPシーケンスナンバの増加分を算出する。RTPの受信側では、RTPシーケンスナンバが1ずつ増加しているかの検証を行なっているため、算出した増加分に所定の定数を加算するなどし、エラーとならない範囲の値としてもよい。制御部44bは、音声処理復旧情報のレコードから読み出したRTPシーケンスナンバに、算出した増加分を加算して、音声処理部47bから送信する最初のRTPパケットに設定すべきRTPシーケンスナンバを算出すると、音声処理部47bへ通知する。また、制御部44bは、通信部40bに指示し、読み出した音声処理復旧情報のレコードで示されるメディアサーバのRTPポートとIPアドレスをオープンする。
【0103】
音声処理部47bは、IVR処理による音声をRTPパケットにより電話端末1へ送信するとともに、電話端末1から送信されたRTPパケットを受信する。電話端末1に送信されるRTPパケットには、ステップS715において読み出したIVR処理情報のレコードに設定されているメディアサーバ4のSSRCと、電話端末1のRTPポート番号及びIPアドレスが用いられる。最初にメディアサーバ4bから送信するRTPパケットには、制御部44bから通知されたRTPシーケンスナンバを用いる。また、音声処理部47bは、ステップS715において読み出したIVR処理情報のレコードに設定されているメディアサーバ4のRTPポート番号及びIPアドレスを用いたRTPパケットを電話端末1から受信する。
【0104】
続いて復旧処理部48bは、外部記憶装置6の呼処理復旧情報記憶部63に記憶されている呼処理復旧情報の中で、まだ読み出していないレコードがあるかを判断し(ステップS730)、まだ読み出していないレコードがあれば(ステップS730:YES)、ステップS710からの処理を行う。一方、全てのレコードについて読み出しを行なったならば(ステップS730:NO)、メディアサーバ4bにおいて、以降、メディアサーバ4aが行なっていたステップS520からの処理を行なう。つまり、各部の符号の最後記載されている「a」を「b」に置き換えればよい。
【0105】
なお、本実施形態のメモリ情報共有方式は、基本的には全てのデータを外部記憶装置6に保持する。そのため、電話端末1からSIP信号を受信すると、メディアサーバ4の呼処理部43は、受信したSIP信号から取得したtoタグ、fromタグ、及び、callidタグにより特定される外部記憶装置6内の呼処理復旧情報、音声処理復旧情報のレコードに対して情報の参照や書込みを行い、呼処理を実行する。ただし、処理の高速化のために外部記憶装置6と同様の情報をメディアサーバ4の主記憶部45上に保持し、データを読むだけの場合は主記憶部45から情報を取得し、データに更新があった場合のみ外部記憶装置6にアクセスして情報を更新するようにしてもよい。
【0106】
[第2の実施形態:メモリ情報再構築方式]
次に、本発明の第2の実施形態によるIVRシステムについて説明する。
本実施形態では、メモリ情報再構築方式によるフェールオーバを実現する。メモリ情報再構築方式では、メディアサーバ4は、SIPの処理を実行するための情報を自サーバ内のメモリに保持しており、受信したINVITEパケットや200OKパケット等のパケット自体を外部記憶装置6に記憶しておく。そして、現用系のメディアサーバ4が故障時した時には、待機系のメディアサーバ4が外部記憶装置6からINVITEパケットやACKパケットを読み込み、自らに当該パケットを送信して現用系が故障前に保持していたメモリの内容を待機系のメモリに再構築して状態復帰処理を行う。なお、待機系のメディアサーバ4は、自身が送信した状態復帰用のパケットに暫定応答を返さない等の特別なロジックを実装する必要がある。なお、RTP関連の情報及びIVR関連の情報の保存や復旧については、メモリ情報共有方式と同様である。
【0107】
上記のように、メモリ情報再構築方式は、現用系のメディアサーバ4の故障時は現用系が受信したパケットを待機系のメディアサーバ4に送信することで、待機系のメディアサーバ4が保持するメモリ情報を、現用系のメディアサーバ4と同じように復旧させる方式であり、メモリ情報共有方式に比べて改修範囲が少ないため、実装が比較的容易である。
以下では、第1の実施形態との差分について説明する。
【0108】
本実施形態によるIVRシステムの構成は、図1に示す第1の実施形態によるIVRシステムの構成と同様である。
また、本実施形態による外部記憶装置6に記憶されるIVRフローデータ、電話番号設定情報、及び、IVR処理情報は、第1の実施形態と同様である。
【0109】
図14は、本実施形態による呼処理復旧情報記憶部63に記憶される呼処理復旧情報のデータ構成例を示す図である。同図に示すように、呼処理復旧情報は、toタグ、fromタグ、callid、INVITEパケット、ACKパケット、200OKパケット、メディアサーバのCSeq、電話端末のCSeq、発着信フラグ、サーバ側電話番号、端末側電話番号を対応付けたレコードからなり、各レコードは通話単位で生成される。メディアサーバ4への着信時にINVITEパケット、ACKパケットが保存され、メディアサーバ4からの発信時に200OKパケットが保存される。
【0110】
図15は、本実施形態による音声処理復旧情報記憶部64に記憶される音声処理復旧情報のデータ構成例を示す図である。同図に示すように、音声処理復旧情報は、toタグ、fromタグ、callid、発着信開始時間、メディアサーバ4のRTPシーケンスナンバ、SSRC、RTPポート番号及びIPアドレスを対応付けたレコードからなり、各レコードは通話単位で生成される。なお、電話端末のRTPポート番号及びIPアドレスは呼処理復旧情報に記録されているSIPメッセージ中に記述される。
【0111】
図16は、本実施形態によるIVRシステムにおける故障発生時のシーケンスを示す図である。
同図において、ステップS805〜S840までの処理は、図8のステップS205〜S240の処理と同様である。
メディアサーバ4bはメディアサーバ4aの故障を検知すると、外部記憶装置6から呼処理復旧情報を読み出す(ステップS845)。メディアサーバ4bは、読込んだ呼処理復旧情報を用い、電話端末1から受信したものと同じSIPパケットを内部的に自メディアサーバ4b宛に送信する。ただし、この内部的に受信したSIPパケットに対する応答は電話端末1へは送信しない。これにより、メディアサーバ4bは、SIP処理に必要な情報を構築して主記憶部45bに記憶する(ステップS850)。
以降、ステップS855〜S880までの処理は、図8のステップS245〜S270の処理と同様である。
ステップS885において、電話端末1からSIPパケットを受信すると、メディアサーバ4bは、ステップS850において構築し、内部に記憶している情報を参照して、すでに確立済みのセッションのSIPパケットかを確認する(ステップS885)。
【0112】
次に、本実施形態によるメディアサーバ4における処理フローについて説明する。本実施形態による監視フローは、図12に示す第1の実施形態と同様である。
【0113】
図17は、本実施形態による電話端末1から現用系のメディアサーバ4への着信時のシーケンス例を示す図である。
同図において、ステップS905〜S925までの処理は、図10に示すS405〜S425までの処理と同様である。
ステップS930において、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、INVITEパケット、ACKパケット、メディアサーバのCSeq、電話端末のCSeqと、着信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置6に出力し、呼処理復旧情報への登録を指示する(ステップS930)。外部記憶装置6は、呼処理復旧情報記憶部63内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録呼処理復旧情報を設定する。
【0114】
さらに、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバ4aが用いるRTPポート番号及びIPアドレスを登録音声処理復旧情報として外部記憶装置6に出力し、音声処理復旧情報への登録を指示する(ステップS935)。外部記憶装置6は、音声処理復旧情報記憶部64内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録音声処理復旧情報を設定する。
メディアサーバ4aの呼処理部43aは、制御部44aにダイアログの確立を通知する。以降は、図10のステップS440からの処理を行う。
【0115】
図18は、本実施形態による現用系のメディアサーバ4における発信時の処理フローを示す図である。
同図において、ステップS1005〜S1020までの処理は、図9に示すS605〜S620までの処理と同様である。
ステップS1025において、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、200OKパケット、メディアサーバのCSeq、電話端末のCSeq、サーバ側電話番号、端末側電話番号と、発信を示す発着信フラグとを登録呼処理復旧情報として外部記憶装置6に出力し、呼処理復旧情報への登録を指示する(ステップS1025)。外部記憶装置6は、呼処理復旧情報記憶部63内の呼処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録呼処理復旧情報を設定する。
【0116】
さらに、メディアサーバ4aの呼処理部43aから指示を受けた制御部44aは、主記憶部45aに記憶されているtoタグ、fromタグ、callid、メディアサーバ4aが用いるRTPポート番号及びIPアドレスを登録音声処理復旧情報として外部記憶装置6に出力し、音声処理復旧情報への登録を指示する(ステップS1030)。外部記憶装置6は、音声処理復旧情報記憶部64内の音声処理復旧情報にレコードを追加し、追加したレコードにメディアサーバ4aから受信した登録音声処理復旧情報を設定する。
メディアサーバ4aの呼処理部43aは、制御部44aにダイアログの確立を通知する。以降は、図10のステップS440からの処理を行う。
【0117】
図19は、本実施形態による現用系のメディアサーバ4の故障が検出されたときに待機系のメディアサーバ4が実行する復旧処理フローを示す図である。
IVR処理中にメディアサーバ4aの故障が発生した場合のステップS1105〜S1115におけるメディアサーバ4bの処理は、図13のステップS705〜S715までの処理と同じである。ただし、ステップS1110において、復旧処理部48bは、特定した外部記憶装置6から、呼処理復旧情報のレコードから読み出したtoタグ、fromタグ及びcallidと、発着信フラグとを受信する。
【0118】
ステップS1110において読み出した発着信フラグが着信を示している場合(ステップS1120:着信)、復旧処理部48bからの指示を受けた制御部44bは、ステップS1110において読み出したtoタグ、fromタグ及びcallidを外部記憶装置6に出力し、INIVITEパケット及びACKパケットの読み出しを指示する(ステップS1125)。外部記憶装置6は、toタグ、fromタグ及びcallidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードからINVITEパケット及びACKパケットを読み出してメディアサーバ4bに出力する。
【0119】
復旧処理部48bは、外部記憶装置6から読み出したINVITEパケットを呼処理部43bに対して内部的に送信する。これにより、呼処理部43bは、INVITEパケット受信時の処理と同様の処理を行なう(ステップS1130)。呼処理部43bは、図10のステップS420における処理と同様に、INVITEパケットを主記憶部45bに書き込むとともに、INVITEパケットに設定されているfromタグ、callid、各種ヘッダフィールド、電話端末1が用いるRTPポート番号及びIPアドレス、電話端末のCSeqを読み出して主記憶部45bに書き込む。
【0120】
続いて、呼処理部43bは、ステップS1130において内部的に送信されたINVITEパケットに対する200OKパケットを生成し、200OKパケットを送信した場合と同様の処理を行なう(ステップS1135)。200OKのメディアサーバ4のRTPポート番号及びIPアドレスには、ステップS1115において読み出した音声処理復旧情報のレコード内のRTPポート番号及びIPアドレスが設定される。また、200OKパケットのToフィールドには、ステップS1110において読み出したtoタグを使用する。なお、実際には200OKパケットの送信は行なわない。これにより、図10のステップS420における処理と同様に、呼処理部43bは、この生成した200OKパケットを主記憶部45bに書き込むとともに、200OKに設定したtoタグと、メディアサーバ4bが用いるRTPポート番号及びIPアドレス、メディアサーバのCSeq、各種ヘッダフィールドを主記憶部45bに書き込む。
【0121】
続いて、復旧処理部48bは、ステップS1125において外部記憶装置6から読み出したACKパケットを呼処理部43bに対して内部的に送信する。これにより、呼処理部43bは、ACKパケット受信時の処理と同様の処理を行なう(ステップS1140)。呼処理部43bは、図10のステップS420における処理と同様に、送信したこのACKパケットを主記憶部45bに書き込むとともに、各種ヘッダフィールドを主記憶部45bに書き込む。
上記処理により、メディアサーバ4bは、図17のステップS920と同じ状態になる。
【0122】
一方、ステップS1110において読み出した発着信フラグが発信を示している場合(ステップS1120:発信)、ステップS1110において読み出したtoタグ、fromタグ及びcallidを外部記憶装置6に出力し、呼処理復旧情報の読み出しを指示する(ステップS1145)。外部記憶装置6は、toタグ、fromタグ及びcallidにより呼処理復旧情報記憶部63内の呼処理復旧情報のレコードを特定し、特定したレコードを読み出してメディアサーバ4bに出力する。
【0123】
復旧処理部48bからの指示を受け呼処理部43bは、外部記憶装置6から読み出した呼処理復旧情報のレコードからINVITEパケットを生成する。これにより、呼処理部43bは、INVITEパケット送信時の処理と同様の処理を行なうが、実際には送信を行なわない(ステップS1150)。INVITE信号のToフィールドには読み出した呼処理復旧情報のレコード内の端末側電話番号が、Fromフィールドには当該呼処理復旧情報のレコード内のサーバ側電話番号とfromタグが、callidには読み出した当該呼処理復旧情報のレコード内のcallidが、メディアサーバのCSeqには1が、メディアサーバ4のRTPポート及びアドレスにはステップS1115において読み出した音声処理復旧情報のレコードから読み出したRTPポート番号及びIPアドレスが設定される。呼処理部43bは、図12のステップS615における処理と同様に、呼処理部43bは、INVITEパケットを主記憶部45bに書き込むとともに、INVITEパケットに設定されているfromタグ、callid、各種ヘッダフィールド、メディアサーバ4bが用いるRTPポート番号及びIPアドレス、メディアサーバのCSeqを読み出して主記憶部45bに書き込む。
【0124】
続いて、復旧処理部48bは、ステップS1150において読み出した呼処理復旧情報のレコードに設定されている200OKを呼処理部43bに対して内部的に送信する。これにより、呼処理部43bは、200OKパケット受信時の処理と同様の処理を行なう(ステップS1155)。呼処理部43bは、図12のステップS615における処理と同様に、受信した200OKパケットを主記憶部45bに書き込むとともに、toタグ、電話端末1が用いるRTPポート番号及びIPアドレス、電話端末のCSeq、各種ヘッダフィールドを主記憶部45bに書き込む。
【0125】
続いて、復旧処理部48bは、ACKパケットを生成するとともに、ACKパケットを送信した場合と同様の処理を行なう(ステップS1160)。ACKパケットには、INVITE信号と同様のToフィールド、Fromフィールド、callid、メディアサーバのCSeqが設定される。ただし、実際にはACKパケットの送信は行なわない。これにより、図12のステップS615における処理と同様に、呼処理部43bは、このACKパケットを主記憶部45bに書き込むとともに、ACKに設定したfromタグと、メディアサーバのCSeqを主記憶部45bに書き込む。
上記により、メディアサーバ4bは、図18のステップS1015と同じ状態になる。
【0126】
メディアサーバ4bの音声処理部47bは、図13のステップS720と同様の処理により主記憶部45bに保存されたIVR処理情報のレコードを用いてIVR処理を途中から再開し(ステップS1165)、音声処理部47bは、図13のステップS725と同様の処理により、ステップS1115において制御部44bが特定したIVR処理情報のレコードに設定されている値を用いて、電話端末1との間のRTPセッションを再開する(ステップS1170)。
【0127】
続いて復旧処理部48bは、外部記憶装置6の音声処理復旧情報記憶部64に記憶されている音声処理復旧情報の中で、まだ読み出していないレコードがあるかを判断し(ステップS1175)、まだ読み出していないレコードがあれば(ステップS1175:YES)、ステップS1110からの処理を行う。一方、全てのレコードについて読み出しを行なったならば(ステップS1175:NO)、メディアサーバ4bにおいて、以降、メディアサーバ4aが行なっていたステップS520からの処理を行なう。つまり、各部の符号の最後に記載されている「a」を「b」に置き換えればよい。
【0128】
上述したように、本実施形態によれば、現用系のメディアサーバは、セッションが確立したときにSIP、RTPの復旧に必要な情報を外部記憶装置に書込み、IVR処理が開始されると、外部記憶装置にIVR処理の更新状況をリアルタイムに書込み、RTPに関する情報は書き込まない。よって、外部記憶装置に対するアクセスの負荷をかけすぎることなく、メディアサーバは故障が発生した際に引継ぎが必要な情報を外部記憶装置に書き込むことができ、音声パケットに遅延を発生させることもない。なお、SIPの更新情報はセッション確立後も外部記憶装置へ書込む場合がある。通話中に現用系のメディアサーバが故障した場合も、通話がとぎれることなく、待機系のメディアサーバは、故障が発生した時点から引続きIVRシナリオを提供することができる。このように、メディアサーバのセッションフェールオーバを実現することができるため、信頼性の高いシステムを実現することが可能となる。
【0129】
上述の電話端末1、中継サーバ2、メディアサーバ4、外部記憶装置6、及び、発信制御装置7は、内部にコンピュータシステムを有している。そして、電話端末1、中継サーバ2、メディアサーバ4の監視部41及びメディア処理プログラム実行部42、外部記憶装置6、ならびに、発信制御装置7の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、CPU及び各種メモリやOS、周辺機器等のハードウェアを含むものである。
【0130】
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0131】
なお、本発明は、上記において説明した実施形態に限定されるものではなく、その主旨を逸脱しない範囲において種々変更可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【符号の説明】
【0132】
1…電話端末
2…中継サーバ
3…ルータ
4、4a、4b…メディアサーバ
40、40a、40b…通信部
41、41a、41b…監視部
42、42a、42b…メディア処理プログラム実行部
43、43a、43b…呼処理部
44、44a、44b…制御部
45、45a、45b…主記憶部
46、46a、46b…IVR処理部
47、47a、47b…音声処理部
48、48a、48b…復旧処理部
6…外部記憶装置
60…記憶部
61…電話番号設定記憶部
62…IVRフロー記憶部
63…呼処理復旧情報記憶部
64…音声処理復旧情報記憶部
65…IVR処理情報記憶部
7…発信制御装置
【特許請求の範囲】
【請求項1】
ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバであって、
前記ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理部と、
音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理部と、
呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力する音声処理部と、
前記呼処理部により送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理部により実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理部が前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む制御部と、
他のメディアサーバの故障を検出する監視部と、
前記監視部により現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理部とを備え、
前記音声自動応答処理部は、前記復旧処理部が読み出した前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行し、
前記音声処理部は、前記復旧処理部が読み出した前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理部から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力し、
前記呼処理部は、前記復旧処理部が読み出した前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう、
ことを特徴とするメディアサーバ。
【請求項2】
呼の復旧に用いられる情報は、送受信した前記呼制御信号から取得した発側電話番号、着側電話番号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含むことを特徴とする請求項1に記載のメディアサーバ。
【請求項3】
呼の復旧に用いられる情報は、前記電話端末から受信した呼制御信号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含み、
前記復旧処理部は、前記外部記憶装置から読み出した前記呼処理復旧情報に設定されている前記呼制御信号を前記呼処理部に送信し、
前記呼処理部は、前記復旧処理部から送信された前記呼制御信号に基づいて前記電話端末との間の呼のセッションを確立する、
ことを特徴とする請求項1に記載のメディアサーバ。
【請求項4】
メディアセッションの復旧に用いられる前記情報は、発信側及び着信側のメディアセッション用のアドレスと、メディアセッションに特有の値が設定された情報と、音声パケットの送信に伴い値が更新される情報のメディアセッション確立時の値と、前記メディアセッションの開始時刻とを含み、
前記音声処理部は、前記復旧処理部により読み出された前記音声処理復旧情報から前記開始時刻と、音声パケットの送信に伴い更新される前記情報のメディアセッション確立時の値とを取得し、前記開始時刻からの経過時間に基づいて更新される前記情報の現在の値を算出し、前記音声処理復旧情報から読み出した、発信側及び着信側のメディアセッション用の前記アドレスと、メディアセッションに特有の値が設定された前記情報と、算出した前記値を設定した、音声パケットの送信に伴い更新される前記情報とを用いて前記呼のメディアセッションを復旧する、
ことを特徴とする請求項1から請求項3のいずれかの項に記載のメディアサーバ。
【請求項5】
前記制御部は、解放された呼の呼特定情報を含む前記呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から削除する、
ことを特徴とする請求項1から請求項4のいずれかの項に記載のメディアサーバ。
【請求項6】
ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバに用いられるセッション復旧方法であって、
呼処理部が、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、
音声自動応答処理部が、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、
音声処理部が、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部へ出力する音声処理ステップと、
制御部が、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、
監視部が、他のメディアサーバの故障を検出する監視ステップと、
復旧処理部が、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、
前記音声自動応答処理部が、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、
前記音声処理復旧が、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、
前記呼処理部が、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、
を有することを特徴とするセッション復旧方法。
【請求項7】
ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバとして用いられるコンピュータに、
ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、
音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、
呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から音声パケットを受信する音声処理ステップと、
前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、
他のメディアサーバの故障を検出する監視ステップと、
前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、
前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、
前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、
前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、
を実行させることを特徴とするコンピュータプログラム。
【請求項1】
ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバであって、
前記ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理部と、
音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理部と、
呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力する音声処理部と、
前記呼処理部により送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理部により実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理部が前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む制御部と、
他のメディアサーバの故障を検出する監視部と、
前記監視部により現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理部とを備え、
前記音声自動応答処理部は、前記復旧処理部が読み出した前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行し、
前記音声処理部は、前記復旧処理部が読み出した前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理部から送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部に出力し、
前記呼処理部は、前記復旧処理部が読み出した前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう、
ことを特徴とするメディアサーバ。
【請求項2】
呼の復旧に用いられる情報は、送受信した前記呼制御信号から取得した発側電話番号、着側電話番号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含むことを特徴とする請求項1に記載のメディアサーバ。
【請求項3】
呼の復旧に用いられる情報は、前記電話端末から受信した呼制御信号、及び、前記呼制御信号の送信または受信に伴って値が更新される情報の最新の値を含み、
前記復旧処理部は、前記外部記憶装置から読み出した前記呼処理復旧情報に設定されている前記呼制御信号を前記呼処理部に送信し、
前記呼処理部は、前記復旧処理部から送信された前記呼制御信号に基づいて前記電話端末との間の呼のセッションを確立する、
ことを特徴とする請求項1に記載のメディアサーバ。
【請求項4】
メディアセッションの復旧に用いられる前記情報は、発信側及び着信側のメディアセッション用のアドレスと、メディアセッションに特有の値が設定された情報と、音声パケットの送信に伴い値が更新される情報のメディアセッション確立時の値と、前記メディアセッションの開始時刻とを含み、
前記音声処理部は、前記復旧処理部により読み出された前記音声処理復旧情報から前記開始時刻と、音声パケットの送信に伴い更新される前記情報のメディアセッション確立時の値とを取得し、前記開始時刻からの経過時間に基づいて更新される前記情報の現在の値を算出し、前記音声処理復旧情報から読み出した、発信側及び着信側のメディアセッション用の前記アドレスと、メディアセッションに特有の値が設定された前記情報と、算出した前記値を設定した、音声パケットの送信に伴い更新される前記情報とを用いて前記呼のメディアセッションを復旧する、
ことを特徴とする請求項1から請求項3のいずれかの項に記載のメディアサーバ。
【請求項5】
前記制御部は、解放された呼の呼特定情報を含む前記呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から削除する、
ことを特徴とする請求項1から請求項4のいずれかの項に記載のメディアサーバ。
【請求項6】
ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバに用いられるセッション復旧方法であって、
呼処理部が、ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、
音声自動応答処理部が、音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、
音声処理部が、呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを前記音声自動応答処理部へ出力する音声処理ステップと、
制御部が、前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、
監視部が、他のメディアサーバの故障を検出する監視ステップと、
復旧処理部が、前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、
前記音声自動応答処理部が、前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、
前記音声処理復旧が、前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、
前記呼処理部が、前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、
を有することを特徴とするセッション復旧方法。
【請求項7】
ネットワークを介して接続された複数のメディアサーバを有する音声自動応答システムにおける前記メディアサーバとして用いられるコンピュータに、
ネットワークを介して接続される電話端末と呼制御信号パケットを送受信し、前記電話端末との間の呼のセッションを確立する呼処理ステップと、
音声自動応答のシナリオに従って、呼を確立した前記電話端末への音声の送出または前記電話端末から受信した音声の認識あるいはその両方を実行する音声自動応答処理ステップと、
呼を確立した前記電話端末との間でメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答処理ステップにおいて送出された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から音声パケットを受信する音声処理ステップと、
前記呼処理ステップにおいて送受信された前記呼制御信号から取得した呼特定情報と呼のセッションの復旧に用いられる情報とを設定した呼処理復旧情報を外部記憶装置に書き込むとともに、前記呼特定情報と、前記呼特定情報により特定される呼について確立された前記メディアセッションの復旧に用いられる情報とを設定した音声処理復旧情報を前記外部記憶装置に書込み、さらに、前記呼特定情報と、前記呼特定情報により特定される呼について前記音声自動応答処理ステップにおいて実行された音声自動応答のシナリオ上の現在の実行位置を特定する情報と、前記音声自動応答処理ステップにおいて前記電話端末から受信した音声を認識した結果とを設定した音声自動応答処理情報を前記外部記憶装置に書き込む情報書込みステップと、
他のメディアサーバの故障を検出する監視ステップと、
前記監視ステップにおいて現用系の他のメディアサーバの故障を検出した際に、前記他のメディアサーバが使用していたアドレスを自アドレスとして設定するとともに、他の前記メディアサーバが書き込んだ、同一の呼特定情報を有する呼処理復旧情報、音声処理復旧情報、及び、音声自動応答処理情報を前記外部記憶装置から読み出す復旧処理ステップと、
前記復旧処理ステップにおいて読み出された前記音声自動応答処理情報からシナリオ上の現在の実行位置を特定する情報を取得し、取得した前記情報により特定される実行位置から前記音声自動応答のシナリオを実行する音声自動応答復旧ステップと、
前記復旧処理ステップにおいて読み出された前記音声処理復旧情報に基づいてメディアセッションを確立し、確立した前記メディアセッションにより前記音声自動応答復旧ステップにおいて送出が指示された音声を符号化した音声パケットを前記電話端末に送信するとともに、前記電話端末から受信した音声パケットを受信する音声処理復旧ステップと、
前記復旧処理ステップにおいて読み出された前記呼処理復旧情報に基づいて前記電話端末との間の呼のセッションを確立し、呼処理信号の送受信を行なう呼処理復旧ステップと、
を実行させることを特徴とするコンピュータプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【公開番号】特開2011−35606(P2011−35606A)
【公開日】平成23年2月17日(2011.2.17)
【国際特許分類】
【出願番号】特願2009−179087(P2009−179087)
【出願日】平成21年7月31日(2009.7.31)
【出願人】(000102728)株式会社エヌ・ティ・ティ・データ (438)
【Fターム(参考)】
【公開日】平成23年2月17日(2011.2.17)
【国際特許分類】
【出願日】平成21年7月31日(2009.7.31)
【出願人】(000102728)株式会社エヌ・ティ・ティ・データ (438)
【Fターム(参考)】
[ Back to top ]