JP2015156541A - 番号解決システムおよび番号解決方法 - Google Patents

Abstract

【課題】複数のキャリア網間での通信において、呼処理の遅延化を抑制し、番号ポータビリティを利用した電話端末に確実に着信させる。
【解決手段】ＳＩＰサーバ１ｂが、発キャリア網内のＳＩＰサーバ１ｘから、着信先の電話端末４ｄの電話番号および自身のキャリア網を示すドメイン名を含む呼制御信号を受信する（Ｓ６）。ＳＩＰサーバ１ｂは、電話端末４ｄを収容していないので、キャリアＥＮＵＭサーバ２ｂに、電話端末４ｄのＵＲＩの問い合わせをする（Ｓ８）。キャリアＥＮＵＭサーバ２ｂは、マスタＥＮＵＭサーバ３に問い合わせて取得した、電話端末４ｄのＵＲＩを、ＳＩＰサーバ１ｂに通知する（Ｓ１２）。ＳＩＰサーバ１ｂは、通知されたＵＲＩを用いて、電話端末４ｄの番号解決をし（Ｓ１３）、電話端末４ｄの着キャリア網内のＳＩＰサーバ１ｃに、電話端末４ｄの電話番号および着キャリア網を示すドメイン名を含む呼制御信号を送信する（Ｓ１４）。
【選択図】図４

Description

本発明は、E.164番号（ITU-TのE.164勧告で規定される、国番号を含む最大１５桁の国際公衆電気通信番号。例えば、「＋81-3-3333-4444」）を管理する複数のキャリアのキャリア網（通信事業者のネットワーク）の相互接続において、電話番号を変更せずにキャリアを変更する番号ポータビリティを利用する電話端末への接続を実現する技術に関する。

番号ポータビリティを利用する電話端末を収容するキャリア網に関する情報を取得するための標準的なプロトコルとして、ＤＮＳ（Domain Name System）をベースとするＥＮＵＭ（Telephone Number Mapping）がある。ＥＮＵＭは、ＤＮＳの仕組みを利用し，E.164番号をドメイン変換した形式でＥＮＵＭサーバに問い合わせ、着信先となるE.164番号の電話端末を収容するキャリア網内のＳＩＰ（Session Initiation Protocol）サーバのＩＰ（Internet Protocol）アドレスや、そのキャリア網で提供されるサービスの情報を取得するための仕組みである。ＥＮＵＭは、例えば、IETF（Internet Engineering Task Force） RFC 6116で規定される（非特許文献１参照）。

また、非特許文献２には、ＥＮＵＭによる番号解決手順について開示されている。しかし、非特許文献２の技術によれば、番号ポータビリティを利用した電話端末を複数のキャリア網間で特定する場合、キャリア網内のＳＩＰサーバ間での呼接続に加え、キャリア網内のＥＮＵＭサーバ間の通信も必要になり、呼処理の遅延化を招く。

そこで、キャリア網内のＥＮＵＭサーバのそれぞれが管理する、電話番号とＵＲＩ（Uniform Resource Identifiers）とを対応付けたレコードを同一にし、キャリア網内のＥＮＵＭサーバ間の通信を不要とする形態を採用することが考えられる。キャリア網内のＥＮＵＭサーバのそれぞれが管理するレコードの同一性が保証されていれば、ＥＮＵＭサーバによる番号解決の処理は、各々のキャリア網内で実現され、呼処理の遅延化を抑制できる。

S.Bradner その他、"The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)"IETF, RFC 6116, March 2011 "IR.67 - DNS/ENUM Guidelines for Service Providers & GRX/IPX Providers"GSM Association 4.1, 3 March 2010

しかし、通話サービスを提供する複数のキャリア網による運用を継続すれば、ＥＮＵＭサーバのそれぞれが管理するリソースレコードの同一性が保証されない場合がある。その場合、番号解決に失敗し、呼の転送先を誤り、番号ポータビリティを利用した電話端末に着信できない、という問題がある。

本発明は、このような問題点に鑑みてなされたものであり、複数のキャリア網間での通信において、呼処理の遅延化を抑制し、番号ポータビリティを利用した電話端末に確実に着信させることを目的とする。

前記の目的を達成するために、本発明の請求項１に記載の発明は、自身のＳＩＰサーバおよび自身のキャリアＥＮＵＭサーバが配置されている複数のキャリア網と、電話端末の電話番号および前記電話端末のＵＲＩを対応付けるマスタＥＮＵＭサーバとが互いに接続しており、発信元の電話端末と、番号ポータビリティを利用した着信先の電話端末との接続を実現する番号解決システムであって、複数の前記キャリア網内の前記ＳＩＰサーバのそれぞれは、自身のキャリア網が収容している電話端末の電話番号を記憶している加入者データベースと、発キャリア網内の前記ＳＩＰサーバから、着信先の前記電話端末の電話番号および自身のキャリア網を示すドメイン名を含む呼制御信号を受信し、自身の前記キャリアＥＮＵＭサーバの処理に基づいて番号解決された着信先の前記電話端末を収容している着キャリア網内の前記ＳＩＰサーバに、着信先の前記電話端末の電話番号および前記着キャリア網を示すドメイン名を含む呼制御信号を送信する、呼処理部と、前記加入者データベースを参照しても着信先の前記電話端末の電話番号が存在しない場合には、自身のキャリア網内の前記キャリアＥＮＵＭサーバに対して、着信先の前記電話端末のＵＲＩの問い合わせをすることで、着信先の前記電話端末の番号解決をする番号解決部と、を備え、複数の前記キャリア網内の前記キャリアＥＮＵＭサーバのそれぞれは、前記電話端末の電話番号および前記電話端末のＵＲＩの対応付け情報を、前記マスタＥＮＵＭサーバから取得して記憶しているマッピングデータベースと、前記番号解決部からの前記問い合わせに応じて、前記マスタＥＮＵＭサーバに問い合わせて取得した、着信先の前記電話端末のＵＲＩを前記番号解決部に通知するＵＲＩ通知部と、を備える、ことを特徴とする。

