JP5249233B2 - Ｉｍｓサービスの柔軟なアドレスの解決の方式 - Google Patents

Description

本発明は概略としてＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークのアドレス解決に関する。アドレス解決は、メッセージをＩＭＳネットワーク内のさまざまなノードの間でルーティングするために、これらのノードによって実行される。アドレス変換の主な用途は、メッセージが異なるネットワークの間でルーティングされる時及びローミングユーザの場合である。

ネットワーク内のユーザ及びノードの識別は、一般に、数値表現を使用するのではなく、ドメイン名などのシステムの英数字表現を使用して行われる。しかし、システム自体は、例えばインターネットプロトコル（ＩＰ）アドレスなどの数値表現を使用する。英数字表現から数値表現への変換がネットワーク内で実施される必要がある。ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークは、ＩＰアドレスを使用して、これらのネットワークを介して及びさまざまなネットワークの間でメッセージをルーティングする。ＩＭＳネットワーク内で送信される全てのメッセージは、メッセージの受信ノードを決定するのに使用される英数字表現であるセッション開始プロトコル（ＳＩＰ）統一資源識別子（ＵＲＩ）を含む。これらのＳＩＰ ＵＲＩは受信ノードが配置されたネットワークを識別するドメイン名を含む。

英数字表現から数値表現への変換を実行する通常の実施態様がドメインネームシステム（ＤＮＳ）である。ＤＮＳはドメイン名がツリー構造に従って編成されるデータベース・システムである。このデータベースはさまざまなＤＮＳサーバの間で分散される。会社が、ウェブサイト又は電子メールなどのアプリケーションのためにそれら自体のドメインを編成することが一般的に実践されている。会社は、それに対して、変換を実行できるネームサーバを提供する。ドメイン名空間の特定の部分の責任を負うネームサーバを権威ネームサーバ（ａｕｔｈｏｒｉｔａｔｉｖｅ ｎａｍｅ ｓｅｒｖｅｒ）と呼ぶ。全ての変更がこのネームサーバに対して行われ、他のネームサーバは最新の情報を取り出すために権威あるネームサーバに照会することができる。

２００６年８月１４日にＧＳＭ Ａｓｓｏｃｉａｔｉｏｎ（ＧＳＭＡ）によって公開されたＯｆｆｉｃｉａｌ Ｄｏｃｕｍｅｎｔ ＩＲ．６５ ｖｅｒｓｉｏｎ ３．５は、ＩＭＳローミング及びインターワーキングのガイドラインを含む。この文書では、２つの可能な解決策がＩＭＳによるＤＮＳの使用について提案されている。

最も便利な解決策であるようにも見える第１の可能な解決策は、ＩＭＳネットワーク内のノードに変換を提供するためにインターネット内でも使用されるパブリックＤＮＳサーバを使用することである。純粋にパブリックな運営されるＤＮＳインフラストラクチャへの切替に関連する主な問題はセキュリティである。全ての情報が公衆に使用可能になり、大規模オペレータは彼らのネットワーク及びその動作に関する情報を共有することを嫌う。第２の可能な解決策は、例えば汎用パケット無線サービス（ＧＰＲＳ）ローミング用に管理される、特定の組織によって管理される既存プライベートＤＮＳサーバを利用する。ＩＭＳノードへのドメイン名の変換を提供するのに既存プライベートＤＮＳサーバを使用する時に、複数の可能な実施態様がある。しかし、これらの実施態様のそれぞれに欠点が伴う。

第１の可能な実施態様は、ＳＩＰ ＵＲＩ内の特定のドメインと、例えばプライベートＤＮＳサーバを管理する組織によって定義されるネーミング方式との使用である。これの例が、ＧＳＭＡによって運営されるＧＰＲＳ Ｒｏａｍｉｎｇ ｅＸｃｈａｎｇｅ（ＧＲＸ）によって使用される３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇドメインである。この場合に、ＧＳＭＡだけがシステムに新しいオペレータを追加することができ、従って、彼らが彼ら自体のＩＭＳネットワークを運営し、他のＩＭＳネットワークと通信することを可能にすることができる。さらに、パブリックネットワークを介してルーティングされなければならないメッセージで３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇドメインを使用することは、不可能である。パブリックＤＮＳサーバはこのドメインを解決することができない。これは、例えば、会社が彼らの会社ネットワーク内のＳＩＰ対応デバイスからモバイルユーザに発呼することを妨げる。

もう１つの可能な実施態様は、オペレータのグローバルＤＮＳインフラストラクチャのサブセットを、ＧＲＸなどのネットワーク内で使用されるプライベートＤＮＳインフラストラクチャに追加することである。この実践は、全ての変更を複製することも人間の責任なので、両方のＤＮＳインフラストラクチャの間での深刻な衝突につながる可能性がある。従って、この実施態様は、より多くの人間の努力を必要とし、従って、障害を発生する傾向がより強い。全ての人間の誤りが、ネットワークが到達不能になることと、通信の混乱とにつながる可能性がある。これは、プライベートＤＮＳインフラストラクチャ内の複製された情報の責任を誰が負うのかという疑問をも提起する。

この機能性の第３の可能な実施態様はパブリックＤＮＳインフラストラクチャとプライベートＤＮＳインフラストラクチャとを混合することによるものである。この実施態様は、いくつかの利益を提供するが、パブリックＤＮＳインフラストラクチャの使用に関係する新しい問題を導入する。しかし、この実施態様を以下でさらに説明する。

現在、ＧＲＸで使用されるプライベートＤＮＳサーバと、インターネットに使用されるものなどのパブリックＤＮＳサーバとの間の接続はない。これは、一般公衆及び特に悪意のある個人によるプライベートネームサーバへのアクセスを防ぐことによって、あるレベルのセキュリティを提供する。ＩＭＳネットワークの編成を発見することは不可能であり、その結果、ＩＭＳネットワーク又はＧＰＲＳネットワークの非常に重要なノードへの攻撃を編成することは困難又は不可能である。現在の機能性を拡張する時に全てのセキュリティ態様を保持することが望まれることは明白である。

遠隔通信市場の主なプレイヤは、現在、固定及び移動体のブロードバンドアクセスｘＤＳＬ及びＧＰＲＳネットワークを運営し、ＩＭＳサービスの提供にも関心を持っている可能性が高い。これらのプレイヤのほとんどは、ＧＰＲＳローミング及びインターワーキングを顧客に提供するために、ＧＲＸ又は類似するプライベートな管理されたネットワークのメンバである。従って、ＩＭＳサービスとＩＭＳネットワークへの相互接続とを提供するためにＧＲＸによって提供されるサービスを使用することが論理的なステップである。

