JP7148803B2

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

Info

Publication number: JP7148803B2
Application number: JP2019019491A
Authority: JP
Inventors: 由彦銭谷
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2019-02-06
Filing date: 2019-02-06
Publication date: 2022-10-06
Anticipated expiration: 2039-02-06
Also published as: US20220109703A1; JP2020127163A; US11503083B2; WO2020162192A1

Description

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

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

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

特開2014-87031号公報

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

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

上記目的を達成するため、本発明の一態様は、呼処理サーバであって、電話番号と、当該電話番号の接続先網を取得するまでに少なくとも１つのサーバに問い合わせた問合せ順番と、が記憶される宛先解決記憶部と、発呼要求で指定された着信先の電話番号に対応する問合せ順番を、前記宛先解決記憶部から取得し、取得した前記問合せ順番の最後に設定されたサーバに問い合わせて前記着信先の電話番号の接続先網を取得し、当該接続先網に前記発呼要求を送信する呼処理部と、を有する。

本発明の一態様は、呼処理サーバが行う呼処理方法であって、前記呼処理サーバは、電話番号と、当該電話番号の接続先網を取得するまでに少なくとも１つのサーバに問い合わせた問合せ順番と、が記憶される宛先解決記憶部を備え、発呼要求で指定された着信先の電話番号に対応する問合せ順番を、前記宛先解決記憶部から取得する取得ステップと、取得した前記問合せ順番の最後に設定されたサーバに問い合わせて前記着信先の電話番号の接続先網を取得し、当該接続先網に前記発呼要求を送信する呼処理ステップと、を行う。

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

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

本発明の実施形態に係る呼処理システムの全体構成を示す図である。宛先解決記憶部の一例を示す図である。呼処理を示すフローチャートである。呼処理を具体的に説明する図である。

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

図１は、本発明の実施形態に係る呼処理システムの全体を示すシステム構成図である。図示する呼処理システムは、呼処理サーバ１と、複数の問合せ先サーバ２～４と、ゲートウェイ（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サーバから取得する。また、ENUMサーバ４は、自通信事業者の050で始まるIP電話の電話番号帯のポータビリティ情報を保持してもよい。

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

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

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

本実施形態では、問合せ先サーバ２～４への問合せ履歴（宛先解決履歴）を用いて、問合せ回数を低減する。

次に、呼処理サーバ１について説明する。図１に示す呼処理サーバ１は、呼処理部１１と、更新部１２と、宛先解決記憶部１３とを備える。

呼処理部１１は、SIP端末６から送信された発呼要求で指定された着信先の電話番号に対応する問合せ順番を、宛先解決記憶部１３から取得し、問合せ順番の最後に設定された問合せ先サーバ２～４に問い合わせて着信先の電話番号の接続先網を取得し、当該接続先網に発呼要求を送信する。更新部１２は、呼処理部１１が接続先網を取得するまで問い合わせた問合せ先サーバ２～４の順番を、宛先解決記憶部１３の着信先の電話番号に対応する問合せ先順番に記憶する。

宛先解決記憶部１３には、電話番号と、当該電話番号の接続先網を取得するまでに少なくとも１つの問合せ先サーバ２～４に問い合わせた問合せ順番とが記憶される。すなわち、宛先解決記憶部１３には、電話番号毎に、宛先解決までに呼処理部１１が実際に接続した問合せ先サーバ２～４の識別情報（名前、ID等）と順番とが履歴として記憶される。

図２は、宛先解決記憶部１３の一例を示す図である。図示する宛先解決記憶部１３は、電話番号と、問合せ先サーバ２～４への問合せ順番とが対応付けて記憶されている。例えば、着信先の電話番号が0120-xxxx-x111の場合、呼処理部１１は、当該電話番号の接続先網を取得するために前回の呼処理において、１番目にASサーバ３に問い合わせ、ASサーバ３から当該電話番号の接続先網を取得できなかったため、２番目にENUMサーバ４に問い合わせ、ENUMサーバ４から当該電話番号の接続先網を取得したことを示している。この場合、呼処理部１１はENUMサーバ４から接続先網を取得したため、１番目のASサーバ３への問い合わせは空振りであったことを示している。

また、着信先の電話番号が050-xxxx-zz33の場合、呼処理部１１は、当該電話番号の接続先網を取得するために前回の呼処理において、１番目にHSSサーバ２に問い合わせ、HSSサーバ２から当該電話番号の接続先網を取得したことを示している。この場合、呼処理部１１は、空振りすることなく、効率的にHSSサーバ２に問い合わせたことを示している。

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

