JP2019149613A - 呼処理サーバ、呼処理方法、および呼処理プログラム - Google Patents

Abstract

【課題】問合せ先のサーバが複数ある場合に、接続先網を決定するまでの問合せ回数を低減し、呼処理における負荷を削減する。【解決手段】呼処理サーバ１であって、複数のサーバ２〜４への問合せ順序を示す順序パターンが複数設定されたパターン記憶部１６と、過去のトラフィック情報から予測されるトラフィック予測に基づいて、前記パターン記憶部からいずれかの順序パターンを選択する選択部１３と、端末６から発呼要求を受信すると、前記選択された順序パターンの順番で前記サーバ２〜４に問合せて、前記発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する呼処理部１４と、を有する。【選択図】図１

Description

本発明は、発信および着信などの呼処理を行う呼処理サーバ、呼処理方法、および呼処理プログラムに関する。

インターネットに代表されるIPベースの通信サービスの普及に伴い、IP網上で電話サービスを提供する形態への移行が行われている。電話サービスにおいて、異なる通信事業者（通信キャリア）のユーザ同士が通話するためには、異なる通信事業者網を相互に接続する必要がある。異なる通信事業者間での相互接続において、PSTN経由の接続からIP網での相互接続（IP相互接続）への移行が進められている。

また、通信トラフィックの予測について、様々な研究がなされている（特許文献１）。

特開2014-87031号公報

従来、呼処理サーバは、加入者からの発呼を受け付けると、宛先電話番号に応じた接続先網を決定するために自身の通信事業者が管理するHSSサーバなどの自社サーバへの問い合わせを行っている。今後、他の通信事業者とのIP相互接続が行われる際には、他の通信事業者網の番号解決を行うENUMサーバへの問い合わせも必要となる。問合せ先のサーバが複数ある場合、接続先網を決定するまでの問合せ回数が増え、呼処理サーバの負荷が増大する。

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、問合せ先のサーバが複数ある場合に、接続先網を決定するまでの問合せ回数を低減し、呼処理における負荷を削減することにある。

上記目的を達成するため、本発明は、呼処理サーバであって、複数のサーバへの問合せ順序を示す順序パターンが複数設定されたパターン記憶部と、過去のトラフィック情報から予測されるトラフィック予測に基づいて、前記パターン記憶部からいずれかの順序パターンを選択する選択部と、端末から発呼要求を受信すると、前記選択された順序パターンの順番で前記サーバに問合せて、前記発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する呼処理部と、を有する。

本発明は、呼処理サーバが行う呼処理方法であって、前記呼処理サーバは、複数のサーバへの問合せ順序を示す順序パターンが複数設定されたパターン記憶部を備え、過去のトラフィック情報から予測されるトラフィック予測に基づいて、前記パターン記憶部からいずれかの順序パターンを選択する選択ステップと、端末から発呼要求を受信すると、前記選択された順序パターンの順番で前記サーバに問合せて、前記発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する呼処理ステップと、を行う。

本発明は、上記呼処理サーバとして、コンピュータを機能させることを特徴とする呼処理プログラムである。

本発明によれば、問合せ先のサーバが複数ある場合に、接続先網を決定するまでの問合せ回数を低減し、呼処理における負荷を削減することができる。

本発明の実施形態に係る呼処理システムの全体構成を示す図である。 呼処理サーバの機能を示す機能ブロック図である。 パターン記憶部の順序パターンテーブルの一例を示す図である。 順序パターン選択処理を示すフローチャートである。 トラフィックDBのトラフィック統計データの一例を示す図である。 呼処理を示すフローチャートである。

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

図１は、本発明の実施形態に係る呼処理システムの全体を示すシステム構成図である。図示する呼処理システムは、呼処理サーバ１と、複数の問合せ先サーバ２〜４と、ゲートウェイ（GW）５と、SIP端末６とを備える。

呼処理サーバ１は、発信および着信などの呼処理（呼制御）を行うサーバである。本実施形態では、呼処理サーバ１は、SIP端末６から発呼要求を受信すると、問合せ先サーバ２〜４に、発呼要求で指定された着信先電話番号の接続先網を問い合わせる。呼処理サーバ１には、自身の通信事業者の網（ネットワーク）である自網が接続されるとともに、他の通信事業者の網である他網がゲートウェイ５を介して接続される。ゲートウェイ５は、プロトコルが異なる他網と接続するための装置である。

