JP2011082868A - 呼救済システム、呼救済サーバ、呼救済サーバの呼救済プログラム - Google Patents

Abstract

【課題】ＳＩＰサーバに障害があった場合でも、ＩＰ電話端末間に確立中の呼を切断することがない。
【解決手段】ＩＰ電話網４を介してＳＩＰサーバ１の死活監視を行う呼救済サーバ２を備え、ＳＩＰサーバ１とＩＰ電話端末３は、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行うセッション監視パケット１０の送信及び応答を行う。呼救済サーバ２は、ＩＰ電話網４を介してセッション監視パケット１０を受信し、死活監視の結果、ＳＩＰサーバ１の障害が検出された場合、ＳＩＰサーバ１に代わってセッション監視パケット１０の送信又は応答を行う。
【選択図】 図1

Description

本発明は、ＩＰ電話網を利用して音声通信を実現する音声通信システムに関し、特に、呼の監視制御を行う呼救済システムに関するものである。

従来、ＩＰ電話網を利用して音声通信を実現する音声通信システムにおいて、伝送経路上に障害が発生したとき、通話中の呼に影響を与えずに通話を維持するための技術が開示されている（特開２００７−２６６７３７：特許文献１）。特許文献１によると、メインサーバは、ＩＰ電話端末間の呼接続の進行状況などを収集し、ＩＰ電話端末間の呼が確立すると、その呼制御情報を、当該ＩＰ電話端末を管理しているサバイバルサーバに転送させる。メインサーバは、ＩＰ電話端末から切断信号を受信すると、当該ＩＰ電話端末の呼の切断処理を行うとともに、当該ＩＰ電話端末についての切断情報をサバイバルサーバにも転送させ、メインサーバが管理している呼制御情報をサバイバルサーバにも管理させる。呼確立中のＩＰ電話端末についてはメインサーバからサバイバルサーバに接続先サーバの変更を行うことで呼救済させることができる。

特開２００７−２６６７３７号公報

しかしながら、メインサーバが管理している呼制御情報において、メインサーバからサバイバルサーバへの呼制御情報を転送するとき、伝送経路に障害があった場合などには、転送されるべき呼制御情報が伝達されないケースも考えられる。このような状態ではメインサーバとサバイバルサーバで管理している呼制御情報が不一致となってしまうおそれがある。特に、呼が確立した通話中呼に関しては、その通話状態を管理するためのセッション状態を監視しているが、メインサーバとサバイバルサーバの呼制御情報が不一致の状態では、呼救済ができないおそれがある。

本発明が解決しようとする課題は、メインサーバとしてのＳＩＰサーバや伝送路に障害があった場合でも、ＩＰ電話端末間で確立中の呼を切断することのない音声通信システムにおける呼救済システムを提供することである。

上記課題を解決するための請求項１記載の発明は、ＳＩＰサーバ及び複数のＩＰ電話端末がＩＰ電話網に接続される呼救済システムにおいて、前記ＩＰ電話網を介して前記ＳＩＰサーバの死活監視を行う呼救済サーバを備え、前記ＳＩＰサーバと前記ＩＰ電話端末は、前記ＩＰ電話端末間で確立した呼の監視を行うセッション監視パケットの送信及び応答を行い、前記呼救済サーバは、前記ＩＰ電話網を介して前記セッション監視パケットを受信し、前記死活監視の結果、障害が検出された場合、前記セッション監視パケットの送信又は応答を行うことを特徴とする呼救済システムである。

上記構成を有する本発明によれば、前記ＳＩＰサーバと前記ＩＰ電話端末は、前記ＩＰ電話端末間で確立した呼の監視を行うセッション監視パケットを前記ＩＰ電話網を介して送信及び応答を行い、更に、ＳＩＰサーバの死活監視を行うとともに、前記ＩＰ電話網を介して前記セッション監視パケットの受信を行う呼救済サーバを設け、当該呼救済サーバは、前記死活監視の結果、ＳＩＰサーバに障害が検出された場合、受信した前記セッション監視パケットに対して代理応答を行うか又は前記セッション監視パケットの代理送信を行うようにしたので、ＳＩＰサーバや伝送路上に障害があった場合でも、確立中の呼を切断することのない音声通信システムにおける呼救済システムを提供することが可能になる。

本発明に関する呼救済システムのブロック図である。 ＳＩＰサーバ１の内部機能を示すブロック図である。 呼救済サーバ２の内部機能を示すブロック図である。 ＩＰ電話端末３の内部機能を示すブロック図である。 セッション監視パケットの概要を示す説明図である。 第１の実施の形態に関する呼救済システムの動作を示すシーケンスである。 第２の実施の形態に関する呼救済システムの動作を示すシーケンスである。