また、本発明の請求項２に記載の発明は、請求項１に記載の発明において、複数の前記キャリア網内の前記キャリアＥＮＵＭサーバのそれぞれは、前記マスタＥＮＵＭサーバからの要求に応じて、着信先の前記電話端末のＵＲＩを、着信先の前記電話端末の電話番号に対応付けるように前記対応付け情報を書き換える、ことを特徴とする。

また、本発明の請求項３に記載の発明は、自身のＳＩＰサーバおよび自身のキャリアＥＮＵＭサーバが配置されている複数のキャリア網と、電話端末の電話番号および前記電話端末のＵＲＩを対応付けるマスタＥＮＵＭサーバとが互いに接続しており、発信元の電話端末と、番号ポータビリティを利用した着信先の電話端末との接続を実現する番号解決システムにおける番号解決方法であって、自身のキャリア網内の前記ＳＩＰサーバが、発キャリア網内の前記ＳＩＰサーバから、着信先の前記電話端末の電話番号および自身のキャリア網を示すドメイン名を含む呼制御信号を受信するステップと、自身のキャリア網内の前記ＳＩＰサーバが、自身のキャリア網が収容している電話端末の電話番号を含む加入者情報を記憶している加入者データベースを参照しても着信先の前記電話端末の電話番号が存在しない場合には、自身のキャリア網内の前記キャリアＥＮＵＭサーバに対して、着信先の前記電話端末のＵＲＩの問い合わせをするステップと、自身のキャリア網内の前記キャリアＥＮＵＭサーバが、前記問い合わせに応じて、前記マスタＥＮＵＭサーバに問い合わせて取得した、着信先の前記電話端末のＵＲＩを、自身のキャリア網内の前記ＳＩＰサーバに通知するステップと、自身のキャリア網内の前記ＳＩＰサーバが、前記通知された着信先の前記電話端末のＵＲＩを用いて、着信先の前記電話端末の番号解決をするステップと、自身のキャリア網内の前記ＳＩＰサーバが、前記番号解決された着信先の前記電話端末を収容している着キャリア網内の前記ＳＩＰサーバに、着信先の前記電話端末の電話番号および前記着キャリア網を示すドメイン名を含む呼制御信号を送信するステップと、を実行する、ことを特徴とする。

請求項１、３に記載の発明によれば、呼処理の遅延化を抑制するためにキャリアＥＮＵＭサーバによる番号解決の処理を各々のキャリア網内で実現する形態をとる場合において、キャリアＥＮＵＭサーバのそれぞれが管理する対応付け情報の同一性が破綻していたとしても、前記同一性の破綻を認識したキャリア網が、前記対応付け情報の正しい内容をマスタＥＮＵＭサーバから取得する。よって、マスタＥＮＵＭサーバから取得したキャリア網は、正しい着キャリア網を特定できる。その結果、複数のキャリア網間での通信において、呼処理の遅延化を抑制し、番号ポータビリティを利用した電話端末に確実に着信させることができる。

また、請求項２に記載の発明によれば、キャリアＥＮＵＭサーバのそれぞれは、マスタＥＮＵＭサーバからの要求に応じて、着信先の電話端末のＵＲＩを、着信先の前記電話端末の電話番号に対応付けるように対応付け情報を書き換える。その結果、発信元の電話端末からの発信を受けた発キャリアは、正しい着キャリアに呼制御信号を送信することができ、今後の呼処理の遅延化を未然に防ぐことができる。

本発明によれば、複数のキャリア網間での通信において、呼処理の遅延化を抑制し、番号ポータビリティを利用した電話端末に確実に着信させることができる。

本実施形態の構成の全体を示す図である。 加入者データベースのデータ構造を示す図である。 マッピングデータベースのデータ構造を示す図である。 本実施形態の処理を示すシーケンス図である。

＜構成＞
図１に示すように、本実施形態の番号解決システムは、相互接続されている複数のキャリア網と、マスタＥＮＵＭサーバ３とを備える。キャリア網のそれぞれは、例えば、ＩＭＳ（IP Multimedia Subsystem: 3GPP TS 24.229）に従って機能している。キャリアＸ、キャリアＡ、キャリアＢ、キャリアＣのそれぞれが運用するキャリア網は、ＩＭＳ−Ｘ、ＩＭＳ−Ａ、ＩＭＳ−Ｂ、ＩＭＳ−Ｃである。
電話端末４ｓ（４）、４ｄ（４）は、例えば、ＶｏＩＰ（Voice over Internet Protocol）端末である。

ＩＭＳ−Ｘ内には、ＳＩＰサーバ１ｘ（１）およびキャリアＥＮＵＭサーバ２ｘ（２）が配置されている。ＩＭＳ−Ｘのドメイン名は、provider-X.netである。
ＩＭＳ−Ａ内には、ＳＩＰサーバ１ａ（１）およびキャリアＥＮＵＭサーバ２ａ（２）が配置されている。ＩＭＳ−Ａのドメイン名は、provider-A.netである。
ＩＭＳ−Ｂ内には、ＳＩＰサーバ１ｂ（１）およびキャリアＥＮＵＭサーバ２ｂ（２）が配置されている。ＩＭＳ−Ｂのドメイン名は、provider-B.netである。
ＩＭＳ−Ｃ内には、ＳＩＰサーバ１ｃ（１）およびキャリアＥＮＵＭサーバ２ｃ（２）が配置されている。ＩＭＳ−Ｃのドメイン名は、provider-C.netである。