本実施形態の問合せ先サーバ２〜４には、自通信事業者の契約者情報を保持するHSS（Home Subscriber Server）サーバ２およびAS（Application Server）サーバ３と、自社管理番号の番号ポータビリティ情報を保持するENUM（E.164 NUmber Mapping）サーバ４とがある。ここで、自社管理番号の番号ポータビリティ情報とは、自通信事業者に割り当てられ管理する電話番号と、その電話番号を利用する自通信事業者の契約者がその電話番号を変えずに契約先を変更（移転）（いわゆる番号持ち運び制度）した先の他通信事業者との対応をとる情報（すなわち実質は他通信事業者の管理する電話番号となる）である。

ENUMサーバ４は、自社管理番号について問合せされた場合は、その電話番号の番号ポータビリティ先の他通信事業者情報を、呼処理サーバ１に応答する。

自社管理番号以外の電話番号、すなわち、他通信事業者の電話番号について問合せされた場合、ENUMサーバ４は、他社が管理する他社ENUMサーバ（不図示）に問い合わせる。他社ENUMサーバは、自身が保持する他社管理番号の番号ポータビリティ情報、または、他社HSSサーバまたは他社ASから取得した接続先網の識別情報などを、ENUMサーバ４に応答する。そして、ENUMサーバ４は、他社ENUMサーバから取得した他社管理番号の番号ポータビリティ情報または接続先網の識別情報を、呼処理サーバに応答する。

またENUMサーバは通信事業者が個々に所有せず、１つのENUMサーバを共有してもよく、その場合、ENUMサーバは、各社の管理番号に関する番号ポータビリティ情報を保持する。

HSSサーバ２は、自通信事業者の0AB〜Jの電話番号帯（電話番号体系）の契約者情報（電話番号、接続先網の識別情報など）を保持するサーバである。また、HSSサーバ２は、自通信事業者の050で始まるIP電話の電話番号帯の契約者情報も保持してもよい。

ASサーバ３は、自通信事業者の付加サービスの電話番号帯（例えば、0120、0800、0570等）の契約者情報（電話番号、接続先網の識別情報）を保持するサーバである。付加サービスには、フリーダイヤル（登録商標）などの着信課金サービス（0120、0800）、ナビダイヤル（登録商標）などの発信者払いサービス（0570）などがある。また、ASサーバ３は、188または189で始まる短縮ダイアルの電話番号帯の契約者情報も保持してもよい。

ENUMサーバ４は、電話番号と番号ポータビリティ情報の対応付けを行うサーバであって、他網の番号解決を行う。本実施形態のENUMサーバ４は、0AB〜Jの電話番号帯および付加サービスの電話番号帯（例えば、0120、0800、0570等）の番号ポータビリティ情報を保持する。番号ポータビリティ情報には、電話番号、移転先事業者の接続先網の識別情報などが含まれる。また、ENUMサーバ４は、携帯電話の電話番号帯（090、080、070等）のアドレス情報も保持してもよい。また、ENUMサーバ４は、問合せされた他通信事業者の電話番号に関する情報（接続先網の識別情報など）を他社ENUMサーバから取得する。

SIP端末６は、他のSIP端末（不図示）と通信する通信端末であり、着信先のSIP端末の電話番号を指定した発呼要求を、呼処理サーバ１に送信する。

従来、HSSサーバ２には自通信事業者の0AB〜J形式の電話番号の契約者情報を保持し、ASサーバ３には自通信事業者の付加サービスの契約者情報を保持するため、呼処理サーバ１は、SIP端末６からの発呼要求の着信先電話番号が0AB〜J形式の電話番号であればHSSに、付加サービスの電話番号であればASサーバ３に問い合わせれば接続先網の識別情報が取得できるため、電話番号がわかれば問合せ先サーバは一意に定まっていた。

