JP4899659B2 - 電話回線接続方法 - Google Patents

Description

本発明は、発信端末から着信端末へ呼の接続を行う呼接続装置（交換機またはＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）サーバ）の電話回線接続に適用される。特に、災害等が発生した場合に生じる呼接続装置の呼の接続に関する発明である。

災害が発生した場合災害地域の人に対して安否確認の電話が交換又はＳＩＰサーバに集中する。トラヒックの増加により輻輳してタイムリーに安否の確認を行う事が出来なかった。

また、災害時の安否確認では、災害時の安否確認用伝言板サービス（１７１）、等があるがタイムリーに安否確認を行う事が出来なく、特番を使う等の事前の知識が必要になっている。

また、メッセージ蓄積用のサーバの設置を全国の拠点に分散させて設置する必要がある。
特開平０８―３１７４７１号公報 特開２００３―３４８６３号公報

本発明の目的は、既存の電話、携帯網を利用して災害時に通信網に負担をかけずに簡単に安否確認を行う、技術を提供することである。

本発明は、上述した目的を達成するために以下の構成を採用する。

第１の手段として、発信端末から着信端末へ呼の接続を行う呼接続装置の電話回線接続方法は、呼接続装置に設定されている呼接続条件が第１の呼接続手順または第２の呼接続手順であるかを判定し、該判定結果が該第１の呼接続手順の場合は該発信端末から該着信端末へ呼の接続を行い通話可能な状態とし、該判定結果が該第２の呼接続手順の場合は該発信端末から該着信端末へ呼の接続を行うと共に、該発信端末又は該着信端末からの切断要求を待たずに通話終了処理を行う事を特徴とする。

第２の手段として、発信端末から着信端末へ呼の接続を行う第１の手段において、
該呼接続装置に設定されている呼接続条件は保守端末により指定される。

第３の手段として、発信端末から着信端末へ呼の接続を行う第１の手段において、
該呼接続装置が該第２の呼接続手順の場合に、該呼接続装置の配下にある該着信端末への呼の接続は所定の時間が経過した後に呼の接続処理と通話終了処理を行う事を特徴とする。

第４の手段として、発信端末から着信端末へ呼の接続を行う第１の手段において、
請求項１の電話回線接続方法において、
該呼接続装置が該第２の呼接続手順に入る前に、該発信端末からの発信番号が特定の番号であるかを検出し、
該特定の番号である時は該第１の呼接続手順により呼接続を行い、
該特定の番号でない時は該第２の呼接続手順により呼接続を行う事を特徴とする。

第５の手段として、発信端末から着信端末へ呼の接続を行う第１の手段において、
請求項１の電話回線接続方法において、
該呼接続装置の該第２の呼接続手順において、通話終了処理を行う前に、該発信端末又は該着信端末へ所定のメッセージが通知されるように、メッセージ信号を送信することを特徴とする。

本発明によれば、一般通話については、相手方を呼び出し着信履歴を着信端末に残しサーバ（又は交換機）から自動的に切断を行う事により通信網にかかる負担を軽減させる。（通常の通話成立までにかかるサーバのリソースの削減、ネットワークに流れる信号（パケット）量を減らす事により、サーバ及び、ネットワークにかかる負担を軽減させる事により安定した通信網を確保することができる。

また、最大輻輳時には、一般通話については、通話は行えないが、着信側（相手方）を呼び出した後に、着信履歴を着信端末に残し、サーバ（又は交換機）から自動的に切断を行う。

この事により、通信網にかかる負担を軽減させた上に、着信側（相手方）にリアルタイムに安否を伝えることができる。

また、災害時にシステムへの切替をネットワークの輻輳に応じて行い最大輻輳時には、緊急通話（１１０，１１９，１１８等）以外は通話を行えない様にできる。

また、高負荷時には、（非同期性を生かして）発信側から着信側への呼び出しをトラヒックに合わせてずらして、確実に着信側（相手方）を呼び出し着信履歴を着信端末に残す様に制御を行うことができる。

また、発信端末と着信端末に、電話番号の他に付加情報として、現在輻輳状態に入っており、通話の接続ができない旨のテキスト、または、音声情報を発信端末と着信端末に送信して、発信端末には着信端末に履歴を残したことを知らせることができる。

