JP5175938B2

JP5175938B2 - 共有ｄｎｓドメインの処理方法

Info

Publication number: JP5175938B2
Application number: JP2010529894A
Authority: JP
Inventors: ヨナスファルケナ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-10-18
Filing date: 2007-10-18
Publication date: 2013-04-03
Anticipated expiration: 2027-10-18
Also published as: US20100217856A1; CA2702914A1; US8949398B2; HK1148140A1; JP2011501558A; EP2198591A4; EP2198591A1; CN101828376B; WO2009051529A1; CN101828376A

Description

本発明は概して共有DNSドメインの取り扱いのための方法及び装置に関し、特にはDNSドメイン名を２つ以上のＳＩＰドメインで共有可能とするための方法及び装置に関する。

ＩＭＳ（ＩＰマルチメディアサブシステム）は、実質上任意の下層ネットワーク技術を横断する、リアルタイムかつパケットベースの呼及びサービスに必要なシグナリング、配信、認証及び課金機能を提供する標準規格セットである。換言すれば、ＩＭＳは、次世代ＩＰサービスを固定及び移動体ネットワークの両方に効率的かつ迅速な実装するために適合され、固定及び移動体ネットワークの収斂を促進するであろうプラットフォームである。

セッション開始プロトコル(SIP)は、インターネット通話、マルチメディア配信及びマルチメディア会議を含む、一人以上の参加者が関与するセッションを生成、変更及び切断するための、トランスポート非依存かつテキストベースのアプリケーションレイヤ制御プロトコルである。SIPはVoIP用のシグナリングプロトコルとして広く用いられており、また、IMS用の第３世代パートナシッププロジェクト(3GPP)シグナリングプロトコルとしても承認されている。

3GPP IMSドメインネームシステム(DNS)において、ドメインは、ユーザがどのSIPドメインに属するかを特定するために用いられる。既知のアプリケーションにおいて、１つのDNSドメインは、１つのSIPドメイン（例えばIMSドメイン）によって表されることしかできなかった。そのような制限は、例えば、IMSベースのIPセントレックス／テレフォニー仮想プライベートネットワーク(VPN)技術に投資して、自身の通信ソリューションを外部委託している多国籍企業とって問題となりうる。この種のシナリオでは、ユーザが世界中に散らばっており、様々な地理的領域のユーザは通常、異なるIMSドメインを管理する異なるオペレータによって管理されている。

オペレータＡによって管理されるIMSドメイン”domain1.com”１００で、IMS関連サービスについての入来要求を処理するための、従来技術による簡易な方法を、図１とともに説明する。通常、IMSドメインの管理は図１に示すよりも多くのノード及びシグナリングを含むが、入来要求を処理するための一般的な手順の理解に必要ないノード及びシグナリングステップは、説明を簡単化するために省略されていることを理解されたい。

第１ステージ１：１において、例えば”user1@domain1.com”のようなURIを有する”user1”宛の要求が、IMSドメイン”domain1.com”の管理を受け持つオペレータであるオペレータＡの、インタロゲーティング呼セッション制御機能(I-CSCF)１０１に届く。要求を”user1”へルーティングできるようにするには、その要求のDNSドメイン名が正しく解決されなければならない。これは、次のステージ１：２において、オペレータＡのユーザデータベース、通常はホーム加入者サーバ(HSS)１０２に問い合わせることによって実現されてよい。HSSは、オペレータＡのIMSドメインの、全IMS関連加入者データ及びサービスデータに関する主データストレージである。HSSに保存される主データは、そのIMSドメインに登録された各ユーザについてのユーザプロファイルを含んでいる。ユーザプロファイルは、入来する要求をサービングCSCF(S-CSCF)及び終端ユーザエンティティへルーティングするためのユーザ情報を有している。ユーザプロファイルは恒久的にHSSに保存されるユーザ固有情報の集合であり、例えばbob.home@domain1.comであるSIP URIか、例えばtel:+46 8 123 456 67である電話URIであってよい、公開ユーザIDを含んでいる。