しかしながら、図１に示す本実施形態のように、他通信事業者とのIP相互接続時には、0AB〜J形式の電話番号、付加サービスの電話番号の番号ポータビリティ情報を保持し、また、他通信事業者の電話番号に関する情報を他社ENUMサーバから取得するENUMサーバ４が存在する。この場合、呼処理サーバ１は、電話番号だけでは、自通信事業者の契約者の電話番号か、他通信事業者に番号ポータビリティした電話番号か、あるいは、他通信事業者の契約者の電話番号か分からない。例えば、呼処理サーバは、発呼要求の着信先電話番号が0AB〜J形式の場合、自通信事業者の電話番号か、他通信事業者の電話番号かを特定できず、自通信事業者の契約者情報を保持するHSSサーバ２、または、ENUMサーバ４のどちらかに問合わせ、該当の電話番号がなければ他方に問い合わせることが必要となる。

本実施形態では、トラフィックの状況に応じて、問合せ先サーバ２〜４への問合せ順番を柔軟に制御し、問合せ回数を低減する。

図２は、呼処理サーバ１の機能構成を示すブロック図である。図示する呼処理サーバ１は、トラフィック収集部１１と、トラフィック予測部１２と、パターン選択部１３と、呼処理部１４と、トラフィックDB１５と、パターン記憶部１６とを備える。

トラフィック収集部１１は、当該呼処理サーバ１が受信した通信呼のトラフィック情報を収集する。トラフィック予測部１２は、収集したトラフィック情報から将来のトラフィックを予測する。パターン選択部１３は、過去のトラフィック情報から予測されるトラフィック予測に基づいて、パターン記憶部１６からいずれかの順序パターンを選択する。

呼処理部１４は、SIP端末６から発呼要求を受信すると、パターン選択部１３により選択された順序パターンの順番で問合せ先サーバ２〜４に問合せて、前記発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する。

トラフィックDB１５には、収集したトラフィック情報を、通信種別毎に集計したトラフィック統計データが記憶される。パターン記憶部１６には、問合せ先サーバ２〜４への問合せ順序を示す順序パターンが複数設定される。

図３は、パターン記憶部１６の複数の順序パターン（順序パターンテーブル）の一例を示す図である。図示する順序パターンは、パターンＩＤと、適用番号帯（番号体系）と、各問合せ先サーバの問合せ順序（順番）が設定されている。

パターン[１]および[２]は、0AB〜Jの電話番号帯の場合に適用されるパターンである。パターン[１]では、呼処理サーバ１は、１番目にHSSサーバ２に着信先電話番号の接続先網を問合せ、HSSサーバ２が当該電話番号の情報を保持していない場合、２番目に、ENUMサーバ４に当該電話番号の接続先網を問合せる。パターン[１]は、自網向けのトラフィックの方が他網向けのトラフィックより多い場合（自通信事業者の着信先電話番号が多い場合）に、問合せ回数が少なくてすむ有効なパターンである。

パターン[２]では、呼処理サーバ１は、１番目にENUMサーバ４に問合せ、ENUMサーバ４が当該電話番号の情報を保持していない場合、２番目に、HSSサーバ２に問合せる。パターン[２]は、他網向けのトラフィックの方が自網向けのトラフィックより多い場合（他通信事業者の着信先電話番号が多い場合）に、問合せ回数が少なくてすむ有効なパターンである。

パターン[３]、[４]は、付加サービスの電話番号帯（例えば、0120、0800、0570等）の場合に適用されるパターンである。パターン[３]では、呼処理サーバ１は、１番目にENUMサーバ４に着信先電話番号の接続先網を問合せ、ENUMサーバ４が当該電話番号の情報を保持していない場合、２番目にASサーバ３に問合せる。パターン[３]は、他網向けのトラフィックの方が自網向けのトラフィックより多い場合に、問合せ回数が少なくてすむ有効なパターンである。

パターン[４]では、呼処理サーバ１は、１番目にASサーバ３に問合せ、ASサーバ３が当該電話番号の情報を保持していない場合、２番目に、ENUMサーバ４に問合せる。パターン[４]は、自網向けのトラフィックの方が他網向けのトラフィックより多い場合に、問合せ回数が少なくてすむ有効なパターンである。