＜第１の実施の形態＞
以下第１の実施の形態について説明する。図１は本発明に関する呼救済システムのブロック図である。本発明に関する呼救済システム１００は、呼制御サーバとしてのＳＩＰ（セッション開始プロトコル：Session Initiation Protocol）サーバ１、呼救済サーバ２、ＩＰ（Internet Protocol）電話端末３−１及び３−２を主な構成とし、ＩＰ電話網４に接続されている。ルータ／ＳＷ５−１及び５−２はこれらの機器をＩＰ電話網４に接続し、ＩＰパケットを中継する装置である。ルータ／ＳＷ５−１及び５−２及びＩＰ電話網４により伝送経路を形成する。

ＳＩＰサーバ１は、ＳＩＰプロキシー（Proxy）の機能と、ＳＩＰ登録（Registrar）の機能を併せ持つ装置である。ＳＩＰサーバ１は、複数のＩＰ電話端末３−１及び３−２からの接続要求を受け付け、相手端末との通信状態の管理を行っている。即ち、ＩＰ電話端末３−１及び３−２の呼を制御するとともに、呼が確立した通話呼の状態管理を行う。ＳＩＰサーバ１はルータ／ＳＷ５−１を経由してＩＰ電話網４に接続されている。後述するように、ＩＰ電話端末３−１及び３−２間で確立した呼の監視のためのセッション監視パケット１０を、ＩＰ電話端末３−１及び３−２との間で送信と応答を行う。即ち、正常時、ＳＩＰサーバ１は、ＩＰ電話端末３−１及び３−２から受信したセッション監視パケット１０に対し応答を行う。

ＩＰ電話端末３−１及び３−２はＳＩＰサーバ１により制御され、他のＩＰ電話端末３−２又は３−１間で通話を行うための装置である。ＩＰ電話端末３−１及び３−２は、ルータ／ＳＷ５−２を経由してＩＰ電話網４に接続されている。また、前記セッション監視パケット１０をＳＩＰサーバ１との間で送信と応答を行う。その際、本実施の形態においては、後述するようにＩＰ電話端末３−１及び３−２がリフレッシャ(Refresher)となって、セッション監視パケット１０をＳＩＰサーバ１と呼救済サーバ２に送信する。

セッション監視パケット１０はタイマ機能を有し、セッション監視パケット１０に対して所定時間内に次のセッション監視パケット１０の送信を行うことが必要である。即ち、タイマ期間が切れる前に、ＩＰ電話端末３−１及び３−２は再度次のセッション監視パケット１０を送り、更新する必要がある。タイマが切れると、呼が切断されることになる。

セッション監視パケット１０を受信した前記ＳＩＰサーバ１は、所定の時間以内に応答することが要求される。セッション監視パケット１０を送信したＩＰ電話端末３−１及び３−２は、所定の時間以内にＳＩＰサーバ１からの応答があるかどうか常に監視している。

呼救済サーバ２は、セッション監視パケット１０を管理する装置である。呼救済サーバ２は、ルータ／ＳＷ５−２を経由してＩＰ電話網４に接続され、正常時、セッション監視パケット１０を受信する。更に、呼救済サーバ２は、ＩＰ電話網４を介してＳＩＰサーバ１の死活監視を行う。死活監視の結果、ＳＩＰサーバ１が正常に動作している場合は、呼救済サーバ２は受信したセッション監視パケット１０に対して応答を行わない。正常時、ＳＩＰサーバ１がセッション監視パケット１０に対して応答を行っている。そこで、呼救済サーバ２の死活監視の結果、ＳＩＰサーバ１に障害が検出された場合は、呼救済サーバ２は受信したセッション監視パケット１０に対しＳＩＰサーバ１に代わって応答を行う。

なお、サバイバルサーバ６は、ＳＩＰサーバ１又は伝送路上に障害が検出されたとき、ＳＩＰサーバ１に代わって呼処理を行う装置であり、ルータ／ＳＷ５−２を経由してＩＰ電話網４に接続されている。ソフトフォン７は、パソコンなどの情報処理装置上に、ソフトウェアで呼処理、音声信号処理などを実現した装置であり、同じくルータ／ＳＷ５−２を経由してＩＰ電話網４に接続されている。

前述のように、セッション監視パケット１０を送信したＩＰ電話端末３−１及び３−２は、所定の時間以内にＳＩＰサーバ１からの応答があるかどうか常に監視しているため、呼救済サーバ２による前記代理応答を受信する。これにより、ＩＰ電話端末３−１及び３−２間で確立した呼の監視のためのセッション監視パケット１０は正常に機能し、ＩＰ電話端末３−１及び３−２間での確立中の呼が切断されることはない。

図２は、ＳＩＰサーバ１の内部機能を示すブロック図である。ＳＩＰサーバ１は、装置管理機能部１１と、呼処理機能部１２と、データベース部１３と、端末収容機能部１４とを備えている。これにより、ＳＩＰサーバ１は、ＩＰ電話端末３−１及び３−２の呼を制御するとともに、呼が確立した通話呼の状態管理を行う。