３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇをパブリックネットワーク内でアドレッシングすることはできず、オペレータはこのドメインの内容を制御していないので、オペレータが彼ら自体のドメイン名を使用し、例えばＧＲＸによって提供される利益から利益を得ることが望ましくなる。これを達成する可能な形は、Ｏｆｆｉｃｉａｌ Ｄｏｃｕｍｅｎｔ ＩＲ．６５文書のセクション９．４で、これらの解決策を回避すべき理由と一緒に提案されている。これらの解決策のすべてが、現在のＧＲＸインフラストラクチャのある変更（即ち、現在使用されている３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇドメインにオペレータドメインをプレフィックスとして追加することによってＵＲＩ方式を変更すること）を必要とし、あるいは、この要件にかなりの量の人間の労力を追加する（即ち、オペレータ側で静的に構成されたリストを保持することによって）。

ＧＰＲＳローミングに使用されるＤＮＳサーバ即ちＧＰＲＳ Ｒｏａｍｉｎｇ ｅＸｃｈａｎｇｅ（ＧＲＸ）が、２００６年８月９日にＧＳＭ Ａｓｓｏｃｉａｔｉｏｎ（ＧＳＭＡ）によって公開されたＯｆｆｉｃｉａｌ Ｄｏｃｕｍｅｎｔ ＩＲ．６７ ｖｅｒｓｉｏｎ １．４に記載されている。この文書には、ＤＮＳサーバの構造と、ドメイン名の解決に用いられるステップとが記載されている。一般に、ＧＲＸ内のＤＮＳサーバは、一般公衆が使用可能なＤＮＳサーバと同一の形で動作する。しかし、ここで既知のドメインのセットはＧＳＭＡによって定義される特定のドメインに制限される。

次世代ネットワーク（ＮＧＮ）の一連の要件が、ＥＴＳＩ ＴＩＳＰＡＮ ｃｏｎｔｒｉｂｕｔｉｏｎ １１ｂＴＤ０７９及びＥＣＭＡ ＴＲ／９１（ＥＴＳＩ ＴＲ １０２ ４７８）で指定されている。これらの要件は、企業が彼ら自体の次世代企業ネットワーク（ＮＧＣＮ）を作成し、ＳＩＰなどのサービスを提供する手段を提供する。ＮＧＮがこれらの要件の全ての実施態様を提供する場合に、ＮＧＮとＮＧＣＮとの間又はＮＧＮを介する複数のＮＧＣＮの間の相互作用が、可能になる。しかし、要件１２は、ＮＧＮがＮＧＣＮがＮＧＮとの以前の取決めなしでそのドメイン内で新しい識別子を割り当てることを可能にしなければならないことを指定する。現在のところ、これは１つのＮＧＮだけがこれらのネットワークの中で既知なので不可能である。従って、これらの要件のすべてについて十分に適格であるＮＧＮを提供する際に問題が生じる。

２００６年８月１４日にＧＳＭ Ａｓｓｏｃｉａｔｉｏｎ（ＧＳＭＡ）によって公開されたＯｆｆｉｃｉａｌ Ｄｏｃｕｍｅｎｔ ＩＲ．６５ ｖｅｒｓｉｏｎ ３．５ ２００６年８月９日にＧＳＭ Ａｓｓｏｃｉａｔｉｏｎ（ＧＳＭＡ）によって公開されたＯｆｆｉｃｉａｌ Ｄｏｃｕｍｅｎｔ ＩＲ．６７ ｖｅｒｓｉｏｎ １．４ ｈｔｔｐ：／／ｗｗｗ．ｉｓｃ．ｏｒｇ／ｉｎｄｅｘ．ｐｌ？／ｓｗ／ｂｉｎｄ／ ｈｔｔｐ：／／ｗｗｗ．ｐｏｗｅｒｄｎｓ．ｃｏｍ／

本発明の目的は、組織によって管理される、インターネット内で一般公衆によって使用されるＤＮＳインフラストラクチャから完全に分離された、ＤＮＳインフラストラクチャと組み合わせて、オペレータ自身のドメイン名を使用する方法をオペレータに提供することである。本発明のもう１つの目的は、既存システムに対する変更をほとんど伴わずにこの機能性を提供することであり、本発明のもう１つの目的は、オペレータドメイン名の使用を達成するためにパブリックＤＮＳインフラストラクチャ内の情報を使用する形を提供することである。本発明のもう１つの目的は、セットアップ及び維持に人間の努力をほとんど必要としないシステムを提供することである。本発明のもう１つの目的は、システムを、従来技術で提案された解決策よりエラーを被りにくいものにすることである。本発明のもう１つの目的は、次世代ネットワークと共に存在する問題の解決策を提供し、次世代ネットワークがそれら自体のアイデンティティを使用することを可能にすることである。

本発明によれば、請求項１に記載のＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク内又はその間でメッセージをルーティングする際に使用される統一資源識別子（ＵＲＩ）を解決する方法であって、
ａ．ＩＰマルチメディアサブシステムネットワークにメッセージを送信できるデバイスからプライベートネームサーバに、統一資源識別子（ＵＲＩ）を解決するためのクエリを送信するステップ、
ｂ．プライベートネームサーバによって統一資源識別子（ＵＲＩ）を解決するステップ、
ｃ．プライベートネームサーバによる統一資源識別子の解決が失敗する場合に、統一資源識別子を解決するための新しいクエリをパブリックネームサーバに送信するステップ、
ｄ．パブリックネームサーバによって統一資源識別子を解決するステップ、及び
ｅ．デバイスによってクエリに対する応答を受信するステップ
を含む方法を介して、上で説明した目的が実現され、従来技術の短所が克服される。

本発明の文脈では、ＵＲＩの解決は、例えばそのＵＲＩの一部であるドメイン名のＩＰアドレス又は異なるドメイン名への標準ＤＮＳプロシージャを使用する変換の試みに用いられる任意のステップ又はステップの組合せを意味する。標準ＤＮＳプロシージャは、ＤＮＳサーバのキャッシュを検査することと、異なるネームサーバと通信することと、既知のドメイン名から情報を取り出すこととを含む。キャッシングを、その構成に応じてネットワーク内のネームサーバ又はノードによって提供することができる。異なるネームサーバとの通信は、権威あるネームサーバを判定するため又は権威あるネームサーバから情報を取り出すためのリフェラル（ｒｅｆｅｒｒａｌ）に起因する可能性がある。解決が、ネームサーバによって実行される場合に、これは、そのネームサーバが権威あるドメイン名に関する情報を提供すること、あるいは他のネームサーバから情報を取り出すことのいずれかとすることができる。

クエリは、情報の要求を含む、ＤＮＳ標準規格によって定義されるメッセージである。要求される情報は、ドメイン名に関係するＩＰアドレス、ある種のプロトコルを処理するサービスの位置、異なるドメイン名へのリフェラルとすることができる。クエリは、要求された情報を含む応答によって回答される。最終的に、クエリを送信したシステムは、この応答を受信し、メッセージのルーティング又は特定のホストへの接続のセットアップなどのタスクに、それに含まれる情報を使用できるようになる。