ＳＩＰサーバ１は、ＳＩＰを利用したＩＰ電話サービスのための呼制御を行う。ＳＩＰサーバ１ｘ、１ａ、１ｂ、１ｃはそれぞれ、呼処理部１１ｘ（１１）、１１ａ（１１）、１１ｂ（１１）、１１ｃ（１１）と、番号解決部１２ｘ（１２）、１２ａ（１２）、１２ｂ（１２）、１２ｃ（１２）と、加入者ＤＢ（Data Base）１３ｘ（１３）、１３ａ（１３）、１３ｂ（１３）、１３ｃ（１３）とを備える。

呼処理部１１は、発信元の電話端末４と着信先の電話端末４との間の呼を処理する。呼処理部１１は、例えば、ＣＳＣＦ（call state control function）に従って動作する。

番号解決部１２は、ＤＮＳをベースとするＥＮＵＭを用いて、着信先の電話端末４の番号解決を行う。前記番号解決は、ＳＩＰサーバ１が、発信元の電話端末４または他のＳＩＰサーバ１から受信した呼制御信号の転送先を決定する（ルーティング）ことを含む。

加入者ＤＢ１３は、自身のキャリア網が収容している電話端末４の電話番号を記憶している。加入者ＤＢ１３は、例えば、ＨＳＳ（Home Subscriber Server: 3GPP 29.229など）として実装することができる。

図２に示すように、加入者ＤＢ１３は、「ユーザＩＤ（Identifier）」と「電話番号」という項目を備える。
「ユーザＩＤ」の項目には、自身のキャリア網が収容している電話端末４を用いるユーザを識別する値（例えば、文字および数字の組み合わせ）が格納されている。
「電話番号」の項目には、自身のキャリア網が収容している電話端末４の電話番号が格納されている。前記格納される電話番号の形式は、通常の形式（例：9012-34-5678）であってもよいし、E.164番号の形式（例：＋81-9012-34-5678）であってもよい。

キャリアＥＮＵＭサーバ２は、電話端末４の電話番号および電話端末４のＵＲＩを対応付けて管理する。管理対象となる電話端末４は、ＩＰ電話サービスを利用するすべての電話端末４であり、自身のキャリア網が収容している電話端末４に限られない。
キャリアＥＮＵＭサーバ２ｘ、２ａ、２ｂ、２ｃはそれぞれ、ＵＲＩ通知部２１ｘ（２１）、２１ａ（２１）、２１ｂ（２１）、２１ｃ（２１）と、マッピングＤＢ２２ｘ（２２）、２２ａ（２２）、２２ｂ（２２）、２２ｃ（２２）とを備える。

ＵＲＩ通知部２１は、同じキャリア網内の番号解決部１２からの要求に対する応答として、着信先の電話端末４のＵＲＩを番号解決部１２に通知する。ＵＲＩ通知部２１は、必要に応じて、着信先の電話端末４のＵＲＩをマスタＥＮＵＭサーバ３から取得する。

マッピングＤＢ２２は、電話端末４の電話番号および電話端末４のＵＲＩの対応付け情報（リソースレコード）を記憶している。

図３に示すように、マッピングＤＢ２２は、「着信先電話番号」と「ＵＲＩ」という項目を備える。
「着信先電話番号」の項目には、着信先となる電話端末４の電話番号が格納されている。前記格納される電話番号の形式は、通常の形式であってもよいし、E.164番号の形式であってもよい。
「ＵＲＩ」の項目には、着信先となる電話端末４のＵＲＩが格納されている。格納されているＵＲＩは、着信先となる電話端末４を収容しているキャリア網のドメイン名を含む。

マスタＥＮＵＭサーバ３は、電話端末４の電話番号および電話端末４のＵＲＩを対応付けて管理する。管理対象となる電話端末４は、ＩＰ電話サービスを利用するすべての電話端末４であり、自身のキャリア網が収容している電話端末４に限られない。マスタＥＮＵＭサーバ３は、キャリアＥＮＵＭサーバ２のそれぞれが備えるマッピングＤＢ２２と同等のマッピングＤＢを備える。

マスタＥＮＵＭサーバ３は、ＤＮＳによるゾーン転送を行い、対応付け情報としてＮＡＰＴＲレコードをキャリアＥＮＵＭサーバ２のそれぞれに送信し、キャリアＥＮＵＭサーバ２のそれぞれと同期とる。キャリアＥＮＵＭサーバ２のそれぞれは、マスタＥＮＵＭサーバ３からの要求に応じて、キャリアＥＮＵＭサーバ２のそれぞれのマッピングＤＢ２２をマスタＥＮＵＭサーバ３のマッピングＤＢと同一にする。このような処理形態は、１つのキャリア網内での番号解決部１２による番号解決を、異なるキャリア網内のキャリアＥＮＵＭサーバ２間の通信をすることなく可能とし、呼処理の遅延化を抑制する。前記ゾーン転送は、例えば、定期的に行われる。