装置管理機能部１１は対象とする装置を管理する機能部である。装置管理機能部１１は、呼を確立したＩＰ電話端末３−１及び３−２の管理機能や、サバイバルサーバ６からのヘルスチェックに対する応答機能を有する。このサバイバルサーバ６からのヘルスチェックに対する応答機能とは、サバイバルサーバ６からヘルスチェック要求信号を受信すると、それに応答するヘルスチェック応答信号をサバイバルサーバ６に応答するものである。更に、装置管理機能部１１は、呼救済サーバ２が行う死活監視に対する応答機能を有する。呼救済サーバ２が行う死活監視に対する応答機能とは、呼救済サーバ２からの死活監視に関する監視信号に対して、呼救済サーバ２に所定時間内に応答するものである。

呼処理機能部１２は、ＩＰ電話端末３−１及び３−２間でやり取りされる呼制御メッセージの中継などを行い、ＩＰ電話端末３−１及び３−２間の呼を確立する。呼処理機能部１２は、ＩＰ電話端末３−１及び３−２間の呼接続の進行状況などを示す情報を収集する。また、呼処理機能部１２は、ＩＰ電話端末３−１及び３−２間の呼が確立すると、呼が確立したＩＰ電話端末３−１及び３−２に関する呼制御情報を、当該ＩＰ電話端末３−１及び３−２を管理しているサバイバルサーバ６に送信させる。これにより、ＳＩＰサーバ１が管理している呼制御情報をサバイバルサーバ６にも管理させることができる。また、ＳＩＰサーバ１は、ＩＰ電話端末３−１又は３−２から切断信号を受信すると、当該ＩＰ電話端末３−１及び３−２の呼の切断処理を行う。それと共に、当該ＩＰ電話端末３−１及び３−２についての切断情報を、サバイバルサーバ６に送信させる。

更に、呼処理機能部１２は、ＩＰ電話端末３−１及び３−２から送信されるセッション監視パケット１０を受信し、そして所定の時間内に応答を行う。更にまた、前回受信したセッション監視パケット１０から所定の時間内に次のセッション監視パケット１０を受信するかどうかを監視する。なお、ＳＩＰサーバ１は、図示しない記憶手段に格納されたプログラムにより動作する。当該プログラムは、ＳＩＰサーバ１の後述する動作手順を図示しないコンピュータに実行させることにより動作する。

データベース部１３は、ＳＩＰサーバ１の管理範囲内の各ＩＰ電話端末３−１及び３−２に関する情報を蓄積する。データベース部１３は、例えば、各ＩＰ電話端末３−１及び３−２に割り当てられているＩＰアドレスと電話番号の対応関係などの情報や、呼処理機能部１２により収集されたＩＰ電話端末３−１及び３−２の状態を示す情報なども蓄積する。

端末収容機能部１４は、ＳＩＰサーバ１の管理範囲内の任意のＩＰ電話端末３−１又は３−２から呼制御メッセージの受付けなどを行うためのポートを有する機能部である。端末収容機能部１４は、常時、ポートの受付けを許可する状態である。

図３は、呼救済サーバ２の内部機能を示すブロック図である。呼救済サーバ２は、装置管理機能部２１と、呼処理機能部２２と、データベース部２３とを備えている。装置管理機能部２１は、ＳＩＰサーバ１の死活監視に対する監視機能を有する。呼救済サーバ２が行う死活監視に対する監視機能とは、ＳＩＰサーバ１の死活監視に関する監視信号をＳＩＰサーバに対して送信するものである。死活監視に関する監視信号に対し、所定時間以内に応答がないときは、ＳＩＰサーバ１における障害発生、又はＳＩＰサーバ１までの間の伝送経路におけるＩＰ電話網４の障害発生と判断する。

呼処理機能部２２は、セッション監視パケット１０を常時受信する。しかしながら、正常時は、受信したセッション監視パケット１０に対して応答は行わない。前記装置管理機能部２１がＳＩＰサーバ１からの監視応答がなく障害発生を検出すると、呼処理機能部２２は、受信したセッション監視パケット１０に対し応答を行う。即ち、呼処理機能部２２は、セッション監視パケット１０をリフレッシャとして送信したＩＰ電話端末３−１及び３−２に対して、ＳＩＰサーバ１に代理して応答を行う。これによって、ＩＰ電話端末３−１及び３−２はセッション監視パケット１０の応答を受信することができるので、ＩＰ電話端末３−１及び３−２間で確立中の呼を切断することがなくなる。なお、呼救済サーバ２は、図示しない記憶手段に格納されたプログラムにより動作する。当該プログラムは、呼救済サーバ２の後述する動作手順を図示しないコンピュータに実行させることにより動作する。

データベース部２３は、ＳＩＰサーバ１を死活監視するためにＳＩＰサーバ１に関する情報を蓄積するが、ＳＩＰサーバ１の管理範囲内の各ＩＰ電話端末３−１及び３−２に関する情報を蓄積することは必須ではない。