以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

図１は本発明を実施するための呼接続装置、即ち、交換機またはＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）サーバのソフトウエア機能を示している。

図中１はソフトウエア制御部を示している。２はプログラムで構成された呼処理機能を示している。３，３’は交換機またはＳＩＰサーバのプログラムで構成されたその他の機能を示している。３，３’の一例として、システムの再開を行うための再開機能等が上げられる。

呼処理機能２には通常時機能２１と災害時機能２２が含まれる。通常時機能２１は通常時呼処理機能２３と通常時輻輳処理機能２４が含まれる。災害時機能２２は災害時呼処理機能２５と災害時輻輳処理機能２６が含まれる。

ソフトウエア制御部１は各機能を読み出し、状況に対応した処理を行う。

図２は呼接続装置内の呼処理機能における処理のフローチャートを示している。図２は図１の着信端末が接続されている交換機またはＳＩＰサーバにおけるソフトウエア制御部１の呼処理機能の動作である。

ステップ２１００では発信端末からの呼の受信により処理を開始する。

ステップ２２００では保守センタに配置された保守運用端末８で保守者により災害発生時は災害発生フラグをオンする。また、災害が集束した場合又は通常の状態は設定をオフにしておく。

ステップ２３００ではステップ２２００で設定された状態を検出する。設定された状態がオフ状態の場合はステップ２４００に進む。設定された状態がオン状態の場合はステップ２５００に進む。

ステップ２４００では通常の状態の呼処理を実施する。ステップ２４００の機能としては着信端末を呼び出す。着信側端末が応答すると通話を開始する。着信側端末又は発信側端末からの切断要求により通話を終了させる。

ステップ２６００ではステップ２４００の通話の終了により呼接続装置の処理を終了する。

ステップ２５００では災害時の呼の処理を実行する。ステップ２５００の機能としては着信側端末を呼び出し、その直後に呼接続装置からの要求により呼の切断処理を行う。即ち、俗に言う所のワン切りの処理を呼接続装置の要求により実施する。

ステップ２７００ではステップ２５００の処理の終了により呼接続装置の処理を終了する。

図３は図２のフローチャート内のステップ２２００の具体的な動作を示している。

ステップ２２０１では保守者は保守端末から災害時にシステム切り替えを行う。具体的には、災害発生において、保守者は保守運用コマンドにより災害発生フラグをオンにする。

ステップ２２０２では保守運用コマンドにより災害発生地域の呼接続装置のフラグがオンになる。

図４は図２のフローチャート内のステップ２４００の具体的な動作シーケンスを示している。ステップ２４００自体はＳＩＰサーバ６の動作である。
図中は呼接続装置としてＳＩＰサーバを用いて説明するが、ＳＩＰサーバは既存の交換機などに置き換えることができる。

発信端末４からの呼設定信号（ＩＮＶＩＴＥ）２４０１をＳＩＰサーバに送る。

ＳＩＰサーバは、呼設定信号（ＩＮＶＩＴＥ）２４０１を受信すると、発信端末４に対して暫定応答信号（１００Ｔｒｙｉｎｇ）２４０２を送信すると共に、着信端末７が所属するＳＩＰサーバ６に呼設定信号（ＩＮＶＩＴＥ）２４０３を送信する。

ＳＩＰサーバ６は、呼設定信号（ＩＮＶＩＴＥ）２４０３を受信すると、着信端末７に呼設定信号（ＩＮＶＩＴＥ）２４０４を送信する。

着信端末７は、ＳＩＰサーバ６から呼設定信号（ＩＮＶＩＴＥ）２４０４を受信すると、
ＳＩＰサーバ６に対して暫定応答信号（１００Ｔｒｙｉｎｇ）２４０５を送信する。さらに、着信端末７は、暫定応答信号（１００Ｔｒｙｉｎｇ）２４０５を送信した後に、ＳＩＰサーバ６に対してリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２４０６を送信する。

ＳＩＰサーバ６は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２４０６を受信すると、ＳＩＰサーバ５にリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２４０７を送信する。

