JP2014011549A

JP2014011549A - 輻輳制御システム

Info

Publication number: JP2014011549A
Application number: JP2012145465A
Authority: JP
Inventors: Kosuke Fujita; 宏介藤田; Yoshiharu Koshiro; 義晴小代
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-06-28
Filing date: 2012-06-28
Publication date: 2014-01-20

Abstract

【課題】網内発呼時に効果的な輻輳制御を行う。
【解決手段】Ｗｅｂサーバ１が複数の発呼先を記載した網内発呼要求をアプリケーションサーバ２に送信し、アプリケーションサーバ２が網内発呼要求に記載された２つの発呼先それぞれについて規制対象となるか否かを判定し、いずれかの発呼先が規制対象となる場合、規制対象となる発呼先を輻輳先として記載したエラー応答をＷｅｂサーバ１に送信し、Ｗｅｂサーバ１は、エラー応答に記載された輻輳先の輻輳を制御するための輻輳制御方法を決定して、その輻輳制御方法に基づく網内発呼要求をアプリケーションサーバ２に送信する。
【選択図】図１

Description

本発明は、輻輳を解消、防止する技術に関する。

Ｗｅｂ技術と電話網を連携したサービスにＷｅｂを起点に網内の２者間の通話を実現する網内発呼（ＴｈｉｒｄＰａｒｔｙＣａｌｌ）が知られている（非特許文献１）。網内発呼を行う際には、Ｗｅｂサーバからアプリケーションサーバに対して網内発呼要求を行い、アプリケーションサーバが各端末に対して発呼を行い、端末間で呼を接続する。

また、従来のＩＰ系キャリア網において電話サービスの輻輳制御を行う場合には、電話番号を用いて呼の流量を規制する制御が行われている（特許文献１）。着信先が規制されている場合、発信者を収容する呼制御サーバが、輻輳を判定し、エラー応答処理や輻輳トーキ接続などの輻輳制御を行っていた。

特開２０１１−１７１９１８号公報

J. Rosenberg, J. Peterson, H. Schulzrine, and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC3725, April 2004

網内発呼では、Ｗｅｂ連携によって接続されるＷｅｂサーバにおいて発呼／切断要求や、エラー時の制御方法の判断を行なっている。しかしながら、網内発呼時の輻輳制御に関しては、十分に技術確立されておらず、Ｗｅｂサーバ側で輻輳時の制御を行えるようにするために、アプリケーションサーバとＷｅｂサーバが連携するための仕組みが必要である。Ｗｅｂサーバにより発呼要求をしているブラウザなどにエラーを通知するだけでは、ユーザがブラウザ上に表示されたエラーメッセージを読んで理解せず、網内発呼を何度も要求して再呼を生み、大量の発呼要求をアプリケーションサーバが受けて、アプリケーションサーバにも輻輳が及ぶ可能性がある。

本発明は、上記に鑑みてなされたものであり、網内発呼時に効果的な輻輳制御を行うことを目的とする。

第１の本発明に係る輻輳制御システムは、網内発呼要求サーバと、当該網内発呼要求サーバから受信した網内発呼要求に記載された複数の発呼先それぞれに発呼して呼を接続するアプリケーションサーバとを備える輻輳制御システムであって、前記網内発呼要求サーバは、複数の発呼先を記載した網内発呼要求を前記アプリケーションサーバに送信する網内発呼要求送信手段と、前記アプリケーションサーバからエラー応答を受信した場合、当該エラー応答に記載された輻輳先に基いて、当該輻輳先の輻輳を制御するための網内発呼要求を前記網内発呼要求送信手段に送信させる輻輳制御手段と、を有し、前記アプリケーションサーバは、前記網内発呼要求サーバからの網内発呼要求に記載された複数の発呼先それぞれについて発呼規制対象であるか否かを判定する輻輳判定手段と、前記網内発呼要求に発呼規制対象の発呼先が含まれている場合、発呼規制対象の発呼先を輻輳先として記載した前記エラー応答を前記網内発呼要求サーバに送信するエラー応答送信手段と、を有することを特徴とする輻輳制御システム。