図４はＩＰ電話端末３の内部機能を示すブロック図である。ＩＰ電話端末３は、制御部３１と、記憶部３２と、呼制御部３３と、通信部３４と、ヘルスチェック部３５と、接続サーバ切替部３６と、操作部３７と、表示部３８とを備えている。制御部３１は、ＩＰ電話端末３の各部を制御するものであり、ハードウェア的にはＩＰ電話端末３のＣＰＵ（中央処理装置）が該当し、ソフトウェア的にはＯＳ（オペレーティングシステム）などの制御プログラムが該当する。

記憶部３２は、揮発性又は不揮発性の記憶資源である。記憶部３２には、ＩＰ電話端末３の機能を実現させる処理プログラムを格納するものである。そして、制御部３１が、記憶部３２に格納されている処理プログラムを読み出して実行することにより、ＩＰ電話端末３としての機能を実現することができる。

呼制御部３３は、制御部３１の制御下で、他のＩＰ電話端末３−１又は３−２と通話をするために、ＳＩＰサーバ１との間で呼制御情報の生成や授受などを行う。呼制御情報は、ＩＮＶＩＴＥ，ＡＣＫ，ＢＹＥ，ＣＡＮＣＥＬ，ＯＰＴＩＯＮＳ，ＲＥＧＩＳＴＥＲなどによりＩＰ電話端末３−１及び３−２がＳＩＰサーバ１とやり取りすることにより、呼を確立するためのパケットである。

更に、呼制御部３３は、制御部３１の制御により、ＳＩＰサーバ１と呼救済サーバ２に対し、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行うためのセッション監視パケット１０をマルチキャスト（Multicast）で送信する。セッション監視パケット１０は、前記呼制御情報の一つで、ｒｅ−ＩＮＶＩＴＥ（既存のセッションに関するＩＮＶＩＴＥ要求）などにより、呼確立中のＩＰ電話端末３−１及び３−２間の呼に対して定期的に監視を行うために送信される。この監視は決められた一定時間のタイマがあり、そのタイマが切れる前に次のセッション監視パケット１０を送る必要がある。セッション監視パケット１０を受信した側も同様に、所定時間内に応答を行う必要がある。仮にＳＩＰサーバ１や伝送経路に障害があり、セッション監視パケット１０が相手側に到達せずタイマが切れた場合には、その呼は切断される。即ち、セッション監視パケット１０に対する応答が所定時間内に到達しないＩＰ電話端末３−１又は３−２は切断要求（ＢＹＥ）をＳＩＰサーバ１に送信し呼を切断してしまう。

また、マルチキャストは、一般にコンピュータネットワークにおいて、決められた複数のネットワーク端末に対して、同時にパケットを送信することである。一対多で通信を行う場合、配信事業者にとって、ユニキャストを使用するよりもネットワーク負荷を軽減することができる。従って、前記呼制御部３３は、マルチキャストアドレスにＳＩＰサーバ１と呼救済サーバ２のアドレスを記載して送信する。そして、リフレッシャとしてセッション監視パケット１０を送信したＩＰ電話端末３−１及び３−２の呼制御部３３は、所定の時間以内にＳＩＰサーバ１からの応答があるかどうか常に監視する。なお、呼制御部３３は、呼制御を実行するための所定の呼制御ソフトウェアを記憶部３２に保持している。

ヘルスチェック部３５は、ＳＩＰサーバ１、サバイバルサーバ６及び当該サーバまでの伝送経路の正常性を検査する部分である。ヘルスチェック部３５は呼が確立すると、ＳＩＰサーバ１から周期的に受信したヘルスチェック要求信号に対してヘルスチェック応答信号を返信する。通信部３４はＩＰ電話網４を介して通信を行う。即ち、制御や管理のために行われるＳＩＰサーバ１又は呼救済サーバ２との通信と、通話相手としてのＩＰ電話端末３−２又は３−１との間で行われるリアルタイムな音声通信を行う。

接続サーバ切替部３６は、制御部３１の制御下で、当該ＩＰ電話端末３−１及び３−２が呼制御やアドレス解決のために、呼制御部３３がアクセスする接続先のＳＩＰサーバ１又はサバイバルサーバ６を切り替え制御するものである。操作部３７は、ＩＰ電話端末３−１及び３−２のユーザが操作するユーザインタフェースである。操作部３７は、少なくとも通話相手の電話番号等を指定するための図示しない入力ボタン等が該当する。表示部３８は、制御部３１からユーザに情報を伝えるための構成部分である。例えば、液晶表示装置や、発光ＬＥＤ素子等によって当該表示部３８を構成する。