ＳＩＰサーバ５は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２４０７を受信すると、発信端末４にリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２４０８を送信する。

着信端末７は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２４０６を送信した後に、ＳＩＰサーバ６に対してリクエストに対する応答信号（２００ ＯＫ）２４０９を送信する。

ＳＩＰサーバ６は、リクエストに対する応答信号（２００ ＯＫ）２４０９を受信すると、承認信号（ＡＣＫ）２４１０を着信端末７に送信すると共に、ＳＩＰサーバ６はＳＩＰサーバ５にリクエストに対する応答信号（２００ ＯＫ）２４１１を送信する。

ＳＩＰサーバ５は、リクエストに対する応答信号（２００ ＯＫ）２４１１を受信すると、承認信号（ＡＣＫ）２４１３をＳＩＰサーバ６に送信すると共に、ＳＩＰサーバ５は発信端末４にリクエストに対する応答信号（２００ ＯＫ）２４１２を送信する。

発信端末４は、リクエストに対する応答信号（２００ ＯＫ）２４１２を受信すると、承認信号（ＡＣＫ）２４１４をＳＩＰサーバ５に送信する。

承認信号（ＡＣＫ）２４１４、２４１３、２４１０が完了することで、通話が開始できる。

発信端末４は、通話が完了すると通話完了信号（ＢＹＥ）２４１５をＳＩＰサーバ５に送信する。

ＳＩＰサーバ５は、発信端末４からの通話完了信号（ＢＹＥ）２４１５を受信すると、ＳＩＰサーバ６に通話完了信号（ＢＹＥ）２４１６を送信する。

ＳＩＰサーバ６は、通話完了信号（ＢＹＥ）２４１６を受信すると、着信端末７に通話完了信号（ＢＹＥ）２４１７を送信する。

着信端末７は、通話完了信号（ＢＹＥ）２４１７を受信すると、リクエストに対する応答信号（２００ ＯＫ）２４１８をＳＩＰサーバ６に送信する。

ＳＩＰサーバ６は、通話完了信号（ＢＹＥ）２４１８を受信すると、リクエストに対する応答信号（２００ ＯＫ）２４１９をＳＩＰサーバ５に送信する。

ＳＩＰサーバ５は、通話完了信号（ＢＹＥ）２４１９を受信すると、リクエストに対する応答信号（２００ ＯＫ）２４２０を発信端末４に送信する。

尚、本図では、通話完了信号（ＢＹＥ）は発信端末４が契機となっているが、着信端末７を契機として、ＳＩＰサーバ６，５を介して、発信端末４に向けて送信しても良い。

図５は図２のフローチャート内のステップ２５００の具体的な動作シーケンスを示している。ステップ２５００自体はＳＩＰサーバ６’の動作である。図中は呼接続装置としてＳＩＰサーバを用いて説明するが、ＳＩＰサーバは既存の交換機などに置き換えることができる。

発信端末４からの呼設定信号（ＩＮＶＩＴＥ）２５０１をＳＩＰサーバ５に送る。

ＳＩＰサーバ５は、呼設定信号（ＩＮＶＩＴＥ）２５０１を受信すると、発信端末４に対して暫定応答信号（１００Ｔｒｙｉｎｇ）２５０２を送信すると共に、災害地域着信端末７’が所属する災害地域ＳＩＰサーバ６’に呼設定信号（ＩＮＶＩＴＥ）２５０３を送信する。

災害地域ＳＩＰサーバ６は、呼設定信号（ＩＮＶＩＴＥ）２５０３を受信すると、災害地域着信端末７’に呼設定信号（ＩＮＶＩＴＥ）２５０４を送信する。

災害地域着信端末７’は、災害地域ＳＩＰサーバ６’から呼設定信号（ＩＮＶＩＴＥ）２５０４を受信すると、災害地域ＳＩＰサーバ’６に対して暫定応答信号（１００Ｔｒｙｉｎｇ）２５０５を送信する。さらに、災害地域着信端末７’は、暫定応答信号（１００Ｔｒｙｉｎｇ）２５０５を送信した後に、災害地域ＳＩＰサーバ６’に対してリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５０６を送信する。