上記輻輳制御システムにおいて、前記アプリケーションサーバは、輻輳により発呼が規制される規制対象を示す規制値、当該規制対象に対して単位時間当たりに発呼された呼数を示す呼数カウント、当該規制対象に対して単位時間当たりに許容された呼数を示す許容呼数を記載した規制対象情報を蓄積した規制対象情報蓄積手段を有し、前記輻輳判定手段は、前記網内発呼要求に記載された複数の発呼先それぞれについて、前記規制対象情報内に該当する規制値が存在する否か照合し、該当する規制値が存在する場合、当該規制値に関連付けられた前記呼数カウントが前記許容呼数以上のときは、その発呼先は発呼規制対象であると判定することを特徴とする。

上記輻輳制御システムにおいて、前記アプリケーションサーバは、経路情報と当該経路情報の示す経路を利用する番号帯とを対応付けた経路番号帯対応情報を蓄積する経路番号帯対応情報蓄積手段と、経路情報を含む規制指示を受信した場合、前記経路番号帯対応情報を参照して前記経路情報を番号帯に変換し、前記規制対象情報に登録する登録手段と、を有することを特徴とする。

上記輻輳制御システムにおいて、前記エラー応答は、規制対象種別、規制対象、輻輳要因をさらに含むことを特徴とする。

上記輻輳制御システムにおいて、前記輻輳制御手段は、前記輻輳先以外の発呼先とトーキを流すメディアサーバを発呼先として記載した網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする。

上記輻輳制御システムにおいて、前記網内発呼要求サーバは、番号とドメインの対応関係を記載した番号ドメイン対応情報を蓄積する番号ドメイン対応情報蓄積手段を有し、前記輻輳制御手段は、前記番号ドメイン対応情報を参照し、前記輻輳先の番号が別のドメインで呼び出し可能である場合、当該輻輳先を別のドメインに変更した前記網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする。

本発明によれば、網内発呼時に効果的な輻輳制御を行うことができる。

本実施の形態における輻輳制御システムの構成を示す機能ブロック図である。規制対象リストの例を示す図である。規制判定処理の流れを示すフローチャートである。エラー応答の例を示す図である。発呼先が輻輳状態のときにトーキを流して輻輳制御を行う処理の流れを示すシーケンス図である。発呼先が輻輳状態のときに輻輳先を回避して輻輳制御を行う処理の流れを示すシーケンス図である。番号−ドメイン対応表の例を示す図である。ＴＧＮ−番号帯対応リストの例を示す図である。

以下、本発明の実施の形態について図面を用いて説明する。

図１は、本実施の形態における輻輳制御システムの構成を示す機能ブロック図である。同図に示す輻輳制御システムは、Ｗｅｂサーバ１とアプリケーションサーバ２で構成される。Ｗｅｂサーバ１は、ユーザに電話番号などが記載されたＷｅｂページを提示して２者間通話の要求を受け付け、アプリケーションサーバ２に対して網内発呼要求を送信する。アプリケーションサーバ２は、ネットワークを介して、メディアサーバ４、呼制御サーバ５Ａ〜５Ｃと接続し、メディアサーバ４や呼制御サーバ５Ａ〜５Ｃに収容された端末に対して発呼を行う。また、オペレーションシステム３は、ネットワークや呼制御サーバ５Ａ〜５Ｃの輻輳を検知し、規制要求をアプリケーションサーバ２に送信する。以下、Ｗｅｂサーバ１とアプリケーションサーバ２について説明する。

Ｗｅｂサーバ１は、網内発呼要求部１１、輻輳制御部１２、および番号−ドメイン対応情報蓄積部１３を備える。