図５はセッション監視パケット１０の概要を示す説明図である。セッション監視パケット１０はリクエスト行４１、ヘッダ部分４２、空白行４３及びメッセージボディー４４からなる。ｒｅ−ＩＮＶＩＴＥ要求の例の場合、リクエスト行４１は「INVITE sip:XXX@XXX.example.com SIP/2.0」のように記述される。ヘッダ部分４２には、例えば「Session-Expires:３６００」のようにタイマ部分が記述され、メッセージが期限切れになるまでの時間が記述される。「Session-Expires:３６００」の期限が切れる前に、再度、ｒｅ−ＩＮＶＩＴＥを送り更新する必要がある時間である。ヘッダ部分４２の他の記述についての説明は省略する。空白行４３は、次のメッセージボディー４４と分けるためのものである。メッセージボディー４４は、ＳＤＰ（Session Description Protocol）を用いて、通信に使用するＳＤＰバージョンやコーデック、セッション開始者、セッション識別情報、セッション名、コネクション情報、セッションの開始・終了時刻などが記述される。

次に、第１の実施の形態に関する動作を説明する。図６は、第１の実施の形態に関する呼救済システムの動作を示すシーケンスである。第１の実施の形態は、前述の通り、ＩＰ電話端末３−１及び３−２がセッション監視パケット１０のリフレッシャとなる場合である。なお、図示の○印はマルチキャストでのパケットの送出を意味する。

ステップ１０１：まず、例えばＩＰ電話端末３−１は、着信先をＩＰ電話端末３−２とする呼設定要求をＳＩＰサーバ１に送信する。ＳＩＰサーバ１はＩＰ電話端末３−１から呼設定要求を受け取ると、呼処理機能部１２が所定の呼制御プロトコルに従って着信先のＩＰ電話端末３−２との間で呼制御を行う。このような接続手順が行われることにより次に進む。

ステップ１０２：ＳＩＰサーバ１によって、ＩＰ電話端末３−１及び３−２との間の呼制御処理がなされ、呼が確立することにより通話が行われる。
ステップ１０３：ＳＩＰサーバ１を介して呼を確立したＩＰ電話端末３−１の制御部３１は、呼制御部３３を制御することにより、正常時、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行うためのセッション監視パケット１０をマルチキャストで、ＳＩＰサーバ１及び呼救済サーバ２に送信する。同時に、所定時間内に応答があるかどうか監視する。

ステップ１０４：ＩＰ電話端末３−１からセッション監視パケット１０を受信したＳＩＰサーバ１の呼処理機能部１２は、正常時、所定時間以内に応答を返信する。同時に、所定時間内に次のセッション監視パケット１０を受信するかどうか監視する。一方、同じく正常時において、セッション監視パケット１０を受信した呼救済サーバ２の呼処理機能部２２は応答を行わない。

ステップ１０５：ＩＰ電話端末３−２の制御部３１は、同様に正常時、呼制御部３３を制御することにより、電話端末３−１及び３−２間で確立した呼の監視を行うためのセッション監視パケット１０をマルチキャストで、ＳＩＰサーバ１及び呼救済サーバ２に送信する。同時に、所定時間内に応答があるかどうか監視する。

ステップ１０６：ＩＰ電話端末３−２からセッション監視パケット１０を受信したＳＩＰサーバ１の呼処理機能部１２は、正常時所定時間以内に応答を返信する。同時に、所定時間内に次のセッション監視パケット１０を受信するかどうか監視する。同様に、セッション監視パケット１０を受信した呼救済サーバ２の呼処理機能部２２は応答を行わない。

ステップ１０７〜１１０：以下同様にＩＰ電話端末３−１及び３−２間の通話中、ＩＰ電話端末３−１及び３−２がリフレッシャとなって、次のセッション監視パケット１０を送信し、ＳＩＰサーバ１はこれに応答することにより、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行う。

ステップ１２０：一方、呼救済サーバ２は、装置管理機能部２１により、ＳＩＰサーバ１に対して常時死活監視を行っている。
ステップ１２１：ＩＰ電話端末３−１及び３−２間の通話中に、ＳＩＰサーバ１に障害が発生したとする。
ステップ１２２：前記ステップ１２１で発生したＳＩＰサーバ１の障害は、呼救済サーバ２の装置管理機能部２１よって検出される。

ステップ１２３：その後、ＩＰ電話端末３−１がセッション監視パケット１０をマルチキャストで、ＳＩＰサーバ１及び呼救済サーバ２に送信する。
ステップ１２４：しかしながら、ＳＩＰサーバ１からは障害のため、応答することができないとする。

ステップ１２５：呼救済サーバ２は、前記ステップ１２２により、装置管理機能部２１がＳＩＰサーバ１の障害を検出している。そして、ステップ１２３により、呼処理機能部２２がセッション監視パケット１０を受信している。従って、呼救済サーバ２は、呼処理機能部２２を制御することにより、所定時間内にセッション監視パケット１０に対してＳＩＰサーバ１に代わって応答を行う。