これまでに説明した、ＳＩＰサーバ１、キャリアＥＮＵＭサーバ２、マスタＥＮＵＭサーバ３、電話端末４はそれぞれ、入力部、出力部、制御部および記憶部といったハードウェアを含むコンピュータである。例えば、制御部がＣＰＵ（Central Processing Unit）から構成される場合、その制御部を含むコンピュータによる情報処理は、ＣＰＵによるプログラム実行処理で実現する。また、そのコンピュータが含む記憶部は、ＣＰＵが指令し、そのコンピュータの機能を実現するためのプログラムを記憶する。これによりソフトウェアとハードウェアの協働が実現される。前記プログラムは、記録媒体に記録したり、ネットワークを経由したりすることで提供される。

＜処理＞
本実施形態の処理について、図１に示す構成に則して説明する。この処理の主体は、ＳＩＰサーバ１、キャリアＥＮＵＭサーバ２、マスタＥＮＵＭサーバ３、電話端末４の制御部であるが、説明の便宜上、「制御部」という言葉は省略する。

（前提）
電話端末４ｄのユーザＸはキャリアＡと契約し、電話端末４ｄはＩＭＳ−Ａに収容されていた。暫くして、ユーザＸは番号ポータビリティを利用して、電話番号は変更せず、キャリアＢとの契約に切り替え、電話端末４ｄはＩＭＳ−Ｂに収容された。さらに、その後、ユーザＸは番号ポータビリティを利用して、電話番号は変更せず、キャリアＣとの契約に切り替え、電話端末４ｄはＩＭＳ−Ｃに収容されて、現在に至る。

マスタＥＮＵＭサーバ３のオペレータは、電話端末４ｄがＩＭＳ−Ａに収容された後、電話端末４ｄに関する対応付け情報を作成し、マスタＥＮＵＭサーバ３に登録した。作成した対応付け情報において、電話端末４ｄを収容している着キャリア網を示すドメイン名として、ＩＭＳ−Ａのドメイン名「provider-A.net」が含まれていた。

マスタＥＮＵＭサーバ３のオペレータは、電話端末４ｄがＩＭＳ−Ｂに収容された後、電話端末４ｄに関する対応付け情報を更新した。更新した対応付け情報において、着キャリア網を示すドメイン名は、ＩＭＳ−Ａのドメイン名「provider-A.net」からＩＭＳ−Ｂのドメイン名「provider-B.net」に変更された。

マスタＥＮＵＭサーバ３のオペレータは、電話端末４ｄがＩＭＳ−Ｃに収容された後、電話端末４ｄに関する対応付け情報を更新した。更新した対応付け情報において、着キャリア網を示すドメイン名は、ＩＭＳ−Ｂのドメイン名「provider-B.net」からＩＭＳ−Ｃのドメイン名「provider-C.net」に変更された。

マスタＥＮＵＭサーバ３は、電話端末４ｄがＩＭＳ−Ｂに収容された後、ゾーン転送によってキャリアＥＮＵＭサーバ２ｘ、２ａ、２ｂ、２ｃのそれぞれと同期をとり、キャリアＥＮＵＭサーバ２ｘ、２ａ、２ｂ、２ｃのそれぞれに対してマッピングＤＢ２２ｘ、２２ａ、２２ｂ、２２ｃのそれぞれの更新要求をした。
前記更新要求はすべて成功したため、マッピングＤＢ２２ｘ、２２ａ、２２ｂ、２２ｃのそれぞれが記憶している、電話端末４ｄに関する対応付け情報が更新され、前記対応付け情報のＵＲＩに含まれている着キャリア網のドメイン名は、ＩＭＳ−Ａのドメイン名「provider-A.net」からＩＭＳ−Ｂのドメイン名「provider-B.net」に変更された。

マスタＥＮＵＭサーバ３は、電話端末４ｄがＩＭＳ−Ｃに収容された後、ゾーン転送によってキャリアＥＮＵＭサーバ２ｘ、２ａ、２ｂ、２ｃのそれぞれと同期をとり、キャリアＥＮＵＭサーバ２ｘ、２ａ、２ｂ、２ｃのそれぞれに対してマッピングＤＢ２２ｘ、２２ａ、２２ｂ、２２ｃのそれぞれの更新要求をした。
キャリアＥＮＵＭサーバ２ａ、２ｂ、２ｃに対する更新要求は成功したため、マッピングＤＢ２２ａ、２２ｂ、２２ｃのそれぞれが記憶している、電話端末４ｄに関する対応付け情報が更新され、前記対応付け情報のＵＲＩに含まれている着キャリア網のドメイン名は、ＩＭＳ−Ｂのドメイン名「provider-B.net」からＩＭＳ−Ｃのドメイン名「provider-C.net」に変更された。
しかし、キャリアＥＮＵＭサーバ２ｘに対する更新要求は、トランスポートエラーなどの障害のために失敗した。その結果、マッピングＤＢ２２ｘが記憶している、電話端末４ｄに関する対応付け情報は更新されず、前記対応付け情報のＵＲＩに含まれている着キャリア網のドメイン名は、ＩＭＳ−Ｂのドメイン名「provider-B.net」のままである。つまり、キャリアＥＮＵＭサーバ２ｘ、２ａ、２ｂ、２ｃが管理する対応付け情報の同一性が損なわれている。

以上の前提を踏まえ、図４の処理は、発信者がユーザＸに電話するために、ＩＭＳ−Ｘ（発信元である電話端末４ｓを収容している発キャリア網）に収容されている電話端末４ｓを操作することで開始し、ステップＳ１に進む。

ステップＳ１において、発信元である電話端末４ｓは、着信先である電話端末４ｄの電話番号（＋81-9012-34-5678）および呼接続要求の入力があると発信する。電話端末４ｓは、着信先に電話をかけることを示す「INVITE tel:+819012345678 SIP/2.0」という値を含むＳＩＰ信号（呼制御信号）をＳＩＰサーバ１ｘに送信する。ステップＳ１の後、ステップＳ２に進む。