網内発呼要求部１１は、ユーザから受け付けた２者間通話の要求に応じた網内発呼要求をアプリケーションサーバ２に対して送信する。また、送信した網内発呼要求に対してエラー応答が返信された場合に、輻輳制御部１２の指示による輻輳を制御するための網内発呼要求をアプリケーションサーバ２に対して送信する。なお、網内発呼要求は、例えば、ＰａｒｌａｙＸ等でｍａｋｅＣａｌｌＳｅｓｓｉｏｎなどの呼制御ＡＰＩを用いて送信される。

輻輳制御部１２は、アプリケーションサーバ２からエラー応答を受信した際に、エラー応答を分析して輻輳制御方法を決定し、網内発呼要求部１１に指示を出す。

番号−ドメイン対応情報蓄積部１３は、端末に付与された番号と対応するドメインの情報を記載した番号−ドメイン対応表を蓄積する。例えば、異なる地域に存在するコールセンタなどに共通の番号を付与し、地域毎に呼び出し先のドメインが異なる場合は、１つの番号に複数のドメインを対応付けて番号−ドメイン対応表に記載する。

一方、アプリケーションサーバ２は、輻輳判定部２１、エラー応答送信部２２、網内発呼部２３、登録部２４、規制対象リスト蓄積部２５、およびＴＧＮ−番号帯対応リスト蓄積部２６を備える。

輻輳判定部２１は、Ｗｅｂサーバ１から受信した網内発呼要求に記載された２つの発呼先それぞれについて、規制対象となるか否か判定する。

エラー応答送信部２２は、輻輳判定部２１による判定で２つの発呼先のいずれかが規制対象となる場合に、エラー応答をアプリケーションサーバ２に送信する。

網内発呼部２３は、輻輳判定部２１による判定で２つの発呼先のいずれも規制対象とならない場合に、２つの発呼先それぞれに対して発呼を行う。

登録部２４は、オペレーションシステム３が送信した規制要求を受信して規制対象リストに登録する。規制対象としては、番号（帯）／ドメイン／ＴＧＮ（ＴｒｕｎｋＧｒｏｕｐＮｕｍｂｅｒ：回線単位）が指定される。ＴＧＮが指定された規制要求を受信した場合は、ＴＧＮを番号帯に変換して規制対象リストに登録する。

規制対象リスト蓄積部２５は、着側として発呼が規制された規制対象の番号（帯）／ドメインを記載した規制対象リストを蓄積する。

ＴＧＮ−番号帯対応リスト蓄積部２６は、ＴＧＮとそのＴＧＮを利用する番号帯とを対応付けたＴＧＮ−番号帯対応リストを蓄積する。

なお、Ｗｅｂサーバ１やアプリケーションサーバ２が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムはＷｅｂサーバ１やアプリケーションサーバ２が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。

次に、アプリケーションサーバ２による輻輳判定について説明する。

アプリケーションサーバ２の輻輳判定部２１は、Ｗｅｂサーバ１から網内発呼要求を受信すると、受信した網内発呼要求に記載された２つの発呼先それぞれについて、規制対象リスト蓄積部２５に蓄積された規制対象リストを参照し、発呼先が規制値に含まれているか否か、発呼先が規制対象となるか否かを判定する。

図２は、規制対象リスト蓄積部２５に蓄積される規制対象リストの例を示す図である。同図に示す規制対象リストは、登録コード、規制値、呼数カウント、および許容呼数を含む。登録コードは、登録された規制対象を識別する識別子である。規制値は、例えば、番号、番号帯、ドメインなど、規制対象として登録されている値を示す。呼数カウントは、単位時間中に、規制値に該当する端末に対して発呼された呼の数を示す。呼数カウントは、単位時間経過するたびに０にリセットされる。許容呼数は、単位時間当たりに許容される発呼を示す。呼数カウントが許容呼数以上の場合は、規制値に含まれる端末への発呼が規制される。

図３は、輻輳判定部２１の処理の流れを示すフローチャートである。