災害地域ＳＩＰサーバ６’は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５０６を受信すると、ＳＩＰサーバ５にリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５０７を送信する。

ＳＩＰサーバ５は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５０７を受信すると、発信端末４にリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５０８を送信する。

災害地域ＳＩＰサーバ６’は、ＳＩＰサーバ５にリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５０７を送信した後で、災害地域着信端末７’に呼設定処理が確立する前に、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５０９を災害地域着信端末７’に送信する。さらに、災害地域ＳＩＰサーバ６’はＳＩＰサーバ５に対しても呼設定処理が確立する前に、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５１０を送信する。

ＳＩＰサーバ５は、呼切断処理信号（ＣＡＮＣＥＬ）２５１０を受信すると、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、発信端末に対して呼切断処理信号（ＣＡＮＣＥＬ）２５１１を送信する。

災害地域着信端末７’は、災害地域ＳＩＰサーバ６’からの呼切断処理信号（ＣＡＮＣＥＬ）２５０９を受信すると、災害地域ＳＩＰサーバ６’にリクエストに対する応答信号（２００ ＯＫ）２５１２を送信する。さらに、災害地域着信端末７’は、災害地域ＳＩＰサーバ６’にリクエストに対する応答信号（２００ ＯＫ）２５１２を送信した後に、災害地域ＳＩＰサーバ６’に、端末側からＣＡＮＣＥＬが成立したことを示す信号（４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄ）２５１５を送信する。また、災害地域着信端末７’は、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドの「災害時通信」より災害時の連絡であると認識する。

発信端末４はＳＩＰサーバ５から呼切断処理信号（ＣＡＮＣＥＬ）２５１１を受信すると、
リクエストに対する応答信号（２００ ＯＫ）２５１３をＳＩＰサーバ５に送信する。発信端末４は、呼切断処理信号（ＣＡＮＣＥＬ）２５１１のＲｅａｓｏｎフィールドの「災害時通信」より災害時の連絡（通信）が正常に行われた事を認識する。

なお、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドの「災害時通信」は、正常に災害時の通信が行われたことを示し、呼接続装置（ＳＩＰサーバ、交換機）では、正常切断と同等の処理を行う。

ＳＩＰサーバ５は、発信端末４からリクエストに対する応答信号（２００ ＯＫ）２５１３を受信すると、災害地域ＳＩＰサーバ６’にリクエストに対する応答信号（２００ ＯＫ）２５１４を送信する。

災害地域ＳＩＰサーバ６’は、端末側からＣＡＮＣＥＬが成立したことを示す信号（４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄ）２５１５とリクエストに対する応答信号（２００ ＯＫ）２５１４を受信すると、災害地域着信端末７’に承認信号（ＡＣＫ）２５１６を送信する。

付加情報信号２５１７、２５１８、２５１９は呼接続装置が発信端末と着信端末に、付加情報を送信する際に用いる信号である。この信号の送信はオプションである。

付加情報とは、現在輻輳状態に入っており、通話の接続ができない旨のテキスト、または、音声情報である。

付加情報を発信端末と着信端末に送信することで、発信端末と着信端末に履歴と現在の呼接続装置の状態を知らせることができる。

災害地域ＳＩＰサーバ６’は、呼切断信号（ＣＡＮＣＥＬ）２５１０と、２５０９を送信する前に、付加情報２５１７を災害地域着信端末７’に送り、付加情報２５１８をＳＩＰサーバ５に送る。ＳＩＰサーバ５は付加情報２５１８を受信すると、発信端末４に対して付加情報２５１９を送信する。

図６は図２のフローチャート内のステップ２５００の具体的な動作シーケンスを示している。ステップ２５００自体はＳＩＰサーバ６’の動作である。図中は呼接続装置としてＳＩＰサーバを用いて説明するが、ＳＩＰサーバは既存の交換機などに置き換えることができる。図５では災害地域ＳＩＰサーバ６’に帰属する端末が着信端末となっていたが、図６では災害地域ＳＩＰサーバ６’に帰属する端末が発信端末になっている。

災害地域発信端末７’’は、呼設定信号（ＩＮＶＩＴＥ）２５４０を災害地域ＳＩＰサーバ６’に送る。