全てのドメインがＤＮＳサーバによって既知であるわけではなく、例えば、ドメイン名のタイピング・エラーが、存在しないドメインに関する要求をもたらす場合がある。ネームサーバが、全ての可能なルックアップ（即ち、キャッシュ又は異なるネームサーバ）を実行し、クエリに対する回答を提供することができない時に、エラー応答が送信される。そのようなエラーが受信される時には、そのエラーは、ネームサーバによるＵＲＩ解決の失敗と考えられる。

パブリックＤＮＳサーバ及びプライベートＤＮＳサーバは、公衆が使用可能又は使用不能と考えられなければならない。パブリックＤＮＳサーバは、例えば、インターネット上のさまざまなサービスにアクセスするのに一般公衆によって使用されるＤＮＳサーバである。プライベートＤＮＳサーバは、ある会社などのある種の組織によって管理され、その使用がそのような組織のメンバ又はそのような組織との合意を有する人に制限されるＤＮＳサーバである。これの一例が、ＧＳＭＡによって運営され、他のサービスの中でもＤＮＳサービスを提供するＧＲＸであり、これらのサービスは、ＧＳＭＡのメンバ及びＧＳＭＡにかかわるオペレータのみが調べることができる。

本発明によれば、そのようなプライベートＤＮＳサーバは、今や、ＳＩＰ ＵＲＩを解決できない場合に、パブリックＤＮＳサーバを調べる。従って、ＳＩＰ ＵＲＩを解決できないことを示すのではなく、プライベートＤＮＳサーバは、ＳＩＰ ＵＲＩを解決するためにパブリックＤＮＳサーバへの要求を発行する。代替案では、プライベートＤＮＳサーバがＳＩＰ ＵＲＩを解決できないことをそれに示すＩＭＳネットワーク内のノードが、本発明に従ってパブリックＤＮＳサーバと連絡を取る。

これらの余分なステップの利益は明白である。オペレータはプライベートネームサーバによって知られた又はＧＳＭＡなどの組織によって定義されたドメイン名に束縛されない。プライベートな運営され使用可能なＤＮＳサーバとパブリックな使用可能なＤＮＳサーバとの間の厳密な分離が、保たれ、従って、分離されたシステムによって提供されるセキュリティが、維持される。両方のドメインの間での変換の提供は、プライベートＤＮＳサーバ内に存在するオペレータとの合意を必要とする、それ自体のドメインを使用するオペレータの責任である。従って、このシステムによって導入される追加の努力の量は非常に限られており、ごく少数の余分なレコードだけがオペレータのパブリックＤＮＳサーバ内で要求される。

請求項６に記載のデバイスは、本発明の全ての目的を提供するのに必要なステップを実行するように適合される。このデバイスは一般にＩＭＳネットワーク内のノードであるが、請求項１に記載のステップを実行することができる。このデバイスはプライベートネームサーバにクエリを送信し、応答を受信することができる。そのような応答が、プライベートネームサーバがＵＲＩを解決できなかったことを示す場合に、このデバイスは新しいクエリをパブリックネームサーバに送信することができる。これは、このデバイスが、プライベートネームサーバとパブリックネームサーバとの両方をチェックすることを可能にし、プライベートネームサーバで入手可能ではないドメイン名を含むＵＲＩの回答を見つけることを可能にする。

請求項７による代替のデバイスは、従来技術の解決策に見られる問題を解決するのに必要な機能性を提供する。このデバイス即ち、一般にプライベートネームサーバはクエリを受信し、このクエリを解決することができる。このデバイスはこのクエリを解決できない場合に、このクエリを解決するために別のパブリックネームサーバに照会することができる。これは、このデバイスが、ノードとパブリックネームサーバとの間の中間システムとして働くことを可能にする。これは、最初のクエリをデバイスに発行したノードに透過的な形でパブリックネームサーバを使用するＵＲＩの変換を可能にする。

任意選択で、メッセージをルーティングする必要があるノードは、請求項２に記載されているように、請求項１のステップｃを実行することができる。

このノードは、２つのＩＭＳネットワークの間でメッセージをルーティングする責任を負い、従って、それ自体のネットワークの外部に配置されたシステムと通信することができるものとすることができる。本発明を実施するこの形は、ノードの侵入を回避するために、このノード内の追加のセキュリティ手段を必要とする。これらのノードでの現在のセキュリティに起因して、これらのノードはパブリックＤＮＳサーバと通信し、パブリックＤＮＳサーバとプライベートＤＮＳサーバとの間の分離を維持するための理想的な候補である。

任意選択で、プライベートネームサーバは、請求項３に記載されているように、請求項１のステップｃで言及した新しいクエリを送信することができる。

パブリックＤＮＳサーバに連絡するのにプライベートネームサーバを使用する時に、透明性が、メッセージをルーティングするノードについて作成される。これらのシステムは、変更を必要とせず、それらが必要とする情報をもたらす単一のクエリを実行するのみである。ネームサーバは大量の要求を処理するように設計され、他のネームサーバに連絡することによって、あるクエリに対する回答を探すように適合させることができる。従って、本発明のこの実施態様をサポートするために、プライベートＤＮＳサーバに対する限られた適合が必要である。やはり、ＩＭＳネットワークに関する情報はパブリックネットワーク上では送信されず、ドメイン名だけが送信される。従って、ノードの位置は一般公衆に明らかにされず、セキュリティが維持される。

本発明の任意選択の実施形態では、請求項４に記載のように、ＮＡＰＴＲレコードを使用して、公に既知のドメイン名をプライベートインフラストラクチャ内で既知のドメイン名に変換することができる。

ＮＡＰＴＲレコードはＲＦＣ ２９１５に記載されている。これらは、一般に、テキストの既存の行を新しいドメイン名又はＵＲＩに書き直すのに使用される。ＮＡＰＴＲレコードの通常の実施態様は、ＲＦＣ ２９１６に記載のｅ．１６４番号変換を使用する、ＵＲＩへの電話番号のマッピングである。

本発明によれば、そのようなＮＡＰＴＲレコードを、ドメインの権威あるネームサーバの構成に追加することができる。これらのレコードはプライベートＤＮＳサーバによって既知のオペレータのドメイン名を提供する。

ＮＡＰＴＲレコードは正規表現の使用を介して柔軟性を提供し、複数のドメインをプライベートネームサーバに既知の単一ドメインに変換できる少数のレコードをもたらす。

本発明の代替の任意選択の実施形態では、請求項５に記載されているように、ＳＲＶレコードを使用して、公に既知のドメイン名をプライベートインフラストラクチャ内で既知のドメイン名に変換することができる。

ＳＲＶレコードはＲＦＣ ２７８２に記載されている。このタイプのレコードは、通常、負荷平衡化解決策及びバックアップ解決策を提供するのに使用される。一般に、複数のレコードが単一のサービスを表すのに使用され、ここで、各レコードは優先順位及び重みを有する。優先順位はバックアップサービスを定義するのに使用され、レコードの重みは、システムのそれぞれに行くべきトラフィックの量を指定するのに使用することができる。

ユーザエージェントがパブリックＤＮＳサーバに連絡できる、本発明の第１の実施形態を示す流れ図である。 プライベートＤＮＳサーバがパブリックＤＮＳサーバに連絡するのに使用される、本発明の第２の実施形態を示す流れ図である。