輻輳判定部２１がＷｅｂサーバ１から網内発呼要求を受信すると、網内発呼要求に記載された発側の発呼先Ｘを取得し、規制対象リストを参照して、発呼先Ｘが規制対象リストの規制値に含まれているか否か判定する（ステップＳ１１）。例えば、発呼先Ｘが「０３１１１１２２２２＠ｘｘｘｘ」の場合、図２に示す規制対象リストでは、発呼先Ｘの番号が登録コードＡの規制値「０３１１１１２２２２」に該当する。なお、網内発呼で先に呼び出す端末を発側、２番目に呼び出す端末を着側とする。

発呼先Ｘが規制値に含まれている場合（ステップＳ１１のＹＥＳ）、呼数カウントと許容呼数を比較する（ステップＳ１２）。

呼数カウントが許容呼数以上の場合は（ステップＳ１２のＹＥＳ）、エラー応答をＷｅｂサーバ１に送信する（ステップＳ１６）。例えば、発呼先Ｘが「０３１１１１２２２２＠ｘｘｘｘ」で登録コードＡの規制対象に該当するとき、登録コードＡの呼数カウントＮ_aと許容呼数ａを比較し、呼数カウントＮ_a≧許容呼数ａの場合は、発呼先Ｘに対する発呼は呼数密度規制されて、エラー応答が送信される。

発呼先Ｘが規制値に含まれていない場合（ステップＳ１１のＮＯ）、および呼数カウントが許容呼数未満の場合は（ステップＳ１２のＮＯ）、網内発呼要求に記載された着側の発呼先Ｙを取得し、規制対象リストを参照して、発呼先Ｙが規制対象リストの規制値に含まれているか否か判定する（ステップＳ１３）。なお、ステップＳ１２のＮＯからステップＳ１３に遷移する場合は、発呼先Ｘが規制値に含まれる規制対象の呼数カウント（上記の例ではＮ_a）を１つ増加する。

発呼先Ｙが規制値に含まれている場合（ステップＳ１３のＹＥＳ）、呼数カウントと許容呼数を比較する（ステップＳ１４）。例えば、発呼先Ｙが「０４４４４４６６６＠ｙｙｙｙ」の場合、図２に示す規制対象リストでは、発呼先Ｙのドメインが登録コードＣの規制値「＠ｙｙｙｙ」に該当するので、登録コードＣの呼数カウントＮ_cと許容呼数ｃを比較する。

呼数カウントが許容呼数以上の場合は（ステップＳ１４のＹＥＳ）、エラー応答をＷｅｂサーバ１に送信する（ステップＳ１６）。このとき、発呼先Ｘが規制値に含まれる規制対象があれば、ステップＳ１２のＮＯからステップＳ１３に遷移するときに、規制対象の呼数カウントを１つ増加しているので、その規制対象の呼数カウントを１つ減らす。

発呼先Ｙが規制値に含まれていない場合（ステップＳ１３のＮＯ）、および呼数カウントが許容呼数未満の場合は（ステップＳ１４のＮＯ）、発呼先Ｘ，Ｙに網内発呼を行う（ステップＳ１５）。なお、ステップＳ１４のＮＯからステップＳ１５に遷移する場合は、発呼先Ｙが規制値に含まれる規制対象の呼数カウントを１つ増加する。

以上の処理により、網内発呼要求の発呼先の輻輳状態が判定され、発呼先が輻輳している場合は、エラー応答が送信される。

図４は、アプリケーションサーバ２が送信するエラー応答の例を示す図である。同図に示すエラー応答は、規制対象種別、規制対象、輻輳先、および輻輳要因を含む。規制対象種別は、番号（帯）／ＴＧＮ／ドメインの内、規制されている種別を示す。規制対象は、規制対象として登録されている値を示す。輻輳先は、輻輳と判定された網内発呼要求に含まれる発呼先の内のどの発呼先を対象としているかを示す。輻輳要因は、輻輳の原因を示し、ユニット輻輳／特定加入者輻輳／エリア輻輳などに分類される。なお、ＰａｒｌａｙＸ仕様におけるｍａｋｅＣａｌｌＳｅｓｓｉｏｎのエラー応答には、エラーコード“SVC:0001”としてサービスエラーが定義されている。

