(57)【要約】【課題】  全体のパフォーマンスを低下させることなくＳＩＰサーバの同時接続数を増加させる。【解決手段】  新規呼発生時に、新規呼を受け付けることにより呼処理メモリに呼制御データが記憶されている呼の数または呼制御メモリに記憶されている呼制御データの量が上限を超えることになるとき（ステップ１１００）、呼処理メモリ上の通話中状態にある呼について（ステップ１１０８）、呼制御データを外部記憶装置へ退避させる（ステップ１１１０）。通話中状態にある呼はイベントの発生が頻繁ではないので、全体のパフォーマンスを落とすことなく新規呼の受け付けが可能となる（ステップ１１０２）。【選択図】      図４
2005269217.tif 000002
【特許請求の範囲】
【請求項１】
端末間での呼制御信号のやりとりを中継することによって端末間で呼を接続するＳＩＰ（Session Intiation Protocol）サーバであって、
生起中のそれぞれの呼について呼の状態を示す呼制御データを記憶する呼処理メモリと、
呼処理メモリに記憶されている呼制御データのうち、通話中の状態にある呼の一部についての呼制御データを呼処理メモリから外部記憶装置へ退避させる退避手段と、
呼制御データが外部記憶装置に退避されている呼について呼切断のイベントを受信したとき、退避されている呼制御データを呼処理メモリへ復旧させる復旧手段とを具備するＳＩＰサーバ。
【請求項２】
前記退避手段は、新規呼を受け付けることにより、呼処理メモリに呼制御データが記憶されている呼の数または呼処理メモリに記憶されている呼制御データの量が所定値を超えることになるとき、前記退避処理を実施する請求項１記載のＳＩＰサーバ。
【請求項３】
長時間接続される性質を有する端末を着信先とする呼を検出する手段をさらに具備し、
前記退避手段は、該検出された呼についての呼制御データを退避させる請求項１記載のＳＩＰサーバ。
【請求項４】
前記退避手段は、接続中状態に移行する呼が前記長時間接続される性質を有する端末を着信先とする呼に該当するとき、その呼制御データを退避させる請求項３記載のＳＩＰサーバ。
【請求項５】
前記退避手段はシステム状態が予め定められた条件を満足するとき、退避処理を開始する請求項１または２記載のＳＩＰサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）ネットワーク内に設置され、ＩＰ電話サービスの提供を受けている端末の間での呼制御信号のやりとりを中継することによって端末間で呼を接続するＳＩＰ（Session Intiation Protocol）サーバ、特に、生起中の呼の状態を記憶する呼処理メモリを備えたタイプのＳＩＰサーバに関する。
【背景技術】
【０００２】
ＳＩＰサーバとは、例えば「日経コミュニケーション２００３，９，２２，ｐ１５０−１５８」に図４を参照して説明されているように、端末間での呼制御信号のやりとりを中継することによって、端末間のセッションの確立を手助けする役割を果たすものである。サービスを受けているＳＩＰサーバが異なる端末（異なるＳＩＰサーバに属する端末）の間で呼を接続する際にはそれぞれの端末が属するＳＩＰサーバの間でメッセージが中継される。
【０００３】
本願発明が対象とするＳＩＰサーバはさらに、課金処理などを行なうために、発呼してから切断されるまでの生起中の呼について、呼び出し中、通話中、などの呼の状態を示す呼制御データを記憶する呼処理メモリを備えており、端末間でのセッション開始および切断のメッセージもＳＩＰサーバ経由でやりとりされる。
【０００４】
この場合において、ＳＩＰサーバが提供するサービスの加入者からのセッション接続要求が同時期に集中することにより、当該ＳＩＰサーバでシステムとして割り当てた呼制御用のメモリ領域を超えた加入者からのセッション接続要求が発生した場合、加入者のセッション接続がＳＩＰサーバ側から制限されてしまう問題がある。
【０００５】
ＳＩＰサーバ内にて、ＯＳにてアクセスできるアドレス空間内で、呼制御用のメモリ領域を最大に定義した上で、予め一定の閾値を設けておき、セッション数（呼量）の増加時に、呼接続に必要なリソースに余裕がある場合には、この閾値を制御して、ＳＩＰサーバへの同時接続できる加入者のセッション数を増加させ、ＳＩＰサーバ側のセッション接続不足を解消する手法がある。
【０００６】
しかし、この解決方法は、同時接続数の増大により呼制御用のメモリ領域を超えたセッション要求が発生した場合には、対応できない問題がある。
【０００７】
特開平６−１６９４９６号公報（ＡＴＭスイッチの呼受付制御方式）には、呼の同時接続数に対して十分な管理テーブルを用意し新規呼を受け付け判断する方式が記載されている。しかし、十分な管理テーブルを用意していたとしても、管理テーブルを超える加入者からのセッション接続要求が同時発生すると加入者からのセッション接続要求が制限されるという問題は解決できていない。
【０００８】
特開平４−１６５７４７号公報（呼受付判定方式）には、通信品質によって分けられたクラス毎に確保されている最大通信資源量の確保した管理テーブルを使用する方式が記載されている。しかし、最大通信資源量の管理テーブルを用意していたとしても、管理テーブルを超える加入者からのセッション接続要求が同時発生すると加入者からのセッション接続要求が制限されるという問題は解決できていない。
【０００９】
呼接続処理用のメモリリソースの最適化といった観点での制御方式が、特開平６−９８３６１号公報（呼処理データエリア管理システム）に記載されているが、この発明においても、呼接続処理用のデータエリアを再配置して、連続した呼処理データエリアを確保するものであり、データエリア自体の拡張や、最大呼接続数を増加させる事は出来ない。
【００１０】
以上に述べたように、ＳＩＰサーバに対してシステムとして割り当てた呼制御用のメモリ領域を越えるセッション接続要求が発生した場合、又は、システムとしてアクセス可能なメモリ空間を超えたセッション接続要求が発生している場合において、従来技術ではＳＩＰサーバへの新規呼を受付可能とする事はできず、新規呼のセッション接続要求受付を制限していた。
【００１１】
【特許文献１】特開平６−１６９４９６号公報
【特許文献２】特開平４−１６５７４７号公報
【特許文献３】特開平６−９８３６１号公報
【特許文献４】特開平７−５８７４７号公報
【特許文献５】特開平６−１７７９８３号公報
【特許文献６】特開２０００−２０１２２０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、ＳＩＰサーバにおいて、呼制御用のメモリ領域を越えるセッション接続要求が発生した場合、又は、システムとしてアクセス可能なメモリ空間を超えたセッション接続要求が発生している場合でも、新規呼を受付可能として、同時接続数を増加させることを可能にすることにある。
【００１３】
本発明のＳＩＰサーバは、生起中のそれぞれの呼について呼の状態を示す呼制御データを記憶する呼処理メモリと、呼処理メモリに記憶されている呼制御データのうち、通話中の状態にある呼の一部についての呼制御データを呼処理メモリから外部記憶装置へ退避させる退避手段と、呼制御データが外部記憶装置に退避されている呼について呼切断のイベントを受信したとき、退避されている呼制御データを呼処理メモリへ復旧させる復旧手段とを具備することを特徴とする。
【００１４】
ＳＩＰサーバには接続中の呼に関してリアルタイム性が厳しく要求され応答の迅速性が求められているが、通話中の呼については、常時接続の呼も含まれるなど、リアルタイム性への要求がそれほど厳しくない。そこで、通話中の呼に関する呼処理データを外部記憶装置へ退避させることで、全体のパフォーマンスを落とすことなく、新規呼の受け付けが可能となる。
【発明を実施するための最良の形態】
【００１５】
図１は本発明の一実施例に係るＳＩＰサーバを含むＩＰネットワークの構成の一例を示し、図２はＳＩＰサーバからＩＰ電話のサービスが提供されている端末間での信号シーケンスの一例を示す。
【００１６】
図１において、端末１０から端末１２へ向けて発呼操作が行なわれると、端末１０からそれが属するＳＩＰサーバ１４へ、図１中１点鎖線で示す経路で「ＩＮＶＩＴＥ」メッセージが送られる（図２：ステップ１０００）。ＳＩＰサーバ１４はメッセージに含まれてるＳＩＰ  ＵＲＩ（Universal Resource Identifier）からメッセージの宛先の端末１２が属しているＳＩＰサーバ１６を割り出してメッセージを転送し、ＳＩＰサーバ１６は端末１２へメッセージを転送することにより端末１２へ端末１０からの着信を知らせる。端末１２は端末１０へ「１８０  Ｒｉｎｇｉｎｇ」メッセージをＳＩＰサーバ１６，１４経由で送ることにより端末１２がユーザを呼び出し中であることを知らせる（ステップ１００２）。端末１２においてユーザの応答操作が行なわれると、同じ経路で「２００  ＯＫ」メッセージが送られる（ステップ１００４）。端末１０から端末１２へ「ＡＣＫ」メッセージが送られることにより（ステップ１００６）、端末間のセッションが確立し、図１中太い破線で示す経路で端末１０と端末１２の間で直接、ＲＴＰ／ＲＴＣＰ（Real-time Transport Protocol/RTP Control Protocol）に従う通信が開始される（ステップ１００８）。一方の端末で切断の操作が行なわれると、他方の端末へ「ＢＹＥ」メッセージが送られ（ステップ１０１０）、その応答として「２００  ＯＫ」メッセージが送られることにより（ステップ１０１２）、端末間のセッションが終了する。
【００１７】
図２に示されるように、本願発明が対象とするＳＩＰサーバは、ＡＣＫメッセージ以降の呼制御メッセージ（ＢＹＥメッセージ等）もすべてＳＩＰサーバを経由して送るように各端末へ指示するので、ＳＩＰサーバは現在生起中のすべての呼の状態を知ることができ呼処理メモリにそれを記録する。
【００１８】
端末１０と１２の間では、音声データだけでなく、予め契約された帯域内で映像データなども伝送される場合もある。図１中ＡＲはエリアルータ、ＥＲはエッジルータ、およびＣＲはコアルータを示している。１８はネットワークを監視するネットワークオペレーティングシステムを示す。
【００１９】
図３は本発明に係るＳＩＰサーバ１４，１６の一実施例の構成を示す。ＩＰ通信制御部２０は、最下位のレイヤの処理として、ＩＰネットワークを介する通信における信号の送受信制御を行う。プロトコル制御部２２はＳＩＰプロトコルの制御を行う。ＯＳＳインタフェース制御部２４はネットワークオペレーティングシステム１８（図１）とのインターフェースとなる。
【００２０】
呼制御部２６はプロトコル制御部２２より前述の種々のメッセージを受信したことをイベントとして通知され、メッセージの転送先の割り出し、メッセージの転送、呼処理メモリ２８の更新などの必要な処理を行うほか、必要に応じて図４に例示したような、物理メモリに割り当てられた呼処理メモリ２８に記録されている呼制御データの外部記憶装置３０への退避処理を行う。
【００２１】
図４において、端末からＩＮＶＩＴＥメッセージを受信した旨のイベントが発生すると、この新規呼を受け付けるために呼制御データの退避処理が必要か否かが判定される（ステップ１１００）。具体的には、例えば、この新規呼を受け付けたならば呼処理メモリ２８に記録されている接続（呼）の数が予め定められている上限値を超えることになるか、または呼処理メモリ２８に割り当て可能なメモリ空間を超えることになれば、退避処理が必要と判断する。
【００２２】
図５に呼処理メモリ２８の構成の一例を示す。先頭にこの呼処理メモリ２８に記録可能な接続数の上限値が格納されており、それに続いて、発信者／宛先／呼番号によってアドレスされる位置に呼制御ロジカル番号が記録され、それに続いて、呼制御ロジカル番号でアドレスされる位置に生起中のそれぞれの呼の呼状態（呼び出し中、通話中など）、通話時間、発信者情報、接続先情報などの呼制御データが記録される。
【００２３】
図４に戻って、ステップ１１００において退避処理の必要がないと判断されるときは、メッセージの転送先の割り出し、メッセージの転送、呼処理メモリ２８内の呼制御データの更新などの通常の新規呼接続のための処理を行う（ステップ１１０２）。ステップ１１００において退避が必要と判断されるときは、外部記憶装置内の退避領域（図３：３０）の空き状況を調べ退避可能か否かを判断する（ステップ１１０４）。退避領域３０に空きがなくて退避できないときは、新規呼を棄却し受け付けを拒否する（ステップ１１０６）。
【００２４】
退避領域３０に空きがあって呼制御データの退避が可能であるときは、呼処理メモリ２８に記憶されている呼の呼状態を調べ、呼状態が「通話中」であるものが存在するか否かを調べる（ステップ１１０８）。通話中の呼が存在しないかまたはそれがすべて退避されて呼処理メモリ２８に残っていなければ、新規呼を棄却し受け付けを拒否する（ステップ１１０６）。通話中の呼があればその呼制御データを退避領域３０に退避させる（ステップ１１１０）。退避済となった呼処理メモリの領域は新規呼用として割り当てられ（ステップ１１１２）、これにより新規呼の受け付けが可能となる（ステップ１１０２）。このとき、図６に示すように、退避先リンク情報として、呼制御ロジカル番号でアドレスされる位置に退避が行なわれた呼の退避先ロジカル番号が記録され、退避領域３０には、この退避先ロジカル番号でアドレスされる位置に、退避された呼処理メモリの内容（呼制御データ）と呼制御ロジカル番号が格納されている。したがって、呼処理メモリ２８と退避領域３０との間で相互に参照することができる。
【００２５】
図８は新規呼発生（ＩＮＶＩＴＥ）のイベントの後に他のイベントが発生した時に呼制御部２６で行われる処理を示すフローチャートである。イベント発生があるとまず、イベント発生対象の呼について呼処理メモリ２８内に呼制御データが記録されているか、すなわち、対象呼の呼制御データが退避領域３０に退避されているかどうかが調べられる（ステップ１２００）。退避されていないときは直ちに発生したイベントに応じた処理が行われる。退避されているときは、呼処理メモリ２８内の呼制御ロジカル番号で、図６の退避先リンク情報を引いて退避先ロジカル番号を獲得し、これを用いて退避領域３０から呼制御データを取得する（ステップ１２０２）。
【００２６】
復旧処理（ステップ１２０４）においては、まず図４のステップ１１００と同様にして、すなわち、退避領域３０から取得された呼制御データを呼処理メモリ２８に復旧したならば接続数（呼）の数が上限を超えるかまたは呼処理メモリ２８に割り当て可能なメモリ空間を超えるときは復旧不成功となり一定時間待って（ステップ１２０６）再度トライする。上限を超えないときは退避領域３０から取得された呼制御データを呼処理メモリ２８に復旧させた後、イベント毎の処理を行う。
【００２７】
上記の復旧処理は通話中の呼についてどちらかの端末から切断要求（ＢＹＥメッセージ）が送られてきたときに実行されることになるが、システム要因により退避中の呼が切断されるときにも上記の復旧処理が行われることになる。
【００２８】
図９は図４に示した呼制御部２６の処理の一変形を示す。また図１０は加入者ごとに現在使用中帯域の合計値を記録する加入者帯域管理テーブルの詳細を示し、図１１は加入者データ４０（図３）の構成を示す。端末からの起呼系イベント（ＩＮＶＩＴＥメッセージ受信）が発生すると、まず、加入者帯域管理テーブル（図１０）にアクセスして当該加入者が既に使用中の帯域を調べる。既に使用中の帯域に新たに要求されている呼が使用する帯域を加算すると、加入者データ４０（図１１）に格納されている契約最大帯域を超える場合には、呼処理メモリの退避をしても呼を受け付けることができず退避処理が無駄になるので、そのような場合には受け付けを拒否する（ステップ１３００）。契約最大帯域を超えないときのステップ１３０２〜１３１４の処理は図４のステップ１１００〜１１１２の処理と同じであるので説明を省略する。
【００２９】
図４のステップ１１１０または図９のステップ１３１２において、通話中の呼が複数存在するときに呼制御データを退避する呼を選択する基準として、呼処理メモリ２８（図３、図５）に記録されている通話時間に基いて選択することが望ましい。具体的には、例えば、通話時間が最も長い呼を退避呼として選択する、通話時間が所定の閾値を超えている呼のデータをすべて退避させる、などが考えられる。この様な呼については切断などのイベントの発生の頻度が小さいと考えられ、呼制御データを退避させても全体のパフォーマンスへの影響は小さいと考えられる。
【００３０】
或いはまた、加入者データ４０（図３、図１１）内の契約条件を参照し、常時接続契約を行っている加入者の呼、または切断時にディレイを生じても良いという契約内容の呼を優先的に退避させるように構成することも可能である。
【００３１】
コンテンツサーバなどの配信サービスを行うサーバの或るものは、一旦接続されると長時間接続が持続する性質を有している。このような性質を有する着信先を予め検出しておき、着信先がこれに該当する呼については、セッションが確立して通話中状態に入る時点でその呼制御データを退避させても全体のパフォーマンスへの影響が小さい。
【００３２】
長時間接続される性質を有する着信先の検出方法の第１の例として、図１２に示すように、例えばネットワークオペレーティングシステム１８からの指令により、退避条件テーブルに条件蓄積対象ｃｏｄｅｃの指定と、退避適用通話時間を格納しておく。音声や動画の伝送のために用いられるｃｏｄｅｃには数十種類のｃｏｄｅｃが存在するが、それらのうち、長時間接続される性質を有するサーバで用いられる可能性のあるｃｏｄｅｃを予め特定しておく。また、指定されたｃｏｄｅｃを用いる呼の平均通話時間をｃｏｄｅｃごとに算出するため、図１３に示すような、指定されたｃｏｄｅｃごとに平均通話時間と蓄積通話回数を保持する平均通話時間格納テーブルを用意する。そして、図１４のフローチャートで示すように、呼の解放を意味するＢＹＥイベントの発生時に退避条件テーブル（図１２）において指定されたｃｏｄｅｃが当該呼において使われている場合（ステップ１４００）、その呼の通話時間により平均通話時間格納テーブルの内容を更新する（ステップ１４０２）。この更新処理において、蓄積通話呼数に１が加算され、平均通話時間は平均通話時間に更新前の通話呼数を乗じ新たに得られた通話時間を加算し更新後の通話呼数で割った値で更新される。この様にして得られた平均通話時間が退避条件テーブル内の退避適用通話時間を超えているｃｏｄｅｃを使用する呼が長時間接続される性質を有する着信先への呼と判断される。
【００３３】
図１５のフローチャートに示すように、通話中状態への移行を示すＡＣＫイベントの発生時に、当該呼において使われているｃｏｄｅｃが指定されたｃｏｄｅｃである場合（ステップ１５００）、平均通話時間格納テーブル（図１３）内の当該ｃｏｄｅｃの平均通話時間を退避条件テーブル（図１２）内の退避適用通話時間と比較し（ステップ１５０２）、それを超えていれば、呼制御データの退避を開始する（ステップ１５０６）。退避領域が残っていないとき退避処理は行なわれない（ステップ１５０４）。これによって長時間接続される性質を有する接続先への呼について、接続中状態への移行時に呼制御データを退避させることができる。
【００３４】
長時間接続される性質を有する着信先の検出方法の第２の例として、接続先ごとに平均通話時間を算出し、算出された平均通話時間が退避適用通話時間を超えている接続先を長時間接続される性質を有する接続先と判定することもできる。具体的には、図１２の退避条件テーブルに、退避適用通話時間とともに退避適用優先度、すなわち、平均通話時間を算出する接続先の数を格納しておく。そして、図１６の接続先情報テーブルを用いて、長時間接続された呼の接続先について接続先ごとに平均通話時間を算出する。図１７のフローチャートに示すように、呼の解放の開始を意味するＢＹＥイベントの発生時に、まず、解放される呼の接続先が接続先情報テーブル（図１６）に登録済かどうかを判定し（ステップ１６００）、登録済であるときは、これから解放される呼の通話時間を用いて、図１４のステップ１４０２において説明したように該当する個所の平均通話時間と蓄積通話呼数を更新する（ステップ１６０２）。未登録であるときは、通話時間が退避適用通話時間を超えていれば（ステップ１６０４）、接続先情報テーブル（図１６）へ新規に登録し（ステップ１６０６）、このとき登録数が図１２の退避条件テーブルに格納されている退避適用優先度の値を超えていれば、平均通話時間が最短のものを削除する（ステップ１６０８，１６１０）。
【００３５】
通話中状態への移行を示すＡＣＫイベント発生時には、図１５のフローチャートで示す処理と同様にして、ステップ１５００において指定ｃｏｄｅｃであるか否かの判定に代えて、呼の接続先が図１６の接続先情報テーブルに登録されているか否かの判定を行なうことにより、長時間接続される性質を有する接続先への呼について、接続中状態への移行時に呼制御データを退避させることができる。
【００３６】
上記に説明した例では、通話中状態での移行時に長時間接続される性質を有する接続先への呼か否かの判定を行なって退避を行なっているが、これに代えて、ネットワークオペレーティングシステム１８からの指令に応じて呼処理メモリ２８に呼制御データが記憶されている呼に対して上記のような着信先が長時間接続される性質を有する端末であるかの判定を行なって退避させるようにしても良い。この場合に、ネットワークオペレーティングシステムから退避させる呼の数の最大値を指定して、退避させる呼の数がこの値に達するまで判定を行うようにしても良い。また、退避させる呼の数を指定する代わりに、呼処理メモリに記憶されている呼の数に対する退避呼の割合で指定しても良い。
【００３７】
また、長時間接続される性質を有する接続先を退避の対象とする代わりに、ネットワークオペレーションシステム１８から通話時間を指定し、通話時間が指定された通話時間を超えている呼について、呼制御データを退避させることも可能である。
【００３８】
退避処理開始のきっかけとして、前述したような新規呼接続要求発生時、通話中状態への移行時、または外部からの指令受信時以外にも、周期的にシステム状態を監視し、予め定められた自動退避条件が満たされるとき、自動的に前述した退避処理を開始するようにしても良い。この予め定められた自動退避条件としては、図１８に示した自動退避／復旧条件テーブルに格納されたシステム状態を示す例えばＭＭ使用量（呼処理メモリ使用量）、ＭＭ使用率（呼処理メモリ使用率）、ＣＣ（呼制御）輻輳状態、または一定時間あたりの新規呼発生数を条件とすることができる。退避処理としては、退避領域に空きがあることを前提として、前述したような、通話中状態の呼の退避、通話時間に基いて選択された呼の退避、契約条件に基いて選択された呼の退避などが考えられる。
【００３９】
自動退避／復旧条件テーブルには自動退避条件とともに自動復旧条件が記憶されており、この条件が満たされると、退避されている呼制御データが自動的に復旧される。
【００４０】
（付記１）端末間での呼制御信号のやりとりを中継することによって端末間で呼を接続するＳＩＰ（Session Intiation Protocol）サーバであって、
生起中のそれぞれの呼について呼の状態を示す呼制御データを記憶する呼処理メモリと、
呼処理メモリに記憶されている呼制御データのうち、通話中の状態にある呼の一部についての呼制御データを呼処理メモリから外部記憶装置へ退避させる退避手段と、
呼制御データが外部記憶装置に退避されている呼について呼切断のイベントを受信したとき、退避されている呼制御データを呼処理メモリへ復旧させる復旧手段とを具備するＳＩＰサーバ。
【００４１】
（付記２）前記退避手段は、新規呼を受け付けることにより、呼処理メモリに呼制御データが記憶されている呼の数または呼処理メモリに記憶されている呼制御データの量が所定値を超えることになるとき、前記退避処理を実施する付記１記載のＳＩＰサーバ。
【００４２】
（付記３）前記退避手段は、新規呼を受け付けることにより当該加入者の使用帯域が契約最大帯域を超えることになるとき、呼の数または呼制御データの量にかかわらず前記退避処理を実施しない付記２記載のＳＩＰサーバ。
【００４３】
（付記４）前記退避手段は、通話中の状態にある呼の通話時間に基いて呼制御データを退避させる呼を選択する付記１〜３のいずれか１項記載のＳＩＰサーバ。
【００４４】
（付記５）前記退避手段は、通話中の状態にある呼の発信端末及び着信端末のサービス提供契約条件に基いて呼制御データを退避させる呼を選択する付記１〜３のいずれか１項記載のＳＩＰサーバ。
【００４５】
（付記６）長時間接続される性質を有する端末を着信先とする呼を検出する手段をさらに具備し、
前記退避手段は、該検出された呼についての呼制御データを退避させる付記１記載のＳＩＰサーバ。
【００４６】
（付記７）前記退避手段は、接続中状態に移行する呼が前記長時間接続される性質を有する端末を着信先とする呼に該当するとき、その呼制御データを退避させる付記６記載のＳＩＰサーバ。
【００４７】
（付記８）前記退避手段は、外部からの指令に応答して前記長時間接続される性質を有する端末を着信先とする呼の呼制御データを退避させる付記６記載のＳＩＰサーバ。
【００４８】
（付記９）前記退避手段はシステム状態が予め定められた条件を満足するとき、退避処理を開始する付記１〜５のいずれか１項記載のＳＩＰサーバ。
【図面の簡単な説明】
【００４９】
【図１】本発明の一実施例に係るＳＩＰサーバを含むＩＰネットワークの構成の一例を示す図である。
【図２】呼制御メッセージの信号シーケンス図である。
【図３】本発明の一実施例に係るＳＩＰサーバの構成を示すブロック図である。
【図４】呼制御部２６における退避処理の第１の例を示すフローチャートである。
【図５】呼処理メモリ２８の構成を示す図である。
【図６】退避先リンク情報の構成を示す図である。
【図７】退避領域３０の構成を示す図である。
【図８】呼制御部２６における復旧処理のフローチャートである。
【図９】呼制御部２６における退避処理の第２の例を示すフローチャートである。
【図１０】加入者帯域管理テーブルの構成を示す図である。
【図１１】加入者データ４０の構成を示す図である。
【図１２】退避条件テーブルの構成を示す図である。
【図１３】平均通話時間格納テーブルの構成を示す図である。
【図１４】呼制御部２６における平均通話時間算出処理のフローチャートである。
【図１５】呼処理部２６における退避処理の第３の例を示すフローチャートである。
【図１６】接続先情報テーブルの構成を示す図である。
【図１７】呼制御部２６における接続先情報テーブル更新処理のフローチャートである。
【図１８】自動退避／復旧条件テーブルの構成を示す図である。
【図１】
2005269217.tif 000003
【図２】
2005269217.tif 000004
【図３】
2005269217.tif 000005
【図４】
2005269217.tif 000006
【図５】
2005269217.tif 000007
【図６】
2005269217.tif 000008
【図７】
2005269217.tif 000009
【図８】
2005269217.tif 000010
【図９】
2005269217.tif 000011
【図１０】
2005269217.tif 000012
【図１１】
2005269217.tif 000013
【図１２】
2005269217.tif 000014
【図１３】
2005269217.tif 000015
【図１４】
2005269217.tif 000016
【図１５】
2005269217.tif 000017
【図１６】
2005269217.tif 000018
【図１７】
2005269217.tif 000019
【図１８】
2005269217.tif 000020