ステップＳ２において、ＳＩＰサーバ１ｘは、呼処理部１１ｘの機能によって、加入者ＤＢ１３ｘを検索する。呼処理部１１ｘは、例えばDIAMETERプロトコルによって、着信先の電話端末４ｄの電話番号を検索キーとして含むLIR(Location-Info-Request)を加入者ＤＢ１３ｘに入力する。ＩＭＳ−Ｘは着信先の電話端末４ｄを収容していないので、呼処理部１１ｘは、着信先の電話端末４ｄが存在しないことを示すLIA（Location-Info-Answer）を取得する。ステップＳ２の後、ステップＳ３に進む。

ステップＳ３において、ＳＩＰサーバ１ｘは、番号解決部１２ｘの機能によって、着信先となる電話端末４ｄのＵＲＩをキャリアＥＮＵＭサーバ２ｘに問い合わせる。ＳＩＰサーバ１ｘは、電話端末４ｄの電話番号を逆順にした形式を持つ「8.7.6.5.4.3.2.1.0.9.1.8.e164enum.net」という値を含むＥＮＵＭクエリをキャリアＥＮＵＭサーバ２ｘに送信する。ステップＳ３の後、ステップＳ４に進む。

ステップＳ４において、キャリアＥＮＵＭサーバ２ｘは、ＵＲＩ通知部２１ｘの機能によって、マッピングＤＢ２２ｘを参照して、着信先となる電話端末４ｄのＵＲＩをＳＩＰサーバ１ｘに通知する。ここで、マッピングＤＢ２２ｘ内の、電話端末４ｄに関する対応付け情報のＵＲＩに含まれている着キャリア網のドメイン名は、ＩＭＳ−Ｂのドメイン名「provider-B.net」であり、本来のＩＭＳ−Ｃのドメイン名「provider-C.net」ではない。よって、キャリアＥＮＵＭサーバ２ｘは、ＳＩＰサーバ１ｘからのＥＮＵＭクエリに対して、電話端末４ｄの着キャリア網がＩＭＳ−Ｂであることを示す「sip:+819012345678;npdi;rn=+819012340001@provider-B.net」という値を含むＵＲＩをＥＮＵＭアンサとしてＳＩＰサーバ１ｘに送信してしまう。ステップＳ４の後、ステップＳ５に進む。

ステップＳ５において、ＳＩＰサーバ１ｘは、番号解決部１２ｘの機能によって、電話端末４ｄの番号解決をする。ＳＩＰサーバ１ｘは、キャリアＥＮＵＭサーバ２ｘからのＥＮＵＭアンサを解析して、発信元である電話端末４ｓからのＳＩＰ信号の転送先がＩＭＳ−Ｂ内のＳＩＰサーバ１ｂであると決定する。ステップＳ５の後、ステップＳ６に進む。

ステップＳ６において、ＳＩＰサーバ１ｘは、呼処理部１１ｘの機能によって、発信元である電話端末４ｓからのＳＩＰ信号を、転送先であるＳＩＰサーバ１ｂに送信する。前記ＳＩＰ信号は、転送先が、着信先である電話端末４ｄの着キャリア網（つまり、ＩＭＳ−Ｂ）であることを示す「INVITE sip:+819012345678;npdi;rn=+819012340001@provider-B.net SIP/2.0」という値を含む。ステップＳ６の後、ステップＳ７に進む。

ステップＳ７において、ＳＩＰサーバ１ｂは、呼処理部１１ｂの機能によって、加入者ＤＢ１３ｂを検索する。呼処理部１１ｂは、例えばDIAMETERプロトコルによって、着信先の電話端末４ｄの電話番号を検索キーとして含むLIRを加入者ＤＢ１３ｂに入力する。しかし、ＩＭＳ−Ｂは着信先の電話端末４ｄを収容していないので、呼処理部１１ｂは、着信先の電話端末４ｄが存在しないことを示すLIAを取得する。ステップＳ７の後、ステップＳ８に進む。

ステップＳ８において、ＳＩＰサーバ１ｂは、番号解決部１２ｂの機能によって、着信先となる電話端末４ｄのＵＲＩをキャリアＥＮＵＭサーバ２ｂに問い合わせる。ＳＩＰサーバ１ｂは、電話端末４ｄの電話番号を逆順にした形式を持つ「8.7.6.5.4.3.2.1.0.9.1.8.e164enum-term.net」という値を含むＥＮＵＭクエリをキャリアＥＮＵＭサーバ２ｂに送信する。

ここで、ＩＭＳ−Ｂが電話端末４ｄの着チャリア網であるとして、ＳＩＰサーバ１ｂがキャリアＥＮＵＭサーバ２ｂに問い合わせることを明確にするために、ＥＮＵＭクエリ内のキャリアＥＮＵＭサーバ２ｂのドメイン名を「e164enum-term.net」とし、発信時のキャリアＥＮＵＭサーバ２のドメイン名「e164enum.net」（ステップＳ３参照）とは異ならせている。
つまり、ＳＩＰサーバ１ｂは、ＩＭＳ−Ｂが電話端末４ｄをすでに収容していない（実際は、番号ポータビリティによってＩＭＳ−Ｃに変更した）にもかかわらず、ＳＩＰサーバ１ｘが、ＩＭＳ−Ｂを着キャリア網としてＳＩＰ信号をＳＩＰサーバ１ｂに送信してきたことを認識することができる。ステップＳ６のＳＩＰ信号に「provider-B.net」というドメイン名が含まれているからである。このような状況から、（１）電話端末４ｄを収容している他のキャリア網が存在しているが、マスタＥＮＵＭサーバ３とキャリアＥＮＵＭサーバ２のそれぞれとの同期がうまく機能しておらず、ＳＩＰサーバ１ｘのマッピングＤＢ２２ｘは間違った対応付け情報を記憶している可能性、または、（２）電話端末４ｄのユーザＸが通話サービスの解約をし、電話端末４ｄがいずれのキャリア網にも収容されていない可能性、などが考えられる。ＳＩＰサーバ１ｂは、このような可能性を追及するための処理を行う。
ステップＳ８の後、ステップＳ９に進む。