次に、Ｗｅｂサーバ１による輻輳制御について説明する。

Ｗｅｂサーバ１の輻輳制御部１２は、アプリケーションサーバ２からエラー応答を受信すると、輻輳先、輻輳要因に応じた輻輳制御指示をアプリケーションサーバ２に出す。本実施の形態では、輻輳制御の方法として、トーキを流す方法と輻輳先を回避する方法を用いる。

まず、トーキを流す方法について説明する。

図５は、発呼先が輻輳状態のときにトーキを流して輻輳制御を行う処理の流れを示すシーケンス図である。

まず最初に、ユーザからの指示に応じて、Ｗｅｂサーバ１が網内発呼要求をアプリケーションサーバ２に送信する（ステップＳ２１）。図５に示す例では、発側をＡ番号、着側をＣ番号とした網内発呼要求を送信した。

アプリケーションサーバ２は、網内発呼要求を受信すると、発側、着側それぞれの発呼先の輻輳判定を行う（ステップＳ２２）。

輻輳判定の結果、いずれかの発呼先が輻輳し、規制対象となる場合は、エラー応答をＷｅｂサーバ１に送信する（ステップＳ２３）。図５に示す例では、着側のＣ番号が規制対象となった。

Ｗｅｂサーバ１は、エラー応答を受信すると、エラー応答の輻輳先を参照して輻輳先が発側であるか着側であるかを確認し、エラー応答の輻輳要因を参照して輻輳要因を分析し、輻輳制御方法を決定する（ステップＳ２４）。図５に示す例では、輻輳先が着側のＣ番号であり、輻輳要因が特定加入者であるので、輻輳制御方法として、発側のＡ番号に対して、輻輳要因に応じたトーキを流すことを決定する。

そして、Ｗｅｂサーバ１は、ステップＳ２４で決定した輻輳制御方法を実行させるための網内発呼要求をアプリケーションサーバ２に送信する（ステップＳ２５）。具体的には、図５に示す例では、発呼先にメディアサーバ４とＡ番号を指定した網内発呼要求をアプリケーションサーバ２に送信している。

アプリケーションサーバ２は、網内発呼要求を受信すると、メディアサーバ４、Ａ番号を収容する呼制御サーバそれぞれを呼び出して、Ａ番号の端末とメディアサーバ４を接続する（ステップＳ２６，２７）。Ａ番号の端末とメディアサーバ４が接続されると、発側のＡ番号の端末に着側のＣ番号が輻輳している旨のトーキが流れる。

Ｗｅｂサーバ１が画面通知によって輻輳を通知するだけでは再呼を呼び、大量の発呼要求がアプリケーションサーバ２に通知される恐れがあるが、輻輳していない側の端末にメディアサーバ４に接続してトーキを流すことによって、ユーザに対して発呼先が輻輳していることを確実に知らせることができ、再呼の量の緩和が期待できる。また、網内発呼要求者と呼び出し先が別の人物の場合に、輻輳状態を呼び出し先に通知することができる。例えば、網内発呼要求者が電話会議主催者であり、呼び出し先が参加者の場合、参加者に主催者側が輻輳していることを通知できる。

続いて、輻輳先を回避する方法について説明する。

図６は、発呼先が輻輳状態のときに輻輳先を回避して輻輳制御を行う処理の流れを示すシーケンス図である。

まず最初に、ユーザからの指示に応じて、Ｗｅｂサーバ１が網内発呼要求をアプリケーションサーバ２に送信する（ステップＳ３１）。図６に示す例では、発側をＡ番号、着側をＣ番号＠ｙｙｙｙとした網内発呼要求を送信した。

アプリケーションサーバ２は、網内発呼要求を受信すると、発側、着側それぞれの発呼先の輻輳判定を行い（ステップＳ３２）、発呼先が規制対象に該当する場合は、エラー応答をＷｅｂサーバ１に送信する（ステップＳ３３）。図６に示す例では、規制対象種別はドメインで、着側のＣ番号＠ｙｙｙｙが規制対象となっている。