災害地域ＳＩＰサーバ６’は災害地域発信端末７’’から呼設定信号（ＩＮＶＩＴＥ）２５４０を受信すると、呼設定信号（ＩＮＶＩＴＥ）２５４１をＳＩＰサーバ５に送る。さらに、災害地域ＳＩＰサーバ６’は暫定応答信号（１００Ｔｒｙｉｎｇ）２５０５を災害地域発信端末７’’に送信する。

ＳＩＰサーバ５は災害地域ＳＩＰサーバ６’から呼設定信号（ＩＮＶＩＴＥ）２５４１を受信すると、呼設定信号（ＩＮＶＩＴＥ）２５４３を着信端末４’に送る。

着信端末４’はＳＩＰサーバ５から呼設定信号（ＩＮＶＩＴＥ）２５４３を受信すると、暫定応答信号（１００Ｔｒｙｉｎｇ）２５４４、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５４５の順で、ＳＩＰサーバ５に送信する。

ＳＩＰサーバ５は着信端末４’から暫定応答信号（１００Ｔｒｙｉｎｇ）２５４４、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５４５を受信すると、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５４６を災害地域ＳＩＰサーバ６’に送信する。

災害地域ＳＩＰサーバ６’はＳＩＰサーバ５からのリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５４６を受信すると、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５４７を災害地域発信端末７’’に送信する。さらに、災害地域ＳＩＰサーバ６’はＳＩＰサーバ５に呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５４８と災害地域発信端末７’’に呼切断処理信号（ＣＡＮＣＥＬ）２５４９を送信する。

ＳＩＰサーバ５は、災害地域ＳＩＰサーバ６’からの呼切断処理信号（ＣＡＮＣＥＬ）２５４８を受信すると、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５５０を着信端末４’に送信する。

着信端末４’は、ＳＩＰサーバ５から呼切断処理信号（ＣＡＮＣＥＬ）２５５０を受信すると、リクエストに対する応答信号（２００ ＯＫ）２５５１をＳＩＰサーバ５に送信する。着信端末４’は、呼切断処理信号（ＣＡＮＣＥＬ）２５５０のＲｅａｓｏｎフィールドの「災害時通信」より災害時の連絡であると認識する。
さらに、着信端末４’は、リクエストに対する応答信号（２００ ＯＫ）２５５１をＳＩＰサーバ５に送信した後、端末側からＣＡＮＣＥＬが成立したことを示す信号（４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄ）２５５３をＳＩＰサーバ５に送信する。

ＳＩＰサーバ５は、着信端末４’から応答信号（２００ ＯＫ）２５５１受信し、端末側からＣＡＮＣＥＬが成立したことを示す信号（４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄ）２５５３を受信すると、災害地域ＳＩＰサーバ６’に応答信号（２００ ＯＫ）２５５４を送信し、着信端末４’には承認信号（ＡＣＫ）２５５５を送信する。

災害地域発信端末７’’は、災害地域ＳＩＰサーバ６’から呼切断処理信号（ＣＡＮＣＥＬ）２５４９を受信すると、災害地域ＳＩＰサーバ６’ 応答信号（２００ ＯＫ）２５５２を送信する。災害地域発信端末７’’は、呼切断処理信号（ＣＡＮＣＥＬ）２５４９のＲｅａｓｏｎフィールドの「災害時通信」より災害時の連絡（通信）が正常に行われた事を認識する。

図７は図２のフローチャート内のステップ２５００の具体的な動作シーケンスを示している。ステップ２５００自体はＳＩＰサーバ６’の動作である。図中は呼接続装置としてＳＩＰサーバを用いて説明するが、ＳＩＰサーバは既存の交換機などに置き換えることができる。図７は図５と同様に、災害地域ＳＩＰサーバ６’に帰属する端末が着信端末となっている例を示している。図７では災害地域ＳＩＰサーバ６’に帰属する着信端末に着信を行う際に所定の遅延やタイミングを取る調整を行う。

発信端末４からの呼設定信号（ＩＮＶＩＴＥ）２５２１をＳＩＰサーバ５に送る。