HSS１０２の問い合わせが成功すれば、ステージ１：３ａに示すように、要求はオペレータＡの関連S-CSCF１０３へルーティングされる。要求は、例えば、要求されたサービスを要求者へ提供するであろう不図示のアプリケーションサーバ(AS)のような意図された終端エンティティへ、S-CSCF１０３から転送される。しかし、HSSクエリに合致する結果が得られなければ、要求は拒否され、オペレータＡは要求されたサービスを要求者へ提供することに失敗する。この場合は別の最終ステージ１：３ｂによって示されている。

例えば”user1@ericsson.com”のようなURIを用いるURI手法を有するエリクソンのような会社は、”ericsson.com”ドメインを、地域的だけでなく国際的に使用することを望むであろう。しかしながら、現時点でそのような機能を提供する手法は存在しない。

本発明の一目的は、あるDNSドメイン名を複数のSIPドメインで利用されることを可能とする方法と、そのような方法に適合された機器を提供することである。これは、SIPドメインのオペレータに、入来する要求のDNSドメイン名が共有ドメインであることを気付かせ、自身のドメインにおいて実行したユーザデータベースクエリに失敗したことによりそのような要求を拒否する代わりに、そのような要求がルーティングされることを可能とするように、要求の宛先URIを解決する機構を提供することによって実現することができる。

一見地によれば、例えばIMSドメインのようなSIPドメインのノードが、ユーザデータベースクエリが失敗(401)した（要求の問い合わせに合致する結果が得られなかった）入来要求を処理するように適合される方法が提供される。そのような方法を実施するための典型的なノードは、例えばインタロゲーティングCSCF(I-CFCS)のような呼セッション制御機能(CSCF)である。

そのノードは要求をルーティングするための適切な宛先アドレスを見つけることができないであろうから、説明されるシナリオは要求の拒否に終わるのが普通であろう。しかし、提案する手順では、要求を拒否する代わりに、要求のDNSドメイン名が共有ドメインとして登録されているか否かを調べる。そのような手順は設定データを調べることによって実行することができる。設定データはそのノードに事前に保存しておいても良いし、ノードがアクセスして入手してもよい。

DNSドメイン名が共有ドメインとして登録されていると判別されれば、DNSドメイン名はグローバルにルーティング可能なURIに解決され、要求は宛先エンティティへルーティングされる。しかし、DNSドメイン名が共有ドメインとして登録されていないことがわかれば、標準的な動作のように要求は拒否されるであろう。

一実施形態によれば、設定データはSIPドメインのオペレータによって管理されるすべてのDNSドメインと、個々のDNSドメインが共有ドメインか否かを示す、DNSドメインに関連付けられたパラメータとを有する。あるいは、設定データはさらに、１つ以上のURIであり、その各々が、共有DNSドメインを共有する１つ以上のSIPドメインを示すURIを保存するためのポストを有してよい。

一実施形態によれば、DNSドメイン名をグローバルにルーティング可能なURIに解決する際に、１つ以上のSIPドメインを有する設定データ（すなわちDNSドメイン名が設定データに登録されている１つ以上のSIPドメイン間で共有されている）を用いることができる。

上述の実施形態と独立して、あるいは組み合わせて実施してよい別の実施形態によれば、設定データの個々のポストにSIPドメインが登録されていないことが、DNSドメイン名の解決に先立って、例えばDNSクエリのような問い合わせの結果として得られてもよい。

別の見地によれば、上述したメカニズムを実施するためのノードも提供される。一実施形態に係るノードは、ユーザデータベースクエリの失敗に応答してドメインチェック手順を開始するためのクエリ部を有する。ドメインチェック部は、ドメインチェック手順を実行するように適合され、要求のDNSドメインが共有ドメインとして登録されているか否かがこの手順において判別される。ドメインチェック部は、DNSドメインが共有ドメインとして登録されていることがわかれば、DNSドメイン名をグローバルにルーティング可能なURIに解決し、要求を宛先エンティテイへルーティングし、DNSドメインが共有ドメインとして登録されていなければ、要求を拒否するように適合される。ドメインチェック手順は、ノードに保存された、あるいはノードに関連付けられた設定データをチェックする手順を有してよい。