図１に、本発明の第１の実施形態のメッセージフローを示す。この実施形態はユーザエージェント（ＵＡ）１２０、プライベートＤＮＳサーバ１２１、パブリックＤＮＳサーバ１２２、及び外部ＩＭＳネットワーク内のノード１２３を含む。

本発明のこの第１の実施形態では、ユーザエージェント１２０は、ＩＭＳネットワークを介してビデオ電話機能性を提供するソフトウェアを有する固定されたデバイス、又はＰｕｓｈ ｔｏ Ｔａｌｋ Ｏｖｅｒ Ｃｅｌｌｕｌａｒ ｎｅｔｗｏｒｋｓ（ＰｏＣ）アプリケーションを有するモバイルデバイスとすることができる。ＰｏＣは、ユーザが、彼らのモバイルデバイス上のキーを押すことによってお互いに話すことを可能にするＩＭＳサービスである。ＰｏＣは、ＩＭＳネットワークへのＧＰＲＳ接続などのパーマネントオンライン接続を使用し、話された言葉を、ＩＭＳネットワークに送信されるデータパケットに変換する。ＩＭＳネットワークはこれらのパケットをその宛先にルーティングし、受信するユーザは話された言葉を聞くことができる。ＰｏＣアプリケーションはＳＩＰ要求のソースの例として働き、ＰｏＣアプリケーションは、さまざまな他のソフトウェアアプリケーションを使用して、さまざまなタスクを実行する。例えば、ＰｏＣアプリケーションは、その上でＰｏＣアプリケーションが動作しているデバイス内で実施されるＤＮＳリゾルバを使用して、要求を送信するのに必要なＤＮＳサーバからの情報を取り出すことができる。ＰｏＣアプリケーションは、他のノード及びＤＮＳサーバにデータを送信するのに、ＴＣＰ／ＩＰプロトコル・スタックの実施態様をも使用する。

プライベートＤＮＳサーバ１２１及びパブリックＤＮＳサーバ１２２は、ＤＮＳサービスを提供するデフォルトソフトウェアアプリケーションである。プライベートＤＮＳサーバ１２１及びパブリックＤＮＳサーバ１２２を構成できる可能なソフトウェアアプリケーションは、ｈｔｔｐ：／／ｗｗｗ．ｉｓｃ．ｏｒｇ／ｉｎｄｅｘ．ｐｌ？／ｓｗ／ｂｉｎｄ／で公表されたＢＩＮＤと、ｈｔｔｐ：／／ｗｗｗ．ｐｏｗｅｒｄｎｓ．ｃｏｍ／で公表されたＰｏｗｅｒＤＮＳとであるが、ＳＲＶレコード及び／又はＮＡＰＴＲレコードの使用をサポートする任意の他のアプリケーションを使用することができる。この第１の実施形態では、ＢＩＮＤが、ＤＮＳサービスを提供するのに使用されると仮定する。プライベートとパブリックとの間の区別は、サーバの位置に基づいて行われる。パブリックＤＮＳサーバ１２２は、例えば電子メールを送信する時又はウェブサイトをブラウズする時に、一般公衆によって連絡され得る。プライベートＤＮＳサーバ１２１はユーザの小さいセットに制限される。プライベートＤＮＳサーバ１２１の一例が、ＧＰＲＳ Ｒｏａｍｉｎｇ ｅＸｃｈａｎｇｅ（ＧＲＸ）ネットワーク内で使用されるＤＮＳサーバである。ローミングとは、ユーザが、彼らが契約を有する携帯電話オペレータに属さないネットワークに接続する行為である。例えば、ある人が、テレフォニサービスについてベルギーのオペレータＡに支払う場合に、この人は、オペレータＡ及びオペレータＢがローミング合意を有する場合に、フランスでオペレータＢのネットワークを使用することができる。従って、ローミングは、あるオペレータとの契約を使用し、複数の他の国でサービスを受けることを可能にする。ローミングの能力は、ユーザが、彼らのＩＭＳ対応デバイス及びアプリケーションを使用しながら自由に移動することを可能にする。

図１に示された外部ＭＩＳネットワーク内のノードは、Ｉｎｔｅｒｒｏｇａｔｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（Ｉ−ＣＳＣＦ）１２３である。パケットはＩＭＳネットワークに渡されるためにこのＩ−ＣＳＣＦ １２３に送信され、従って、Ｉ−ＣＳＣＦはＩＭＳネットワークの境界上のプロキシサーバとして働き、ＩＭＳネットワークへの入口点である。

この実施形態は、２つのネットワーク即ちプライベートネットワーク及びパブリックネットワークを参照して説明される。というのは、本発明の基礎になる問題に、特に、メッセージが、起点がその一部であるネットワークの外部に配置された宛先を有する時に出会うからである。この第１の実施形態では、２つのＩＭＳネットワークが存在し、その一方がオペレータＡに属し、ｏｐｅｒａｔｏｒａ．ｃｏｍドメインを使用し、他方がオペレータＢに属し、ｏｐｅｒａｔｏｒｂ．ｂｅドメインを使用すると仮定する。この実施形態について、オペレータＢが、モバイルテレフォニ、ＧＰＲＳ、及びＩＭＳなどのさまざまな通信サービスを公衆に提供するパブリックオペレータであると仮定する。従って、オペレータＢは、ローミングに関してＧＲＸのメンバであり、ＧＲＸによって提供されるサービスを使用することができる。

この第１の実施形態で、オペレータＢのネットワーク内に位置する、ＵＡ １２０のユーザＢが、ＰｏＣサービスを使用してオペレータＡのネットワーク内に位置するユーザＡと話すことを望む。それに対して、ユーザＢはオペレータＡのネットワーク内でユーザＡを識別できるＵＲＩを知ることを必要とする。ここで、このＵＲＩはｓｉｐ：ｕｓｅｒａ＠ｉｍｓ．ｏｐｅｒａｔｏｒａ．ｃｏｍである。この接続を開始するのに使用されるＳＩＰ要求がＳＩＰ Ｉｎｖｉｔｅ要求１１０である。

図１では、ＵＡ １２０が、メッセージ１１０をＩｎｔｅｒｒｏｇａｔｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（Ｉ−ＣＳＣＦ）１２３にルーティングする必要があると仮定する。このメッセージ１１０は、この２つのユーザの間でＰｏＣセッションを確立するのに使用できるＳＩＰ Ｉｎｖｉｔｅ要求である。ユーザＢはオペレータＢの顧客であり、オペレータＡの従業員であるユーザＡと話すことを望む。従って、ユーザＢはユーザＡにＳＩＰ Ｉｎｖｉｔｅ要求１１０を送信する必要があり、この要求でユーザＡを識別するＳＩＰ ＵＲＩを使用する。通常、全てのＳＩＰ要求はヘッダ及び本体からなり、ここで、ヘッダは、要求１１０のソース、宛先、ルート、及び内容に関する必須情報を含み、本体は要求１１０の内容を含む。ＳＩＰ要求１１０の最初の部分は、どのタイプの要求が提示されるか（この例ではＩｎｖｉｔｅ）、要求１１０が行かなければならない場所を識別するＵＲＩ（この例ではｓｉｐ：ｕｓｅｒａ＠ｉｍｓ．ｏｐｅｒａｔｏｒａ．ｃｏｍ）、及び使用されるＳＩＰのバージョン（例えば、２．０）を定義する。