ＳＩＰサーバ５は、呼設定信号（ＩＮＶＩＴＥ）２５０１を受信すると、発信端末４に対して暫定応答信号（１００Ｔｒｙｉｎｇ）２５２３を送信すると共に、災害地域着信端末７’が所属する災害地域ＳＩＰサーバ６’に呼設定信号（ＩＮＶＩＴＥ）２５２２を送信する。

災害地域ＳＩＰサーバ６’は、ＳＩＰサーバ５から呼設定信号（ＩＮＶＩＴＥ）２５２２を受信すると、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５２４をＳＩＰサーバ５に送信する。さらに、災害地域ＳＩＰサーバ６’は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５２４をＳＩＰサーバ５に送信した後に、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５２６をＳＩＰサーバ５に送信する。

ＳＩＰサーバ５は、災害地域ＳＩＰサーバ６’からリングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５２４を受信すると、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５２４を発信端末４に送信する。さらに、ＳＩＰサーバ５は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５２４を発信端末４に送信した後に、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５２７を発信端末４に送信する。

発信端末４は、ＳＩＰサーバ５から呼切断処理信号（ＣＡＮＣＥＬ）２５２７を受信すると、リクエストに対する応答信号（２００ ＯＫ）２５２８をＳＩＰサーバ５に送信する。

ＳＩＰサーバ５は、発信端末４からリクエストに対する応答信号（２００ ＯＫ）２５２８を受信すると、リクエストに対する応答信号（２００ ＯＫ）２５２９を災害地域ＳＩＰサーバ６’に送信する。発信端末４は、呼切断処理信号（ＣＡＮＣＥＬ）２５２７のＲｅａｓｏｎフィールドの「災害時通信」より災害時の連絡（通信）が正常に行われた事を認識する。

災害地域ＳＩＰサーバ６’は呼設定信号（ＩＮＶＩＴＥ）２５２２またはリクエストに対する応答信号（２００ ＯＫ）２５２９を受信した時点から所定のタイミングを取った後に呼設定信号（ＩＮＶＩＴＥ）２５３０を災害地域着信端末７’に送信する。

災害地域着信端末７’は、災害地域ＳＩＰサーバ６’に対して暫定応答信号（１００Ｔｒｙｉｎｇ）２５３１を送信すると共に、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５３２を災害地域ＳＩＰサーバ６’に送信する。

災害地域ＳＩＰサーバ６’は、リングバックトーン（１８０Ｒｉｎｇｉｎｇ）２５３２を受信すると、呼切断処理信号（ＣＡＮＣＥＬ）のＲｅａｓｏｎフィールドに「災害時通信」を設定して、呼切断処理信号（ＣＡＮＣＥＬ）２５３３を災害地域着信端末７’に送信する。

災害地域着信端末７’は、災害地域ＳＩＰサーバ６’からの呼切断処理信号（ＣＡＮＣＥＬ）２５３３を受信すると、リクエストに対する応答信号（２００ ＯＫ）２５３４を災害地域ＳＩＰサーバ６’に送信する。さらに、災害地域着信端末７’は、リクエストに対する応答信号（２００ ＯＫ）２５３４を送信した後に、端末側からＣＡＮＣＥＬが成立したことを示す信号（４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄ）２５３５送信する。災害地域着信端末７’は、呼切断処理信号（ＣＡＮＣＥＬ）２５４９のＲｅａｓｏｎフィールドの「災害時通信」より災害時の連絡であると認識する。

災害地域ＳＩＰサーバ６’は、端末側からＣＡＮＣＥＬが成立したことを示す信号（４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄ）２５３５受信すると、災害地域着信端末７’に承認信号（ＡＣＫ）２５１６を送信する。

図８は呼接続装置内の処理のフローチャートを示している。図８は図１の着信端末が接続されている交換機またはＳＩＰサーバにおけるソフトウエア制御部１の呼処理機能の動作である。即ち、図８は図２の呼接続装置内の処理のフローチャートをさらに具体化したものである。従って、図２と同一部材は同一番号で示す。尚、ステップ２２００は図３で説明済みのため図８上では省略した。