ステップＳ９において、キャリアＥＮＵＭサーバ２ｂは、着信先となる電話端末４ｄのＵＲＩをマスタＥＮＵＭサーバ３に問い合わせる。キャリアＥＮＵＭサーバ２ｂは、ＳＩＰサーバ１ｂからのＥＮＵＭクエリ中のドメイン名「e164enum-term.net」を読み取って、ＩＭＳ−Ｂが電話端末４ｄの着チャリア網であるとして、ＳＩＰサーバ１ｂから問い合わせを受けていると判定する。キャリアＥＮＵＭサーバ２ｂは、電話端末４ｄの対応付け情報が正しいか否かを確認するために、電話端末４ｄの電話番号を逆順にした形式を持つ「8.7.6.5.4.3.2.1.0.9.1.8.e164enum.net」という値を含むＥＮＵＭクエリをマスタＥＮＵＭサーバ３に送信する。ステップＳ９の後、ステップＳ１０に進む。

ステップＳ１０において、マスタＥＮＵＭサーバ３は、自身のマッピングＤＢを参照して、着信先となる電話端末４ｄの（正しい）ＵＲＩをキャリアＥＮＵＭサーバ２ｂに通知する。マスタＥＮＵＭサーバ３は、キャリアＥＮＵＭサーバ２ｂからのＥＮＵＭクエリに対して、電話端末４ｄの着キャリア網がＩＭＳ−Ｃであることを示す「sip:+819012345678;npdi;rn=+819012340001@provider-C.net」という値を含むＵＲＩをＥＮＵＭアンサとしてキャリアＥＮＵＭサーバ２ｂに送信する。ステップＳ１０の後、ステップＳ１１に進む。

ステップＳ１１において、マスタＥＮＵＭサーバ３は、すべてのキャリアＥＮＵＭサーバ２に対して、送信先の電話端末４ｄに関する対応付け情報のＵＲＩ中のドメイン名の更新要求を行う。マスタＥＮＵＭサーバ３は、キャリアＥＮＵＭサーバ２ｂからのＥＮＵＭクエリを受信することで、少なくとも１つのキャリアＥＮＵＭサーバ２との同期が機能せず、いずれかのマッピングＤＢ２２が記憶する、電話端末４ｄに関する対応付け情報が古いことを認識できる。よって、マスタＥＮＵＭサーバ３は、電話端末４ｄに関する対応付け情報のＵＲＩ中のドメイン名を、ＩＭＳ−Ｃのドメイン名「provider-C.net」に書き換えるようにすべてのキャリアＥＮＵＭサーバ２に要求する。
すべてのキャリアＥＮＵＭサーバ２は、マスタＥＮＵＭサーバ３からの更新要求に対して、電話端末４ｄに関する対応付け情報のＵＲＩ中のドメイン名を、ＩＭＳ−Ｃのドメイン名「provider-C.net」に書き換えるように、マッピングＤＢ２２をそれぞれ更新する。すべてのキャリアＥＮＵＭサーバ２は、更新が完了したことをマスタＥＮＵＭサーバ３に通知してもよい。前記通知の有無を判定することで、マスタＥＮＵＭサーバ３とすべてのキャリアＥＮＵＭサーバ２との間の同期の成否を知ることができる。

前記更新要求は、マスタＥＮＵＭサーバ３に問い合わせたキャリアＥＮＵＭサーバ２（２ｂ）にのみ行ってもよい。この場合、キャリアＥＮＵＭサーバ２ｂは、ＳＩＰサーバ１ｂ、１ｘを経由してキャリアＥＮＵＭサーバ２ｘに前記更新要求を送信してもよい。また、前記更新要求は、問い合わせのあった電話端末４（４ｄ）の対応付け情報のみを差分更新として行ってもよいし、すべての電話端末の対応付け情報の全体更新として行ってもよい。
なお、後記の説明も踏まえれば、発信元の電話端末４ｓからのＳＩＰ信号は、着信先の電話端末４ｄに確実に転送されるので、ステップＳ１１の処理は省略してもよい。
ステップＳ１１の後、ステップＳ１２に進む。

ステップＳ１２において、キャリアＥＮＵＭサーバ２ｂは、ＵＲＩ通知部２１ｂの機能によって、マスタＥＮＵＭサーバ３から通知のあった、着信先となる電話端末４ｄのＵＲＩをＳＩＰサーバ１ｂに通知する。キャリアＥＮＵＭサーバ２ｂは、ＳＩＰサーバ１ｂからのＥＮＵＭクエリに対して、電話端末４ｄの着キャリア網がＩＭＳ−Ｃであることを示す「sip:+819012345678;npdi;rn=+819012340001@provider-C.net」という値を含むＵＲＩをＥＮＵＭアンサとしてＳＩＰサーバ１ｂに送信する。ステップＳ１２の後、ステップＳ１３に進む。