ステップ１２６：ＩＰ電話端末３−２も次のセッション監視パケット１０をマルチキャストで、ＳＩＰサーバ１及び呼救済サーバ２に送信する。
ステップ１２７：しかしながら、同様に、ＳＩＰサーバ１は応答できない。
ステップ１２８：呼救済サーバ２は、呼処理機能部２２を制御することにより、所定時間内にセッション監視パケット１０に対して代理応答を行う。これにより、ＩＰ電話端末３−１及び３−２間で確立した呼は切断することがないので通話を継続することができる。

以上説明したように、第１の実施の形態によれば、ＳＩＰサーバ１の死活監視を行う呼救済サーバ２を設け、呼救済サーバ２は、ＩＰ電話網４を介して、ＩＰ電話端末３−１及び３−２からセッション監視パケット１０を受信するが、ＳＩＰサーバ１が正常に動作しているときは、セッション監視パケット１０に対して応答はしない。呼救済サーバ２が、ＳＩＰサーバ１の障害を検出したときは、ＳＩＰサーバ１に代わってセッション監視パケット１０に対して、ＩＰ電話端末３−１及び３−２宛に応答を行うようにしたので、ＩＰ電話端末３−１及び３−２間で確立した呼を切断することがなく、通話は継続することができる。

＜第２の実施の形態＞
次に第２の実施の形態について説明する。前記第１の実施の形態は、ＩＰ電話端末３−１及び３−２がリフレッシャとなってセッション監視パケット１０を送信し、ＳＩＰサーバ１に障害があると、呼救済サーバ２が代理に応答したのに対し、本実施の形態では、ＳＩＰサーバ１がリフレッシャとなってセッション監視パケット１０を送信し、ＳＩＰサーバ１に障害があると、呼救済サーバ２がＳＩＰサーバ１に代理してセッション監視パケット１０を送信するものである。以下の第２の実施の形態の構成は、前記第１の実施の形態の構成とほぼ同様であるが、異なる内容のみ説明する。

図１において、ＳＩＰサーバ１は、ＩＰ電話端末３−１及び３−２の呼を制御するとともに、呼が確立した通話呼の状態管理を行うための装置である。ＳＩＰサーバ１はルータ／ＳＷ５−１を経由してＩＰ電話網４に接続されている。ＩＰ電話端末３−１及び３−２間で確立した呼の監視のためのセッション監視パケット１０を、ＩＰ電話端末３−１及び３−２との間で送信と応答受信を行う。その際、本実施の形態においては、ＳＩＰサーバ１がリフレッシャとなって、セッション監視パケット１０をＩＰ電話端末３−１及び３−２と呼救済サーバ２に送信する。

ＩＰ電話端末３−１及び３−２はＳＩＰサーバ１により制御され、他のＩＰ電話端末３−１又は３−２間で通話を行うための装置である。ＩＰ電話端末３−１及び３−２は、ルータ／ＳＷ５−２を経由してＩＰ電話網４に接続されている。また、前記セッション監視パケット１０をＳＩＰサーバ１との間で送信と応答を行う。呼救済サーバ２は、本実施の形態において、ＳＩＰサーバ１に対する死活監視の結果、ＳＩＰサーバ１に障害が検出された場合は、ＳＩＰサーバ１に代わってセッション監視パケット１０を送信する。

図２において、ＳＩＰサーバ１の呼処理機能部１２は、前記第１の実施の形態で説明した各機能に加えて、セッション監視パケット１０に対する送信と応答の受信を行う。即ち、ＩＰ電話端末３−１及び３−２と呼救済サーバ２に対し、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行うためのセッション監視パケット１０をマルチキャストで送信する。そして、ＩＰ電話端末３−１又は３−２からの応答を受信する。

仮にＳＩＰサーバ１や伝送経路に障害があり、セッション監視パケット１０が相手側に到達せずタイマが切れた場合には、その呼は切断される。即ち、セッション監視パケット１０が所定時間内に到達しないＩＰ電話端末３−１又は３−２は、切断要求（ＢＹＥ）をＳＩＰサーバ１に送信し切断してしまう。また、ＳＩＰサーバ１からの切断要求（ＢＹＥ）をＩＰ電話端末３−１及び３−２へ送信することとしてもよい。

図３において、呼救済サーバ２の呼処理機能部２２は、セッション監視パケット１０を常時受信する。しかしながら、正常時は、受信したセッション監視パケット１０に対して応答は行わない。これは第１の実施の形態と同じである。本実施の形態では、前記装置管理機能部２１がＳＩＰサーバ１の障害発生を検出すると、呼処理機能部２２は、ＳＩＰサーバ１の代わりにセッション監視パケット１０の送信を行う。即ち、呼処理機能部２２は、セッション監視パケット１０を受信しているＩＰ電話端末３−１及び３−２に対して、ＳＩＰサーバ１に代理してセッション監視パケット１０の送信を行う。これによって、ＩＰ電話端末３−１及び３−２間で確立中の呼を切断することがなくなる。

