JP2012503350A - Ｉｐアドレスの発見 - Google Patents

Abstract

ＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進する方法が提供される。前記ＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持つ。前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換するためにピア・ツー・ピア・ネットワークにアクセス可能である。前記方法は、前記ＳＩＰベース・ネットワークへのゲートウェイの識別子と当該ゲートウェイのＩＰアドレスとの間のマッピングを前記ピア・ツー・ピア・ネットワークに発行するステップを備える。前記識別子は、前記ホスト名部分に対応するか又はそこから導出可能である。前記ＳＩＰベース・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイで問い合わせが受信されると、当該ＵＲＩがコンタクトＩＰアドレスに変換される。前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスが返される。また、ＳＩＰユーザエージェントを提供するように構成される装置、及び、ＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進するゲートウェイ装置も提供される。

Description

本発明は、プライベート・セッション開始プロトコル（ＳＩＰ）ネットワークのユーザと外部ＳＩＰユーザとの間の通信を促進する方法、並びに、ピアＳＩＰユーザエージェントにコンタクトするためのＳＩＰユーザエージェントを提供するように構成される装置、プライベートＳＩＰベース・ネットワークのユーザをピア・ツー・ピアＳＩＰベース・ネットワークに対して相互接続するためのゲートウェイ、及び、ピア・ツー・ピアＳＩＰベース・ネットワークのノードに関する。

分散コンピューティングは、分散データ構造内部の全ての協働するネットワークノード間の恒常的な相互作用を必要とする。サーバはボトルネックにも単一障害点にもなり得るので、伝統的なクライアント−サーバベースのアプローチを使用してネットワークノード間のそのような恒常的な相互作用を提供することは不可能である。この理由により、全てのネットワークノードが同等の役割を担う、所謂ピア・ツー・ピア（Ｐ２Ｐ）ネットワークが提案されてきた。Ｐ２Ｐネットワークでは、全てのネットワークノードがクライアント機能及びサーバ機能の両方を組み込んでおり、各ノードがネットワーク内の他のノードに対して直接要求を行うという意味において、全てのネットワークノードは対等である。

協働ネットワーク環境では、共通のデータリポジトリが必要とされ、このデータリポジトリもＰ２Ｐ手段によって実装可能である。このデータリポジトリのために分散ハッシュテーブル（ＤＨＴ）が使用され、ハッシュ関数を利用してデータキーが座標空間(coordinate space)にマッピングされ座標空間が参加ノード間で分散される。ルーティングアルゴリズムは、空間の所与のセグメントを担当するノードを発見すること、従って問い合わされた(queried)キーを発見すること、を担う。ＤＨＴアプリケーションの中には、所謂コンシステント・ハッシュ法(consistent hashing)を使用するものがある。コンシステント・ハッシュ法では、キー及びノード識別子を同一の座標空間にマッピングするために同一のハッシュ関数が使用され、空間区間(space partition)をノードにマッピングするために距離メトリックが使用される。そのようなアプリケーションでは、参加ノードは、固有の識別子によって識別されるが、自分たちのネットワークアドレスを用いてアドレス指定される。それゆえ、ネットワーク内の各ノードは、他の参加ノードと通信可能になるためには、データのトリプレット（固有の識別子、ＩＰアドレス、ポート番号）を必要とする。

そのようなＤＨＴが実装されたデータ構造の１つは、I. Stoica, R. Morris, D. Karger, F. Kaashoek and H. Balakrishnan, "Chord: A scalable peer-to-peer lookup service for internet applications", Proceedings of SIGCOMM'01, 2001によって開示される、所謂Chordリング構造である。Chordリング構造では、使用される識別子空間は円であり、最大の識別子及び最小の識別子は隣接するノードを表し、識別子は、最小のものから最大のものへと、時計回りに組織される。更に、そのようなChordリング構造では、特定のノードと直接隣り合う２つの隣接ノードは、その特定のノードの「先行者(predecessor)」及び「後行者(successor)」と呼ばれ、前者は反時計回り方向の隣接ノードであり、後者は時計回り方向の隣接ノードである（即ち、最小の識別子を持つノードを除く全てのノードにとって、特定のノードの先行者は、その特定のノードよりも小さい識別子を持つノードの中では最大の識別子を持つノードであり、最小の識別子を持つノードにとっては、そのノードの先行者は全てのノードの中で最大の識別子を持つノードである）。特定のノードの後行者も同様に定められるが、ノードの順序付けは反対方向になる。

加えて、そのようなChordリング構造では、ネットワークに参加している全てのノードが、自分自身の識別子（それ自体を含む）と先行者の識別子（それ自体を除く）との間の識別子空間区間を担当するようになる。ノードの挿入、及び、データ項目を求めるためのこの区間のキーを伴う要求は全て、この特定のノードのアドレスへと転送されることになる。