別の一実施形態によれば、ドメインチェック部は、個々のDNSドメインを共有する１つ以上のSIPドメインが設定データに登録されていれば、設定データに基づいて要求のDNSドメイン名をグローバルにルーティング可能なURIに解決するように適合されてよい。

上述の実施形態と独立して、あるいは組み合わせて実施してよい別の代替実施形態によれば、ドメインチェック部は、設定データにSIPドメインが登録されていなければ、問い合わせを実行してからDNSドメイン名を解決するように適合される。

従来技術において、IMSドメイン内で要求を処理するための手順の概要を示す図である。共有DNSドメイン宛の要求を処理するための、一実施形態に係る手順の概要を示す図である。一実施形態に係る、例示的な拡張設定を説明する表を示す図である。一実施形態に係る、SIPドメイン内で入来要求を処理するための方法を説明するフローチャートである。図４に関して説明された方法において、共有IMSドメイン名を解決するための別の方法を説明するフローチャートである。

以下、添付図面を参照して、例示的な実施形態によって本発明をより詳細に説明する。
簡単に説明すると、本発明はDNSドメイン名が複数のSIPドメインで用いられることを可能にするための仕組みを提供する。すなわち、DNSドメインが共有DNSドメインとして用いられることを可能にする仕組みを提案する。

一実施形態によれば、共有DNSドメインを処理するための仕組みは、SIPドメインの、変更されたノード、典型的にはI-CSCFを導入することによって達成することができる。I-CSCFは、図１に関して既に説明した従来技術の例と同様に、SIPドメインに到着した要求の問い合わせを受け持つ。SIPドメインはIMSドメインであっても、SIPプロトコルを用いるように適合された他の任意の形式のネットワークであってもよい。ドメインチェック手順はSIPドメインのノードに導入される。この手順は、ユーザデータベースクエリ、典型的にはHSSクエリの失敗に応答して実行されるべきである。

この例示的な実施形態は、HSSへ問い合わせる変更されたI-CSCFと、他のCSCFノードへの要求のルーティングとに基づいているが、提案する仕組みは、類似のキューイングとルーティング手順を処理するように構成された他のエンティティで実施することも可能であることを理解されたい。

従来技術によれば、要求のユーザデータベースクエリが合致に至らなかった場合には、個々の要求の拒否に繋がっていたであろう。そして、オペレータは発呼者に対し、要求されたサービスを提供できなかった。そのような状況において要求を拒否する代わりに、提案するドメインチェック手順は、SIPドメインに関連付けられた拡張設定データを問い合わせるように適合される。拡張設定データは、既存の、DNSドメインを有する個々のSIPドメイン（すなわち、SIPドメインによって管理されるDNSドメイン）のリストが、各DNSドメインに設定された、各DNSドメインが別のSIPドメインと共有されているか否かを示すパラメータによって拡張されたものである。ノードは、設定データにおいてDNSドメインが共有ドメインであることが示されている場合、入来要求のクエリ、典型的にはDNSクエリ手順を実行するように適合される。クエリ手順は１つ以上のクエリを含んでよく、このクエリは、ノードが要求をルーティングすることを可能とするように、特定かつ予め定められた方法で実行されてよい。あるいはクエリは、Diameter, LADP(Lightweight Directory Access Protocol)又は、この種のクエリを実行するのに適した他のプロトコルによって行ってよい。

提案する仕組みをSIPドメインに実装することにより、共有DNSドメイン宛の要求は、異なるSIPドメイン間で共有されるDNSドメインに関連付けられた追加データを有する有益な設定データ、の問い合わせに応答してルーティングされるであろう。

複数のSIPドメインで共有されているDNSドメイン名を処理するように適合された、一実施形態に係る汎用ネットワークアーキテクチャを、図２を参照してより詳細に説明する。なお、提案する仕組みの理解に必要ないノード及びシグナリングステップは、簡潔さを目的として省略されていることを理解されたい。また、図２に示したアーキテクチャは純粋に論理的なものであって、説明する、ノードに対して関連する機能を提供する部分(unit)は、様々な代替方法によって実施可能であることも留意されたい。