Ｗｅｂサーバ１は、エラー応答を受信すると、エラー応答の輻輳先を参照して輻輳先が発側であるか着側であるかを確認し、輻輳先が別ドメインで呼び出し可能か否かを番号−ドメイン対応表を参照して輻輳制御方法を決定する（ステップＳ３４）。番号−ドメイン対応表は番号−ドメイン対応情報蓄積部１３に蓄積されている。図７に、番号−ドメイン対応表の例を示す。図７に示す例では、Ｃ番号は＠ｙｙｙｙと＠ｚｚｚｚの２つのドメインで呼び出し可能であり、回避先としてＣ番号＠ｚｚｚｚが利用できるので、輻輳制御方法として、着側をＣ番号＠ｚｚｚｚに変更して輻輳制御することを決定する。

そして、Ｗｅｂサーバ１は、ステップＳ３４で決定した輻輳制御方法を実行させるための網内発呼要求をアプリケーションサーバ２に送信する（ステップＳ３５）。具体的には、図６に示す例では、発側にＡ番号、着側にＣ番号＠ｚｚｚｚを指定した網内発呼要求をアプリケーションサーバ２に送信している。

アプリケーションサーバ２は、網内発呼要求を受信すると、Ａ番号、Ｃ番号＠ｚｚｚｚを収容する呼制御サーバそれぞれを呼び出して、Ａ番号とＣ番号＠ｚｚｚｚを接続する（ステップＳ３６，３７）。

Ｗｅｂサーバ１において番号と対応するドメインを管理し、輻輳状態に応じて、接続するドメイン先を柔軟に選択できるようにすることで、網内発呼のサービスを継続しつつ、輻輳の鎮静化につなげることができる。

次に、オペレーションシステムからの規制指示を規制対象リストに登録する処理について説明する。

オペレーションシステム３は、輻輳を検知すると、規制対象として番号（帯）／ＴＧＮ／ドメインを指定してアプリケーションサーバ２に規制を指示する。アプリケーションサーバ２の輻輳判定部２１は、網内発呼要求に記載された発呼先を規制対象リストに照合して輻輳判定を行うため、規制対象としてＴＧＮが指定された場合は、ＴＧＮを対応する番号帯に変換して規制対象リストに登録する。

登録部２４は、オペレーションシステム３から規制指示を受信すると、規制対象に番号、ドメインが指定されていた場合は、その番号、ドメインを規制対象リストに登録する。規制対象にＴＧＮが指定されていた場合は、ＴＧＮ−番号帯対応リスト蓄積部２６に蓄積されたＴＧＮ−番号帯対応リストを参照し、ＴＧＮを番号帯に変換してから規制対象リストに登録する。

図８は、ＴＧＮ−番号帯対応リストの例を示す図である。例えば、ＴＧＮ：００２が規定対象として通知された場合、登録部２４は、ＴＧＮ：００２に対応する番号帯０４４４，０４４５を規定対象リストに登録する。

以上説明したように、本実施の形態によれば、Ｗｅｂサーバ１が複数の発呼先を記載した網内発呼要求をアプリケーションサーバ２に送信し、アプリケーションサーバ２が網内発呼要求に記載された２つの発呼先それぞれについて規制対象となるか否かを判定し、いずれかの発呼先が規制対象となる場合、規制対象となる発呼先を輻輳先として記載したエラー応答をＷｅｂサーバ１に送信し、Ｗｅｂサーバ１は、エラー応答に記載された輻輳先の輻輳を制御するための輻輳制御方法を決定して、その輻輳制御方法に基づく網内発呼要求をアプリケーションサーバ２に送信することにより、Ｗｅｂサーバ１にエラーメッセージを表示させる場合と比べて再呼を緩和でき、輻輳の鎮静化が期待できる。

