(57)【要約】【課題】セッションの救済を確実に実行しつつ、迅速にサービスを再開すること。【解決手段】送受信部２１０は、ＳＩＰサーバ２００の異常検知後に受信されたＳＩＰ信号のコールＩＤを救済ファイル検索部２８０へ出力する。セッション制御部２２０は、救済ファイルに対応するセッション用の呼処理リソースおよびインスタンスを再確保し、改めて呼処理リソース情報およびインスタンス情報を主記憶部２３０に記憶させる。主記憶部２３０は、救済ファイルに含まれるセッション情報を改めて記憶する。救済ファイル作成部２４０は、救済ファイルを作成する。外部記憶部２５０は、救済ファイルを記憶する。救済ファイル検索部２８０は、送受信部２１０から出力されるコールＩＤに一致する救済ファイルを外部記憶部２５０から検索し、この救済ファイルをセッション制御部２２０および主記憶部２３０へ出力する。【選択図】        図２
2008103952.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ間の通信用に確立されるセッションを管理する通信管理装置であって、
ユーザ間のセッションを制御する信号を受信する受信手段と、
前記受信手段によって受信された信号に基づいてセッションの管理に利用されるセッションごとの情報を記憶する主記憶手段と、
前記主記憶手段によって記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記主記憶手段の外部に保持させる作成手段と、
前記通信管理装置の異常発生後に前記受信手段によって受信された信号に対応する救済ファイルを取得する取得手段と、
前記取得手段によって取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御手段と
を有することを特徴とする通信管理装置。
【請求項２】
前記通信管理装置の異常発生時に前記主記憶手段を初期化する初期化手段をさらに有することを特徴とする請求項１記載の通信管理装置。
【請求項３】
前記作成手段は、
前記主記憶手段によって記憶された情報のうちユーザへの課金に係る情報を含む救済ファイルを作成することを特徴とする請求項１記載の通信管理装置。
【請求項４】
第１のサーバおよび第２のサーバによる二重化構成を採り、通常時は前記第１のサーバが現用系としてユーザ間の通信用に確立されるセッションを管理する通信管理装置であって、
前記第１のサーバは、
ユーザ間のセッションを制御する信号を受信する受信手段と、
前記受信手段によって受信された信号に基づいてセッションの管理に利用されるセッションごとの情報を記憶する主記憶手段と、
前記主記憶手段によって記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記主記憶手段の外部に保持させる作成手段と、
前記作成手段によって救済ファイルが保持させられた後、前記第１のサーバに異常が発生すると、前記第２のサーバを現用系に切り替える切替手段とを有し、
前記第２のサーバは、
前記第２のサーバが現用系となった後、ユーザ間のセッションを制御する信号を受信する受信手段と、
前記受信手段によって受信された信号に対応する救済ファイルを取得する取得手段と、
前記取得手段によって取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御手段とを有する
ことを特徴とする通信管理装置。
【請求項５】
ユーザ間の通信用に確立されるセッションを管理する通信管理方法であって、
ユーザ間のセッションを制御する信号を受信する第１の受信工程と、
前記第１の受信工程にて受信された信号に基づいてセッションの管理に利用されるセッションごとの情報をメモリに記憶する記憶工程と、
前記記憶工程にて記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記メモリの外部に保持させる作成工程と、
前記通信管理装置の異常発生後にユーザ間のセッションを制御する信号を受信する第２の受信工程と、
前記第２の受信工程にて受信された信号に対応する救済ファイルを取得する取得工程と、
前記取得工程にて取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御工程と
を有することを特徴とする通信管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ間の通信用に確立されるセッションを管理する通信管理装置および通信管理方法に関し、特に、セッションの救済を確実に実行しつつ、迅速にサービスを再開することができる通信管理装置および通信管理方法に関する。
【背景技術】
【０００２】
従来、発信側と着信側との間で回線を確立してから通信を開始する回線交換型の通信方法においては、障害などが発生した場合でも回線が確立済みであった呼を救済する様々な方法が検討されている。例えば特許文献１においては、呼の救済に必要な情報をメモリに保持しておき、呼を復帰する際には、メモリに保持された情報を参照して呼を再開させることが記載されている。
【０００３】
このような処理は、例えばＳＩＰ（Session Initial Protocol：セッション開始プロトコル）などの通信制御プロトコルにおいてセッションを救済する場合にも同様に検討されている。以下、図８を参照して、ＳＩＰにおけるセッションの救済について簡単に説明する。
【０００４】
ＳＩＰにおいては複数の発ユーザと複数の着ユーザとの間のそれぞれのセッションが１つのＳＩＰサーバによって制御されている。図８は、これらのうちの１つのセッションが確立された後に、障害が発生してセッションが救済される様子を示すシーケンス図である。同図に示すように、セッション確立時には、発ユーザがセッション開始要求をＳＩＰサーバへ送信し（ステップＳ１）、ＳＩＰサーバは、このセッション開始要求を着ユーザへ転送する（ステップＳ２）。
【０００５】
着ユーザは、セッション開始要求を受信すると、セッション開始応答をＳＩＰサーバへ送信し（ステップＳ３）、ＳＩＰサーバは、このセッション開始応答を発ユーザへ転送する（ステップＳ４）。発ユーザは、セッション開始応答を受信すると、受信確認応答（ＡＣＫ）をＳＩＰサーバへ送信し（ステップＳ５）、ＡＣＫが着ユーザへ転送されて（ステップＳ６）、発ユーザと着ユーザの間のセッションが確立される。このとき、セッションの状態管理などのセッション制御に係る情報（以下「セッション制御情報」という）および確立されたセッションにおいて使用されるリソースの情報（以下「呼処理リソース情報」という）は、ＳＩＰサーバのメモリに保持される。
【０００６】
発ユーザと着ユーザは、確立されたセッションを用いて通信を行うが、例えばＳＩＰサーバの故障などにより異常が検知されると（ステップＳ７）、ＳＩＰサーバは、ＳＩＰサーバの動作を復旧させるための初期設定を行うとともに（ステップＳ８）、メモリに保持されているセッション制御情報から呼処理リソース情報を再生成し（ステップＳ９）、既に通信中として安定していたセッションの救済を図る。
【０００７】
こうしてセッションが救済された後は、定期的に発ユーザがセッション更新要求をＳＩＰサーバへ送信し（ステップＳ１０）、ＳＩＰサーバは、このセッション更新要求を着ユーザへ転送する（ステップＳ１１）。
【０００８】
着ユーザは、セッション更新要求を受信すると、セッション更新応答をＳＩＰサーバへ送信し（ステップＳ１２）、ＳＩＰサーバは、このセッション更新応答を発ユーザへ転送する（ステップＳ１３）。発ユーザは、セッション更新応答を受信すると、ＡＣＫをＳＩＰサーバへ送信し（ステップＳ１４）、ＡＣＫが着ユーザへ転送されて（ステップＳ１５）、発ユーザと着ユーザ間のセッションが存続していることが確認される。
【０００９】
【特許文献１】特開平７−１２３４５１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述のようなセッション救済時には、ＳＩＰサーバの初期設定と呼処理リソース情報の再生成が同時に行われるため、ＳＩＰサーバが復旧するまでの時間が遅延するという問題がある。すなわち、ＳＩＰサーバは、故障などの異常発生時に初期設定を実行するとともに、引き続きメモリに保持されるセッション制御情報から既に確立されていたセッションを救済するが、この一連の処理には比較的長時間を要し、ＳＩＰサーバの復旧に時間がかかる。そしてこの間、ＳＩＰサーバは、新たなセッション開始要求などを受け付けることができず、サービスの再開が遅延してしまう。
【００１１】
本発明はかかる点に鑑みてなされたものであり、セッションの救済を確実に実行しつつ、迅速にサービスを再開することができる通信管理装置および通信管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明は、ユーザ間の通信用に確立されるセッションを管理する通信管理装置であって、ユーザ間のセッションを制御する信号を受信する受信手段と、前記受信手段によって受信された信号に基づいてセッションの管理に利用されるセッションごとの情報を記憶する主記憶手段と、前記主記憶手段によって記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記主記憶手段の外部に保持させる作成手段と、前記通信管理装置の異常発生後に前記受信手段によって受信された信号に対応する救済ファイルを取得する取得手段と、前記取得手段によって取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御手段とを有することを特徴とする。
【００１３】
また、本発明は、上記発明において、前記通信管理装置の異常発生時に前記主記憶手段を初期化する初期化手段をさらに有することを特徴とする。
【００１４】
また、本発明は、上記発明において、前記作成手段は、前記主記憶手段によって記憶された情報のうちユーザへの課金に係る情報を含む救済ファイルを作成することを特徴とする。
【００１５】
また、本発明は、上記発明において、前記制御手段は、前記取得手段によって取得された救済ファイルに対応するセッションに割り当てる呼処理リソースを再確保することを特徴とする。
【００１６】
また、本発明は、上記発明において、前記制御手段は、前記取得手段によって取得された救済ファイルに対応するセッションの管理を行うインスタンスを再生成することを特徴とする。
【００１７】
また、本発明は、上記発明において、前記主記憶手段は、前記取得手段によって取得された救済ファイルに対応するセッションについて、この救済ファイルに含まれる情報を引き継いで記憶することを特徴とする。
【００１８】
また、本発明は、上記発明において、前記作成手段は、セッションの識別情報を含む救済ファイルを作成し、前記取得手段は、前記受信手段によって受信された信号に含まれる識別情報を抽出し、識別情報が一致する救済ファイルを取得することを特徴とする。
【００１９】
また、本発明は、上記発明において、前記作成手段は、セッションごとの救済ファイルを前記通信管理装置の外部に保持させることを特徴とする。
【００２０】
また、本発明は、第１のサーバおよび第２のサーバによる二重化構成を採り、通常時は前記第１のサーバが現用系としてユーザ間の通信用に確立されるセッションを管理する通信管理装置であって、前記第１のサーバは、ユーザ間のセッションを制御する信号を受信する受信手段と、前記受信手段によって受信された信号に基づいてセッションの管理に利用されるセッションごとの情報を記憶する主記憶手段と、前記主記憶手段によって記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記主記憶手段の外部に保持させる作成手段と、前記作成手段によって救済ファイルが保持させられた後、前記第１のサーバに異常が発生すると、前記第２のサーバを現用系に切り替える切替手段とを有し、前記第２のサーバは、前記第２のサーバが現用系となった後、ユーザ間のセッションを制御する信号を受信する受信手段と、前記受信手段によって受信された信号に対応する救済ファイルを取得する取得手段と、前記取得手段によって取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御手段とを有することを特徴とする。
【００２１】
また、本発明は、ユーザ間の通信用に確立されるセッションを管理する通信管理方法であって、ユーザ間のセッションを制御する信号を受信する第１の受信工程と、前記第１の受信工程にて受信された信号に基づいてセッションの管理に利用されるセッションごとの情報をメモリに記憶する記憶工程と、前記記憶工程にて記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記メモリの外部に保持させる作成工程と、前記通信管理装置の異常発生後にユーザ間のセッションを制御する信号を受信する第２の受信工程と、前記第２の受信工程にて受信された信号に対応する救済ファイルを取得する取得工程と、前記取得工程にて取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御工程とを有することを特徴とする。
【発明の効果】
【００２２】
本発明によれば、ユーザ間のセッションを制御する信号を受信し、受信された信号に基づいてセッションの管理に利用されるセッションごとの情報をメモリに記憶し、記憶された情報の一部を含むセッションごとの救済ファイルを作成してメモリの外部に保持させ、通信管理装置の異常発生後に受信された信号に対応する救済ファイルを取得し、取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する。このため、通信管理装置の異常が発生した場合にメモリを初期化して迅速に通信管理装置を復旧させることができるとともに、通信管理装置の復旧後、セッションを制御する信号が通信管理装置に受信されたセッションのみを救済ファイルを用いて救済することができる。結果として、セッションの救済を確実に実行しつつ、迅速にサービスを再開することができる。
【００２３】
また、本発明によれば、通信管理装置の異常発生時にメモリを初期化するため、確実に通信管理装置を復旧させ、サービスを再開することができる。
【００２４】
また、本発明によれば、メモリによって記憶された情報のうちユーザへの課金に係る情報を含む救済ファイルを作成するため、ユーザ間の通信開始後にメモリが初期化されても、救済ファイルを用いることにより通信開始時からの通信について正確に課金することができる。
【００２５】
また、本発明によれば、取得された救済ファイルに対応するセッションに割り当てる呼処理リソースを再確保するため、通信開始時に確保された呼処理リソースの情報がメモリから消去されても、新たに呼処理リソースを確保してセッションを継続することができる。
【００２６】
また、本発明によれば、取得された救済ファイルに対応するセッションの管理を行うインスタンスを再生成するため、通信開始時に生成されたインスタンスの情報がメモリから消去されても、新たにインスタンスを生成してセッションを継続することができる。
【００２７】
また、本発明によれば、取得された救済ファイルに対応するセッションについて、この救済ファイルに含まれる情報を引き継いで記憶するため、通信管理装置の異常が発生した場合にメモリが初期化されても、事後にメモリを異常発生前の状態に復帰させることができる。
【００２８】
また、本発明によれば、セッションの識別情報を含む救済ファイルを作成し、受信された信号に含まれる識別情報を抽出し、識別情報が一致する救済ファイルを取得するため、通信管理装置の異常発生後に受信された信号に対応する救済ファイルを確実に取得し、通信を継続する意志があるユーザ間のセッションを救済することができる。
【００２９】
また、本発明によれば、セッションごとの救済ファイルを通信管理装置の外部に保持させるため、異常が発生した通信管理装置以外の通信管理装置でも救済ファイルを用いてセッションを救済することができ、サービスの信頼性をさらに向上することができる。
【００３０】
また、本発明によれば、第１のサーバが、ユーザ間のセッションを制御する信号を受信し、受信された信号に基づいてセッションの管理に利用されるセッションごとの情報をメモリに記憶し、記憶された情報の一部を含むセッションごとの救済ファイルを作成してメモリの外部に保持させ、救済ファイルが保持させられた後、第１のサーバに異常が発生すると、第２のサーバを現用系に切り替え、第２のサーバが、現用系となった後、ユーザ間のセッションを制御する信号を受信し、受信された信号に対応する救済ファイルを取得し、取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する。このため、第１のサーバの異常が発生した場合に第２のサーバを現用系として迅速にサービスを再開させることができるとともに、第２のサーバが現用系となった後、セッションを制御する信号が第２のサーバに受信されたセッションを救済ファイルを用いて救済することができる。結果として、セッションの救済を確実に実行しつつ、迅速にサービスを再開することができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の一実施の形態について、図面を参照して詳細に説明する。以下においては、ＳＩＰにおける通信を例に挙げて説明するが、本発明は、ＳＩＰ以外のプロトコルであってシグナリングによってセッションを確立するプロトコルであれば適用することができる。
【００３２】
図１は、本実施の形態における通信システムの概略構成を示す図である。同図に示すように、本実施の形態においては、発ユーザ１００−１〜１００−３がＳＩＰサーバ２００を介して着ユーザ３００−１〜３００−３とセッションを確立した上で、音声通話やテレビ電話などの通信を行うものとする。なお、ＳＩＰサーバ２００が収容する発ユーザおよび着ユーザの数は３ユーザに限定されることはない。
【００３３】
このような通信システムにおいて、例えば発ユーザ１００−１が着ユーザ３００−１との通信を希望する場合には、発ユーザ１００−１からセッションの開始を要求するセッション開始要求が送信され、ＳＩＰサーバ２００は、このセッション開始要求を着ユーザ３００−１へ転送する。そして、セッション開始要求を受信した着ユーザ３００−１からセッションの開始を許可するセッション開始応答が送信され、ＳＩＰサーバ２００は、このセッション開始応答を発ユーザ１００−１へ転送する。発ユーザ１００−１がセッション開始応答を受信すると、受信確認応答であるＡＣＫが発ユーザ１００−１からＳＩＰサーバ２００を介して着ユーザ３００−１へ返送され、セッションが確立される。
【００３４】
以後、発ユーザ１００−１と着ユーザ３００−１は、確立されたセッションを利用して通信を行う。このとき、発ユーザ１００−１と着ユーザ３００−１の間で確立されたセッションが存続していることを確認するために、定期的に発ユーザ１００−１からセッション更新要求が送信され、ＳＩＰサーバ２００は、このセッション更新要求を着ユーザ３００−１へ転送する。その後、セッション開始要求の送信時と同様に、セッション更新応答およびＡＣＫが発ユーザ１００−１と着ユーザ３００−１の間でやり取りされ、セッションが存続していることが確認される。
【００３５】
また、通信を終了する場合には、セッションの切断を要求するセッション切断要求とこのセッション切断要求に対する応答のセッション切断応答とが発ユーザ１００−１および着ユーザ３００−１の間でやり取りされ、セッションが切断されることになる。その他の発ユーザ１００−２、１００−３および着ユーザ３００−２、３００−３における通信も発ユーザ１００−１と着ユーザ３００−１の間の通信と同様に行われる。なお、以下では、セッション確立時に発信する発ユーザ１００−１〜１００−３を代表して単に「発ユーザ１００」といい、セッション確立時に着信する着ユーザ３００−１〜３００−３を代表して単に「着ユーザ３００」という。
【００３６】
本実施の形態においては、ＳＩＰサーバ２００は、セッションの確立時に、例えば発ユーザおよび着ユーザの情報や発信時刻の情報などのセッションの救済に必要となる情報を救済ファイルとしてハードディスクなどの外部記憶に記憶しておく。そして、例えばＳＩＰサーバ２００の故障などの異常が検知されると、ＳＩＰサーバ２００は、復旧のために主記憶であるメモリを初期化し、サービスを再開する。その後、既に確立済みであったセッションにおいて、発ユーザまたは着ユーザから例えばセッション更新要求やセッション更新応答などのＳＩＰ信号が送信されると、ＳＩＰサーバ２００は、これらのＳＩＰ信号を受信する。そして、ＳＩＰサーバ２００は、ＳＩＰ信号が受信されたセッションについてのみ外部記憶に記憶された救済ファイルを用いて、呼処理リソース情報を新たにメモリ上に生成し、このセッションを異常発生前の状態に復帰させる。
【００３７】
図２は、本実施の形態に係るＳＩＰサーバ２００の要部構成を示すブロック図である。図２に示すＳＩＰサーバ２００は、送受信部２１０、セッション制御部２２０、主記憶部２３０、救済ファイル作成部２４０、外部記憶部２５０、異常検知部２６０、初期化処理部２７０、および救済ファイル検索部２８０を有している。
【００３８】
送受信部２１０は、発ユーザ１００および着ユーザ３００から送信されるＳＩＰ信号を受信し、必要に応じてセッション制御部２２０の指示に従い、ＳＩＰ信号を着ユーザ３００および発ユーザ１００へ転送する。具体的には、送受信部２１０は、発ユーザ１００から送信されるセッション開始要求およびセッション更新要求や、着ユーザ３００から送信されるセッション開始応答およびセッション更新応答などのＳＩＰ信号を受信し、これらのＳＩＰ信号を着ユーザ３００または発ユーザ１００へ転送する。また、送受信部２１０は、ＳＩＰサーバ２００の異常検知後にＳＩＰ信号を受信すると、このＳＩＰ信号に含まれるセッションごとに固有のコールＩＤを抽出し、このコールＩＤが異常検知後に初めて抽出されたものである場合には、救済ファイル検索部２８０へ出力する。
【００３９】
セッション制御部２２０は、送受信部２１０によって受信されるＳＩＰ信号の種類に応じてセッションの確立や切断などを制御する。このとき、セッション制御部２２０は、セッションごとの作業領域としてインスタンスを生成し、各セッションの状態を対応するインスタンスにおいて管理する。すなわち、セッション制御部２２０は、例えばＳＩＰ信号の宛先の分析などをそれぞれのセッションに対応して生成されたインスタンスにおいて実行する。また、セッション制御部２２０は、セッション確立時に確保されるセッションごとの呼処理リソースを示す呼処理リソース情報、セッションごとの発ユーザ、着ユーザ、および発信時刻などセッションの内容を示すセッション情報、およびセッションごとのインスタンス情報を主記憶部２３０に記憶させる。
【００４０】
さらに、セッション制御部２２０は、送受信部２１０において着ユーザ３００からセッション開始応答が受信されると、セッションの救済に備えて救済ファイルを作成するように救済ファイル作成部２４０へ指示する。また、セッション制御部２２０は、救済ファイル検索部２８０から救済ファイルが出力されると、救済ファイルに対応するセッションの呼処理リソースを再確保するとともに、このセッションの管理に使用されるインスタンスを再度生成し、改めて呼処理リソース情報およびインスタンス情報を主記憶部２３０に記憶させる。
【００４１】
主記憶部２３０は、セッション制御部２２０におけるセッション管理に用いられる情報を記憶するメモリであり、セッション確立時にセッションごとの呼処理リソース情報、セッション情報、およびインスタンス情報を記憶する。また、主記憶部２３０は、救済ファイル検索部２８０から救済ファイルが出力されると、救済ファイルに含まれるセッション情報を改めて記憶する。
【００４２】
救済ファイル作成部２４０は、セッション制御部２２０から救済ファイルの作成が指示されると、セッションの発着ユーザ、発信時刻、および通話開始時刻などを含むセッション情報を主記憶部２３０から読み出し、セッションごとのコールＩＤに対応付けてセッションごとの救済ファイルを作成する。そして、救済ファイル作成部２４０は、作成した救済ファイルを外部記憶部２５０に記憶させる。なお、救済ファイル作成部２４０が作成する救済ファイルには、上記のセッション情報以外にも、例えばユーザへの課金に必要な情報などが含まれている。
【００４３】
外部記憶部２５０は、例えばハードディスクやフラッシュメモリなどの外部記憶装置であり、救済ファイル作成部２４０によって作成された救済ファイルを記憶する。すなわち、外部記憶部２５０は、例えば図３に示すように、各セッションのコールＩＤに発着ユーザ、発信時刻、および通話開始時刻などが対応付けられた救済ファイルを記憶する。外部記憶部２５０は外部記憶装置であるため、ＳＩＰサーバ２００の外部に独立して設けることも可能である。
【００４４】
異常検知部２６０は、ＳＩＰサーバ２００において発生する故障などの異常を検知し、異常が検知された場合には、その旨を初期化処理部２７０へ通知する。
【００４５】
初期化処理部２７０は、異常検知部２６０から異常が検知された旨が通知されると、主記憶部２３０を初期化して、主記憶部２３０に記憶された情報を消去する。すなわち、初期化処理部２７０は、ＳＩＰサーバ２００に異常が発生した場合、既に記憶されているセッションごとの呼処理リソース情報、セッション情報、およびインスタンス情報を主記憶部２３０から消去することにより、新たなセッション開始要求の受け付けを可能にし、迅速なサービスの再開を図る。
【００４６】
救済ファイル検索部２８０は、送受信部２１０から出力されるコールＩＤに一致する救済ファイルを外部記憶部２５０から検索し、該当する救済ファイルが外部記憶部２５０に記憶されている場合には、この救済ファイルをセッション制御部２２０および主記憶部２３０へ出力する。また、救済ファイル検索部２８０は、送受信部２１０から出力されるコールＩＤに一致する救済ファイルが外部記憶部２５０に記憶されていない場合には、エラーが発生したものとしてエラー信号を送受信部２１０から送信させる。
【００４７】
次いで、上記のように構成されたＳＩＰサーバ２００のよる発ユーザ１００および着ユーザ３００間のセッション開始時の動作について、図４に示すフロー図を参照しながら説明する。
【００４８】
セッション開始時には、上述したように発ユーザ１００と着ユーザ３００の間でセッション開始要求およびセッション開始応答の２種類のＳＩＰ信号がやり取りされる。ここでやり取りされるＳＩＰ信号は、ＳＩＰサーバ２００の送受信部２１０によって受信され（ステップＳ１０１）、ＳＩＰ信号の種類が発ユーザ１００から送信されたセッション開始要求であるか否かが判定される（ステップＳ１０２）。
【００４９】
ここでは、ＳＩＰ信号がセッション開始要求であるものとすると（ステップＳ１０２Ｙｅｓ）、セッション開始要求が受信された旨がセッション制御部２２０へ通知され、セッション制御部２２０によって、着ユーザ３００へセッション開始要求を転送する旨の指示が送受信部２１０へ出される。この指示を受け、セッション開始要求が送受信部２１０から着ユーザ３００へ送信される（ステップＳ１０３）。また、セッション制御部２２０において、新たに開始されるセッションの管理のためのインスタンスが生成されるとともに、このセッションのための呼処理リソースが確保され（ステップＳ１０４）、インスタンス情報および呼処理リソース情報が主記憶部２３０に記憶される。また、セッション情報のうち、セッション開始要求から判明する発着ユーザおよび発信時刻などの情報がコールＩＤに対応付けられて主記憶部２３０に記憶される。
【００５０】
こうしてセッション確立の準備が整えられ、着ユーザ３００へセッション開始要求が転送されると、セッション開始要求に対する応答としてセッション開始応答が着ユーザ３００から送信される。セッション開始応答がＳＩＰサーバ２００の送受信部２１０によって受信されると、このＳＩＰ信号がセッション開始要求ではないため（ステップＳ１０２Ｎｏ）、引き続き送受信部２１０によって、セッション開始応答が受信されたか否かが判定される（ステップＳ１０５）。ここでＳＩＰ信号がセッション開始応答でなければ（ステップＳ１０５Ｎｏ）、このＳＩＰ信号はセッションの開始に関するものではないと考えられるため、セッション開始時の動作は終了する。
【００５１】
ここでは、ＳＩＰ信号がセッション開始応答であるので（ステップＳ１０５Ｙｅｓ）、セッション開始応答が受信された旨がセッション制御部２２０へ通知され、セッション制御部２２０によって、発ユーザ１００へセッション開始応答を転送する旨の指示が送受信部２１０へ出される。この指示を受け、セッション開始応答が送受信部２１０から発ユーザ１００へ送信される（ステップＳ１０６）。また、セッション開始応答の転送によってセッションが確立されて発着ユーザ間の通話が開始されるため、主記憶部２３０に記憶されたセッション情報に通話開始時刻などの情報が追加される。
【００５２】
さらに、着ユーザ３００からのセッション開始応答が受信されたため、救済ファイルの作成がセッション制御部２２０から救済ファイル作成部２４０へ指示され、救済ファイル作成部２４０によって、主記憶部２３０に記憶されたセッション情報が取得されて救済ファイルが作成される。すなわち、救済ファイル作成部２４０によって、発着ユーザ、発信時刻、および通話開始時刻などの課金に必要な情報が主記憶部２３０から取得され、これらの情報がコールＩＤに対応付けられた救済ファイルが作成される。こうして作成された救済ファイルは、外部記憶部２５０に記憶される（ステップＳ１０７）。これにより、外部記憶部２５０には、例えば図３に示したように、コールＩＤに発着ユーザ、発信時刻、および通話開始時刻などが対応付けられたセッションごとの救済ファイルが記憶されることになる。
【００５３】
こうしてセッション救済の準備が整えられ、発ユーザ１００へセッション開始応答が転送されると、さらに発ユーザ１００から着ユーザ３００へセッション開始応答に対するＡＣＫが送信され、発ユーザ１００と着ユーザ３００の間のセッションが確立される。そして、セッション制御部２２０のセッションに対応するインスタンスにおいて、確立されたセッションの管理が開始される（ステップＳ１０８）。具体的には、セッション制御部２２０のインスタンスにおいて、発ユーザ１００と着ユーザ３００の間でやり取りされる信号の宛先分析などが行われる。また、セッションの確立後、定期的に発ユーザ１００から送信されるセッション更新要求が送受信部２１０によって受信されると、セッションが存続していることを確認するため、セッション制御部２２０のインスタンスにおいて、セッション更新要求およびセッション更新応答の転送が制御される。
【００５４】
次に、ＳＩＰサーバ２００の故障などの異常が検知された場合に、確立済みのセッションを救済する動作について、図５に示すフロー図を参照しながら説明する。
【００５５】
ＳＩＰサーバ２００において異常が発生すると、異常検知部２６０によって異常が検知され（ステップＳ２０１）、その旨が初期化処理部２７０へ通知される。そして、初期化処理部２７０によって、主記憶部２３０が初期化され、主記憶部２３０に記憶されている呼処理リソース情報、セッション情報、およびインスタンス情報が消去される（ステップＳ２０２）。主記憶部２３０が初期化されることにより、ＳＩＰサーバ２００は初期状態に戻り、セッション開始要求を受け付けて新たにセッションを確立することが可能になる。換言すれば、主記憶部２３０の初期化が行われると、確立済みのセッション救済前にＳＩＰサーバ２００が復旧し、迅速にサービスを再開することができる。
【００５６】
ＳＩＰサーバ２００が復旧すると、送受信部２１０によってＳＩＰ信号を受信することが可能になるため、ＳＩＰ信号の受信が待機される（ステップＳ２０３）。ここでは、例えばセッション更新要求など、特に確立済みのセッションに関するＳＩＰ信号の受信が待機され、新たなセッション開始要求などが受信された場合には、上述したセッション開始時の動作が行われる。セッション更新要求などのＳＩＰ信号が送受信部２１０によって受信されると（ステップＳ２０３Ｙｅｓ）、異常検知部２６０によって異常が検知された後であることから、送受信部２１０によってＳＩＰ信号に含まれるコールＩＤが抽出され、このコールＩＤが異常検知後に初めて抽出されたものであれば、救済ファイル検索部２８０へ出力される。なお、コールＩＤが異常検知後に既に抽出されたものであれば、このコールＩＤに対応するセッションは既に救済されていると考えられるため、通常通りセッション制御部２２０のインスタンスにおけるセッション管理が行われる。
【００５７】
救済ファイル検索部２８０へコールＩＤが出力されると、救済ファイル検索部２８０によって、外部記憶部２５０に記憶された救済ファイルの中からコールＩＤが一致する救済ファイルが検索される（ステップＳ２０４）。この結果、コールＩＤが一致する救済ファイルが外部記憶部２５０に記憶されていなければ（ステップＳ２０４Ｎｏ）、このコールＩＤに対応するセッションは救済不可能であると判断され、エラー処理が実行される（ステップＳ２０８）。具体的には、救済ファイル検索部２８０の指示によって、セッション救済が不可能である旨のエラー信号が送受信部２１０から異常検知後にＳＩＰ信号を送信したユーザへ送信される。
【００５８】
エラー信号を受信するユーザは、セッションの救済が不可能であることを把握するため、再度セッション開始要求を送信して、新たにセッションを確立することになる。このようなエラーが発生するケースとしては、例えばセッション開始要求が着ユーザ３００へ転送された後、着ユーザ３００からのセッション開始応答が転送される前にＳＩＰサーバ２００が故障する場合などが考えられる。すなわち、このようなケースにおいては、セッション開始応答が転送されていないため、救済ファイル作成部２４０によって救済ファイルが作成されておらず、外部記憶部２５０に救済ファイルが記憶されていない。このため、ＳＩＰサーバ２００が復旧して着ユーザ３００からセッション開始応答が受信されても、セッション開始応答に含まれるコールＩＤと一致する救済ファイルが外部記憶部２５０に記憶されておらず、改めて最初からセッションの確立が行われることになる。
【００５９】
一方、異常検知後に受信されたＳＩＰ信号に含まれるコールＩＤと一致する救済ファイルが外部記憶部２５０に記憶されていれば（ステップＳ２０４Ｙｅｓ）、この救済ファイルが救済ファイル検索部２８０によって読み出され、セッション制御部２２０および主記憶部２３０へ出力される。そして、セッション制御部２２０によって、この救済ファイルに対応するセッションのためのインスタンスが再生成されるとともに、呼処理リソースが再確保される（ステップＳ２０５）。これらの呼処理リソース情報およびインスタンス情報は、改めて主記憶部２３０に記憶され、ＳＩＰサーバ２００における異常検知前に確立済みであったセッションの管理が可能となる。また、救済ファイルに含まれる発着ユーザや発信時刻などのセッション情報が主記憶部２３０に展開され（ステップＳ２０６）、インスタンスや呼処理リソースは異常検知後に改めて確保されるものの、課金に関する情報などは異常検知前のセッション確立時からの状態が引き継がれる。
【００６０】
これにより、確立済みのセッションに関して主記憶部２３０に記憶される情報がＳＩＰサーバ２００の異常検知前の状態に復帰し、セッションが救済されることになるため、セッション制御部２２０において再生成されたインスタンスにおけるセッションの管理が再開される（ステップＳ２０７）。また、このセッションの管理は、ＳＩＰサーバ２００の異常検知後に、ＳＩＰ信号が受信されたことを契機として再開されているため、異常検知後にＳＩＰ信号を送信せずセッションの継続の意志がないユーザ間のセッションは救済されない。したがって、無駄にセッションを救済することがなく、ＳＩＰサーバ２００の復旧後のセッション救済による処理負荷を軽減することができる。
【００６１】
なお、上記の説明ではＳＩＰサーバ２００の異常検知後に受信されたＳＩＰ信号のコールＩＤに一致する救済ファイルのセッションのみが救済されるものとしたが、例えば外部記憶部２５０に記憶される救済ファイルをグループ化しておき、グループ内のいずれかの救済ファイルを用いてセッションが救済される際に、グループ内のすべてのセッションが同時に救済されるようにしても良い。すなわち、セッションごとの救済ファイルを例えば発ユーザ１００が同一地域や同一企業のものごとにグループ化して外部記憶部２５０に記憶しておき、救済ファイル検索部２８０によって外部記憶部２５０から救済ファイルが取得される際に、同一グループに属するすべての救済ファイルが取得されるようにしておく。こうすることにより、同一地域や同一企業から発信されて確立されていたセッションが一斉に救済されることになり、効率的にセッション救済を実行することができる。
【００６２】
次に、発ユーザ１００と着ユーザ３００の間のセッション確立後にＳＩＰサーバ２００が故障し、セッションが救済される際の一連の処理の例について、図６に示すシーケンス図を参照しながら説明する。
【００６３】
セッション確立時には、まず、発ユーザ１００からセッション開始要求がＳＩＰサーバ２００へ送信され（ステップＳ３０１）、ＳＩＰサーバ２００の送受信部２１０によって受信される。送受信部２１０によってセッション開始要求が受信されると、セッション制御部２２０によって、セッションに割り当てるインスタンスが生成され呼処理リソースが確保されるとともに、送受信部２１０からセッション開始要求が着ユーザ３００へ転送される（ステップＳ３０２）。
【００６４】
着ユーザ３００によってセッション開始要求が受信されると、セッション開始要求に応答するセッション開始応答がＳＩＰサーバ２００へ送信され（ステップＳ３０３）、ＳＩＰサーバ２００の送受信部２１０によって受信される。送受信部２１０によってセッション開始応答が受信されると、セッション制御部２２０によって通話開始時刻などのセッション情報が主記憶部２３０に記憶されるとともに、送受信部２１０からセッション開始応答が発ユーザ１００へ転送される（ステップＳ３０４）。また、セッション制御部２２０からセッション開始応答が受信された旨が救済ファイル作成部２４０へ通知され、救済ファイル作成部２４０によって主記憶部２３０から必要な情報が読み出され、セッションの救済ファイルが作成される（ステップＳ３０５）。作成された救済ファイルは、外部記憶部２５０に記憶される。
【００６５】
ＳＩＰサーバ２００から転送されたセッション開始応答が発ユーザ１００によって受信されると、発ユーザ１００からＳＩＰサーバ２００へＡＣＫが送信され（ステップＳ３０６）、さらにＳＩＰサーバ２００から着ユーザ３００へＡＣＫが転送される（ステップＳ３０７）。これにより、発ユーザ１００と着ユーザ３００の間のセッションが確立され、ＳＩＰサーバ２００のセッション制御部２２０におけるセッション対応のインスタンスにおいては、セッションの管理が開始され（ステップＳ３０８）、発ユーザ１００と着ユーザ３００が通信中となる。
【００６６】
発ユーザ１００と着ユーザ３００の通信中に、ＳＩＰサーバ２００が故障するなどの異常が発生すると、異常検知部２６０によって異常の発生が検知され（ステップＳ３０９）、その旨が初期化処理部２７０へ通知される。そして、初期化処理部２７０によって、主記憶部２３０が初期化され（ステップＳ３１０）、主記憶部２３０に記憶された確立済みのセッションの呼処理リソース情報、セッション情報、およびインスタンス情報が消去される。この時点で、主記憶部２３０が初期状態に戻るため、ＳＩＰサーバ２００はサービスを再開することができ、発ユーザ１００や着ユーザ３００から送信されるＳＩＰ信号を受信することが可能となる。
【００６７】
一方、発ユーザ１００と着ユーザ３００は既に確立されたセッションによって通信を行っているため、セッションの存続を確認するためのセッション更新要求が発ユーザ１００から定期的にＳＩＰサーバ２００へ送信され（ステップＳ３１１）、ＳＩＰサーバ２００では上述のようにＳＩＰ信号を受信することが可能となっているため、発ユーザ１００から送信されたセッション更新要求が送受信部２１０によって受信される。送受信部２１０によってセッション更新要求が受信されると、ＳＩＰサーバ２００の異常検知後であることから、セッション更新要求に含まれるコールＩＤが抽出され、抽出されたコールＩＤが異常検知後に初めて抽出されたものであるか否かが判定される。
【００６８】
ここでは、このセッション更新要求が異常検知後に発ユーザ１００から初めて受信したＳＩＰ信号であるため、抽出されるコールＩＤも初めて抽出されたものであり、コールＩＤが救済ファイル検索部２８０へ出力される。そして、救済ファイル検索部２８０によって、コールＩＤが一致する救済ファイルが外部記憶部２５０に記憶された救済ファイルの中から検索され、コールＩＤが一致する救済ファイルがセッション制御部２２０および主記憶部２３０へ出力されて展開される（ステップＳ３１２）。すなわち、セッション制御部２２０によって、救済ファイルに対応するセッションのためのインスタンスが再生成され呼処理リソースが再確保されるとともに、救済ファイルに含まれるセッションの発着ユーザや発信時刻などの情報が主記憶部２３０に改めて記憶される。これにより、発ユーザ１００と着ユーザ３００の間のセッションについては、主記憶部２３０に記憶される情報がＳＩＰサーバ２００の異常検知前の状態に復帰し、課金に必要な情報などについては、異常検知前のセッション確立時点からの状態が引き継がれることになる。換言すれば、発ユーザ１００と着ユーザ３００の間のセッションが救済されたことになる。
【００６９】
その後、送受信部２１０に受信されたセッション更新要求が着ユーザ３００へ転送され（ステップＳ３１３）、セッション更新要求に応答するセッション更新応答が着ユーザ３００からＳＩＰサーバ２００へ送信され（ステップＳ３１４）、さらに、セッション更新応答がＳＩＰサーバ２００から発ユーザ１００へ転送される（ステップＳ３１５）。ＳＩＰサーバ２００から転送されたセッション更新応答が発ユーザ１００によって受信されると、発ユーザ１００からＳＩＰサーバ２００へＡＣＫが送信され（ステップＳ３１６）、ＳＩＰサーバ２００から着ユーザ３００へＡＣＫが転送される（ステップＳ３１７）。これにより、発ユーザ１００と着ユーザ３００の間のセッションが存続していることが確認され、ＳＩＰサーバ２００のセッション制御部２２０で再生成されたインスタンスにおいては、セッションの管理が再開される（ステップＳ３１８）。
【００７０】
以上のように、本実施の形態によれば、セッション確立時にセッションの救済に必要な情報を救済ファイルとして外部記憶しておき、異常発生時には、主記憶を初期化してＳＩＰサーバの復旧を図る。そして、異常発生後、ＳＩＰ信号が受信されたことを契機として、このＳＩＰ信号の送信元のユーザに関するセッションについて外部記憶された救済ファイルを取得し、改めてインスタンスや呼処理リソースを確保するとともに、課金に関する情報などはセッション確立時点からの状態を引き継ぐ。このため、セッションに関する主記憶の状態を異常発生前の状態に復帰させ、セッションを確実に救済することができる。そして、異常発生時には、セッションの救済を待機することなくＳＩＰサーバのサービスを再開することができるため、セッションの救済を確実に実行しつつ、迅速にサービスを再開することができる。
【００７１】
なお、上記一実施の形態において、通信管理の信頼性を向上するために、ＳＩＰサーバ２００の二重化構成が採られることがある。すなわち、現用系のＳＩＰサーバ２００と予備系のＳＩＰサーバ２００とが設置され、現用系のＳＩＰサーバ２００に異常が発生した場合には系が切り替えられて、セッションの制御が継続されることがある。このような二重化構成が採られる場合に本発明を適用する際の変形例を図７に示す。図７においては、予備系のＳＩＰサーバ２００の内部構成は、現用系のＳＩＰサーバ２００の内部構成と同一であるため、図示を省略している。
【００７２】
図７に示すように、現用系のＳＩＰサーバ２００と予備系のＳＩＰサーバ２００とが設けられる場合は、救済ファイルを記憶する外部記憶部２５０をそれぞれのＳＩＰサーバ２００が共用する。したがって、現用系のＳＩＰサーバ２００内の救済ファイル作成部２４０によって作成された救済ファイルが外部記憶部２５０に記憶されると、この救済ファイルは、予備系のＳＩＰサーバ２００からも参照することが可能となる。そして、現用系のＳＩＰサーバ２００に異常が発生し、予備系が現用系に切り替えられると、新たに現用系となったＳＩＰサーバ２００は、外部記憶部２５０に記憶された救済ファイルを用いてセッションを救済する。
【００７３】
このように救済ファイルを共用の外部記憶部２５０に記憶しておくことにより、系の切り替えが発生した場合にも適正にセッションを救済することができる。また、セッションの救済に必要な情報が救済ファイルとして外部記憶部２５０に記憶されているため、現用系のＳＩＰサーバ２００の主記憶部２３０に記憶される情報を逐一予備系のＳＩＰサーバ２００の主記憶部２３０へ転送する必要がない。なお、外部記憶部２５０は、現用系のＳＩＰサーバ２００および予備系のＳＩＰサーバ２００の外部に設けられていても良く、いずれか一方のＳＩＰサーバ２００の内部に設けられていても良い。
【００７４】
（付記１）ユーザ間の通信用に確立されるセッションを管理する通信管理装置であって、
ユーザ間のセッションを制御する信号を受信する受信手段と、
前記受信手段によって受信された信号に基づいてセッションの管理に利用されるセッションごとの情報を記憶する主記憶手段と、
前記主記憶手段によって記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記主記憶手段の外部に保持させる作成手段と、
前記通信管理装置の異常発生後に前記受信手段によって受信された信号に対応する救済ファイルを取得する取得手段と、
前記取得手段によって取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御手段と
を有することを特徴とする通信管理装置。
【００７５】
（付記２）前記通信管理装置の異常発生時に前記主記憶手段を初期化する初期化手段をさらに有することを特徴とする付記１記載の通信管理装置。
【００７６】
（付記３）前記作成手段は、
前記主記憶手段によって記憶された情報のうちユーザへの課金に係る情報を含む救済ファイルを作成することを特徴とする付記１記載の通信管理装置。
【００７７】
（付記４）前記制御手段は、
前記取得手段によって取得された救済ファイルに対応するセッションに割り当てる呼処理リソースを再確保することを特徴とする付記１記載の通信管理装置。
【００７８】
（付記５）前記制御手段は、
前記取得手段によって取得された救済ファイルに対応するセッションの管理を行うインスタンスを再生成することを特徴とする付記１記載の通信管理装置。
【００７９】
（付記６）前記主記憶手段は、
前記取得手段によって取得された救済ファイルに対応するセッションについて、この救済ファイルに含まれる情報を引き継いで記憶することを特徴とする付記１記載の通信管理装置。
【００８０】
（付記７）前記作成手段は、
セッションの識別情報を含む救済ファイルを作成し、
前記取得手段は、
前記受信手段によって受信された信号に含まれる識別情報を抽出し、識別情報が一致する救済ファイルを取得することを特徴とする付記１記載の通信管理装置。
【００８１】
（付記８）前記作成手段は、
セッションごとの救済ファイルを前記通信管理装置の外部に保持させることを特徴とする付記１記載の通信管理装置。
【００８２】
（付記９）第１のサーバおよび第２のサーバによる二重化構成を採り、通常時は前記第１のサーバが現用系としてユーザ間の通信用に確立されるセッションを管理する通信管理装置であって、
前記第１のサーバは、
ユーザ間のセッションを制御する信号を受信する受信手段と、
前記受信手段によって受信された信号に基づいてセッションの管理に利用されるセッションごとの情報を記憶する主記憶手段と、
前記主記憶手段によって記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記主記憶手段の外部に保持させる作成手段と、
前記作成手段によって救済ファイルが保持させられた後、前記第１のサーバに異常が発生すると、前記第２のサーバを現用系に切り替える切替手段とを有し、
前記第２のサーバは、
前記第２のサーバが現用系となった後、ユーザ間のセッションを制御する信号を受信する受信手段と、
前記受信手段によって受信された信号に対応する救済ファイルを取得する取得手段と、
前記取得手段によって取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御手段とを有する
ことを特徴とする通信管理装置。
【００８３】
（付記１０）ユーザ間の通信用に確立されるセッションを管理する通信管理方法であって、
ユーザ間のセッションを制御する信号を受信する第１の受信工程と、
前記第１の受信工程にて受信された信号に基づいてセッションの管理に利用されるセッションごとの情報をメモリに記憶する記憶工程と、
前記記憶工程にて記憶された情報の一部を含むセッションごとの救済ファイルを作成して前記メモリの外部に保持させる作成工程と、
前記通信管理装置の異常発生後にユーザ間のセッションを制御する信号を受信する第２の受信工程と、
前記第２の受信工程にて受信された信号に対応する救済ファイルを取得する取得工程と、
前記取得工程にて取得された救済ファイルを用いてこの救済ファイルに対応するセッションの管理を再開する制御工程と
を有することを特徴とする通信管理方法。
【産業上の利用可能性】
【００８４】
本発明は、セッションの救済を確実に実行しつつ、迅速にサービスを再開する場合に適用することができる。
【図面の簡単な説明】
【００８５】
【図１】一実施の形態に係る通信システムの概略構成を示す図である。
【図２】一実施の形態に係るＳＩＰサーバの要部構成を示すブロック図である。
【図３】一実施の形態に係る救済ファイルの例を示す図である。
【図４】一実施の形態に係るセッション開始動作を示すフロー図である。
【図５】一実施の形態に係るセッション救済動作を示すフロー図である。
【図６】一実施の形態に係る通信動作の一例を示すシーケンス図である。
【図７】一実施の形態に係るＳＩＰサーバの構成の変形例を示すブロック図である。
【図８】セッション救済動作の例を示すシーケンス図である。
【符号の説明】
【００８６】
２１０  送受信部
２２０  セッション制御部
２３０  主記憶部
２４０  救済ファイル作成部
２５０  外部記憶部
２６０  異常検知部
２７０  初期化処理部
２８０  救済ファイル検索部
【図１】
2008103952.tif 000003
【図２】
2008103952.tif 000004
【図３】
2008103952.tif 000005
【図４】
2008103952.tif 000006
【図５】
2008103952.tif 000007
【図６】
2008103952.tif 000008
【図７】
2008103952.tif 000009
【図８】
2008103952.tif 000010