図２は、要求が、IMSドメイン２００のオペレータＡが管理する、変更されたSIPノード２０１（この場合はI-CSCF）によってどのように処理され、また、新規なドメイン問い合わせの仕組みに従って入来要求を問い合わせるように適合されているかを説明する。I-CSCF２０１は、入来要求を受信するとユーザデータベース２０３（この場合はHSS）へのクエリを実行するように適合されたクエリ部２０２を有する。HSSクエリの目的は、要求を意図された宛先エンティティ（不図示）へ配信する責を負う適切なサービングノード２０４（この場合はS-CSCF）又は他の任意の形式の類似ノードを見つけることである。宛先エンティテイはIMSドメイン２００内に設置されていても、DNSドメインを共有する他のドメイン（例えばIMSドメイン２０８）内に設置されていてもよい。

この時点まで、説明する手順は周知のクエリ及びルーティング手順に従って実行されている。関連S-CSCF２０４がユーザデータベースクエリで見つかった場合、要求は個々のS-CSCFへルーティングされ、標準的な動作と同様に、そこからさらに（例えば不図示のアプリケーションサーバ(AS)のような）宛先エンティティへルーティングされる。

しかし、問い合わせを実行しても合致する結果が得られなければ、通常はこの特定の状況において次のステップで実行されるであろう要求の拒否の代わりに、ドメインチェック部２０５が有効化される。ドメインチェック部２０５は、入来要求のDNSドメインが共有DNSドメインか否かを判別するように適合される。これは、問い合わせノード２０１内に保存され、あるいは問い合わせノード２０１と関連付けられた設定データ２０６に問い合わせることによって実現される。設定データは、個々のDNSドメインが共有ドメインか否かを示すパラメータを受け入れる少なくとも１つの新規ポストによって拡張されている。設定データはまた、個々のDNSドメインを共有する１つ以上のIMSドメインの、グローバルにルーティング可能な１つ以上のURIを示すローカル設定情報を有する、追加ポストをさらに有することができる。この設定データに基づき、共有DNSドメイン宛の要求は関連IMSドメインへルーティングされる。一方、他のIMSドメインと共有されていないDNSドメインへの要求は、ユーザデータベースクエリが失敗すれば、従前の方法に従って処理部が拒否するであろう。

設定データに基づいて、クエリに引き続きルーティングが実行されてよい。あるいは、ローカル設定情報が設定データからアクセス可能ならば、共有IMSドメインへのルーティングに引き続いて実行されてよい。要求が電話番号を有する場合、例えばDNSクエリのようなクエリは、ENUM DNS又は企業固有DNSを含みうる１つ以上のDNSサーバの問い合わせを含むのが通常である。図２において、このクエリは、DNSサーバ２０７で実行されるDNSクエリによって例示されている。

最初のステージ２：１においてオペレータＡのIMSドメイン２００に到着した要求は、次のステージ２：２でクエリ部２０２によって問い合わせられる。ここでは、周知の手順に従ってHSS２０３が問い合わせを受ける。合致するものが見つかれば、すなわち、個々のDNSドメイン名に関連付けられたS-CSCFがHSSで見つかれば、要求はステージ２：３ａによって示されるように個々のS-CSCF２０４へルーティングされる。しかし、HSSクエリによって合致するものが見つからなければ、代替ステージ２：３ｂによって示されるように、ドメインチェック手順が代わりに開始される。次のステージ２：４で示されるドメインチェック手順は、要求のDNSドメイン名のホスト部分、すなわち”domain1.com”を、ドメインチェック部２０５がアクセス可能な設定データ２０６と比較する。DNSドメインが２つ以上のIMSドメイン間で共有されていることがわかると、ステージ２：５ａで示されるように、ドメインチェック部はDNSドメイン名をグローバルにルーティング可能なURIに解決するように構成される。