図４において、ＩＰ電話端末３の呼制御部３３は、制御部３１の制御下で、他のＩＰ電話端末３−１又は３−２と通話をするために、ＳＩＰサーバ１との間で呼制御メッセージの生成や授受などを行う。更に、呼制御部３３は、制御部３１の制御により、ＳＩＰサーバ１から送信されるセッション監視パケット１０を受信する。そして、所定の時間以内に応答を送信する。更にまた、前回受信したセッション監視パケット１０から所定の時間内に次のセッション監視パケット１０を受信するかどうかを監視する。

次に、第２の実施の形態に関する動作を説明する。図７は、第２の実施の形態に関する呼救済システムの動作を示すシーケンスである。第２の実施の形態は、前述の通り、ＳＩＰサーバ１がセッション監視パケット１０のリフレッシャとなる場合である。なお、図示の○印はマルチキャストでのパケットの送出を意味する。

ステップ２０１：まず、例えばＩＰ電話端末３−１は、着信先をＩＰ電話端末３−２とする呼設定要求をＳＩＰサーバ１に送信する。ＳＩＰサーバ１はＩＰ電話端末３−１から呼設定要求を受け取ると、呼処理機能部１２が所定の呼制御プロトコルに従って着信先のＩＰ電話端末３−２との間で呼制御を行う。このような接続手順が行われることにより次に進む。
ステップ２０２：ＳＩＰサーバ１によって、ＩＰ電話端末３−１及び３−２との間の呼制御処理がなされ、呼が確立することにより通話が行われる。

ステップ２０３：ＳＩＰサーバ１の呼処理機能部１２は、正常時、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行うためのセッション監視パケット１０をマルチキャストで、ＩＰ電話端末３−１及び呼救済サーバ２に送信する。同時に、所定時間内に応答があるかどうか監視する。

ステップ２０４：ＳＩＰサーバ１からセッション監視パケット１０を受信したＩＰ電話端末３−１の呼制御部３３は、正常時、所定時間以内に応答を返信する。同時に、所定時間内に次のセッション監視パケット１０を受信するかどうか監視する。一方、同じくセッション監視パケット１０を受信した呼救済サーバ２の呼処理機能部２２は応答を行わない。

ステップ２０５：ＳＩＰサーバ１の呼処理機能部１２は、同様に正常時、次のセッション監視パケット１０をマルチキャストで、ＩＰ電話端末３−２及び呼救済サーバ２に送信する。同時に、所定時間内に応答があるかどうか監視する。

ステップ２０６：ＳＩＰサーバ１からセッション監視パケット１０を受信したＩＰ電話端末３−２の呼制御部３３は、正常時、所定時間以内に応答を返信する。同時に、所定時間内に次のセッション監視パケット１０を受信するかどうか監視する。同様に、セッション監視パケット１０を受信した呼救済サーバ２の呼処理機能部２２は応答を行わない。

ステップ２０７〜２１０：以下同様にＩＰ電話端末３−１及び３−２間の通話中、ＳＩＰサーバ１がリフレッシャとなって、次のセッション監視パケット１０を送信し、ＩＰ電話端末３−１及び３−２がこれに応答することにより、ＩＰ電話端末３−１及び３−２間で確立した呼の監視を行う。

ステップ２２０：一方、呼救済サーバ２は、装置管理機能部２１により、ＳＩＰサーバ１に対して常時死活監視を行っている。
ステップ２２１：ＩＰ電話端末３−１及び３−２間の通話中に、ＳＩＰサーバ１に障害が発生したとする。
ステップ２２２：前記ステップ２２１で発生したＳＩＰサーバ１の障害は、呼救済サーバ２の装置管理機能部２１よって検出される。

ステップ２２３：その後、ＳＩＰサーバ１はセッション監視パケット１０をマルチキャストで、ＩＰ電話端末３−１及び呼救済サーバ２に送信できなくなる。
ステップ２２４：呼救済サーバ２は、前記ステップ２２２により、装置管理機能部２１がＳＩＰサーバ１の障害を検出している。従って、呼救済サーバ２は、呼処理機能部２２を制御することにより、ＩＰ電話端末３−１に対して、ＳＩＰサーバ１に代わって所定の時間内にセッション監視パケット１０の送信を行う。
ステップ２２５：ＩＰ電話端末３−１は、呼救済サーバ２から送信されたセッション監視パケット１０を受信すると、所定の時間内に呼救済サーバ２に対して応答を行う。

ステップ２２６：同様に、ＳＩＰサーバ１は次のセッション監視パケット１０もＩＰ電話端末３−２及び呼救済サーバ２に送信できない。
ステップ２２７：呼救済サーバ２は、前記ステップ２２２により、装置管理機能部２１がＳＩＰサーバ１の障害を検出している。従って、呼救済サーバ２は、呼処理機能部２２を制御することにより、ＩＰ電話端末３−２に対して、所定の時間内に次のセッション監視パケット１０の代理送信を行う。
ステップ２２８：ＩＰ電話端末３−２は、呼救済サーバ２から送信されたセッション監視パケット１０を受信すると、所定の時間内に呼救済サーバ２に対して応答を行う。これにより、ＩＰ電話端末３−１及び３−２間で確立した呼は切断することがないので通話を継続することができる。

