呼制御装置及び呼制御方法
【課題】同一の着信先に対して大量の呼が集中した際の負荷増大を抑制でき、故意の攻撃や転送呼ループが形成されても適切に転送を中断して交換機能を維持できるようにすること。
【解決手段】ＶｏＩＰ網１０上のソフトスイッチ１３−１において発信側と着信側とを接続するための呼処理を行う場合、受信ＩＮＶＩＴＥからＴｏヘッダ３４のユーザパート３５を取り出して着信先毎にカウントする。ソフトスイッチ１３−１の呼規制手段２３が受信ＩＮＶＩＴＥに指定された着信先についてカウント値が上限値に達しているか否か判定し、カウント値が上限値に達していれば当該ＩＮＶＩＴＥによる入り呼の転送動作を規制する。
【解決手段】ＶｏＩＰ網１０上のソフトスイッチ１３−１において発信側と着信側とを接続するための呼処理を行う場合、受信ＩＮＶＩＴＥからＴｏヘッダ３４のユーザパート３５を取り出して着信先毎にカウントする。ソフトスイッチ１３−１の呼規制手段２３が受信ＩＮＶＩＴＥに指定された着信先についてカウント値が上限値に達しているか否か判定し、カウント値が上限値に達していれば当該ＩＮＶＩＴＥによる入り呼の転送動作を規制する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＶｏＩＰ(Voice over Internet Protocol)網において発信側と着信側との間に呼を接続するための処理を行う呼制御装置及び呼制御方法に関する。
【背景技術】
【０００２】
図１１は、公衆電話網（ＰＳＴＮ）とＶｏＩＰ網とをゲートウェイ装置を介して接続したネットワーク構成図である。公衆電話網はＰＢＸや局交換機等の回線交換機１で構成され、ＶｏＩＰ網は局交換機に相当するソフトスイッチ２で構成されている。回線交換機１及びソフトスイッチ２は複数のユーザ端末をそれぞれ収容している。例えば、ソフトスイッチ２に収容された発ユーザ端末４から回線交換機１に収容された着信先５へ発呼する場合、ソフトスイッチ２が発ユーザ端末４から受け取った通話要求に関するリクエストを、公衆電話網の回線交換機１へ送信する。公衆電話網の回線交換機１は収容端末に対する入り呼を受信すると、該当する着信先５へ着信させる。このとき、ＶｏＩＰ網から公衆電話網へ入る際にゲートウェイ装置６でＶｏＩＰプロトコルから公衆電話網のプロトコルに対応した信号形態に変換している。また、回線交換機１及びソフトスイッチ２には転送機能を搭載することもできる。例えば、ソフトスイッチ２の収容端末４に対する呼を、回線交換機１の収容端末へ転送するように設定することができる。その逆に回線交換機１の収容端末に対する呼を、ソフトスイッチ２の収容端末へ転送するように設定することもできる。ある発信端末からソフトスイッチ２の収容端末４に対する入り呼が発生すると、ソフトスイッチ２は収容端末４へ着信させずに、回線交換機１に対して当該入り呼を転送して収容端末５に着信させることができる。
【０００３】
ところで、上記回線交換機１の収容端末５を着信先とした呼を、ソフトスイッチ２の収容端末４へ転送するように設定がされていた場合、ソフトスイッチ２から回線交換機１に対して送出した呼が、再び戻ってくることになる。ソフトスイッチ２は上記転送設定にしたがって再び回線交換機１の収容端末５へ転送するので、ソフトスイッチ２と回線交換機１との間で呼がループする現象が生じる。また、上記回線交換機１に収容端末５に対する呼を、ソフトスイッチ２以外の収容端末へ転送するように設定されていた場合であっても、他のソフトスイッチ又は回線交換機を経由してソフトスイッチ２に戻ってくる可能性がある。
【０００４】
このように、ＶｏＩＰ網のソフトスイッチ２と公衆電話網の回線交換機１との間でループが形成されて呼の転送が繰り返されると、ゲートウェイ装置６の収容回線を順次消費していき使用回線数が収容回線数の最大値に達したところで処理不能になるといった問題がある。また、ソフトスイッチ２及び回線交換機１において本来不要な呼処理（ループ）に関する負荷が大幅に増大して通信不能に陥る危険性がある。
【０００５】
ＳＩＰ対応のソフトスイッチの場合、ダイアログＩＤのユニーク特性又はMax-Forwards ヘッダを使用することにより、呼の転送によって形成されるループを防ぐことができる。ＳＩＰ対応のソフトスイッチは、転送呼に対してReferred-Byヘッダ等を用いて転送元情報を付与する。そこで、入り呼に付与されているReferred-Byヘッダから転送回数を検出して、例えば５回目以降は転送しないようにすることができる。また、Max-Forwards のデクリメント値が下限に達した時点で転送処理を中断すれば、呼のループを防止することができる。
【０００６】
なお、ＡＴＭ（Asynchronous Transfer Mode）交換システム又はフレームリレー交換システムのように通信データメッセージを所定データ長のセグメントデータにセグメント化して伝送することにより、コネクションレスで交換処理を行う交換システムにおいて、輻輳等の障害の発生により伝送中のメッセージ情報の廃棄を行うにあたり、メッセージ情報を無差別的でなく積極的に選択して廃棄して、伝送中のメッセージのうちの一部のメッセージを選択的に確実に伝送し、システムの実質的な伝送効率を高めることが提案されている（例えば、特許文献１参照）。
【特許文献１】特開平９−１１６５５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記従来技術のダイアログＩＤのユニーク特性又はMax-Forwards ヘッダを利用したループ防止機能は、ＰＳＴＮプロトコルとＶｏＩＰプロトコルを変換するゲートウェイ装置やＢ２ＢＵＡ（Back Ｔｏ Back User Agent）タイプのエンティティが間にあった場合には、ダイアログＩＤが毎回変化し、Max-Forwardsのデクリメント値もクリアされてしまうため使用できない。また、上記ループ防止機能はソフトスイッチが転送呼に対してReferred-Byヘッダを付与することを前提とするが、通信事業者によっては転送呼であってもReferred-Byヘッダを付与しないことがあるので、必ずしもループ防止機能が機能するとは限らないといった問題がある。
また、ＳＩＰ−ＰＳＴＮ間のゲートウェイ装置に限らず、MGCP
(Media Gateway Control Protocol)-ＳＩＰ間やＨ．３２３-ＳＩＰ間のトランキングを行うゲートウェイ装置、また、ＳＩＰ-ＳＩＰ間でも音声を扱う装置（例えば、ＳＢＣ(Session Boarder
Controller)）が間にあるケースでも同様にループによる呼の転送が繰り返されて資源（収容回線）が枯渇する問題が発生する。
【０００８】
また、ソフトスイッチ又は回線交換機に収容された特定の着信先に対して故意に大量の呼を集中させてソフトスイッチ又は回線交換機に過大な負荷を与え、交換機能を停滞させる攻撃事例も報告されている。しかしながら、上記ループ防止機能を含めて現状の防御機能ではこれらの攻撃を十分に防ぐことができなかった。
【０００９】
本発明は、以上のような実情に鑑みてなされたもので、一方ではループ形成の有無に拘わらず同一のユーザに着信する数を制限可能でソフトスイッチの過負荷を防止でき、他方でループ回避することができて、それによる資源（収容回線）の枯渇防止及び回線交換機やソフトスイッチの過負荷防止を図る呼制御装置及び呼制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の呼制御装置は、ＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼処理手段と、前記呼処理手段が受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントするカウント手段と、前記呼処理手段が受信したリクエストに指定された着信先について前記カウント値が上限値に達している場合、当該リクエストの転送動作を規制する呼規制手段とを具備したことを特徴とする。
【００１１】
このように構成された呼制御装置によれば、同一の着信先を指定したリクエストが大量に発生した場合に、当該着信先についてカウント値が上限値に達して転送動作されなくなるので、同一の着信先に対して大量の呼が集中することを防止でき、ソフトスイッチの過負荷防止を図ることができる。また、リクエストの着信先情報は転送を繰り返しても変化しないので、異プロトコル上の呼処理サーバとの間で転送呼がループするようなことがあっても着信先についてカウント値が上限値に達して転送動作されなくなり、異プロトコル上の呼処理サーバとの間に配置されたゲートウェイ装置等において資源（収容回線）が枯渇するといった不具合を防止することができる。
【００１２】
また、本発明は、上記呼制御装置において、高速アクセス可能な内部メモリに対して前記カウント値の書込み及び読出しを行うことを特徴とする。
【００１３】
このように、高速アクセス可能な内部メモリに対してカウント値の書込み及び読出しを行うことにより、メモリアクセス時の待ち時間を短縮できるので、内部メモリに対して頻繁にアクセスが発生したとしても、リクエストに指定された着信先についてカウンタ値が上限値に達しているか否かの判断に要する処理負担を軽減できる。
【００１４】
また、本発明は、上記呼制御装置において、前記各カウント値にスイープインターバルを設定し、スイープインターバル期間内に変化しなかったカウント値を０クリアすることを特徴とする。
【００１５】
これにより、スイープインターバル期間に変化しなかったカウント値を０クリアするので、短時間に呼が集中している着信先以外についてはカウント値を整理することができる。
【００１６】
上記呼制御装置において、前記呼処理手段はＳＩＰ(Session Initiation Protocol)に基づいて呼処理を行い、前記カウント手段はＩＮＶＩＴＥリクエストのＴｏヘッダから着信先情報を取得するものとする。
【００１７】
また、上記呼制御装置において、前記呼処理手段はＨ．３２３に基づいて呼処理を行い、前記カウント手段はＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒから着信先情報を取得するものとする。
【００１８】
また、本発明の呼制御方法は、ＶｏＩＰ網上で発信側と着信側とを接続するための呼処理を行う呼制御方法において、受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントする工程と、受信したリクエストに指定された着信先について前記カウント値が上限値に達しているか否か判定する工程と、前記判定の結果、前記カウント値が上限値に達していた場合に当該リクエストの転送動作を規制する工程とを具備したことを特徴とする。
【００１９】
このように構成された呼制御方法によれば、同一の着信先を指定したリクエストが大量に発生した場合に、当該着信先についてカウント値が上限値に達して転送動作されなくなるので、同一の着信先に対して大量の呼が集中することを防止でき、呼処理の負荷増大による通信不能状態を回避することができる。
【発明の効果】
【００２０】
本発明によれば、ループ形成の有無に拘わらず同一のユーザに着信する数を制限可能でソフトスイッチの過負荷を防止できる一方、ループ回避することができて資源（収容回線）の枯渇防止及び回線交換機やソフトスイッチの過負荷防止を図ることができる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の一実施の形態に係る呼制御装置としてＳＩＰ対応のソフトスイッチを説明するが、本発明はＳＩＰ対応のソフトスイッチに限定されるものではない。
図１は本実施の形態に係るソフトスイッチを備えたＶｏＩＰ網及びゲートウェイ装置を介して接続された異プロトコル網からなるネットワーク構成図である。ＶｏＩＰ網１０はＳＩＰに基づいて呼処理する複数のソフトスイッチ１３−１〜１３−ｎで構成されており、異プロトコル網１１は１つ又は複数の呼処理サーバで構成されている。図１に示す異プロトコル網１１では１つの呼処理サーバを例示している。ＶｏＩＰ網１０と異プロトコル網１１とは互いのプロトコルを変換するゲートウェイ装置１２を介して接続されている。ソフトスイッチ１３−１、１３−２等は、それぞれ加入者端末となるユーザ端末１５−１〜１５−ｎ、１６−１〜１６−ｎを収容しており、加入者毎に転送先などの設定をできるように構成されている。呼処理サーバ１４は加入者端末となるユーザ端末１７−１〜１７−ｎを収容しており、加入者毎に転送先などの設定をできるように構成されている。
【００２２】
図２はソフトスイッチ１３−１の概念図である。ソフトスイッチ１３−１は、ＳＩＰに基づいてＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼処理手段２０を備える。さらに、ソフトスイッチ１３−１は、ＩＮＶＩＴＥリクエストから着信先情報を取り出して着信先毎にカウントするカウント手段２１と、着信先毎にカウントされるカウント値を記録するための着ユーザカウント用メモリ２２と、同一の着信先に対して集中する呼を規制する呼規制手段２３と、着ユーザカウント用メモリ２２においてスイープインターバル期間内に変化しなかった着信先情報（少なくともカウント値を含む）を０クリアするクリア手段２４とを備える。カウント手段２１は、他のソフトスイッチ又は回線交換機から受信したＩＮＶＩＴＥリクエストのＴｏヘッダからユーザパートを取り出して、ユーザパートにセットされた着信先毎にカウントする。図４はＩＮＶＩＴＥリクエストの概念図である。ＳＩＰで用いられるＩＮＶＩＴＥリクエストは、主にスタートライン３１、ヘッダフィールド３２、空行及びボディ３３で構成されている。ヘッダフィールド３２におけるＴｏヘッダ３４には、リクエストの着信先を示すユーザパート３５が設けられている。図４に示すリクエストに設定された各パラメータは転送される度に各部が書き換えられるが、Ｔｏヘッダ３４のユーザパート３５は転送されても変化しない。本実施の形態は、Ｔｏヘッダ３４のユーザパート３５が転送されても変化しないことに着目して、同一呼のリクエストを繰り返し転送していることを検出すると共に、特定の着信先に呼が集中していることを検出するようにした。
【００２３】
その他のソフトスイッチ１３−２〜１３−ｎは、上記ソフトスイッチ１３−１と同様に構成されているものとする。
【００２４】
図３は、着ユーザカウント用メモリ２２に書き込まれる書込み情報の概念図である。着ユーザカウント用メモリ２２には、着信先の加入者番号２５、同一の着信先のカウント値２６及びカウント値２６の最新更新時間２７が書き込まれる。呼規制手段２３はカウント値２６が所定時間内に所定値に到達したら当該リクエストの転送を中断する。
【００２５】
次に、以上のように構成された本実施の形態の動作について説明する。
図５はソフトスイッチ１３−１において呼の転送を規制する際のフロー図である。ソフトスイッチ１３−１は、ＶｏＩＰ網１０の他のソフトスイッチ１３−２〜１３−ｎからＩＮＶＩＴＥリクエストを受信し、又は異プロトコル網１１の呼処理サーバ１４からゲートウェイ装置１２経由でＩＮＶＩＴＥリクエストを受信する。
【００２６】
ソフトスイッチ１３−１の呼処理手段２０がＩＮＶＩＴＥを受信すると（ステップＳ１）、他のソフトスイッチ又は他の呼処理サーバへ転送を要する呼の場合には、カウント手段２１が当該ＩＮＶＩＴＥのＴｏヘッダ３４からユーザパート３５を取得する（ステップＳ２）。今回取得したユーザパート３５が示す「着信先」と同一の着信先（加入者番号２５）が着ユーザカウント用メモリ２２に存在するか否か判断する（ステップＳ３）。着ユーザカウント用メモリ２２に同一の着信先が登録されていない場合は、着ユーザカウント用メモリ２２に今回取得した「着信先」として加入者番号２５を追加登録し（ステップS４）、さらにカウント値２６に１を設定する（ステップＳ５）。本実施の形態では、カウント値のゼロクリア契機を得るために更新時間２７も同時に登録している。
【００２７】
一方、ステップＳ３の判定で同一の着信先が着ユーザカウント用メモリ２２に登録されていた場合は、当該着信先のカウント値２６を着ユーザカウント用メモリ２２から読み込んで予め設定されている上限値に到達しているか否か判断する(ステップＳ６)。カウント値２６が上限値に到達していなければ、当該着信先のカウント値２６を１つアップさせる(ステップＳ７)。
【００２８】
以上のように、着ユーザカウント用メモリ２２に今回取得した「着信先」と同一の着信先が登録されていなかった場合（ステップＳ３、Ｓ４，Ｓ５）、並びに当該着信先のカウント値２６が上限値に到達していなかった場合（ステップＳ６、Ｓ７）は、呼処理手段２０に転送許可を与えて他のソフトスイッチ又は他の呼処理サーバへ転送させる（ステップＳ８）。これにより、特定の着信先に対して呼が集中していない場合には、従来通り転送処理を実施することができる。
【００２９】
一方、上記ステップＳ６の判定で着信先のカウント値２６が上限値に到達していた場合は、ＩＮＶＩＴＥ送信元に対して４０３レスポンスを返送して、転送動作は行わない（ステップＳ９）。このように、同一の着信先のカウント値が所定時間内に予め設定した上限値に到達した場合には、当該着信先のカウント値２６がゼロクリアされるまで、当該ソフトスイッチ１３−１を経由して当該着信先を収容する他のソフトスイッチ又は回線交換機へ呼を転送できないことになる。例えば、ソフトスイッチ１３−２に収容されたユーザ端末１６−１を着信先としたＩＮＶＩＴＥが短時間に集中した場合、ソフトスイッチ１３−２にＩＮＶＩＴＥを転送する周囲のソフトスイッチ１３−１等において上記した転送制限が掛かりソフトスイッチ１３−２の負荷増大を防止することができる。
【００３０】
次に、着ユーザカウント用メモリ２２に着信先毎に蓄積しているカウント値２６をゼロクリアする契機について説明する。
【００３１】
図６は着ユーザカウント用メモリ２２のカウント値をゼロクリアする動作を示すフロー図である。本実施の形態では、発側へのファイナルレスポンス送信時（ステップＳ２０）、及びスイープインターバル経過時（ステップＳ２１）にカウント値をゼロクリアする。カウンタ手段２１は、呼処理手段２０が発側へファイナルレスポンスを送信する際に（ステップＳ２０）、当該リクエストのＴｏヘッダ３４からユーザパート３５を取得し（ステップＳ２２）、着ユーザカウント用メモリ２２に取得したユーザパート３５と同一の着信先（加入者番号２５）が登録されているか否か判断する（ステップＳ２３）。同一の着信先が登録されていた場合は、クリア手段２４に指示して着ユーザカウント用メモリ２２の当該着信先のカウント値２６を０クリアする（ステップＳ２４）。
【００３２】
また、クリア手段２４は、着ユーザカウント用メモリ２２に登録された着信先について、最新の更新時刻２５から予め設定したスイープインターバルを経過している着信先を検出する（ステップＳ２１）。スイープインターバルを経過しているカウント値２６があれば、それを０クリアする（ステップＳ２４）。
【００３３】
なお、ステップＳ２４では、カウント値２６だけでなく、着信先情報（加入者番号２５、カウント値２６及び更新時間２７）を全て削除しても良い。
【００３４】
このように、発側へのファイナルレスポンス送信時（ステップＳ２０）及びスイープインターバル経過時（ステップＳ２１）にカウント値をゼロクリアするので、特定の収容端末に所定時間（短時間）のうちに呼が集中する場合にだけ、当該着信先が指定されたＩＮＶＩＴＥの転送を制限することができる。また、スイープインターバル経過時（ステップＳ２１）にカウント値をゼロクリアするので、ファイナルレスポンスがなされない等の０クリア契機を失った場合にカウント値が整理されずに残ってしまう不都合を防止できる。
【００３５】
次に、２つのソフトスイッチ間で呼転送が繰り返されるループが形成される設定になっていた場合に、呼転送を中断する動作について具体例に基づいて説明する。
【００３６】
図７は、呼転送のループが形成されるように転送設定されたソフトスイッチＡ及びソフトスイッチＢのシーケンス図である。ソフトスイッチＡ及びソフトスイッチＢは、上記ソフトスイッチ１３−１と同様の構成を有しているものとする。
【００３７】
図７には、発信端末（加入者番号＝0312345678）からソフトスイッチＡに収容されているユーザ端末（加入者番号＝05011110001）に対して発信し、ソフトスイッチＡがユーザ端末（05011110001）の設定に基づいて他のソフトスイッチＢに収容されたユーザ端末（加入者番号＝09011110001）へ呼を転送し、ソフトスイッチＢがユーザ端末（09011110001）の設定に基づいてソフトスイッチＡに収容されたユーザ端末（05011110001）へ呼を転送する場合を例示している。
【００３８】
回線交換機に収容された発信端末からソフトスイッチＡの収容端末（05011110001）に対して発呼があると、ソフトスイッチＡは図８（ａ）に示すＩＮＶＩＴＥを受信する。ソフトスイッチＡは、受信ＩＮＶＩＴＥのリクエストＵＲＩから自己が収容しているユーザ端末（05011110001）が着信先であると判断する。ユーザ端末（05011110001）には上記転送先が設定されているので、転送先のユーザ端末（09011110001）を着信先（Ｔｏヘッダ）に設定したＩＮＶＩＴＥを生成して当該入り呼を着信先のユーザ端末（09011110001）を収容しているソフトスイッチＢへ送信する。図８（ｂ）はソフトスイッチＡからソフトスイッチＢへ呼を転送するＩＮＶＩＴＥのヘッダ構成を示している。Ｔｏヘッダのユーザパートに着信先を示す"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている。また、ユーザ端末（05011110001）からの転送呼であることを示すReferred-By:
<sip:05011110001@172.17.19.25>が付加されている。
【００３９】
ソフトスイッチＢでは、図８（ｂ）に示すＩＮＶＩＴＥを受信する。ソフトスイッチＢは、受信ＩＮＶＩＴＥのリクエスト行から当該クエストの宛先は自己が収容しているユーザ端末（09011110001）であると判断する。ユーザ端末（09011110001）には上記転送先が設定されているので、転送先のユーザ端末（05011110001）を着信先（Ｔｏヘッダ）に設定したＩＮＶＩＴＥを生成して当該入り呼を着信先のユーザ端末（05011110001）を収容しているソフトスイッチＡへ転送する。図９（ａ）はソフトスイッチＢからソフトスイッチＡへ呼を転送した際のＩＮＶＩＴＥのヘッダ構成を示している。Ｔｏヘッダのユーザパートに着信先を示す"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている。すなわち、転送呼であってもＴｏヘッダのユーザパートは変化していない。また、ソフトスイッチＢは、呼を転送してもReferred-Byヘッダを追加する設定となっておらず、Referred-Byヘッダが削除されている。Max-Forwardsヘッダのデクリメント値も初期化されている。したがって、このＩＮＶＩＴＥを受信したソフトスイッチＡは、Referred-Byヘッダ及びMax-Forwardsヘッダを使用してもループを防止することはできない。
【００４０】
本実施の形態は、上記した通りＴｏヘッダのユーザパート（"09011110001" <sip:09011110001@172.17.19.25:5060>）を取り出して、着信先毎に同一呼のＩＮＶＩＴＥを何回受信したかをカウントしている。図７に示すシーケンスでは転送１回目であるので、着信先（"09011110001" <sip:09011110001@172.17.19.25:5060>）に対するカウント値は１となる。
【００４１】
図７に示すように、ソフトスイッチＡからソフトスイッチＢへ再び同一呼のＩＮＶＩＴＥが転送され、当該ＩＮＶＩＴＥを受けたソフトスイッチＢがソフトスイッチＡに対して同一呼のＩＮＶＩＴＥを再び転送する。図９（ｂ）はソフトスイッチＢからソフトスイッチＡに対しての２回目転送時のＩＮＶＩＴＥのヘッダ構成を示している。Ｔｏヘッダのユーザパートに着信先を示す"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている。転送２回目であるので、同一の着信先（"09011110001" <sip:09011110001@172.17.19.25:5060>）に対するカウント値は１つインクリメントして２となる。
【００４２】
ソフトスイッチＡにおいて着ユーザカウント値の上限値を５に設定しておけば、ソフトスイッチＡからはＴｏヘッダのユーザパートに"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている呼について５回目以降は転送を中断することとなる。
【００４３】
以上のようにして、各ソフトスイッチではReferred-Byヘッダ及びMax-Forwardsヘッダを使用することなく、確実にループを防止することができる。
【００４４】
本実施の形態では、ソフトスイッチにおいて呼規制手段２３が着信先毎のカウント値を記録するために高速アクセス可能な内部記憶媒体として着ユーザカウント用メモリ２２を用いている。このため、ソフトスイッチの負荷を増大させること無く入り呼の制限が可能である。
【００４５】
但し、着ユーザカウント用メモリ２２に代えてハードディスクで構成されるデータベースを用いても、同一ユーザに着信する着信数の制限及びループ回避は可能である。データベースに着信先毎のカウント値を記録する場合、着ユーザカウント用メモリ２２に比べてアクセス速度は低下することになるが、アクセス速度の低下が問題にならないのであれば、データベースを利用することもできる。
【００４６】
本発明は、ＳＩＰ対応のソフトスイッチに限定されるものではなく、ＳＩＰ以外のＶｏＩＰプロトコル（例えば、Ｈ．３２３）に基づいて動作する呼制御装置にも同様に適用することができる。
【００４７】
図１０は、Ｈ．３２３網上のゲートキーパとＳＩＰ網上のソフトスイッチとの間にループが形成された状態を示すシーケンス図である。Ｈ．３２３に基づいて動作する呼制御装置としてゲートキーパ３１が示されている。また、ＳＩＰ網上の呼制御装置としてソフトスイッチ３２、Ｈ．３２３網とＳＩＰ網との間にプロトコル変換を行う装置としてゲートウェイ装置３３が示されている。Ｈ．３２３網においては通話要求に関するリクエストとしてＳｅｔｕｐリクエストが用いられる。
【００４８】
Ｈ．３２３網において発信端末からＳｅｔｕｐリクエストを受け取ったゲートキーパ３１は、着信先が異プロトコルのソフトスイッチ３２に収容された端末の場合には、Ｃａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒに当該着信先の加入者番号を設定したＳｅｔｕｐリクエストをゲートウェイ装置３３経由でソフトスイッチ３２へ送信する。Ｓｅｔｕｐリクエストはゲートウェイ装置３３でＩＮＶＩＴＥリクエストに変換されるが、Ｃａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒの書き換えは行われない。
【００４９】
ソフトスイッチ３２が収容する着信先の設定内容が、当該端末に対する呼をゲートキーパ３１が収容する端末へ転送することとなっているものとする。この場合、図１０に示すようにゲートキーパ３１が収容する端末を宛先としたＩＮＶＩＴＥリクエストによって呼が転送される。このとき、上記した通り、Ｔｏヘッダの着信先情報はそのまま変化せずに維持される。このようにして、ＳＩＰ網側においてループが発生する。
【００５０】
ゲートキーパ３１においても、ＳＩＰ網側からＩＮＶＩＴＥリクエストを変換したＳｅｔｕｐリクエストを受信するが、当該着信先に対する転送設定は変わっていないので、再びソフトスイッチ３２が収容する同一端末を宛先としたＳｅｔｕｐリクエストを生成してゲートウェイ装置３３経由でソフトスイッチ３２へ送信する。このとき、Ｓｅｔｕｐリクエスト上で着信先を指定しているＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒは書き換えられずに維持される。このようにして、Ｈ．３２３網側においてもループが発生する。
【００５１】
本発明では、ゲートキーパ３１及びソフトスイッチ３２の双方において、図２に示す構成及び図５に示す処理内容に基づいて、ゲートキーパ３１では受信したＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒから同一着信先をカウントして上限値に達した時点で転送を制限する。ソフトスイッチ３２では受信したＩＮＶＩＴＥリクエストのＴｏヘッダから同一着信先をカウントして上限値に達した時点で転送を制限する。
【００５２】
このように、Ｈ．３２３網上の呼処理サーバであるゲートキーパ３１においても他の異プロトコルの呼処理サーバとの間で呼の転送が繰り返されるループが発生した場合に、ゲートウェイ装置３３で資源が枯渇する不具合を未然に防止できる。
【００５３】
以上の説明では、主に呼処理サーバ間で呼の転送が繰り返されるループ発生のケースを例に説明したが、本発明はこのようなループ回避目的に限定されるものではない。本発明は、ＶｏＩＰ網上の通話要求に関するリクエストの着信先情報（ＩＮＶＩＴＥリクエストのＴｏヘッダ、ＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒ）をチェックしてカウントする機能を搭載したことにより、ループ回避機能の他に、ループの有無に拘わらず同一ユーザに着信する着信数を制限することができる。したがって、呼処理サーバ間でループ形成される設定となっていない場合であっても、同一ユーザに着信する着信数を制限するという機能を発揮でき、従来技術では簡易な方法で防御が困難であった特定の着信先に対して故意に大量の呼を集中させる攻撃に対しても、上気した通りの簡易な構成で確実に防御することができる。
【図面の簡単な説明】
【００５４】
【図１】本発明の一実施の形態に係るソフトスイッチを備えたＶｏＩＰ網及び公衆電話網からなるネットワーク構成図
【図２】上記一実施の形態におけるソフトスイッチの概念図
【図３】上記一実施の形態において着ユーザカウント用メモリに書き込まれる書込み情報の概念図
【図４】ＳＩＰリクエストの構成例を示す図
【図５】上記一実施の形態のソフトスイッチにおいて呼の転送を規制する際のフロー図
【図６】上記一実施の形態のソフトスイッチにおいてカウント値を０クリアするフロー図
【図７】発信端末からリクエストを受けた際のソフトスイッチ間のシーケンス図
【図８】（ａ）発信端末からソフトスイッチＡへ送信されたＩＮＶＩＴＥの構成図、（ｂ）ソフトスイッチＡからソフトスイッチＢへ１回目の転送で送信されたＩＮＶＩＴＥの構成図
【図９】（ａ）ソフトスイッチＢからソフトスイッチＡへ１回目の転送で送信されたＩＮＶＩＴＥの構成図、（ｂ）ソフトスイッチＢからソフトスイッチＡへ２回目の転送で送信されたＩＮＶＩＴＥの構成図
【図１０】Ｈ．３２３網上のゲートキーパとＳＩＰ網上のソフトスイッチとの間にループが形成された状態を示すシーケンス図
【図１１】公衆電話網とＶｏＩＰ網とをゲートウェイ装置を介して接続したネットワーク構成図
【符号の説明】
【００５５】
１０…ＶｏＩＰ網
１１…公衆電話網
１２…ゲートウェイ装置
１３−１〜１３−ｎ…ソフトスイッチ
１４…回線交換機
１５−１〜１５−ｎ、１６−１〜１６−ｎ、１７−１〜１７−ｎ…ユーザ端末
２０…呼処理手段
２１…カウント手段
２２…着ユーザカウント用メモリ
２３…呼規制手段
２４…クリア手段
２５…加入者番号
２６…カウント値
２７…更新時間
【技術分野】
【０００１】
本発明は、ＶｏＩＰ(Voice over Internet Protocol)網において発信側と着信側との間に呼を接続するための処理を行う呼制御装置及び呼制御方法に関する。
【背景技術】
【０００２】
図１１は、公衆電話網（ＰＳＴＮ）とＶｏＩＰ網とをゲートウェイ装置を介して接続したネットワーク構成図である。公衆電話網はＰＢＸや局交換機等の回線交換機１で構成され、ＶｏＩＰ網は局交換機に相当するソフトスイッチ２で構成されている。回線交換機１及びソフトスイッチ２は複数のユーザ端末をそれぞれ収容している。例えば、ソフトスイッチ２に収容された発ユーザ端末４から回線交換機１に収容された着信先５へ発呼する場合、ソフトスイッチ２が発ユーザ端末４から受け取った通話要求に関するリクエストを、公衆電話網の回線交換機１へ送信する。公衆電話網の回線交換機１は収容端末に対する入り呼を受信すると、該当する着信先５へ着信させる。このとき、ＶｏＩＰ網から公衆電話網へ入る際にゲートウェイ装置６でＶｏＩＰプロトコルから公衆電話網のプロトコルに対応した信号形態に変換している。また、回線交換機１及びソフトスイッチ２には転送機能を搭載することもできる。例えば、ソフトスイッチ２の収容端末４に対する呼を、回線交換機１の収容端末へ転送するように設定することができる。その逆に回線交換機１の収容端末に対する呼を、ソフトスイッチ２の収容端末へ転送するように設定することもできる。ある発信端末からソフトスイッチ２の収容端末４に対する入り呼が発生すると、ソフトスイッチ２は収容端末４へ着信させずに、回線交換機１に対して当該入り呼を転送して収容端末５に着信させることができる。
【０００３】
ところで、上記回線交換機１の収容端末５を着信先とした呼を、ソフトスイッチ２の収容端末４へ転送するように設定がされていた場合、ソフトスイッチ２から回線交換機１に対して送出した呼が、再び戻ってくることになる。ソフトスイッチ２は上記転送設定にしたがって再び回線交換機１の収容端末５へ転送するので、ソフトスイッチ２と回線交換機１との間で呼がループする現象が生じる。また、上記回線交換機１に収容端末５に対する呼を、ソフトスイッチ２以外の収容端末へ転送するように設定されていた場合であっても、他のソフトスイッチ又は回線交換機を経由してソフトスイッチ２に戻ってくる可能性がある。
【０００４】
このように、ＶｏＩＰ網のソフトスイッチ２と公衆電話網の回線交換機１との間でループが形成されて呼の転送が繰り返されると、ゲートウェイ装置６の収容回線を順次消費していき使用回線数が収容回線数の最大値に達したところで処理不能になるといった問題がある。また、ソフトスイッチ２及び回線交換機１において本来不要な呼処理（ループ）に関する負荷が大幅に増大して通信不能に陥る危険性がある。
【０００５】
ＳＩＰ対応のソフトスイッチの場合、ダイアログＩＤのユニーク特性又はMax-Forwards ヘッダを使用することにより、呼の転送によって形成されるループを防ぐことができる。ＳＩＰ対応のソフトスイッチは、転送呼に対してReferred-Byヘッダ等を用いて転送元情報を付与する。そこで、入り呼に付与されているReferred-Byヘッダから転送回数を検出して、例えば５回目以降は転送しないようにすることができる。また、Max-Forwards のデクリメント値が下限に達した時点で転送処理を中断すれば、呼のループを防止することができる。
【０００６】
なお、ＡＴＭ（Asynchronous Transfer Mode）交換システム又はフレームリレー交換システムのように通信データメッセージを所定データ長のセグメントデータにセグメント化して伝送することにより、コネクションレスで交換処理を行う交換システムにおいて、輻輳等の障害の発生により伝送中のメッセージ情報の廃棄を行うにあたり、メッセージ情報を無差別的でなく積極的に選択して廃棄して、伝送中のメッセージのうちの一部のメッセージを選択的に確実に伝送し、システムの実質的な伝送効率を高めることが提案されている（例えば、特許文献１参照）。
【特許文献１】特開平９−１１６５５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記従来技術のダイアログＩＤのユニーク特性又はMax-Forwards ヘッダを利用したループ防止機能は、ＰＳＴＮプロトコルとＶｏＩＰプロトコルを変換するゲートウェイ装置やＢ２ＢＵＡ（Back Ｔｏ Back User Agent）タイプのエンティティが間にあった場合には、ダイアログＩＤが毎回変化し、Max-Forwardsのデクリメント値もクリアされてしまうため使用できない。また、上記ループ防止機能はソフトスイッチが転送呼に対してReferred-Byヘッダを付与することを前提とするが、通信事業者によっては転送呼であってもReferred-Byヘッダを付与しないことがあるので、必ずしもループ防止機能が機能するとは限らないといった問題がある。
また、ＳＩＰ−ＰＳＴＮ間のゲートウェイ装置に限らず、MGCP
(Media Gateway Control Protocol)-ＳＩＰ間やＨ．３２３-ＳＩＰ間のトランキングを行うゲートウェイ装置、また、ＳＩＰ-ＳＩＰ間でも音声を扱う装置（例えば、ＳＢＣ(Session Boarder
Controller)）が間にあるケースでも同様にループによる呼の転送が繰り返されて資源（収容回線）が枯渇する問題が発生する。
【０００８】
また、ソフトスイッチ又は回線交換機に収容された特定の着信先に対して故意に大量の呼を集中させてソフトスイッチ又は回線交換機に過大な負荷を与え、交換機能を停滞させる攻撃事例も報告されている。しかしながら、上記ループ防止機能を含めて現状の防御機能ではこれらの攻撃を十分に防ぐことができなかった。
【０００９】
本発明は、以上のような実情に鑑みてなされたもので、一方ではループ形成の有無に拘わらず同一のユーザに着信する数を制限可能でソフトスイッチの過負荷を防止でき、他方でループ回避することができて、それによる資源（収容回線）の枯渇防止及び回線交換機やソフトスイッチの過負荷防止を図る呼制御装置及び呼制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の呼制御装置は、ＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼処理手段と、前記呼処理手段が受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントするカウント手段と、前記呼処理手段が受信したリクエストに指定された着信先について前記カウント値が上限値に達している場合、当該リクエストの転送動作を規制する呼規制手段とを具備したことを特徴とする。
【００１１】
このように構成された呼制御装置によれば、同一の着信先を指定したリクエストが大量に発生した場合に、当該着信先についてカウント値が上限値に達して転送動作されなくなるので、同一の着信先に対して大量の呼が集中することを防止でき、ソフトスイッチの過負荷防止を図ることができる。また、リクエストの着信先情報は転送を繰り返しても変化しないので、異プロトコル上の呼処理サーバとの間で転送呼がループするようなことがあっても着信先についてカウント値が上限値に達して転送動作されなくなり、異プロトコル上の呼処理サーバとの間に配置されたゲートウェイ装置等において資源（収容回線）が枯渇するといった不具合を防止することができる。
【００１２】
また、本発明は、上記呼制御装置において、高速アクセス可能な内部メモリに対して前記カウント値の書込み及び読出しを行うことを特徴とする。
【００１３】
このように、高速アクセス可能な内部メモリに対してカウント値の書込み及び読出しを行うことにより、メモリアクセス時の待ち時間を短縮できるので、内部メモリに対して頻繁にアクセスが発生したとしても、リクエストに指定された着信先についてカウンタ値が上限値に達しているか否かの判断に要する処理負担を軽減できる。
【００１４】
また、本発明は、上記呼制御装置において、前記各カウント値にスイープインターバルを設定し、スイープインターバル期間内に変化しなかったカウント値を０クリアすることを特徴とする。
【００１５】
これにより、スイープインターバル期間に変化しなかったカウント値を０クリアするので、短時間に呼が集中している着信先以外についてはカウント値を整理することができる。
【００１６】
上記呼制御装置において、前記呼処理手段はＳＩＰ(Session Initiation Protocol)に基づいて呼処理を行い、前記カウント手段はＩＮＶＩＴＥリクエストのＴｏヘッダから着信先情報を取得するものとする。
【００１７】
また、上記呼制御装置において、前記呼処理手段はＨ．３２３に基づいて呼処理を行い、前記カウント手段はＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒから着信先情報を取得するものとする。
【００１８】
また、本発明の呼制御方法は、ＶｏＩＰ網上で発信側と着信側とを接続するための呼処理を行う呼制御方法において、受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントする工程と、受信したリクエストに指定された着信先について前記カウント値が上限値に達しているか否か判定する工程と、前記判定の結果、前記カウント値が上限値に達していた場合に当該リクエストの転送動作を規制する工程とを具備したことを特徴とする。
【００１９】
このように構成された呼制御方法によれば、同一の着信先を指定したリクエストが大量に発生した場合に、当該着信先についてカウント値が上限値に達して転送動作されなくなるので、同一の着信先に対して大量の呼が集中することを防止でき、呼処理の負荷増大による通信不能状態を回避することができる。
【発明の効果】
【００２０】
本発明によれば、ループ形成の有無に拘わらず同一のユーザに着信する数を制限可能でソフトスイッチの過負荷を防止できる一方、ループ回避することができて資源（収容回線）の枯渇防止及び回線交換機やソフトスイッチの過負荷防止を図ることができる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の一実施の形態に係る呼制御装置としてＳＩＰ対応のソフトスイッチを説明するが、本発明はＳＩＰ対応のソフトスイッチに限定されるものではない。
図１は本実施の形態に係るソフトスイッチを備えたＶｏＩＰ網及びゲートウェイ装置を介して接続された異プロトコル網からなるネットワーク構成図である。ＶｏＩＰ網１０はＳＩＰに基づいて呼処理する複数のソフトスイッチ１３−１〜１３−ｎで構成されており、異プロトコル網１１は１つ又は複数の呼処理サーバで構成されている。図１に示す異プロトコル網１１では１つの呼処理サーバを例示している。ＶｏＩＰ網１０と異プロトコル網１１とは互いのプロトコルを変換するゲートウェイ装置１２を介して接続されている。ソフトスイッチ１３−１、１３−２等は、それぞれ加入者端末となるユーザ端末１５−１〜１５−ｎ、１６−１〜１６−ｎを収容しており、加入者毎に転送先などの設定をできるように構成されている。呼処理サーバ１４は加入者端末となるユーザ端末１７−１〜１７−ｎを収容しており、加入者毎に転送先などの設定をできるように構成されている。
【００２２】
図２はソフトスイッチ１３−１の概念図である。ソフトスイッチ１３−１は、ＳＩＰに基づいてＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼処理手段２０を備える。さらに、ソフトスイッチ１３−１は、ＩＮＶＩＴＥリクエストから着信先情報を取り出して着信先毎にカウントするカウント手段２１と、着信先毎にカウントされるカウント値を記録するための着ユーザカウント用メモリ２２と、同一の着信先に対して集中する呼を規制する呼規制手段２３と、着ユーザカウント用メモリ２２においてスイープインターバル期間内に変化しなかった着信先情報（少なくともカウント値を含む）を０クリアするクリア手段２４とを備える。カウント手段２１は、他のソフトスイッチ又は回線交換機から受信したＩＮＶＩＴＥリクエストのＴｏヘッダからユーザパートを取り出して、ユーザパートにセットされた着信先毎にカウントする。図４はＩＮＶＩＴＥリクエストの概念図である。ＳＩＰで用いられるＩＮＶＩＴＥリクエストは、主にスタートライン３１、ヘッダフィールド３２、空行及びボディ３３で構成されている。ヘッダフィールド３２におけるＴｏヘッダ３４には、リクエストの着信先を示すユーザパート３５が設けられている。図４に示すリクエストに設定された各パラメータは転送される度に各部が書き換えられるが、Ｔｏヘッダ３４のユーザパート３５は転送されても変化しない。本実施の形態は、Ｔｏヘッダ３４のユーザパート３５が転送されても変化しないことに着目して、同一呼のリクエストを繰り返し転送していることを検出すると共に、特定の着信先に呼が集中していることを検出するようにした。
【００２３】
その他のソフトスイッチ１３−２〜１３−ｎは、上記ソフトスイッチ１３−１と同様に構成されているものとする。
【００２４】
図３は、着ユーザカウント用メモリ２２に書き込まれる書込み情報の概念図である。着ユーザカウント用メモリ２２には、着信先の加入者番号２５、同一の着信先のカウント値２６及びカウント値２６の最新更新時間２７が書き込まれる。呼規制手段２３はカウント値２６が所定時間内に所定値に到達したら当該リクエストの転送を中断する。
【００２５】
次に、以上のように構成された本実施の形態の動作について説明する。
図５はソフトスイッチ１３−１において呼の転送を規制する際のフロー図である。ソフトスイッチ１３−１は、ＶｏＩＰ網１０の他のソフトスイッチ１３−２〜１３−ｎからＩＮＶＩＴＥリクエストを受信し、又は異プロトコル網１１の呼処理サーバ１４からゲートウェイ装置１２経由でＩＮＶＩＴＥリクエストを受信する。
【００２６】
ソフトスイッチ１３−１の呼処理手段２０がＩＮＶＩＴＥを受信すると（ステップＳ１）、他のソフトスイッチ又は他の呼処理サーバへ転送を要する呼の場合には、カウント手段２１が当該ＩＮＶＩＴＥのＴｏヘッダ３４からユーザパート３５を取得する（ステップＳ２）。今回取得したユーザパート３５が示す「着信先」と同一の着信先（加入者番号２５）が着ユーザカウント用メモリ２２に存在するか否か判断する（ステップＳ３）。着ユーザカウント用メモリ２２に同一の着信先が登録されていない場合は、着ユーザカウント用メモリ２２に今回取得した「着信先」として加入者番号２５を追加登録し（ステップS４）、さらにカウント値２６に１を設定する（ステップＳ５）。本実施の形態では、カウント値のゼロクリア契機を得るために更新時間２７も同時に登録している。
【００２７】
一方、ステップＳ３の判定で同一の着信先が着ユーザカウント用メモリ２２に登録されていた場合は、当該着信先のカウント値２６を着ユーザカウント用メモリ２２から読み込んで予め設定されている上限値に到達しているか否か判断する(ステップＳ６)。カウント値２６が上限値に到達していなければ、当該着信先のカウント値２６を１つアップさせる(ステップＳ７)。
【００２８】
以上のように、着ユーザカウント用メモリ２２に今回取得した「着信先」と同一の着信先が登録されていなかった場合（ステップＳ３、Ｓ４，Ｓ５）、並びに当該着信先のカウント値２６が上限値に到達していなかった場合（ステップＳ６、Ｓ７）は、呼処理手段２０に転送許可を与えて他のソフトスイッチ又は他の呼処理サーバへ転送させる（ステップＳ８）。これにより、特定の着信先に対して呼が集中していない場合には、従来通り転送処理を実施することができる。
【００２９】
一方、上記ステップＳ６の判定で着信先のカウント値２６が上限値に到達していた場合は、ＩＮＶＩＴＥ送信元に対して４０３レスポンスを返送して、転送動作は行わない（ステップＳ９）。このように、同一の着信先のカウント値が所定時間内に予め設定した上限値に到達した場合には、当該着信先のカウント値２６がゼロクリアされるまで、当該ソフトスイッチ１３−１を経由して当該着信先を収容する他のソフトスイッチ又は回線交換機へ呼を転送できないことになる。例えば、ソフトスイッチ１３−２に収容されたユーザ端末１６−１を着信先としたＩＮＶＩＴＥが短時間に集中した場合、ソフトスイッチ１３−２にＩＮＶＩＴＥを転送する周囲のソフトスイッチ１３−１等において上記した転送制限が掛かりソフトスイッチ１３−２の負荷増大を防止することができる。
【００３０】
次に、着ユーザカウント用メモリ２２に着信先毎に蓄積しているカウント値２６をゼロクリアする契機について説明する。
【００３１】
図６は着ユーザカウント用メモリ２２のカウント値をゼロクリアする動作を示すフロー図である。本実施の形態では、発側へのファイナルレスポンス送信時（ステップＳ２０）、及びスイープインターバル経過時（ステップＳ２１）にカウント値をゼロクリアする。カウンタ手段２１は、呼処理手段２０が発側へファイナルレスポンスを送信する際に（ステップＳ２０）、当該リクエストのＴｏヘッダ３４からユーザパート３５を取得し（ステップＳ２２）、着ユーザカウント用メモリ２２に取得したユーザパート３５と同一の着信先（加入者番号２５）が登録されているか否か判断する（ステップＳ２３）。同一の着信先が登録されていた場合は、クリア手段２４に指示して着ユーザカウント用メモリ２２の当該着信先のカウント値２６を０クリアする（ステップＳ２４）。
【００３２】
また、クリア手段２４は、着ユーザカウント用メモリ２２に登録された着信先について、最新の更新時刻２５から予め設定したスイープインターバルを経過している着信先を検出する（ステップＳ２１）。スイープインターバルを経過しているカウント値２６があれば、それを０クリアする（ステップＳ２４）。
【００３３】
なお、ステップＳ２４では、カウント値２６だけでなく、着信先情報（加入者番号２５、カウント値２６及び更新時間２７）を全て削除しても良い。
【００３４】
このように、発側へのファイナルレスポンス送信時（ステップＳ２０）及びスイープインターバル経過時（ステップＳ２１）にカウント値をゼロクリアするので、特定の収容端末に所定時間（短時間）のうちに呼が集中する場合にだけ、当該着信先が指定されたＩＮＶＩＴＥの転送を制限することができる。また、スイープインターバル経過時（ステップＳ２１）にカウント値をゼロクリアするので、ファイナルレスポンスがなされない等の０クリア契機を失った場合にカウント値が整理されずに残ってしまう不都合を防止できる。
【００３５】
次に、２つのソフトスイッチ間で呼転送が繰り返されるループが形成される設定になっていた場合に、呼転送を中断する動作について具体例に基づいて説明する。
【００３６】
図７は、呼転送のループが形成されるように転送設定されたソフトスイッチＡ及びソフトスイッチＢのシーケンス図である。ソフトスイッチＡ及びソフトスイッチＢは、上記ソフトスイッチ１３−１と同様の構成を有しているものとする。
【００３７】
図７には、発信端末（加入者番号＝0312345678）からソフトスイッチＡに収容されているユーザ端末（加入者番号＝05011110001）に対して発信し、ソフトスイッチＡがユーザ端末（05011110001）の設定に基づいて他のソフトスイッチＢに収容されたユーザ端末（加入者番号＝09011110001）へ呼を転送し、ソフトスイッチＢがユーザ端末（09011110001）の設定に基づいてソフトスイッチＡに収容されたユーザ端末（05011110001）へ呼を転送する場合を例示している。
【００３８】
回線交換機に収容された発信端末からソフトスイッチＡの収容端末（05011110001）に対して発呼があると、ソフトスイッチＡは図８（ａ）に示すＩＮＶＩＴＥを受信する。ソフトスイッチＡは、受信ＩＮＶＩＴＥのリクエストＵＲＩから自己が収容しているユーザ端末（05011110001）が着信先であると判断する。ユーザ端末（05011110001）には上記転送先が設定されているので、転送先のユーザ端末（09011110001）を着信先（Ｔｏヘッダ）に設定したＩＮＶＩＴＥを生成して当該入り呼を着信先のユーザ端末（09011110001）を収容しているソフトスイッチＢへ送信する。図８（ｂ）はソフトスイッチＡからソフトスイッチＢへ呼を転送するＩＮＶＩＴＥのヘッダ構成を示している。Ｔｏヘッダのユーザパートに着信先を示す"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている。また、ユーザ端末（05011110001）からの転送呼であることを示すReferred-By:
<sip:05011110001@172.17.19.25>が付加されている。
【００３９】
ソフトスイッチＢでは、図８（ｂ）に示すＩＮＶＩＴＥを受信する。ソフトスイッチＢは、受信ＩＮＶＩＴＥのリクエスト行から当該クエストの宛先は自己が収容しているユーザ端末（09011110001）であると判断する。ユーザ端末（09011110001）には上記転送先が設定されているので、転送先のユーザ端末（05011110001）を着信先（Ｔｏヘッダ）に設定したＩＮＶＩＴＥを生成して当該入り呼を着信先のユーザ端末（05011110001）を収容しているソフトスイッチＡへ転送する。図９（ａ）はソフトスイッチＢからソフトスイッチＡへ呼を転送した際のＩＮＶＩＴＥのヘッダ構成を示している。Ｔｏヘッダのユーザパートに着信先を示す"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている。すなわち、転送呼であってもＴｏヘッダのユーザパートは変化していない。また、ソフトスイッチＢは、呼を転送してもReferred-Byヘッダを追加する設定となっておらず、Referred-Byヘッダが削除されている。Max-Forwardsヘッダのデクリメント値も初期化されている。したがって、このＩＮＶＩＴＥを受信したソフトスイッチＡは、Referred-Byヘッダ及びMax-Forwardsヘッダを使用してもループを防止することはできない。
【００４０】
本実施の形態は、上記した通りＴｏヘッダのユーザパート（"09011110001" <sip:09011110001@172.17.19.25:5060>）を取り出して、着信先毎に同一呼のＩＮＶＩＴＥを何回受信したかをカウントしている。図７に示すシーケンスでは転送１回目であるので、着信先（"09011110001" <sip:09011110001@172.17.19.25:5060>）に対するカウント値は１となる。
【００４１】
図７に示すように、ソフトスイッチＡからソフトスイッチＢへ再び同一呼のＩＮＶＩＴＥが転送され、当該ＩＮＶＩＴＥを受けたソフトスイッチＢがソフトスイッチＡに対して同一呼のＩＮＶＩＴＥを再び転送する。図９（ｂ）はソフトスイッチＢからソフトスイッチＡに対しての２回目転送時のＩＮＶＩＴＥのヘッダ構成を示している。Ｔｏヘッダのユーザパートに着信先を示す"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている。転送２回目であるので、同一の着信先（"09011110001" <sip:09011110001@172.17.19.25:5060>）に対するカウント値は１つインクリメントして２となる。
【００４２】
ソフトスイッチＡにおいて着ユーザカウント値の上限値を５に設定しておけば、ソフトスイッチＡからはＴｏヘッダのユーザパートに"09011110001" <sip:09011110001@172.17.19.25:5060>が設定されている呼について５回目以降は転送を中断することとなる。
【００４３】
以上のようにして、各ソフトスイッチではReferred-Byヘッダ及びMax-Forwardsヘッダを使用することなく、確実にループを防止することができる。
【００４４】
本実施の形態では、ソフトスイッチにおいて呼規制手段２３が着信先毎のカウント値を記録するために高速アクセス可能な内部記憶媒体として着ユーザカウント用メモリ２２を用いている。このため、ソフトスイッチの負荷を増大させること無く入り呼の制限が可能である。
【００４５】
但し、着ユーザカウント用メモリ２２に代えてハードディスクで構成されるデータベースを用いても、同一ユーザに着信する着信数の制限及びループ回避は可能である。データベースに着信先毎のカウント値を記録する場合、着ユーザカウント用メモリ２２に比べてアクセス速度は低下することになるが、アクセス速度の低下が問題にならないのであれば、データベースを利用することもできる。
【００４６】
本発明は、ＳＩＰ対応のソフトスイッチに限定されるものではなく、ＳＩＰ以外のＶｏＩＰプロトコル（例えば、Ｈ．３２３）に基づいて動作する呼制御装置にも同様に適用することができる。
【００４７】
図１０は、Ｈ．３２３網上のゲートキーパとＳＩＰ網上のソフトスイッチとの間にループが形成された状態を示すシーケンス図である。Ｈ．３２３に基づいて動作する呼制御装置としてゲートキーパ３１が示されている。また、ＳＩＰ網上の呼制御装置としてソフトスイッチ３２、Ｈ．３２３網とＳＩＰ網との間にプロトコル変換を行う装置としてゲートウェイ装置３３が示されている。Ｈ．３２３網においては通話要求に関するリクエストとしてＳｅｔｕｐリクエストが用いられる。
【００４８】
Ｈ．３２３網において発信端末からＳｅｔｕｐリクエストを受け取ったゲートキーパ３１は、着信先が異プロトコルのソフトスイッチ３２に収容された端末の場合には、Ｃａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒに当該着信先の加入者番号を設定したＳｅｔｕｐリクエストをゲートウェイ装置３３経由でソフトスイッチ３２へ送信する。Ｓｅｔｕｐリクエストはゲートウェイ装置３３でＩＮＶＩＴＥリクエストに変換されるが、Ｃａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒの書き換えは行われない。
【００４９】
ソフトスイッチ３２が収容する着信先の設定内容が、当該端末に対する呼をゲートキーパ３１が収容する端末へ転送することとなっているものとする。この場合、図１０に示すようにゲートキーパ３１が収容する端末を宛先としたＩＮＶＩＴＥリクエストによって呼が転送される。このとき、上記した通り、Ｔｏヘッダの着信先情報はそのまま変化せずに維持される。このようにして、ＳＩＰ網側においてループが発生する。
【００５０】
ゲートキーパ３１においても、ＳＩＰ網側からＩＮＶＩＴＥリクエストを変換したＳｅｔｕｐリクエストを受信するが、当該着信先に対する転送設定は変わっていないので、再びソフトスイッチ３２が収容する同一端末を宛先としたＳｅｔｕｐリクエストを生成してゲートウェイ装置３３経由でソフトスイッチ３２へ送信する。このとき、Ｓｅｔｕｐリクエスト上で着信先を指定しているＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒは書き換えられずに維持される。このようにして、Ｈ．３２３網側においてもループが発生する。
【００５１】
本発明では、ゲートキーパ３１及びソフトスイッチ３２の双方において、図２に示す構成及び図５に示す処理内容に基づいて、ゲートキーパ３１では受信したＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒから同一着信先をカウントして上限値に達した時点で転送を制限する。ソフトスイッチ３２では受信したＩＮＶＩＴＥリクエストのＴｏヘッダから同一着信先をカウントして上限値に達した時点で転送を制限する。
【００５２】
このように、Ｈ．３２３網上の呼処理サーバであるゲートキーパ３１においても他の異プロトコルの呼処理サーバとの間で呼の転送が繰り返されるループが発生した場合に、ゲートウェイ装置３３で資源が枯渇する不具合を未然に防止できる。
【００５３】
以上の説明では、主に呼処理サーバ間で呼の転送が繰り返されるループ発生のケースを例に説明したが、本発明はこのようなループ回避目的に限定されるものではない。本発明は、ＶｏＩＰ網上の通話要求に関するリクエストの着信先情報（ＩＮＶＩＴＥリクエストのＴｏヘッダ、ＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒ）をチェックしてカウントする機能を搭載したことにより、ループ回避機能の他に、ループの有無に拘わらず同一ユーザに着信する着信数を制限することができる。したがって、呼処理サーバ間でループ形成される設定となっていない場合であっても、同一ユーザに着信する着信数を制限するという機能を発揮でき、従来技術では簡易な方法で防御が困難であった特定の着信先に対して故意に大量の呼を集中させる攻撃に対しても、上気した通りの簡易な構成で確実に防御することができる。
【図面の簡単な説明】
【００５４】
【図１】本発明の一実施の形態に係るソフトスイッチを備えたＶｏＩＰ網及び公衆電話網からなるネットワーク構成図
【図２】上記一実施の形態におけるソフトスイッチの概念図
【図３】上記一実施の形態において着ユーザカウント用メモリに書き込まれる書込み情報の概念図
【図４】ＳＩＰリクエストの構成例を示す図
【図５】上記一実施の形態のソフトスイッチにおいて呼の転送を規制する際のフロー図
【図６】上記一実施の形態のソフトスイッチにおいてカウント値を０クリアするフロー図
【図７】発信端末からリクエストを受けた際のソフトスイッチ間のシーケンス図
【図８】（ａ）発信端末からソフトスイッチＡへ送信されたＩＮＶＩＴＥの構成図、（ｂ）ソフトスイッチＡからソフトスイッチＢへ１回目の転送で送信されたＩＮＶＩＴＥの構成図
【図９】（ａ）ソフトスイッチＢからソフトスイッチＡへ１回目の転送で送信されたＩＮＶＩＴＥの構成図、（ｂ）ソフトスイッチＢからソフトスイッチＡへ２回目の転送で送信されたＩＮＶＩＴＥの構成図
【図１０】Ｈ．３２３網上のゲートキーパとＳＩＰ網上のソフトスイッチとの間にループが形成された状態を示すシーケンス図
【図１１】公衆電話網とＶｏＩＰ網とをゲートウェイ装置を介して接続したネットワーク構成図
【符号の説明】
【００５５】
１０…ＶｏＩＰ網
１１…公衆電話網
１２…ゲートウェイ装置
１３−１〜１３−ｎ…ソフトスイッチ
１４…回線交換機
１５−１〜１５−ｎ、１６−１〜１６−ｎ、１７−１〜１７−ｎ…ユーザ端末
２０…呼処理手段
２１…カウント手段
２２…着ユーザカウント用メモリ
２３…呼規制手段
２４…クリア手段
２５…加入者番号
２６…カウント値
２７…更新時間
【特許請求の範囲】
【請求項１】
ＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼処理手段と、
前記呼処理手段が受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントするカウント手段と、
前記呼処理手段が受信したリクエストに指定された着信先について前記カウント値が上限値に達している場合、当該リクエストの転送動作を規制する呼規制手段と、
を具備したことを特徴とする呼制御装置。
【請求項２】
高速アクセス可能な内部メモリに対して前記カウント値の書込み及び読出しを行うことを特徴とする請求項１記載の呼制御装置。
【請求項３】
前記各カウント値にスイープインターバルを設定し、スイープインターバル期間内に変化しなかったカウント値を０クリアすることを特徴とする請求項１又は請求項２記載の呼制御装置。
【請求項４】
前記呼処理手段はＳＩＰ(Session Initiation Protocol)に基づいて呼処理を行い、前記カウント手段はＩＮＶＩＴＥリクエストのＴｏヘッダから着信先情報を取得することを特徴とする請求項１から請求項３の何れかに記載の呼制御装置。
【請求項５】
前記呼処理手段はＨ．３２３に基づいて呼処理を行い、前記カウント手段はＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒから着信先情報を取得することを特徴とする請求項１から請求項３の何れかに記載の呼制御装置。
【請求項６】
ＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼制御方法において、
受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントする工程と、
受信したリクエストに指定された着信先について前記カウント値が上限値に達しているか否か判定する工程と、
前記判定の結果、前記カウント値が上限値に達していた場合に当該リクエストの転送動作を規制する工程と、
を具備したことを特徴とする呼制御方法。
【請求項１】
ＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼処理手段と、
前記呼処理手段が受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントするカウント手段と、
前記呼処理手段が受信したリクエストに指定された着信先について前記カウント値が上限値に達している場合、当該リクエストの転送動作を規制する呼規制手段と、
を具備したことを特徴とする呼制御装置。
【請求項２】
高速アクセス可能な内部メモリに対して前記カウント値の書込み及び読出しを行うことを特徴とする請求項１記載の呼制御装置。
【請求項３】
前記各カウント値にスイープインターバルを設定し、スイープインターバル期間内に変化しなかったカウント値を０クリアすることを特徴とする請求項１又は請求項２記載の呼制御装置。
【請求項４】
前記呼処理手段はＳＩＰ(Session Initiation Protocol)に基づいて呼処理を行い、前記カウント手段はＩＮＶＩＴＥリクエストのＴｏヘッダから着信先情報を取得することを特徴とする請求項１から請求項３の何れかに記載の呼制御装置。
【請求項５】
前記呼処理手段はＨ．３２３に基づいて呼処理を行い、前記カウント手段はＳｅｔｕｐリクエストのＣａｌｌｅｄ Ｐａｒｔｙ Ｎｕｍｂｅｒから着信先情報を取得することを特徴とする請求項１から請求項３の何れかに記載の呼制御装置。
【請求項６】
ＶｏＩＰ網上で発信側と着信側との間に呼を接続するための処理を行う呼制御方法において、
受信した通話要求に関するリクエストから当該リクエストの着信先情報を取り出して着信先毎にカウントする工程と、
受信したリクエストに指定された着信先について前記カウント値が上限値に達しているか否か判定する工程と、
前記判定の結果、前記カウント値が上限値に達していた場合に当該リクエストの転送動作を規制する工程と、
を具備したことを特徴とする呼制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−３１１７２２（Ｐ２００８−３１１７２２Ａ）
【公開日】平成２０年１２月２５日（２００８．１２．２５）
【国際特許分類】
【出願番号】特願２００７−１５５０８９（Ｐ２００７−１５５０８９）
【出願日】平成１９年６月１２日（２００７．６．１２）
【出願人】（３０３０６７４７８）株式会社 ネクストジェン (12)
【Ｆターム（参考）】
【公開日】平成２０年１２月２５日（２００８．１２．２５）
【国際特許分類】
【出願日】平成１９年６月１２日（２００７．６．１２）
【出願人】（３０３０６７４７８）株式会社 ネクストジェン (12)
【Ｆターム（参考）】
[ Back to top ]