まず、設定データ２０６を問い合わせるように構成された解決手順が起動される。解決手順の目的は、個々のIMSドメインに関連付けられたローカル設定が存在するか否か、すなわち、設定データ２０６が、DNSドメインを共有しているIMSドメインに関連付けられた、グローバルにルーティング可能な１つ以上のURIの登録を有するか否かを判別することである。ローカル設定が見つかれば、ステージ２：６で示されるように、DNSドメイン名は、オペレータＢが管理する登録されたIMSドメイン２０８へ要求がルーティングされることを可能にするように解決される。設定データに複数のIMSドメインが登録されている場合、その１つ、例えば最初の１つを、要求をルーティングする次の宛先として選択してよい。一般に、問い合わせノード２０１の構成は、要求をルーティングすべきドメインをどのようにして選択するかを指定する、予め設定されたルールをさらに有する。選択された宛先ドメインで合致するものが見つからない場合、宛先ドメインの問い合わせノードは、登録されたIMSドメインの次のものへ、要求をさらにルーティングするように構成されてよい。この手順は、通常、適切なIMSドメイン及び宛先エンティティが見つかるまで継続する。あるいは、要求の宛先URIのユーザ情報を解析し、その結果を用いてURIを、その最初の場所に存在する正しいIMSドメインに解決してもよい。

オペレータＢのIMSドメイン２０８にはI-CSCF２０９のみが示されているが、任意のIMSドメインに関し、または他の任意の型式のSIPドメインに関し、ドメイン２０８は、IMSサービス及び／又は他のSIPサービスを管理したりエンドユーザに提供するために必要な、従前の制御機能ノード及びサーバのようなさらなるノードを有していることを理解すべきである。

要求がIMSドメイン２０８で終端宛先へ転送可能となる（図示せず）より前に、IMSドメイン２０８で、DNSクエリ手順及び／又は他の任意のクエリ手順が実行される。それらクエリ手順は従前のクエリ及びルーティング手順に従って行われる。

ステージ２：５ａでの解決フェーズの間、設定データ内にローカル設定を見つけることが出来なければ、問い合わせ手順は既知の任意の方法に従って実行されるであろう。クエリ手順は、設定に従って、IMSドメイン２００に固有の、１つ以上のDNSクエリ及び／又は他のクエリを有してよい。本例において、DNSサーバ２０７で実行されるクエリは、代替ステージ２：５ｂによって示されている。提案されるDNSクエリ手順の結果に基づいて、要求の宛先アドレスがグローバルにルーティング可能なURIに解決される。グローバルURIが提供されると、ステージ２：６で、要求は宛先ドメイン２０８へルーティングされることが可能になる。ドメイン２０８で、要求を意図された宛先エンティティへ配信するために、さらなるルーティングが実行されてもよい。しかし、DNSドメインが共有ドメインでなければ、要求は標準的な動作のように拒否される。これは代替ステージ２：５ｃによって示されている。

図３に、上述した実施形態に従って拡張された設定データの一例を説明する単純化された表３００を示す。この例示的な表は、”ドメイン”列３０１に登録された３つのドメイン”domain1.com”、”domain2.com”及び”domain3.com”を有する。設定データのこのカテゴリは、IMSドメインの全DNSドメインが、例えば個々のIMSドメインの認証、サービス能力、及び利用可能なHSSエンティティ、を参照する情報のような、そのIMSドメインについての他の設定データと共に、従来技術の方法において既に検索可能であることを示している。図３に示される設定データはしかし、各DNSドメインについて、DNSドメインが共有ドメインである(yes)かそうでない(no)かを示すパラメータを”共有”列３０２にさらに有している。加えて、図３の表は、必要に応じて設けられる”〜と共有”列３０３を有している。この列には、個々のDNSドメインがどの１つ以上のIMSドメインによって共有されているかを伝える情報を登録することができる。従って、ドメイン”domain1.com”への要求は、表に格納されたルーティング情報に従って、すなわちIMSドメイン”telenor.com”へルーティングされるであろう。そして、ドメイン”telenor.com”において、要求を終端宛先へルーティングするために、従前のDNSクエリ手順が実行されるであろう。一方、”domain2.com”への要求は、”domain2.com”が共有ドメインとして登録されていないため、問い合わせノードによって拒否されるであろう。最後に、ホスト部”domain3.com”を有する要求は、１つ以上のクエリから検索される情報に従ってルーティングされるであろう。