ステップ２３００では保守者により設定された状態を検出する。設定された状態がオフ状態の場合はステップ２４００に進む。設定された状態がオン状態の場合はステップ２８００に進む。

ステップ２８００は発信端末からの呼が、緊急特番の発呼番号（１１０（警察所）、１１９（消防署）、１１８（海上保安局））か否かを検出する。検出結果が緊急特番の発呼番号以外であればステップ２５００に移る。このとき、特番発呼番号には、ガス、電気、電話、水道などのライフラインに関する事業者の電話番号を含めても良い。また、特番発呼の場合ステップ２４００に移る。本図の例では、着信呼の呼び出しのステップ２４２１に移る。

ステップ２５００は輻輳に関する処理のステップ２５６２と、着信に関する処理のステップ２５６５とを有している。

ステップ２５６２はステップ２８００が終了すると実行される。ステップ２５６２は呼接続装置が輻輳中か否かを検出するステップ２５６３と、輻輳時に所定の時間間隔をずらすステップ２５６４が含まれている。

ステップ２５６４はステップ２５６３で、輻輳状態を定義する基準の呼の数より、着信の呼の数が多い場合に、輻輳中と判断する。

ステップ２５６４の処理は一定の割合で着信側への接続要求に対してタイミング（数秒）を取る。または、着信の呼の数に対応付けして、遅延する時間を調整する。ステップ２５６４が終了するとステップ２５６５に移る。

ステップ２５６５は着信呼を呼出すステップ２５６０と着信直後に呼接続装置（ＳＩＰサーバ、交換機）から切断要求（災害時通信）を行うステップ２５６１が含まれている。当該処理手順はステップ２５６０、ステップ２５６１の順で行われる。
なお、切断要求（災害時通信）は、切断要求（正常切断）と同等の処理を呼接続装置（ＳＩＰサーバ、交換機）で行う。

ステップ２３００で災害発生フラグがオフの場合はステップ２４００に進む。

ステップ２４００内の処理手順を以下に説明する。

災害発生フラグがオフの場合はステップ２４２０で、呼接続装置が輻輳状態か既存状態かの検出を行う。呼接続装置が輻輳状態の場合はステップ２４２５に進み、呼接続装置が輻輳状態で無い場合はステップ２４２１に進む。

ステップ２４２１は着信側端末を呼び出す。 次に、ステップ２４２２は着信側端末の応答で通話を開始する。 次に、ステップ２４２３は着信側端末または発信側端末の切断要求で通話を切断する。

ステップ２４２５では輻輳時の規制処理（既存の規制処理）を行う。次に、ステップ２４２６で、発信側からの切断要求を確認し、切断を行う。

図９は本発明の呼接続装置を用いた場合のシステム全体のサービス形態を示す図。

保守運用端末８から保守者が災害発生時に災害フラグをオンにする。これにより、災害発生地域の呼接続処理を行う呼接続装置６’（先に述べた図ではＳＩＰサーバ）の災害フラグがオンになる。

次に、非災害発生地域の呼接続装置５（先に述べた図ではＳＩＰサーバ）の配下にある発信端末から発信が行われる。

次に、呼接続装置５は呼接続装置６’に対して接続要求を行う。呼接続装置５からの接続要求に対して、呼接続装置６’は配下にある着信端末７’に呼出を行った後に、着信端末７’と呼接続装置５に対して切断処理を行う。

図９に図示しないが、呼接続装置６’は配下にある着信端末７’に呼出を行う際には、呼接続装置５からの接続要求を受けた後に、所定時間の間、読み出しタイミングをずらして切断処理を行っても良い。

図１０は本発明の呼接続装置を用いた場合のシステム全体の他のサービス形態を示す図。

保守運用端末８から保守者が災害発生時に災害フラグをオンにする。これにより、災害発生地域の呼接続処理を行う呼接続装置６’（先に述べた図ではＳＩＰサーバ）の災害フラグがオンになる。

次に、災害発生地域の呼接続装置６’（先に述べた図ではＳＩＰサーバ）の配下にある発信端末７’’から発信が行われる。