パターン[５]は、050で始まるIP電話の電話番号帯の場合に適用されるパターンであって、この場合、呼処理サーバ１はHSSサーバ２のみに問合せる。パターン[６]は、090/080/070で始まる携帯電話の電話番号帯の場合に適用されるパターンであって、この場合、呼処理サーバ１はENUMサーバ４のみに問合せる。パターン[７]は、188/189で始まる短縮ダイアルの電話番号帯の場合に適用されるパターンであって、この場合、呼処理サーバ１はASサーバ３のみに問合せる。

図４は、呼処理サーバ１の順序パターン決定処理を示すフローチャートである。呼処理サーバ１のトラフィック収集部１１は、常時、当該呼処理サーバ１で処理した通信呼のトラフィック情報を収集する（S11）。以下に、収集するトラフィック情報の一例を示す。

・発信元電話番号
・発信元電話番号の所属する網（自網 or 他網）
・着信先電話番号
・着信先電話番号の所属する網（自網 or 他網）
・通信開始時刻
・通信終了時刻
・通信時間（通信開始時刻〜通信終了時刻までの時間）
そして、トラフィック収集部１１は、収集したトラフィック情報を通信種別毎に集計し、トラフィック統計データとしてトラフィックDB15に蓄積する（S12）。以下に、トラヒック統計データの一例を示す。

図５は、トラフィック統計データの一例を示す図である。図示するトラフィック統計データは、毎日、所定の単位時間帯毎（例えば１時間毎）、および通信種別毎に、通信数、通信時間、当該時間帯で使用していた順序パタ-ンが設定されている。

通信種別は、以下の３つである。

・第１の通信種別：自網発信で自網着信（発信元と着信先とが、自網の通信）
・第２の通信種別：自網発信で他網着信（発信元が自網で、着信先が他網の通信）
・第３の通信種別：他網発信で自網着信（発信元が他網で、着信先が自網の通信）
そして、トラフィック予測部１２は、トラフィックDB15に蓄積された過去のトラフィック統計データを用いて、将来のトラフィックを予測する（S13）。すなわち、過去のトラヒック情報を蓄積し、分析することで、例えば、午前は自網への発信が多いが、午後は他網への発信が多いなどの傾向が見えてきて、確度の高いトラフィック予測が可能となる。

例えば、トラフィック予測部１２は、図５に示すトラフィック統計データを用いて、過去の１日毎の通信トラヒックのモデルを生成する。そして、トラフィック予測部１２は、将来の予測しようとする時間帯の直前の複数の時間帯（例えば３時間など）のトラフィ
ック情報を取得して、トラフィックの推移をグラフ化し、グラフの複数の点を定点観測しておく。そして、トラフィック予測部１２は、過去の各日のトラヒックのモデルから、直前の複数の時間帯のトラフィックの推移と類似する部分（複数の時間帯）を検索する。そして、所定の閾値ｘ％以上、類似する部分がある場合、トラフィック予測部１２は、予測しようとする時間帯は、その類似する部分の次の時間帯と同じ動きをすると判定する。そして、トラフィック予測部１２は、過去のトラフィックのモデルの類似する部分の次の時間帯のトラフィックを、将来の予測しようとする時間帯のトラフィックであると予測する。

そして、パターン選択部１３は、トラフィック予測部１２が予測した予測トラフィックに応じた順序パターンをパターン記憶部１６から選択する（S14）。例えば、パターン選択部１３は、予測トラフィックにおいて、第１の通信種別（自網発信→自網着信）の通信数と、第２の通信種別（自網発信→他網着信）の通信数とを用いて、順序パターンを選択する。

具体的には、予測トラフィックにおいて、第１の通信種別の通信数が、第２の通信種別の通信数より多い場合は、パターン選択部１３は、0AB〜Jの電話番号帯についてはパターン１を、また、付加サービスの電話番号帯（0120/0800/0570）についてはパターン４を選択する。一方、予測されたトラフィックにおいて、第２の通信種別の通信数が、第１の通信種別の通信数より多い場合は、パターン選択部１３は、0AB〜Jの電話番号帯についてはパターン２を、また、付加サービスの電話番号帯についてはパターン３を選択する。

また、パターン選択部１３は、S13のトラフィック予測において、過去のトラフィックのモデルの類似する部分の次の時間帯で使用していた順序パターンを選択することとしてもよい。

