JP5699202B1 - 呼処理システム、負荷分散方法及び負荷分散プログラム - Google Patents

呼処理システム、負荷分散方法及び負荷分散プログラム Download PDF

Info

Publication number
JP5699202B1
JP5699202B1 JP2013267347A JP2013267347A JP5699202B1 JP 5699202 B1 JP5699202 B1 JP 5699202B1 JP 2013267347 A JP2013267347 A JP 2013267347A JP 2013267347 A JP2013267347 A JP 2013267347A JP 5699202 B1 JP5699202 B1 JP 5699202B1
Authority
JP
Japan
Prior art keywords
server
request
state
tts
conversion
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013267347A
Other languages
English (en)
Other versions
JP2015126260A (ja
Inventor
寛 藤兼
寛 藤兼
山田 恭子
恭子 山田
田中 誠二
誠二 田中
誠 伊勢
誠 伊勢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2013267347A priority Critical patent/JP5699202B1/ja
Application granted granted Critical
Publication of JP5699202B1 publication Critical patent/JP5699202B1/ja
Publication of JP2015126260A publication Critical patent/JP2015126260A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】負荷分散装置を備えた呼処理システムにおいて、確実な音声通話を実現すること。【解決手段】負荷分散装置1において、TTSサーバ3aに動作状態を確認するための確認要求を送信し、その確認要求に対する応答結果からTTSサーバ3aの動作状態を判別し、その判別結果に基づきTTSサーバ3aの動作状態を閉塞状態又は非閉塞状態として管理する。【選択図】図1

Description

本発明は、サーバの状態を管理・監視する技術に関する。
現在では、所定のサービスを提供するサーバの負荷を軽減するため、様々なシステムにおいて負荷分散装置が用いられている。例えば、図14に示すように、音声をIP(Internet Protocol)で伝える呼処理システム100に導入されている。
図14は、呼処理システムにおいて一部の機能部を模式的に示す図である。SDP(Service Delivery Platform)サーバ2は、SIP(Session Initiation Protocol)を用いてマルチメディアのセッションを制御するサーバである。また、TTS(Text to Speech)サーバ3は、SDPサーバ2からの要求に基づき、その要求に係るテキストデータをデジタル音声データに変換するサーバであり、変換されたデジタル音声データはSIPで確立されたマルチメディアのセッション中にRTP(Real-time Transport Protocol)に変換され、ユーザ端末へ通知される。
このような構成において負荷分散装置1は、SDPサーバ2と複数のTTSサーバ3a〜3nとの間に接続され、HTTP要求をSDPサーバ2から受信すると一定のアルゴリズムに基づいて1つのTTSサーバ3i(i:a〜n)を決定し、そのTTSサーバ3iに先のHTTP要求を転送する。例えば、ラウンドロビン方式で転送先を順番に割り振ることにより、特定のTTSサーバ3iにのみ音声変換に係る負荷が集中するのを防止している。
特開2003−99413号公報
しかしながら、単にSDPサーバからの要求を負荷分散する処理を実行するため、動作不能の状態にあるTTSサーバに要求が転送されると音声への変換処理が実行できず、結果として要求元の音声が要求先のユーザ端末に届かないという課題があった。
また、更にSDPサーバ2より受信するテキストデータの変換処理に失敗した場合、単なる負荷分散処理では異なるTTSサーバ3iへのリトライ処理を繰り返すため、全てのTTSサーバ3a〜3nの動作不具合を引き起こす可能性があり、結果として要求元の音声が要求先のユーザ端末に届かないという課題もあった。
本発明は、上記事情を鑑みてなされたものであり、負荷分散装置を備えた呼処理システムにおいて、確実な音声通話を実現することを目的とする。
請求項1に記載の呼処理システムは、負荷分散装置を備えた呼処理システムにおいて、前記負荷分散装置は、マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送する要求転送手段と、前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別する変換サーバ状態管理手段と、前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて記憶する変換サーバ閉塞情報記憶手段と、を有し、前記負荷分散装置は、全ての変換サーバが閉塞状態の際に前記要求の受付を拒否する、又は、前記制御サーバは、全ての変換サーバが閉塞状態の際に前記要求に係る他のサーバからの要求の受付を拒否することを要旨とする。
本発明によれば、変換サーバに動作状態を確認するための確認要求を送信し、その確認要求に対する応答結果から変換サーバの動作状態を判別し、その判別結果に基づき変換サーバの動作状態を閉塞状態又は非閉塞状態として管理するため、その管理内容に基づいて制御サーバからの要求を変換サーバに転送できることから、結果として確実な音声通話を実現できる。
本発明によれば、全ての変換サーバが閉塞状態の際に制御サーバからの要求の受付を拒否するため、閉塞状態の変換サーバ群に対する要求のリトライを抑止できる。また、本発明によれば、制御サーバが、全ての変換サーバが閉塞状態の際に他のサーバからの要求の受付を拒否するため、閉塞状態の変換サーバ群に対する要求のリトライを抑止できる。
請求項に記載の呼処理システムは、請求項に記載の呼処理システムにおいて、前記要求転送手段は、転送先の変換サーバが閉塞状態の際に前記要求を他の変換サーバに転送することを要旨とする。
請求項に記載の呼処理システムは、請求項1又は2に記載の呼処理システムにおいて、前記変換サーバ状態管理手段は、前記要求に対する変換サーバでの処理結果がNGの際にのみ前記判別処理を実行することを要旨とする。
請求項に記載の呼処理システムは、請求項1乃至3のいずれかに記載の呼処理システムにおいて、前記制御サーバは、全てのメディアサーバが使用不能状態の際又は電話網が輻輳状態の際に、前記要求に係る他のサーバからの要求の受付を拒否する要求規制手段を有することを要旨とする。
請求項に記載の負荷分散方法は、負荷分散装置を備えた呼処理システムで行う負荷分散方法において、マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送するステップと、前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別するステップと、前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて変換サーバ閉塞情報記憶手段に記憶するステップと、全ての変換サーバが閉塞状態の際に、前記要求の受付又は前記要求に係る他のサーバからの要求の受付を拒否するステップと、を有することを要旨とする。
請求項に記載の負荷分散プログラムは、請求項に記載の負荷分散方法をコンピュータに実行させることを要旨とする。
本発明によれば、負荷分散装置を備えた呼処理システムにおいて、確実な音声通話を実現できる。
呼処理システムの全体構成を模式的に示す図である。 負荷分散装置の機能ブロック構成を示す図である。 SDPサーバの機能ブロック構成を示す図である。 TTSサーバの状態管理動作フローを示す図である。 TTSサーバ閉塞情報の例を示す図である。 TTSサーバの状態監視動作フローを示す図である。 TTSサーバの動作状態に基づく新たなHTTP要求の規制処理シーケンスを示す図である。 MSサーバの動作状態に基づく新たなHTTP要求の規制処理シーケンスを示す図である。 MSサーバの状態監視動作フローを示す図である。 MSサーバの状態監視動作フローを示す図である。 図9及び図10を説明する際の参照図である。 MS状態管理テーブルの例を示す図である。 電話網の動作状態に基づく新たなHTTP要求の規制処理シーケンスを示す図である。 呼処理システムにおいて一部の機能部を模式的に示す図である。
本発明は、(1)負荷分散装置においてTTSサーバの動作状態を管理・監視し、(2)特に全てのTTSサーバが閉塞状態の場合には、負荷分散装置やSDPサーバにおいてHTTP要求の受付を拒否することにより、確実な音声通話を実現するようにしている。以下、本発明を実施する一実施の形態について図面を用いて説明する。
図1は、本実施の形態に係る呼処理システムの全体構成を模式的に示す図である。本呼処理システム100は、負荷分散装置1と、SDPサーバ2と、複数のTTSサーバ3a〜3nと、を備えて構成される。以下、それらの機能について説明する。
負荷分散装置1は、SDPサーバ2と複数のTTSサーバ3a〜3nとの間に接続される。そして、図2に示すように、HTTP要求転送部11と、TTSサーバ状態管理部12と、TTSサーバ閉塞情報記憶部13と、を備えて構成される。
HTTP要求転送部11は、HTTP要求をSDPサーバ2から受信すると、予め設定されたアルゴリズムに基づいて複数のTTSサーバ3a〜3nの中から1つのTTSサーバ3i(i:a〜n)を決定し、その決定されたTTSサーバ3iに先のHTTP要求を転送する機能部である。
また、HTTP要求転送部11は、後述するTTSサーバ閉塞情報を参照し、全てのTTSサーバ3a〜3nが閉塞状態の場合にSDPサーバ2からのHTTP要求の受付を拒否する機能や、転送先のTTSサーバ3iが閉塞状態の場合にHTTP要求を他のTTSサーバ3i’に転送する機能を更に備えている。
TTSサーバ状態管理部12は、動作状態を確認するための状態確認コマンドを実行して1つのTTSサーバ3i又は全部のTTSサーバ3a〜3nにおける現在の動作状態を確認し、その確認結果に基づきTTSサーバ3の動作状態を閉塞状態又は非閉塞状態として管理する機能部である。
TTSサーバ閉塞情報記憶部13は、TTSサーバ状態管理部12で確認された各TTSサーバ3a〜3nの夫々の動作状態を各TTSサーバ3a〜3nの識別子IDに夫々関連付けてTTSサーバ閉塞情報として記憶する機能部である。このTTSサーバ閉塞情報は、HTTP要求転送部11によってHTTP要求の受付時や転送時に参照される。
以上が負荷分散装置1の備える機能である。続いて、SDPサーバ2の機能について説明する。SDPサーバ2は、SIPを用いてマルチメディアのセッションを制御するサーバであり、負荷分散装置1やTTSサーバ3以外に、Webサーバ4や複数のMS(Media Server)サーバ5a〜5n、更には任意の電話網6に通信可能に接続されている(図1参照)。そして、図3に示すように、HTTP要求受付部21と、HTTP要求規制部22と、TTSサーバ状態確認部23と、を備えて構成される。
HTTP要求受付部21は、上位のWebサーバ4から送信されたHTTP要求を受け付けて、負荷分散装置1を通じてTTSサーバ3に当該HTTP要求を送信する機能部である。
HTTP要求規制部22は、全てのTTSサーバ3a〜3nが閉塞状態の場合、全てのMSサーバ5a〜5nが使用不能状態の場合、又は、電話網6が輻輳状態の場合に、Webサーバ4からの新たなHTTP要求の受付を拒否する機能部である。
TTSサーバ状態確認部23は、負荷分散装置1に対して各TTSサーバ3a〜3nの動作状態を問い合わせる機能部である。
以上がSDPサーバ2の備える機能である。ここで、他のサーバについて説明しておく。TTSサーバ3とは、負荷分散装置1を介してSDPサーバ2から送信されたHTTP要求に基づき、そのHTTP要求に係るRTP内のテキストデータをデジタル音声に変換するサーバである。また、MSサーバ5は、音声ガイダンスの再生やユーザの音声を録音等するサーバである。また、電話網6は、既存のPSTN(Public Switched Telephone Network)網やPSTNを代替するNGN(Next Generation Network)網等である。
次に、本実施の形態に係る呼処理システムの動作について説明する。最初に、負荷分散装置1で行うTTSサーバ3の状態管理動作について説明する。図4は、TTSサーバ3の状態管理処理フローを示す図である。
まず、あるHTTP要求をSDPサーバ2から受信すると、HTTP要求転送部11は、所定のアルゴリズムに基づいて複数のTTSサーバ3a〜3nの中から例えばTTSサーバ3aを転送先として決定し、HTTP要求の宛先に設定されているバーチャルIPアドレス(負荷分散装置1のSDPサーバ側のIPアドレス)をTTSサーバ3aのプライベートIPアドレスに書き換えて転送処理を実行する(ステップS101)。
次に、転送したHTTP要求に対するHTTP応答をTTSサーバ3aから受信すると、HTTP要求転送部11は、そのHTTP応答に含まれている応答コードの番号を判別する(ステップS102)。
そして、その応答コードが200(処理結果:OK)の場合、HTTP要求に対する処理がTTSサーバ3aの内部で何らの問題なく成功しているので、HTTP要求転送部11は、TTSサーバ3からのHTTP応答をそのままSDPサーバ2に返信する(ステップS103)。
一方、その応答コードが200以外(処理結果:NG)の場合、転送したHTTP要求に対する処理が何らかの理由により失敗している可能性があるため、TTSサーバ状態管理部12は、状態確認コマンドを実行することにより動作状態を確認するための状態確認要求を送信し、その状態確認要求に対する応答結果からTTSサーバ3aの現在の動作状態を確認する(ステップS104)。
すなわち、TTSサーバ3aからの状態確認応答に含まれている応答コードの番号を判別し、その応答コードが1(動作状態:OK)の場合、先のHTTP要求に対する処理については成功したものとみなし、HTTP要求転送部11は、ステップS103と同様にTTSサーバ3aからのHTTP応答をそのままSDPサーバ2に返信する(ステップS105)。また、TTSサーバ状態管理部12は、そのTTSサーバ3aの動作状態を非閉塞状態として管理する(ステップS106)。
このとき、TTSサーバ3aの動作状態を新規に確認した場合には、そのTTSサーバ3aが非閉塞状態である情報を当該TTSサーバ3aの識別子IDに対応付けてTTSサーバ閉塞情報記憶部13のTTSサーバ閉塞情報に追記して管理する。一方、TTSサーバ3aの動作状態が過去に閉塞状態として既に管理されていた場合には、その過去に確認された閉塞状態を今回確認した非閉塞状態に変更する。
一方、TTSサーバ3aからの状態確認応答に含まれている応答コードが0(動作状態:NG)の場合、又は、TTSサーバ3aから状態確認応答を一定のタイムアウト時間(例えば10秒)以内に受信しない場合、先のHTTP要求に対する処理については失敗したものとみなし、HTTP要求転送部11は、そのHTTP要求を他のTTSサーバ3i’(i’:b〜n)に振り替えて送信する(ステップS107)。
具体的には、先のアルゴリズムに基づいてTTSサーバ3aを除く全てのTTSサーバ3b〜3nの中から例えばTTSサーバ3bを転送先として決定し、HTTP要求の宛先をTTSサーバ3bのプライベートIPアドレスに書き換えて転送処理を実行する。
そして、ステップS107の後、TTSサーバ状態管理部12は、TTSサーバ3aの動作状態を閉塞状態として管理する(ステップS108)。本ステップ又はステップS106の結果、TTSサーバ閉塞情報記憶部13には例えば図5に示すようなTTSサーバ閉塞情報が記録される。その後、HTTP要求転送部11は、HTTP要求を新たに受信した場合、このTTSサーバ閉塞情報を参照して動作状態が非閉塞状態であるTTSサーバ3の中から転送先を決定する。
以上の状態管理処理フローによれば、HTTP要求に対するHTTP応答内の応答コードが200以外の場合、転送先のTTSサーバ3aの動作状態を確認し、その確認結果に基づきTTSサーバ3aの動作状態を閉塞状態又は非閉塞状態として管理するので、HTTP要求が動作不能状態のTTSサーバ3に転送されることを回避でき、結果としてユーザ端末間での音声通話を確実に実現できる。
続いて、負荷分散装置1で行うTTSサーバ3の状態監視動作について説明する。図6は、TTSサーバ3の状態監視処理フローを示す図である。
まず、TTSサーバ状態管理部12は、TTSサーバ3の動作状態が閉塞状態又は非閉塞状態のいずれかに関わらず、負荷分散装置1に接続されている全てのTTSサーバ3a〜3nに対し、状態確認コマンドを実行して各TTSサーバ3a〜3nの現在の動作状態を夫々確認する(ステップS201)。
その後、各TTSサーバ3a〜3nから夫々返信された各状態確認応答に含まれる各応答コードを夫々判別し、応答コードが1(動作状態:OK)の場合、TTSサーバ状態管理部12は、その応答コードを返信したTTSサーバ3の動作状態を非閉塞状態として管理する(ステップS202)。
一方、応答コードが0(動作状態:NG)の場合、又は、TTSサーバ3から状態確認応答を一定のタイムアウト時間内に受信しない場合、TTSサーバ状態管理部12は、その応答コードを返信したTTSサーバ3、又は状態確認応答を返信しなかったTTSサーバ3の動作状態を閉塞状態として管理する(ステップS203)。
そして、ステップS202及び/又はステップS203の後はステップS201に戻り、ステップS201〜S203を定周期で繰り返し実行する。そして、本状態監視処理による全てのTTSサーバ3a〜3nの状態監視結果は、TTSサーバ閉塞情報記憶部13のTTSサーバ閉塞情報で管理され、本状態監視処理を実行する毎に更新(追加、削除、変更)される。
なお、本状態監視処理の実行期間間隔が短い場合、TTSサーバ閉塞情報内で管理している動作状態がTTSサーバ3の実状態に合致している可能性が高いことから、前述したTTSサーバ3の状態管理動作(図4参照)において、ステップS104をスキップし、記録済みのTTSサーバ閉塞情報を元にステップS105又はステップS107を実行するようにしても構わない。
以上の状態監視処理のフローによれば、各TTSサーバ3a〜3nの動作状態を定期的に確認するため、TTSサーバ閉塞情報内の情報が随時更新されることから、ユーザ端末間での音声通話をより確実に実現できる。
これまで、TTSサーバ3の動作状態を管理・監視する方法について説明した。引き続き、その管理結果や監視結果を利用して負荷分散装置1及びSDPサーバ2で行う新たなHTTP要求の規制動作について説明する。図7は、新たなHTTP要求の規制処理シーケンスを示す図である。なお、複数のTTSサーバ3a〜3nは全て閉塞状態であるとする。
まず、SDPサーバ2において、TTSサーバ状態確認部23は、負荷分散装置3に各TTSサーバ3a〜3nの動作状態を問い合わせる(ステップS301)。
次に、負荷分散装置1において当該動作状態の問合せを受け付けると、HTTP要求転送部11は、TTSサーバ閉塞情報記憶部13のTTSサーバ閉塞情報を参照し、全てのTTSサーバ3a〜3nが閉塞状態である問合せ結果を返信し、以降、SDPサーバ2からの新たなHTTP要求の受付を拒否する(ステップS302)。
続いて、新たなHTTP要求がWebサーバ4からSDPサーバ2に送信されると、SDPサーバ2においてHTTP要求受付部21で一旦受信されるが、ステップS302の問合せ結果から全てのTTSサーバ3a〜3nが閉塞状態であるため、HTTP要求規制部22は、その新たなHTTP要求を受け付けることなくメモリ上から削除し、その受付を拒否したことを意味する受付拒否応答をWebサーバ4に返信する(ステップS303)。
以上の規制動作シーケンスによれば、全てのTTSサーバ3a〜3nの動作状態が閉塞状態の場合、負荷分散装置1においてSDPサーバ2からの新たなHTTP要求の受付を拒否するため、閉塞状態のTTSサーバ3群に対するHTTP要求のリトライを抑止できる。
同様に、全てのTTSサーバ3a〜3nの動作状態が閉塞状態の場合、SDPサーバ2においてWebサーバ4からの新たなHTTP要求の受付を拒否するため、閉塞状態のTTSサーバ3群に対するHTTP要求のリトライを抑止できる。
なお、このようなHTTP要求の規制処理は、全てのMSサーバ5a〜5nが使用不能状態である場合にも適用できる。例えば、図8に示すように、全てのMSサーバ5a〜5nから使用不可を意味するメッセージや信号が送信された場合、SDPサーバ2は、前述のステップS303と同様に、新たなHTTP要求を受け付けることなくメモリ上から削除し、受付拒否応答をWebサーバ4に返信する。
ここで、SDPサーバ2で行うMSサーバ5の状態監視方法について詳述する。図9及び図10は、MSサーバ5の状態監視動作フローを示す図である。両図面はA及びBの符号によって関連付けられている。
まず、MSサーバ5からMS状態情報が通知されると、それに含まれている状態コードの番号を判別する(ステップS401)。MS状態情報には、MSサーバ5の動作状態(以下、MS状態)を表す状態コードが含まれており、例えば、図11に示すような状態コードのうちいずれかが入力されている。
そして、その状態コードが000(正常),004(システムエラー),005(閉塞中),006(チャネル故障中),021(輻輳中),022(一時的輻輳中),026(APL(MSサーバ5を実行するためのApplication)故障)のうちいずれかの場合には、まず、通知元のMSサーバ5がMS状態管理テーブルに登録されているか否かを確認する(ステップS402)。一方、状態コードがそれら以外の場合には、特に処理を行うことなく符号Bを介して進み本動作を終了する。
ここで、未登録の場合には、新たなMSサーバ5からの通知であるため、そのMSサーバ5の識別子ID(例えば、MSサーバ5のプライベートIPアドレス)をMS状態管理テーブルに登録する(ステップS403)。一方、MS状態管理テーブルに登録されている場合には、既に監視対象であるため、本ステップをスキップする。
続いて、先の7つの状態コードを更に判別し、000,004,022の場合には、通知元のMSサーバ5のMS状態をOKとみなし、そのMSサーバ5のMS状態を正常として管理し、更に異常状態テーブルから処理全面停止フラグを削除して、そのMSサーバ5との間での処理を実行できるようにする(ステップS404)。そしてその後、符号Aを介して進む。
例えば、図12に示すようなMS状態管理テーブルが作成される。なお、このMS状態管理テーブルには、MSサーバ5の識別子IDやMS状態の他、MS状態情報が通知された日時、セッションの確立時に設定されるセッションIDが対応付けて登録される。
なお、状態コードが004や022の場合であっても、MSサーバ5は使用可能な状態の場合があるため、正常として処理する。
また、異常状態管理テーブルとは、MS状態管理テーブルとは別の管理テーブルであり、管理対象のMSサーバ5が全て異常の場合に処理全面停止フラグが登録される。SDPサーバ2の起動直後には処理全面停止フラグが登録されており、MSサーバ5からのMS状態情報の状態コードが上記3つの場合に削除(全面停止の解除)される。
一方、状態コードが005,006,021,026の場合には、通知元のMSサーバ5のMS状態をNGとみなし、まず、異常状態テーブルに処理全面停止フラグが登録されているか否かを確認して(ステップS405)、そのフラグが登録されていない場合、すなわち、少なくとも1つ以上のMSサーバ5との間で処理できる状態の場合には、通知元のMSサーバ5のMS状態を異常として管理する(ステップS406)。そして、全てのMSサーバ5のMS状態を確認し(ステップS407)、全てのMSサーバ5のMS状態が異常の場合には、異常状態テーブルに処理全面停止フラグを登録し(ステップS408)、符号Aを介して進む。
一方、ステップS405において処理全面停止フラグが登録されている場合には、全てのMSサーバ5のMS状態が既に異常であるため、ステップS406〜S408をスキップして符号Aを介して進む。
また、ステップS407において全てのMSサーバ5のMS状態が異常でない場合には、処理全面停止フラグを登録する必要がないため、ステップS408をスキップして符号Aを介して進む。
引き続き、図10を参照しながら説明する。これまでは、状態コードに応じたMS状態管理テーブルや異常状態テーブルへの設定方法について説明したが、これ以降は、状態コードに応じて行うセッションに対する制御方法について説明する。
続いても先の7つの状態コードを更に判別し、状態コードが006,021,026の場合には、通知されたMS状態情報にセッショングループIDが含まれているか否かを確認し(ステップS409)、セッショングループIDが含まれている場合には、そのセッショングループIDのセッションを切断して、MS状態管理テーブルから該当するMSサーバ5のセッションIDを削除して本動作を終了する(ステップS410)。一方、セッショングループIDが含まれている場合には、ステップS410をスキップして本動作を終了する。
一方、状態コードが026の場合には、MS状態情報にセッショングループIDが含まれていないことは明らかであるため、単にMS状態管理テーブルから該当するMSサーバ5のセッションIDを削除して本動作を終了する(ステップS411)。また、状態コードが000,004,005の場合には、そのような削除処理を実行することなく、本動作を終了する。
なお、MS状態管理テーブルは、SDPサーバ2の内部ジョブにより定期的にチェックされ、MS状態管理テーブルの通知日時が更新されていない場合には、該当のMSサーバ5が使用不能になったと判断し、登録されているセッションIDのセッションに対して切断を行い、MS状態管理テーブルから当該セッションIDを削除して、MS状態を異常に変更する。
以上、MSサーバ5に対するHTTP要求の規制処理について説明したが、その他、電話網6が輻輳状態である場合にも適用できる。例えば、図13に示すように、電話網6から、輻輳によりサービス停止中であることを意味するコード番号503のメッセージや信号が送信された場合についても同様である。
以上、本実施の形態では、負荷分散装置1をSDPサーバ2と複数のTTSサーバ3a〜3nとの間に介在させた構成について説明した。一方、負荷分散装置1は、SDPサーバ2と電話網6との間に介在させることも可能である。例えば、実行系と待機系といった複数のNGN網の前段に配置する。そして、実行系のNGN網が震災等の影響により故障や輻輳が発生した場合、具体的には、NGN網から一定時間内にデータが送信されない場合や無応答の場合等には、直ちに転送先を待機系のNGN網に切り替えると共にその旨をSDPサーバ2に返信する。
通常、NGN網のIPアドレスはDNS(Domain Name System)で管理されており、そのDNS内においてNGN網の待機系のIPアドレスが実行系のIPアドレスに切り替わるタイミングは1日1回程度と遅い。そこで、故障等の発生時に系を切り替えるため、系切り替えのタイミングを短縮でき、呼処理サービスを継続的に運用できる。
また、故障や輻輳が発生した場合、待機系のNGN網が実行系となるまでの間、故障中や混雑中のエラーメッセージを定型のフォーマットで安否確認システムの画面や保守運用端末の画面に出力する。SDPサーバ2からの要求に対してそのような画面で応答することにより、リアルタイム通信の利用可否を保守者に通知でき、故障等の状態からの早期回復を実現できる。
最後に、本実施の形態で説明した負荷分散装置1やSDPサーバ2は、メモリやCPUを備えたコンピュータで実現できる。また、その処理は、プログラムによって実行される。更に、負荷分散装置1やSDPサーバ2の各動作をプログラムとして構築し、コンピュータにインストールして実行させることや、通信ネットワークを介して流通させることも可能である。
100…呼処理システム
1…負荷分散装置
11…HTTP要求転送部(要求転送手段)
12…TTSサーバ状態管理部(変換サーバ状態管理手段)
13…TTSサーバ閉塞情報記憶部(変換サーバ閉塞情報記憶手段)
2…SDPサーバ(制御サーバ)
21…HTTP要求受付部
22…HTTP要求規制部(要求規制手段)
23…TTSサーバ状態確認部
3a〜3n…TTSサーバ(変換サーバ)
4…Webサーバ
5a〜5n…MSサーバ
6…電話網
S101〜S108、S201〜S203、S301〜S303、S401〜S411…ステップ

Claims (6)

  1. 負荷分散装置を備えた呼処理システムにおいて、
    前記負荷分散装置は、
    マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送する要求転送手段と、
    前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別する変換サーバ状態管理手段と、
    前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて記憶する変換サーバ閉塞情報記憶手段と、を有し、
    前記負荷分散装置は、全ての変換サーバが閉塞状態の際に前記要求の受付を拒否する、又は、前記制御サーバは、全ての変換サーバが閉塞状態の際に前記要求に係る他のサーバからの要求の受付を拒否することを特徴とする呼処理システム
  2. 前記要求転送手段は、
    転送先の変換サーバが閉塞状態の際に前記要求を他の変換サーバに転送することを特徴とする請求項1に記載の呼処理システム。
  3. 前記変換サーバ状態管理手段は、
    前記要求に対する変換サーバでの処理結果がNGの際にのみ前記判別処理を実行することを特徴とする請求項1又は2に記載の呼処理システム。
  4. 前記制御サーバは、
    全てのメディアサーバが使用不能状態の際又は電話網が輻輳状態の際に、前記要求に係る他のサーバからの要求の受付を拒否する要求規制手段を有することを特徴とする請求項1乃至3のいずれかに記載の呼処理システム。
  5. 負荷分散装置を備えた呼処理システムで行う負荷分散方法において、
    マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送するステップと、
    前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別するステップと、
    前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて変換サーバ閉塞情報記憶手段に記憶するステップと、
    全ての変換サーバが閉塞状態の際に、前記要求の受付又は前記要求に係る他のサーバからの要求の受付を拒否するステップと、
    を有することを特徴とする負荷分散方法。
  6. 請求項5に記載の負荷分散方法をコンピュータに実行させることを特徴とする負荷分散プログラム。
JP2013267347A 2013-12-25 2013-12-25 呼処理システム、負荷分散方法及び負荷分散プログラム Active JP5699202B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013267347A JP5699202B1 (ja) 2013-12-25 2013-12-25 呼処理システム、負荷分散方法及び負荷分散プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013267347A JP5699202B1 (ja) 2013-12-25 2013-12-25 呼処理システム、負荷分散方法及び負荷分散プログラム

Publications (2)

Publication Number Publication Date
JP5699202B1 true JP5699202B1 (ja) 2015-04-08
JP2015126260A JP2015126260A (ja) 2015-07-06

Family

ID=52837065

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013267347A Active JP5699202B1 (ja) 2013-12-25 2013-12-25 呼処理システム、負荷分散方法及び負荷分散プログラム

Country Status (1)

Country Link
JP (1) JP5699202B1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112420052A (zh) * 2020-11-18 2021-02-26 青岛海尔科技有限公司 设备控制方法、装置、存储介质及电子装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102428296B1 (ko) * 2020-10-13 2022-08-02 주식회사 케이티 음성 합성 스케쥴을 조정하는 캐쉬 서버, 방법 및 음성 합성을 수행하는 음성 합성 서버

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09298556A (ja) * 1996-05-08 1997-11-18 Nec Corp 音声蓄積再生サービス装置
JP2003099413A (ja) * 2001-09-25 2003-04-04 Nec Commun Syst Ltd 分散処理システム
JP2014072577A (ja) * 2012-09-27 2014-04-21 Toshiba Corp 音声アプリケーションシステム、管理サーバ装置及びその制御方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09298556A (ja) * 1996-05-08 1997-11-18 Nec Corp 音声蓄積再生サービス装置
JP2003099413A (ja) * 2001-09-25 2003-04-04 Nec Commun Syst Ltd 分散処理システム
JP2014072577A (ja) * 2012-09-27 2014-04-21 Toshiba Corp 音声アプリケーションシステム、管理サーバ装置及びその制御方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112420052A (zh) * 2020-11-18 2021-02-26 青岛海尔科技有限公司 设备控制方法、装置、存储介质及电子装置

Also Published As

Publication number Publication date
JP2015126260A (ja) 2015-07-06

Similar Documents

Publication Publication Date Title
US10165431B2 (en) Method and system for emergency call management
CN102177690B (zh) 在电信网络中提供镇静服务的方法、系统和计算机可读介质
EP2074791B1 (en) Communication system
US20090049180A1 (en) Gateway apparatus
US8266298B2 (en) Storage medium, uniqueness assurance realizing method, session management method and uniqueness assurance information setting management device
US20110149750A1 (en) Subscriber fallback/migration mechanisms in ims geographic redundant networks
EP2079197A1 (en) A method and system for coordinating the services provided by different service providers
JP4609345B2 (ja) 中継サーバ及び接続制御方法並びにプログラム
JP4566589B2 (ja) Sipサーバ
JP2006157612A (ja) ネットワーク電話システムとこのネットワーク電話システムのサーバ装置及び電話端末
CN105027528A (zh) 会话建立的过载控制
CN101296177A (zh) 在分组网络中实现过载控制的方法、系统和装置
JP5202383B2 (ja) 通信ネットワークシステムとその呼制御装置及び発信規制方法
JP5699202B1 (ja) 呼処理システム、負荷分散方法及び負荷分散プログラム
US20130336312A1 (en) Communication system, datacenter apparatus, and control method used in datacenter apparatus
US11757952B2 (en) Relay device for call processing, call processing method performed by relay device, and storage medium in which program for executing call processing method is stored
KR20120052444A (ko) 모바일 메시징 서비스에서의 파일 전송을 지원하는 파일 전송 관리 시스템 및 파일 전송 관리 방법
US11750665B2 (en) Distributed network system for call processing provided are a call processing method performed by a distributed network system and a recording medium, in which a program for executing the call processing method is recorded
CN100586110C (zh) 用于将消息路由到暂时不可利用的网络用户的方法、系统和网络设备
US8504701B2 (en) Method for the management of flows between appliances of a telecommunications network
KR102636491B1 (ko) 5g 망에서의 단말 기반 동적 네트워크 정책 제어 방법, 그리고 이를 제공하는 단말 및 네트워크 시스템
US20150023152A1 (en) Method for changing terminal accommodation destination, server apparatus and terminal apparatus
JP5766164B2 (ja) 呼制御システム
EP2475157A1 (en) Method and apparatus for managing telephone services of a user communication device when a server providing those telephone services is unavailable
JP2010239529A (ja) 負荷分散システム及びコンピュータープログラム

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150120

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150216

R150 Certificate of patent or registration of utility model

Ref document number: 5699202

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250