次に、呼接続装置６’は呼接続装置５に対して接続要求を行う。呼接続装置６’からの接続要求に対して、非災害発生地域の呼接続装置５は配下にある着信端末４’に呼出を行った後に、発信端末７’’と呼接続装置５に対して切断処理を行う。

図１１は本発明の呼接続装置を用いた場合のシステム全体の他のサービス形態を示す図。

保守運用端末８から保守者が災害発生時に災害フラグをオンにする。これにより、災害発生地域の呼接続処理を行う呼接続装置６’（先に述べた図ではＳＩＰサーバ）の災害フラグがオンになる。

次に、災害発生地域の呼接続装置６’（先に述べた図ではＳＩＰサーバ）の配下にある発信端末７’’から発信が行われる。呼接続装置６’は発信端末７’’の呼が特番発呼の場合、非災害発生地域の呼接続装置５に呼び出しを行う。次に、呼接続装置５は緊急特番着信端末９に呼を接続し、緊急特番着信端末９からの応答を呼接続装置６’に返す。これにより、災害発生時でも緊急特番着信端末９と発信端末７’’は通話を行うことができる。

上述した実施形態は、以下の発明を開示する。以下の発明は、必要に応じて適宜組み合わせることができる。

呼接続装置のソフトウエア機能を示す図 呼接続装置内の呼処理機能における処理のフローチャート 図２のフローチャート内のステップ２２００の具体的な動作を示す図 図２のフローチャート内のステップ２４００の具体的な動作シーケンスを示す図 図２のフローチャート内のステップ２５００の具体的な動作シーケンスを示す図 図２のフローチャート内のステップ２５００の具体的な動作シーケンスを示す図 図２のフローチャート内のステップ２５００の具体的な動作シーケンスを示す図 呼接続装置内の処理のフローチャート 呼接続装置を用いた場合のシステム全体のサービス形態を示す図 呼接続装置を用いた場合のシステム全体の他のサービス形態を示す図 呼接続装置を用いた場合のシステム全体の他のサービス形態を示す図

符号の説明

１ ソフトウエア制御部
２ 呼処理機能
３ 再開機能
３’ その他の機能
４ 発信端末
４’ 着信端末
５ 呼接続装置（ＳＩＰサーバ、交換機）
６ 呼接続装置（ＳＩＰサーバ、交換機）
６’ 災害地域呼接続装置（ＳＩＰサーバ、交換機）
７ 着信端末
７’ 災害地域着信端末
７’’ 災害地域発信端末

Claims (4)

1. 発信端末から着信端末へ呼の接続を行う呼接続装置の電話回線接続方法において、
   該呼接続装置が災害発生地域にあるか否かを示すフラグの設定状態を判定し、
   該判定の結果、該フラグの設定状態が該呼接続装置が災害発生地域にないことを示す場合は、該発信端末から該着信端末へ呼の接続を行い通話可能な状態とし、該発信端末又は該着信端末からの切断要求に応答して通話終了処理を行い、
   該判定の結果、該フラグの設定状態が該呼接続装置が災害発生地域にあることを示す場合は、該発信端末から該呼接続装置の配下にある該着信端末への呼の接続要求を受けてから所定の時間が経過した後で、該着信端末への呼び出し処理を行い、該発信端末又は該着信端末からの切断要求を待たずに、該発信端末と該着信端末の間の通話が開始される前に、該着信端末との切断処理を行う
   ことを特徴とする電話回線接続方法。
2. 請求項１の電話回線接続方法において、
   該呼接続装置に設定されている呼接続条件は保守端末により指定されることを特徴とする電話回線接続方法。
3. 請求項１の電話回線接続方法において、
   該呼接続装置が該第２の呼接続手順に入る前に、該発信端末からの発信番号が特定の番号であるかを検出し、
   該特定の番号である時は該第１の呼接続手順により呼接続を行い、
   該特定の番号でない時は該第２の呼接続手順により呼接続を行う事を特徴とする電話回線接続方法。
4. 請求項１の電話回線接続方法において、
   該呼接続装置の該第２の呼接続手順において、通話終了処理を行う前に、該発信端末又は該着信端末へ所定のメッセージが通知されるように、メッセージ信号を送信することを特徴とする電話回線接続方法。