なお、本実施形態では、パターン選択部１３は、電話番号だけでは問合せ先サーバが一意に定まらない、0AB〜Jの電話番号帯および付加サービスの電話番号帯について、順序パターンを選択する。具体的には、図３のパターン記憶部１６に示すように、0AB〜Jの電話番号帯については、パターン[１]とパターン[２]のいずれかを選択し、付加サービスの電話番号帯については、パターン[３]とパターン[４]のいずれかを選択する。パターン[５]〜[７]については、パターン選択部１３は、電話番号がわかれば問合せ先サーバは一意に定まるため、順序パターンの選択は行わない。

パターン選択部１３は、選択した順序パターンを呼処理部１４に通知する。また、パターン選択部１３は、図３に示すパターン記憶部１６において、選択したことを示す選択フラグを、選択した順序パターンに設定することとしてもよい。

図４のS13のトラフィック予測およびS14のパターン選択は、所定のタイミング（例えば、所定の時間毎、単位時間帯毎）に繰り返し行われるものとする。これにより、トラフィックの状況に応じて、サーバへの問合せ順を柔軟に制御し、問合せ回数を削減することができる。

図６は、呼処理サーバ１の呼処理を示すフローチャートである。

呼処理サーバ１の呼処理部１４は、SIP端末６から発呼要求を受け付け（S21）、発呼要求で指定された着信先電話番号の番号帯（番号体系）を特定する（S22）。そして、呼処理部１４は、特定した番号帯に対応する問合せ先サーバに、パターン選択部１３が選択した順序パターンの順番で問合せ、着信先電話番号に対応する接続先網を取得する（S23）。

本実施形態では、特定した番号体系が0AB〜Jの場合で、選択した順序パターンがパターン[１]の場合（図３参照）、呼処理部１４は、最初にHSSサーバ２に着信先電話番号を含む問合せ要求を送信する。HSSサーバ２は、当該着信先電話番号の接続先網の識別情報（契約者情報）を保持している場合は、接続先網の識別情報を呼処理サーバ１に送信する。接続先網の識別情報は、例えば、通信経路、NRN：Network Routing Numberなどである。

一方、HSSサーバ２は、当該着信先電話番号の接続先網の識別情報を保持していない場合、保持していない旨を呼処理サーバ１に応答する。これにより、呼処理部１４は、パターン[１]の問合せ順番に従って、次にENUMサーバ４に着信先電話番号を含む問合せ要求を送信する。この場合、ENUMサーバ４は、基本的には、当該着信先電話番号の接続先網の識別情報を保持しているため、当該接続先網の識別情報（通信経路、NRNなど）を呼処理サーバ１に応答する。

また、特定した番号体系が0AB〜Jの場合で、選択した順序パターンがパターン[２]の場合、呼処理部１４は、最初にENUMサーバ４に問合せ、ENUMサーバ４が指定された着信先電話番号の接続先網の識別情報を保持している場合は、ENUMサーバ４から接続先網の識別情報を取得する。ENUMサーバ４が着信先電話番号の接続先網の識別情報を保持していない場合は、呼処理部１４は、HSSサーバ２に着信先電話番号を含む問合せ要求を送信する。この場合、HSSサーバ２は、基本的には、当該着信先電話番号の接続先網の識別情報を保持しているため、当該接続先網の識別情報を呼処理サーバ１に応答する。

そして、呼処理部１４は、取得した識別情報の接続先網に発呼要求を送信する呼処理を行う（S24）。

以上説明した本実施形態の呼処理サーバ１は、過去のトラフィック情報から予測されるトラフィック予測に基づいて、パターン記憶部１６からいずれかの順序パターンを選択するパターン選択部１３と、SIP端末６から発呼要求を受信すると、トラフィックの状況に選択された順序パターンの順番で問合せ先サーバに問合せて、発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する呼処理部１４とを備える。

これにより本実施形態では、問合せ先サーバが複数ある場合に、接続先網を決定するまでの問合せ回数を低減し、呼処理における負荷を削減することができる。具体的には、IP相互接続時などにおいて、電話番号だけでは問合せ先サーバが一意に定まらない場合に、トラフィックの状況に応じて、問合せ先サーバへの問合せ順序を柔軟に制御することで、呼処理サーバのリソースを有効に活用することができる。

