JP2014007617A - 呼制御サーバ、通信システム、および呼制御方法 - Google Patents
呼制御サーバ、通信システム、および呼制御方法 Download PDFInfo
- Publication number
- JP2014007617A JP2014007617A JP2012142605A JP2012142605A JP2014007617A JP 2014007617 A JP2014007617 A JP 2014007617A JP 2012142605 A JP2012142605 A JP 2012142605A JP 2012142605 A JP2012142605 A JP 2012142605A JP 2014007617 A JP2014007617 A JP 2014007617A
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- call control
- control server
- information
- telephone number
- 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.)
- Pending
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
【課題】 呼制御サーバが故障しても、呼制御ログを一次保存する記憶装置などを必要とせずに呼接続を継続し、システム停止となる可能性が低く、信頼性の高い呼制御サーバ、および通信システムを得ることを目的とする。
【解決手段】 通常動作時に、他の呼制御サーバから他の呼制御サーバが制御する第2のIP端末の第2の端末情報が転送されることにより、例えば、他の呼制御サーバと第2のIP端末との通信に障害が発生した場合に、第2のIP端末から発信先である第1のIP端末の電話番号を受信し、第1のIP端末から送信されて記憶している第1のIP端末の電話番号に対応するアドレス情報を検索して第2のIP端末に送信するので、外部記憶装置を必要とすることなく、他の呼制御サーバに障害が発生した場合にも、第1のIP端末と第2のIP端末の通信を可能にすることができる。
【選択図】 図1
【解決手段】 通常動作時に、他の呼制御サーバから他の呼制御サーバが制御する第2のIP端末の第2の端末情報が転送されることにより、例えば、他の呼制御サーバと第2のIP端末との通信に障害が発生した場合に、第2のIP端末から発信先である第1のIP端末の電話番号を受信し、第1のIP端末から送信されて記憶している第1のIP端末の電話番号に対応するアドレス情報を検索して第2のIP端末に送信するので、外部記憶装置を必要とすることなく、他の呼制御サーバに障害が発生した場合にも、第1のIP端末と第2のIP端末の通信を可能にすることができる。
【選択図】 図1
Description
本発明は、電話通信システムのIP端末を制御する呼制御サーバに関するものである。
近年、IP(Internet Protocol)ネットワークの発展により、音声信号をIPパケット化して伝送するVoIP(Voice over IP)技術の普及が進んでいる。VoIPによる電話通信システムは、音声パケットを送受信して音声通話を行うIP電話端末(以降、単にIP端末という)と、IP端末の電話番号と電話番号に対応するアドレス情報などを管理してIP端末どうしの通信を制御する呼制御サーバから構成される。
呼制御サーバは、通常SIP(Session Initiation Protocol)と呼ばれる呼制御プロトコルを用いてIP端末とメッセージを交換し、各種呼制御を行う。
VoIPによる電話通信システムでは、従来の公衆電話網のように電話番号とIP端末が接続されるアクセス回線とが対応付けられていない。そのため、各IP端末を特定するアドレス情報として、そのIPアドレスやURI(Uniform Resource Identifiers)等のネットワークアドレスが用いられる。
VoIPによる電話通信システムでは、従来の公衆電話網のように電話番号とIP端末が接続されるアクセス回線とが対応付けられていない。そのため、各IP端末を特定するアドレス情報として、そのIPアドレスやURI(Uniform Resource Identifiers)等のネットワークアドレスが用いられる。
そこで、SIPでは、例えばIP端末が所定の呼制御サーバへ、自身のIPアドレスや電話番号を含む各種端末情報を起動時や端末情報変更時に登録する。そして、IP端末が他のIP端末に発信する場合、端末情報を登録した呼制御サーバに発信先のIP端末の電話番号を伝える。
呼制御サーバは、IP端末から発信先の他のIP端末の電話番号を受信すると、発信先の他のIP端末の電話番号に対応したIPアドレスを登録されている端末情報から検索して特定し、特定した発信先の電話番号に対応したIPアドレスを発信元のIP端末(発信先の他のIP端末の電話番号を送信してきたIP端末)に送信する。呼制御サーバのこのような機能により、発信元のIP端末が発信先の他のIP端末のIPアドレスがわからなくても、IP端末どうしの通信が行える。
呼制御サーバは、IP端末から発信先の他のIP端末の電話番号を受信すると、発信先の他のIP端末の電話番号に対応したIPアドレスを登録されている端末情報から検索して特定し、特定した発信先の電話番号に対応したIPアドレスを発信元のIP端末(発信先の他のIP端末の電話番号を送信してきたIP端末)に送信する。呼制御サーバのこのような機能により、発信元のIP端末が発信先の他のIP端末のIPアドレスがわからなくても、IP端末どうしの通信が行える。
このような電話通信システムにおいて呼制御サーバが故障すると、全ての音声通信が出来なくなる。そこで、呼制御サーバを二重化してシステムの信頼性を上げる方法が各種検討されている。
例えば、呼制御サーバを二重化するシステムとして、運用中の呼制御サーバ、待機中の呼制御サーバ、および呼制御ログを一時保存する外部記憶装置を備え、運用中の呼制御サーバは常に呼制御ログを外部記憶装置に書き出すというものがある。このシステムでは、運用中の呼制御サーバが故障すると待機中の呼制御サーバに切り替えられる。この切替えにおいて、待機中の呼制御サーバは外部記憶装置に書き込まれた呼制御ログから運用に必要な情報を得るため、運用中の呼制御サーバが故障しても、待機中の呼制御サーバによりIP端末どうしの通信が可能となる(特許文献1)。
例えば、呼制御サーバを二重化するシステムとして、運用中の呼制御サーバ、待機中の呼制御サーバ、および呼制御ログを一時保存する外部記憶装置を備え、運用中の呼制御サーバは常に呼制御ログを外部記憶装置に書き出すというものがある。このシステムでは、運用中の呼制御サーバが故障すると待機中の呼制御サーバに切り替えられる。この切替えにおいて、待機中の呼制御サーバは外部記憶装置に書き込まれた呼制御ログから運用に必要な情報を得るため、運用中の呼制御サーバが故障しても、待機中の呼制御サーバによりIP端末どうしの通信が可能となる(特許文献1)。
従来の呼制御サーバの技術では、外部記憶装置の設置が必要である。また、外部記憶装置に障害が発生した場合には、待機中の呼制御サーバは外部記憶装置に書き込まれた呼制御ログから必要な情報を得ることができずにIP端末どうしの通信ができなくなるという課題があった。
この発明に係る呼制御サーバは、複数のIP端末を制御する呼制御サーバにおいて、第1の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第1の端末情報を前記第1のIP端末から受信すると共に、他の呼制御サーバが制御する第2の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第2の端末情報を前記他の呼制御サーバから転送されて受信する受信部、該受信部で受信した前記第1の端末情報と前記第2の端末情報を記憶する記憶部、前記第2のIP端末から前記第1のIP端末の電話番号を前記受信部で受信すると、前記第1のIP端末の電話番号に対応したアドレス情報を前記記憶部から検索し、前記第1のIP端末から前記第2のIP端末の電話番号を前記受信部で受信すると、前記第2のIP端末の電話番号に対応したアドレス情報を前記記憶部から検索する検索部、該検索部で検索した前記第1のIP端末のアドレス情報を前記第2のIP端末に送信し、前記検索部で検索した前記第2のIP端末のアドレス情報を前記第1のIP端末に送信する送信部、を備えたものである。
この発明は、通常動作時に、他の呼制御サーバから他の呼制御サーバが制御する第2のIP端末の第2の端末情報が転送されることにより、例えば、他の呼制御サーバと第2のIP端末との通信に障害が発生した場合に、第2のIP端末から発信先である第1のIP端末の電話番号を受信し、第1のIP端末から送信されて記憶している第1のIP端末の電話番号に対応するアドレス情報を検索して第2のIP端末に送信するので、外部記憶装置を必要とすることなく、他の呼制御サーバに障害が発生した場合にも、第1のIP端末と第2のIP端末の通信を可能にすることができる。
実施の形態1.
図1は、この発明の実施の形態1おける通信システム1の構成図である。
通信システム1は、SIP端末の電話番号と電話番号に対応するIPアドレスを管理して、SIP端末4a〜4nの呼接続を制御する呼制御サーバ2a及び2b、SIPメッセージや音声パケットなどのIPパケットを伝送するIP網3、音声通信を行うSIP端末4a、4b、〜4nで構成される。
図1は、この発明の実施の形態1おける通信システム1の構成図である。
通信システム1は、SIP端末の電話番号と電話番号に対応するIPアドレスを管理して、SIP端末4a〜4nの呼接続を制御する呼制御サーバ2a及び2b、SIPメッセージや音声パケットなどのIPパケットを伝送するIP網3、音声通信を行うSIP端末4a、4b、〜4nで構成される。
また、図2は、この発明の実施の形態1における通信システム1の呼制御サーバ2(2a,2b)の内部構成図である。
図2において、呼制御サーバ2は、SIPメッセージのリクエスト及び応答の送受信の制御を行うSIPメッセージ送受信部21、SIP端末4の電話番号と電話番号に対応したIPアドレスを含む端末情報を保存する端末情報保存部22、SIPメッセージを転送するかどうかを判定する転送判定部23、SIP端末4の電話番号に対応するIPアドレスを検索するアドレス検索部24から構成される。
図2において、呼制御サーバ2は、SIPメッセージのリクエスト及び応答の送受信の制御を行うSIPメッセージ送受信部21、SIP端末4の電話番号と電話番号に対応したIPアドレスを含む端末情報を保存する端末情報保存部22、SIPメッセージを転送するかどうかを判定する転送判定部23、SIP端末4の電話番号に対応するIPアドレスを検索するアドレス検索部24から構成される。
SIPメッセージ送受信部21のSIPメッセージを受信する部分が受信部に相当し、SIPメッセージを送信する部分が送信部に相当する。また、端末情報保存部22が記憶部に相当し、アドレス検索部24が検索部に相当する。
また、図3は、この発明の実施の形態1における通信システム1のSIPメッセージシーケンスである。
以下、図3に示すメッセージシーケンスを、図2を参照しながら説明する。
尚、以下の説明において、図3に示したSIP端末4aとSIP端末4bには、呼制御サーバ2aと呼制御サーバ2bのIPアドレスが予め設定などにより与えられているものとする。
また、呼制御サーバ2aと呼制御サーバ2bには、互いのIPアドレスが予め設定などにより与えられているものとする。
以下、図3に示すメッセージシーケンスを、図2を参照しながら説明する。
尚、以下の説明において、図3に示したSIP端末4aとSIP端末4bには、呼制御サーバ2aと呼制御サーバ2bのIPアドレスが予め設定などにより与えられているものとする。
また、呼制御サーバ2aと呼制御サーバ2bには、互いのIPアドレスが予め設定などにより与えられているものとする。
SIP端末4aとSIP端末4bが起動すると、呼制御サーバ2aまたは呼制御サーバ2bのどちらかに自端末の電話番号とIPアドレスを含むREGISTERリクエスト(SIP端末4が自端末の端末情報の登録を呼制御サーバ2に要求する登録要求)を送信する。
ここでは、SIP端末4が起動し、呼制御サーバ2にREGISTERリクエストを送信するのは、SIP端末4に電源が投入され、初期設定時にREGISTERリクエストを呼制御サーバ2に送信する場合であるとして説明する。
ここでは、SIP端末4が起動し、呼制御サーバ2にREGISTERリクエストを送信するのは、SIP端末4に電源が投入され、初期設定時にREGISTERリクエストを呼制御サーバ2に送信する場合であるとして説明する。
例えば、SIP端末4aは、自端末を制御する呼制御サーバ2を呼制御サーバ2aと決め、REGISTERリクエストを送信する。
SIP端末4aが自端末を制御する呼制御サーバ2を呼制御サーバ2aと決めるのは、予め設定されているとして説明する。呼制御サーバ2の決め方は、他に、呼制御サーバ2の優先順位のリストを持っていて、リスト順で呼制御サーバ2aを決定するとしてもよい。
SIP端末4aが自端末を制御する呼制御サーバ2を呼制御サーバ2aと決めるのは、予め設定されているとして説明する。呼制御サーバ2の決め方は、他に、呼制御サーバ2の優先順位のリストを持っていて、リスト順で呼制御サーバ2aを決定するとしてもよい。
SIP端末4aが自端末を制御する呼制御サーバ2を呼制御サーバ2aと決め、REGISTERリクエストを送信する際には、REGISTERリクエストの宛先に自端末を制御する呼制御サーバ2aのIPアドレスを指定する。
以上の様に、ここでは、SIP端末4aが起動すると、自端末を制御する呼制御サーバ2を呼制御サーバ2aに決定して呼制御サーバ2aにREGISTERリクエストを送信し、SIP端末4bが起動すると、自端末を管理する呼制御サーバ2を呼制御サーバ2bに決定して呼制御サーバ2bにREGISTERリクエストを送信するものとして説明する。
図3は、SIP端末4a、4bが起動してから、通話開始・完了までのSIPメッセージシーケンスである。
図3に示す通り、SIP端末4aが起動すると、SIP端末4aは、宛先に呼制御サーバ2aのIPアドレスを指定し、自端末の電話番号とIPアドレスを含むREGISTERリクエストを呼制御サーバ2aに送信する。
図3に示す通り、SIP端末4aが起動すると、SIP端末4aは、宛先に呼制御サーバ2aのIPアドレスを指定し、自端末の電話番号とIPアドレスを含むREGISTERリクエストを呼制御サーバ2aに送信する。
また、SIP端末4bが起動すると、SIP端末4bは、宛先に呼制御サーバ2bのIPアドレスを指定し、自端末の電話番号とIPアドレスを含むREGISTERリクエストを呼制御サーバ2bに送信する。
ここで、SIP端末4a、4bが起動して、SIP端末4a、4bが呼制御サーバ2a、及び呼制御サーバ2bにREGISTERリクエストを送信し、呼制御サーバ2a、及び呼制御サーバ2bがREGISTERリクエストを受信した場合の呼制御サーバ2の内部の動作について、図2を用いて説明する。
まず、SIPメッセージ送受信部21が、SIP端末4から受信したリクエストがREGISTERリクエストか否かを判定する。REGISTERリクエストであれば、SIP端末4の電話番号とIPアドレスの端末情報を保存(記憶)するために端末情報保存部(記憶部)22に出力し、同時に転送判定部23に出力する。
次に、端末情報保存部22が、REGISTERリクエストからSIP端末4の電話番号とIPアドレスを抜き出して、SIP端末4の電話番号と電話番号に対応するIPアドレスの端末情報を保存し、応答指示をSIPメッセージ送受信部21に出力する。
次に、SIPメッセージ送受信部21がこの応答指示を受けると、SIP端末4から受信したREGISTERリクエストに対して成功応答(200OK)を生成して、REGISTERリクエストの送信元のSIP端末4に生成した成功応答を送信する。
次に、転送判定部23が、REGISTERリクエストのリクエストライン(例えば、REGISTERリクエストの1行目)を参照して自装置宛のREGISTERリクエストか否かを判定する。
自装置宛のREGISTERリクエストであれば、転送指示をSIPメッセージ送受信部21に出力する。
自装置宛のREGISTERリクエストではなく、他の呼制御サーバから転送されたREGISTERリクエストであれば転送指示は出力しない(何もしない)。
SIPメッセージ送受信部21は、転送判定部23から転送指示を受けると、自装置以外の呼制御サーバ2にREGISTERリクエストを転送する。
自装置宛のREGISTERリクエストではなく、他の呼制御サーバから転送されたREGISTERリクエストであれば転送指示は出力しない(何もしない)。
SIPメッセージ送受信部21は、転送判定部23から転送指示を受けると、自装置以外の呼制御サーバ2にREGISTERリクエストを転送する。
本実施の形態1では、図3に示すように、SIP端末4aから呼制御サーバ2aにREGISTERリクエストを送信し(リクエストラインの宛先に呼制御サーバ2aのIPアドレスを指定し)、呼制御サーバ2aが呼制御サーバ2bにSIP端末4aの端末情報を転送する。また、SIP端末4bから呼制御サーバ4bにREGISTERリクエストを送信し(リクエストラインの宛先に呼制御サーバ2bのIPアドレスを指定し)、呼制御サーバ2bが呼制御サーバ2aにSIP端末4bの端末情報を転送する。
ここで、転送判定部23がREGISTERリクエストを参照して、どのようにREGISTERリクエストが自装置宛であるか否かを判定するか、について説明する。
転送判定部23が自装置宛のREGISTERリクエストか否かを判定するのは、リクエストラインの情報による。
図4は、SIP端末4aが呼制御サーバ2aに対して送信するREGISTERリクエストの内容の例である。
転送判定部23が自装置宛のREGISTERリクエストか否かを判定するのは、リクエストラインの情報による。
図4は、SIP端末4aが呼制御サーバ2aに対して送信するREGISTERリクエストの内容の例である。
このリクエストラインの宛先に、自分自身(自装置、ここでは呼制御サーバ2a)のIPアドレスまたはURI(Uniform Resource Identifiers)が示されていれば、自装置宛てであると判定する。
また、他の呼制御サーバ(呼制御サーバ2b)のIPアドレスが示されていれば、他の呼制御サーバから転送されてきたREGISTERリクエストであると判定する。
また、他の呼制御サーバ(呼制御サーバ2b)のIPアドレスが示されていれば、他の呼制御サーバから転送されてきたREGISTERリクエストであると判定する。
例えば、呼制御サーバ2aのIPアドレスが「192.168.0.1」であって、図4の1行目に示すように、REGISTER sip:192.168.0.1の記述があれば、SIP端末4aから自装置に送信されたREGISTERリクエストであると判定する。
このように、転送判定部23は、REGISTERリクエストを参照してREGISTERリクエストが自装置宛であるか否かを判定する。
このように、転送判定部23は、REGISTERリクエストを参照してREGISTERリクエストが自装置宛であるか否かを判定する。
次に、転送判定部23でREGISTERリクエストが自装置宛に送信されたと判定されると、SIPメッセージ送受信部21が、そのREGISTERリクエストを他の呼制御サーバである呼制御サーバ2bに転送する。
ここで、REGISTERリクエストを転送する処理について説明する。
REGISTERリクエストの転送指示が、転送判定部23からSIPメッセージ送受信部21に入力されると、SIPメッセージ送受信部21は、SIP端末4aから受け取ったREGISTERリクエストに、転送先である呼制御サーバ2bのIPアドレスをパケットのIPヘッダの宛先として付加して呼制御サーバ2bに転送する。
REGISTERリクエストの転送指示が、転送判定部23からSIPメッセージ送受信部21に入力されると、SIPメッセージ送受信部21は、SIP端末4aから受け取ったREGISTERリクエストに、転送先である呼制御サーバ2bのIPアドレスをパケットのIPヘッダの宛先として付加して呼制御サーバ2bに転送する。
REGISTERリクエストを呼制御サーバ2aから転送された呼制御サーバ2bは、REGISTERリクエストのリクエストラインの宛先は自装置(呼制御サーバ2b)宛ではないため、呼制御サーバ2bは受け取りREGISTERリクエストに含まれるIP端末の端末情報を端末情報保存部に記憶し、転送指示は出さない。
このように、転送判定部23は、REGISTERリクエストのリクエストラインの宛先が自装置のIPアドレスであるか否かにより、REGISTERリクエストが自装置宛であるか否かを判定する。
このように、転送判定部23は、REGISTERリクエストのリクエストラインの宛先が自装置のIPアドレスであるか否かにより、REGISTERリクエストが自装置宛であるか否かを判定する。
REGISTERリクエストが自装置宛であれば、そのREGISTERリクエストを他の制御サーバ2bに転送する転送指示をSIPメッセージ送受信部21に出力する。
一方、REGISTERリクエストが自装置宛でなければ(他の呼制御サーバ2から転送されたものであれば)、REGISTERリクエストの転送指示は出力せず何もしない。
ここまでが、自装置宛に送信されたREGISTERリクエストを呼制御サーバ2aが受信した場合の呼制御サーバ2aの内部の動作の説明である。
一方、REGISTERリクエストが自装置宛でなければ(他の呼制御サーバ2から転送されたものであれば)、REGISTERリクエストの転送指示は出力せず何もしない。
ここまでが、自装置宛に送信されたREGISTERリクエストを呼制御サーバ2aが受信した場合の呼制御サーバ2aの内部の動作の説明である。
次に、図3を用いて、呼制御サーバ2がSIP端末4からREGISTERリクエストを受信した時の呼制御サーバ2とIP端末4の動作について説明する。
呼制御サーバ2aがSIP端末4aからREGISTERリクエストを受信すると、呼制御サーバ2aはその成功応答(200 OK)をSIP端末4aに送信すると共に、このREGISTERリクエスト(SIP端末4aの端末情報を含む)を呼制御サーバ2bに転送する。
この時、呼制御サーバ2aの内部の処理では、SIP端末4aの端末情報を図2の端末情報保存部22に保存する。
呼制御サーバ2aがSIP端末4aからREGISTERリクエストを受信すると、呼制御サーバ2aはその成功応答(200 OK)をSIP端末4aに送信すると共に、このREGISTERリクエスト(SIP端末4aの端末情報を含む)を呼制御サーバ2bに転送する。
この時、呼制御サーバ2aの内部の処理では、SIP端末4aの端末情報を図2の端末情報保存部22に保存する。
そして、呼制御サーバ2bは、呼制御サーバ2aから転送されたSIP端末4aのREGISTERリクエストに対して成功応答(200 OK)を呼制御サーバ2aに返す。
この時、呼制御サーバ2bの内部の処理では、呼制御サーバ2aから転送されたSIP端末4aの端末情報を図2の端末情報保存部22に保存する。
この時、呼制御サーバ2bの内部の処理では、呼制御サーバ2aから転送されたSIP端末4aの端末情報を図2の端末情報保存部22に保存する。
同様に、呼制御サーバ2bがSIP端4bからREGISTERリクエストを受信すると、呼制御サーバ2bはその成功応答(200 OK)をSIP端末4bに送信すると共に、このREGISTERリクエスト(SIP端末4bの端末情報を含む)を呼制御サーバ2aに転送する。
この時、呼制御サーバ2bの内部の処理では、SIP端末4bの端末情報を図2の端末情報保存部22に保存する。
この時、呼制御サーバ2bの内部の処理では、SIP端末4bの端末情報を図2の端末情報保存部22に保存する。
そして、呼制御サーバ2aは、呼制御サーバ2bから転送されたSIP端末4bからのREGISTERリクエストに対して成功応答(200 OK)を呼制御サーバ2bに返す。
この時、呼制御サーバ2aの内部の処理では、呼制御サーバ2bから転送されたSIP端末4bの端末情報を端末情報保存部22に保存する。
この時、呼制御サーバ2aの内部の処理では、呼制御サーバ2bから転送されたSIP端末4bの端末情報を端末情報保存部22に保存する。
このように呼制御サーバ2aと呼制御サーバ2bが、SIP端末4aとSIP端末4bから受信した端末情報をお互いに転送することで、呼制御サーバ2a及び呼制御サーバ2bは、SIP端末4aとSIP端末4bの両方のアドレス情報(端末情報)を保持(記憶)することになる。
次に、図3で、SIP端末4aからSIP端末4bに対して発信する場合について説明する。
SIP端末4aは、発信先であるSIP端末4bのIPアドレスを得るため、図3に示す通りINVITEリクエスト(SIP端末4が他のSIP端末4との通信を要求する通信要求)を呼制御サーバ2aに送信する。
尚、このINVITEリクエスト(通信要求)のリクエストライン(1行目)には発信先(通信要求先)の電話番号が含まれる。
SIP端末4aは、発信先であるSIP端末4bのIPアドレスを得るため、図3に示す通りINVITEリクエスト(SIP端末4が他のSIP端末4との通信を要求する通信要求)を呼制御サーバ2aに送信する。
尚、このINVITEリクエスト(通信要求)のリクエストライン(1行目)には発信先(通信要求先)の電話番号が含まれる。
ここで、呼制御サーバ2aがSIP端末4aからINVITEリクエストを受信した場合の呼制御サーバ2の内部の動作について、図2を用いて説明する。
SIPメッセージ送受信部21は、SIP端末4aから受信したリクエストがINVITEリクエストか否かを判定する。INVITEリクエストであれば、これをアドレス検索部24に出力する。
SIPメッセージ送受信部21は、SIP端末4aから受信したリクエストがINVITEリクエストか否かを判定する。INVITEリクエストであれば、これをアドレス検索部24に出力する。
アドレス検索部24は、INVITEリクエストから発信先の電話番号を抜き出し(抽出し)、端末情報保存部22に保存(記憶)されたアドレス情報(端末情報)を参照して、発信先の電話番号に対応したIPアドレスを検索する。
前述したように、端末情報保存部22には、SIP端末4aとSIP端末4bの端末情報が保存されている。そのため、アドレス検索部24は、端末情報保存部22に保存されているアドレス情報から発信先のSIP端末4bの電番号に対応するIPアドレス(発信先IPアドレス)を検索してSIPメッセージ送受信部21に出力する。
SIPメッセージ送受信部21は、アドレス検索部24から入力された発信先IPアドレスを用いてリダイレクト応答(300 Multiple Choices)を生成し、SIP端末4aに送信する。
尚、発信先IPアドレスは、この「300 Multiple Choices」応答のContactヘッダに含めて、SIP端末4aに送信される。
尚、発信先IPアドレスは、この「300 Multiple Choices」応答のContactヘッダに含めて、SIP端末4aに送信される。
呼制御サーバ2aが上記の通り動作すると、図3に示す通り、SIP端末4aからINVITEリクエストを受信した呼制御サーバ2aは、発信先IPアドレス(SIP端末4bのIPアドレス)を含めた応答(300 Multiple Choices)をSIP端末4aに送信する。
このような、呼制御サーバ2aの内部の動作の概略を説明すると、以下のようになる。
(1)INVITEリクエストが、図2のSIPメッセージ送受信部21からアドレス検索部24に入力される。
(2)アドレス検索部24が、INVITEリクエストから発信先のSIP端末4bの電話番号を抽出する。
(1)INVITEリクエストが、図2のSIPメッセージ送受信部21からアドレス検索部24に入力される。
(2)アドレス検索部24が、INVITEリクエストから発信先のSIP端末4bの電話番号を抽出する。
(3)アドレス検索部24が、発信先のSIP端末4bの電話番号に対応するIPアドレスを検索する。検索する際には、呼制御サーバ2bから転送されて端末情報保存部22に保存されているSIP端末4bの端末情報を参照する。
(4)アドレス検索部24が、検索した発信先のSIP端末4bのIPアドレスをSIPメッセージ送受信部21に出力する。
(4)アドレス検索部24が、検索した発信先のSIP端末4bのIPアドレスをSIPメッセージ送受信部21に出力する。
(5)SIPメッセージ送受信部21が、Contactヘッダに発信先IPアドレス(SIP端末4bのIPアドレス)を含めた応答(300 Multiple Choices)をSIP端末4aに送信する
この様に、呼制御サーバ2aは、呼制御サーバ2bから転送されて記憶している発信先のSIP端末4bの端末情報を参照して、発信先のSIP端末4bの電話番号に対応するIPアドレスをSIP端末4aへの応答に含めて送信する。
すると、SIP端末4aは、呼制御サーバ2aからの応答(300 Multiple Choices)を受信したことを通知するACKリクエストを呼制御サーバ2aに送信する。
次に、SIP端末4aは、呼制御サーバ2aから受信した応答の中のContactヘッダに含まれるIPアドレスに対して(つまりSIP端末4bに対して)、新たなINVITEリクエストを送信する。
以降は、SIPの規定に従い、SIP端末4bが応答(200 OK)を返し、これに対してSIP端末4aがACKリクエストをSIP端末4bに送信することで、呼接続が完了する。このように、呼接続が完了することで、通話が開始される(音声パケットの送受信が開始される(セッションの確立))。
ここまでが、呼制御サーバ2が通常に機能している場合のSIP端末4と呼制御サーバ2との動作である。
ここまでが、呼制御サーバ2が通常に機能している場合のSIP端末4と呼制御サーバ2との動作である。
次に、呼制御サーバ2が故障した場合のSIP端末4と他の呼制御サーバ2(呼制御サーバ2b)との動作について説明する。
図5は、SIP端末4aがSIP端末4bに対して発信する前に、呼制御サーバ2aが故障した場合のSIPメッセージシーケンスである。
SIP端末4aは、発信先であるSIP端末4bのIPアドレスを得るため、発信先のSIP端末4bの電話番号を含めたINVITEリクエストを呼制御サーバ2aに送信する。
図5は、SIP端末4aがSIP端末4bに対して発信する前に、呼制御サーバ2aが故障した場合のSIPメッセージシーケンスである。
SIP端末4aは、発信先であるSIP端末4bのIPアドレスを得るため、発信先のSIP端末4bの電話番号を含めたINVITEリクエストを呼制御サーバ2aに送信する。
しかし、呼制御サーバ2aが故障したため応答が得られず、INVITEリクエストを再送するが、呼制御サーバ2aからの応答がない状態で最終的にタイムアウトになる(呼制御サーバ2aから所定の時間応答がない状態となる)。SIPの規定では標準的に32秒経つとタイムアウトとするため、SIP端末4aが呼制御サーバ2aを故障と判定する。
SIP端末4aは、呼制御サーバ2aへのINVITEリクエストの送信に対する応答のない状態でタイムアウトになると、呼制御サーバ2bにINVITEリクエストを送信する。
即ち、呼制御サーバ2bが、呼制御サーバ2aに制御されているSIP端末4aからINVITEリクエストを受信するのは、SIP端末4aが呼制御サーバ2aを故障と判定した場合となる。
即ち、呼制御サーバ2bが、呼制御サーバ2aに制御されているSIP端末4aからINVITEリクエストを受信するのは、SIP端末4aが呼制御サーバ2aを故障と判定した場合となる。
SIP端末4aからINVITEリクエストを受信した呼制御サーバ2bにも、呼制御サーバ2aと同じアドレス情報が保存されている(呼制御サーバ2aからSIP端末4aの端末情報が転送され、保存されている)。そのため、呼制御サーバ2bは、SIP端末4aから受信した発信先(SIP端末4b)の電話番号に対応するIPアドレス情報を検索し、検索した発信先のSIP端末4bのIPアドレスを含む応答(300 Multiple Choices)をSIP端末4aに返す。
この応答を受けることで、SIP端末4aは発信先(SIP端末4b)のIPアドレスを得る。
以降は、図3と同様なSIPメッセージシーケンスによりSIP端末4aとSIP端末4bとの呼接続が行われる。(SIP端末4aとSIP端末4bとのセッションが確立され音声パケットの送受信が可能になる。)
以降は、図3と同様なSIPメッセージシーケンスによりSIP端末4aとSIP端末4bとの呼接続が行われる。(SIP端末4aとSIP端末4bとのセッションが確立され音声パケットの送受信が可能になる。)
この様な動作をまとめると、SIP端末4aが自端末の端末情報を含めたREGISTERリクエストを呼制御サーバ2aに送信することにより、SIP端末4aは呼制御サーバ2aに制御される。
また、SIP端末4bが自端末の端末情報を含めたREGISTERリクエストを呼制御サーバ2aに送信すると、SIP端末4bは呼制御サーバ4bに制御される。
このような状況で、SIP端末4aがSIP端末4bとの通信を要求する場合、呼制御サーバ2aが正常に動作していれば、SIP端末4aは、発信先のSIP端末4bの電話番号を含めたINVITEリクエストを呼制御サーバ2aに送信する。
また、SIP端末4bが自端末の端末情報を含めたREGISTERリクエストを呼制御サーバ2aに送信すると、SIP端末4bは呼制御サーバ4bに制御される。
このような状況で、SIP端末4aがSIP端末4bとの通信を要求する場合、呼制御サーバ2aが正常に動作していれば、SIP端末4aは、発信先のSIP端末4bの電話番号を含めたINVITEリクエストを呼制御サーバ2aに送信する。
すると、呼制御サーバ2aは、呼制御サーバ2bから転送されて記憶しているSIP端末4bの電話番号に対するIPアドレスを検索して、発信先のSIP端末4bの電話番号に対応するIPアドレスを含めた応答をSIP端末4aに送信する。
もし、呼制御サーバ2aに障害が発生、または呼制御サーバ2aとSIP端末4aとの通信に障害が発生して、SIP端末4aがINVITEリクエストに対する応答を呼制御サーバ2aから受け取ることができなければ、SIP端末4aは発信先のSIP端末4bの電話番号を含むINVITEリクエストを呼制御サーバ2bに送信する。
呼制御サーバ2b側から説明すると、呼制御サーバ2bは、他の呼制御サーバである呼制御サーバ2aに制御されているSIP端末4aから発信先の電話番号(自装置が制御しているSIP端末4bの電話番号)を含むINVITEリクエストを受信する。
すると、呼制御サーバ2bは、自装置が制御するSIP端末4bから受け取り、記憶している端末情報に基づいて、SIP端末4bの電話番号に対応したIPアドレスを検索して、発信先のSIP端末4bの電話番号に対応するIPアドレスを含めた応答をSIP端末4aに送信する。
そのため、例えば、呼制御サーバ4aに故障などの障害が発生、または呼制御サーバ2aとSIP端末4aとの通信に障害が発生しても、SIP端末4aは発信先のSIP端末4bと呼接続を継続することができる。
以上のように、本実施の形態によれば、呼制御サーバ2a、2bはSIP端末4a、4bから受信したREGISTERリクエストを他の呼制御サーバに転送するため、呼制御サーバが全てのSIP端末4のアドレス情報(端末情報)を保存(記憶)することができる。
更に、SIP端末4aは、発信先であるSIP端末4bとの通信を要求する際に、INVITEリクエストを呼制御サーバ2aに送信して、呼制御サーバ2aから応答がない場合に、呼制御サーバ2bにINVITEリクエスト(発信先のSIP端末4bの電話番号を含む)を送信する。そして、呼制御サーバ2bから発信先のSIP端末4bの電話番号に対応するIPアドレスを受け取り、呼接続を継続することが出来る。
そのため、例えば、呼制御サーバ2aが故障、あるは呼制御サーバ2aとの通信に障害が発生しても、外部記憶装置や故障を監視する装置等を必要とせずに、呼制御サーバ2bが呼制御サーバ2aの代わり呼制御を継続することができる。
また、SIP端末4aから呼制御サーバ2aに送信したINVITEリクエストに対して所定の時間応答がない場合に、他の呼制御サーバである呼制御サーバ2bにINVITEリクエストを送信するため、例えば、SIP端末4aと呼制御サーバ2aとの間に通信の障害が発生した場合にも、呼制御を継続することができる。
このように、呼制御サーバ2aが故障、あるは呼制御サーバ2aとの通信に障害が発生しても、呼接続を継続することができるため、システム停止となる可能性が低く、信頼性の高い通信システム及び呼制御サーバを得ることが出来る。
また、SIP端末4aから呼制御サーバ2aに送信したINVITEリクエストに対して所定の時間応答がない場合に、他の呼制御サーバである呼制御サーバ2bにINVITEリクエストを送信するため、例えば、SIP端末4aと呼制御サーバ2aとの間に通信の障害が発生した場合にも、呼制御を継続することができる。
このように、呼制御サーバ2aが故障、あるは呼制御サーバ2aとの通信に障害が発生しても、呼接続を継続することができるため、システム停止となる可能性が低く、信頼性の高い通信システム及び呼制御サーバを得ることが出来る。
尚、SIP端末4がREGISTERリクエストを送信する呼制御サーバ2は、例えば優先順位で呼制御サーバ2のIPアドレスをリストとして保持しており、そのリスト順に従って呼制御サーバ2のIPアドレスにREGISTERリクエストを送信するとしてもよい。もし、REGISTERリクエストの送信が上手くいかなければ、リストの次の呼制御サーバ2のIPアドレスにREGISTERリクエストを送信することになる。
また、呼制御サーバ2aが制御するSIP端末4a1とSIP端末4a2があり、例えば呼制御サーバ2aにSIP端末4a2との通信を要求するINVITEリクエストを送信して、所定の時間応答がない場合に、SIP端末4a1が呼制御サーバ2aを故障と判定する。そして、SIP端末4a1がSIP端末4a2との通信を要求するINVITEリクエストを呼制御サーバ2bに送信してきた場合にも、呼制御サーバ2aから転送されてSIP端末4a2の端末情報を記憶している呼制御サーバ2bは、SIP端末4a2の電話番号に対応したIPアドレスをSIP端末4a1に送信する。そのため呼制御サーバ2aが故障と判定されても、その呼制御サーバ2aが制御するSIP端末4aどうしの通信を制御することができる。
実施の形態2.
実施の形態1では、SIP端末4が呼制御サーバ2にINVITEリクエストを送信し、その応答から発信先SIP端末4のIPアドレスを得て、発信先SIP端末4に新たなINVITEリクエストを送信したが、サーバ側にINVITEリクエストを転送する機能があっても良い。
その場合、図3に示したシーケンスは図6に示すように変わり、図5に示したシーケンスは図7に示すように変わる。
実施の形態1では、SIP端末4が呼制御サーバ2にINVITEリクエストを送信し、その応答から発信先SIP端末4のIPアドレスを得て、発信先SIP端末4に新たなINVITEリクエストを送信したが、サーバ側にINVITEリクエストを転送する機能があっても良い。
その場合、図3に示したシーケンスは図6に示すように変わり、図5に示したシーケンスは図7に示すように変わる。
図6は、呼制御サーバ2にINVITEリクエストを転送する機能がある場合に、SIP端末4aと4bが起動してから、発信元のSIP端末4aと発信先のSIP端末4bの通話を開始して完了するまでのSIPメッセージシーケンスである。
また、図7は、呼制御サーバ2にINVITEリクエストを転送する機能がある場合であって、SIP端末4aがSIP端末4bに対して発信する前に、呼制御サーバ2aが故障した場合のSIPメッセージシーケンスである。
図6において、SIP端末4aが発信先であるSIP端末4bのIPアドレスを得るために、INVITEリクエストを呼制御サーバ2aに送信するところまでは、実施の形態1の図3と同様である。
また、図7は、呼制御サーバ2にINVITEリクエストを転送する機能がある場合であって、SIP端末4aがSIP端末4bに対して発信する前に、呼制御サーバ2aが故障した場合のSIPメッセージシーケンスである。
図6において、SIP端末4aが発信先であるSIP端末4bのIPアドレスを得るために、INVITEリクエストを呼制御サーバ2aに送信するところまでは、実施の形態1の図3と同様である。
この時の呼制御サーバ2aの内部の動作について図2を用いて説明する。
(1)SIP端末4aから送信されたINVITEリクエストをSIPメッセージ送受信部21で受信し、SIPメッセージ送受信部21から入力されたINVITEリクエストに含まれる発信先のSIP端末4bの電話番号をアドレス検索部24が抽出する。
(2)抽出したSIP端末4bの電話番号に対応するIPアドレスを端末情報保存部22から取得する。呼制御サーバ2aは、呼制御サーバ2bから転送されてSIP端末4bの端末情報を端末情報保存部22に保存している。そのため、SIP端末4bの電話番号に対応するIPアドレスを端末情報保存部22から検索して取得することができる。
(1)SIP端末4aから送信されたINVITEリクエストをSIPメッセージ送受信部21で受信し、SIPメッセージ送受信部21から入力されたINVITEリクエストに含まれる発信先のSIP端末4bの電話番号をアドレス検索部24が抽出する。
(2)抽出したSIP端末4bの電話番号に対応するIPアドレスを端末情報保存部22から取得する。呼制御サーバ2aは、呼制御サーバ2bから転送されてSIP端末4bの端末情報を端末情報保存部22に保存している。そのため、SIP端末4bの電話番号に対応するIPアドレスを端末情報保存部22から検索して取得することができる。
(3)取得したSIP端末4bの電話番号に対応するIPアドレスに従って、SIP端末4bにINVITEリクエストをSIPメッセージ送受信部21から送信し、SIP端末4bから応答(200 OK)をSIPメッセージ送受信部21が受信する。この応答には、SIP端末4bのIPアドレスが含まれている。
(4)更に、SIP端末4aに応答(200 OK)をSIPメッセージ送受信部21から送信。この応答に、SIP端末4bのIPアドレスが含まれている。
ここまでが、呼制御サーバ2aの内部の動作である。
(4)更に、SIP端末4aに応答(200 OK)をSIPメッセージ送受信部21から送信。この応答に、SIP端末4bのIPアドレスが含まれている。
ここまでが、呼制御サーバ2aの内部の動作である。
このように、呼制御サーバ2aからSIP端末4aにSIP端末4bのIPアドレスが含まれる応答(200 OK)が送信されると、SIP端末4aは、応答を受信したことを通知するACKリクエストを呼制御サーバ2aに送信する。
そして、更に、呼制御サーバ4aは、SIP端末4aからの応答を受信したことを通知するACKリクエストをSIP端末4bに送信することで、呼接続が完了し、SIP端末4aとSIP端末4bとの通話が開始される(セッションが確立され、音声パケットの送受信が開始される)。
そして、更に、呼制御サーバ4aは、SIP端末4aからの応答を受信したことを通知するACKリクエストをSIP端末4bに送信することで、呼接続が完了し、SIP端末4aとSIP端末4bとの通話が開始される(セッションが確立され、音声パケットの送受信が開始される)。
本実施の形態によっても、呼制御サーバ2aと2bは、SIP端末4aとSIP端末4bから受信したREGISTERリクエストを他の呼制御サーバに転送する。そのため、呼制御サーバ2aと呼制御サーバ2bのそれぞれが制御している全てのSIP端末4(図1のSIP端末4a〜4n)のアドレス情報を保存することが可能となる。
そして、SIP端末4aがSIP端末4bへの発信時に、例えば、図7のように、呼制御サーバ2aにSIP端末4aがINVITEリクエストを送信しても呼制御サーバ2aからの応答がなく、呼制御サーバ2aが故障であると判定した場合に、他の呼制御サーバである呼制御サーバ2bにINVITEリクエストを送信する。そうすることにより、呼接続を継続することが出来る。従って、呼制御サーバが故障してもシステム停止となる可能性が低く、信頼性の高い通信システムおよび呼制御サーバを得ることが出来る。
実施の形態3.
上記実施の形態1では、呼制御サーバ2aが故障した場合、SIP端末4aが呼制御サーバ2aにINVITEリクエストを送信して、その応答を呼制御サーバ2aから受信しようとして、受信できない状態でタイムアウトになると、SIP端末4aは呼制御サーバ2aを故障と判定して、呼制御サーバ2bへのINVITEリクエスト送信に切替える。そのため、タイムアウトになるまでの呼接続時間が長くなる。
本実施の形態においては、呼制御サーバ2aが故障した時の呼接続時間を短くする実施形態を示す。
上記実施の形態1では、呼制御サーバ2aが故障した場合、SIP端末4aが呼制御サーバ2aにINVITEリクエストを送信して、その応答を呼制御サーバ2aから受信しようとして、受信できない状態でタイムアウトになると、SIP端末4aは呼制御サーバ2aを故障と判定して、呼制御サーバ2bへのINVITEリクエスト送信に切替える。そのため、タイムアウトになるまでの呼接続時間が長くなる。
本実施の形態においては、呼制御サーバ2aが故障した時の呼接続時間を短くする実施形態を示す。
図8は、この発明の実施の形態3における通信システム1のSIPメッセージシーケンスである。
この図は、SIP端末4aからSIP端末4bに発信する際に、SIP端末4aが呼制御サーバ2aを故障と判定して、呼制御サーバ2bにINVITEリクエストを送信することで、SIP端末4aとSIP端末4bとの呼接続及び呼切断が完了するまでのシーケンスである。
SIP端末4aがSIP端末4bにINVITEリクエストを送信して応答を受信し、ACKリクエストを送信するまでは、図5に示したシーケンスと同様である。
但し、SIP端末4aが、呼制御サーバ2bに送信するINVITEリクエスト内に、呼制御サーバ2aが故障したことを通知する情報を含める点が図5の場合と異なる。
この図は、SIP端末4aからSIP端末4bに発信する際に、SIP端末4aが呼制御サーバ2aを故障と判定して、呼制御サーバ2bにINVITEリクエストを送信することで、SIP端末4aとSIP端末4bとの呼接続及び呼切断が完了するまでのシーケンスである。
SIP端末4aがSIP端末4bにINVITEリクエストを送信して応答を受信し、ACKリクエストを送信するまでは、図5に示したシーケンスと同様である。
但し、SIP端末4aが、呼制御サーバ2bに送信するINVITEリクエスト内に、呼制御サーバ2aが故障したことを通知する情報を含める点が図5の場合と異なる。
図9は、SIP端末4aがSIP端末4bに発信する場合に、SIP端末4aが呼制御サーバ2bに対して送信するINVITEリクエストの内容を示している。
これに対して、図10は、図9で示したINVITEリクエストに、呼制御サーバ2aが故障したことを通知する故障サーバ情報を含めた内容を示している。
これに対して、図10は、図9で示したINVITEリクエストに、呼制御サーバ2aが故障したことを通知する故障サーバ情報を含めた内容を示している。
これらの図は、呼制御サーバ2aのIPアドレスが「192.168.0.1」、呼制御サーバ2bのIPアドレスが「192.168.0.2」、SIP端末4aのIPアドレスが「192.168.0.31」、SIP端末4bのIPアドレスが「192.168.0.32」である場合の例である。
図10の9行目には、図9に示した内容にOrganizationヘッダが追加されている。Organizationヘッダには故障サーバ情報「server fault 192.168.0.1」(192.168.0.1が故障した呼制御サーバ2aのIPアドレス)が含まれている。
図10の9行目には、図9に示した内容にOrganizationヘッダが追加されている。Organizationヘッダには故障サーバ情報「server fault 192.168.0.1」(192.168.0.1が故障した呼制御サーバ2aのIPアドレス)が含まれている。
このヘッダは、INVITEリクエストに含めることが出来るオプションのヘッダであり、通常はリクエストを送信する端末が所属する組織名などを提供するために用いられるが、SIP規定において呼制御に直接関わるヘッダではなく、任意の文章や文字列を含むことが出来る。
そこで、このINIVITEリクエストでは、Organizationヘッダによって、サーバが故障したことと、故障したサーバのIPアドレスを通知する。
そこで、このINIVITEリクエストでは、Organizationヘッダによって、サーバが故障したことと、故障したサーバのIPアドレスを通知する。
次に、図10に示した故障サーバ情報を含むINVITEリクエストを呼制御サーバ2が受けた場合の動作について、図11に示す呼制御サーバ2の内部構成図を用いて説明する。
図11は、実施の形態3における呼制御サーバ2の内部構成図である。
図11の呼制御サーバ2の内部構成は、実施の形態1で示した図2の内部構成に故障サーバ情報抽出部25が追加されたものである。また、図11のSIPメッセージ送受信部21の動作は、図2に示したSIPメッセージ送受信部21と異なる。
図11の端末情報保存部22、転送判定部23、アドレス検索部24の動作については、図2に示した呼制御サーバ2の内部構成の場合と同様である。
図11は、実施の形態3における呼制御サーバ2の内部構成図である。
図11の呼制御サーバ2の内部構成は、実施の形態1で示した図2の内部構成に故障サーバ情報抽出部25が追加されたものである。また、図11のSIPメッセージ送受信部21の動作は、図2に示したSIPメッセージ送受信部21と異なる。
図11の端末情報保存部22、転送判定部23、アドレス検索部24の動作については、図2に示した呼制御サーバ2の内部構成の場合と同様である。
SIPメッセージ送受信部21は、受信したリクエストがINVITEリクエストか否かを判定し、INVITEリクエストであればこれをアドレス検索部24に出力すると共に、故障サーバ情報抽出部25にも出力する。
または、受信したリクエストがREGISTERリクエストか否かを判定し、REGISTERリクエストであればこれを端末情報保存部22と転送判定部23に出力すると共に、故障サーバ情報抽出部25にも出力する。
故障サーバ情報抽出部25は、SIPメッセージ送受信部21で受信した受信リクエストの中から故障したサーバの情報を抽出する。
または、受信したリクエストがREGISTERリクエストか否かを判定し、REGISTERリクエストであればこれを端末情報保存部22と転送判定部23に出力すると共に、故障サーバ情報抽出部25にも出力する。
故障サーバ情報抽出部25は、SIPメッセージ送受信部21で受信した受信リクエストの中から故障したサーバの情報を抽出する。
故障サーバ情報抽出部25は、INVITEリクエスト及びREGISTERリクエスト中にOrganizationヘッダがあるか否かを検索し、これが無ければ何もしない。
Organizationヘッダがある場合は、Organizationヘッダの内容を故障サーバ情報とし、更に、端末情報保存部22に保存されている全てのアドレス情報の中からこのリクエストの発信元以外のIPアドレスを抜き出して、このIPアドレスを送信先のアドレス情報とし、これらの故障サーバ情報と送信先のアドレス情報をSIPメッセージ送受信部21に出力する。
Organizationヘッダがある場合は、Organizationヘッダの内容を故障サーバ情報とし、更に、端末情報保存部22に保存されている全てのアドレス情報の中からこのリクエストの発信元以外のIPアドレスを抜き出して、このIPアドレスを送信先のアドレス情報とし、これらの故障サーバ情報と送信先のアドレス情報をSIPメッセージ送受信部21に出力する。
SIPメッセージ送受信部21は、故障サーバ情報抽出部25から故障サーバ情報と送信先のアドレス情報を受けると、送信先のアドレス情報で指定される全てのSIP端末4に対して故障サーバ情報を含めたINFOリクエストを送信する。
以上が呼制御サーバ2の内部の動作である。
呼制御サーバ2bが以上のように動作すると、図8に示すシーケンスにおいて、呼制御サーバ2bはSIP端末4aからINVITEリクエストを受けた後、INFOリクエストをSIP端末4bに送信する。
以上が呼制御サーバ2の内部の動作である。
呼制御サーバ2bが以上のように動作すると、図8に示すシーケンスにおいて、呼制御サーバ2bはSIP端末4aからINVITEリクエストを受けた後、INFOリクエストをSIP端末4bに送信する。
図12は、呼制御サーバ2bがSIP端末4aからINVITEリクエストを受けて、呼制御サーバ2aがSIP端末4bに送信する故障サーバ情報を含めたINFOリクエストの内容を示している。
このINFOリクエストにもOrganizationヘッダが含まれており、SIP端末4bは呼制御サーバ2aの故障を知ることが出来る。
このINFOリクエストにもOrganizationヘッダが含まれており、SIP端末4bは呼制御サーバ2aの故障を知ることが出来る。
上述のように、SIP端末4aから呼制御サーバ2aへ送信したINVITEリクエストに対して呼制御サーバ2aからの応答がない状態でタイムアウトになれば、IP端末4aは呼制御サーバ2aが故障していると判定し、SIP端末4aは呼制御サーバ4bに故障サーバ情報を送信する。すると、故障サーバ情報を含むINFOリクエストが呼制御サーバ2bからSIP端末4bに送信される。そのため、SIP端末4bは呼制御サーバ2aの故障を認識(検出)することが出来る。
以降、SIP端末4aおよびSIP端末4bは、SIP端末4aが故障と判定した呼制御サーバ2aにINVITEリクエストを送信せず、呼制御サーバ2bに送信するので、呼接続時間が長くならない。
以降、SIP端末4aおよびSIP端末4bは、SIP端末4aが故障と判定した呼制御サーバ2aにINVITEリクエストを送信せず、呼制御サーバ2bに送信するので、呼接続時間が長くならない。
尚、SIP端末4が呼制御サーバ2に送信するREGISTERリクエストによるアドレス情報には、通常、有効期限があり、これが失効する前に再度REGISTERリクエストの送信が行われる。
従って、SIP端末4がこのような有効期限の失効により再度REGISTERリクエストを送信する際に、呼制御サーバ2からの応答がない状態でタイムアウトになった場合にも、呼制御サーバ2の故障と認識(判定)する。そして、この故障サーバ情報を他の呼制御サーバ2に通知し、通知された呼制御サーバ2は、故障サーバ情報を送信してきたSIP端末4を除く全てのSIP端末4に故障サーバ情報を通知する。
従って、SIP端末4がこのような有効期限の失効により再度REGISTERリクエストを送信する際に、呼制御サーバ2からの応答がない状態でタイムアウトになった場合にも、呼制御サーバ2の故障と認識(判定)する。そして、この故障サーバ情報を他の呼制御サーバ2に通知し、通知された呼制御サーバ2は、故障サーバ情報を送信してきたSIP端末4を除く全てのSIP端末4に故障サーバ情報を通知する。
図13は、SIP端末4aがREGISTERリクエストを呼制御サーバ2aに再送信する際にサーバの故障を認識した場合のSIPメッセージシーケンスである。
SIP端末4aはREGISTERリクエストの再送信によって呼制御サーバ2aの故障を認識し、呼制御サーバ2bにREGISTERリクエストを送信する際、呼制御サーバ2aの故障を通知する。
SIP端末4aはREGISTERリクエストの再送信によって呼制御サーバ2aの故障を認識し、呼制御サーバ2bにREGISTERリクエストを送信する際、呼制御サーバ2aの故障を通知する。
通知の方法は、上記INVITEリクエスト送信の場合と同様であり、Organizationヘッダによって通知する。
呼制御サーバ2bは、このREGISTERリクエストを受信することによって呼制御サーバ2aの故障を認識し、SIP端末4bに対してINFOリクエストを送信することによってこの故障を通知する。
呼制御サーバ2bは、このREGISTERリクエストを受信することによって呼制御サーバ2aの故障を認識し、SIP端末4bに対してINFOリクエストを送信することによってこの故障を通知する。
以上のように、本実施の形態によれば、SIP端末4aが呼制御サーバ2aへ送信するINVITEリクエストまたはREGISTERリクエストに対する応答がない状態でタイムアウトになると、SIP端末4aが呼制御サーバ2aを故障と判定する。すると、故障と判定した呼制御サーバのIPアドレスを含む故障サーバ情報を他の呼制御サーバ2bに通知する。そして、この通知を受けた呼制御サーバ2bは、端末情報保存部22に保存しているSIP端末4のIPアドレスのうち故障サーバ情報を送信してきたSIP端末4aを除くSIP端末4に、故障サーバ情報を通知する。そのため、SIP端末4aを除く他のSIP端末4は、以降、INVITEリクエストを故障したサーバに送信しなくて済む。
従って、実施の形態1と同様に、呼制御サーバ2が故障、あるは呼制御サーバ2aとの通信に障害が発生しても、呼制御サーバ2の外部記憶装置や故障を監視する装置等を必要とせずに呼接続を継続することができる。そのため、システム停止となる可能性が低く、信頼性の高い通信システム1および呼制御サーバ2を得ることが出来る。
更に、SIP端末4aが呼制御サーバ2aを故障と判定すると、故障と判定した呼制御サーバ2aのIPアドレスを含む故障サーバ情報をINFOリクエストとして故障していない呼制御サーバ2bに送信し、呼制御サーバ2bがSIP端末4aを除く他のSIP端末4に故障サーバ情報を送信するため、他のSIP端末4から故障した呼制御サーバ2への呼接続時間が長くなることを防止することができる。
更に、SIP端末4aが呼制御サーバ2aを故障と判定すると、故障と判定した呼制御サーバ2aのIPアドレスを含む故障サーバ情報をINFOリクエストとして故障していない呼制御サーバ2bに送信し、呼制御サーバ2bがSIP端末4aを除く他のSIP端末4に故障サーバ情報を送信するため、他のSIP端末4から故障した呼制御サーバ2への呼接続時間が長くなることを防止することができる。
実施の形態4.
呼制御サーバ2bがSIP端末4bから受信したREGISTERリクエストを他の呼制御サーバ2aに転送する時、REGISTERリクエストの応答がない状態でタイムアウトになることにより、転送先の呼制御サーバ2aの故障を認識(故障と判定)することが出来る。
本実施の形態においては、呼制御サーバ2bが他の呼制御サーバ2aの故障を検出し、その故障を検出した呼制御サーバ2aのIPアドレスを含む故障サーバ情報を実施の形態3の図11で説明した故障サーバ情報抽出部25が作成して、全てのSIP端末4に通知する実施の形態を示す。
ここでは、故障サーバ情報抽出部25が故障サーバ情報を生成するとして説明するが、故障サーバ情報生成部が故障サーバ情報を生成するとしてもよい。
呼制御サーバ2bがSIP端末4bから受信したREGISTERリクエストを他の呼制御サーバ2aに転送する時、REGISTERリクエストの応答がない状態でタイムアウトになることにより、転送先の呼制御サーバ2aの故障を認識(故障と判定)することが出来る。
本実施の形態においては、呼制御サーバ2bが他の呼制御サーバ2aの故障を検出し、その故障を検出した呼制御サーバ2aのIPアドレスを含む故障サーバ情報を実施の形態3の図11で説明した故障サーバ情報抽出部25が作成して、全てのSIP端末4に通知する実施の形態を示す。
ここでは、故障サーバ情報抽出部25が故障サーバ情報を生成するとして説明するが、故障サーバ情報生成部が故障サーバ情報を生成するとしてもよい。
図14は、この発明の実施の形態4による呼制御サーバ2の内部構成図である。
図14の呼制御サーバ2の内部構成は、実施の形態3で示した図11の呼制御サーバ2の内部構成と同様であり、この図において、転送判定部23、端末情報保存部22、アドレス検索部24の動作については、実施の形態3の図11に示した呼制御サーバ2の内部構成の場合と同様である。
図14の呼制御サーバ2の内部構成は、実施の形態3で示した図11の呼制御サーバ2の内部構成と同様であり、この図において、転送判定部23、端末情報保存部22、アドレス検索部24の動作については、実施の形態3の図11に示した呼制御サーバ2の内部構成の場合と同様である。
そして、転送判定部23からの指示によってREGISTERリクエストを転送した場合、その転送に対して呼制御サーバ2aから応答がない状態でタイムアウトになる。
この様に、転送に失敗すると、SIPメッセージ送受信部21が故障サーバ情報抽出部25に転送タイムアウト情報を通知し、故障サーバ情報抽出部25が故障した呼制御サーバのIPアドレスを含む故障サーバ情報を作成する。この動作が追加となっている点が、図11に示した故障サーバSIPメッセージ送受信部21との違いであり、その他は同様である。
この様に、転送に失敗すると、SIPメッセージ送受信部21が故障サーバ情報抽出部25に転送タイムアウト情報を通知し、故障サーバ情報抽出部25が故障した呼制御サーバのIPアドレスを含む故障サーバ情報を作成する。この動作が追加となっている点が、図11に示した故障サーバSIPメッセージ送受信部21との違いであり、その他は同様である。
故障サーバ情報抽出部25は、呼制御サーバ2bから呼制御サーバ2aへのREGISTERリクエストの転送に対して、呼制御サーバ2aから応答のない状態でタイムアウトとなった時、SIPメッセージ送受信部21から転送タイムアウト情報が入力されて、転送先の呼制御サーバ2bが故障したものと判定する。
そして、図10及び図12のOrgnizationヘッダと同様な故障サーバ情報「server fault 192.168.0.1」を生成する。192.168.0.1が故障した呼制御サーバ2aのIPアドレスである。
そして、図10及び図12のOrgnizationヘッダと同様な故障サーバ情報「server fault 192.168.0.1」を生成する。192.168.0.1が故障した呼制御サーバ2aのIPアドレスである。
更に、端末情報保存部22に保存されている全てのアドレス情報を送信先のアドレス情報とし、これらの故障サーバ情報と送信先のアドレス情報をSIPメッセージ送受信部21に出力する。
図15は、呼制御サーバ2bが呼制御サーバ2aの故障を検出して、SIP端末4aとSIP端末4bに通知する場合のSIPメッセージシーケンスである。
ここでは、呼制御サーバ2bは、SIP端末4bからRGISTERリクエストの再送信が行われる。
ここでは、呼制御サーバ2bは、SIP端末4bからRGISTERリクエストの再送信が行われる。
そして、呼制御サーバ2bが、SIP端末4bからのREGISTERリクエストを呼制御サーバ2aに転送する。この時、呼制御サーバ2aから、REGISTERリクエストの転送に対する呼制御サーバ2bへの応答がなくタイムアウトになると、呼制御サーバ2bは、呼制御サーバ2aが故障したものと判定する。
すると、呼制御サーバ2bは、故障サーバ情報を含めたINFOリクエストをSIP端末4bに送信する。
この時のINFOリクエストの内容は、図12と同様である。INFOリクエストのOrganizationヘッダによって呼制御サーバ2aが故障であるという故障サーバ情報を通知する。
呼制御サーバ2bからのINFOリクエストをSIP端末4bが受信することにより、SIP端末4bは呼制御サーバ4aの故障を認識することができる。
この時のINFOリクエストの内容は、図12と同様である。INFOリクエストのOrganizationヘッダによって呼制御サーバ2aが故障であるという故障サーバ情報を通知する。
呼制御サーバ2bからのINFOリクエストをSIP端末4bが受信することにより、SIP端末4bは呼制御サーバ4aの故障を認識することができる。
同様に、呼制御サーバ2bは、SIP端末4aにもINFOリクエストを送信し、呼制御サーバ2aが故障であるという故障サーバ情報を通知する。
以降、SIP端末4aおよびSIP端末4bは、呼制御サーバ2aが故障であると認識しているため、INVITEリクエストを呼制御サーバ2aに送信せず呼制御サーバ2bに送信するため、呼接続時間が長くなることがなくなる。
以降、SIP端末4aおよびSIP端末4bは、呼制御サーバ2aが故障であると認識しているため、INVITEリクエストを呼制御サーバ2aに送信せず呼制御サーバ2bに送信するため、呼接続時間が長くなることがなくなる。
以上のように、本実施の形態によれば、呼制御サーバ2bがREGISTERリクエストを転送する際に、転送に対する応答のない状態でタイムアウトとなり、転送先の呼制御サーバ2aを故障と判定する。そして、その故障と判定した呼制御サーバ2aの故障サーバ情報を、端末情報保存部22に保存しているIPアドレスの全てのSIP端末4に通知する。そのため、SIP端末4は、以降、故障した呼制御サーバ2aにINVITEリクエストを送信しないため、故障した呼制御サーバ2aに対しての呼接続時間が長くなることを防止することが出来る。
実施の形態5.
上記実施の形態3においては、呼制御サーバ2bがSIP端末4aから呼制御サーバ2aが故障であるという故障サーバ情報を受け、故障サーバを検出したSIP端末4aを除く全てのSIP端末4b〜4nに対して、呼制御サーバ2bから故障と判定した呼制御サーバ2の故障サーバ情報を送信すると説明した。
また、上記実施の形態4においては、故障サーバを検出した呼制御サーバ2が、全てのSIP端末4に対して故障サーバ情報を送信するとして説明した。が、本実施の形態においては、各SIP端末がINVITEリクエストを優先して送信する優先呼制御サーバ2pを設定しておき、故障サーバ情報を一部のSIP端末に送信する場合について説明する。
上記実施の形態3においては、呼制御サーバ2bがSIP端末4aから呼制御サーバ2aが故障であるという故障サーバ情報を受け、故障サーバを検出したSIP端末4aを除く全てのSIP端末4b〜4nに対して、呼制御サーバ2bから故障と判定した呼制御サーバ2の故障サーバ情報を送信すると説明した。
また、上記実施の形態4においては、故障サーバを検出した呼制御サーバ2が、全てのSIP端末4に対して故障サーバ情報を送信するとして説明した。が、本実施の形態においては、各SIP端末がINVITEリクエストを優先して送信する優先呼制御サーバ2pを設定しておき、故障サーバ情報を一部のSIP端末に送信する場合について説明する。
ここで、優先呼制御サーバ2pとは、各SIP端末がINVITEリクエストを優先して送信する呼制御サーバ2をいう。
即ち、故障した呼制御サーバ2aを優先呼制御サーバ2pとしているSIP端末4に対してのみ、呼制御サーバ2bが、INFOリクエストによって故障サーバ情報を送信する場合について説明する。
即ち、故障した呼制御サーバ2aを優先呼制御サーバ2pとしているSIP端末4に対してのみ、呼制御サーバ2bが、INFOリクエストによって故障サーバ情報を送信する場合について説明する。
故障した呼制御サーバ2aを優先呼制御サーバ2pとしていないその他のSIP端末4(例えば、呼制御サーバ2bに制御されるSIP端末4b)については、SIP端末4bが呼制御サーバ2bにREGISTERリクエストを受信したときにだけ、その応答にOrganizationヘッダを付けて故障サーバ情報を通知する。
これにより、呼制御サーバ2が同時にSIP端末4に送信するINFOリクエストの個数を減らすことができ、ネットワークの負荷を軽減することができる。
本実施の形態における呼制御サーバ2の内部構成図は、実施の形態1の図1または実施の形態3の図11と同様である。
本実施の形態における呼制御サーバ2の内部構成図は、実施の形態1の図1または実施の形態3の図11と同様である。
本実施の形態の動作についても、実施の形態1の通信システム1のSIPメッセージシーケンサ、または実施の形態3の通信システム1のSIPメッセージシーケンサと同様であるが、図16に示す様に、SIP端末4aが呼制御サーバ2aに対して送信するREGISTERリクエストの内容が異なる。
図16は、本実施の形態において、SIP端末4aが呼制御サーバ2aに対して優先呼制御サーバ2pであることを通知するREGISTERリクエストの内容を示している。
図16のREGISTERリクエストに示す通り、Organizationヘッダの記述「Organization:Priority server 192.168.0.1」により呼制御サーバ2a(IPアドレス:192.168.0.1)が優先呼制御サーバ2pであることを通知する。
図16のREGISTERリクエストに示す通り、Organizationヘッダの記述「Organization:Priority server 192.168.0.1」により呼制御サーバ2a(IPアドレス:192.168.0.1)が優先呼制御サーバ2pであることを通知する。
SIP端末4a1〜SIP端末4anが優先呼制御サーバ2pである呼制御サーバ2aにREGISTERリクエストを送信し、呼制御サーバ2aがSIP端末4a1〜SIP端末4anを制御するとする。
この時、SIP端末4a1が呼制御サーバ2aの故障を検出、または、呼制御サーバ2bが呼制御サーバ2aの故障を検出したとする。すると、呼制御サーバ2aを優先呼制御サーバ2pとするSIP端末4a1以外のSIP端末4a2〜SIP端末4anに、呼制御サーバ2bが故障サーバ情報を含めたINFOリクエスト送信し、呼制御サーバ2aの故障を通知する。
この時、SIP端末4a1が呼制御サーバ2aの故障を検出、または、呼制御サーバ2bが呼制御サーバ2aの故障を検出したとする。すると、呼制御サーバ2aを優先呼制御サーバ2pとするSIP端末4a1以外のSIP端末4a2〜SIP端末4anに、呼制御サーバ2bが故障サーバ情報を含めたINFOリクエスト送信し、呼制御サーバ2aの故障を通知する。
以上のように、本実施の形態によれば、各SIP端末4a1〜4anに優先呼制御サーバ2pを設定すると共にその優先呼制御サーバ2pに優先呼制御サーバであることを通知する。
そして、SIP端末4a1が優先呼制御サーバ2pとして設定している呼制御サーバ2aの故障を検出すると、その故障した呼制御サーバ2aを優先呼制御サーバ2pとしているSIP端末4a2〜4anにのみINFOリクエストを用いてその故障を通知する。
または呼制御サーバ2bが、呼制御サーバ2aの故障を検出すると、その故障した呼制御サーバ2aを優先呼制御サーバ2pとしているSIP端末4a1〜4anにのみINFOリクエストを用いてその故障を通知する。
そのため、INFOリクエストの一斉送信によるネットワーク負荷を軽減することが出来る。
そして、SIP端末4a1が優先呼制御サーバ2pとして設定している呼制御サーバ2aの故障を検出すると、その故障した呼制御サーバ2aを優先呼制御サーバ2pとしているSIP端末4a2〜4anにのみINFOリクエストを用いてその故障を通知する。
または呼制御サーバ2bが、呼制御サーバ2aの故障を検出すると、その故障した呼制御サーバ2aを優先呼制御サーバ2pとしているSIP端末4a1〜4anにのみINFOリクエストを用いてその故障を通知する。
そのため、INFOリクエストの一斉送信によるネットワーク負荷を軽減することが出来る。
実施の形態6.
上記実施の形態1〜5においては、呼制御サーバ2を2個備えるシステム構成について説明したが、呼制御サーバ2は3個以上あってもよい。
本実施の形態においては、呼制御サーバ2が3個以上ある場合のシステム構成について説明する。
呼制御サーバ2が3個以上であっても、SIP端末4が呼制御サーバ2の故障を検出し、故障していない他の呼制御サーバ2に通知する、または故障していない他の呼制御サーバ2が呼制御サーバ2の故障を検出して、故障していない他の呼制御サーバ2に故障サーバ情報を含めたINFOリクエストを用いて故障サーバ情報を通知する。
この様に、故障していない他の呼制御サーバ2の制御によってSIP端末4が発信先のSIP端末4との通信が可能となり、システム停止となる可能性が低く、信頼性の高い通信システムを得ることが出来る。
上記実施の形態1〜5においては、呼制御サーバ2を2個備えるシステム構成について説明したが、呼制御サーバ2は3個以上あってもよい。
本実施の形態においては、呼制御サーバ2が3個以上ある場合のシステム構成について説明する。
呼制御サーバ2が3個以上であっても、SIP端末4が呼制御サーバ2の故障を検出し、故障していない他の呼制御サーバ2に通知する、または故障していない他の呼制御サーバ2が呼制御サーバ2の故障を検出して、故障していない他の呼制御サーバ2に故障サーバ情報を含めたINFOリクエストを用いて故障サーバ情報を通知する。
この様に、故障していない他の呼制御サーバ2の制御によってSIP端末4が発信先のSIP端末4との通信が可能となり、システム停止となる可能性が低く、信頼性の高い通信システムを得ることが出来る。
また、故障していない他の呼制御サーバ2にINFOリクエストを用いて故障サーバ情報を通知する場合、呼制御サーバ2が故障していない他の呼制御サーバ2に対してSIP端末4からのINVITEリクエストを転送するので、故障した呼制御サーバ2へのINVITEリクエストの転送を回避することが可能となる。そのため、呼接続時間が長くなることを防止することができる。
このようにSIP端末4からの接続要求(INVITEリクエスト)を他のSIP端末または他の呼制御サーバ2に転送することができるのは、呼制御サーバ2が、SIPプロキシ機能を持つ場合である。
このようにSIP端末4からの接続要求(INVITEリクエスト)を他のSIP端末または他の呼制御サーバ2に転送することができるのは、呼制御サーバ2が、SIPプロキシ機能を持つ場合である。
更に、呼制御サーバ2がSIPプロキシ機能を持つ場合には、各呼制御サーバ2に対してINVITEリクエストを優先的に転送する優先呼制御サーバ2pを設定しておき、故障した呼制御サーバ2を優先呼制御サーバ2pとしているSIP端末4に対してのみ、故障サーバ情報をINFOリクエストによって送信するようにしても良い。
そして、その他の呼制御サーバ2については、REGISTERリクエストを転送するとき、そのREGISTERリクエスト内にOrganizationヘッダを付けて故障サーバ情報を通知する。これにより、呼制御サーバ2が同時に送信するINFOリクエストの個数を減らすことができ、ネットワークの負荷を軽減することが出来る。
そして、その他の呼制御サーバ2については、REGISTERリクエストを転送するとき、そのREGISTERリクエスト内にOrganizationヘッダを付けて故障サーバ情報を通知する。これにより、呼制御サーバ2が同時に送信するINFOリクエストの個数を減らすことができ、ネットワークの負荷を軽減することが出来る。
1 通信システム、2 呼制御サーバ、3 IP網、4 SIP端末、21 SIPメッセージ送受信部、22 端末情報保存部、23 転送判定部、24 アドレス検索部、25 故障サーバ情報抽出部。
Claims (10)
- 複数のIP端末を制御する呼制御サーバにおいて、
第1の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第1の端末情報を前記第1のIP端末から受信すると共に、他の呼制御サーバが制御する第2の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第2の端末情報を前記他の呼制御サーバから転送されて受信する受信部、
該受信部で受信した前記第1の端末情報と前記第2の端末情報を記憶する記憶部、
前記第2のIP端末から前記第1のIP端末の電話番号を前記受信部で受信すると、前記第1のIP端末の電話番号に対応したアドレス情報を前記記憶部から検索し、前記第1のIP端末から前記第2のIP端末の電話番号を前記受信部で受信すると、前記第2のIP端末の電話番号に対応したアドレス情報を前記記憶部から検索する検索部、
該検索部で検索した前記第1のIP端末のアドレス情報を前記第2のIP端末に送信し、前記検索部で検索した前記第2のIP端末のアドレス情報を前記第1のIP端末に送信する送信部、
を備えたことを特徴とする呼制御サーバ。 - 前記受信部で受信した端末情報を前記他の呼制御サーバに転送するか否かを判定する転送判定部を更に備え、
該転送判定部は、前記第1のIP端末から受信した前記端末情報の登録先が自己であれば、前記第1のIP端末から受信した端末情報を前記他の呼制御サーバに転送する転送指示を前記送信部に出力し、
該送信部は、前記転送判定部から転送指示が入力されると前記他の呼制御サーバに前記端末情報を転送することを特徴とする請求項1に記載の呼制御サーバ。 - 前記受信部で前記第2のIP端末から前記第1のIP端末の電話番号を受信するのは、前記第2のIP端末が前記他の呼制御サーバに前記第1のIP端末との通信を要求する通信要求を送信して前記他の呼制御サーバから所定の時間応答がない場合であることを特徴とする請求項1または請求項2に記載の呼制御サーバ。
- 前記受信部で前記第2のIP端末から自端末の端末情報の登録を要求する登録要求、または前記第2のIP端末から前記第1の端末との通信を要求する通信要求を受信すると、前記登録要求または前記通信要求から前記第2のIP端末によって生成された前記他の呼制御サーバの故障情報である故障サーバ情報を抽出し、前記送信部に出力する故障サーバ情報抽出部を更に備え、
前記送信部は、前記故障サーバ情報抽出部から入力された前記故障サーバ情報を前記記憶部に記憶されている端末情報のIP端末に送信することを特徴とする請求項3記載に記載の呼制御サーバ。 - 前記送信部は、前記故障サーバ情報抽出部から入力された前記故障サーバ情報を前記他の制御サーバが制御するIP端末に送信することを特徴とする請求項4記載に記載の呼制御サーバ。
- 前記転送判定部から入力された転送指示に従い前記送信部が前記他の呼制御サーバへ前記第1のIP端末の端末情報を転送して、前記他の呼制御サーバから所定の時間応答がない場合に、前記他の呼制御サーバの故障情報である故障サーバ情報を生成し、この生成した故障サーバ情報を前記送信部に出力する故障サーバ情報生成部を更に備え、
前記送信部は、前記故障サーバ情報生成部から入力された前記故障サーバ情報を前記記憶部に記憶されている端末情報のIP端末に送信することを特徴とする請求項2に記載の呼制御サーバ。 - 前記送信部は、前記故障サーバ情報生成部から入力された前記故障サーバ情報を前記他の制御サーバが制御するIP端末に送信することを特徴とする請求項6に記載の呼制御サーバ。
- 前記送信部は、故障していない他の呼制御サーバに前記故障サーバ情報を送信することを特徴とする請求項4〜7のいずれかに記載の呼制御サーバ。
- 複数のIP端末とそれを制御する複数の呼制御サーバから構成される通信システムであって、
前記呼制御サーバは、
第1の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第1の端末情報を前記第1のIP端末から受信すると共に、他の呼制御サーバが制御する第2の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第2の端末情報を前記他の呼制御サーバから転送されて受信する受信部、
該受信部で受信した前記第1の端末情報と前記第2の端末情報を記憶する記憶部、
前記第2のIP端末から前記第1のIP端末の電話番号を前記受信部で受信すると、前記第1のIP端末の電話番号に対応したアドレス情報を前記記憶部から検索し、前記第1のIP端末から前記第2のIP端末の電話番号を前記受信部で受信すると、前記第2のIP端末の電話番号に対応したアドレス情報を前記記憶部から検索する検索部、
該検索部で検索した前記第1のIP端末のアドレス情報を前記第2のIP端末に送信し、前記検索部で検索した前記第2のIP端末のアドレス情報を前記第1のIP端末に送信する送信部を備え、
前記第2のIP端末は、
前記第1のIP端末との通信を要求する通信要求を前記他の呼制御サーバに送信して、前記他の呼制御サーバから所定の時間応答がない場合、前記呼制御サーバに前記第1のIP端末の電話番号を送信することを特徴とする通信システム。 - 複数のIP端末を制御する呼制御サーバの呼制御方法において、
第1の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第1の端末情報を前記第1のIP端末から受信すると共に、他の呼制御サーバが制御する第2の前記IP端末の電話番号と電話番号に対応したアドレス情報を含む第2の端末情報を前記他の呼制御サーバから転送されて受信する第1の受信ステップ、
該第1の受信ステップで受信した前記第1の端末情報と前記第2の端末情報を前記呼制御サーバの記憶部で記憶する記憶ステップ、
前記第2のIP端末から前記第1のIP端末の電話番号を受信する、または前記第1のIP端末から前記第2のIP端末の電話番号を受信する第2の受信ステップ、
該第2の受信ステップで前記第2のIP端末から前記第1のIP端末の電話番号を受信すると、前記記憶ステップで記憶した記憶部から前記第1のIP端末の電話番号に対応したアドレス情報を検索し、前記第1のIP端末から前記第2のIP端末の電話番号を受信すると、前記記憶ステップで記憶した記憶部から前記第2のIP端末の電話番号に対応したアドレス情報を検索する検索ステップ、
該検索ステップで前記第1のIP端末のアドレス情報を検索すると前記第2のIP端末に前記第1のIP端末のアドレス情報を送信し、前記第2のIP端末のアドレス情報を検索すると前記第1のIP端末に前記第2のIP端末のアドレス情報を送信する送信ステップ、
を備えたことを特徴とする呼制御サーバの呼制御方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012142605A JP2014007617A (ja) | 2012-06-26 | 2012-06-26 | 呼制御サーバ、通信システム、および呼制御方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012142605A JP2014007617A (ja) | 2012-06-26 | 2012-06-26 | 呼制御サーバ、通信システム、および呼制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014007617A true JP2014007617A (ja) | 2014-01-16 |
Family
ID=50104976
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012142605A Pending JP2014007617A (ja) | 2012-06-26 | 2012-06-26 | 呼制御サーバ、通信システム、および呼制御方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2014007617A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017508360A (ja) * | 2014-01-28 | 2017-03-23 | クアルコム,インコーポレイテッド | VoIPシステムにおけるフェイルオーバー中のユーザの区別または優先順位付け |
-
2012
- 2012-06-26 JP JP2012142605A patent/JP2014007617A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017508360A (ja) * | 2014-01-28 | 2017-03-23 | クアルコム,インコーポレイテッド | VoIPシステムにおけるフェイルオーバー中のユーザの区別または優先順位付け |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4425841B2 (ja) | 中継システムおよび呼救済方法 | |
US8374079B2 (en) | Proxy server, communication system, communication method and program | |
US20070041327A1 (en) | Multicast heartbeat signaling | |
JP5173607B2 (ja) | 通信システム | |
JP2005229273A (ja) | サーババックアップ装置 | |
JP2008236003A (ja) | Sipサーバ | |
US20100161745A1 (en) | Communication System and Terminal Registration Method Thereof, Server Unit, and Terminal Device | |
WO2016101457A1 (zh) | 一种终端及终端呼叫软切换的方法 | |
JP5841262B2 (ja) | Sipプロキシ・フェイルオーバ方法 | |
US20080144630A1 (en) | Call management method, call management system and message processing server system | |
CN110602339B (zh) | 一种基于语音网关的故障检测方法、系统及存储介质 | |
CN102487341B (zh) | 会话检测方法、装置及会话初始协议服务器 | |
JP4387937B2 (ja) | 電話システムおよび交換システム | |
JP2010239216A (ja) | 呼制御方法 | |
CN111491007A (zh) | Sip中心信令控制服务负载均衡方法及其负载均衡器 | |
CN107454178B (zh) | 数据传输方法及装置 | |
JP2014007617A (ja) | 呼制御サーバ、通信システム、および呼制御方法 | |
CN116028278A (zh) | 一种主备双机切换方法、介质及系统 | |
JP2008306340A (ja) | Ip電話システム、ip電話機および通信方法 | |
CN113595765A (zh) | 一种VoIP终端注册业务的故障转移方法及装置 | |
JP2009033453A (ja) | 電話交換装置及びこの電話交換装置で使用される制御方法 | |
CN113746865B (zh) | 一种VoIP终端通信业务的故障转移方法及装置 | |
JP4665063B2 (ja) | 通信システムとその端末登録方法およびサーバ | |
JP2011082868A (ja) | 呼救済システム、呼救済サーバ、呼救済サーバの呼救済プログラム | |
WO2016201973A1 (zh) | 一种容灾方法、装置及通信系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20140326 |