(57)【要約】【課題】ＳＩＰサーバにかかる処理負荷を小さくするＤＮＳパケット処理システムを提供する。【解決手段】ＤＮＳパケット処理システムに含まれるＳＩＰサーバ１０は、電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部１２２を備え、ＤＮＳサーバ２０は、電話番号をデータとして記憶する記憶部２３と、電話番号がラベル形式のＤＮＳクエリパケットから電話番号を抽出して、当該データを参照するＤＮＳ信号解析部２２１と、接続先情報の問合せが解決できた場合、電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部２２２と、を備える。【選択図】図１
2019029965.tif 000002
【特許請求の範囲】
【請求項１】
着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、
前記ＳＩＰサーバは、
発信元端末からＳＩＰリクエストを受信し、前記着信先端末へと前記ＳＩＰリクエストを送信するＳＩＰ信号通信部と、
前記ＳＩＰリクエストに基づいて前記電話番号を取得するＳＩＰ信号解析部と、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、
前記ＤＮＳサーバへとＤＮＳクエリを送信し、前記ＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、
前記ＤＮＳアンサに基づいて前記接続先情報を取得するＤＮＳ信号解析部と、
前記接続先情報に応じてＳＩＰ信号を生成するＳＩＰ信号生成部と、を備え、
前記ＤＮＳサーバは、
前記ＳＩＰサーバから前記ＤＮＳクエリを受信し、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、
前記電話番号をデータとして記憶する記憶部と、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、
前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、
を備えることを特徴とするＤＮＳパケット処理システム。
【請求項２】
着信先端末の電話番号に対応する接続先情報の問合せを行うＤＮＳクライアントと、前記ＤＮＳクライアントから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、
前記ＤＮＳクライアントは、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、
前記ＤＮＳサーバへとＤＮＳクエリを送信し、前記ＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、を備え、
前記ＤＮＳサーバは、
前記ＤＮＳクライアントから前記ＤＮＳクエリを受信し、前記ＤＮＳクライアントへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、
前記電話番号をデータとして記憶する記憶部と、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、
前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、
を備えることを特徴とするＤＮＳパケット処理システム。
【請求項３】
着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、
前記ＳＩＰサーバは、
発信元端末からＳＩＰリクエストを受信し、前記着信先端末へと前記ＳＩＰリクエストを送信するＳＩＰ信号通信部と、
前記ＳＩＰリクエストに基づいて前記電話番号を取得するＳＩＰ信号解析部と、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、
前記ＤＮＳサーバへとＤＮＳクエリを送信し、前記ＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、
前記ＤＮＳアンサに基づいて前記接続先情報を取得するＤＮＳ信号解析部と、
前記接続先情報に応じてＳＩＰ信号を生成するＳＩＰ信号生成部と、を備え、
前記ＤＮＳサーバは、
前記ＳＩＰサーバから前記ＤＮＳクエリを受信し、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、
前記電話番号をデータとして記憶する記憶部と、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、
前記問合せが解決できていない場合、前記電話番号を、ラベル形式の電話番号からドメイン形式の電話番号へと変換する表記形式変換機能部と、
前記ドメイン形式の電話番号に基づいて、他のＤＮＳサーバに前記問合せを行うフルサービスリゾルバ機能部と、
前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、
を備えることを特徴とするＤＮＳパケット処理システム。
【請求項４】
着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付ける複数のＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、
前記ＳＩＰサーバは、
発信元端末からＳＩＰリクエストを受信し、前記着信先端末へと前記ＳＩＰリクエストを送信するＳＩＰ信号通信部と、
前記ＳＩＰリクエストに基づいて前記電話番号を取得するＳＩＰ信号解析部と、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、
第１のＤＮＳサーバへとＤＮＳクエリを送信し、前記第１のＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、
前記ＤＮＳアンサに基づいて前記接続先情報を取得するＤＮＳ信号解析部と、
前記接続先情報に応じてＳＩＰ信号を生成するＳＩＰ信号生成部と、を備え、
前記第１のＤＮＳサーバは、
前記ＳＩＰサーバから前記ＤＮＳクエリを受信し、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、
前記電話番号をデータとして記憶する記憶部と、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、
前記問合せが解決できていない場合、前記ＤＮＳクエリパケットに基づいて、第２のＤＮＳサーバに前記問合せを行うフルサービスリゾルバ機能部と、
前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、
を備えることを特徴とするＤＮＳパケット処理システム。
【請求項５】
着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、
前記ＳＩＰサーバは、
発信元端末からＳＩＰリクエストを受信するステップと、
前記ＳＩＰリクエストに基づいて前記電話番号を取得するステップと、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、
前記ＤＮＳサーバへとＤＮＳクエリを送信するステップと、
前記ＤＮＳサーバからＤＮＳアンサを受信するステップと、
前記ＤＮＳアンサに基づいて前記接続先情報を取得するステップと、
前記接続先情報に応じてＳＩＰ信号を生成するステップと、
前記着信先端末へと前記ＳＩＰリクエストを送信するステップと、を実行し、
前記ＤＮＳサーバは、
前記ＳＩＰサーバから前記ＤＮＳクエリを受信するステップと、
前記電話番号をデータとして記憶するステップと、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、
前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、
前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するステップと、
を実行することを特徴とするＤＮＳパケット処理方法。
【請求項６】
着信先端末の電話番号に対応する接続先情報の問合せを行うＤＮＳクライアントと、前記ＤＮＳクライアントから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、
前記ＤＮＳクライアントは、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、
前記ＤＮＳサーバへとＤＮＳクエリを送信するステップと、
前記ＤＮＳサーバからＤＮＳアンサを受信するステップと、を実行し、
前記ＤＮＳサーバは、
前記ＤＮＳクライアントから前記ＤＮＳクエリを受信するステップと、
前記電話番号をデータとして記憶するステップと、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、
前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、
前記ＤＮＳクライアントへと前記ＤＮＳアンサを送信するステップと、
を実行することを特徴とするＤＮＳパケット処理方法。
【請求項７】
着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、
前記ＳＩＰサーバは、
発信元端末からＳＩＰリクエストを受信するステップと、
前記ＳＩＰリクエストに基づいて前記電話番号を取得するステップと、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、
前記ＤＮＳサーバへとＤＮＳクエリを送信するステップと、
前記ＤＮＳサーバからＤＮＳアンサを受信するステップと、
前記ＤＮＳアンサに基づいて前記接続先情報を取得するステップと、
前記接続先情報に応じてＳＩＰ信号を生成するステップと、
前記着信先端末へと前記ＳＩＰリクエストを送信するステップと、を実行し、
前記ＤＮＳサーバは、
前記ＳＩＰサーバから前記ＤＮＳクエリを受信するステップと、
前記電話番号をデータとして記憶するステップと、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、
前記問合せが解決できていない場合、前記電話番号を、ラベル形式の電話番号からドメイン形式の電話番号へと変換するステップと、
前記ドメイン形式の電話番号に基づいて、他のＤＮＳサーバに前記問合せを行うステップと、
前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、
前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するステップと、
を実行することを特徴とするＤＮＳパケット処理方法。
【請求項８】
着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付ける複数のＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、
前記ＳＩＰサーバは、
発信元端末からＳＩＰリクエストを受信するステップと、
前記ＳＩＰリクエストに基づいて前記電話番号を取得するステップと、
前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、
第１のＤＮＳサーバへとＤＮＳクエリを送信するステップと、
前記第１のＤＮＳサーバからＤＮＳアンサを受信するステップと、
前記ＤＮＳアンサに基づいて前記接続先情報を取得するステップと、
前記接続先情報に応じてＳＩＰ信号を生成するステップと、
前記着信先端末へと前記ＳＩＰリクエストを送信するステップと、を実行し、
前記第１のＤＮＳサーバは、
前記ＳＩＰサーバから前記ＤＮＳクエリを受信するステップと、
前記電話番号をデータとして記憶するステップと、
前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、
前記問合せが解決できていない場合、前記ＤＮＳクエリパケットに基づいて、第２のＤＮＳサーバに前記問合せを行うステップと、
前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、
前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するステップと、
を備えることを特徴とするＤＮＳパケット処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）電話を提供するサービス網（ＩＰ網）が複数事業者により提供され、それらが相互接続されるシステムにおいて、事業者間で電話番号を持ちまわる番号ポータビリティ制度が導入されている条件下でのＤＮＳパケット処理システム、及びＤＮＳパケット処理方法に関する。
【背景技術】
【０００２】
従来、ＩＰ網において通信事業者網内の装置（ＳＩＰ（Session Initiation/Protocol）サーバ等）が、電話番号とＵＲＩ（Uniform Resource Identifier）との対応付けを行う仕組みとしてＥＮＵＭ（E.164 Number Mapping）／ＤＮＳ（Domain Name System）システムが提案されている。このＥＮＵＭ／ＤＮＳシステムでは、通信事業者のネットワーク内に設置されたＳＩＰサーバが、接続先となる端末（ＩＰ電話等）の電話番号についての接続先の情報（ＩＰアドレスや、ドメイン名等）をＤＮＳサーバに問合せて、その接続先の情報に基づいてルーティングを行う。
【０００３】
また、ＰＳＴＮ（Public Switched Telephone Network：公衆電話交換回線網）網からＩＰ網への移行に伴い、ＩＰ網において固定電話番号を通信事業者間で自由に持ち回れる番号ポータビリティの仕組みが検討されている（非特許文献１参照）。
【０００４】
非特許文献１に記載の方式では、各通信事業者の番号ポータビリティ情報を集中管理したデータベースを、ＤＮＳの仕組みを利用したＤＮＳサーバ（ＤＮＳ権威サーバ）に備え、各通信事業者のＳＩＰサーバは、ＤＮＳサーバ（ＤＮＳ権威サーバ）にアクセスすることにより、各電話番号が他網へ移転(ポートアウト)しているか否かを解決し、接続先の情報を取得して通信を行う。
【０００５】
図１１は、ＤＮＳサーバを採用した場合のＥＮＵＭ／ＤＮＳシステムの従来例を示す図である。
【０００６】
図１１に示すように、まず、０３−９９９９帯の端末１（１ａ）（発信元端末：ＩＰ電話等）から０４２２−５９帯の端末１（１ｂ）（着信先端末：ＩＰ電話等）への「接続要求メッセージ（ＳＩＰリクエスト）」（図１１において、「接続要求」と記載する。）が、ＳＩＰサーバ２０へ送信される（ステップＳ１１）。
【０００７】
接続要求メッセージを受け付けたＳＩＰサーバ２０は、ＤＮＳサーバ２０に対して、着信先の通信事業者へ接続するための接続先情報（着信先電話番号に対応するＵＲＩ等）の問合せ（「接続先情報問合せメッセージ（ＤＮＳクエリ）」。図１１において、「接続先情報問合せ」と記載する。）を行う（ステップＳ１２）。
【０００８】
ＤＮＳサーバ２０は、接続先情報問合せメッセージを受信すると、自身の記憶部を参照し、その着信先の端末（「着信先情報」）に対応する接続先情報を抽出し、ＳＩＰサーバ２０に応答情報（「接続先情報問合せ応答メッセージ（ＤＮＳアンサ）」。図１１において、「接続先情報問合せ応答」と記載する。）を送信する（ステップＳ１３）。なお、ＤＮＳサーバ２０に、着信先情報に対応する接続先情報が記憶されていない場合には、ＤＮＳサーバ２０は、他の通信事業者のＩＰ網（他ＩＰ網）２０００に対して、着信先の通信事業者へ接続するための接続先情報の問合せを行っても良い。
【０００９】
ＳＩＰサーバ２０は、接続先情報問合せ応答メッセージに含まれる接続先情報を受信すると、着信先が、通信事業者のネットワークである自ＩＰ網１０００か否かを判断し、自ＩＰ網１０００である場合には、着信先となる０４２２−５９帯の端末１（１ｂ）に呼接続する（ステップＳ１４）。一方、ＳＩＰサーバ２０は、着信先が、他ＩＰ網２０００である場合には、接続先情報に示される他ＩＰ網２０００へＳＩＰ信号を転送する（図示省略）。
【００１０】
上記の処理とは別に、ＤＮＳサーバ２０は、他ＩＰ網２０００からも、自身が管理する着信先情報に対応する接続先情報問合せメッセージを受け付ける（ステップＳ１５）。そして、ＤＮＳサーバ２０は、着信先情報に対応する接続先情報を抽出し、問合せを送信してきた他ＩＰ網２０００に接続先情報問合せ応答メッセージを送信する（ステップＳ１６）。
【００１１】
図１２は、ＤＮＳ権威サーバと、ＤＮＳ権威サーバの負荷を軽減するためのＤＮＳキャッシュサーバを採用した場合のＥＮＵＭ／ＤＮＳシステムの従来例を示す図である。
【００１２】
図１２に示すように、まず、０３−９９９９帯の端末１（１ａ）（ＩＰ電話等）から０４２２−５９帯の端末１（１ｂ）（ＩＰ電話等）への「接続要求メッセージ（ＳＩＰリクエスト）」（図１２において、「接続要求」と記載する。）が、ＳＩＰサーバ２０へ送信される（ステップＳ１）。
【００１３】
接続要求メッセージを受け付けたＳＩＰサーバ２０は、ＤＮＳキャッシュサーバ６０に対して、着信先の通信事業者へ接続するための接続先情報（着信先電話番号に対応するＵＲＩ等）の取得要求（「接続先情報要求メッセージ」。図１２において、「接続先情報要求」と記載する。）を送信する（ステップＳ２）。
【００１４】
ＤＮＳキャッシュサーバ６０は、着信先情報に対応する接続先情報を自身の記憶部に記憶（キャッシュ）しているかを確認し、記憶していない場合には、ＤＮＳ権威サーバ７０に対して、着信先の通信事業者へ接続するための接続先情報（着信先電話番号に対応するＵＲＩ等）の問合せ（「接続先情報問合せメッセージ（ＤＮＳクエリ）」。図１２において、「接続先情報問合せ」と記載する。）を行う（ステップＳ３）。なお、ＤＮＳキャッシュサーバ６０は、他ＩＰ網２０００に対して、着信先の通信事業者へ接続するための接続先情報の問合せを行っても良い。
【００１５】
ＤＮＳ権威サーバ７０は、接続先情報問合せメッセージを受信すると、自身の記憶部を参照し、その着信先の端末（「着信先情報」）に対応する接続先情報を抽出し、ＤＮＳキャッシュサーバ６０に応答情報（「接続先情報問合せ応答メッセージ（ＤＮＳアンサ）」。図１２においては、「接続先情報問合せ応答」と記載する。）を送信する（ステップＳ４）。
【００１６】
ＤＮＳキャッシュサーバ６０は、接続先情報問合せ応答メッセージに含まれる接続先情報を受信すると、その応答情報に含まれる接続先情報を自身の記憶部に記憶（キャッシュ）する（ステップＳ５）。そして、ＤＮＳキャッシュサーバ６０は、その接続先情報を含む応答メッセージ（「接続先情報応答メッセージ」。図１２においては、「接続先情報応答」と記載する。）を、ＳＩＰサーバ２０に送信する（ステップＳ６）。
【００１７】
なお、ステップＳ３〜Ｓ５の処理について、ＤＮＳキャッシュサーバ６０に着信先の通信事業者に対応する接続先情報が記憶（キャッシュ）されている場合には行わず、ＤＮＳキャッシュサーバ６０は、ＳＩＰサーバ２０に接続先情報応答メッセージを送信しても良い（ステップＳ６の処理）。
【００１８】
ＳＩＰサーバ２０は、接続先情報応答メッセージに含まれる接続先情報を受信すると、着信先が自ＩＰ網１０００か否かを判断し、自ＩＰ網１０００である場合には、着信先となる０４２２−５９帯の端末１（１ｂ）に呼接続する（ステップＳ７）。一方、ＳＩＰサーバ２０は、着信先が他ＩＰ網２０００である場合には、接続先情報に示される他ＩＰ網２０００へＳＩＰ信号を転送する（図示省略）。
【００１９】
上記の処理とは別に、ＤＮＳ権威サーバ７０は、他ＩＰ網２０００からも、自身が管理する着信先情報に対応する接続先情報問合せメッセージを受け付ける（ステップＳ８）。そして、ＤＮＳ権威サーバ７０は、着信先情報に対応する接続先情報を抽出し、問合せを送信してきた他ＩＰ網２０００に接続先情報問合せ応答メッセージを送信する（ステップＳ９）。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】「ＪＪ−９０．３１  キャリアＥＮＵＭの相互接続  共通インタフェース」一般社団法人情報通信技術委員会、２０１５年８月２７日
【非特許文献２】Domain Names: Implementation and Specification、［online］、［平成２９年７月２６日検索］、インターネット〈URL：https://www.ietf.org/rfc/rfc1035.txt〉
【発明の概要】
【発明が解決しようとする課題】
【００２１】
ところで、ＳＩＰサーバは、ＤＮＳサーバへと送信する接続先情報問合せメッセージ（ＤＮＳクエリ）における、質問部（Ｑｕｅｓｔｉｏｎ部）のＱＮＡＭＥを、一般的に以下のような手順で生成する。
（Ａ）発信元端末から受信した接続要求メッセージ（ＳＩＰリクエスト）に含まれる着信先端末の電話番号（例えば、０４２２−５９−９９９９）のE.164番号（“＋81-4-2259-9999”）から先頭の“＋”、及びvisual-separatorを除外して、“81422599999”とする。
（Ｂ）数字を逆順に並べ替えて、“99999522418”とする。
（Ｃ）数字の間にピリオド“.”を挿入して、“9.9.9.9.9.5.2.2.4.1.8”とする。
（Ｄ）末尾に“.e164enum.net.”を付与して、着信先端末の電話番号をドメイン形式に変換し、“9.9.9.9.9.5.2.2.4.1.8.e164enum.net.”とする。
（Ｅ）“9.9.9.9.9.5.2.2.4.1.8.e164enum.net.”を、［RFC 1035］の4.1.2節（Question selection format）に従って（非特許文献２参照）、「各ラベルのオクテット数＋その数だけのオクテット」の連続で表し、実データ（１６進数）“013901390139013901390135013201320134013101380865313634656e756d036e657400”を生成する（図１３（ａ）参照）。
例えば、“e164enum”において、ラベルの長さを表す数値は、「8」であり、“e164enum”全体を１６進数に変換した数値は、「65313634656e756d」であるため、“e164enum”を、実データで表すと、0865313634656e756dとなる（図１３（ａ）のＸ１参照）。また、例えば、“net”において、ラベルの長さを表す数値は、「3」であり、“net”全体を１６進数に変換した数値は、「6e6574」であるため、“net”を、実データで表すと、036e6574となる（図１３（ａ）のＸ２参照）。
【００２２】
ＤＮＳサーバは、ＳＩＰサーバからＤＮＳクエリを受信すると、自身の記憶部に格納されるデータを参照して、着信先端末の電話番号に対応する接続先情報を抽出し、ＳＩＰサーバへと接続先情報問合せ応答メッセージ（ＤＮＳアンサ）を送信する。ＤＮＳサーバの記憶部には、例えば、ドメイン“9.9.9.9.9.5.2.2.4.1.8.e164enum.net.”、ＮＡＰＴＲレコード“100 10 u E2U+sip !^.*$!sip:+81422609999@exapmle2.ne.jp;user=phone! .”、或いは、ドメイン“9.9.9.9.9.5.2.2.4.1.8.e164enum.net.”、ＮＡＰＴＲレコード“100 20 u E2U+pstn:sip !^.*$!sip:+81422609999;npdi;rn=+81422610051@exapmle2.ne.jp;user=phone! .”、等のデータが格納される（図１３（ｂ）参照）。ＤＮＳサーバは、これらのデータを参照して、着信先端末の電話番号に対応する接続先情報の問合せの解決を行う。
【００２３】
しかしながら、上述のように、従来のＥＮＵＭ／ＤＮＳシステムでは、ＳＩＰサーバがＤＮＳクエリを生成する際、着信先端末の電話番号をドメイン形式に変換していたため、ＳＩＰサーバにかかる処理負荷が大きくなってしまうという問題が生じていた。
【００２４】
このような背景を鑑みて本発明がなされたのであり、本発明は、ＳＩＰサーバにかかる処理負荷を小さくするＤＮＳパケット処理システム及びＤＮＳパケット処理システム方法を提供することを課題とする。
【課題を解決するための手段】
【００２５】
前記した課題を解決するため、請求項１に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、前記ＳＩＰサーバは、発信元端末からＳＩＰリクエストを受信し、前記着信先端末へと前記ＳＩＰリクエストを送信するＳＩＰ信号通信部と、前記ＳＩＰリクエストに基づいて前記電話番号を取得するＳＩＰ信号解析部と、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、前記ＤＮＳサーバへとＤＮＳクエリを送信し、前記ＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、前記ＤＮＳアンサに基づいて前記接続先情報を取得するＤＮＳ信号解析部と、前記接続先情報に応じてＳＩＰ信号を生成するＳＩＰ信号生成部と、を備え、前記ＤＮＳサーバは、前記ＳＩＰサーバから前記ＤＮＳクエリを受信し、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、前記電話番号をデータとして記憶する記憶部と、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、を備えることを特徴とするＤＮＳパケット処理システムとした。
【００２６】
また、請求項５に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、前記ＳＩＰサーバは、発信元端末からＳＩＰリクエストを受信するステップと、前記ＳＩＰリクエストに基づいて前記電話番号を取得するステップと、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、前記ＤＮＳサーバへとＤＮＳクエリを送信するステップと、前記ＤＮＳサーバからＤＮＳアンサを受信するステップと、前記ＤＮＳアンサに基づいて前記接続先情報を取得するステップと、前記接続先情報に応じてＳＩＰ信号を生成するステップと、前記着信先端末へと前記ＳＩＰリクエストを送信するステップと、を実行し、前記ＤＮＳサーバは、前記ＳＩＰサーバから前記ＤＮＳクエリを受信するステップと、前記電話番号をデータとして記憶するステップと、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するステップと、を実行することを特徴とするＤＮＳパケット処理方法とした。
【００２７】
このようにすることで、ＳＩＰサーバがパケットサイズの小さいＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、ＤＮＳサーバもパケットサイズの小さいＤＮＳアンサパケットを生成できる。このＳＩＰサーバを当該ＤＮＳパケット処理システムに採用することで、ＳＩＰサーバにかかる処理負荷を小さくすることが可能になる。
【００２８】
請求項２に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＤＮＳクライアントと、前記ＤＮＳクライアントから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、前記ＤＮＳクライアントは、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、前記ＤＮＳサーバへとＤＮＳクエリを送信し、前記ＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、を備え、前記ＤＮＳサーバは、前記ＤＮＳクライアントから前記ＤＮＳクエリを受信し、前記ＤＮＳクライアントへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、前記電話番号をデータとして記憶する記憶部と、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、を備えることを特徴とするＤＮＳパケット処理システムとした。
【００２９】
また、請求項６に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＤＮＳクライアントと、前記ＤＮＳクライアントから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、前記ＤＮＳクライアントは、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、前記ＤＮＳサーバへとＤＮＳクエリを送信するステップと、前記ＤＮＳサーバからＤＮＳアンサを受信するステップと、を実行し、前記ＤＮＳサーバは、前記ＤＮＳクライアントから前記ＤＮＳクエリを受信するステップと、前記電話番号をデータとして記憶するステップと、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、前記問合せが解決できた場合、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、前記ＤＮＳクライアントへと前記ＤＮＳアンサを送信するステップと、を実行することを特徴とするＤＮＳパケット処理方法とした。
【００３０】
このようにすることで、ＤＮＳクライアントがパケットサイズの小さいＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、ＤＮＳサーバもパケットサイズの小さいＤＮＳアンサパケットを生成できる。このＤＮＳクライアントを当該ＤＮＳパケット処理システムに採用することで、ＤＮＳクライアントにかかる処理負荷を小さくすることが可能になる。
【００３１】
請求項３に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、前記ＳＩＰサーバは、発信元端末からＳＩＰリクエストを受信し、前記着信先端末へと前記ＳＩＰリクエストを送信するＳＩＰ信号通信部と、前記ＳＩＰリクエストに基づいて前記電話番号を取得するＳＩＰ信号解析部と、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、前記ＤＮＳサーバへとＤＮＳクエリを送信し、前記ＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、前記ＤＮＳアンサに基づいて前記接続先情報を取得するＤＮＳ信号解析部と、前記接続先情報に応じてＳＩＰ信号を生成するＳＩＰ信号生成部と、を備え、前記ＤＮＳサーバは、前記ＳＩＰサーバから前記ＤＮＳクエリを受信し、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、前記電話番号をデータとして記憶する記憶部と、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、前記問合せが解決できていない場合、前記電話番号を、ラベル形式の電話番号からドメイン形式の電話番号へと変換する表記形式変換機能部と、前記ドメイン形式の電話番号に基づいて、他のＤＮＳサーバに前記問合せを行うフルサービスリゾルバ機能部と、前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、を備えることを特徴とするＤＮＳパケット処理システムとした。
【００３２】
また、請求項７に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付けるＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、前記ＳＩＰサーバは、発信元端末からＳＩＰリクエストを受信するステップと、前記ＳＩＰリクエストに基づいて前記電話番号を取得するステップと、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、前記ＤＮＳサーバへとＤＮＳクエリを送信するステップと、前記ＤＮＳサーバからＤＮＳアンサを受信するステップと、前記ＤＮＳアンサに基づいて前記接続先情報を取得するステップと、前記接続先情報に応じてＳＩＰ信号を生成するステップと、前記着信先端末へと前記ＳＩＰリクエストを送信するステップと、を実行し、前記ＤＮＳサーバは、前記ＳＩＰサーバから前記ＤＮＳクエリを受信するステップと、前記電話番号をデータとして記憶するステップと、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、前記問合せが解決できていない場合、前記電話番号を、ラベル形式の電話番号からドメイン形式の電話番号へと変換するステップと、前記ドメイン形式の電話番号に基づいて、他のＤＮＳサーバに前記問合せを行うステップと、前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するステップと、を実行することを特徴とするＤＮＳパケット処理方法とした。
【００３３】
このようにすることで、着信先端末の電話番号に対応する接続先情報の問合せの解決を行う他のＤＮＳサーバが、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに対応していない場合であっても、ＳＩＰサーバがパケットサイズの小さいＤＮＳクエリパケットを生成することができる。このＳＩＰサーバを当該ＤＮＳパケット処理システムに採用することで、ＳＩＰサーバにかかる処理負荷を小さくすることが可能になる。
【００３４】
請求項４に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付ける複数のＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムであって、前記ＳＩＰサーバは、発信元端末からＳＩＰリクエストを受信し、前記着信先端末へと前記ＳＩＰリクエストを送信するＳＩＰ信号通信部と、前記ＳＩＰリクエストに基づいて前記電話番号を取得するＳＩＰ信号解析部と、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するＤＮＳ信号生成部と、第１のＤＮＳサーバへとＤＮＳクエリを送信し、前記第１のＤＮＳサーバからＤＮＳアンサを受信するＤＮＳ信号通信部と、前記ＤＮＳアンサに基づいて前記接続先情報を取得するＤＮＳ信号解析部と、前記接続先情報に応じてＳＩＰ信号を生成するＳＩＰ信号生成部と、を備え、前記第１のＤＮＳサーバは、前記ＳＩＰサーバから前記ＤＮＳクエリを受信し、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するＤＮＳ信号通信部と、前記電話番号をデータとして記憶する記憶部と、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するＤＮＳ信号解析部と、前記問合せが解決できていない場合、前記ＤＮＳクエリパケットに基づいて、第２のＤＮＳサーバに前記問合せを行うフルサービスリゾルバ機能部と、前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するＤＮＳ信号生成部と、を備えることを特徴とするＤＮＳパケット処理システムとした。
【００３５】
また、請求項８に記載の発明は、着信先端末の電話番号に対応する接続先情報の問合せを行うＳＩＰサーバと、前記ＳＩＰサーバから前記問合せを受け付ける複数のＤＮＳサーバと、を含んで構成されるＤＮＳパケット処理システムにおけるＤＮＳパケット処理方法であって、前記ＳＩＰサーバは、発信元端末からＳＩＰリクエストを受信するステップと、前記ＳＩＰリクエストに基づいて前記電話番号を取得するステップと、前記電話番号がラベル形式のＤＮＳクエリパケットを生成するステップと、第１のＤＮＳサーバへとＤＮＳクエリを送信するステップと、前記第１のＤＮＳサーバからＤＮＳアンサを受信するステップと、前記ＤＮＳアンサに基づいて前記接続先情報を取得するステップと、前記接続先情報に応じてＳＩＰ信号を生成するステップと、前記着信先端末へと前記ＳＩＰリクエストを送信するステップと、を実行し、前記第１のＤＮＳサーバは、前記ＳＩＰサーバから前記ＤＮＳクエリを受信するステップと、前記電話番号をデータとして記憶するステップと、前記ＤＮＳクエリパケットから前記電話番号を抽出して、前記データを参照するステップと、前記問合せが解決できていない場合、前記ＤＮＳクエリパケットに基づいて、第２のＤＮＳサーバに前記問合せを行うステップと、前記問合せが解決できた後、前記電話番号がラベル形式のＤＮＳアンサパケットを生成するステップと、前記ＳＩＰサーバへと前記ＤＮＳアンサを送信するステップと、を備えることを特徴とするＤＮＳパケット処理方法とした。
【００３６】
このようにすることで、ＳＩＰサーバがパケットサイズの小さいＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できていない場合、他のＤＮＳサーバが、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに基づいて、問合せの解決を行うことができる。このＳＩＰサーバを当該ＤＮＳパケット処理システムに採用することで、ＳＩＰサーバにかかる処理負荷を小さくすることが可能になる。
【発明の効果】
【００３７】
本発明によれば、ＳＩＰサーバにかかる処理負荷を小さくするＤＮＳパケット処理システム及びＤＮＳパケット処理方法を提供できる。
【図面の簡単な説明】
【００３８】
【図１】第１実施形態に係るＤＮＳパケット処理システムの全体構成を示す図である。
【図２】第１実施形態に係るＳＩＰリクエストにおけるデータ構成例、及びＤＮＳクエリにおけるデータ構成例を示す図である。
【図３】第１実施形態に係る記憶部に格納されるデータ構成例を示す図である。
【図４】第１実施形態に係るＳＩＰサーバの動作を示すフローチャートである。
【図５】第１実施形態に係るＤＮＳサーバの動作を示すフローチャートである。
【図６】変形例１に係るＤＮＳパケット処理システムの全体構成を示す図である。
【図７】第２実施形態に係るＤＮＳパケット処理システムの全体構成を示す図である。
【図８】第２実施形態に係るＳＩＰサーバの動作を示すフローチャートである。
【図９】第２実施形態に係るＤＮＳサーバの動作を示すフローチャートである。
【図１０】変形例２に係るＤＮＳパケット処理システムの全体構成を示す図である。
【図１１】従来のＥＮＵＭ／ＤＮＳシステムの構成例を示す図である。
【図１２】従来のＥＮＵＭ／ＤＮＳシステムの構成例を示す図である。
【図１３】従来のＤＮＳクエリにおけるデータ構成例、及び記憶部に格納されるデータ構成例を示す図である。
【発明を実施するための形態】
【００３９】
以下、本発明を実施するための形態（以下、実施形態と称する。）における、ＤＮＳパケット処理システムについて説明する。
【００４０】
＜第１実施形態＞
≪ＤＮＳパケット処理システムの構成≫
まず、本実施形態に係るＤＮＳパケット処理システムについて説明する。図１は、本実施形態に係るＤＮＳパケット処理システム１００の全体構成を示す図である。
【００４１】
図１に示すように、本実施形態に係るＤＮＳパケット処理システム１００は、通信事業者のネットワークである自ＩＰ網に、複数の発信元端末１ａ及び複数の着信先端末１ｂを収容するＳＩＰサーバ１０と、ＳＩＰサーバ１０から着信先端末の電話番号に対応する接続先情報の問合せを受け付けるＤＮＳサーバ２０とを含んで構成される。
【００４２】
本実施形態に係るＤＮＳパケット処理システム１００は、ＳＩＰサーバ１０が、パケットサイズの小さいＤＮＳクエリパケットを生成することを特徴とする。また、ＤＮＳサーバ２０が、人間が視認し易い電話番号をデータとして記憶し、当該データを参照して、ＤＮＳアンサパケットを生成、或いは反復問合せを行うことを特徴とする。
【００４３】
例えば、ＳＩＰサーバ１０は、着信先端末の電話番号がラベル形式（詳細は後述する）で表されたＤＮＳクエリパケットを生成する。また、例えば、ＤＮＳサーバ２０は、自身の記憶部に格納されるデータを参照して、問合せが解決できた場合、着信先端末の電話番号がラベル形式で表されたＤＮＳアンサパケットを生成する。
【００４４】
なお、図１では、ＳＩＰサーバ１０、ＤＮＳサーバ２０が１台の場合を一例に挙げて説明しているが、これらのサーバの台数は特に限定されるものではない。また、ＤＮＳパケット処理システム１００において、ＤＮＳサーバ２０を１つの装置で構成せずに、ＤＮＳ権威サーバとＤＮＳキャッシュサーバとを別装置とする構成としても良い。この場合、ＤＮＳキャッシュサーバにも本実施形態に係るＳＩＰサーバ１０の機能を持たせることが可能である。以下、具体的に説明する。
【００４５】
≪ＳＩＰサーバ１０≫
図１及び図２を参照して、本実施形態に係るＳＩＰサーバ１０について説明する。図２（ａ）は、ＳＩＰリクエストにおけるRequest-URIに格納されるデータの一例であり、図２（ｂ）は、ＤＮＳクエリにおけるＱｕｅｓｔｉｏｎ部のＱＮＡＭＥに格納されるデータの一例である。
【００４６】
ＳＩＰサーバ１０は、通信部１１と、制御部１２とを含んで構成される。通信部１１は、端末１、ＤＮＳサーバ２０、等との間で情報の送受信を行う通信インタフェース等により構成される。制御部１２は、通信部１１からＳＩＰリクエストを受信し、生成したＤＮＳクエリパケットを通信部１１へと送信する。また、制御部１２は、通信部１１からＤＮＳアンサパケットを受信し、生成したＳＩＰリクエストを通信部１１へと送信する。
【００４７】
更に、通信部１１は、ＳＩＰ信号通信部１１１と、ＤＮＳ信号通信部１１２とを含んで構成される。また、制御部１２は、ＳＩＰ信号解析部１２１と、ＤＮＳ信号生成部１２２と、ＤＮＳ信号解析部１２３と、ＳＩＰ信号生成部１２４とを含んで構成される。
【００４８】
ＳＩＰ信号通信部１１１は、発信元端末（例えば、０３−９９９９帯の端末１ａ）から着信先端末（例えば、０４２２−５９帯の端末１ｂ）への「接続要求メッセージ（ＳＩＰリクエスト）」（図１において、「接続要求」と記載する。）を受信する。Request-URIに格納される実データ（１６進数）は、例えば、“2b3831343232353939393939”である（図２（ａ）参照）。
【００４９】
また、ＳＩＰ信号通信部１１１は、接続先情報に示される着信先端末が自ＩＰ網に収容されている場合、接続先情報に示される着信先端末へとＳＩＰリクエストを送信し、接続先情報に示される着信先端末が自ＩＰ網に収容されていない場合、接続先情報に示される他ＩＰ網へとＳＩＰリクエストを転送する。つまり、ＳＩＰ信号通信部１１１は、着信先が自ＩＰ網である場合、自ＩＰ網に収容される着信先端末（例えば、０４２２−５９帯の端末１ｂ）に呼接続し、着信先が他ＩＰ網である場合、ＳＩＰ信号を転送する。
【００５０】
ＳＩＰ信号解析部１２１は、ＳＩＰリクエストに基づいて、着信先端末の電話番号を取得する。例えば、Request-URIに格納される実データが、“2b3831343232353939393939”である場合、ＳＩＰ信号解析部１２１は、当該実データに基づいて、着信先端末の電話番号「０４２２−５９−９９９９」を取得する。
【００５１】
ＤＮＳ信号生成部１２２は、着信先端末の電話番号「０４２２−５９−９９９９」をラベル形式に変換し、当該電話番号がラベル形式で表されたＤＮＳクエリパケットを生成する。Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥに格納される実データ（１６進数）は、例えば、“8b38313432323539393939390865313634656e756d036e657400”である（図２（ｂ）参照）。
【００５２】
具体的には、ＤＮＳ信号生成部１２２は、接続先情報問合せメッセージ（ＤＮＳクエリ）における、質問部（Ｑｕｅｓｔｉｏｎ部）のＱＮＡＭＥを、以下のような手順で生成する。
（Ａ）発信元端末から受信した接続要求メッセージ（ＳＩＰリクエスト）に含まれる着信先端末の電話番号（例えば、０４２２−５９−９９９９）のE.164番号（“＋81-4-2259-9999”）から先頭の“＋”、及びvisual-separatorを除外して、“81422599999”とする。
（Ｂ）末尾に“.e164enum.net.”を付与して、着信先端末の電話番号をラベル形式に変換し、“81422599999.e164enum.net.”とする。つまり、着信先端末の電話番号「０４２２−５９−９９９９」を、１つのラベル“81422599999”とする。
（Ｃ）“81422599999”を、「ラベルのオクテット数＋その数だけのオクテット」で表す際、ラベルのオクテット数を示すオクテットの先頭ビットを、例えば、“10”（着信先端末の電話番号を表すオクテット数）にする。更に、“.e164enum.net.”を、従来と同様に、［RFC 1035］の4.1.2節（Question selection format）に従って、「各ラベルのオクテット数＋その数だけのオクテット」の連続で表す。つまり、実データ（１６進数）“8b38313432323539393939390865313634656e756d036e657400”を生成する（図２（ｂ）参照）。
例えば、“81422599999”において、“81422599999”を１つのラベルとして先頭ビットを適宜設定し、“81422599999”全体を１６進数に変換すると、実データは、「8b3831343232353939393939」となる（図２（ｂ）のＸ参照）。
なお、ラベルのオクテット数を示すオクテットの先頭ビットは、着信先端末の電話番号を表すオクテット数に限定されるものではなく、他の数字の組み合わせであっても良いし、着信先端末の電話番号がラベル形式のＤＮＳパケットを利用するクライアントのリスト、等であっても良い。
【００５３】
ＤＮＳ信号通信部１１２は、ＤＮＳサーバ２０へと、「接続先情報問合せメッセージ（ＤＮＳクエリ）」（図１において、「接続先情報問合せ」と記載する。）を送信する。また、ＤＮＳ信号通信部１１２は、ＤＮＳサーバ２０から、「接続先情報問合せ応答メッセージ（ＤＮＳアンサ）」（図１において、「接続先情報問合せ応答」と記載する。）を受信する。
【００５４】
ＤＮＳ信号解析部１２３は、ＤＮＳアンサに基づいて、着信先端末の電話番号に対応する接続先情報を取得する。例えば、着信先端末の電話番号が「０４２２−５９−９９９９」である場合、接続先情報問合せ応答メッセージ（ＤＮＳアンサ）における、回答部（Ａｎｓｗｅｒ部）のＲＥＧＥＸＰは、“!^.*$!sip:+81422599999@exapmle2.ne.jp;user=phone!”となる。従って、この場合、ＤＮＳ信号解析部１２３は、着信先端末の電話番号に対応する接続先情報として、ＲＥＧＥＸＰ（“!^.*$!sip:+81422599999@exapmle2.ne.jp;user=phone!”）を取得する。
【００５５】
ＳＩＰ信号生成部１２４は、取得したＲＥＧＥＸＰ（“!^.*$!sip:+81422599999@exapmle2.ne.jp;user=phone!”）を、ＳＩＰリクエストにおけるRequest-URIに、実データ（１６進数）“2b3831343232353939393939”、参考情報“+81422599999”として格納する（図２（ａ）参照）。そして、ＳＩＰ信号生成部１２４は、接続先情報に応じて、ＳＩＰ信号を変更する。例えば、ＳＩＰ信号生成部１２４は、ＳＩＰリクエストに格納されたＲＥＧＥＸＰに示される着信先端末が自ＩＰ網に収容されている場合、当該着信先端末に呼接続するためのＳＩＰ信号を生成する。また、例えば、ＳＩＰ信号生成部１２４は、ＳＩＰリクエストに格納されたＲＥＧＥＸＰに示される着信先端末が他ＩＰ網に収容されている場合、他ＩＰ網へと転送するためのＳＩＰ信号を生成する。
【００５６】
本実施形態に係るＳＩＰサーバ１０は、ＤＮＳクエリパケットを生成する際、着信先端末の電話番号を１つのラベルとし、当該ラベルのオクテット数を示すオクテットの先頭ビットを、例えば、着信先端末の電話番号を表すオクテット数として、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットを生成する。着信先端末の電話番号がラベル形式のＤＮＳクエリパケットは、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットと比較して、パケットサイズが小さい。このため、ＤＮＳパケット処理システム１００において、ＳＩＰサーバにかかる処理負荷を小さくすることができる。
【００５７】
≪ＤＮＳサーバ２０≫
図１及び図３を参照して、本実施形態に係るＤＮＳサーバ２０について説明する。図３は、記憶部２３に格納されるデータ２３１の一例である。
【００５８】
ＤＮＳサーバ２０は、通信部２１と、制御部２２と、記憶部２３とを含んで構成される。通信部２１は、ＳＩＰサーバ１０、等との間で情報の送受信を行う通信インタフェース等により構成される。制御部２２は、通信部２１からＤＮＳクエリパケットを受信し、生成したＤＮＳアンサパケットを通信部２１へと送信する。記憶部２３は、ハードディスクやフラッシュメモリ等の記憶手段からなり、各種データ２３１が格納される。
【００５９】
更に、通信部２１は、ＤＮＳ信号通信部２１１を含んで構成される。また、制御部２２は、ＤＮＳ信号解析部２２１と、ＤＮＳ信号生成部２２２と、表記形式変換機能部２２３と、フルサービスリゾルバ機能部２２４とを含んで構成される。
【００６０】
ＤＮＳ信号通信部２１１は、ＳＩＰサーバ１０から、「接続先情報問合せメッセージ（ＤＮＳクエリ）」（図１において、「接続先情報問合せ」と記載する。）を受信する。また、ＤＮＳ信号通信部２１１は、ＳＩＰサーバ１０へと、「接続先情報問合せ応答メッセージ（ＤＮＳアンサ）」（図１において、「接続先情報問合せ応答」と記載する。）を送信する。
【００６１】
記憶部２３は、電話番号２３１１、ドメイン２３１２、ＮＡＰＴＲレコード２３１３、ＮＳレコード２３１４（図３参照）、ＤＮＳサーバ２０にて実行されるプログラム、等を記憶する。また、記憶部２３は、制御部２２がプログラムを実行するための、作業用記憶領域として用いられる。
【００６２】
例えば、着信先端末の電話番号が「０４２２−５９−９９９９」である場合、記憶部２３は、電話番号２３１１として、“81422599999”を、ドメイン２３１２として、“9.9.9.9.9.5.2.2.4.1.8.e164enum.net.”を、ＮＡＰＴＲレコード２３１３として、“100 10 u E2U+sip !^.*$!sip:+81422599999@exapmle2.ne.jp;user=phone! .”を、或いは、電話番号２３１１として、“81422599999”を、ドメイン２３１２として、“9.9.9.9.9.5.2.2.4.1.8.e164enum.net.”を、ＮＡＰＴＲレコード２３１３として、“100 20 u E2U+pstn:sip !^.*$!sip:+81422599999;npdi;rn=+81422610051@exapmle2.ne.jp;user=phone! .”を、記憶する。
【００６３】
また、例えば、着信先端末の電話番号が「０４２２−５９−００００」である場合、記憶部２３は、電話番号２３１１として、“81422590000”を、ドメイン２３１２として、“0.0.0.0.9.5.2.2.4.1.8.e164enum.net.”を、ＮＳレコード２３１４として、“ns1.example3.ne.jp.”を、或いは、電話番号２３１１として、“81422590000”を、ドメイン２３１２として、“0.0.0.0.9.5.2.2.4.1.8.e164enum.net.”を、ＮＳレコード２３１４として、“ns2.example3.ne.jp.”を、記憶する。
【００６４】
本実施形態に係るＤＮＳサーバ２０に搭載される記憶部２３には、従来のＤＮＳサーバに搭載される記憶部には格納されていなかった、人間が視認し易い電話番号２３１１がデータとして格納される。これにより、ＤＮＳサーバ２０は、着信先端末の電話番号のラベル（例えば、“81422599999”）をキーとして、当該データを参照することができる。よって、ＤＮＳパケット処理システム１００における利便性を高めることができる。
【００６５】
ＤＮＳ信号解析部２２１は、記憶部２３に格納されるデータ２３１（例えば、電話番号２３１１、ドメイン２３１２、ＮＡＰＴＲレコード２３１３、ＮＳレコード２３１４、等）を参照して、ＤＮＳクエリを解析する。
【００６６】
まず、ＤＮＳ信号解析部２２１は、ＤＮＳ信号通信部２１１から受信したＤＮＳクエリパケットが、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットであるか否かを判定する。例えば、ＤＮＳ信号解析部２２１は、Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥにおいて、ラベルのオクテット数を示すオクテットの先頭ビットが“10”であれば、「着信先端末の電話番号を表すオクテット数」であると判定し、ＤＮＳ信号通信部２１１から受信したＤＮＳクエリパケットが、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットであると判定する。また、例えば、ＤＮＳ信号解析部２２１は、Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥにおいて、ラベルのオクテット数を示すオクテットの先頭ビットが“10”でなければ、「着信先端末の電話番号を表すオクテット数」でないと判定し、ＤＮＳ信号通信部２１１から受信したＤＮＳクエリパケットが、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットであると判定する。
【００６７】
なお、ＤＮＳ信号解析部２２１は、ラベルのオクテット数を示すオクテットの先頭ビットが“10”であるか否かに基づいて、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットであるか、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットであるか、を判定するのみならず、ラベルのオクテット数を示すオクテットの先頭ビットが、他の数字の組み合わせであるか否かに基づいて、或いは、着信先端末の電話番号がラベル形式のＤＮＳパケットを利用するクライアントのリストであるか否かに基づいて、当該判定を行うことも可能である。
【００６８】
着信先端末の電話番号がラベル形式のＤＮＳクエリパケットである場合、ＤＮＳ信号解析部２２１は、当該ＤＮＳクエリパケットから電話番号を抽出して、記憶部２３に格納されるデータ２３１の中の電話番号２３１１を参照する。一方、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットである場合、ＤＮＳ信号解析部２２１は、当該ＤＮＳクエリパケットからドメインを抽出して、記憶部２３に格納されるデータ２３１の中のドメイン２３１２を参照する。
【００６９】
そして、ＤＮＳ信号解析部２２１は、着信先端末の電話番号に対応する接続先情報の問合せが解決できたか否かを判定する。着信先端末の電話番号がラベル形式のＤＮＳクエリパケットである場合、ＤＮＳ信号解析部２２１は、記憶部２３に格納される電話番号２３１１を参照した結果、抽出した電話番号が、当該電話番号２３１１の中に存在すれば、着信先端末の電話番号に対応する接続先情報の問合せが解決できたと判定し、抽出した電話番号が、当該電話番号２３１１の中に存在しなければ、着信先端末の電話番号に対応する接続先情報の問合せが解決できていないと判定する。また、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットである場合、ＤＮＳ信号解析部２２１は、記憶部２３に格納されるドメイン２３１２を参照した結果、抽出したドメインが、当該ドメイン２３１２の中に存在すれば、着信先端末の電話番号に対応する接続先情報の問合せが解決できたと判定し、抽出したドメインが、当該ドメイン２３１２の中に存在しなければ、着信先端末の電話番号に対応する接続先情報の問合せが解決できていないと判定する。
【００７０】
即ち、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットである場合、ＤＮＳ信号解析部２２１は、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットから抽出した電話番号と一致する電話番号を、記憶部２３に格納される電話番号２３１１の中から見つけられれば、着信先端末の電話番号に対応する接続先情報の問合せが解決できたと判定し、解決できたという判定結果をＤＮＳ信号生成部２２２へと送信する。一方で、ＤＮＳ信号解析部２２１は、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットから抽出した電話番号と一致する電話番号を、記憶部２３に格納される電話番号２３１１の中から見つけられなければ、着信先端末の電話番号に対応する接続先情報の問合せが解決できていないと判定し、解決できていないという判定結果を表記形式変換機能部２２３へと送信する。
【００７１】
また、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットである場合、ＤＮＳ信号解析部２２１は、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットから抽出したドメインと一致するドメインを、記憶部２３に格納されるドメイン２３１２の中から見つけられれば、着信先端末の電話番号に対応する接続先情報の問合せが解決できたと判定し、解決できたという判定結果をＤＮＳ信号生成部２２２へと送信する。一方で、ＤＮＳ信号解析部２２１は、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットから抽出したドメインと一致するドメインを、記憶部２３に格納されるドメイン２３１２の中から見つけられなければ、着信先端末の電話番号に対応する接続先情報の問合せが解決できていないと判定し、解決できていないという判定結果をフルサービスリゾルバ機能部２２４へと送信する。
【００７２】
ＤＮＳ信号生成部２２２は、ＤＮＳ信号解析部２２１から受信した、着信先端末の電話番号に対応する接続先情報の問合せが解決できたという判定結果に基づいて、ＤＮＳアンサパケットを生成する。例えば、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットである場合であって、ＤＮＳ信号解析部２２１から問合せが解決できたという判定結果を受信すると、ＤＮＳ信号生成部２２２は、着信先端末の電話番号がラベル形式のＤＮＳアンサパケットを生成する。また、例えば、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットである場合であって、ＤＮＳ信号解析部２２１から問合せが解決できたという判定結果を受信すると、ＤＮＳ信号生成部２２２は、着信先端末の電話番号がドメイン形式のＤＮＳアンサパケットを生成する。
【００７３】
なお、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットにおける、Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥにおける実データと、着信先端末の電話番号がラベル形式のＤＮＳアンサパケットにおける、Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥにおける実データとは、一致する（例えば、“8b38313432323539393939390865313634656e756d036e657400”）。また、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットにおける、Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥにおける実データと、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットにおける、Ｑｕｅｓｔｉｏｎ部のＱＮＡＭＥにおける実データとは、一致する（例えば、“013901390139013901390135013201320134013101380865313634656e756d036e657400”）。
【００７４】
表記形式変換機能部２２３は、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットである場合であって、ＤＮＳ信号解析部２２１から問合せが解決できていないという判定結果を受信すると、着信先端末の電話番号を、ラベル形式の電話番号（例えば、“81422599999.e164enum.net.”）からドメイン形式の電話番号（例えば、“8.1.4.2.2.5.9.9.9.9.9.e164enum.net.”）へと変換する。
【００７５】
フルサービスリゾルバ機能部２２４は、表記形式変換機能部２２３から変換されたドメイン形式の電話番号（例えば、“8.1.4.2.2.5.9.9.9.9.9.e164enum.net.”）を受信すると、当該ドメイン形式の電話番号に基づいて、他のＤＮＳサーバに対して、着信先端末の電話番号に対応する接続先情報の問合せを行う。
【００７６】
一方、フルサービスリゾルバ機能部２２４は、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットである場合であって、ＤＮＳ信号解析部２２１から問合せが解決できていないという判定結果を受信すると、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットに基づいて、他のＤＮＳサーバに対して、着信先端末の電話番号に対応する接続先情報の問合せを行う。
【００７７】
つまり、フルサービスリゾルバ機能部２２４は、ＤＮＳ信号解析部２２１が自身の記憶部２３に格納されるドメイン２３１２を参照した結果、着信先端末の電話番号がドメイン形式のＤＮＳクエリパケットから抽出したドメインが、自身の記憶部２３に格納されていない場合に、他のＤＮＳサーバに対して、反復問合わせを行う。そして、フルサービスリゾルバ機能部２２４は、該当するドメインの情報が格納されている他のＤＮＳサーバから、当該問合わせに対応するドメインの情報を取得し、着信先端末の電話番号に対応する接続先情報の問合せを解決する。これにより、着信先端末の電話番号に対応する接続先情報の問合せの解決を行う他のＤＮＳサーバが、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに対応していない場合であっても、問合せの解決を実施できる。なお、フルサービスリゾルバ機能部２２４は、公知のＤＮＳサーバに搭載される構成と同様の構成を有する。
【００７８】
本実施形態に係るＤＮＳサーバ２０は、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットを受信し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、着信先端末の電話番号がラベル形式のＤＮＳアンサパケットを生成する。着信先端末の電話番号がラベル形式のＤＮＳアンサパケットは、着信先端末の電話番号がドメイン形式のＤＮＳアンサパケットと比較して、パケットサイズが小さい。このため、ＤＮＳパケットのパケットサイズを小さくするＤＮＳパケット処理システムを実現できる。
【００７９】
なお、ＤＮＳパケット処理システム１００において、ＤＮＳサーバ２０を１つの装置で構成せずに、ＤＮＳ権威サーバとＤＮＳキャッシュサーバとを別装置とする構成とする場合には、ＤＮＳ権威サーバ、本実施形態に係るＳＩＰサーバ１０の機能を持たせたＤＮＳキャッシュサーバ、それぞれにかかる処理負荷を小さくすることができる。
【００８０】
本実施形態に係るＤＮＳパケット処理システム１００によれば、ＳＩＰサーバ１０が着信先端末の電話番号がラベル形式のＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、ＤＮＳサーバ２０が着信先端末の電話番号がラベル形式のＤＮＳアンサパケットを生成する。これにより、ＳＩＰサーバにかかる処理負荷を小さくするＤＮＳパケット処理システム１００を実現できる。また、ＳＩＰサーバにかかる処理負荷を小さくすることで、ＳＩＰサーバからの問合せに対するＤＮＳサーバの応答遅延等を抑制したＤＮＳパケット処理システム１００を実現できる。
【００８１】
≪ＳＩＰサーバ１０の動作≫
次に、図４を参照して、本実施形態に係るＳＩＰサーバ１０の動作について説明する。
【００８２】
ステップＳ１０１において、ＳＩＰ信号通信部１１１は、発信元端末（例えば、０３−９９９９帯の端末）から、ＳＩＰリクエストを受信する。
【００８３】
ステップＳ１０２において、ＳＩＰ信号解析部１２１は、ＳＩＰリクエストに基づいて、着信先端末（例えば、０４２２−５９帯の端末）の電話番号を取得する。
【００８４】
ステップＳ１０３において、ＤＮＳ信号生成部１２２は、電話番号がラベル形式のＤＮＳクエリパケットを生成する。
【００８５】
ステップＳ１０４において、ＤＮＳ信号通信部１１２は、ＤＮＳサーバ２０へと、ＤＮＳクエリを送信する。
【００８６】
ステップＳ１０５において、ＤＮＳ信号通信部１１２は、ＤＮＳサーバ２０から、ＤＮＳアンサを受信する。
【００８７】
ステップＳ１０６において、ＤＮＳ信号解析部１２３は、ＤＮＳアンサに基づいて、Ａｎｓｗｅｒ部のＲＥＧＥＸＰを取得する。
【００８８】
ステップＳ１０７において、ＳＩＰ信号生成部１２４は、ＲＥＧＥＸＰを、ＳＩＰリクエストのRequest-URIに格納して、着信先に応じてＳＩＰ信号を変更する。
【００８９】
ステップＳ１０８において、ＳＩＰ信号通信部１１１は、着信先端末（例えば、０４２２−５９帯の端末）へとＳＩＰリクエストを送信する。
【００９０】
上述のように、ＳＩＰサーバ１０は、着信先端末の電話番号がラベル形式で表されたパケットサイズの小さいＤＮＳクエリパケットを生成する。これにより、ＳＩＰサーバ１０がＤＮＳクエリパケットを生成する際に、ＳＩＰサーバ１０にかかる処理負荷を小さくすることができる。
【００９１】
≪ＤＮＳサーバ２０の動作≫
次に、図５を参照して、本実施形態に係るＤＮＳサーバ２０の動作について説明する。
【００９２】
ステップＳ２０１において、ＤＮＳ信号通信部２１１は、ＳＩＰサーバ１０から、ＤＮＳクエリを受信する。
【００９３】
ステップＳ２０２において、ＤＮＳ信号解析部２２１は、ＤＮＳクエリに基づいて、電話番号がラベル形式であるか否かを判定する。ＤＮＳ信号解析部２２１は、電話番号がラベル形式であると判定する場合（ステップＳ２０２→Ｙｅｓ）、ステップＳ２０３の処理に進む。一方、ＤＮＳ信号解析部２２１は、電話番号がラベル形式でないと判定する場合（ステップＳ２０２→Ｎｏ）、ステップＳ２０７の処理に進む。
【００９４】
ステップＳ２０３において、ＤＮＳ信号解析部２２１は、電話番号がラベル形式のＤＮＳクエリパケットから電話番号を抽出して、記憶部２３に格納されるデータ２３１を参照する。
【００９５】
ステップＳ２０４において、ＤＮＳ信号解析部２２１は、問合わせが解決できたか否かを判定する。ＤＮＳ信号解析部２２１は、問合わせが解決できたと判定する場合（ステップＳ２０４→Ｙｅｓ）、ステップＳ２０５の処理に進む。一方、ＤＮＳ信号解析部２２１は、問合わせが解決できていないと判定する場合（ステップＳ２０４→Ｎｏ）、ステップＳ２１１の処理に進む。
【００９６】
ステップＳ２０５において、ＤＮＳ信号生成部２２２は、電話番号がラベル形式のＤＮＳアンサパケットを生成する。
【００９７】
ステップＳ２０６において、ＤＮＳ信号通信部２１１は、ＳＩＰサーバ１０へと、ＤＮＳアンサを送信する。
【００９８】
ステップＳ２０７において、ＤＮＳ信号解析部２２１は、電話番号がドメイン形式のＤＮＳクエリパケットからドメインを抽出して、記憶部２３に格納されるデータ２３１を参照する。
【００９９】
ステップＳ２０８において、ＤＮＳ信号解析部２２１は、問合わせが解決できたか否かを判定する。ＤＮＳ信号解析部２２１は、問合わせが解決できたと判定する場合（ステップＳ２０８→Ｙｅｓ）、ステップＳ２０９の処理に進む。一方、ＤＮＳ信号解析部２２１は、問合わせが解決できていないと判定する場合（ステップＳ２０８→Ｎｏ）、ステップＳ２１０の処理に進む。
【０１００】
ステップＳ２０９において、ＤＮＳ信号生成部２２２は、電話番号がドメイン形式のＤＮＳアンサパケットを生成する。
【０１０１】
ステップＳ２１０において、フルサービスリゾルバ機能部２２４は、他のＤＮＳサーバに対して、問合わせの解決を行う。
【０１０２】
ステップＳ２１１において、表記形式変換機能部２２３は、電話番号を、ラベル形式からドメイン形式へと変換する。
【０１０３】
ステップＳ２１２において、フルサービスリゾルバ機能部２２４は、他のＤＮＳサーバに対して、問合わせの解決を行う。
【０１０４】
上述のように、ＤＮＳサーバ２０は、電話番号がラベル形式のＤＮＳクエリパケットを受信して問合せが解決できた場合、電話番号がラベル形式のＤＮＳアンサパケットを生成する。これにより、ＤＮＳパケット処理システム１００におけるパケットサイズを小さくすることができる。
【０１０５】
＜変形例１＞
次に、本実施形態に係るＤＮＳパケット処理システムの変形例について説明する。図６は、本実施形態の変形例に係るＤＮＳパケット処理システム１００ａの全体構成を示す図である。
【０１０６】
図６に示すように、変形例に係るＤＮＳパケット処理システム１００ａは、通信事業者のネットワークである自ＩＰ網に、複数の発信元端末１ａ及び複数の着信先端末１ｂを収容するＤＮＳクライアント３０と、ＤＮＳクライアント３０から着信先端末の電話番号に対応する接続先情報を受け付けるＤＮＳサーバ２０とを含んで構成される。
【０１０７】
ＤＮＳクライアント３０は、ＤＮＳ信号通信部３１と、ＤＮＳ信号生成部３２とを含んで構成される。図１に示すＤＮＳパケット処理システム１００と、図６に示すＤＮＳパケット処理システム１００ａとで異なる点は、ＤＮＳパケット処理システム１００に搭載されるＳＩＰサーバ１０が、ＳＩＰ信号通信部１１１、ＤＮＳ信号通信部１１２、ＳＩＰ信号解析部１２１、ＤＮＳ信号生成部１２２、ＤＮＳ信号解析部１２３、ＳＩＰ信号生成部１２４を含んで構成されるのに対して、ＤＮＳパケット処理システム１００ａに搭載されるＤＮＳクライアント３０は、少なくとも、ＤＮＳ信号通信部３１、ＤＮＳ信号生成部３２を含んで構成されていれば良い点である。
【０１０８】
なお、ＤＮＳパケット処理システム１００ａにおいて、ＤＮＳサーバ２０を１つの装置で構成せずに、ＤＮＳ権威サーバとＤＮＳキャッシュサーバとを別装置とする構成としても良い。この場合、ＤＮＳキャッシュサーバにも本実施形態に係るＤＮＳクライアント３０の機能を持たせることが可能である。
【０１０９】
ＤＮＳ信号通信部３１は、ＤＮＳサーバ２０へと、「接続先情報問合せメッセージ（ＤＮＳクエリ）」（図６において、「接続先情報問合せ」と記載する。）を送信する。また、ＤＮＳ信号通信部３１は、ＤＮＳサーバ２０から、「接続先情報問合せ応答メッセージ（ＤＮＳアンサ）」（図６において、「接続先情報問合せ応答」と記載する。）を受信する。
【０１１０】
ＤＮＳ信号生成部３２は、着信先端末の電話番号「０４２２−５９−９９９９」をラベル形式に変換し、当該電話番号がラベル形式で表されたＤＮＳクエリパケットを生成する。
【０１１１】
具体的には、ＤＮＳ信号生成部３２は、接続先情報問合せメッセージ（ＤＮＳクエリ）における、質問部（Ｑｕｅｓｔｉｏｎ部）のＱＮＡＭＥを、以下のような手順で生成する。
（Ａ）着信先端末の電話番号（例えば、０４２２−５９−９９９９）のE.164番号（“＋81-4-2259-9999”）から先頭の“＋”、及びvisual-separatorを除外して、“81422599999”とする。
（Ｂ）末尾に“.e164enum.net.”を付与して、着信先端末の電話番号をラベル形式に変換し、“81422599999.e164enum.net.”とする。つまり、着信先端末の電話番号「０４２２−５９−９９９９」を、１つのラベル“81422599999”とする。
（Ｃ）“81422599999”を、「ラベルのオクテット数＋その数だけのオクテット」で表す際、ラベルのオクテット数を示すオクテットの先頭ビットを、例えば、“10”（着信先端末の電話番号を表すオクテット数）にする。更に、“.e164enum.net.”を、従来と同様に、［RFC 1035］の4.1.2節（Question selection format）に従って、「各ラベルのオクテット数＋その数だけのオクテット」の連続で表す。つまり、実データ（１６進数）“8b38313432323539393939390865313634656e756d036e657400”を生成する（図２（ｂ）参照）。
【０１１２】
変形例に係るＤＮＳパケット処理システム１００ａによれば、ＤＮＳクライアント３０が着信先端末の電話番号がラベル形式のＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、ＤＮＳサーバ２０が着信先端末の電話番号がラベル形式のＤＮＳアンサパケットを生成する。これにより、ＳＩＰサーバにかかる処理負荷を小さくするＤＮＳパケット処理システム１００ａを実現できる。また、ＤＮＳパケットのパケットサイズを小さくするＤＮＳパケット処理システム１００ａを実現できる。
【０１１３】
なお、ＤＮＳパケット処理システム１００ａは、ＥＮＵＭに適用されるだけでなく、ＩＰｖ６アドレスの逆引き等に適用することも可能である。ＤＮＳパケット処理システム１００ａをＩＰｖ６アドレスの逆引きに適用する場合、記憶部２３に格納されるデータ２３１は、ＩＰｖ６アドレス表記となる。
【０１１４】
＜第２実施形態＞
≪ＤＮＳパケット処理システムの構成≫
次に、本実施形態に係るＤＮＳパケット処理システムについて説明する。図７は、本実施形態に係るＤＮＳパケット処理システム２００の全体構成を示す図である。なお、第２実施形態において、上述の第１実施形態と、共通する部分については、重複した説明を省略する。
【０１１５】
図７に示すように、本実施形態に係るＤＮＳパケット処理システム２００は、通信事業者のネットワークである自ＩＰ網に、複数の発信元端末１ａ及び複数の着信先端末１ｂを収容するＳＩＰサーバ１０と、ＳＩＰサーバ１０から着信先端末の電話番号に対応する接続先情報の問合せを受け付ける複数のＤＮＳサーバ２０＿１（第１のＤＮＳサーバ）、ＤＮＳサーバ２０＿２（第２のＤＮＳサーバ）とを含んで構成される。
【０１１６】
本実施形態に係るＤＮＳパケット処理システム２００は、ＳＩＰサーバ１０が、パケットサイズの小さいＤＮＳクエリパケットを生成することを特徴とする。また、ＤＮＳサーバ２０＿１，２０＿２が、人間が視認し易い電話番号をデータとして記憶し、当該データを参照して、ＤＮＳアンサパケットを生成、或いは反復問合せを行うことを特徴とする。更に、複数のＤＮＳサーバの全てが、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに対応し、問合せの解決を行うことを特徴とする。
【０１１７】
また、本実施形態に係るＤＮＳパケット処理システム２００は、ＤＮＳサーバ２０＿１、ＤＮＳサーバ２０＿２に、表記形式変換機能部が搭載されていないことを特徴する。ＤＮＳサーバ２０＿１に搭載されるフルサービスリゾルバ機能部２２４＿１は、着信先端末の電話番号に対応する接続先情報の問合せが解決できていない場合、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに基づいて、ＤＮＳサーバ２０＿２に対して、問合せを行う。
【０１１８】
つまり、ＤＮＳサーバ２０＿１、ＤＮＳサーバ２０＿２のどちらも、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットから電話番号を抽出して、記憶部２３に格納されるデータ２３１の中の電話番号２３１１を参照して、着信先端末の電話番号に対応する接続先情報の問合せを解決することができる。このため、ＤＮＳサーバ２０＿１、ＤＮＳサーバ２０＿２は、着信先端末の電話番号を、ラベル形式の電話番号（例えば、“81422599999.e164enum.net.”）からドメイン形式の電話番号（例えば、“8.1.4.2.2.5.9.9.9.9.9.e164enum.net.”）へと変換する表記形式変換機能部を必要とすることなく、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに基づいて、問合せの解決を行うことができる。
【０１１９】
第２実施形態に係るＳＩＰサーバ１０の構成は、第１実施形態に係るＳＩＰサーバ１０の構成と同じである。
【０１２０】
なお、図７では、ＳＩＰサーバ１０が１台、ＤＮＳサーバ２０（２０＿１、２０＿２）が２台の場合を一例に挙げて説明しているが、これらのサーバの台数は特に限定されるものではない。また、ＤＮＳパケット処理システム２００において、ＤＮＳサーバ２０（２０＿１、２０＿２）を１つの装置で構成せずに、ＤＮＳ権威サーバとＤＮＳキャッシュサーバとを別装置とする構成としても良い。この場合、ＤＮＳキャッシュサーバにも本実施形態に係るＳＩＰサーバ１０の機能を持たせることが可能である。
【０１２１】
≪ＳＩＰサーバ１０の動作≫
次に、図８を参照して、本実施形態に係るＳＩＰサーバ１０の動作について説明する。
【０１２２】
ステップＳ１００１において、ＳＩＰ信号通信部１１１は、発信元端末（例えば、０３−９９９９帯の端末）から、ＳＩＰリクエストを受信する。
【０１２３】
ステップＳ１００２において、ＳＩＰ信号解析部１２１は、ＳＩＰリクエストに基づいて、着信先端末（例えば、０４２２−５９帯の端末）の電話番号を取得する。
【０１２４】
ステップＳ１００３において、ＤＮＳ信号生成部１２２は、電話番号がラベル形式のＤＮＳクエリパケットを生成する。
【０１２５】
ステップＳ１００４において、ＤＮＳ信号通信部１１２は、ＤＮＳサーバ２０へと、ＤＮＳクエリを送信する。
【０１２６】
ステップＳ１００５において、ＤＮＳ信号通信部１１２は、ＤＮＳサーバ２０から、ＤＮＳアンサを受信する。
【０１２７】
ステップＳ１００６において、ＤＮＳ信号解析部１２３は、ＤＮＳアンサに基づいて、Ａｎｓｗｅｒ部のＲＥＧＥＸＰを取得する。
【０１２８】
ステップＳ１００７において、ＳＩＰ信号生成部１２４は、ＲＥＧＥＸＰを、ＳＩＰリクエストのRequest-URIに格納して、着信先に応じてＳＩＰ信号を変更する。
【０１２９】
ステップＳ１００８において、ＳＩＰ信号通信部１１１は、ＳＩＰ信号通信部１１１は、着信先端末（例えば、０４２２−５９帯の端末）へとＳＩＰリクエストを送信する。
【０１３０】
上述のように、ＳＩＰサーバ１０は、着信先端末の電話番号がラベル形式で表されたパケットサイズの小さいＤＮＳクエリパケットを生成する。これにより、ＳＩＰサーバ１０がＤＮＳクエリパケットを生成する際に、ＳＩＰサーバ１０にかかる処理負荷を小さくすることができる。
【０１３１】
≪ＤＮＳサーバ２０＿１の動作≫
次に、図９を参照して、本実施形態に係るＤＮＳサーバ２０＿１の動作について説明する。
【０１３２】
ステップＳ２００１において、ＤＮＳ信号通信部２１１＿１は、ＳＩＰサーバ１０から、ＤＮＳクエリを受信する。
【０１３３】
ステップＳ２００２において、ＤＮＳ信号解析部２２１＿１は、電話番号がラベル形式のＤＮＳクエリパケットに基づいて、電話番号を抽出し、記憶部２３に格納されるデータ２３１を参照する。
【０１３４】
ステップＳ２００３において、ＤＮＳ信号解析部２２１＿１は、問い合わせが解決できたか否かを判定する。ＤＮＳ信号解析部２２１＿１は、問い合わせが解決できたと判定する場合（ステップＳ２００３→Ｙｅｓ）、ステップＳ２００４の処理に進む。一方、ＤＮＳ信号解析部２２１＿１は、問い合わせが解決できていないと判定する場合（ステップＳ２００３→Ｎｏ）、ステップＳ２００６の処理に進む。
【０１３５】
ステップＳ２００４において、ＤＮＳ信号生成部２２２＿１は、電話番号がラベル形式のＤＮＳアンサパケットを生成する。
【０１３６】
ステップＳ２００５において、ＤＮＳ信号通信部２１１＿１は、ＳＩＰサーバ１０へと、ＤＮＳアンサを送信する。
【０１３７】
ステップＳ２００６において、フルサービスリゾルバ機能部２２４＿１は、ＤＮＳサーバ２０＿２に対して、問合わせの解決を行う。
【０１３８】
上述のように、ＤＮＳサーバ２０＿１は、電話番号がラベル形式のＤＮＳクエリパケットを受信し、問合せが解決できた場合、電話番号がラベル形式のＤＮＳアンサパケットを生成する。これにより、ＤＮＳパケット処理システム２００におけるパケットサイズを小さくすることができる。
【０１３９】
本実施形態に係るＤＮＳパケット処理システム２００によれば、ＳＩＰサーバ１０が着信先端末の電話番号がラベル形式のＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、ＤＮＳサーバ２０＿１が着信先端末の電話番号がラベル形式のＤＮＳアンサパケットを生成する。これにより、ＳＩＰサーバにかかる処理負荷を小さくするＤＮＳパケット処理システム２００を実現できる。また、ＤＮＳパケットのパケットサイズを小さくするＤＮＳパケット処理システム２００を実現できる。
【０１４０】
＜変形例２＞
次に、本実施形態に係るＤＮＳパケット処理システムの変形例について説明する。図１０は、本実施形態の変形例に係るＤＮＳパケット処理システム２００ａの全体構成を示す図である。
【０１４１】
図１０に示すように、変形例に係るＤＮＳパケット処理システム２００ａは、通信事業者のネットワークである自ＩＰ網に、複数の発信元端末１ａ及び複数の着信先端末１ｂを収容するＤＮＳクライアント３０と、ＤＮＳクライアント３０から着信先端末の電話番号に対応する接続先情報を受け付けるＤＮＳサーバ２０＿１、ＤＮＳサーバ２０＿２とを含んで構成される。
【０１４２】
ＤＮＳクライアント３０は、ＤＮＳ信号通信部３１と、ＤＮＳ信号生成部３２とを含んで構成される。図７に示すＤＮＳパケット処理システム２００と、図１０に示すＤＮＳパケット処理システム２００ａとで異なる点は、ＤＮＳパケット処理システム２００に搭載されるＳＩＰサーバ１０が、ＳＩＰ信号通信部１１１、ＤＮＳ信号通信部１１２、ＳＩＰ信号解析部１２１、ＤＮＳ信号生成部１２２、ＤＮＳ信号解析部１２３、ＳＩＰ信号生成部１２４を含んで構成されるのに対して、ＤＮＳパケット処理システム１００ａに搭載されるＤＮＳクライアント３０は、少なくとも、ＤＮＳ信号通信部３１、ＤＮＳ信号生成部３２を含んで構成されていれば良い点である。
【０１４３】
なお、ＤＮＳパケット処理システム２００ａにおいて、ＤＮＳサーバ２０を１つの装置で構成せずに、ＤＮＳ権威サーバとＤＮＳキャッシュサーバとを別装置とする構成としても良い。この場合、ＤＮＳキャッシュサーバにも本実施形態に係るＤＮＳクライアント３０の機能を持たせることが可能である。
【０１４４】
ＤＮＳ信号通信部３１は、ＤＮＳサーバ２０＿１へと、「接続先情報問合せメッセージ（ＤＮＳクエリ）」（図１０において、「接続先情報問合せ」と記載する。）を送信する。また、ＤＮＳ信号通信部３１は、ＤＮＳサーバ２０＿１から、「接続先情報問合せ応答メッセージ（ＤＮＳアンサ）」（図１０において、「接続先情報問合せ応答」と記載する。）を受信する。
【０１４５】
ＤＮＳ信号生成部３２は、着信先端末の電話番号「０４２２−５９−９９９９」をラベル形式に変換し、当該電話番号がラベル形式で表されたＤＮＳクエリパケットを生成する。
【０１４６】
具体的には、ＤＮＳ信号生成部３２は、接続先情報問合せメッセージ（ＤＮＳクエリ）における、質問部（Ｑｕｅｓｔｉｏｎ部）のＱＮＡＭＥを、以下のような手順で生成する。
（Ａ）着信先端末の電話番号（例えば、０４２２−５９−９９９９）のE.164番号（“＋81-4-2259-9999”）から先頭の“＋”、及びvisual-separatorを除外して、“81422599999”とする。
（Ｂ）末尾に“.e164enum.net.”を付与して、着信先端末の電話番号をラベル形式に変換し、“81422599999.e164enum.net.”とする。つまり、着信先端末の電話番号「０４２２−５９−９９９９」を、１つのラベル“81422599999”とする。
（Ｃ）“81422599999”を、「ラベルのオクテット数＋その数だけのオクテット」で表す際、ラベルのオクテット数を示すオクテットの先頭ビットを、例えば、“10”（着信先端末の電話番号を表すオクテット数）にする。更に、“.e164enum.net.”を、従来と同様に、［RFC 1035］の4.1.2節（Question selection format）に従って、「各ラベルのオクテット数＋その数だけのオクテット」の連続で表す。つまり、実データ（１６進数）“8b38313432323539393939390865313634656e756d036e657400”を生成する（図２（ｂ）参照）。
【０１４７】
変形例に係るＤＮＳパケット処理システム２００ａによれば、ＤＮＳクライアント３０が、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットを生成し、着信先端末の電話番号に対応する接続先情報の問合せが解決できた場合、ＤＮＳサーバ２０＿１が着信先端末の電話番号がラベル形式のＤＮＳアンサパケットを生成する。これにより、ＤＮＳクライアントにかかる処理負荷を小さくするＤＮＳパケット処理システム２００ａを実現できる。また、ＤＮＳパケットのパケットサイズを小さくするＤＮＳパケット処理システム２００ａを実現できる。
【０１４８】
また、ＤＮＳサーバ２０＿１、ＤＮＳサーバ２０＿２のどちらも、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットから電話番号を抽出して、記憶部２３に格納されるデータ２３１の中の電話番号２３１１を参照して、着信先端末の電話番号に対応する接続先情報の問合せを解決することができる。このため、ＤＮＳサーバ２０＿１、ＤＮＳサーバ２０＿２は、着信先端末の電話番号を、ラベル形式の電話番号からドメイン形式の電話番号へと変換する表記形式変換機能部を必要とすることなく、着信先端末の電話番号がラベル形式のＤＮＳクエリパケットに基づいて、問合せの解決を行うことができる。
【０１４９】
なお、ＤＮＳパケット処理システム２００ａは、ＥＮＵＭに適用されるだけでなく、ＩＰｖ６アドレスの逆引き等に適用することも可能である。ＤＮＳパケット処理システム２００ａをＩＰｖ６アドレスの逆引きに適用する場合、記憶部２３に格納されるデータ２３１は、ＩＰｖ６アドレス表記となる。
【符号の説明】
【０１５０】
１ａ    発信元端末
１ｂ    着信先端末
１０    ＳＩＰサーバ
２０    ＤＮＳサーバ
２３    記憶部
１００，１００ａ，２００，２００ａ  ＤＮＳパケット処理システム
１１１    ＳＩＰ信号通信部
１１２    ＤＮＳ信号通信部
１２１    ＳＩＰ信号解析部
１２２    ＤＮＳ信号生成部
１２３    ＤＮＳ信号解析部
１２４    ＳＩＰ信号生成部
２２１    ＤＮＳ信号解析部
２２２    ＤＮＳ信号生成部
２２３    表記形式変換機能部
２２４    フルサービスリゾルバ機能部
【図１】
2019029965.tif 000003
【図２】
2019029965.tif 000004
【図３】
2019029965.tif 000005
【図４】
2019029965.tif 000006
【図５】
2019029965.tif 000007
【図６】
2019029965.tif 000008
【図７】
2019029965.tif 000009
【図８】
2019029965.tif 000010
【図９】
2019029965.tif 000011
【図１０】
2019029965.tif 000012
【図１１】
2019029965.tif 000013
【図１２】
2019029965.tif 000014
【図１３】
2019029965.tif 000015