輻輳制御方法としては、発呼規制されていない発呼先とメディアサーバ４を接続する網内発呼要求をアプリケーションサーバ２に送信してトーキを流す方法、あるいは、番号とドメインの対応関係を記載した番号−ドメイン対応表を参照して輻輳先の回避先となるドメインを呼び出す方法がある。これらの輻輳制御方法により、網内発呼時に効果的な輻輳制御が可能になることによって、ユーザは網内発呼できない要因を知ることができたり、輻輳を回避して網内発呼サービスの提供を受けることができるようになるため、網内発呼サービスを利用するユーザの利便性の向上を図ることもできる。

１…Ｗｅｂサーバ
１１…網内発呼要求部
１２…輻輳制御部
１３…番号−ドメイン対応情報蓄積部
２…アプリケーションサーバ
２１…輻輳判定部
２２…エラー応答送信部
２３…網内発呼部
２４…登録部
２５…規制対象リスト蓄積部
２６…ＴＧＮ−番号帯対応リスト蓄積部
３…オペレーションシステム
４…メディアサーバ
５Ａ〜５Ｃ…呼制御サーバ

Claims

網内発呼要求サーバと、当該網内発呼要求サーバから受信した網内発呼要求に記載された複数の発呼先それぞれに発呼して呼を接続するアプリケーションサーバとを備える輻輳制御システムであって、
前記網内発呼要求サーバは、
複数の発呼先を記載した網内発呼要求を前記アプリケーションサーバに送信する網内発呼要求送信手段と、
前記アプリケーションサーバからエラー応答を受信した場合、当該エラー応答に記載された輻輳先に基いて、当該輻輳先の輻輳を制御するための網内発呼要求を前記網内発呼要求送信手段に送信させる輻輳制御手段と、を有し、
前記アプリケーションサーバは、
前記網内発呼要求サーバからの網内発呼要求に記載された複数の発呼先それぞれについて発呼規制対象であるか否かを判定する輻輳判定手段と、
前記網内発呼要求に発呼規制対象の発呼先が含まれている場合、発呼規制対象の発呼先を輻輳先として記載した前記エラー応答を前記網内発呼要求サーバに送信するエラー応答送信手段と、を有すること
を特徴とする輻輳制御システム。
前記アプリケーションサーバは、
輻輳により発呼が規制される規制対象を示す規制値、当該規制対象に対して単位時間当たりに発呼された呼数を示す呼数カウント、当該規制対象に対して単位時間当たりに許容された呼数を示す許容呼数を記載した規制対象情報を蓄積した規制対象情報蓄積手段を有し、
前記輻輳判定手段は、前記網内発呼要求に記載された複数の発呼先それぞれについて、前記規制対象情報内に該当する規制値が存在する否か照合し、該当する規制値が存在する場合、当該規制値に関連付けられた前記呼数カウントが前記許容呼数以上のときは、その発呼先は発呼規制対象であると判定することを特徴とする請求項１記載の輻輳制御システム。
前記アプリケーションサーバは、
経路情報と当該経路情報の示す経路を利用する番号帯とを対応付けた経路番号帯対応情報を蓄積する経路番号帯対応情報蓄積手段と、
経路情報を含む規制指示を受信した場合、前記経路番号帯対応情報を参照して前記経路情報を番号帯に変換し、前記規制対象情報に登録する登録手段と、を有すること
を特徴とする請求項１又は２記載の輻輳制御システム。
前記エラー応答は、規制対象種別、規制対象、輻輳要因をさらに含むことを特徴とする請求項１乃至３のいずれかに記載の輻輳制御システム。
前記輻輳制御手段は、前記輻輳先以外の発呼先とトーキを流すメディアサーバを発呼先として記載した網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする請求項１乃至４のいずれかに記載の輻輳制御システム。
前記網内発呼要求サーバは、
番号とドメインの対応関係を記載した番号ドメイン対応情報を蓄積する番号ドメイン対応情報蓄積手段を有し、
前記輻輳制御手段は、前記番号ドメイン対応情報を参照し、前記輻輳先の番号が別のドメインで呼び出し可能である場合、当該輻輳先を別のドメインに変更した前記網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする請求項１乃至５のいずれかに記載の輻輳制御システム。