すなわち、問合せ先サーバへの問い合わせ順序が一律で固定である場合、トラフィックの状況によっては、接続先網を取得するまでの問合せ回数が増える可能性がある。例えば、自網から他網向けの網間トラヒックが多い時間帯では、最初にHSSサーバ２またはASサーバ（自網の契約者の電話番号解決）に問い合わせるより、ENUMサーバ４（他網の契約者のでユーザの電話番号解決）から先に問い合わせる方が、空振りが少なく効率的であるとなる。一方、自網から自網向けのトラヒックが多い時間帯は、この逆となる。このため、本実施形態では、トラフィックの状況に応じた順序パターンを選択することで、接続先網を決定するまでの問合せ回数を低減する。

また、本実施形態では、所定の時間毎に予測される前記トラフィック予測に基づいて、所定の時間毎にパターン記憶部１６からいずれかの順序パターンを選択する。これにより、本実施形態では、トラフィックの状況変化に応じて、問合せ順番を柔軟に制御し、呼処理サーバのリソースを有効に活用することができる。

なお、上記説明した呼処理サーバ１には、例えば、CPU（Central Processing Unit、プロセッサ）と、メモリと、ストレージ（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置と、入力装置と、出力装置とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた所定のプログラムを実行することにより、呼処理サーバ１の各機能が実現される。また、呼処理サーバ１用のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

また、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１ ：呼処理サーバ
１１：トラフィック収集部
１２：トラフィック予測部
１３：パターン選択部
１４：呼処理部
１５：トラフィックDB
１６：パターン記憶部
２ ：HSSサーバ
３ ：ASサーバ
４ ：ENUMサーバ
５ ：ゲートウェイ
６ ：SIP端末

Claims (8)

1. 呼処理サーバであって、
   複数のサーバへの問合せ順序を示す順序パターンが複数設定されたパターン記憶部と、
   過去のトラフィック情報から予測されるトラフィック予測に基づいて、前記パターン記憶部からいずれかの順序パターンを選択する選択部と、
   端末から発呼要求を受信すると、前記選択された順序パターンの順番で前記サーバに問合せて、前記発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する呼処理部と、を有すること
   を特徴とする呼処理サーバ。
2. 請求項１記載の呼処理サーバであって、
   前記選択部は、所定の時間毎に予測される前記トラフィック予測に基づいて、前記所定の時間毎に前記パターン記憶部からいずれかの順序パターンを選択すること
   を特徴とする呼処理サーバ。
3. 請求項１または２記載の呼処理サーバであって、
   前記パターン記憶部には、電話番号の番号帯毎に、前記順序パターンが設定されること
   を特徴とする呼処理サーバ。
4. 請求項１から３のいずれか一項に記載の呼処理サーバであって、
   通信呼のトラフィック情報を収集するトラフィック収集部と、
   前記収集したトラフィック情報から将来のトラフィックを予測する予測部と、をさらに備えること
   を特徴とする呼処理サーバ。
5. 呼処理サーバが行う呼処理方法であって、
   前記呼処理サーバは、
   複数のサーバへの問合せ順序を示す順序パターンが複数設定されたパターン記憶部を備え、
   過去のトラフィック情報から予測されるトラフィック予測に基づいて、前記パターン記憶部からいずれかの順序パターンを選択する選択ステップと、
   端末から発呼要求を受信すると、前記選択された順序パターンの順番で前記サーバに問合せて、前記発呼要求で指定された着信先電話番号に対応する接続先網を取得し、当該接続先網に発呼要求を送信する呼処理ステップと、を行うこと
   を特徴とする呼処理方法。
6. 請求項５記載の呼処理方法であって、
   前記選択ステップは、所定の時間毎に予測される前記トラフィック予測に基づいて、前記所定の時間毎に前記パターン記憶部からいずれかの順序パターンを選択すること
   を特徴とする呼処理方法。
7. 請求項５または６記載の呼処理方法であって、
   前記パターン記憶部には、電話番号の番号帯毎に、前記順序パターンが設定されること
   を特徴とする呼処理方法。
8. 請求項１から４のいずれか１項に記載の呼処理サーバとして、コンピュータを機能させること、を特徴とする呼処理プログラム。

Images