ＵＡ １２０は、オペレータＡのＩ−ＣＳＣＦにＳＩＰ Ｉｎｖｉｔｅ要求１１０を送信できるようになる前に、ドメインだけがＳＩＰ ＵＲＩから既知なので、Ｉ−ＣＳＣＦ １２３のＩＰアドレスを必要とする。従って、ＵＡ １２０は、クエリ１０１を形成し、これをプライベートＤＮＳサーバ１２１に送信する。このクエリ１０１はＤＮＳプロトコルに従ってフォーマットされたパケットであり、ＳＩＰ要求１１０をルーティングするのに必要なＩＰアドレスの要求を含む。クエリ１０１では、ＵＡ １２０はドメイン名（この例ではｉｍｓ．ｏｐｅｒａｔｏｒａ．ｃｏｍをプライベートＤＮＳサーバ１２１に供給し、この要求で指定されたドメインに関係するＩ−ＣＳＣＦ １２３のＩＰアドレスを返すように要求する。ＤＮＳサーバを見つけ、これに連絡することができるために、ＵＡ １２０は、それが使用できるＤＮＳサーバのアドレスを用いて構成されなければならない。これは、デバイスに対する静的構成を使用して行うことができ、あるいは、ＤＮＳサーバのアドレスを、動的ホスト構成プロトコル（ＤＨＣＰ）などのプロトコルを使用して供給することができる。

プライベートＤＮＳサーバ１２１は、図１の矢印１０２によって示されるように、ローカルキャッシュ及びＤＮＳ情報を使用してドメイン名を解決することを試みる。実際に、ＤＮＳサーバを、前に収集された全ての情報のキャッシュを保持するように構成することができる。これは、全ての要求されたドメイン名が、対応するＩＰアドレスと一緒に格納され、これらのレコードが特定の長さの時間にわたって格納されることを意味する。キャッシングは効率を改善し、他のＤＮＳサーバに対して行われる要求の量を減らすのに使用される機構である。それ自体のキャッシュに加えて、ＤＮＳサーバ１２１はプライベートネットワーク内で定義されるドメイン名空間全体を構成するＤＮＳサーバのネットワークに含まれるＤＮＳ情報を調べることができる。プライベートＤＮＳサーバについて、このドメイン名空間は通常は小さい。オペレータＢなどの特定のオペレータだけがこの名前空間内で既知である。オペレータＡはＧＲＸの一部ではなく、従って、オペレータＡのドメインはプライベートＤＮＳサーバ１２１によって使用されるドメイン名空間内で未定義と仮定することができる。その結果、プライベートＤＮＳサーバ１２１はオペレータＡのドメインの解決を要求する、１０１などのクエリに関する結果を返すことができない。

ＵＡ １２０が、オペレータＢのＩＰアドレスを要求した場合に、プライベートＤＮＳサーバ１２１がそのＩＰアドレスを応答することができ、ＵＡ １２０が、次のノードにＳＩＰ Ｉｎｖｉｔｅ要求１１０をルーティングできることに留意されたい。しかし、この場合には、アドレスがオペレータＡについて要求され、そのオペレータＡのドメイン名がプライベートＤＮＳサーバ１２１に未知であり、クエリ１０１に対する応答１０３は、ＳＩＰ ＵＲＩを解決することの失敗の通知を含まなければならない。これは、ＵＡ １２０が、まだプライベートＤＮＳサーバ応答１０３の受信時にＩ−ＣＳＣＦ １２３にＳＩＰ Ｉｎｖｉｔｅ要求１１０を送信できず、さらなるアクションが必要であることを意味する。

この失敗に起因して、ＵＡ １２０は必要なＩＰアドレスを発見するために異なる手法を試みなければならない。本発明によれば、ＵＡ １２０は、ここで、ＤＮＳサーバ、この場合にはパブリックＤＮＳサーバ１２２が、プライベートＤＮＳサーバ１２１によって既知のドメイン名を用いて回答することを要求する新しいクエリ１０４を形成する。

オペレータＡは一般公衆にサービスを提供するパブリックオペレータではなく、従って、ＧＲＸの一部ではない。オペレータＡはその従業員にＩＭＳサービスを提供するので、オペレータＢへのリンクなど、パブリックＩＭＳネットワークへのリンクを必要とする。これは、例えばオペレータＡとオペレータＢとの間の合意によって達成される。この合意は、オペレータＡが特定のサービスを有するＩＭＳネットワークを有し、オペレータＢのネットワークを介してパブリックＩＭＳネットワークに接続されることを可能にする。従って、要件は、オペレータＡのＩＭＳネットワークの入口点に関する要求が応答としてオペレータＢの入口点を返すことである。オペレータＡのネットワーク内のユーザに関する要求は、オペレータＢのネットワークを介してルーティングされる必要があり、オペレータＢはこれらのメッセージをオペレータＡのネットワークに配送する。システムのこのセットアップに起因して、ＤＮＳインフラストラクチャのある種の実施態様が必要である。この実施態様では、オペレータＢはＧＲＸのＤＮＳサーバ内で既知である。オペレータＡは、そのドメイン（例えば、ｉｍｓ．ｏｐｅｒａｔｏｒａ．ｃｏｍ）からオペレータＢのドメイン（例えば、ｉｍｓ．ｏｐｅｒａｔｏｒｂ．ｂｅ）への変換を提供する。

パブリックＤＮＳサーバ１２２は、図１の矢印１０５によって示されるように、ローカルキャッシュ及びＤＮＳ情報を使用して新しいクエリ１０４に回答することを試みる。ローカルキャッシュ及びＤＮＳ情報はステップ１０２で使用されたものに非常に似ている。ローカルキャッシュは、パブリックＤＮＳサーバ１２２が前に回答した全ての要求に関する、パブリックＤＮＳサーバ１２２によって格納された情報である。ＤＮＳ情報はパブリックＤＮＳサーバ１２２に既知のドメイン名空間に関係する。このドメイン名空間はプライベートＤＮＳサーバ１２１に既知のドメイン名空間よりかなり大きく、一般に、登録された全てのドメインを含む。パブリックＤＮＳサーバ１２２が、ＵＲＩを解決できる場合には、プライベートＤＮＳサーバ１２１に既知の新しいドメイン名を含む応答１０６が形成される。この文脈での解決は、オペレータＡのパブリックＩＭＳネットワークへのリンクを提供するパブリックＩＭＳオペレータＢのドメインを判定することを意味する。パブリックＤＮＳサーバ１２２は、例えば、ＵＡ １２０に送信される応答１０６内で新しいドメインとしてｉｍｓ．ｏｐｅｒａｔｏｒｂ．ｂｅを配送する。