この領域における研究の多くは、ＤＨＴアルゴリズムを改良すること、又は、ファイル共有アプリケーション（例えば、BitTorrent及びeMule）を開発することに重点を置いてきていた。最近まで、個人間の通信（例えば、音声電話及びマルチメディア電話）のためにＰ２Ｐ技術を活用することに対しては、あまり努力の重点が置かれてこなかった。しかしながら、Ｐ２Ｐネットワークにおけるそのような個人間通信を可能にするであろうプロトコルを標準化する、進行中の努力がある。これらの標準化の努力は、ＩＥＴＦ(Internet Engineering Task Force)のＰ２ＰＳＩＰ(Peer-to-Peer Session Initiation Protocol)ワーキンググループで行われている。このワーキンググループの今日までの成果として、
1) D. Bryan, P. Matthews, E. Shim, D. Willis, Concepts and Terminology for Peer to Peer SIP, November 2007, draft-ietf-p2psip-concepts-01 (http://tools.ietf.org/id/draft-ietf-p2psip-concepts-01.txt) 及び
2) E. Marocco, D. Bryan, Interworking between P2PSIP Overlays and Conventional SIP Networks, March 2007, draft-marocco-p2psip-interwork-01 (http://tools.ietf.org/id/draft-marocco-p2psip-interwork-01.txt)
が挙げられる。

ユーザがピア・ユーザの位置を特定して接続することができる独立したＰ２ＰＳＩＰネットワークを構築することは可能であるかもしれないが、所与のＰ２ＰＳＩＰの中のユーザが他のＰ２ＰＳＩＰネットワークの中のユーザやＩＭＳネットワークや伝統的なクライアント／サーバネットワークの中のユーザと通信できるようにするためには、少なくとも一部のネットワークがゲートウェイ経由で既存のＳＩＰベース・ネットワークに接続されることが期待される。

Ｐ２Ｐネットワークの相互接続を可能にするソリューションが、Marocco及びBryanによって提示されている（上記を参照）。これは、ドメイン・ネーム・システム（ＤＮＳ）に登録されたプロキシを使用することにより、相互接続を可能にする。所与のＰ２ＰＳＩＰネットワークについて、外部ＵＲＩに宛てられた問い合わせは、ローカルプロキシへ転送される。するとプロキシは、ＤＮＳに問い合わせることで、その外部ＵＲＩを担当するプロキシのＩＰアドレスを決定する。このＩＰアドレスがＰ２ＰＳＩＰネットワーク内の問い合わせ元のユーザへ返されることで、そのユーザは、例えばＳＩＰ ＩＮＶＩＴＥをリモートプロキシへ転送することができる。リモートプロキシはその招待要求をリモートユーザへ転送する。しかしながら、このソリューションに伴う潜在的な問題は、各プロキシが有効なＤＮＳドメイン名を持つ必要があるということである。このことは、ダイナミック環境（例えば、プロキシのＩＰアドレスがしばしば変化する環境）やアドホック環境（例えば、大規模な会議やスポーツのイベント）には適していない。

本発明の目的は、少なくとも１つがＰ２ＰＳＩＰネットワークを含む複数のＳＩＰベース・ネットワークの相互接続を可能にすることである。これは、識別子及びゲートウェイＩＰアドレスをＰ２ＰＳＩＰネットワークに登録可能なゲートウェイを提供することにより達成される。ここで、識別子は、ホスト名部分に対応するか、又は、ホスト名部分から導出可能である。

本発明の第１の態様によれば、ＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進する方法が提供される。前記ＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持つ。前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換(resolve)するためにピア・ツー・ピア・ネットワークにアクセス可能である。前記方法は、前記ＳＩＰベース・ネットワークへのゲートウェイの識別子と当該ゲートウェイのＩＰアドレスとの間のマッピングを前記ピア・ツー・ピア・ネットワークに発行するステップを備える。前記識別子は、前記ホスト名部分に対応するか又はそこから導出可能である。前記ＳＩＰベース・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイで問い合わせが受信されると、当該ＵＲＩがコンタクトＩＰアドレスに変換される。前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスが返される。前記ＵＲＩをコンタクトＩＰアドレスに変換する前記ステップは、前記ＳＩＰベース・ネットワークのピア・ツー・ピア・ネットワークにおける検索を実行するステップを含んでもよい。

理解されるであろうこととして、前記ＳＩＰベース・ネットワークは任意の適切なＳＩＰネットワークであってよく、例えば、ＩＰマルチメディア・サブシステム・ネットワーク、又は、クライアント−サーバＳＩＰベース・ネットワークである。

前記問い合わせは、外部のＳＩＰユーザから受信されてもよい。或いは、前記問い合わせは、更なるゲートウェイから受信されてもよい。後者の場合、前記問い合わせは、当該更なるゲートウェイの後ろにいるＳＩＰユーザに代わって送信される。

幾つかの実施形態においては、前記ＳＩＰベース・ネットワークは、更なるピア・ツー・ピア・ネットワークを含んでもよい。これらの実施形態においては、最初に言及した前記ピア・ツー・ピア・ネットワークの各ユーザは、第２のホスト名部分を含むＳＩＰ ＵＲＩを持つ。これらの実施形態に従う前記方法は、前記ゲートウェイの識別子と前記ゲートウェイのＩＰアドレスとの間のマッピングを前記更なるピア・ツー・ピア・ネットワークに発行するステップを備える。当該識別子は、前記第２のホスト名部分に対応するか又はそこから導出可能である。最初に言及された前記ピア・ツー・ピア・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイで問い合わせが受信されると、当該ＵＲＩがコンタクトＩＰアドレスに変換される。前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスが返される。

前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークの各々にマッピングを発行する前記ステップは、前記ゲートウェイを前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークに登録するステップを含んでもよい。

前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークの各々は、オーバーレイネットワークであってもよい。前記オーバーレイネットワークは、分散ハッシュテーブル（ＤＨＴ）ベースのアドレス指定メカニズムを採用してもよく、こうすると、前記オーバーレイネットワークは分散ハッシュテーブルベースのネットワークである。前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークの各々が分散ハッシュテーブルベースのネットワークである場合、マッピングは、ＳＩＰ ＵＲＩをハッシュ関数に通すことで得られる値を用いてネットワーク全体に分散され、前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークの各々の１以上のノードに格納され得る。

幾つかの実施形態では、前記ゲートウェイで受信される前記問い合わせは、Ｐ２ＰＳＩＰ（ピア・ツー・ピアＳＩＰ）ｇｅｔメッセージである。

前記コンタクトＩＰアドレスへ宛てられ前記ゲートウェイで受信されたＳＩＰメッセージは、前記ＳＩＰベース・ネットワーク内の宛先ＳＩＰユーザへ転送することができる。理解されるであろうこととして、これらのＳＩＰメッセージは、前記問い合わせの発信元のノードへ前記コンタクトＩＰアドレスが返された後で、転送される。

本発明の第２の態様によれば、ＳＩＰユーザエージェントを提供するように構成される装置が提供される。前記装置は、登録ユニットと、ＳＩＰセッション開始器と、検出器と、ＩＰアドレス変換ユニットと、を備える。前記登録ユニットは、前記ＳＩＰユーザエージェントをローカル・ピア・ツー・ピアＳＩＰベース・ネットワークに登録するためのものであり、前記ＳＩＰセッション開始器は、ピアＳＩＰユーザエージェントとのＳＩＰセッションを開始するためのものである。前記検出器は、前記ピアＳＩＰユーザエージェントのＳＩＰ ＵＲＩから、当該ピアＳＩＰユーザエージェントが外部ドメインに所属するか否かを検出するためのものである。前記ＩＰアドレス変換ユニットは、前記ピアＳＩＰユーザエージェントが外部ドメインに所属する場合に、前記ローカル・ピア・ツー・ピア・ネットワークと前記外部ドメインとを相互接続するゲートウェイのＩＰアドレスを取得するために、前記ＳＩＰ ＵＲＩのホスト部分を使用して前記ローカル・ピア・ツー・ピア・ネットワークに対して問い合わせを行うように構成される。前記ＩＰアドレス変換ユニットはまた、前記ピアＳＩＰユーザエージェントのコンタクトＩＰアドレスを取得するために、前記ＩＰアドレスを使用して前記ゲートウェイに問い合わせを行うように構成される。前記ＳＩＰセッション開始器は、前記受信したコンタクトＩＰアドレスを使用して前記ピアＳＩＰユーザエージェントに対してセッション開始メッセージを送信するように更に構成される。前記ローカル・ピア・ツー・ピアＳＩＰベース・ネットワークは、分散ハッシュテーブルベースのネットワークであってもよい。

本発明の第３の態様によれば、ＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進するゲートウェイ装置が提供される。前記ＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持つ。前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換するためにピア・ツー・ピア・ネットワークにアクセス可能である。前記ゲートウェイ装置は、発行ユニットとＩＰアドレス変換ユニットとを備える。前記発行ユニットは、前記ゲートウェイ装置の識別子とＩＰアドレスとの間のマッピングを前記ピア・ツー・ピア・ネットワークに発行するためのものである。前記識別子は、前記ホスト名部分に対応するか又はそこから導出可能である。前記ＩＰアドレス変換ユニットは、前記ＳＩＰベース・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイ装置で問い合わせが受信されると、当該ＵＲＩをコンタクトＩＰアドレスに変換するように構成される。前記ＩＰアドレス変換ユニットは、前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスを返すように更に構成される。

前記ＩＰアドレス変換ユニットは、前記ＳＩＰベース・ネットワークのピア・ツー・ピア・ネットワーク内で問い合わせを実行することにより、前記ＵＲＩをコンタクトＩＰアドレスに変換するように構成されてもよい。

本発明の第４の態様によれば、プライベートＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進する方法が提供される。前記プライベートＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持つ。前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換するためにピア・ツー・ピア・ネットワークにアクセス可能である。前記方法は、前記プライベートＳＩＰベース・ネットワークのゲートウェイのＩＰアドレスと前記ホスト名部分との関連付けを前記ピア・ツー・ピアＳＩＰベース・ネットワークに発行するステップを備える。前記外部のＳＩＰユーザの１人においてピア・ツー・ピア・セッションが開始される。前記ホスト名部分に関して前記ピア・ツー・ピアＳＩＰベース・ネットワークに第１の検索要求が送信される。それに応えて前記ゲートウェイの前記ＩＰアドレスが外部のＳＩＰユーザへ返される。提供されたＩＰアドレスを使用して、更なる検索要求が前記ゲートウェイへ送信される。当該検索要求は、前記プライベートＳＩＰベース・ネットワークの内部のユーザのＳＩＰ ＵＲＩ、又は当該ＳＩＰ ＵＲＩの派生物を含む。前記内部のユーザのＩＰアドレスが前記外部のＳＩＰユーザへ返される。前記ピア・ツー・ピア・ネットワークは分散ハッシュテーブルベースのネットワークであってもよい。

ＩＭＳネットワーク、クライアント−サーバＳＩＰベース・ネットワーク、及びＰ２ＰＳＩＰネットワークの間の相互接続を可能にするゲートウェイを概略的に示す。 ゲートウェイの登録手順を示すシグナリングフローである。 セッション確立からのシグナリングフローである。 Ｐ２ＰＳＩＰ ＵＡにおける手順を概略的に示す。 ゲートウェイにおける手順を概略的に示す。

Ｐ２ＰＳＩＰネットワークは、そこに登録しているメンバーのコンタクトアドレスを維持管理することになる。ＤＨＴベースのネットワークの場合、これが意味することは、各メンバーについて、ネットワークがＵＲＩ(Universal Resource Identifier)とＩＰアドレスとの間のマッピングを維持管理するということである。マッピング情報は、ＵＲＩに対してハッシング(hashing)を適用することにより、オーバーレイネットワークの複数のノードのあちこちへ分散される。例として、企業ＬＡＮの中に実装されたＰ２ＰＳＩＰネットワークを考える。ＬＡＮはホスト名（例えば、"example.com"）に関連付けられており、そうすることで、ＬＡＮのユーザはそれぞれ、"user.name@example.com"という形式のＵＲＩを持つ。もちろん、他のドメイン内のユーザ（即ち、その企業ＬＡＮの外部のユーザ）は、このＰ２ＰＳＩＰネットワークのメンバーではなく、このネットワークは彼らのＩＰアドレスに関する知識を持たない。

Ｐ２Ｐ環境において複数のＵＲＩベースのネットワークを接続するためのメカニズム（ここでは”ＵＲＩＣｏｎｎ”と呼ぶ）をここで説明する。このメカニズムは、スタティック環境、ダイナミック環境、及びアドホック環境に適している。このメカニズムの動作の利点は、このメカニズムがドメイン・ネーム・システム（ＤＮＳ）の使用に依存しないことである。

図１は、ＵＲＩＣｏｎｎゲートウェイと呼ばれるゲートウェイがＩＭＳネットワーク、伝統的なクライアント−サーバＳＩＰベース・ネットワーク、及びＰ２ＰＳＩＰネットワークの間の相互接続を可能にする、ハイレベルのシナリオを提示する。注目すべきこととして、ＵＲＩＣｏｎｎメカニズムは、前述のネットワークには限定されない。実際、ＵＲＩＣｏｎｎメカニズムは、ユーザをアドレス指定する（実施形態によってはＥメールを含む）ためにＵＲＩを使用するあらゆるネットワークと共に使用可能である。例として、２つのＰ２ＰＳＩＰネットワークの相互接続に関するシナリオを考える。第１のネットワークはホスト名"alpha.com"に関連付けられており、第２のネットワークはホスト名"beta.com"に関連付けられている。

相互接続を可能にするための準備ステップは、ＵＲＩＣｏｎｎゲートウェイが自分自身を両方のＰ２ＰＳＩＰネットワークに登録することである。登録の後で、ゲートウェイはセッション確立を支援することができる。ＵＲＩＣｏｎｎゲートウェイの登録手順を示すシグナリングフローを図２に示す。これらの手順は、例えば、C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, REsource LOcation And Discovery (RELOAD), July 2008, draft-ietf-p2psip-reload-00 (http://tools.ietf.org/id/draft-ietf-p2psip-reload-00.txt)においてＰ２ＰＳＩＰのために提案される"Store"メッセージとして実装可能な、"put"メッセージを利用する。ゲートウェイが登録を行えるようになる前に、ゲートウェイは接続先のネットワークのドメイン名を知らなければならない。このことは、例えば相互設定(manual configuration)により達成可能である。

図２におけるメッセージ及び関連する手順は、以下の通りである。

１．ゲートウェイがalpha.comネットワークへｐｕｔ要求を送信する。このｐｕｔ要求は、ゲートウェイのＩＰアドレスとbeta.comドメイン名との間のバインドを含む。
２．単数又は複数の中間ノードが、Ｈ（beta.com）を担当するオーバーレイネットワークノードへｐｕｔ要求を転送する。ここで、Ｈはハッシュ関数を示す。
３．要求に対する応答。
４．転送される応答。

これで、alpha.comネットワークに対するＵＲＩＣｏｎｎゲートウェイの登録が完了する。

５．次にゲートウェイは、beta.comネットワークへｐｕｔ要求を送信する。このｐｕｔ要求は、ゲートウェイのＩＰアドレスとalpha.comドメイン名との間のバインドを含む。
６．単数又は複数の中間ノードが、Ｈ（alpha.com）を担当するノードへｐｕｔ要求を転送する。
７．要求に対する応答。
８．転送される応答。

これで、beta.comネットワークに対するＵＲＩＣｏｎｎゲートウェイの登録が完了する。

理解されるであろうこととして、ＵＲＩＣｏｎｎゲートウェイがＰ２ＰＳＩＰネットワーク及びＩＭＳネットワークを相互接続する場合、ｐｕｔ要求はＩＭＳ側には必要でない。そうではなく、ゲートウェイは、ＩＭＳネットワークの管理者によって、ＩＭＳ側に相互登録することができる。

登録手順（図２）の完了に続いて、ＵＲＩＣｏｎｎゲートウェイに接続された複数のネットワークのうちの１つのネットワークのユーザが、セッション確立を開始することができる。セッション確立手順の一例を、図３のシグナリングフローによって示す。図３において、メッセージ及び関連する手順は、以下の通りである。

１．alpha.comネットワークの中の発呼者が、john.doe@beta.comに対するセッション確立を開始する。Ｐ２ＰＳＩＰ ＵＡは、Ｒｅｑｕｅｓｔ−ＵＲＩの評価を行い、被呼者が異なるネットワークに位置すると判断する。ＵＡは、beta.comに関連付けられたＩＰアドレスを要求するｇｅｔ要求を送信する。この要求の中ではドメイン部分だけが使用されることに注意されたい。この要求は、Ｈ（beta.com）とＵＲＩＣｏｎｎゲートウェイのＩＰアドレスとの間のマッピングを持つ、ローカルＰ２ＰＳＩＰネットワーク内のノードによって受信され、このノードによって応答される。
２．ＵＲＩＣｏｎｎゲートウェイのＩＰアドレスを含む、要求に対する応答。
３．発呼者のＵＡが、ＵＲＩＣｏｎｎゲートウェイのＩＰアドレスに対してｇｅｔ要求を送信する。このｇｅｔ要求は、john.doe@beta.comに関連付けられたＩＰアドレスを要求するものである。この要求の中では、通常通り、ユーザ名部分及びドメイン部分の両方が使用されることに注意されたい。
４．ゲートウェイは、この要求をbeta.comネットワークへ転送する。
５．単数又は複数の中間ノードが、beta.comネットワーク内のＨ（john.doe@beta.com）を担当するノードへｇｅｔ要求を転送する。Ｈ（john.doe@beta.com）を担当するノードは、ネットワーク構成に応じて、被呼者のピア自体であってもよいし、beta.comネットワーク内の他の何らかのノードであってもよい。
６．john.doe@beta.comに関連付けられたＩＰアドレスを含む、要求に対する応答。
７．転送される応答。
８．転送される応答。
９．転送される応答。
１０．発呼者のＵＡが被呼者のＵＡへＳＩＰ ＩＮＶＩＴＥを送信する。
１１．被呼者のＵＡが２００ＯＫにより応答する。

ＳＩＰ ＩＮＶＩＴＥは、例えば、３つの異なる方法のうちの１つを使用してルーティング可能である。その３つとは、１）オーバーレイネットワークを介すること、２）リレーを介すること、及び３）直接、である。最後の方法が最も単純な事例であるため、図３はこの方法を示している。しかしながら、ネットワーク中にネットワークアドレス変換が存在する場合、方法１又は方法２が必要とされる場合もある。

例えばＩＭＳネットワークをbeta.comネットワークに相互接続するためにゲートウェイが使用される場合、発呼者はＩＭＳ側にいるので、メッセージ１から３及び８から９は必要とされない。発呼者のＩＭＳユーザエージェント（ＵＡ）は、ＳＩＰ ＩＮＶＩＴＥを直接送信可能であり、ＩＭＳネットワークがこれをゲートウェイへルーティングすることになる。

図４は、Ｐ２ＰＳＩＰ ＵＡ１の様々な機能コンポーネントを示す。最初に、アプリケーションレイヤ上の通信アプリケーション２は、所与のＵＲＩへメッセージを送信したいという要望を表現する。その後、Ｐ２Ｐモジュール３は、Ｒｅｑｕｅｓｔ−ＵＲＩの評価を行う。Ｐ２Ｐモジュール内の決定ユニット４は、Ｒｅｑｕｅｓｔ−ＵＲＩがＰ２ＰＳＩＰ ＵＡ自身と同じネットワークに所属するか否かを判定する。そうであれば、ローカルルーティングユニット５によって通常のＰ２ＰＳＩＰ ＵＡ手順が適用される。反対に、Ｒｅｑｕｅｓｔ−ＵＲＩが他の何らかのネットワークに所属する場合、外部ルーティングユニット６によって以下の手順が実行される。

最初に、ホスト名部分だけを伴うｇｅｔ要求が送信される。この要求に対する応答は、ゲートウェイのＩＰアドレスを含む。その後、今回はユーザ名部分及びホスト名部分の両方を伴う別のｇｅｔ要求がゲートウェイへ直接送信される。するとゲートウェイは、所与のＵＲＩに関連付けられたＩＰアドレスで応答する。その後、アプリケーションレイヤ・メッセージをそのＩＰアドレスへ送信することができる。

ＵＲＩＣｏｎｎゲートウェイの中に実装される手順を、ゲートウェイの機能コンポーネントと共に、図５に示す。ゲートウェイは、メッセージを転送する際に通常のＰ２ＰＳＩＰ ＵＡとして振る舞ってもよいし、ゲートウェイとして振る舞ってもよい。ゲートウェイは、Ｐ２ＰＳＩＰ ＵＡによって実行されるのと同種のＲｅｑｕｅｓｔ−ＵＲＩの評価を実行することにより（即ち、宛先ＵＲＩのホスト名部分がローカルネットワークに所属するか否かを判定することにより）、自身がどのモードで振る舞うべきかを決定する。ゲートウェイモードで振る舞う場合、ゲートウェイは最初に、要求を転送するにはどの物理インタフェースが適切であるかを判断する。その後、ゲートウェイは、自分のルーティング情報データベースから、次ホップのノードのための最良の候補を探す。ルーティング情報データベースは、各ネットワーク毎に異なってもよい（Ｐ２ＰＳＩＰについては、これはオーバーレイルーティングテーブルである）。最後に、ゲートウェイはメッセージを次ホップのノードへ転送する。

図５は、ゲートウェイ１０によって受信されるメッセージがalpha.comネットワークから来る場合を示す。ゲートウェイ内の決定ユニット１１が最初に、宛先ＵＲＩのホスト名がローカルホスト名であるか否かを判定する。そうであれば、メッセージはローカルルーティングユニット１２へ渡され、alpha.comネットワーク内の次ホップのノードへ転送される。そうでなければ、メッセージはゲートウェイ処理ユニット１３へ渡され、ゲートウェイ処理ユニット１３は、beta.comネットワーク内の次ホップのノードを判定してメッセージをそのネットワークへ転送する。ゲートウェイはまた、登録ユニット１４も備える。登録ユニット１４は、alpha.comのＰ２Ｐネットワークの中に、自分のＩＰアドレスとbeta.comホスト部分との間のマッピングを発行(publish)するように構成される。

幾つかの実施形態においては、ゲートウェイは「対称的に」機能可能であり、図５の転送機能を２つの（又はそれ以上の）側のネットワークに提供する。やはり注目すべきこととして、ゲートウェイがＩＭＳネットワーク内で使用される場合、ＩＭＳ端末（ＵＡ）は変更を必要としない。一緒に、ＩＭＳネットワーク及びＵＲＩＣｏｎｎゲートウェイは、ＩＭＳ ＵＡに対して透過的にネットワーク相互接続(internetwork)の振る舞いを行う。

上述の相互接続手順に関する潜在的な利点は、次のように要約することができる。
・この方法はダイナミック環境及びアドホック環境に適している。
・この方法が持つオーバーヘッドは低い（例えば、この方法は過度に多くのシグナリングを生じさせはしない）。
・この方法は、少なくとも幾つかのシナリオにおいては、ＩＭＳ端末のような既存のエンドユーザ端末を用いて使用可能である。
・この方法は、ＤＮＳの使用に依存しない。
・この方法は、ユーザをアドレス指定するためにＵＲＩを使用する任意のネットワークで使用可能である。

本明細書で引用した参考文献は、本願と矛盾しない限りにおいて、ここにその全体が組み込まれる。

当業者によって理解されるであろうこととして、本発明の範囲から逸脱することなしに、上述の実施形態に対して様々な変更を行うことができる。例えば、プライベートＳＩＰベース・ネットワーク（Ｐ２ＰＳＩＰ、ＩＭＳ、クライアントサーバ、等）を、個々のＵＲＩＣｏｎｎゲートウェイ経由で共有Ｐ２ＰＳＩＰネットワークに結合することができる。このシナリオにおいて、各ゲートウェイは共有Ｐ２ＰＳＩＰネットワークに別々に登録する。共有Ｐ２ＰＳＩＰネットワークに直接アクセスすることにより（リモート・ピアＳＩＰユーザの）ゲートウェイＩＰアドレスを判断するのではなく、ユーザは、自分自身のＵＲＩＣｏｎｎゲートウェイ経由でこれを行う。

Claims (16)

1. ＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進する方法であって、
   前記ＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持ち、
   前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換するためにピア・ツー・ピア・ネットワークにアクセス可能であり、
   前記方法は、前記ＳＩＰベース・ネットワークへのゲートウェイの識別子と当該ゲートウェイのＩＰアドレスとの間のマッピングを前記ピア・ツー・ピア・ネットワークに発行するステップを備え、前記識別子は、前記ホスト名部分に対応するか又はそこから導出可能であり、
   前記方法は、前記ＳＩＰベース・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイで問い合わせが受信されると、当該ＵＲＩをコンタクトＩＰアドレスに変換するステップと、前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスを返すステップと、を備える
   ことを特徴とする方法。
2. 前記ＵＲＩをコンタクトＩＰアドレスに変換する前記ステップは、前記ＳＩＰベース・ネットワークのピア・ツー・ピア・ネットワークにおける検索を実行するステップを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記ＳＩＰベース・ネットワークは、ＩＰマルチメディア・サブシステム・ネットワーク、又は、クライアント−サーバＳＩＰベース・ネットワークである
   ことを特徴とする請求項１に記載の方法。
4. 前記問い合わせは、外部のＳＩＰユーザから受信される
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記問い合わせは、更なるゲートウェイから受信され、当該更なるゲートウェイの後ろにいるＳＩＰユーザに代わって送信される
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
6. 前記ＳＩＰベース・ネットワークは、更なるピア・ツー・ピア・ネットワークを含み、
   最初に言及された前記ピア・ツー・ピア・ネットワークの各ユーザは、第２のホスト名部分を含むＳＩＰ ＵＲＩを持ち、
   前記方法は、前記ゲートウェイの識別子と前記ゲートウェイのＩＰアドレスとの間のマッピングを前記更なるピア・ツー・ピア・ネットワークに発行するステップを備え、当該識別子は、前記第２のホスト名部分に対応するか又はそこから導出可能であり、
   前記方法は、最初に言及された前記ピア・ツー・ピア・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイで問い合わせが受信されると、当該ＵＲＩをコンタクトＩＰアドレスに変換するステップと、前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスを返すステップと、を備える
   ことを特徴とする請求項１に記載の方法。
7. 前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークの各々にマッピングを発行する前記ステップは、前記ゲートウェイを前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークに登録するステップを含む
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記ピア・ツー・ピア・ネットワーク、又は、前記ピア・ツー・ピア・ネットワーク及び前記更なるピア・ツー・ピア・ネットワークの各々は、分散ハッシュテーブルベースのネットワークであり、マッピングは、ＳＩＰ ＵＲＩをハッシュ関数に通すことで得られる値を用いてネットワーク全体に分散される
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記ゲートウェイで受信される前記問い合わせは、Ｐ２ＰＳＩＰ ｇｅｔメッセージである
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記コンタクトＩＰアドレスを返す前記ステップに続いて、当該コンタクトＩＰアドレスへ宛てられ前記ゲートウェイで受信されたＳＩＰメッセージを、前記ＳＩＰベース・ネットワーク内の宛先ＳＩＰユーザへ転送するステップを備える
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. ＳＩＰユーザエージェントを提供するように構成される装置であって、
    前記ＳＩＰユーザエージェントをローカル・ピア・ツー・ピアＳＩＰベース・ネットワークに登録する登録ユニットと、
    ピアＳＩＰユーザエージェントとのＳＩＰセッションを開始するＳＩＰセッション開始器と、
    前記ピアＳＩＰユーザエージェントのＳＩＰ ＵＲＩから、当該ピアＳＩＰユーザエージェントが外部ドメインに所属するか否かを検出する検出器と、
    前記ピアＳＩＰユーザエージェントが外部ドメインに所属する場合に、
    前記ローカル・ピア・ツー・ピア・ネットワークと前記外部ドメインとを相互接続するゲートウェイのＩＰアドレスを取得するために、前記ＳＩＰ ＵＲＩのホスト部分を使用して前記ローカル・ピア・ツー・ピア・ネットワークに対して問い合わせを行い、
    前記ピアＳＩＰユーザエージェントのコンタクトＩＰアドレスを取得するために、前記ＩＰアドレスを使用して前記ゲートウェイに問い合わせを行う、
    ＩＰアドレス変換ユニットと、
    を備え、
    前記ＳＩＰセッション開始器は、前記受信したコンタクトＩＰアドレスを使用して前記ピアＳＩＰユーザエージェントに対してセッション開始メッセージを送信するように更に構成される
    ことを特徴とする装置。
12. 前記ローカル・ピア・ツー・ピアＳＩＰベース・ネットワークは、分散ハッシュテーブルベースのネットワークである
    ことを特徴とする請求項１１に記載の装置。
13. ＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進するゲートウェイ装置であって、
    前記ＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持ち、
    前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換するためにピア・ツー・ピア・ネットワークにアクセス可能であり、
    前記ゲートウェイ装置は、前記ゲートウェイ装置の識別子とＩＰアドレスとの間のマッピングを前記ピア・ツー・ピア・ネットワークに発行する発行ユニットを備え、前記識別子は、前記ホスト名部分に対応するか又はそこから導出可能であり、
    前記ゲートウェイ装置は、前記ＳＩＰベース・ネットワークの前記ユーザの１人に関連付けられたＵＲＩに関して前記ゲートウェイ装置で問い合わせが受信されると、当該ＵＲＩをコンタクトＩＰアドレスに変換するＩＰアドレス変換し、前記問い合わせの発信元のノードに対して当該コンタクトＩＰアドレスを返すＩＰアドレス変換ユニットを備える
    ことを特徴とするゲートウェイ装置。
14. 前記ＩＰアドレス変換ユニットは、前記ＳＩＰベース・ネットワークのピア・ツー・ピア・ネットワーク内で問い合わせを実行することにより、前記ＵＲＩをコンタクトＩＰアドレスに変換するように構成される
    ことを特徴とする請求項１３に記載のゲートウェイ装置。
15. プライベートＳＩＰベース・ネットワークのユーザと当該ネットワークの外部のＳＩＰユーザとの間の通信を促進する方法であって、
    前記プライベートＳＩＰベース・ネットワークの各ユーザは、当該ネットワークに所属するホスト名部分とユーザ名部分とを含むＳＩＰ ＵＲＩを持ち、
    前記外部のＳＩＰユーザは、ＳＩＰ ＵＲＩをコンタクトＩＰアドレスに変換するためにピア・ツー・ピア・ネットワークにアクセス可能であり、
    前記方法は、
    ａ）前記プライベートＳＩＰベース・ネットワークのゲートウェイのＩＰアドレスと前記ホスト名部分との関連付けを前記ピア・ツー・ピアＳＩＰベース・ネットワークに発行するステップと、
    ｂ）前記外部のＳＩＰユーザの１人においてピア・ツー・ピア・セッションを開始し、前記ホスト名部分に関して前記ピア・ツー・ピアＳＩＰベース・ネットワークに第１の検索要求を送信し、それに応えて前記ゲートウェイの前記ＩＰアドレスを外部のＳＩＰユーザへ返すステップと、
    ｃ）提供されたＩＰアドレスを使用して、前記プライベートＳＩＰベース・ネットワークの内部のユーザのＳＩＰ ＵＲＩ、又は当該ＳＩＰ ＵＲＩの派生物を含む更なる検索要求を前記ゲートウェイへ送信するステップと、
    ｄ）前記内部のユーザのＩＰアドレスを前記外部のＳＩＰユーザへ返すステップと、
    を備えることを特徴とする方法。
16. 前記ピア・ツー・ピア・ネットワークは分散ハッシュテーブルベースのネットワークである
    ことを特徴とする請求項１５に記載の方法。