JP2014011549A - 輻輳制御システム - Google Patents
輻輳制御システム Download PDFInfo
- Publication number
- JP2014011549A JP2014011549A JP2012145465A JP2012145465A JP2014011549A JP 2014011549 A JP2014011549 A JP 2014011549A JP 2012145465 A JP2012145465 A JP 2012145465A JP 2012145465 A JP2012145465 A JP 2012145465A JP 2014011549 A JP2014011549 A JP 2014011549A
- Authority
- JP
- Japan
- Prior art keywords
- call
- congestion
- restriction
- destination
- call request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
【課題】網内発呼時に効果的な輻輳制御を行う。
【解決手段】Webサーバ1が複数の発呼先を記載した網内発呼要求をアプリケーションサーバ2に送信し、アプリケーションサーバ2が網内発呼要求に記載された2つの発呼先それぞれについて規制対象となるか否かを判定し、いずれかの発呼先が規制対象となる場合、規制対象となる発呼先を輻輳先として記載したエラー応答をWebサーバ1に送信し、Webサーバ1は、エラー応答に記載された輻輳先の輻輳を制御するための輻輳制御方法を決定して、その輻輳制御方法に基づく網内発呼要求をアプリケーションサーバ2に送信する。
【選択図】図1
【解決手段】Webサーバ1が複数の発呼先を記載した網内発呼要求をアプリケーションサーバ2に送信し、アプリケーションサーバ2が網内発呼要求に記載された2つの発呼先それぞれについて規制対象となるか否かを判定し、いずれかの発呼先が規制対象となる場合、規制対象となる発呼先を輻輳先として記載したエラー応答をWebサーバ1に送信し、Webサーバ1は、エラー応答に記載された輻輳先の輻輳を制御するための輻輳制御方法を決定して、その輻輳制御方法に基づく網内発呼要求をアプリケーションサーバ2に送信する。
【選択図】図1
Description
本発明は、輻輳を解消、防止する技術に関する。
Web技術と電話網を連携したサービスにWebを起点に網内の2者間の通話を実現する網内発呼(Third Party Call)が知られている(非特許文献1)。網内発呼を行う際には、Webサーバからアプリケーションサーバに対して網内発呼要求を行い、アプリケーションサーバが各端末に対して発呼を行い、端末間で呼を接続する。
また、従来のIP系キャリア網において電話サービスの輻輳制御を行う場合には、電話番号を用いて呼の流量を規制する制御が行われている(特許文献1)。着信先が規制されている場合、発信者を収容する呼制御サーバが、輻輳を判定し、エラー応答処理や輻輳トーキ接続などの輻輳制御を行っていた。
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
網内発呼では、Web連携によって接続されるWebサーバにおいて発呼/切断要求や、エラー時の制御方法の判断を行なっている。しかしながら、網内発呼時の輻輳制御に関しては、十分に技術確立されておらず、Webサーバ側で輻輳時の制御を行えるようにするために、アプリケーションサーバとWebサーバが連携するための仕組みが必要である。Webサーバにより発呼要求をしているブラウザなどにエラーを通知するだけでは、ユーザがブラウザ上に表示されたエラーメッセージを読んで理解せず、網内発呼を何度も要求して再呼を生み、大量の発呼要求をアプリケーションサーバが受けて、アプリケーションサーバにも輻輳が及ぶ可能性がある。
本発明は、上記に鑑みてなされたものであり、網内発呼時に効果的な輻輳制御を行うことを目的とする。
第1の本発明に係る輻輳制御システムは、網内発呼要求サーバと、当該網内発呼要求サーバから受信した網内発呼要求に記載された複数の発呼先それぞれに発呼して呼を接続するアプリケーションサーバとを備える輻輳制御システムであって、前記網内発呼要求サーバは、複数の発呼先を記載した網内発呼要求を前記アプリケーションサーバに送信する網内発呼要求送信手段と、前記アプリケーションサーバからエラー応答を受信した場合、当該エラー応答に記載された輻輳先に基いて、当該輻輳先の輻輳を制御するための網内発呼要求を前記網内発呼要求送信手段に送信させる輻輳制御手段と、を有し、前記アプリケーションサーバは、前記網内発呼要求サーバからの網内発呼要求に記載された複数の発呼先それぞれについて発呼規制対象であるか否かを判定する輻輳判定手段と、前記網内発呼要求に発呼規制対象の発呼先が含まれている場合、発呼規制対象の発呼先を輻輳先として記載した前記エラー応答を前記網内発呼要求サーバに送信するエラー応答送信手段と、を有することを特徴とする輻輳制御システム。
上記輻輳制御システムにおいて、前記アプリケーションサーバは、輻輳により発呼が規制される規制対象を示す規制値、当該規制対象に対して単位時間当たりに発呼された呼数を示す呼数カウント、当該規制対象に対して単位時間当たりに許容された呼数を示す許容呼数を記載した規制対象情報を蓄積した規制対象情報蓄積手段を有し、前記輻輳判定手段は、前記網内発呼要求に記載された複数の発呼先それぞれについて、前記規制対象情報内に該当する規制値が存在する否か照合し、該当する規制値が存在する場合、当該規制値に関連付けられた前記呼数カウントが前記許容呼数以上のときは、その発呼先は発呼規制対象であると判定することを特徴とする。
上記輻輳制御システムにおいて、前記アプリケーションサーバは、経路情報と当該経路情報の示す経路を利用する番号帯とを対応付けた経路番号帯対応情報を蓄積する経路番号帯対応情報蓄積手段と、経路情報を含む規制指示を受信した場合、前記経路番号帯対応情報を参照して前記経路情報を番号帯に変換し、前記規制対象情報に登録する登録手段と、を有することを特徴とする。
上記輻輳制御システムにおいて、前記エラー応答は、規制対象種別、規制対象、輻輳要因をさらに含むことを特徴とする。
上記輻輳制御システムにおいて、前記輻輳制御手段は、前記輻輳先以外の発呼先とトーキを流すメディアサーバを発呼先として記載した網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする。
上記輻輳制御システムにおいて、前記網内発呼要求サーバは、番号とドメインの対応関係を記載した番号ドメイン対応情報を蓄積する番号ドメイン対応情報蓄積手段を有し、前記輻輳制御手段は、前記番号ドメイン対応情報を参照し、前記輻輳先の番号が別のドメインで呼び出し可能である場合、当該輻輳先を別のドメインに変更した前記網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする。
本発明によれば、網内発呼時に効果的な輻輳制御を行うことができる。
以下、本発明の実施の形態について図面を用いて説明する。
図1は、本実施の形態における輻輳制御システムの構成を示す機能ブロック図である。同図に示す輻輳制御システムは、Webサーバ1とアプリケーションサーバ2で構成される。Webサーバ1は、ユーザに電話番号などが記載されたWebページを提示して2者間通話の要求を受け付け、アプリケーションサーバ2に対して網内発呼要求を送信する。アプリケーションサーバ2は、ネットワークを介して、メディアサーバ4、呼制御サーバ5A〜5Cと接続し、メディアサーバ4や呼制御サーバ5A〜5Cに収容された端末に対して発呼を行う。また、オペレーションシステム3は、ネットワークや呼制御サーバ5A〜5Cの輻輳を検知し、規制要求をアプリケーションサーバ2に送信する。以下、Webサーバ1とアプリケーションサーバ2について説明する。
Webサーバ1は、網内発呼要求部11、輻輳制御部12、および番号−ドメイン対応情報蓄積部13を備える。
網内発呼要求部11は、ユーザから受け付けた2者間通話の要求に応じた網内発呼要求をアプリケーションサーバ2に対して送信する。また、送信した網内発呼要求に対してエラー応答が返信された場合に、輻輳制御部12の指示による輻輳を制御するための網内発呼要求をアプリケーションサーバ2に対して送信する。なお、網内発呼要求は、例えば、Parlay X等でmakeCallSessionなどの呼制御APIを用いて送信される。
輻輳制御部12は、アプリケーションサーバ2からエラー応答を受信した際に、エラー応答を分析して輻輳制御方法を決定し、網内発呼要求部11に指示を出す。
番号−ドメイン対応情報蓄積部13は、端末に付与された番号と対応するドメインの情報を記載した番号−ドメイン対応表を蓄積する。例えば、異なる地域に存在するコールセンタなどに共通の番号を付与し、地域毎に呼び出し先のドメインが異なる場合は、1つの番号に複数のドメインを対応付けて番号−ドメイン対応表に記載する。
一方、アプリケーションサーバ2は、輻輳判定部21、エラー応答送信部22、網内発呼部23、登録部24、規制対象リスト蓄積部25、およびTGN−番号帯対応リスト蓄積部26を備える。
輻輳判定部21は、Webサーバ1から受信した網内発呼要求に記載された2つの発呼先それぞれについて、規制対象となるか否か判定する。
エラー応答送信部22は、輻輳判定部21による判定で2つの発呼先のいずれかが規制対象となる場合に、エラー応答をアプリケーションサーバ2に送信する。
網内発呼部23は、輻輳判定部21による判定で2つの発呼先のいずれも規制対象とならない場合に、2つの発呼先それぞれに対して発呼を行う。
登録部24は、オペレーションシステム3が送信した規制要求を受信して規制対象リストに登録する。規制対象としては、番号(帯)/ドメイン/TGN(Trunk Group Number:回線単位)が指定される。TGNが指定された規制要求を受信した場合は、TGNを番号帯に変換して規制対象リストに登録する。
規制対象リスト蓄積部25は、着側として発呼が規制された規制対象の番号(帯)/ドメインを記載した規制対象リストを蓄積する。
TGN−番号帯対応リスト蓄積部26は、TGNとそのTGNを利用する番号帯とを対応付けたTGN−番号帯対応リストを蓄積する。
なお、Webサーバ1やアプリケーションサーバ2が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムはWebサーバ1やアプリケーションサーバ2が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。
次に、アプリケーションサーバ2による輻輳判定について説明する。
アプリケーションサーバ2の輻輳判定部21は、Webサーバ1から網内発呼要求を受信すると、受信した網内発呼要求に記載された2つの発呼先それぞれについて、規制対象リスト蓄積部25に蓄積された規制対象リストを参照し、発呼先が規制値に含まれているか否か、発呼先が規制対象となるか否かを判定する。
図2は、規制対象リスト蓄積部25に蓄積される規制対象リストの例を示す図である。同図に示す規制対象リストは、登録コード、規制値、呼数カウント、および許容呼数を含む。登録コードは、登録された規制対象を識別する識別子である。規制値は、例えば、番号、番号帯、ドメインなど、規制対象として登録されている値を示す。呼数カウントは、単位時間中に、規制値に該当する端末に対して発呼された呼の数を示す。呼数カウントは、単位時間経過するたびに0にリセットされる。許容呼数は、単位時間当たりに許容される発呼を示す。呼数カウントが許容呼数以上の場合は、規制値に含まれる端末への発呼が規制される。
図3は、輻輳判定部21の処理の流れを示すフローチャートである。
輻輳判定部21がWebサーバ1から網内発呼要求を受信すると、網内発呼要求に記載された発側の発呼先Xを取得し、規制対象リストを参照して、発呼先Xが規制対象リストの規制値に含まれているか否か判定する(ステップS11)。例えば、発呼先Xが「0311112222@xxxx」の場合、図2に示す規制対象リストでは、発呼先Xの番号が登録コードAの規制値「0311112222」に該当する。なお、網内発呼で先に呼び出す端末を発側、2番目に呼び出す端末を着側とする。
発呼先Xが規制値に含まれている場合(ステップS11のYES)、呼数カウントと許容呼数を比較する(ステップS12)。
呼数カウントが許容呼数以上の場合は(ステップS12のYES)、エラー応答をWebサーバ1に送信する(ステップS16)。例えば、発呼先Xが「0311112222@xxxx」で登録コードAの規制対象に該当するとき、登録コードAの呼数カウントNaと許容呼数aを比較し、呼数カウントNa≧許容呼数aの場合は、発呼先Xに対する発呼は呼数密度規制されて、エラー応答が送信される。
発呼先Xが規制値に含まれていない場合(ステップS11のNO)、および呼数カウントが許容呼数未満の場合は(ステップS12のNO)、網内発呼要求に記載された着側の発呼先Yを取得し、規制対象リストを参照して、発呼先Yが規制対象リストの規制値に含まれているか否か判定する(ステップS13)。なお、ステップS12のNOからステップS13に遷移する場合は、発呼先Xが規制値に含まれる規制対象の呼数カウント(上記の例ではNa)を1つ増加する。
発呼先Yが規制値に含まれている場合(ステップS13のYES)、呼数カウントと許容呼数を比較する(ステップS14)。例えば、発呼先Yが「044444666@yyyy」の場合、図2に示す規制対象リストでは、発呼先Yのドメインが登録コードCの規制値「@yyyy」に該当するので、登録コードCの呼数カウントNcと許容呼数cを比較する。
呼数カウントが許容呼数以上の場合は(ステップS14のYES)、エラー応答をWebサーバ1に送信する(ステップS16)。このとき、発呼先Xが規制値に含まれる規制対象があれば、ステップS12のNOからステップS13に遷移するときに、規制対象の呼数カウントを1つ増加しているので、その規制対象の呼数カウントを1つ減らす。
発呼先Yが規制値に含まれていない場合(ステップS13のNO)、および呼数カウントが許容呼数未満の場合は(ステップS14のNO)、発呼先X,Yに網内発呼を行う(ステップS15)。なお、ステップS14のNOからステップS15に遷移する場合は、発呼先Yが規制値に含まれる規制対象の呼数カウントを1つ増加する。
以上の処理により、網内発呼要求の発呼先の輻輳状態が判定され、発呼先が輻輳している場合は、エラー応答が送信される。
図4は、アプリケーションサーバ2が送信するエラー応答の例を示す図である。同図に示すエラー応答は、規制対象種別、規制対象、輻輳先、および輻輳要因を含む。規制対象種別は、番号(帯)/TGN/ドメインの内、規制されている種別を示す。規制対象は、規制対象として登録されている値を示す。輻輳先は、輻輳と判定された網内発呼要求に含まれる発呼先の内のどの発呼先を対象としているかを示す。輻輳要因は、輻輳の原因を示し、ユニット輻輳/特定加入者輻輳/エリア輻輳などに分類される。なお、Parlay X仕様におけるmakeCallSessionのエラー応答には、エラーコード“SVC:0001”としてサービスエラーが定義されている。
次に、Webサーバ1による輻輳制御について説明する。
Webサーバ1の輻輳制御部12は、アプリケーションサーバ2からエラー応答を受信すると、輻輳先、輻輳要因に応じた輻輳制御指示をアプリケーションサーバ2に出す。本実施の形態では、輻輳制御の方法として、トーキを流す方法と輻輳先を回避する方法を用いる。
まず、トーキを流す方法について説明する。
図5は、発呼先が輻輳状態のときにトーキを流して輻輳制御を行う処理の流れを示すシーケンス図である。
まず最初に、ユーザからの指示に応じて、Webサーバ1が網内発呼要求をアプリケーションサーバ2に送信する(ステップS21)。図5に示す例では、発側をA番号、着側をC番号とした網内発呼要求を送信した。
アプリケーションサーバ2は、網内発呼要求を受信すると、発側、着側それぞれの発呼先の輻輳判定を行う(ステップS22)。
輻輳判定の結果、いずれかの発呼先が輻輳し、規制対象となる場合は、エラー応答をWebサーバ1に送信する(ステップS23)。図5に示す例では、着側のC番号が規制対象となった。
Webサーバ1は、エラー応答を受信すると、エラー応答の輻輳先を参照して輻輳先が発側であるか着側であるかを確認し、エラー応答の輻輳要因を参照して輻輳要因を分析し、輻輳制御方法を決定する(ステップS24)。図5に示す例では、輻輳先が着側のC番号であり、輻輳要因が特定加入者であるので、輻輳制御方法として、発側のA番号に対して、輻輳要因に応じたトーキを流すことを決定する。
そして、Webサーバ1は、ステップS24で決定した輻輳制御方法を実行させるための網内発呼要求をアプリケーションサーバ2に送信する(ステップS25)。具体的には、図5に示す例では、発呼先にメディアサーバ4とA番号を指定した網内発呼要求をアプリケーションサーバ2に送信している。
アプリケーションサーバ2は、網内発呼要求を受信すると、メディアサーバ4、A番号を収容する呼制御サーバそれぞれを呼び出して、A番号の端末とメディアサーバ4を接続する(ステップS26,27)。A番号の端末とメディアサーバ4が接続されると、発側のA番号の端末に着側のC番号が輻輳している旨のトーキが流れる。
Webサーバ1が画面通知によって輻輳を通知するだけでは再呼を呼び、大量の発呼要求がアプリケーションサーバ2に通知される恐れがあるが、輻輳していない側の端末にメディアサーバ4に接続してトーキを流すことによって、ユーザに対して発呼先が輻輳していることを確実に知らせることができ、再呼の量の緩和が期待できる。また、網内発呼要求者と呼び出し先が別の人物の場合に、輻輳状態を呼び出し先に通知することができる。例えば、網内発呼要求者が電話会議主催者であり、呼び出し先が参加者の場合、参加者に主催者側が輻輳していることを通知できる。
続いて、輻輳先を回避する方法について説明する。
図6は、発呼先が輻輳状態のときに輻輳先を回避して輻輳制御を行う処理の流れを示すシーケンス図である。
まず最初に、ユーザからの指示に応じて、Webサーバ1が網内発呼要求をアプリケーションサーバ2に送信する(ステップS31)。図6に示す例では、発側をA番号、着側をC番号@yyyyとした網内発呼要求を送信した。
アプリケーションサーバ2は、網内発呼要求を受信すると、発側、着側それぞれの発呼先の輻輳判定を行い(ステップS32)、発呼先が規制対象に該当する場合は、エラー応答をWebサーバ1に送信する(ステップS33)。図6に示す例では、規制対象種別はドメインで、着側のC番号@yyyyが規制対象となっている。
Webサーバ1は、エラー応答を受信すると、エラー応答の輻輳先を参照して輻輳先が発側であるか着側であるかを確認し、輻輳先が別ドメインで呼び出し可能か否かを番号−ドメイン対応表を参照して輻輳制御方法を決定する(ステップS34)。番号−ドメイン対応表は番号−ドメイン対応情報蓄積部13に蓄積されている。図7に、番号−ドメイン対応表の例を示す。図7に示す例では、C番号は@yyyyと@zzzzの2つのドメインで呼び出し可能であり、回避先としてC番号@zzzzが利用できるので、輻輳制御方法として、着側をC番号@zzzzに変更して輻輳制御することを決定する。
そして、Webサーバ1は、ステップS34で決定した輻輳制御方法を実行させるための網内発呼要求をアプリケーションサーバ2に送信する(ステップS35)。具体的には、図6に示す例では、発側にA番号、着側にC番号@zzzzを指定した網内発呼要求をアプリケーションサーバ2に送信している。
アプリケーションサーバ2は、網内発呼要求を受信すると、A番号、C番号@zzzzを収容する呼制御サーバそれぞれを呼び出して、A番号とC番号@zzzzを接続する(ステップS36,37)。
Webサーバ1において番号と対応するドメインを管理し、輻輳状態に応じて、接続するドメイン先を柔軟に選択できるようにすることで、網内発呼のサービスを継続しつつ、輻輳の鎮静化につなげることができる。
次に、オペレーションシステムからの規制指示を規制対象リストに登録する処理について説明する。
オペレーションシステム3は、輻輳を検知すると、規制対象として番号(帯)/TGN/ドメインを指定してアプリケーションサーバ2に規制を指示する。アプリケーションサーバ2の輻輳判定部21は、網内発呼要求に記載された発呼先を規制対象リストに照合して輻輳判定を行うため、規制対象としてTGNが指定された場合は、TGNを対応する番号帯に変換して規制対象リストに登録する。
登録部24は、オペレーションシステム3から規制指示を受信すると、規制対象に番号、ドメインが指定されていた場合は、その番号、ドメインを規制対象リストに登録する。規制対象にTGNが指定されていた場合は、TGN−番号帯対応リスト蓄積部26に蓄積されたTGN−番号帯対応リストを参照し、TGNを番号帯に変換してから規制対象リストに登録する。
図8は、TGN−番号帯対応リストの例を示す図である。例えば、TGN:002が規定対象として通知された場合、登録部24は、TGN:002に対応する番号帯0444,0445を規定対象リストに登録する。
以上説明したように、本実施の形態によれば、Webサーバ1が複数の発呼先を記載した網内発呼要求をアプリケーションサーバ2に送信し、アプリケーションサーバ2が網内発呼要求に記載された2つの発呼先それぞれについて規制対象となるか否かを判定し、いずれかの発呼先が規制対象となる場合、規制対象となる発呼先を輻輳先として記載したエラー応答をWebサーバ1に送信し、Webサーバ1は、エラー応答に記載された輻輳先の輻輳を制御するための輻輳制御方法を決定して、その輻輳制御方法に基づく網内発呼要求をアプリケーションサーバ2に送信することにより、Webサーバ1にエラーメッセージを表示させる場合と比べて再呼を緩和でき、輻輳の鎮静化が期待できる。
輻輳制御方法としては、発呼規制されていない発呼先とメディアサーバ4を接続する網内発呼要求をアプリケーションサーバ2に送信してトーキを流す方法、あるいは、番号とドメインの対応関係を記載した番号−ドメイン対応表を参照して輻輳先の回避先となるドメインを呼び出す方法がある。これらの輻輳制御方法により、網内発呼時に効果的な輻輳制御が可能になることによって、ユーザは網内発呼できない要因を知ることができたり、輻輳を回避して網内発呼サービスの提供を受けることができるようになるため、網内発呼サービスを利用するユーザの利便性の向上を図ることもできる。
1…Webサーバ
11…網内発呼要求部
12…輻輳制御部
13…番号−ドメイン対応情報蓄積部
2…アプリケーションサーバ
21…輻輳判定部
22…エラー応答送信部
23…網内発呼部
24…登録部
25…規制対象リスト蓄積部
26…TGN−番号帯対応リスト蓄積部
3…オペレーションシステム
4…メディアサーバ
5A〜5C…呼制御サーバ
11…網内発呼要求部
12…輻輳制御部
13…番号−ドメイン対応情報蓄積部
2…アプリケーションサーバ
21…輻輳判定部
22…エラー応答送信部
23…網内発呼部
24…登録部
25…規制対象リスト蓄積部
26…TGN−番号帯対応リスト蓄積部
3…オペレーションシステム
4…メディアサーバ
5A〜5C…呼制御サーバ
Claims (6)
- 網内発呼要求サーバと、当該網内発呼要求サーバから受信した網内発呼要求に記載された複数の発呼先それぞれに発呼して呼を接続するアプリケーションサーバとを備える輻輳制御システムであって、
前記網内発呼要求サーバは、
複数の発呼先を記載した網内発呼要求を前記アプリケーションサーバに送信する網内発呼要求送信手段と、
前記アプリケーションサーバからエラー応答を受信した場合、当該エラー応答に記載された輻輳先に基いて、当該輻輳先の輻輳を制御するための網内発呼要求を前記網内発呼要求送信手段に送信させる輻輳制御手段と、を有し、
前記アプリケーションサーバは、
前記網内発呼要求サーバからの網内発呼要求に記載された複数の発呼先それぞれについて発呼規制対象であるか否かを判定する輻輳判定手段と、
前記網内発呼要求に発呼規制対象の発呼先が含まれている場合、発呼規制対象の発呼先を輻輳先として記載した前記エラー応答を前記網内発呼要求サーバに送信するエラー応答送信手段と、を有すること
を特徴とする輻輳制御システム。 - 前記アプリケーションサーバは、
輻輳により発呼が規制される規制対象を示す規制値、当該規制対象に対して単位時間当たりに発呼された呼数を示す呼数カウント、当該規制対象に対して単位時間当たりに許容された呼数を示す許容呼数を記載した規制対象情報を蓄積した規制対象情報蓄積手段を有し、
前記輻輳判定手段は、前記網内発呼要求に記載された複数の発呼先それぞれについて、前記規制対象情報内に該当する規制値が存在する否か照合し、該当する規制値が存在する場合、当該規制値に関連付けられた前記呼数カウントが前記許容呼数以上のときは、その発呼先は発呼規制対象であると判定することを特徴とする請求項1記載の輻輳制御システム。 - 前記アプリケーションサーバは、
経路情報と当該経路情報の示す経路を利用する番号帯とを対応付けた経路番号帯対応情報を蓄積する経路番号帯対応情報蓄積手段と、
経路情報を含む規制指示を受信した場合、前記経路番号帯対応情報を参照して前記経路情報を番号帯に変換し、前記規制対象情報に登録する登録手段と、を有すること
を特徴とする請求項1又は2記載の輻輳制御システム。 - 前記エラー応答は、規制対象種別、規制対象、輻輳要因をさらに含むことを特徴とする請求項1乃至3のいずれかに記載の輻輳制御システム。
- 前記輻輳制御手段は、前記輻輳先以外の発呼先とトーキを流すメディアサーバを発呼先として記載した網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする請求項1乃至4のいずれかに記載の輻輳制御システム。
- 前記網内発呼要求サーバは、
番号とドメインの対応関係を記載した番号ドメイン対応情報を蓄積する番号ドメイン対応情報蓄積手段を有し、
前記輻輳制御手段は、前記番号ドメイン対応情報を参照し、前記輻輳先の番号が別のドメインで呼び出し可能である場合、当該輻輳先を別のドメインに変更した前記網内発呼要求を前記網内発呼要求送信手段に送信させることを特徴とする請求項1乃至5のいずれかに記載の輻輳制御システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012145465A JP2014011549A (ja) | 2012-06-28 | 2012-06-28 | 輻輳制御システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012145465A JP2014011549A (ja) | 2012-06-28 | 2012-06-28 | 輻輳制御システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014011549A true JP2014011549A (ja) | 2014-01-20 |
Family
ID=50107887
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012145465A Pending JP2014011549A (ja) | 2012-06-28 | 2012-06-28 | 輻輳制御システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2014011549A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2014154903A (ja) * | 2013-02-05 | 2014-08-25 | Nippon Telegr & Teleph Corp <Ntt> | 輻輳制御方法および発呼サーバ |
US20180198080A1 (en) * | 2017-01-11 | 2018-07-12 | Samsung Electronics Co., Ltd. | Organometallic compound, composition containing the organometallic compound, and organic light-emitting device |
-
2012
- 2012-06-28 JP JP2012145465A patent/JP2014011549A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2014154903A (ja) * | 2013-02-05 | 2014-08-25 | Nippon Telegr & Teleph Corp <Ntt> | 輻輳制御方法および発呼サーバ |
US20180198080A1 (en) * | 2017-01-11 | 2018-07-12 | Samsung Electronics Co., Ltd. | Organometallic compound, composition containing the organometallic compound, and organic light-emitting device |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2859816C (en) | Ip-based conferencing in a telecommunications network | |
US8744060B2 (en) | Communicating information pertaining to cancelling of forked call requests | |
US10721318B2 (en) | Methods and apparatus for generating, aggregating and/or distributing presence information | |
CN105027528B (zh) | 会话建立的过载控制 | |
GB2584922A (en) | System, device, and method for routing communications in an emergency service network | |
US11582267B2 (en) | Method of and communications handling equipment for controlling communication session establishment in a multimedia communications network | |
US20130219070A1 (en) | Resolving device specific identifiers to a user identifier to initiate a dialog establishment with devices of a user | |
JP2007201900A (ja) | セッション制御方法、通信システム、通信制御装置、及び、接続指示装置 | |
WO2011143821A1 (zh) | 将呼叫请求分流至被叫用户地址的方法以及装置 | |
US20100056120A1 (en) | Method and server for filtering telephone calls | |
US9979795B1 (en) | Managing presence state | |
JP2014011549A (ja) | 輻輳制御システム | |
KR101212651B1 (ko) | 복수의 수신 단말에 대한 멀티링 서비스 제공 시스템 및 방법 | |
US9407770B2 (en) | Managing calls in IMS networks | |
US8472603B2 (en) | Remote monitoring of phone calls | |
US8102991B2 (en) | Method and system for automatic call distribution | |
JP2012504367A (ja) | 事業体のためのimsネットワークにおける着呼応答サービス | |
JP5393248B2 (ja) | 発側呼処理装置及び発信制御方法 | |
EP3055984B1 (en) | Configurable call recording policy | |
JP2007311872A (ja) | コール制御サーバおよびその方法 | |
US11653334B2 (en) | Systems and methods for reducing transcoding resource allocation during call setup to multiple terminations | |
WO2012053884A1 (en) | Location independent approach to session transfer for real-time voip session | |
JP5784522B2 (ja) | 呼制御サーバ、呼制御サーバの規制方法 | |
US10574832B1 (en) | Call redirect from mobile device in IPBX | |
JP2006295760A (ja) | VoIPサービスシステム、呼制御サーバ、および呼制御方法 |