パブリックＤＮＳサーバ１２２は、ＤＮＳ構成内の特定のレコードを使用することによって、ｉｍｓ．ｏｐｅｒａｔｏｒａ．ｃｏｍからｉｍｓ．ｏｐｅｒａｔｏｒｂ．ｂｅへの変換を提供することができる。本発明のこの第１の実施形態では、ＮＡＰＴＲレコードが変換に使用される。ＮＡＰＴＲレコードは要求に対してＵＲＩを応答する柔軟な形を定義する。これは、パブリックＤＮＳサーバ１２２がｓｉｐ：ｕｓｅｒａ＠ｉｍｓ．ｏｐｅｒａｔｏｒａ．ｃｏｍに関する要求を受信し、ｓｉｐ：ｕｓｅｒａ＠ｉｍｓ．ｏｐｅｒａｔｏｒｂ．ｂｅを応答することを可能にする。ＵＡ １２０は後者のＵＲＩを解決するためにクエリを用いてプライベートＤＮＳサーバ１２１に連絡できるので、後者の要求ＵＲＩを用いてメッセージをルーティングすることができる。ｏｐｅｒａｔｏｒｂ．ｂｅはプライベートＤＮＳサーバ１２１によって既知であるので、要求されたＩＰアドレスをＵＡ １２０に提供することができる。ＵＡ １２０はクエリ１０７を用いてこの変換を要求する。このクエリは変換されるＵＲＩを含み、図１で矢印１０８によって示されるローカルキャッシュ及びＤＮＳ情報の新しいチェックの後に、プライベートＤＮＳサーバ１２１はＳＩＰ Ｉｎｖｉｔｅ要求１１０をルーティングするためにＵＡ １２０が必要とする情報を提供することができ、この情報は、応答１０９を用いてＵＡ １２０に配送される。

パブリックＤＮＳサーバ１２２がドメイン名を解決できず、従って、プライベートＤＮＳサーバ１２１とパブリックＤＮＳサーバ１２２との両方が要求されたＩＰアドレスを配送できない場合には、このプロセスが停止され、ＵＡ １２０は、Ｉ−ＣＳＣＦ １２３のアドレスを入手できないので、メッセージ１１０をＩ−ＣＳＣＦ １２３にルーティングすることができない。

図２に、本発明の代替実施形態でのメッセージフローを示す。この実施形態は、ＩＭＳネットワーク内のノード２２０、プライベートＤＮＳサーバ２２１、パブリックＤＮＳサーバ２２２、及び外部ＩＭＳネットワーク内のノード２２３を含む。プライベートＤＮＳサーバ２２１及びパブリックＤＮＳサーバ２２２は伝統的なＤＮＳに従って互いにリンクされてはいない。

伝統的なＤＮＳはサーバのツリー様構造によって形成される。最上部には、トップレベルドメイン（ＴＬＤ）に関する情報を有するＤＮＳルートサーバがある。ホスト名を解決する必要があるＤＮＳサーバは、ルートＤＮＳサーバに連絡して、どのＤＮＳサーバが特定のＴＬＤに関して権威があるのかを見つけることができる。ＤＮＳサーバは、ＴＬＤのオーソラテイティブＤＮＳサーバに連絡して、どのＤＮＳサーバが特定のドメインに関して権威があるのかを見つけることができる。次に、ＤＮＳサーバはこのオーソラテイティブＤＮＳサーバに連絡してホスト名を解決する。

このシステムでは、ＤＮＳサーバはお互いを参照することができ、後者は、要求された情報を有するか、それを有する可能性があるＤＮＳサーバを参照することができる。このプロセス全体が、矢印２０２、２０４、及び２０６によって示されるステップ中に発生し得る。ここでの相違は、パブリックＤＮＳ ２２２が伝統的なＤＮＳリフェラルを介して到達可能ではないことである。プライベートＤＮＳサーバ２２１は、ＤＮＳクエリを実行できる通常のパーソナル・コンピュータ・システムの構成に非常に似て、その構成内でパブリックＤＮＳサーバ２２２に連絡する方法に関するある知識を有する。

本発明のこの代替実施形態で、ノード２２０及びノード２２３は、両方ともＩｎｔｅｒｒｏｇａｔｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（Ｉ−ＣＳＣＦ）である。Ｉ−ＣＳＣＦのタスクの１つは、ＩＭＳネットワークへの入口点として働くことである。特定のＩＭＳネットワークの外部のノードはそのＩＭＳネットワークのＩ−ＣＳＣＦに連絡して、そのネットワークにメッセージを送信することができる。

パブリックＤＮＳサーバ２２２はＤＮＳサービスを提供するデフォルト・ソフトウェアアプリケーションである。ｈｔｔｐ：／／ｗｗｗ．ｐｏｗｅｒｄｎｓ．ｃｏｍ／で公開されたＰｏｗｅｒＤＮＳがこの第２の実施形態でパブリックＤＮＳサーバ２２２として使用されると仮定する。パブリックＤＮＳサーバ２２２は一般公衆にＤＮＳサービスを提供するので、パブリックであると考えられる。誰もが特定のＤＮＳ情報の要求をパブリックＤＮＳサーバ２２２に連絡することができる。

プライベートＤＮＳサーバ２２１などのＤＮＳサーバは限られた量のユーザだけに情報を提供するのでプライベートと考えられる。この実施形態では、ＧＲＸによって提供されるＤＮＳサーバはプライベートＤＮＳサーバ２２１であり、ＧＲＸに接続されたオペレータだけがプライベートＤＮＳサーバ２２１に連絡することができる。プライベートＤＮＳサーバ２２１に既知のドメイン名空間は一般に小さいが、パブリックＤＮＳサーバ２２２に既知のドメイン名空間はかなりより大きい。パブリックＤＮＳサーバ２２２は、登録されインターネットに関して使用される全てのドメインに関する知識を有するか、その知識を入手することができる。

プライベートＤＮＳサーバ２２１は、本発明のこの実施形態では、ＤＮＳサービスを提供する、標準ルックアップの一部ではないステップを実行する能力においてＰｏｗｅｒＤＮＳなどの他のＤＮＳソフトウェアアプリケーションとは異なるソフトウェアアプリケーションである。プライベートＤＮＳサーバ２２１はネットワーク内の他のデバイスから特定のＤＮＳ情報に関する要求を伴うクエリを受信し、要求された情報を提供することを試みることができ、これは以下でさらに説明するプロセスである。しかし、プライベートＤＮＳサーバ２２１が、要求がパブリックＤＮＳサーバ２２２だけに既知のドメインに関係するので、要求された情報を提供できない場合に、プライベートＤＮＳサーバ２２１は、例えば図２の要求２０３など、情報に関する要求をパブリックＤＮＳサーバ２２１に連絡することができる。