ステップＳ１３において、ＳＩＰサーバ１ｂは、番号解決部１２ｂの機能によって、電話端末４ｄの番号解決をする。ＳＩＰサーバ１ｂは、キャリアＥＮＵＭサーバ２ｂからのＥＮＵＭアンサを解析して、発信元である電話端末４ｓからのＳＩＰ信号の転送先がＩＭＳ−Ｃ内のＳＩＰサーバ１ｃであると決定する。ステップＳ１３の後、ステップＳ１４に進む。

ステップＳ１４において、ＳＩＰサーバ１ｂは、呼処理部１１ｂの機能によって、発信元である電話端末４ｓからのＳＩＰ信号を、転送先であるＳＩＰサーバ１ｃに送信する。前記ＳＩＰ信号は、転送先が、着信先である電話端末４ｄの着キャリア網（つまり、ＩＭＳ−Ｃ）であることを示す「INVITE sip:+819012345678;npdi;rn=+819012340001@provider-C.net SIP/2.0」という値を含む。ステップＳ１４の後、ステップＳ１５に進む。

ステップＳ１５において、ＳＩＰサーバ１ｃは、呼処理部１１ｃの機能によって、加入者ＤＢ１３ｃを検索する。呼処理部１１ｃは、例えばDIAMETERプロトコルによって、着信先の電話端末４ｄの電話番号を検索キーとして含むLIRを加入者ＤＢ１３ｃに入力する。ＩＭＳ−Ｃは着信先の電話端末４ｄを収容しているので、呼処理部１１ｃは、着信先の電話端末４ｄが存在していることを示すLIAを取得する。ステップＳ１５の後、ステップＳ１６に進む。

ステップＳ１６において、ＳＩＰサーバ１ｃは、呼処理部１１ｃの機能によって、着信先となる電話端末４ｄに着信する。ＳＩＰサーバ１ｃは、着信先にかけた電話が着信したことを示す「INVITE sip:+819012345678@192.168.0.1 SIP/2.0」という値を含むＳＩＰ信号（呼制御信号）を電話端末４ｄに送信する。ステップＳ１６の後、ステップＳ１７に進む。

ステップＳ１７において、着信先の電話端末４ｄは、ＳＩＰサーバ１ｘ、１ｃを介して、発信先の電話端末４ｓに対して最終応答を行う。着信先の電話端末４ｄは、着信先の電話端末４ｄのユーザが電話にでたことを示す「SIP/2.0 200 OK」という値を含むＳＩＰ信号を電話端末４ｄに送信する。前記ＳＩＰ信号は、ＳＩＰサーバ１ｃ、１ｂ、１ｘを経由する。ステップＳ１７の後、通話の通信が確立し、図４の処理を終了する。

なお、従来の技術によれば、ＳＩＰサーバ１ｂは、ステップＳ７の処理において着信先の電話端末４ｄが存在しないことを確認した後、「SIP/2.0 404 Not Found」という値を含むＳＩＰエラー応答をＳＩＰサーバ１ｘに送信していた。つまり、電話端末４ｓからの発信は、呼損となっていた。そのため、ユーザＸの電話端末４ｄの最新の対応付け情報を保有していないキャリア網（ＩＭＳ−Ｘ）を発キャリア網から電話端末４ｄに着信することは不可能であった。

本実施形態によれば、呼処理の遅延化を抑制するためにキャリアＥＮＵＭサーバ２による番号解決の処理を各々のキャリア網内で実現する形態をとる場合において、キャリアＥＮＵＭサーバ２のそれぞれが管理する対応付け情報の同一性が破綻していたとしても、前記同一性の破綻を認識したキャリア網が、前記対応付け情報の正しい内容をマスタＥＮＵＭサーバ３から取得する。よって、マスタＥＮＵＭサーバ３から取得したキャリア網は、正しい着キャリア網を特定できる。その結果、複数のキャリア網間での通信において、呼処理の遅延化を抑制し、番号ポータビリティを利用した電話端末に確実に着信させることができる。
なお、本実施形態の処理は、標準で規定されるプロトコル手順を用いて実行でき、また、データベースの性能がどのようなものであっても実行できるので、汎用性が高い。また、対応付け情報の同一性が破綻したことを確認したときにのみ、本実施形態の処理を実行すればよいので、処理の負荷を低減できる。

また、本実施形態によれば、キャリアＥＮＵＭサーバ２のそれぞれは、マスタＥＮＵＭサーバ３からの要求に応じて、着信先の電話端末のＵＲＩを、着信先の前記電話端末の電話番号に対応付けるように対応付け情報を書き換える（ステップＳ１１参照）。その結果、発信元の電話端末からの発信を受けた発キャリアは、正しい着キャリアに呼制御信号を送信することができ、今後の呼処理の遅延化を未然に防ぐことができる。

＜その他＞
本実施形態は、本発明を好適に実施するための一例あって、本発明を限定するためのものではない。よって、本発明の要旨を変更しない範囲内において、本実施形態を種々変形することが可能である。

例えば、本発明は、既存の回線交換網（CS:Circuit Switching）にも適用できる。

ステップＳ１０において、マスタＥＮＵＭサーバ３からのＥＮＵＭアンサによって、キャリアＥＮＵＭサーバ２ｂが、電話端末４ｄの着キャリア網がＩＭＳ−Ｃであることを認識した場合には、ＳＩＰサーバ１ｂは、呼処理部１１ｂの機能によって、発キャリア網内のＳＩＰサーバ１ｘに対し、着キャリア網内のＳＩＰサーバ１ｃへのＳＩＰ信号の再送信を指示してもよい。