呼処理サーバ１の呼処理部１１は、SIP端末６から発呼要求を受け付け（ステップS11）、発呼要求で指定された着信先電話番号を特定する（ステップS12）。

そして、呼処理部１１は、特定した着信先電話番号を検索キーとして宛先解決記憶部１３を検索し、着信先電話番号に対応する問合せ順番を取得する（ステップS13）。

そして、呼処理部１１は、取得した問合せ順番の最後に設定された問合せ先サーバに、着信先電話番号に対応する接続先網を問い合わせ、接続先網を取得する（ステップS14）。例えば、問合せ順番の最後に設定された問合せ先サーバ２～４がENUMサーバ４の場合、呼処理部１１は、ENUMサーバ４に着信先電話番号を含む問合せ要求を送信する。ENUMサーバ４は、当該着信先電話番号の接続先網の識別情報を保持している場合、接続先網の識別情報を呼処理サーバ１に送信する。接続先網の識別情報は、例えば、通信経路、NRN：Network Routing Numberなどである。

宛先解決記憶部１３には、各着信先電話番号に対応する前回（直前）の発呼要求で使用された問合せ順番が設定されている。例えば、呼処理サーバ１は、前回の発呼要求で、最初にHSSサーバ２に着信先電話番号の接続先網を問い合わせ、HSSサーバ２から接続先網を取得できない場合、次に、ENUMサーバ４に接続先網を問い合わせ、ENUMサーバ４から接続先網を取得するとする。

この場合、宛先解決記憶部１３には、当該着信先電話番号の問合せ順番は、「１番目：HSSサーバ、２番目：ENUMサーバ」となる。問合せ順番の最後に設定されたENUMサーバ４が当該着信先電話番号にとって宛先解決できる正しい問合せ先サーバである。一方、問合せ順番の最後に設定されたENUMサーバ４以外のサーバ、すなわち、１番目に設定されたHSSサーバ２は、当該着信先電話番号にとって宛先解決できない誤った問合せ先サーバである。したがって、当該着信先電話番号にとって、HSSサーバ２への問合せは、空振りであり、無駄な問合せである。

本実施形態では、問合せ順番の最後に設定された問合せ先サーバに、着信先電話番号の接続先網を問い合わせることで、不要な問合せ先サーバへの問い合せ（空振り）を削減する。

なお、ステップS13で、宛先解決記憶部１３に発呼要求の着信先電話番号が存在しない場合、すなわち、当該着信先電話番号への最初の呼処理の場合、呼処理部１１は、着信先電話番号の番号体系に応じた所定の順番で、問合せ先サーバに接続先網を問い合わせる。

例えば、着信先電話番号の番号体系が0AB～Jの場合、呼処理部１１は、最初にHSSサーバ２に着信先電話番号を含む問合せ要求を送信する。HSSサーバ２は、当該着信先電話番号の接続先網の識別情報を保持している場合は、接続先網の識別情報を呼処理サーバ１に送信し、保持していない場合、保持していない旨を呼処理サーバ１に応答する。HSSサーバ２が接続先網の識別情報を保持していない場合、呼処理部１１は、所定の順番に従って、次にENUMサーバ４に着信先電話番号を含む問合せ要求を送信する。この場合、ENUMサーバ４は、基本的には、当該着信先電話番号の接続先網の識別情報を保持しているため、当該接続先網の識別情報（通信経路、NRNなど）を呼処理サーバ１に応答する。

また、ステップS14で、宛先解決記憶部１３から取得した問合せ順番の最後に設定された問合せ先サーバから接続先網を取得できない場合、呼処理部１１は、着信先電話番号の番号体系に応じた他の問合せ先サーバに接続先網を問い合わせる。

そして、呼処理部１１は、取得した識別情報の接続先網に発呼要求を送信する呼処理を行う（ステップS15）。また、更新部１２は、宛先解決記憶部１３の当該着信先電話番号の問合せ順番を更新する（ステップS16）。具体的には、更新部１２は、ステップS14で呼処理部１１が接続先網を取得するまでに実際に問い合わせた問合せ順番（問合せ先サーバの識別情報、順番）を、宛先解決記憶部１３に書き込む。なお、更新前の問合せ順番と、更新後の問合せ順番が同じ場合、更新部１２は宛先解決記憶部１３を更新しない。