共有DNSドメイン宛かもしれない要求を処理するための、別の見地に係る方法を、図４のフローチャートを参照して説明する。最初のステップ４００で開始すると、要求が、一般にIMSドメインであるSIPドメインＡの問い合わせSIPノードに到着する。次のステップ４０１で、ドメインＡの問い合わせSIPノードにおいて、DNSドメイン名をユーザデータベースに問い合わせる。そして、問い合わせの結果、合致するものが見つからず、その結果、オペレータは要求をルーティンすることに失敗し、何も処理を行わない。そのような判定に引き続き、その要求のDNSドメインが共有ドメインか否かを判定するために、設定データが問い合わせされる。これは次のステップ４０２で実行される。DNSドメインが共有ドメインでないことがわかれば、ステップ４０３で示されるように既知の手順に従って要求が拒否され、その後処理がステップ４０６で終了する。しかし、DNSドメインが共有ドメインであれば、ステップ４０４で、設定データに従って、要求のDNSドメイン名がグローバルにルーティング可能なURIに解決される。そして、ステップ４０５に示されるように要求はそのURIに従ってSIPドメインへルーティングされた後、ステップ４０６で処理が終了する。要求がルーティングされたSIPドメインで、要求は既知の手順に従って終端エンティティへ配信される。

図４のステップ４０４で示される解決手順は、設定データからどのような情報が読み出し可能かに応じて、様々な方法で実行されてもよい。

図５において、図４のステップ４０４及び４０５は代替ブロック方法によって置き換えられている。ステップ５００で示すように要求が共有ドメイン名を有することがわかっていれば、すなわち、図４のステップ４０２の結果が”yes”であれば、DNSドメインを共有するSIPドメインＢの情報を有するローカル設定が設定データ内に存在するかどうかの判定が行われる。そのような判定は次のステップ５０１で実行される。そのような情報が実際に登録されていれば、ステップ５０２で要求は適切なアドレスに解決され、引き続くステップ５０５で個々のSIPドメインＢへルーティングされる。SIPドメインＢにおいて、クエリ手順、典型的には１つ以上のDNSサーバが関与するDNSクエリ手順が既知の方法で実行されるであろう。そして、クエリ手順の結果に従って、要求は終端エンティティへルーティングされることができる。一方、そのような設定が見つからなければ、別の代替ステップ５０３で示されるように、要求の完全な終端URIを問い合わせるクエリ手順、例えばDNSクエリ手順が代わりにSIPドメインＡで実行される。続くステップ５０４で、クエリ手順の結果を用いて、終端URIはグローバルにルーティング可能なURIに解決される。このURIを用い、要求は次のステップ５０５でルーティングされ、その後、図４のステップ４０６によって示されるように解決手順が終了する。終端ドメインにおいて、要求は終端エンティティへ到達できるよう、既知の手順に従ってルーティングされるであろう。

本発明を特定の例示的な実施形態に関して説明してきたが、この説明は主に発明の概念を説明することを意図したものであり、添付の特許請求の範囲によって規定される本発明の範囲を限定するものと解されるべきではない。

Claims