もし、すでにユーザＸの電話端末４ｄによる通話サービスが解約されており、電話端末４ｄに関する対応付け情報が存在しない場合には、ステップＳ１０において、マスタＥＮＵＭサーバ３は、電話端末４ｄに関する対応付け情報が存在しないことを示すＥＮＵＭアンサをキャリアＥＮＵＭサーバ２ｂに送信する。このとき、ＳＩＰサーバ１ｂは、呼処理部１１ｂの機能によって、発キャリア網内のＳＩＰサーバ１ｘに対し、電話端末４ｄの電話番号が欠番であることを通知してもよい。

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１、１ｘ、１ａ、１ｂ、１ｃ ＳＩＰサーバ
１１、１１ｘ、１１ａ、１１ｂ、１１ｃ 呼処理部
１２、１２ｘ、１２ａ、１２ｂ、１２ｃ 番号解決部
１３、１３ｘ、１３ａ、１３ｂ、１３ｃ 加入者ＤＢ
２、２ｘ、２ａ、２ｂ、２ｃ キャリアＥＮＵＭサーバ
２１、２１ｘ、２１ａ、２１ｂ、２１ｃ ＵＲＩ通知部
２２、２２ｘ、２２ａ、２２ｂ、２２ｃ マッピングＤＢ
３ マスタＥＮＵＭサーバ
４、４ｓ、４ｄ 電話端末

Claims (3)

1. 自身のＳＩＰサーバおよび自身のキャリアＥＮＵＭサーバが配置されている複数のキャリア網と、電話端末の電話番号および前記電話端末のＵＲＩを対応付けるマスタＥＮＵＭサーバとが互いに接続しており、発信元の電話端末と、番号ポータビリティを利用した着信先の電話端末との接続を実現する番号解決システムであって、
   複数の前記キャリア網内の前記ＳＩＰサーバのそれぞれは、
   自身のキャリア網が収容している電話端末の電話番号を記憶している加入者データベースと、
   発キャリア網内の前記ＳＩＰサーバから、着信先の前記電話端末の電話番号および自身のキャリア網を示すドメイン名を含む呼制御信号を受信し、
   自身の前記キャリアＥＮＵＭサーバの処理に基づいて番号解決された着信先の前記電話端末を収容している着キャリア網内の前記ＳＩＰサーバに、着信先の前記電話端末の電話番号および前記着キャリア網を示すドメイン名を含む呼制御信号を送信する、呼処理部と、
   前記加入者データベースを参照しても着信先の前記電話端末の電話番号が存在しない場合には、自身のキャリア網内の前記キャリアＥＮＵＭサーバに対して、着信先の前記電話端末のＵＲＩの問い合わせをすることで、着信先の前記電話端末の番号解決をする番号解決部と、を備え、
   複数の前記キャリア網内の前記キャリアＥＮＵＭサーバのそれぞれは、
   前記電話端末の電話番号および前記電話端末のＵＲＩの対応付け情報を、前記マスタＥＮＵＭサーバから取得して記憶しているマッピングデータベースと、
   前記番号解決部からの前記問い合わせに応じて、前記マスタＥＮＵＭサーバに問い合わせて取得した、着信先の前記電話端末のＵＲＩを前記番号解決部に通知するＵＲＩ通知部と、を備える、
   ことを特徴とする番号解決システム。
2. 複数の前記キャリア網内の前記キャリアＥＮＵＭサーバのそれぞれは、
   前記マスタＥＮＵＭサーバからの要求に応じて、着信先の前記電話端末のＵＲＩを、着信先の前記電話端末の電話番号に対応付けるように前記対応付け情報を書き換える、
   ことを特徴とする請求項１に記載の番号解決システム。
3. 自身のＳＩＰサーバおよび自身のキャリアＥＮＵＭサーバが配置されている複数のキャリア網と、電話端末の電話番号および前記電話端末のＵＲＩを対応付けるマスタＥＮＵＭサーバとが互いに接続しており、発信元の電話端末と、番号ポータビリティを利用した着信先の電話端末との接続を実現する番号解決システムにおける番号解決方法であって、
   自身のキャリア網内の前記ＳＩＰサーバが、発キャリア網内の前記ＳＩＰサーバから、着信先の前記電話端末の電話番号および自身のキャリア網を示すドメイン名を含む呼制御信号を受信するステップと、
   自身のキャリア網内の前記ＳＩＰサーバが、自身のキャリア網が収容している電話端末の電話番号を含む加入者情報を記憶している加入者データベースを参照しても着信先の前記電話端末の電話番号が存在しない場合には、自身のキャリア網内の前記キャリアＥＮＵＭサーバに対して、着信先の前記電話端末のＵＲＩの問い合わせをするステップと、
   自身のキャリア網内の前記キャリアＥＮＵＭサーバが、前記問い合わせに応じて、前記マスタＥＮＵＭサーバに問い合わせて取得した、着信先の前記電話端末のＵＲＩを、自身のキャリア網内の前記ＳＩＰサーバに通知するステップと、
   自身のキャリア網内の前記ＳＩＰサーバが、前記通知された着信先の前記電話端末のＵＲＩを用いて、着信先の前記電話端末の番号解決をするステップと、
   自身のキャリア網内の前記ＳＩＰサーバが、前記番号解決された着信先の前記電話端末を収容している着キャリア網内の前記ＳＩＰサーバに、着信先の前記電話端末の電話番号および前記着キャリア網を示すドメイン名を含む呼制御信号を送信するステップと、を実行する、
   ことを特徴とする番号解決方法。

Images