上で述べたクエリは、情報に関する質問を含むＤＮＳ標準規格に従ってフォーマットされたＤＮＳサーバに送信されるメッセージである。クエリの一例が特定のサーバのＩＰアドレスに関する要求である。クエリを受信するＤＮＳサーバは応答を見つけるためにさまざまなステップを実行することができる。第１ステップを、そのＤＮＳサーバによって維持されるローカルキャッシュ内のルックアップとすることができる。キャッシングは、特定の長さの時間にわたって以前のクエリに関する情報を格納することを意味する。従って、ＤＮＳサーバがクエリに対する回答を提供した場合に、そのＤＮＳサーバは指定された長さの時間にわたって、そのネームサーバに対して行われる全ての後続要求のためにその回答を格納する。これは、ＤＮＳサーバによって他のＤＮＳサーバに対して生成されるトラフィックの量を減らし、ＤＮＳサーバによって処理できるクエリの量を増やす。もう１つのステップは、ＤＮＳサーバが責任を負うドメインに関する情報を調べることとすることができる。ＤＮＳサーバはクエリ内で指定されたドメインの責任を負う場合に、それ自体のデータベースから情報を取り出し、その情報を応答として提供することができる。もう１つのステップは、特定のドメインの権威あるネームサーバを突き止めるために他のＤＮＳサーバに連絡し、その後、必要な情報についてそのネームサーバに連絡することとすることができる。

この第２の実施形態をも、２つの異なるＩＭＳネットワークを参照して説明する。一方のネットワークは、ｏｐｅｒａｔｏｒａ．ｃｏｍドメインを使用し、一般公衆にサービスを提供するパブリックＩＭＳオペレータであるオペレータＡに属する。他方のネットワークはｅｎｔｅｒｐｒｉｓｅｂ．ｃｏｍドメインを使用し、その従業員にＩＭＳサービスを提供する企業Ｂに属する。この実施形態では、オペレータＡのネットワーク内のユーザＡが企業Ｂのネットワーク内のユーザＢにメッセージを送信すると仮定する。このメッセージは両方のユーザの間でセッションを確立するのに使用されるＳＩＰ Ｉｎｖｉｔｅ要求２０８である。Ｉ−ＣＳＣＦ ２２０は、例えばＵＡからＳＩＰ Ｉｎｖｉｔｅ要求を受信し、このＳＩＰ Ｉｎｖｉｔｅ要求を、ＳＩＰ Ｉｎｖｉｔｅ要求で指定される要求ＵＲＩ ｓｉｐ：ｕｓｅｒｂ＠ｅｎｔｅｒｐｒｉｓｅｂ．ｃｏｍを用いてＩ−ＣＳＣＦ ２２３にルーティングする必要がある。Ｉ−ＣＳＣＦ ２２０は、アドレス変換の後に、受信されたＳＩＰ Ｉｎｖｉｔｅ要求をＳＩＰ Ｉｎｖｉｔｅ要求２０８として送信する。

Ｉ−ＣＳＣＦ ２２０は、ＳＩＰ Ｉｎｖｉｔｅ要求２０８をＩ−ＣＳＣＦ ２２３に送信できるようになる前に、Ｉ−ＣＳＣＦ ２２３のＩＰアドレスを必要とする。従って、Ｉ−ＣＳＣＦ ２２０は、ｓｉｐ：ｕｓｅｒｂ＠ｅｎｔｅｒｐｒｉｓｅｂ．ｃｏｍを解決する要求を伴うクエリ２０１をプライベートＤＮＳサーバ２２１に発行し、Ｉ−ＣＳＣＦ ２２０はプライベートＤＮＳサーバ２２１からの回答内でＩ−ＣＳＣＦ ２２３のＩＰアドレスを期待する。プライベートＤＮＳサーバ２２１は、図１の矢印２０２によって示されるように、ローカルキャッシュ及びプライベートＤＮＳ情報を使用してこのＵＲＩを解決することを試みる。しかし、プライベートＤＮＳサーバ２２１はｅｎｔｅｒｐｒｉｓｅｂ．ｃｏｍドメインについて知らず、要求された情報を提供することができない。プライベートＤＮＳサーバ２２１はｅｎｔｅｒｐｒｉｓｅｂ．ｃｏｍに連絡するのに使用できる代替ドメインを発見するために、クエリ２０３をパブリックＤＮＳサーバ２２２に連絡することができる。パブリックＤＮＳサーバ２２２は、図２の矢印２０４によって示されるように、ｅｎｔｅｒｐｒｉｓｅｂ．ｃｏｍを含む全てのＳＩＰ ＵＲＩをｏｐｅｒａｔｏｒｃ．ｃｏｍを含むＵＲＩに変換するＮＡＰＴＲレコードを有する。この実施形態では、ｏｐｅｒａｔｏｒｂ．ｃｏｍは、別のパブリックＩＭＳオペレータＣに属し、このオペレータＣは企業ＢとのＩＭＳルーティング・サービスを提供する合意を有する。オペレータＣはパブリックＩＭＳオペレータなので、プライベートＤＮＳサーバ２２１によって既知である。あるドメインから別のドメインへの変換はローカルキャッシュ又はＤＮＳ情報を使用して行うことができ、図１の矢印２０４によって示されている。パブリックＤＮＳサーバ２２２は新しいＵＲＩ、例えばｓｉｐ：ｕｓｅｒｂ＠ｏｐｅｒａｔｏｒｃ．ｃｏｍを含む応答をパブリックＤＮＳサーバ２２１に送信する。次に、プライベートＤＮＳサーバ２２１は、矢印２０６によって示されるように、ローカルキャッシュ及びＤＮＳ情報を使用してこの新しいＵＲＩを解決することができる。ｏｐｅｒａｔｏｒｃ．ｃｏｍドメインは、プライベートＤＮＳサーバ２２１に既知であり、従って、プライベートＤＮＳサーバ２２１は応答２０７でＩ−ＣＳＣＦ ２２０にＩＰアドレスを提供することができる。このＩＰアドレスを使用して、Ｉ−ＣＳＣＦ ２２０は、ＳＩＰ Ｉｎｖｉｔｅ要求をオペレータＣに送信することができ、オペレータＣはそのメッセージをＩ−ＣＳＣＦ ２２３に配送する。

図１の矢印１０７、１０８、及び１０９並びに図２の矢印２０６が必要ではないことを認めることが重要である。これらの矢印は、パブリックＤＮＳサーバ１２２又は２２２がそれぞれプライベートＤＮＳサーバ１２１又は２２１に既知のドメイン名を返し、これらのＤＮＳサーバがそのドメイン名を解決するためにもう１つの試みを実行する必要があることを示す。パブリックＤＮＳサーバ１２２又は２２２を介して要求元デバイス（１２０又は２２０）に直接にＩＰアドレスを提供することによって、あるセキュリティを放棄することが可能である。これは、会社がそれ自体の公に既知のドメインを使用することを可能にすることによって所望の柔軟性を提供する。