ユーザデータベースクエリが失敗した(401)入来要求を処理するための、SIPドメイン(200)のノード(201)における方法であって、
前記要求のDNSドメイン名の全体が共有ドメインとして登録されているかどうかを判別するステップ(402)と、
前記DNSドメイン名の全体が共有ドメインとして登録されている場合に、前記DNSドメイン名をグローバルにルーティング可能なURIに解決するステップ(404)、及び、
前記DNSドメイン名の全体が共有ドメインとして登録されている場合に、前記要求を終端エンティティへルーティングするステップ(405)、又は、
前記DNSドメイン名の全体が共有ドメインとして登録されていない場合に、前記要求を拒否するステップ(403)と、
を有することを特徴とする方法。
前記判別するステップが、設定データを調べるステップを有することを特徴とする請求項１記載の方法。
前記設定データが、前記SIPドメインのオペレータが管理するすべてのDNSドメイン(301)と、個々のDNSドメインが共有ドメインか否かを示す、関連付けられたパラメータ(302)と、を有することを特徴とする請求項２記載の方法。
前記設定データが、各々が個々のDNSドメインを共有するSIPドメインを示す１つ以上のURI、を格納するためのポスト(303)をさらに有することを特徴とする請求項３記載の方法。
前記設定データが１つ以上のSIPドメイン名(501)を有する場合、当該SIPドメイン名を、前記DNSドメイン名をグローバルにルーティング可能なURIに解決する(502)際に用いることを特徴とする請求項４記載の方法。
前記設定データにおいて、共有DNSドメインとして登録されているSIPドメイン名がない場合、クエリを実行(503)した後で前記個々のDNSドメイン名が解決される(504)ことを特徴とする請求項２乃至請求項５のいずれか１項に記載の方法。
前記クエリがDNSクエリであることを特徴とする請求項６記載の方法。
前記ノードが呼セッション制御機能(CSCF)であることを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
前記CSCFがインタロゲーティングCSCF(I-CSCF)であることを特徴とする請求項８記載の方法。
前記SIPドメインがIMSドメインであることを特徴とする請求項１乃至請求項９のいずれか１項に記載の方法。
ユーザデータベースクエリ(2:2)が失敗した入来要求(2:1)を処理するための、SIPドメイン(200)のノード(201)であって、
前記失敗したユーザデータベースクエリに応答して、ドメインチェック手順(2:3b)を開始するクエリ手段(202)と、
前記要求のDNSドメイン名の全体が共有ドメインとして登録されているかどうかを判別するステップ(402)を有する前記ドメインチェック手順(2:4)、を実行するドメインチェック手段(205)であって、前記DNSドメイン名の全体が共有ドメインとして登録されている場合に、前記DNSドメイン名をグローバルにルーティング可能なURIに解決する(2:5a, 2:5b)ように適合されるとともに、前記DNSドメイン名の全体が共有ドメインとして登録されている場合に、前記要求を終端エンティティへルーティングする(2:6)ように適合されるか、前記DNSドメイン名の全体が共有ドメインとして登録されていない場合に、前記要求を拒否する(2:5c)ように適合される、ドメインチェック手段(205)と、を有することを特徴とするノード。
前記ドメインチェック手順が、前記ノードに保存されているか、前記ノードに関連付けられた、設定データを調べるステップを有することを特徴とする請求項１１記載のノード。
前記設定データが、前記SIPドメインのオペレータが管理するすべてのDNSドメイン(301)と、個々のDNSドメインが共有ドメインか否かを示す、関連付けられたパラメータ(302)と、を有することを特徴とする請求項１２記載のノード。
前記設定データが、各々が個々のDNSドメインを共有するSIPドメインを示す１つ以上のURI、を格納するためのポスト(303)をさらに有することを特徴とする請求項１３記載のノード。
個々のDNSドメインを共有する１つ以上のSIPドメインが前記設定データに登録されている場合に、前記ドメインチェック手段が、前記設定データに従って、前記DNSドメイン名をグローバルにルーティング可能なURIに解決するように適合されることを特徴とする請求項１２乃至請求項１４のいずれか１項に記載のノード。
前記設定データにSIPドメインが登録されていない場合、前記ドメインチェック手段が、クエリを実行した後で前記DNSドメイン名を解決するように適合されることを特徴とする請求項１２乃至請求項１５のいずれか１項に記載のノード。
前記クエリがDNSクエリであることを特徴とする請求項１６記載のノード。
前記ノードが呼セッション制御機能(CSCF)であることを特徴とする請求項１１乃至請求項１７のいずれか１項に記載のノード。
前記CSCFがインタロゲーティングCSCF(I-CSCF)であることを特徴とする請求項１８記載のノード。
前記SIPドメインがIMSドメインであることを特徴とする請求項１１乃至請求項１９のいずれか１項に記載のノード。