以上説明したように、第２の実施の形態によれば、ＳＩＰサーバ１の死活監視を行う呼救済サーバ２を設け、ＩＰ電話網４を介して、ＳＩＰサーバ１からセッション監視パケット１０を受信するが、ＳＩＰサーバ１が正常に動作しているときは、セッション監視パケット１０に対して応答はしないが、ＳＩＰサーバ１の障害を検出したときは、ＳＩＰサーバ１に代わってセッション監視パケット１０を送信するようにしたので、ＩＰ電話端末３−１及び３−２間で確立した呼を切断することがなく、通話は継続することができる。

なお、前記第１の実施の形態は、ＩＰ電話端末３−１及び３−２がリフレッシャとなってセッション監視パケット１０を送信するのに対し、第２の実施の形態では、ＳＩＰサーバ１がリフレッシャとなってセッション監視パケット１０を送信するが、両者は別々のプログラムによってもよく、プログラムの設定を変えることによってもよい。

１ ＳＩＰサーバ
２ 呼救済サーバ
３ ＩＰ電話端末
４ ＩＰ電話網
１０ セッション監視パケット

Claims (9)

1. ＳＩＰサーバ及び複数のＩＰ電話端末がＩＰ電話網に接続される呼救済システムにおいて、
   前記ＩＰ電話網を介して前記ＳＩＰサーバの死活監視を行う呼救済サーバを備え、
   前記ＳＩＰサーバと前記ＩＰ電話端末は、前記ＩＰ電話端末間で確立した呼の監視を行うセッション監視パケットの送信及び応答を行い、
   前記呼救済サーバは、前記ＩＰ電話網を介して前記セッション監視パケットを受信し、前記死活監視の結果、障害が検出された場合、前記セッション監視パケットの送信又は応答を行うことを特徴とする呼救済システム。
2. 前記セッション監視パケットは、前記ＩＰ電話端末がリフレッシャとなって、前記ＳＩＰサーバと前記呼救済サーバに対して、マルチキャストで送信することを特徴とする請求項１記載の呼救済システム。
3. 前記セッション監視パケットは、前記ＳＩＰサーバがリフレッシャとなって、前記ＩＰ電話端末と前記呼救済サーバに対して、マルチキャストで送信することを特徴とする請求項１記載の呼救済システム。
4. ＳＩＰサーバ及び複数のＩＰ電話端末が接続されるＩＰ電話網に収容され、
   更に、前記ＩＰ電話網を介して前記ＳＩＰサーバの死活監視を行う装置管理機能部と、
   前記ＩＰ電話端末間で確立した呼の監視を行うセッション監視パケットを、前記ＩＰ電話網を介して受信し、前記装置管理機能部による前記死活監視の結果、障害が検出された場合、前記ＳＩＰサーバに代わって前記セッション監視パケットの送信又は応答を行う呼処理機能部を備えることを特徴とする呼救済サーバ。
5. 前記セッション監視パケットは、前記ＩＰ電話端末がリフレッシャとなってマルチキャストで送信され、正常時、前記呼処理機能部がこれを受信することを特徴とする請求項４記載の呼救済サーバ。
6. 前記セッション監視パケットは、前記ＳＩＰサーバがリフレッシャとなってマルチキャストで送信され、正常時、前記呼処理機能部がこれを受信することを特徴とする請求項４記載の呼救済サーバ。
7. ＳＩＰサーバ及び複数のＩＰ電話端末が接続されるＩＰ電話網を介して、前記ＳＩＰサーバの死活監視を行うＳＩＰサーバ死活監視手順と、
   前記ＩＰ電話端末間で確立した呼の監視を行うセッション監視パケットを、前記ＩＰ電話網を介して受信する監視パケット受信手順と、
   前記ＳＩＰサーバ死活監視手順による死活監視の結果、障害が検出された場合、監視パケット受信手順で受信したセッション監視パケットに対する応答を行う監視パケット応答手順、又は次のセッション監視パケットの送信を行う監視パケット送信手順とをコンピュータに実行させるための呼救済サーバの呼救済プログラム。
8. 前記監視パケット応答手順において受信した前記セッション監視パケットは、前記ＩＰ電話端末がリフレッシャとなってマルチキャストで送信されるものであることを特徴とする請求項７記載の呼救済サーバの呼救済プログラム。
9. 前記監視パケット送信手順において、次に送信する前記セッション監視パケットの前に受信するセッション監視パケットは、前記ＳＩＰサーバがリフレッシャとなってマルチキャストで送信されるものであることを特徴とする請求項７記載の呼救済サーバの呼救済プログラム。
   
   

Images