前の図に描かれたＤＮＳサーバブロックがＤＮＳサーバの集合を表す場合があることに留意されたい。複数のＤＮＳサーバが、クエリが受信された後、応答が送信される前に、互いに通信することができる。例えば、ＤＮＳブロックから発し、ＤＮＳブロックに進む矢印は、実際には、複数のメッセージを表す場合がある。この矢印は、例えば、パブリックＤＮＳサーバが、第１にローカルキャッシュをチェックし、第２にルートネームサーバに連絡し、第３にトップレベルドメイン（．ｃｏｍ又は．ｂｅなど）のサーバに連絡し、第４にｓｏｍｅｄｏｍａｉｎ．ｃｏｍの権威あるネームサーバに連絡し、所望の情報を取り出すことを表すことができる。ＰｏｗｅｒＤＮＳ及びＢＩＮＤなどの言及されたＤＮＳアプリケーションは、ＤＮＳサービスを提供するのに使用できる既存ソフトウェアの例にすぎない。ドメイン名からＩＰアドレスへの変換を提供でき、ＮＡＰＴＲレコード及びＳＲＶレコードを実施できる全てのソフトウェア又はデバイスをパブリックＤＮＳサーバ２２２として使用することができる。

ＰｏＣがＩＭＳサービスの一例にすぎないことにさらに留意されたい。もう１つの例は、ユーザがお互いにテキストメッセージを送信することを可能にし、これらのメッセージが受信ユーザに瞬間的に表示されるインスタントメッセージサービスである。一般に、ＩＭＳネットワークを使用するアプリケーションは、ある点でさまざまなＩＭＳネットワークの間の通信を必要とすると期待される。

ＧＲＸインフラストラクチャはプライベートな管理されるネットワークの一例として使用される。この例はＧＰＲＳネットワークにローミング及びＤＮＳサービスを提供する。ＩＭＳネットワークの間の接続を提供でき、アドレス解決サービスを提供できる全てのシステムをＧＲＸの代替物として使用することができる。

ＮＡＰＴＲレコード及びＳＲＶレコードは上の説明で例として使用される。その特徴だけが本発明に重要であり、代替物を使用して、必要な機能性を提供することができる。異なるシステムへのリダイレクションを提供できるかＵＲＩを異なるＵＲＩに変換できる、あるいは特定のドメインに基づいて異なるドメインを取り出すのに使用できる、全てのＤＮＳレコードタイプを本発明の実施形態で使用することができる。

本発明を特定の実施形態を参照して例示してきたが、当業者には、本発明が前述の例示的実施形態の詳細に限定されないことと、本発明を本発明の趣旨及び範囲から逸脱せずにさまざまな変更及び修正を加えて実施できることが明白であろう。従って、この実施形態は全ての面において、例示的であって制限的ではないと考えられなければならず、本発明の範囲は前述の説明によるのではなく添付の特許請求の範囲によって示され、従って、特許請求の範囲の意味及び同等性の範囲に含まれる全ての変更は特許請求の範囲に含まれることが意図されている。言い換えると、基本的な基礎になる原理の趣旨及び範囲に含まれ、その本質的属性が本願で請求される全ての修正形態、変形形態、又は同等物を含むことが企図されている。さらに、単語「含む（ｃｏｍｐｒｉｓｉｎｇ又はｃｏｍｐｒｉｓｅ）」が、他の要素又はステップを除外しないことと、単語「１つの（ａ又はａｎ）」が、複数を除外しないことと、コンピュータ・システム又は一体化されたユニットなどの単一の要素が、特許請求の範囲に列挙された複数の手段の機能を満足できることとが、本願の読者によって理解されるであろう。特許請求の範囲の全ての符号は、関係するめいめいの請求項を限定するものと解釈されてはならない。用語「第１」、「第２」、第３」、「１」、「２」、「３」、及び類似物は、この説明又は特許請求の範囲で使用される時に、類似する要素又はステップの間で区別するために導入されるものであって、必ずしも順番又は年代的順序を記述するものではない。そのように使用される用語が適当な情況の下で交換可能であることと、本発明の実施形態が、他のシーケンスで、又は上で説明若しくは図示されたものと異なる方位で、本発明に従って動作できることとを理解されたい。

Claims (4)

1. ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク内又はその間でメッセージをルーティングする際に使用される統一資源識別子（ＵＲＩ）を解決する方法であって、
   ａ．前記ＩＰマルチメディアサブシステムネットワークにメッセージを送信できるデバイス（１２０）からプライベートネームサーバ（１２１）に、前記統一資源識別子を解決するためのクエリ（１０１）を送信するステップ、及び
   ｂ．前記プライベートネームサーバ（１２１）によって前記統一資源識別子を解決する（１０２）ステップ、
   からなり、前記方法が、さらに、
   ｃ．前記プライベートネームサーバ（１２１）による前記統一資源識別子の解決が失敗する場合に、前記統一資源識別子を解決するための新しいクエリ（１０４）を前記デバイス（１２０）からパブリックネームサーバ（１２２）に送信するステップ、
   ｄ．前記パブリックネームサーバ（１２２）によって前記統一資源識別子を解決する（１０５）ステップ、及び
   ｅ．前記デバイス（１２０）によって前記新しいクエリ（１０４）に対する応答（１０６）を受信するステップ
   からなることを特徴とする方法。
2. 請求項１に記載の統一資源識別子（ＵＲＩ）を解決する方法において、前記ステップｄがネーミングオーソリティポインタ（ＮＡＰＴＲ）レコードを使用して、前記統一資源識別子内のドメインを異なるドメインに変換することを含み、
   前記異なるドメインは、前記プライベートネームサーバ（１２１）に知られている、ことを特徴とする方法。
3. 請求項１に記載の統一資源識別子（ＵＲＩ）を解決する方法において、前記ステップｄがＳｅｒｖｉｃｅ（ＳＲＶ）レコードを使用して、前記統一資源識別子内のドメインを異なるドメインに変換することを含み、
   前記異なるドメインは、前記プライベートネームサーバ（１２１）に知られている、ことを特徴とする方法。
4. ＩＰマルチメディアサブシステムネットワーク内でメッセージをルーティングするデバイス（１２０）であって、前記デバイス（１２０）が、
   −統一資源識別子（ＵＲＩ）を解決する（１０２）ためにクエリ（１０１）を定式化できる手段、
   −プライベートネームサーバ（１２１）に前記クエリ（１０１）を送信する手段、及び
   −前記クエリ（１０１）に対する応答（１０３）を解釈する手段
   からなり、前記デバイス（１２０）が、前記プライベートネームサーバからの応答（１０３）が前記プライベートネームサーバ（１２１）による前記統一資源識別子（ＵＲＩ）の解決（１０２）の失敗を示す場合に、前記統一資源識別子（ＵＲＩ）を解決する（１０５）ために新しいクエリ（１０４）を定式化し、前記新しいクエリ（１０４）をパブリックネームサーバ（１２２）に送信するようにさらに適合されることを特徴とするデバイス（１２０）。

Images