図４は、図３で説明した呼処理を具体的に説明する図である。図示する例では、呼処理サーバ１は、SIP端末６から発呼要求を受信し、発呼要求の着信先電話番号（0120-xxx-x111）を特定する（ステップS11、12）。呼処理サーバ１は、「0120-xxx-x111」を検索キーとして宛先解決記憶部１３を検索し、問合せ順番（１番目：ASサーバ、２番目：ENUMサーバ）を取得する（ステップS13）。呼処理サーバ１は、問合せ順番の最後に設定されたENUMサーバ４に問い合わせて、着信先電話番号の接続網の識別情報を取得し（ステップS14）、取得した識別情報の接続先網に発呼要求を送信する。呼処理サーバ１は、ステップS14で問い合わせたENUMサーバ４を宛先解決記憶部１３の問合せ順番に書き込み、宛先解決記憶部を更新する（ステップS16）。これにより、宛先解決記憶部１３の「0120-xxx-x111」に対応する問合せ順番は、「１番目：ASサーバ、２番目：ENUMサーバ」から、「１番目：ENUMサーバ」に更新される。

以上説明した本実施形態の呼処理サーバ１は、電話番号と、当該電話番号の接続先網を取得するまでに少なくとも１つのサーバに問い合わせた問合せ順番と、が記憶される宛先解決記憶部と、発呼要求で指定された着信先の電話番号に対応する問合せ順番を、前記宛先解決記憶部から取得し、取得した前記問合せ順番の最後に設定されたサーバに問い合わせて前記着信先の電話番号の接続先網を取得し、当該接続先網に前記発呼要求を送信する呼処理部と、を有する。

これにより本実施形態では、問合せ先サーバが複数ある場合に、接続先網を決定するまでの問合せ回数を低減し、呼処理における負荷を削減することができる。具体的には、IP相互接続時などにおいて、電話番号だけでは問合せ先サーバが一意に定まらない場合に、過去の問合せ先サーバへの問合せ履歴が記憶された宛先解決記憶部１３を用いることで、問合せ先サーバを一意に特定し、呼処理サーバのリソースを有効に活用することができる。

すなわち、問合せ先サーバへの問い合わせ順序が番号体系毎に固定の場合、空振りを０にすることはできず、問合せ回数を削減することは難しい。このため、本実施形態では、過去の問合せ先サーバへの問合せ履歴を用いることで、着信先の電話番号毎に、最初１回の呼処理では空振りが発生する可能性があるが、それ以降の呼処理では、問合せ先サーバは一意に特定され、空振りの発生を抑制することができる。最初の１回は、宛先解決記憶部１３に記憶されていない電話番号に対する最初の発呼要求、または、番号持ち運び制度により電話番号を変えることなく契約先の通信事業者を変更した後の最初の発呼要求などである。これにより、本実施形態では、接続先網を決定するまでの問合せ回数を低減し、呼処理サーバのリソースを有効に活用することができる。

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

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

１：呼処理サーバ
１１：呼処理部
１２：更新部
１３：宛先解決記憶部
２：HSSサーバ
３：ASサーバ
４：ENUMサーバ
５：ゲートウェイ
６：SIP端末

Claims

呼処理サーバであって、
電話番号と、当該電話番号の接続先網を取得するまでに少なくとも１つのサーバに問い合わせた問合せ順番と、が記憶される宛先解決記憶部と、
発呼要求で指定された着信先の電話番号に対応する問合せ順番を、前記宛先解決記憶部から取得し、取得した前記問合せ順番の最後に設定されたサーバに問い合わせて前記着信先の電話番号の接続先網を取得し、当該接続先網に前記発呼要求を送信する呼処理部と、を有すること
を特徴とする呼処理サーバ。
請求項１記載の呼処理サーバであって、
前記呼処理部が前記接続先網を取得するまで問い合わせたサーバの順番を、前記宛先解決記憶部の前記着信先の電話番号に対応する問合せ先順番に記憶する更新部を有すること
を特徴とする呼処理サーバ。
呼処理サーバが行う呼処理方法であって、
前記呼処理サーバは、
電話番号と、当該電話番号の接続先網を取得するまでに少なくとも１つのサーバに問い合わせた問合せ順番と、が記憶される宛先解決記憶部を備え、
発呼要求で指定された着信先の電話番号に対応する問合せ順番を、前記宛先解決記憶部から取得する取得ステップと、
取得した前記問合せ順番の最後に設定されたサーバに問い合わせて前記着信先の電話番号の接続先網を取得し、当該接続先網に前記発呼要求を送信する呼処理ステップと、を行うこと
を特徴とする呼処理方法。
請求項３記載の呼処理方法であって、
前記呼処理ステップで前記接続先網を取得するまで問い合わせたサーバの順番を、前記宛先解決記憶部の前記着信先の電話番号に対応する問合せ先順番に記憶する更新ステップを行うこと
を特徴とする呼処理方法。
請求項１または２に記載の呼処理サーバとして、コンピュータを機能させること、を特徴とする呼処理プログラム。