JP4908724B2 - ピア・ツー・ピア・アプリケーション通信を容易にするための方法および装置 - Google Patents
ピア・ツー・ピア・アプリケーション通信を容易にするための方法および装置 Download PDFInfo
- Publication number
- JP4908724B2 JP4908724B2 JP2002527139A JP2002527139A JP4908724B2 JP 4908724 B2 JP4908724 B2 JP 4908724B2 JP 2002527139 A JP2002527139 A JP 2002527139A JP 2002527139 A JP2002527139 A JP 2002527139A JP 4908724 B2 JP4908724 B2 JP 4908724B2
- Authority
- JP
- Japan
- Prior art keywords
- address
- application
- translation
- network
- area
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2557—Translation policies or rules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の背景】
１．発明の分野
本発明は、インターネット上でデータを交換するアプリケーション間の通信を処理するためのデバイスに関する。より詳細には、本発明は、ネットワーク・アドレス変換（ＮＡＴ：Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）デバイスと、このようなＮＡＴデバイスを用いて、インターネット上でのデータのピア・ツー・ピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）通信を容易にするためのシステムおよび方法と、に関連する。
【０００２】
２．従来技術の説明
図１に示すように、従来の種類のネットワーク・アドレス変換（ＮＡＴ）デバイス２０は、通常、２つの異種のアドレス領域５０と３０との間の境界にある、インターネット・プロトコル（ＩＰ）ネットワーク内に配置されている。一方の領域５０は、民間組織の内部ネットワーク１０であってよく、他方の領域３０は、公衆グローバル・インターネットであってよい。このような従来のデバイスが扱う問題は、組織が、大規模な内部ネットワークを必要とし、そのネットワーク上に、各々が一意のＩＰアドレスを必要とする多くのデバイスを備える場合がある、ということである。現在利用可能な一意のＩＰアドレス（２32通りの利用可能アドレス）のためのアドレス空間、および現在のアドレス割振りパターンを考えると、この組織は、このようなアドレスを割り当てる権威ある機関によって、充分な数の公式ＩＰアドレスを、割り振ってもらえないことがある。したがって、この組織は、実質的に、それ自体の内部ネットワークのための内部的に有効なアドレスを、生成せざるを得ない。これによって、内部ネットワークは、正しく機能するであろう；このような状況において、公式に割り当てられるＩＰアドレスを使用する必要は全くない。その大規模内部ネットワーク中のデバイスまたはアプリケーション（特定のデバイス上で実行しているプログラム）が、グローバル・インターネット（公式に割り当てられたＩＰアドレスを使用している、公衆または民間の任意のＩＰネットワークを意味する）と通信を行うことが必要になったときに、困難が生じる。組織が内部的に割り当てたアドレスは、ある別の組織に属する、公式に割り当てられたアドレスと重複するため、または公式に割り当てられたものではないため、グローバル・インターネットは、それらを使って、その組織の内部ネットワーク中に正しくデータを送ることができない。たとえば、ネットワークに接続されたデバイスにデータを送るために、送信元アプリケーションは、ターゲット・アプリケーションのアドレスを持っていなければならず、データを受信するネットワーク自体は、そのターゲット・アプリケーションの位置を捜し出す方法を知らなければならない。これらの動作は、どのＩＰアドレスがどのデバイスおよびアプリケーションに所属するかに関する取り決めに、すべての参与アプリケーションが合意している場合にのみ、うまく機能する。
【０００３】
１つの解決策は、その組織が、１組の公式ＩＰアドレスを、割り当ててもらうことである。これらは、一意のアドレスである。これらのアドレスにデータを送るグローバル・インターネット上のどのアプリケーションも、そのデータが、その組織の内部ネットワークの入口に到着することを、信頼することができる。すなわち、グローバル・インターネットのインフラ・ストラクチャは、データをその組織に正しく送達し、その後に、（ＩＰが正常である場合）その組織が、組織内の正しいエンドポイント・アプリケーションを突き止めて、最終的な送達を行ってくれることを信頼する。
【０００４】
その組織は、次いで、それに割り振られた公式ＩＰアドレスのそれぞれを、無期限に、個々のアプリケーションに割り当てて、幸運である、わずかなアプリケーションだけに、インターネット・アクセスを許可することができる。より広範なアクセスを可能にする、より良い解決策は、実質的に、任意の所与の時間に、グローバル・インターネットにアクセスする必要がある任意のアプリケーションに対して、公式に割り振られたＩＰアドレスを、動的に割り当てることができるデバイスを使用することである。アドレスは、もうそれらを使用していないアプリケーションから回収され、再割当て用として、利用可能にされる。この共用システムは、非常にうまく機能し、最も簡単な形態において、まさに従来のネットワーク・アドレス変換機構（ＮＡＴ）が通常行っているものである。（インターネット技術標準化委員会（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）発行のＲＦＣ２６６３「ＩＰネットワーク・アドレス変換（ＮＡＴ）の術語および考察（ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ ａｎｄ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ）」を参照されたい。これは、ＮＡＴデバイスを取り巻く動作および問題を説明している基本的なＩＥＴＦ文書である。）
しばしば、組織は、特定の非常にわずかの公式ＩＰアドレスしか、割り当てられない。場合によってはわずか３１、または２５５のこのようなアドレスが、組織に与えられることがある。その内部ネットワーク上に、何千ものアプリケーションを有する組織にとって、公式ＩＰアドレスを割り当てることしかできない単純なＮＡＴは、十分ではないことがある。例えば、５，０００のアプリケーション（そのそれぞれが個々の従業員に対応している）のうちのわずか３１だけが、一度にグローバル・インターネットを使用できるのであれば、問題は、完全に解決されていない。
【０００５】
公式に割り振られたアドレス・プールの有用なサイズを有効に拡張するために、組織のＮＡＴは、通常、同じ公式アドレスを複数の内部アプリケーションに使用する能力を備えている。特定の公式ＩＰアドレス（例えば、Ｘ）宛てに到着するデータを、いくつかのデータス・トリーム（例えば、Ａ、Ｂ、およびＣ）の１つに所属させることによって、さらに識別することができる。ＮＡＴは、アドレスＸのストリームＡを、あるアプリケーションのための特定のデータス・トリームに割り当てることができ、一方、アドレスＸのストリームＢおよびＣは、別の２つの異なるアプリケーションに所属する。
【０００６】
ストリーム識別子は、ポート番号と呼ばれる。ＩＰネットワーク中のデータのストリームは、次の５つの別個の数値量から成る、いわゆる「５タプル」によって一意に識別される：
１）ソースＩＰアドレス
２）宛先ＩＰアドレス
３）ソースポート番号
４）宛先ポート番号
５）トランスポート・プロトコル。
【０００７】
ＩＰネットワーク中のあらゆるデータ項目（パケット）は、その中にこれらの５つの数値識別子を持っている。２つのＩＰアドレス（上記の項目１および項目２））は、多かれ少なかれ、ソースおよび目的アプリケーションを識別する。プロトコルは、信頼できるデータの移送を確実にするためのどのメカニズムが使用されているかを識別する。現在の目的において、プロトコルは、ＮＡＴにとっては必要なものではないため、それについては無視する。ソースおよび宛先ポート（上記の項目３および項目４）は、ネットワーク中のどのアプリケーションが、このパケットを送ったのか、また受信するのかをそれぞれ識別する。
【０００８】
本明細書が考える従来のネットワーク・アドレス変換機（例えば、カリフォルニア州サンホセのシスコ・システムズ社のプライベート・インターネット交換（ＰＩＸ：Ｐｒｉｖａｔｅ Ｉｎｔｅｒｎｅｔ Ｅｘｃｈａｎｇｅ）は、パケット内のこれらの５つの数値識別子を変更することによって動作する。上述のように、ＮＡＴデバイスは、２つのアドレス領域の間、必ずではないが通常は、グローバル・インターネットと組織のプライベート・ネットワークとの境界に常駐し、この場合、これら２つのネットワークは、互換性がないＩＰアドレス指定方式を使用している。ＮＡＴデバイスは、その中を流れる各パケット内の４つのソース／宛先エレメントを知的に書き直すことを利用して、２つのネットワークのそれぞれに、相手のネットワークのＩＰアドレス指定方式の偽りではあるが互換性があるビューを示す。各ＮＡＴは、それがアドレス変換のために使用する、内部アドレス／外部アドレスの組合わせを定義する、１組の規則を備えていなければならない。有用なＮＡＴは、これらの組合せを作って、内部アプリケーションが、利用可能な外部アドレスを有効に利用できるようにしなければならない。この外部アドレスは、外部領域が公式ＩＰアドレスを要求する場合、制限される。
【０００９】
内部ネットワークに関連する従来のＮＡＴは、基本的に２種類の同時動作モードをサポートする。第１は、内部ネットワーク上のアプリケーションから外部のグローバル・インターネットに向けた、データ・トランザクションを可能にする（例えば、法人ユーザによるウェブページへのアクセス）。これは、内部クライアントの外部サーバへのアクセスである。第２は、グローバル・インターネット上のアプリケーションが、内部ネットワーク上の特定のデバイス上の特定のサービスにアクセスすることを可能にする（例えば、顧客による組織のウェブサイトへのアクセス）。これは、外部クライアントの内部サーバへのアクセスである。従来のＮＡＴデバイスが、第１および第２のタイプのアクセスを可能にするアドレスの組合せ（アドレス・ペアリング）を作る方法は、いくらか異なる。
【００１０】
従来のＮＡＴデバイスは、第１のモードを、次のように実施する。データ・トランザクションの最初のアウトバウンド・パケットが、ＮＡＴデバイスに到着すると、ＮＡＴデバイスは、そのソース・アドレスおよびポート（パケットを送信した内部のデバイスおよびアプリケーションを識別する）を調べる。ＮＡＴは、次いで、その利用可能公式アドレスおよびポートのプールから、外部で有効なＩＰアドレスおよびポートを選び、パケット中の内部で有効なソース・アドレスおよびポートと置き換えて使用する。内部で有効なソース・アドレスおよびポートから、外部で有効なソース・アドレスおよびポートへのマッピングは、ＮＡＴ内において、何らかの形で、例えば、対応する規則を定義するテーブル形式で、保持される。最後に、ＮＡＴは、アウトバウンド・パケット中の内部で有効なソース・アドレスおよびポートのフィールドを修正して、それを転送する。初期パケットに応答するインバウンド返信パケットが、外側からＮＡＴに現れた場合、その返信パケット中の宛先アドレスおよびポートは、外部で有効なソース・アドレスおよびポートに一致する（なぜならば、返信において、例えば、まさに郵便の手紙の場合のように、当然、送信者のアドレスと受信者のアドレスが、反対になるからである。）ＮＡＴは、この着信した、外部で有効なソース・アドレスおよびポートを使って、初期アウトバウンド・パケットから、内部で有効なソース・アドレスおよびポートを突き止める。ＮＡＴは、次いで、突き止めた内部で有効なソース・アドレスおよびポートを使って、この着信した返信パケット中の宛先アドレスおよびポートを置き換える。この場合、着信した返信パケットは、初期アウトバウンド・パケットを送ったデバイスおよびアプリケーションに送達するための、正しい内部で有効な宛先アドレスおよびポートを備えている。
【００１１】
従来のＮＡＴデバイスは、第２のモードを、ＮＡＴを管理する者によって定義される固定内部／外部アドレス対応構成情報を使って、実施する。このモードの場合、初期パケットは、公式に割り振られたＩＰアドレスのうちの１つを含む、特定の宛先情報を備えて、外部から入って来て、ＮＡＴに到着する。なぜならば、これらの外部で有効なアドレスは、グローバル・インターネットがＮＡＴを使ってターゲット組織にパケットを送達するために使用できるＩＰアドレスだけだからである。ターゲット組織のＮＡＴは、その構成情報に相談して、その着信パケット中に含まれている外部で有効な宛先アドレスおよびポートと交換するのに、どの（固定された）内部で有効な宛先ＩＰアドレスおよびポートを使うべきかを判断する。実際、アプリケーション（例えば、ウェブサーバ）が、ターゲット組織の内部デバイスＡ（非公式の、内部で有効なＩＰアドレス）に存在し、パケットがポートＸに要求されている場合、ＮＡＴは、ＩＰアドレスＭ（公式に割り当てられ、外部で有効）、ポートＹにアドレス指定されたパケットを、内部で有効なアドレス、デバイスＡ／ポートＸにアドレス指定し直すべきであると認識するように、構成することができる。ターゲット組織の別のアプリケーションが、外部からポートＺのデバイスＢとして認識される別の内部デバイス上で実行していることがあり、ＮＡＴは、この場合も特定の固定された事前定義の構成データに従って、同じ内部アドレスＡと特定の別のポートを用いて、このアプリケーションの内部／外部アドレスの組合せを使うことができる。
【００１２】
問題は、第１のモードが、外部サーバにデータを送る（かつ、その後、そこからデータを受け取る）ことを、内部クライアントに許可するだけであり、一方、第２のモードが、内部サーバに関連するＮＡＴ中で事前定義された、固定ＩＰアドレスおよびポートの、少数の１組の内部サーバにデータを送る（かつ、その後、そこから返信を受け取る）ことを、外部クライアントに許可するだけという点である。ある外部クライアントが、割り振られたばかりのポート番号で、作成されたばかりの内部サーバに接続するトランザクションは、サポートされない。
【００１３】
様々な従来技術の参考文献が、ＮＡＴデバイス、およびその基本的なアドレス変換機能の変形について説明している：
「Ｍｅｔｈｏｄ Ａｎｄ Ｓｙｓｔｅｍ Ｆｏｒ Ｌｏｃａｔｉｎｇ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅｓ Ｗｉｔｈ Ｄｉｓｔｒｉｂｕｔｅｄ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ（分散ネットワーク・アドレス変換でネットワーク・サービスの位置を突き止めるための方法およびシステム）」という名称の米国特許第６，０５５，２３６号は、基本的に、サービスを安全にアドバタイズする方法を扱っている。その米国特許第６，０５５，２３６号は、クライアント側の情報にアドレスを提供する対称の問題には言及しておらず、ひたすら、サーバのために外部で有用なアドレスをアドバタイズことに焦点を当て、クライアントが使用する外部アドレスについては何も述べていない。
【００１４】
「Ｓｅｃｕｒｉｔｙ Ｓｙｓｔｅｍ Ｆｏｒ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ Ｓｙｓｔｅｍｓ（ネットワーク・アドレス変換システムのためのセキュリティ・システム）」という名称の米国特許第５，７９３，７６３号は、デバイスがＩＰアドレスを変換するだけで、また、セキュリティ上の考慮すべき事柄に関するものであるという点を除けば、ある種のＮＡＴデバイスに関する特許である。そこに、ポート番号を使って、利用可能な「論理」アドレス・スペースを拡張するというテーマについての教示は何もない。
【００１５】
ＳＯＣＫＳ。ＳＯＣＫＳは、インターネット技術標準化委員会（ＩＥＴＦ）標準であり、それによって、アプリケーションが、リモート・クライアント・アプリケーションにアドバタイズできる外部で有用なアドレスに関して、アプリケーション・ファイアウォールに照会することができるメカニズムを提供する。ＳＯＣＫＳは、このアプリケーションのプロキシであり、ＮＡＴと同様のサービスを提供するが、全く異なって動作する。パケットがデバイスの中を流れるときにその内容を書き直すのではなく、ＳＯＣＫＳは（任意のアプリケーション・プロキシのように）、２つの通信チャネルを終了して、それ自体の内部の上層で、それらを論理的に接続する。例えば、ネットワークの内部にあるサーバは、そのサービスを開始し、次いで、ネットワークの端にあるＳＯＣＫＳアプリケーションに要求を出すことがある。ＳＯＣＫＳアプリケーションは、ネットワークの端で、そのホスト上の「シン（ｔｈｉｎ）」サーバを開始し、次いで、その「シン」サーバを見つけることができるアドレスおよびポートを、元のサーバに知らせる。元のサーバは、この情報をクライアントに伝達し、クライアントは、ＳＯＣＫＳが動作している「シン」サーバに接続する。ＳＯＣＫＳは、次いで、クライアントとして元のサーバに接続し、その後、外部クライアントから受け取ったデータを元のサーバにコピーし、また、元のサーバから受け取ったデータを、外部クライアントに返してコピーする。特に、ＳＯＣＫＳは、ＮＡＴではなく、特定のパフォーマンスおよびスケーリングを伴う、パケットごとの動作を行わない。ＳＯＣＫＳに関するさらなる情報は、ｈｔｔｐ：／／ｗｗｗ．ｓｏｃｋｓ．ｎｅｃ．ｃｏｍを参照されたい。
【００１６】
ディジタル化された声、音、またはビデオ（「メディア」コンテンツ）から成るデータを送るために、ＩＰネットワークの使用が増えるであろうと予想されている。インターネットおよびその他のＩＰネットワーク上のピア・ツー・ピアのデータ交換（メディアの伝送を含む）を容易にする、ネットワーク・アドレス変換のための方法および装置が、必要とされている。
【００１７】
【発明の概要】
本発明は、第１のアドレス領域中の第１のアプリケーションと、異なるアドレス領域中の第２のアプリケーションと、の間の通信を容易にするための、ネットワーク・アドレス変換デバイスを含む。このデバイスは、変換規則に基づいて、第１のアドレス領域で有効なアドレスを、第２のアドレス領域で有効なアドレスに変換し、かつ、第２のアドレス領域で有効なアドレスを第１の領域で有効なアドレスに変換するための、アドレス変換機構を使用する。また、第１のアドレス領域で有効なアドレスを第２のアドレス領域で有効なアドレスに関連付けることによって変換規則を確立する、アドレス・マネージャを使用する。アドレス・マネージャと通信する制御チャネルが存在し、この制御チャネルは、第１のアプリケーションから、第１の領域で有効な指定アドレスに関連付けることができる第２のアドレス領域で有効なアドレスを求める要求を受け取り、かつ、第２のアプリケーションへの第２の領域で有効なアドレスの伝達を容易にするために、第１のアプリケーションに第２のアドレス領域で有効なアドレスへのアクセスを提供する。
【００１８】
本発明の一実施形態において、アプリケーションは、ＩＰ電話に接続されたエンティティである。本発明の別の実施形態において、アドレス・マネージャは、より複雑な変換規則を確立し、それによって、外部で有効な宛先アドレスは、着信ソース・アドレスに応じて、ある値または別の値の、内部で有効なアドレスに、変換することができる。特定の複数リモート・アドレス、より大きなリモート・アドレス・セット、あるいは、任意の単一リモート・アドレスは、特定のより複雑なＮＡＴ規則を使用するためのトリガとして、使うことができる。さらなる実施形態において、アプリケーションは、アドレス・マネージャが確立した変換規則を特定の範囲内で制御するように、プログラムされる。
【００１９】
【詳細な説明】
Ｉ．ピア・ツー・ピア・アプリケーション
本発明を使ったシステムは、一方のデバイスが周知のロケーション（ＩＰアドレス）にあり、もう一方を周知のロケーション（ＩＰアドレス）に位置することも位置しないこともあるという伝統的なモデルとは異なり、ピア・ツー・ピア（いずれかの場所に位置し、基本的に対称的に通信を行う１つまたは複数のデバイス）方式で動作する新しい種類のインターネット・アプリケーションにとって、少なくとも、役に立つ。
【００２０】
新世代のインターネット・アプリケーション（例えば、ＩＰ電話、インスタント・メッセージングなど）によって、異なるアドレス領域内のネットワーク上の複数のユーザが、直接、互いのコンピュータに接続することが可能となり、データを共用し、又は、共同して働き、或いは、持続的なリアルタイム対話で、単にチャットすることができる。これらのプロトコルにおいて、各ユーザのコンピュータは、マイクロ・サーバと呼ばれることがあるアプリケーションをセットアップし、次いで、異なるアドレス領域に位置する別のコンピュータに、マイクロ・サーバに到達することができるＩＰアドレスおよびポートを伝達する。（これが、従来のＮＡＴデバイスが扱っていない「割り振られたばかりのポート番号」の「作成されたばかりの内部サーバ」である。）ピア・ツー・ピア接続を完了するために、各ユーザのコンピュータは、次いで、クライアント・アプリケーションを立ち上げて、別のアドレス領域中のマイクロ・サーバに接続する。それぞれのクライアント・アプリケーションは、次いで、その別のアドレス領域中のその別のコンピュータ上のマイクロ・サーバに到達できるアドレスを保有しなければならない。その後、異なるアドレス領域を扱うＮＡＴを使って、２つのクライアント／マイクロ・サーバのペアの間で、双方向通信が開始可能になる。
【００２１】
上述のように、図１は、従来のＮＡＴが使用されている状況を示す。通常、解決すべき一般的な問題は、大規模な内部ネットワーク１０に関する問題であり、その内部ネットワーク１０は、非公式の、即ち割り当てられていないＩＰアドレスであって、グローバル・インターネットにとっては未知である、またはグローバル・インターネットによっては正しく経路指定されないＩＰアドレスの領域５０中に存在している。ＮＡＴデバイス２０は、内部ネットワーク１０のグローバル・インターネット３０への単一相互接続点（または複数相互接続点）に、配置されている。ＮＡＴ２０は、公式に割り当てられたアドレスの小プールを使って、グローバル・インターネット３０に対し、公式に割り当てられたＩＰアドレスを使って、小規模デバイス・ネットワークという幻想（イルージョン）を作り出す。また、ＮＡＴ２０は、内部ネットワーク１０内のデバイスの多くまたはすべてに、グローバル・インターネット３０への特定のアクセスを提供する。
【００２２】
１つには、アプリケーションおよびその対応するＮＡＴが通信する方法が、限定されたものであるために、ピア・ツー・ピア・アプリケーションは、現世代のＮＡＴデバイスを介して、作動しない。普通、ＮＡＴデバイスは、メッセージ・パケットのＩＰアドレス・フィールドのみを処理し、限定された１組の規則に従って、アドレス変換を行う。図２は、従来のＮＡＴ１２０の基本的なアドレス変換機能を示す。ホストＡ１１０は、従来のＮＡＴ１２０がサービスするアドレス領域１００の一部にある。アプリケーションＡ１ １２１は、ホストＡ上で実行している。それは、内部で有効であって、着信メッセージ・パケットをそれに経路指定するために使用する、宛先アドレスまたは終了アドレスを有する。また、アプリケーションＡ１は、アプリケーションＡ１を、それが送信したメッセージ・パケットのソースとして識別するために使用される、送信元アドレスも有する。上述のように、ＩＰメッセージ・パケットは５つの部分から成るＩＰヘッダを含む。したがって、アプリケーションＡ１が、遠隔の外部アドレス領域中のホストＲ２１０に送ることを望む発信パケット１３０は、そのＩＰヘッダ１４０中に次の構成要素を有する：
１）ソースＩＰアドレス
２）宛先ＩＰアドレス
３）ソースポート番号
４）宛先ポート番号
５）トランスポート・プロトコル。
【００２３】
このＩＰヘッダの後に、メディアであってよいデータ１４２が続く。アプリケーションＡ１が、発信メッセージ１３０をＮＡＴ１２０に提供すると、ＮＡＴ１２０は、内部で有効なアドレスおよびポート番号をいずれも、外部で有効なアドレスおよびポート番号に、置き換えなければならない。ＮＡＴ１２０は、任意の形態（例えば、対応テーブル１２４など）で記憶されているその変換規則を適用する、ハードウェアおよびソフトウェア１２２を備えることができる。一般に、アプリケーションＡ１ １２１は、内部で有効なソースＩＰアドレスおよびソースポート番号（その送信元アドレス）しか持っておらず、ＮＡＴ１２０は、それらをホストＲ２１０に伝送する前に、いずれかの発信メッセージ１３０中に挿入するとき、パケット２３０の外部で有効なアドレス・ヘッダ２４０に変換しなければならない。簡単にするために、ホストＲが、公式ＩＰアドレスを使用するアドレス領域２００中にあると想定する。この場合、ＮＡＴ及びアドレス変換のいずれも、外部で有効なアドレス・ヘッダ２４０を有するパケット２３０を、ホストＲのアドレス領域２００中の指定宛先ＩＰアドレスおよびポートに送達するために、不必要である。
【００２４】
ホストＲの返信パケット２５０は、そのアドレス・ヘッダ２６０中に、外部で有効なＩＰアドレスを使用する。ＮＡＴ１２０は、これらの外部で有効なアドレスを、アドレス領域１００のための内部で有効なＩＰアドレスに変換する必要がある。この場合も、ＮＡＴは、任意の形態（例えば、対応テーブル１２４など）で記憶されたその変換規則を適用する、ハードウェアおよびソフトウェア１２２を使用する。ホストＲからホストＡに伝送されると、その結果、内部で有効なパケット１５０は、内部で有効な宛先アドレスおよびポート（すなわち、アプリケーションＡ１の終了アドレス）を有する、適切に変換されたアドレス・ヘッダ１６０を備える。これによって、データ・コンテンツ１６２を備えた内部で有効なパケット１５０が、アプリケーションＡ１に到達することができる。
【００２５】
本発明により容易になるピア・ツー・ピア通信のためのマイクロ・サーバは、潜在的に、組織の内部ネットワーク内の任意のホストデバイス上に、常駐している。これらのマイクロ・サーバは、一般に、基礎をなすオペレーティング・システムによって（オペレーティング・システム固有の方法で）、そのサービスのために使用するポートとして、ランダムな、利用可能ポート番号を、割り当てられる；この番号は、マイクロ・サーバが実行しているホストデバイス上のどの他のアプリケーションも、現在、使用していない番号である。実際、マイクロ・サーバは、そのマイクロ・サーバのアドレスを伝達するアプリケーションと同じデバイス上に常駐していなければならない理由もない。また、別のアドレス領域中のマイクロ・サーバのクライアントは、データ交換のセットアップのためにそのマイクロ・サーバのアドレスが伝達されるべきデバイスと同じデバイス上に、常駐していなければならない必要もない。しかし、このような分離が生じる場合、すべてのアプリケーションが、それらが知る必要があるすべてのアドレスおよびポート情報を知るように、特定のイントラ・ネットワーク通信が、必要になる。
【００２６】
本明細書において「ピア・ツー・ピア・アプリケーション」として説明しているアプリケーションの種類について言及する。この種のアプリケーションは、２つのアプリケーションがネットワーク上で基本的に対称的な方式で通信を行うような、すべてのアプリケーションを含むことを意図されている。この場合、アプリケーションが、サービスを提供する、またはサービスを受け取るという意味でのサーバでもクライアントでもないことは明らかである。そうではなく、両方のアプリケーションは、他方のために、同じまたは同様の機能を実行する。なお、本明細書の残りの部分において、データ転送セッションを開始するアプリケーションという意味で「クライアント」という用語を使用し、また、クライアントからのデータ転送セッションの開始を受け付けるアプリケーションという意味で「サーバ」という用語を使っていることに留意されたい。これは、２つのアプリケーション間を通る初期データパケットが、どちらの方向に進むのかを定義するために役立つ、便利な用語である。この開始ステップは、ＮＡＴの挙動を説明するために重要である。別途記載がない限り、「クライアント」という用語は、データ転送の初期セッションパケットを送るアプリケーションまたはデバイスを意味し、「サーバ」は、その初期パケットが向けられる先のアプリケーションまたはデバイスを意味することを、出願人は、意図している。
【００２７】
ＩＰ電話は、ピア・ツー・ピア・アプリケーションの著名な例である。この例において、各エンドポイント・アプリケーションは、いわゆる「メディア」接続を開始して、ディジタル化された音声を含むパケットを別のアプリケーションに送ることによって、クライアントとして動作する。その別のアプリケーションは、ディジタル化された音声を含むパケットを、サーバとして受け取る。ディジタル化された音声は、両方向に通るため、この関係は、多かれ少なかれ、対称的である。
【００２８】
ＩＰ電話おいて、内部ネットワーク上のマイクロ・サーバ（例えば、リモート電話からのディジタル化された音声パケットのストリームを待ちうけるＩＰ電話）は、通常、そのホストデバイスのＩＰアドレスを、リモート・クライアント（別のＩＰ電話、あるいは、特定の別のデバイス（例えば、別の電話のために動作する、仮想ＰＢＸまたはその他のＩＰ電話ゲートウェイなど））に、伝達する必要がある。マイクロ・サーバの、内部で有効なネットワーク・アドレスは、グローバル・インターネット上のクライアントにとって、役に立たない。なぜならば、このアドレスは、公式に割り当てられたＩＰアドレスではないからである。マイクロ・サーバが、初期パケットによってリモート・クライアントに伝達することができる公式ＩＰアドレスを、何とか独立して検出または計算できたとしても、従来のＮＡＴは、リモート・クライアント・アプリケーションが送ってきた最初の返信パケットをどのように処置すべきかに関する手順または規則を、依然として何も持っていない。すなわち、ＮＡＴ自体が、この初期パケット中の公式ＩＰアドレスの検出または計算に関与していない限り、ＮＡＴは、内部ネットワーク・アドレスと着信メッセージ中のいずれかの公式ＩＰアドレスとを関連付ける変換規則を何も持っていない。
【００２９】
ＩＩ．改良ピア・ツー・ピア・ネットワーク・アドレス変換デバイス
以下の記載において、図３を参照して、本発明が、どのようにして改良ＮＡＴ装置および方法を使用し、ピア・ツー・ピア・インターネット通信を確立するかを説明する。
【００３０】
異なるアドレス領域間の効率的なピア・ツー・ピア・アプリケーション通信は、アプリケーション（簡単にするために、１対多数または多数対多数の交換ではなく、２つの間でデータを交換する２つのアプリケーションに限定して説明を行う）が、その通信において使用する、公式な、外部で有効なＩＰアドレスの情報にアクセスできることが必要である。最も単純なケースにおいて、第１のアプリケーションは、（１）他のアプリケーションがそれに到達するために使用する、外部で有効なアドレスの情報にアクセスすることが必要であり、それによって、このような第１のアプリケーションが、そのアドレス情報を別のアドレス領域中の第２のアプリケーションに伝達できる。また、第１のアプリケーションは、（２）第２のアプリケーションの外部で有効なアドレスにアクセスすることが必要である。実際、対称であるために、またセキュリティおよびその他の機能を容易にするために、第１および第２のアプリケーションのそれぞれは、２つのアドレスを持っているとよりよい：ここで、２つのアドレスは、送信元アプリケーションのデバイスおよびポートを、アウトバウンド・メッセージ・パケットのソースとして識別するために使用する送信元アドレスＡOと、インバウンド・メッセージ・パケットを受け取る、別のデバイスおよびポートを識別するために使用する、別個の終了アドレスＡTとである。したがって、第１および第２のアプリケーションのそれぞれが、２つの関連する公式アドレス（送信アドレスおよび終了アドレス）を持ち、それらを伝達することによって、理想的な通信は、確立される。さらに、第１および第２のアプリケーションのそれぞれは、ピア・ツー・ピア通信を行うことを望んでいる相手側の送信アドレスおよび終了アドレスにアクセスする。
【００３１】
図３は、異なるアドレス領域中の２つのピア・ツー・ピア・アプリケーション間における改良された通信を容易にするためのシステムを示す。ホストＡ１１０およびホストＢ３１０は、ともにアドレス領域１００の一部である。ホストＡは、その中で実行している１つまたは複数のアプリケーションを有する。例として、アプリケーションＡ１ １２１およびアプリケーションＡ２ １２２を示してある。そのアプリケーションのそれぞれは、内部で有効な終了アドレスおよび内部で有効な送信元アドレスを持っている。ホストＢも、その中で実行している１つまたは複数のアプリケーションを有することができる。例として、アプリケーションＢ１ ３２１およびアプリケーションＢ２ ３２２を示してある。ホストＡおよびホストＢは、同じネットワーク上にあってもよいし、あるいは、そうでない場合、ホストＡとホストＢとの間の通信用のチャネル３７０が存在するように接続される（例えば、一般的な通信ネットワークへの接続）。さらなるホストが、このアドレス領域１００に存在することもあるが、図示していない。
【００３２】
改良ＮＡＴ３２０は、アドレス領域１００を取り扱う。改良ＮＡＴ３２０は、２つの機能セクションを有する。１つは、アドレス変換セクション３２２であり、これは、図２のＮＡＴ１２０に関して説明した従来のアドレス変換機能を実行する。もう一方は、アドレス・マネージャ・セクション３２４である。ＩＰメッセージ・チャネル３６０は、ホストＡ１１０をアドレス変換セクションに接続する。このチャネル３６０は、ＮＡＴ３２０によって取り扱われるホストＡ又はその他の任意のホスト上のアプリケーションが、発信メッセージを送り出す必要があり、かつ、内部で有効なアドレスが、外部で有効なアドレスに変換されることを必要とする場合に、使用される。また、チャネル３６０は、外部で有効なアドレスを有する着信メッセージが、到着し、ＮＡＴ３２０が、着信メッセージ中の外部で有効なアドレスを内部で有効なアドレスに変換して、アドレス領域１００中の該当するアプリケーションにそのメッセージを転送する必要がある場合にも、使用される。
【００３３】
アドレス変換セクション３２２は、「外側」のアドレス領域に接続されている。例として、図３は、アドレス変換セクション３２２に接続されているグローバル・インターネット領域４００を示す。アドレス領域４００内に、別のアドレス領域２００があり、アドレス領域２００は、ホストＡまたはホストＢが通信し得る他のアプリケーション（アプリケーションＲ１、Ｒ２、Ｓ１、およびＳ２が、例として示されている）をホストするホストＲ４１０およびホストＳ５１０を含む。チャネル４７０（例えば、一般的なネットワーク接続）は、ホストＲ４１０とホストＳ５１０との間の通信を提供する。
【００３４】
制御チャネル３５０は、ホストＡ１１０を（および、間接的にホストＢ３１０を）、アドレス・マネージャ・セクション３２４に接続する。制御チャネル３５０は、ＮＡＴ３２０によって取り扱われるホストＡ又は他の任意のホスト上のアプリケーションが、アドレス・マネージャ３２４のサービスを要求するためにＮＡＴ３２０と通信する必要がある場合に、使用される。アドレス・マネージャは、要求しているアプリケーションのために、いくつかのサービスを実施することができる。第１に、要求しているアプリケーションは、内部で有効なアドレス（送信元アドレスまたは終了アドレスのいずれか一方）を提供し、また、アドレス・マネージャ３２４に対して、内部で有効なそのアドレスと組み合わされた外部で有効なアドレスを提供するように要求し、且つアドレス変換セクション３２２にこの組合せ（ペアリング）へのアクセス権を与えるように要求する。これは、アドレス変換セクション３２２が、着信および発信メッセージ・パケットの変換規則としてこの対応を使うように、行うことができる。
【００３５】
第２に、アプリケーションは、アドレス・マネージャ３２４に、単純な内部／外部の組合せを超えるように、ＮＡＴ３２０中で使用されている変換規則に対して、さらなる、またはより複雑な変換規則を、追加させることができる。例えば、単に、対応する内部で有効な宛先アドレスまたはポートを、着信メッセージの中で見つけられた外部で有効な宛先アドレスまたはポートに、無条件に置き換える代わりに、より複雑な変換規則を、アプリケーションの要求で、アドレス・マネージャ３２４によって、構築することができる。アドレス変換セクション３２２が、着信したソース・アドレスおよび／またはポートを調べ、そのフィールドの内容に応じて異なる変換規則を適用するように、規則を、策定することができる。例えば、ＮＡＴ３２０で受信されたパケット中の、外部で有効なアドレスＡEは、もしそのパケット中に特定のソース・アドレスが存在するならば、内部で有効なＡI1に変換されるが、そのソース・アドレスが存在しないならば、変換は行われず、パケットは廃棄される。これはセキュリティのために役立つことがある。あるいは、外部で有効な宛先ポート番号ＰEを、着信したソース・アドレスに応じて、ある値ＰI1または異なる値ＰI2の、内部で有効なポート番号に変換することができる。特定の複数リモート・アドレス、より大きなリモート・アドレス・セット、またはいずれかの単一リモート・アドレスを、特定のＮＡＴ規則を使用するためのトリガとして使うことができる。
【００３６】
第３に、アプリケーションは、内部で有効なアドレスと関連付けるために要求される外部で有効なアドレスに関する必要な特性又は所望の特性を、アドレス・マネージャ３２４に、指定することができる。これは、変換によって得られる外部ＩＰアドレスが特定のＩＰアドレスでなければならないこと、または指定したＩＰアドレス範囲内になければならないことを、アプリケーションに指定させる際に、役に立ち得る。したがって、適切な要求によって、アプリケーションは、メッセージ・パケットが、公衆グローバル・インターネット中の特定の外部サーバに向けられ、または押し進められことを要求するＮＡＴ規則を確立し、同様に、メッセージ・パケットが、再び公衆グローバル・インターネットに転送される前に、そのメッセージ・パケットが、特定のタイプの伝送または請求書作成が発生するような特定のプライベート・ネットワークに向けられるＮＡＴ規則を確立することができる。
【００３７】
したがって、制御チャネル３５０およびアドレス・マネージャ３２４は、従来のＮＡＴでは得られない情報と、ＮＡＴのアドレス変換セクション３２２のために特定の変換規則を確立するための権能との両方を、アプリケーションに提供するための柔軟性に富んだ機能を表していることがわかろう。アドレス・マネージャ３２４は、ハードウェアまたはソフトウェア、あるいはその両方の組合せで実装することができる。例えば、アドレス・マネージャ３２４は、マイクロプロセッサと、アプリケーションからの制御メッセージに応答して、どのサービスおよび機能が利用可能かを判定するコードを記憶するメモリと、を備えていることが望ましいことがある。さらに、アドレス・マネージャ３２４と通信を行う各アプリケーションが、制御チャネル３５０を介して要求がなされることを可能にし、また、要求した情報またはステータス情報がそのアプリケーションに返されることを可能にする、ハードウェアおよび／またはソフトウェアを必要とすることがわかるであろう。
【００３８】
ＩＩＩ．制御チャネルを使ったピア・ツー・ピア交換のサンプル
上述のサーバとクライアントの関係の説明に戻ると、いくつかの異なる例示的状況における、制御チャネル３５０の機能と、アプリケーション、アドレス・マネージャ３２４およびアドレス変換セクション３２２間の通信とを、説明することができる。各例を、図３を参照して説明する。
【００３９】
（サーバのアドレス／ポートの割り振りおよび検出の例）：
アドレス領域１００中のホストＡ１１０は、マイクロ・サーバのアプリケーションＡ１ １２１を起動する。このとき、アプリケーションＡ１ １２１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＲ４１０に、アドレス情報を伝達することを意図している。ホストＲ４１０は、このアドレス情報を使って、マイクロ・サーバのアプリケーションＡ１に接続することができる。ホストＲに有用なアドレス情報を提供するために、以下のステップが存在する：
１．アプリケーションＡ１ １２１は、制御チャネル３５０を介してＮＡＴデバイス３２０と交信し、アプリケーションＡ１が使用している内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる；
２．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスおよびポート番号を、アプリケーションＡ１がその要求の中で提供している内部で有効な終了アドレスに変換する；
３．アプリケーションＡ１（これが、ＩＰメッセージ・パケットを、ホストＲのアプリケーションＲ１ ４２１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴ３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、アプリケーションＡ１にパケットを送る方法を、ホストＲ４１０のアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む；
４．ホストＲ４１０のアプリケーションＲ１ ４２１は、アプリケーションＡ１によって与えられた外部で有効なＩＰアドレスおよびポート番号によって、接続要求を送る。これは（公式ＩＰアドレスに正しくアドレス指定されているので）ＮＡＴ３２０に到着し、そこで、外部で有効なアドレスが、アプリケーションＡ１の、内部で有効なアドレスおよびポートに変換される；
５．ＮＡＴ３２０は、アプリケーションＲ１ ４２１からの返信パケットを、ホストＡ上のアプリケーションＡ１ １２１に送る。
【００４０】
（クライアントのアドレス／ポートの割り振りおよび検出の例）：
アドレス領域２００中の外部ホストＲ４１０は、マイクロ・サーバ、例えばアプリケーションＲ１ ４２１を起動する。アプリケーションＡ１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＲに、アドレス情報を伝達することを意図している。ホストＲは、このアドレス情報を使って、ホストＡからの着信した接続の妥当性を確認することができる。ホストＲ ４２０に有用なアドレス情報を提供するために、以下のステップが存在する。
【００４１】
１．アプリケーションＲ１ ４２１は、ホストＡのアプリケーションＡ１ １２１から、アプリケーションＡ１ １２１からの接続がどのＩＰアドレスおよびポートから行われるかに関する情報を要求するホストＡに、パケットを送る。この送信元アドレス情報は、セキュリティのために有用であり、また、アプリケーションＲ１によって、それ自体の目的（例えば、通信プロトコルへの準拠など）のために、必要とされることもある。
【００４２】
２．ホストＡ上のアプリケーションＡ１ １２１は、制御チャネル３５０を介してＮＡＴデバイス３２０に交信し、アプリケーションＡ１がホストＲ上のマイクロ・サーバと通信を行うために使用する、内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる。
【００４３】
３．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスおよびポート番号を、アプリケーションＡ１がその要求の中で提供している内部で有効な送信元アドレスに変換する。
【００４４】
４．アプリケーションＡ１ １２１（これが、ＩＰメッセージ・パケットをホストＲのアプリケーションＲ１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴデバイス３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、どのＩＰアドレスおよびポートから、アプリケーションＡ１ １２１からのパケットを送信するかを、ホストＲのアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む。
【００４５】
５．アプリケーションＡ１ １２１は、次いで、ホストＲのアプリケーションＲ１ ４２１にアドレス指定した発信パケットを送ることによって、接続を開始し、このパケットは、ＮＡＴデバイス３２０のアドレス変換セクション３２２に到着する。
【００４６】
６．ＮＡＴデバイス３２０のアドレス変換セクション３２２は、パケットのソース・アドレスおよびポート（アプリケーションＡ１の内部ＩＰアドレスおよびポートを表す）を、これらの外部で有効なバージョン（ステップ３でアプリケーションＡ１に渡され、ステップ４で、アプリケーションＡ１がアプリケーションＲ１に送ったもの）に変換する。
【００４７】
７．アドレス変換セクション３２２は、アプリケーションＲ１がこの場合に期待しているソース情報とともに、パケットを、ホストＲのアプリケーションＲ１に送る。
【００４８】
（別個のリクエスタ／サーバを用いた、サーバのアドレス／ポートの割り振りおよび検出の例）：
この例において、ホストＡおよびホストＢは、それらの間の通信チャネル３７０を使用する。これによって、ホストＡ上のアプリケーションは、ホストＢ上のアプリケーションのプロキシとして動作することが可能になる。例えば、ホストＢ上のアプリケーションが、あまり知能を備えていないＩＰ電話の場合、ホストＡは、ＩＰ電話が必要とする様々なサービス（例えば、電話番号案内、電話番号とＩＰアドレスの関連付け）を扱うことが可能であるアプリケーションを備える仮想ＰＢＸであり得り、或いは、何か他の形態のＩＰ電話ゲートウェイであり得る。プロキシを使うと、要求しているエンティティが実際に所有または使用しているアドレスおよびポートと、アドレス・マネージャ３２４への要求で呼び出しているアドレスおよびポートとの間の関係は、何も必要でないことが明らかである。
【００４９】
アドレス領域１００中のホストＢ３１０は、マイクロ・サーバ、例えば、アプリケーションＢ１ ３２１を起動する。このとき、アプリケーションＢ１ ３２１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＲに、アドレス情報を伝達することを意図している。ホストＲ（クライアントとして動作する）は、このアドレス情報を使って、マイクロ・サーバ、アプリケーションＢ１に接続する。ホストＲに有用なアドレス情報を提供するために、以下のステップが存在する。
【００５０】
１．アプリケーションＡ１ １２１は、チャネル３７０を介してアプリケーションＢ１と通信を行って、アプリケーションＢ１ ３２１に交信するのに、どの内部で有効なアドレスおよびポートを使用できるかを検出する。
【００５１】
２．アプリケーションＡ１ １２１は、アドレス領域２００中のアプリケーションＲ１に交信して、アプリケーションＢ１の、外部で有効なアドレスの情報をアプリケーションＲ１に提供する必要がある。アプリケーションＡ１は、制御チャネル３５０を介してＮＡＴデバイス３２０に交信し、アプリケーションＢ１が使用している内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる。
【００５２】
３．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスおよびポート番号を、アプリケーションＡ１がその要求の中で提供している、アプリケーションＢ１の、内部で有効な終了アドレスに変換する。
【００５３】
４．アプリケーションＡ１ １２１（これが、ＩＰメッセージ・パケットをホストＲのアプリケーションＲ１ ４２１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴデバイス３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、アプリケーションＢ１ ３２１にパケットを送る方法を、ホストＲのアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む。
【００５４】
５．ホストＲのアプリケーションＲ１ ４２１は、アプリケーションＡ１ １２１によって与えられた外部で有効なＩＰアドレスおよびポート番号によって、接続要求を送る。これは（公式ＩＰアドレスに正しくアドレス指定されているので）ＮＡＴ３２０に到着し、そこで、外部で有効なアドレスが、アプリケーションＢ１の、内部で有効なアドレスおよびポートに変換される。
【００５５】
６．ＮＡＴ３２０は、アプリケーションＲ１からの返信を、ホストＢ上のアプリケーションＢ１に送る。
【００５６】
（交渉中のエンティティとは別個のクライアント／サーバを用いた、クライアントのアドレス／ポートの割り振りおよび検出の例）：
この例において、ホストＲ４１０およびホストＳ５１０は、それらの間の通信チャネル４７０を使う。これによって、ホストＲ４１０上のアプリケーションは、ホストＳ５１０上のアプリケーションのプロキシとして、動作することができる。例えば、ホストＳ上のアプリケーションが、あまり知能を備えていないＩＰ電話の場合、ホストＲ４１０は、ＩＰ電話が必要とする様々なサービス（例えば、電話番号案内、電話番号とＩＰアドレスの関連付け）を扱うことが可能であるアプリケーションを備える仮想ＰＢＸであり得り、或いは、何か他の形態のＩＰ電話ゲートウェイであり得る。
【００５７】
アドレス領域１００中のホストＳ５１０は、マイクロ・サーバ、例えば、アプリケーションＳ１を起動する。アプリケーションＢ１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＳ５１０に、アドレス情報を伝達することを意図する。ホストＳ５１０は、このアドレス情報を使って、ホストＢから着信した接続の妥当性を確認することができる。ホストＳ５１０に有用なアドレス情報を提供するために、以下のステップが存在する。
【００５８】
１．アプリケーションＲ１ ４２１は、ホストＡのアプリケーションＡ１ １２１から、アプリケーションＢ１ ３２１からの接続がどのＩＰアドレスおよびポートから行われるかに関する情報を要求するホストＡに、パケットを送る。この送信元アドレス情報は、セキュリティのために有用であり、また、アプリケーションＳ１によって、それ自体の目的（例えば、通信プロトコルへの準拠など）のために、必要とされることもある。
【００５９】
２．アプリケーションＡ１ １２１は、チャネル３７０を介してアプリケーションＢ１ ３２１と通信を行って、アプリケーションＳ１ ５２１に交信するのに、どの内部で有効なアドレスおよびポートをアプリケーションＢ１ ３２１が使用するかを検出する。
【００６０】
３．ホストＡ上のアプリケーションＡ１ １２１は、チャネル３５０を介してＮＡＴデバイス３２０に交信し、アプリケーションＢ１がホストＳ５１０上のマイクロ・サーバと通信を行うために使用する、内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる。
【００６１】
４．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスよびポート番号を、アプリケーションＡ１ １２１がその要求の中で提供している内部で有効な送信元アドレスに変換する。
【００６２】
５．アプリケーションＡ１ １２１（これが、ＩＰメッセージ・パケットをホストＲのアプリケーションＲ１ ４２１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴデバイス３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、どのＩＰアドレスおよびパケットから、アプリケーションＢ１ ３２１からのパケットを送信するかを、ホストＲのアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む。
【００６３】
６．アプリケーションＲ１ ４２１は、通信チャネル４７０を介してアプリケーションＳ１ ５２１と通信を行って、アプリケーションＢ１ ３２１がアプリケーションＳ１ ５２１と通信を行うのに使用するＩＰアドレスおよびポートを、アプリケーションＳ１ ５２１に伝達する。
【００６４】
７．アプリケーションＢ１ ３２１は、次いで、ホストＳのアプリケーションＳ１ ５２１にアドレス指定した発信パケットを送ることによって、接続を開始し、このパケットは、ＮＡＴデバイス３２０のアドレス変換セクション３２２に到着する。
【００６５】
８．ＮＡＴデバイス３２０のアドレス変換セクション３２２は、パケットのソース・アドレスおよびポート（アプリケーションＢ１の内部ＩＰアドレスおよびポートを表す）を、これらの外部で有効なバージョン（ステップ４でアプリケーションＡ１ １２１に渡され、ステップ５でアプリケーションＡ１がアプリケーションＲ１ ４２１に送ったもの）に変換する。
【００６６】
９．アドレス変換セクション３２２は、アプリケーションＳ１がこの場合に期待しているソース情報とともに、パケットを、ホストＲ４１０を経由して、ホストＳのアプリケーションＳ１ ５２１に送る。
【００６７】
ＩＶ．音声通信アプリケーション
（Ａ．ＮＡＴ不使用の場合）
本発明のＩＰ電話への適用をさらに詳細に説明するには、ＳＩＰと呼ばれるプロトコルを使った単純な電話の呼が、どのように動作するかを説明することが助けになる。ＳＩＰとは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のことである。しかしながら、ＳＩＰは、一般に、ＳＩＰと、これと一緒になって動作することによって、ユーザがデータ・ネットワーク（例えば、ＩＰ）を介して電話をかける（および何か別のことを行う）ことを可能にするすべての関連プロトコルと、に対する容認された略語である。
【００６８】
ある単純な例において、基本的に、電話の呼を確立するために送られるメッセージが２つある。（この説明において、特定の詳細については触れない。実際には、さらにずっと続く場合がある。）ここで関係がある２つのメッセージは、ＩＮＶＩＴＥ（招待）メッセージと、それに対するＯＫ応答とである。
【００６９】
ＳＩＰ電話（電話Ａと呼ぶ）を使っているある人が、電話番号又は何か別の識別子（例えば、電子メールアドレスなど）で識別できる誰か別の人に、電話をかけたいと思っていると想定する。電話をかけようとする人は、電話番号又は他の識別子を打ち込むことによって、所望のターゲットである相手を入力する。もちろん、電話Ａは、ターゲットである相手がどこにいるかについて、何も知らないが、プロキシ・サーバと呼ばれるより高性能な装置がどこにあるのか、知っている。したがって、電話Ａは、ターゲットが誰なのかに関する情報、特定のその他の情報、および−−これが重要である−−ターゲットが突き止められ、電話が鳴って、電話を取ったときにいつでも、電話Ａがどこでターゲットからメディア・パケットの受け取りを待つのかに関する宛先情報を含む、ＩＮＶＩＴＥメッセージを策定する。電話Ａは、一般に、この情報を、それ自体のＩＰアドレスおよびポート番号という形で、供給する。これらは、それぞれ１．１．１．１および１１１１であると仮定する。
【００７０】
電話Ａが交信したプロキシ・サーバは、ターゲットを突き止めるまで、たいてい、特定のネットワーク・サーチ・パスをたどって、ＩＮＶＩＴＥを他のプロキシ・サーバ・デバイスに送る。この時点で、最初に電話Ａが策定したＩＮＶＩＴＥメッセージは、ターゲットに送達される。このターゲットを電話Ｂと呼ぶ。電話Ｂは、おそらく、しばらくの間、鳴るであろう。そして（幸運にも）誰かがそれを取る。この時点で、電話Ｂは、ＯＫメッセージで応答する。このＯＫメッセージは、電話Ｂがそこでメディアの受け取りを待つ宛先アドレスを含めて、様々な情報を含む。これは、ＩＰアドレス２．２．２．２、ポート番号２２２２であると仮定する。
【００７１】
電話Ｂは、ディジタル化された音声を備えたメディア・パケットを、直ちに１．１．１．１／１１１１に送り始めることができる。なぜならば、電話Ｂは、この情報を、ＩＮＶＩＴＥメッセージ内で、受け取っているからである。ＯＫメッセージが、電話Ａに戻ると（プロキシ・サーバを介して）、その電話は、同様のメディア・パケットを２．２．２．２／２２２２に、送り始めることができる。この時点で、ディジタル・オーディオ・データは、両方向に送られており、その後、推定できるように、会話が行われる。
【００７２】
（Ｂ．ＮＡＴ使用の場合）
図中のＮＡＴを用いた３つのケースが考えられる。第１のケースにおいて、ターゲット電話は、結局、プロキシ・サーバによって、特定のＮＡＴデバイスの内側で捜し出される。第２のケースにおいて、ソースの電話が、（特定の）ＮＡＴデバイスの内側に位置している。第３のケースにおいて、どちらの電話も、ＮＡＴデバイスの「内側」に位置していないが、それらの間のメディア・トラフィックは、ＮＡＴデバイスの内側に配置されているネットワークを通る必要がある。以下に説明する例において、すべてのＮＡＴデバイスは、図３で説明した種類のものである。
【００７３】
もちろん、その様々なケースを組み合わせることができる。一般に、特定のプロキシ・サーバは、ネットワーク中のその他のプロキシ・サーバ、および関与している電話に、ＮＡＴデバイスが全くないという幻想（イルージョン）を、与える。これがうまく行われるので、実際に多数のＮＡＴデバイスは、多数のプロキシ・サーバとともに動作させることができ、そのそれぞれが、自分が唯一のＮＡＴであると確信し、かつネットワークの残りの部分に、結局「ここにはＮＡＴが全くない」と確信させるのである。
【００７４】
１．ターゲット電話がＮＡＴの内側にある場合
この場合、ターゲット電話であり、ＮＡＴのアドレス領域の内側にある電話Ｂは、送信元電話にデータを送ることについて、何の問題もない。なぜならば、ＮＡＴは、一般に、外側のアドレスにアドレス指定することによって、トラフィックをどこにでも送る能力を、その「内側」にあるものに、与えるからである。問題は、送信元電話に何を伝えるべきかを、選別することにある。なぜならば、ターゲット電話は、ＮＡＴの「内側」にあるため、ＮＡＴから何か手助けがない限り、外側から到達することができないからである。ターゲット電話は、グローバルに経路指定可能なＩＰアドレスを使っていない；たいてい、それは、世界の残りの部分にとっては、そこにパケットを送達する方法が全くわからないアドレスである、プライベートＩＰアドレスを使っている。ターゲット電話のローカル・ネットワーク上のデバイスのみが、そこにデータが送達されるという期待を持って、ターゲット電話の実際のＩＰアドレスに、データをアドレス指定することができる。
【００７５】
この場合、ターゲット電話のネットワーク内にあるプロキシ・サーバが、関与しなければならない。もちろん、それは、ＩＮＶＩＴＥをローカル・ネットワーク内の正しい電話に経路指定して呼を完了する責任を持っているので、いずれにしても常に関与している。このプロキシ・サーバは、ターゲット電話からのＯＫ応答の処理も行う。なお、ターゲット電話が、そのアドレスおよびポートである２．２．２．２／２２２２を、このＯＫメッセージ内に書き込むことを思い出されたい。この場合、２．２．２．２は、プライベートであり、内部でのみ有効なため、送信元電話にとって役立つアドレスではない。したがって、プロキシ・サーバは、別の外部で有効なアドレスを入手して、ＯＫメッセージを送信元電話に送り返す前に、その中に含まれているアドレス（および可能にはポート）を取り替えなければならない。
【００７６】
プロキシ・サーバは、ターゲット電話のＮＡＴデバイスに、「サーバ・アドレス／ポートの割り振り／検出」要求を行う。ＮＡＴは、アドレスおよびポート、例えば３．３．３．３／３３３３で応答する。これによって、ＮＡＴデバイスのもう一方の側（「外側」）にあるデバイスは、２．２．２．２／２２２２にあるデバイス（ターゲット電話）に到達することができる。プロキシ・サーバは、２．２．２．２／２２２２の代わりに３．３．３．３／３３３３を表すようにＯＫメッセージを書き直して、この新しいＯＫメッセージを電話Ａに送る。
【００７７】
次に、電話Ｂが、電話Ａにメディア・パケットを送る場合、それは、１．１．１．１／１１１１にアドレス指定され、ＮＡＴは、これがうまく行われるようにする。すなわち、アウトバウンド・トラフィックが、単に、「正しい」外部で有効なアドレスにアドレス指定されるようにする。しかし、電話Ａが、メディア・パケットを電話Ｂに送る場合、ＯＫメッセージ内で受け取られる宛先エンドポイント情報である、３．３．３．３／３３３３に、送られる。正しい構成を前提とすると、このパケットは、ＮＡＴデバイスに到着し、ＮＡＴデバイスは、パケットがプロキシ・サーバの要求によって、２．２．２．２／２２２２にアドレス指定され、ネットワークの内側に送られるように、パケットを変換する。メディア・パケットは、これで、正しくアドレス指定されて、この「プライベートにアドレス指定された」メディア・パケットの送達の仕方を知っているローカル・ネットワーク内に存在する。したがって、所望通りに、メディア・パケットは、電話Ｂに到着する。
【００７８】
２．ターゲット電話がＮＡＴの外側にある場合
これは前の例とほぼ全く同じである。しかし、この場合、電話Ａ（この場合はＮＡＴの「内側」の電話であり、そのローカル・ネットワーク内でのみ有用なプライベートＩＰアドレスを有する）の近くのプロキシ・サーバは、ＮＡＴデバイスに外部で有効なアドレスを照会した後、ＩＮＶＩＴＥメッセージを書き直さなければならない。場合によって、１．１．１．１／１１１１というアドレスは、要求されたＮＡＴ規則のもとで、４．４．４．４／４４４４に書き直される（この場合、１．１．１．１／１１１１は、プライベートＩＰアドレスであり、４．４．４．４／４４４４は、そうではないと想定する）。
【００７９】
電話Ａからのメディア・パケットは、変更されないままＮＡＴデバイスを通って外部に進むが、ＮＡＴの外側にある電話Ｂからのメディア・パケットは、４．４．４．４／４４４４にアドレス指定されて、ＮＡＴデバイスに到着し、１．１．１．１／１１１１に変換されて、最終的に内側の電話Ａに送達される。
【００８０】
３．両方の電話が外側にあって、通過ネットワーク（トランジット・ネットワーク：ｔｒａｎｓｉｔ ｎｅｔｗｏｒｋ）がＮＡＴデバイスを備える場合
この場合、両方の電話はどこか「外」にあり、ＮＡＴ装置を備えたネットワークは通過ネットワーク、おそらくＩＰ電話のための長距離キャリアであることを前提とする。さらに、このネットワークが、ＩＮＶＩＴＥメッセージおよびＯＫメッセージの処理および経路指定に、関与していることも前提とする。おそらく、このネットワークは、パーソン−ロケーション（ｐｅｒｓｏｎ−ｌｏｃａｔｉｏｎ）・サービスを提供し、また、メディアの処理を行う。
【００８１】
電話Ａおよび電話Ｂを、それぞれ１．１．１．１／１１１１および２．２．２．２／２２２２とする。
電話ＡからのＩＮＶＩＴＥが、考慮中の、ＮＡＴを備えた通過ネットワーク中にある特定のプロキシ・サーバに、到着すると想定する。これは、この例では「インバウンド」のＩＮＶＩＴＥを処理するため、進入プロキシ・サーバと呼ぶことができる。進入プロキシ・サーバは、前の諸例と同様に、同じ「サーバのアドレス／ポートの検出」を行って、通過ネットワークの内側のデバイスが電話Ａに到達するために使用できるアドレスを検出する。この動作は、通過ネットワークから電話Ａへの出口ポイントにある、ＮＡＴ Ａと呼ぶ特定のＮＡＴデバイス上で行われると想定する。例えば、ＮＡＴ Ａが、１０．１０．１０．１０／１０１０というアドレス／ポートを返すとする。これは、通過ネットワークの内側にあるものが電話Ａに到達するために使うことができる、通過ネットワーク内において有用なプライベート・アドレスである。すなわち、１０．１０．１０．１０／１０１０にアドレス指定された、通過ネットワーク内のメッセージ・パケットはどれも、そのネットワークによって、ＮＡＴ Ａに経路指定される。ＮＡＴ Ａは、それらのアドレスを１．１．１．１／１１１１に変換して、それらのパケットを電話Ａに送る。
【００８２】
ＩＮＶＩＴＥメッセージ（この場合、電話Ａが１０．１０．１０．１０／１０１０でメディアを受け取ることを望んでいることを表す）は、通過ネットワーク上を、通過する。別のプロキシ・サーバが、ある点で、このＩＮＶＩＴＥを受け取る。なお、通過ネットワークから出る道の上にあるＩＮＶＩＴＥを処理するため、この別のプロキシ・サーバを、退出プロキシ・サーバと呼ぶ。この退出プロキシ・サーバは、電話Ｂへのトラフィック及び電話Ｂからのトラフィックを提供するようにうまく適合化された別のＮＡＴデバイス（例えば、ＮＡＴ Ｂ）上で、さらに別の要求を実行して、ＮＡＴ Ｂの「外側」にあるものが、ＩＮＶＩＴＥ中に現在含まれているエンドポイント（１０．１０．１０．１０／１０１０）に到達できるためのアドレスを、検出する。ＮＡＴ Ｂは、特定のアドレス、例えば２０．２０．２０．２０／２０２０で応答する。このアドレスの重要な点は、外側にあるもの（例えば、電話Ｂ）によって２０．２０．２０．２０／２０２０にアドレス指定されて送られたパケットが、ＮＡＴ Ｂに到着すると、アドレスを書き換えられ、具体的に、１０．１０．１０．１０／１０１０というアドレスに、変換されるということである。したがって、通過ネットワークは、このデータをＮＡＴ Ａに経路指定し（このように経路指定するように設定されているため）、ＮＡＴ Ａは、前のパラグラフで指摘したように、この場合もそのデータのアドレスを、１．１．１．１／１１１１に書き直す。
【００８３】
次いで、ＩＮＶＩＴＥは電話Ｂに送られ、電話Ｂは、ＩＮＶＩＴＥの内容によって、メディア・パケットを、アドレス２０．２０．２０．２０／２０２０に送る。メディア・パケットは、アドレス２０．２０．２０．２０に進み、アドレス２０．２０．２０．２０は、ネットワーク構成が正しいとすると、それをＮＡＴ Ｂに到着させる。ＮＡＴ Ｂで、それは１０．１０．１０．１０／１０１０に変換され、したがってＮＡＴ Ａに到着する。ＮＡＴ Ａはそれを１．１．１．１／１１１１に変換して、電話Ａに送る。
【００８４】
結果として得られるアドレスは異なるが、全く同じ１組の動作が、電話Ｂから戻ってくるＯＫにも、適用される。ただし、その方向は反対である。最初に、退出プロキシ・サーバが、ＮＡＴ Ｂに、通過ネットワークの内側にあるものが電話Ｂ（２．２．２．２／２２２２にある）に到達できるためのアドレスを要求する。場合によって、ＮＡＴ Ｂは、４０．４０．４０．４０／４０４０というアドレスを返す。ＯＫメッセージは、これを示すように退出プロキシ・サーバによって書き換えられて、進入プロキシ・サーバに送られる。このプロキシ・サーバは、外側にあるもの（例えば電話Ａ）がアドレス４０．４０．４０．４０／４０４０に到達できるためのアドレスを、ＮＡＴ Ａに要求する。ＮＡＴ Ａは、５０．５０．５０．５０／５０５０というアドレスを返すかもしれない。この場合も、ＯＫは、これを示すように書き換えられて、電話Ａに送られる。電話Ａは、次いで、そのメディア・パケットのすべてを、アドレス５０．５０．５０．５０／５０５０に送る。
【００８５】
要するに、電話Ｂがそのメディア・パケットを２０．２０．２０．２０／２０２０に送り、電話Ａがそのメディア・パケットを５０．５０．５０．５０／５０５０に送り、すべてのアドレスが、最終的に、メディア・パケットが正しい場所に到着するように変換されるということである。
【００８６】
これを行うことの利点は、２０．２０．２０．２０および５０．５０．５０．５０などのＩＰアドレスを、ＮＡＴを制御する能力を備えたアプリケーションによって、通過ネットワーク自体に属するアドレスに、強制的にして選択することができることである。それによって、２つの電話からのパケットが、通過ネットワーク自体への適切な進入ポイントに到着することを保証し、通過ネットワークが、そのメディアデータを実際に処理することを保証し、さらに、各メディアストリームの進入ポイントを保証することができる。これなしには、メディア・パケットがどのように電話の１つから他の電話に到着するかを、通過ネットワークが、事前にコントロールする方法はない。
【００８７】
ＩＶ．結論、および代替実施形態
本発明の原理および趣旨から逸脱することなく、これらの実施形態および原理の無数の変形、変更、応用、および拡張形態が可能であることが、当業者には明らかであろう。したがって、本発明の範囲は、頭記の特許請求の範囲によって余儀なくされる場合にしか、限定されることはない。
【図面の簡単な説明】
【図１】 複数のデバイスまたはアプリケーションを備えた内部ネットワークをインターネットに接続するための、従来技術のネットワークで使用されているＮＡＴデバイスを示す構成図である。
【図２】 従来技術に従ってアドレス変換を行うＮＡＴデバイスを示す構成図である。
【図３】 ＮＡＴがサービスするアドレス領域中のアプリケーションと、別のアドレス領域中のアプリケーションとの間における通信を容易にするための、本発明の実施形態によるＮＡＴデバイスを示す構成図である。
【発明の背景】
１．発明の分野
本発明は、インターネット上でデータを交換するアプリケーション間の通信を処理するためのデバイスに関する。より詳細には、本発明は、ネットワーク・アドレス変換（ＮＡＴ：Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）デバイスと、このようなＮＡＴデバイスを用いて、インターネット上でのデータのピア・ツー・ピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）通信を容易にするためのシステムおよび方法と、に関連する。
【０００２】
２．従来技術の説明
図１に示すように、従来の種類のネットワーク・アドレス変換（ＮＡＴ）デバイス２０は、通常、２つの異種のアドレス領域５０と３０との間の境界にある、インターネット・プロトコル（ＩＰ）ネットワーク内に配置されている。一方の領域５０は、民間組織の内部ネットワーク１０であってよく、他方の領域３０は、公衆グローバル・インターネットであってよい。このような従来のデバイスが扱う問題は、組織が、大規模な内部ネットワークを必要とし、そのネットワーク上に、各々が一意のＩＰアドレスを必要とする多くのデバイスを備える場合がある、ということである。現在利用可能な一意のＩＰアドレス（２32通りの利用可能アドレス）のためのアドレス空間、および現在のアドレス割振りパターンを考えると、この組織は、このようなアドレスを割り当てる権威ある機関によって、充分な数の公式ＩＰアドレスを、割り振ってもらえないことがある。したがって、この組織は、実質的に、それ自体の内部ネットワークのための内部的に有効なアドレスを、生成せざるを得ない。これによって、内部ネットワークは、正しく機能するであろう；このような状況において、公式に割り当てられるＩＰアドレスを使用する必要は全くない。その大規模内部ネットワーク中のデバイスまたはアプリケーション（特定のデバイス上で実行しているプログラム）が、グローバル・インターネット（公式に割り当てられたＩＰアドレスを使用している、公衆または民間の任意のＩＰネットワークを意味する）と通信を行うことが必要になったときに、困難が生じる。組織が内部的に割り当てたアドレスは、ある別の組織に属する、公式に割り当てられたアドレスと重複するため、または公式に割り当てられたものではないため、グローバル・インターネットは、それらを使って、その組織の内部ネットワーク中に正しくデータを送ることができない。たとえば、ネットワークに接続されたデバイスにデータを送るために、送信元アプリケーションは、ターゲット・アプリケーションのアドレスを持っていなければならず、データを受信するネットワーク自体は、そのターゲット・アプリケーションの位置を捜し出す方法を知らなければならない。これらの動作は、どのＩＰアドレスがどのデバイスおよびアプリケーションに所属するかに関する取り決めに、すべての参与アプリケーションが合意している場合にのみ、うまく機能する。
【０００３】
１つの解決策は、その組織が、１組の公式ＩＰアドレスを、割り当ててもらうことである。これらは、一意のアドレスである。これらのアドレスにデータを送るグローバル・インターネット上のどのアプリケーションも、そのデータが、その組織の内部ネットワークの入口に到着することを、信頼することができる。すなわち、グローバル・インターネットのインフラ・ストラクチャは、データをその組織に正しく送達し、その後に、（ＩＰが正常である場合）その組織が、組織内の正しいエンドポイント・アプリケーションを突き止めて、最終的な送達を行ってくれることを信頼する。
【０００４】
その組織は、次いで、それに割り振られた公式ＩＰアドレスのそれぞれを、無期限に、個々のアプリケーションに割り当てて、幸運である、わずかなアプリケーションだけに、インターネット・アクセスを許可することができる。より広範なアクセスを可能にする、より良い解決策は、実質的に、任意の所与の時間に、グローバル・インターネットにアクセスする必要がある任意のアプリケーションに対して、公式に割り振られたＩＰアドレスを、動的に割り当てることができるデバイスを使用することである。アドレスは、もうそれらを使用していないアプリケーションから回収され、再割当て用として、利用可能にされる。この共用システムは、非常にうまく機能し、最も簡単な形態において、まさに従来のネットワーク・アドレス変換機構（ＮＡＴ）が通常行っているものである。（インターネット技術標準化委員会（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）発行のＲＦＣ２６６３「ＩＰネットワーク・アドレス変換（ＮＡＴ）の術語および考察（ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ ａｎｄ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ）」を参照されたい。これは、ＮＡＴデバイスを取り巻く動作および問題を説明している基本的なＩＥＴＦ文書である。）
しばしば、組織は、特定の非常にわずかの公式ＩＰアドレスしか、割り当てられない。場合によってはわずか３１、または２５５のこのようなアドレスが、組織に与えられることがある。その内部ネットワーク上に、何千ものアプリケーションを有する組織にとって、公式ＩＰアドレスを割り当てることしかできない単純なＮＡＴは、十分ではないことがある。例えば、５，０００のアプリケーション（そのそれぞれが個々の従業員に対応している）のうちのわずか３１だけが、一度にグローバル・インターネットを使用できるのであれば、問題は、完全に解決されていない。
【０００５】
公式に割り振られたアドレス・プールの有用なサイズを有効に拡張するために、組織のＮＡＴは、通常、同じ公式アドレスを複数の内部アプリケーションに使用する能力を備えている。特定の公式ＩＰアドレス（例えば、Ｘ）宛てに到着するデータを、いくつかのデータス・トリーム（例えば、Ａ、Ｂ、およびＣ）の１つに所属させることによって、さらに識別することができる。ＮＡＴは、アドレスＸのストリームＡを、あるアプリケーションのための特定のデータス・トリームに割り当てることができ、一方、アドレスＸのストリームＢおよびＣは、別の２つの異なるアプリケーションに所属する。
【０００６】
ストリーム識別子は、ポート番号と呼ばれる。ＩＰネットワーク中のデータのストリームは、次の５つの別個の数値量から成る、いわゆる「５タプル」によって一意に識別される：
１）ソースＩＰアドレス
２）宛先ＩＰアドレス
３）ソースポート番号
４）宛先ポート番号
５）トランスポート・プロトコル。
【０００７】
ＩＰネットワーク中のあらゆるデータ項目（パケット）は、その中にこれらの５つの数値識別子を持っている。２つのＩＰアドレス（上記の項目１および項目２））は、多かれ少なかれ、ソースおよび目的アプリケーションを識別する。プロトコルは、信頼できるデータの移送を確実にするためのどのメカニズムが使用されているかを識別する。現在の目的において、プロトコルは、ＮＡＴにとっては必要なものではないため、それについては無視する。ソースおよび宛先ポート（上記の項目３および項目４）は、ネットワーク中のどのアプリケーションが、このパケットを送ったのか、また受信するのかをそれぞれ識別する。
【０００８】
本明細書が考える従来のネットワーク・アドレス変換機（例えば、カリフォルニア州サンホセのシスコ・システムズ社のプライベート・インターネット交換（ＰＩＸ：Ｐｒｉｖａｔｅ Ｉｎｔｅｒｎｅｔ Ｅｘｃｈａｎｇｅ）は、パケット内のこれらの５つの数値識別子を変更することによって動作する。上述のように、ＮＡＴデバイスは、２つのアドレス領域の間、必ずではないが通常は、グローバル・インターネットと組織のプライベート・ネットワークとの境界に常駐し、この場合、これら２つのネットワークは、互換性がないＩＰアドレス指定方式を使用している。ＮＡＴデバイスは、その中を流れる各パケット内の４つのソース／宛先エレメントを知的に書き直すことを利用して、２つのネットワークのそれぞれに、相手のネットワークのＩＰアドレス指定方式の偽りではあるが互換性があるビューを示す。各ＮＡＴは、それがアドレス変換のために使用する、内部アドレス／外部アドレスの組合わせを定義する、１組の規則を備えていなければならない。有用なＮＡＴは、これらの組合せを作って、内部アプリケーションが、利用可能な外部アドレスを有効に利用できるようにしなければならない。この外部アドレスは、外部領域が公式ＩＰアドレスを要求する場合、制限される。
【０００９】
内部ネットワークに関連する従来のＮＡＴは、基本的に２種類の同時動作モードをサポートする。第１は、内部ネットワーク上のアプリケーションから外部のグローバル・インターネットに向けた、データ・トランザクションを可能にする（例えば、法人ユーザによるウェブページへのアクセス）。これは、内部クライアントの外部サーバへのアクセスである。第２は、グローバル・インターネット上のアプリケーションが、内部ネットワーク上の特定のデバイス上の特定のサービスにアクセスすることを可能にする（例えば、顧客による組織のウェブサイトへのアクセス）。これは、外部クライアントの内部サーバへのアクセスである。従来のＮＡＴデバイスが、第１および第２のタイプのアクセスを可能にするアドレスの組合せ（アドレス・ペアリング）を作る方法は、いくらか異なる。
【００１０】
従来のＮＡＴデバイスは、第１のモードを、次のように実施する。データ・トランザクションの最初のアウトバウンド・パケットが、ＮＡＴデバイスに到着すると、ＮＡＴデバイスは、そのソース・アドレスおよびポート（パケットを送信した内部のデバイスおよびアプリケーションを識別する）を調べる。ＮＡＴは、次いで、その利用可能公式アドレスおよびポートのプールから、外部で有効なＩＰアドレスおよびポートを選び、パケット中の内部で有効なソース・アドレスおよびポートと置き換えて使用する。内部で有効なソース・アドレスおよびポートから、外部で有効なソース・アドレスおよびポートへのマッピングは、ＮＡＴ内において、何らかの形で、例えば、対応する規則を定義するテーブル形式で、保持される。最後に、ＮＡＴは、アウトバウンド・パケット中の内部で有効なソース・アドレスおよびポートのフィールドを修正して、それを転送する。初期パケットに応答するインバウンド返信パケットが、外側からＮＡＴに現れた場合、その返信パケット中の宛先アドレスおよびポートは、外部で有効なソース・アドレスおよびポートに一致する（なぜならば、返信において、例えば、まさに郵便の手紙の場合のように、当然、送信者のアドレスと受信者のアドレスが、反対になるからである。）ＮＡＴは、この着信した、外部で有効なソース・アドレスおよびポートを使って、初期アウトバウンド・パケットから、内部で有効なソース・アドレスおよびポートを突き止める。ＮＡＴは、次いで、突き止めた内部で有効なソース・アドレスおよびポートを使って、この着信した返信パケット中の宛先アドレスおよびポートを置き換える。この場合、着信した返信パケットは、初期アウトバウンド・パケットを送ったデバイスおよびアプリケーションに送達するための、正しい内部で有効な宛先アドレスおよびポートを備えている。
【００１１】
従来のＮＡＴデバイスは、第２のモードを、ＮＡＴを管理する者によって定義される固定内部／外部アドレス対応構成情報を使って、実施する。このモードの場合、初期パケットは、公式に割り振られたＩＰアドレスのうちの１つを含む、特定の宛先情報を備えて、外部から入って来て、ＮＡＴに到着する。なぜならば、これらの外部で有効なアドレスは、グローバル・インターネットがＮＡＴを使ってターゲット組織にパケットを送達するために使用できるＩＰアドレスだけだからである。ターゲット組織のＮＡＴは、その構成情報に相談して、その着信パケット中に含まれている外部で有効な宛先アドレスおよびポートと交換するのに、どの（固定された）内部で有効な宛先ＩＰアドレスおよびポートを使うべきかを判断する。実際、アプリケーション（例えば、ウェブサーバ）が、ターゲット組織の内部デバイスＡ（非公式の、内部で有効なＩＰアドレス）に存在し、パケットがポートＸに要求されている場合、ＮＡＴは、ＩＰアドレスＭ（公式に割り当てられ、外部で有効）、ポートＹにアドレス指定されたパケットを、内部で有効なアドレス、デバイスＡ／ポートＸにアドレス指定し直すべきであると認識するように、構成することができる。ターゲット組織の別のアプリケーションが、外部からポートＺのデバイスＢとして認識される別の内部デバイス上で実行していることがあり、ＮＡＴは、この場合も特定の固定された事前定義の構成データに従って、同じ内部アドレスＡと特定の別のポートを用いて、このアプリケーションの内部／外部アドレスの組合せを使うことができる。
【００１２】
問題は、第１のモードが、外部サーバにデータを送る（かつ、その後、そこからデータを受け取る）ことを、内部クライアントに許可するだけであり、一方、第２のモードが、内部サーバに関連するＮＡＴ中で事前定義された、固定ＩＰアドレスおよびポートの、少数の１組の内部サーバにデータを送る（かつ、その後、そこから返信を受け取る）ことを、外部クライアントに許可するだけという点である。ある外部クライアントが、割り振られたばかりのポート番号で、作成されたばかりの内部サーバに接続するトランザクションは、サポートされない。
【００１３】
様々な従来技術の参考文献が、ＮＡＴデバイス、およびその基本的なアドレス変換機能の変形について説明している：
「Ｍｅｔｈｏｄ Ａｎｄ Ｓｙｓｔｅｍ Ｆｏｒ Ｌｏｃａｔｉｎｇ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅｓ Ｗｉｔｈ Ｄｉｓｔｒｉｂｕｔｅｄ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ（分散ネットワーク・アドレス変換でネットワーク・サービスの位置を突き止めるための方法およびシステム）」という名称の米国特許第６，０５５，２３６号は、基本的に、サービスを安全にアドバタイズする方法を扱っている。その米国特許第６，０５５，２３６号は、クライアント側の情報にアドレスを提供する対称の問題には言及しておらず、ひたすら、サーバのために外部で有用なアドレスをアドバタイズことに焦点を当て、クライアントが使用する外部アドレスについては何も述べていない。
【００１４】
「Ｓｅｃｕｒｉｔｙ Ｓｙｓｔｅｍ Ｆｏｒ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ Ｓｙｓｔｅｍｓ（ネットワーク・アドレス変換システムのためのセキュリティ・システム）」という名称の米国特許第５，７９３，７６３号は、デバイスがＩＰアドレスを変換するだけで、また、セキュリティ上の考慮すべき事柄に関するものであるという点を除けば、ある種のＮＡＴデバイスに関する特許である。そこに、ポート番号を使って、利用可能な「論理」アドレス・スペースを拡張するというテーマについての教示は何もない。
【００１５】
ＳＯＣＫＳ。ＳＯＣＫＳは、インターネット技術標準化委員会（ＩＥＴＦ）標準であり、それによって、アプリケーションが、リモート・クライアント・アプリケーションにアドバタイズできる外部で有用なアドレスに関して、アプリケーション・ファイアウォールに照会することができるメカニズムを提供する。ＳＯＣＫＳは、このアプリケーションのプロキシであり、ＮＡＴと同様のサービスを提供するが、全く異なって動作する。パケットがデバイスの中を流れるときにその内容を書き直すのではなく、ＳＯＣＫＳは（任意のアプリケーション・プロキシのように）、２つの通信チャネルを終了して、それ自体の内部の上層で、それらを論理的に接続する。例えば、ネットワークの内部にあるサーバは、そのサービスを開始し、次いで、ネットワークの端にあるＳＯＣＫＳアプリケーションに要求を出すことがある。ＳＯＣＫＳアプリケーションは、ネットワークの端で、そのホスト上の「シン（ｔｈｉｎ）」サーバを開始し、次いで、その「シン」サーバを見つけることができるアドレスおよびポートを、元のサーバに知らせる。元のサーバは、この情報をクライアントに伝達し、クライアントは、ＳＯＣＫＳが動作している「シン」サーバに接続する。ＳＯＣＫＳは、次いで、クライアントとして元のサーバに接続し、その後、外部クライアントから受け取ったデータを元のサーバにコピーし、また、元のサーバから受け取ったデータを、外部クライアントに返してコピーする。特に、ＳＯＣＫＳは、ＮＡＴではなく、特定のパフォーマンスおよびスケーリングを伴う、パケットごとの動作を行わない。ＳＯＣＫＳに関するさらなる情報は、ｈｔｔｐ：／／ｗｗｗ．ｓｏｃｋｓ．ｎｅｃ．ｃｏｍを参照されたい。
【００１６】
ディジタル化された声、音、またはビデオ（「メディア」コンテンツ）から成るデータを送るために、ＩＰネットワークの使用が増えるであろうと予想されている。インターネットおよびその他のＩＰネットワーク上のピア・ツー・ピアのデータ交換（メディアの伝送を含む）を容易にする、ネットワーク・アドレス変換のための方法および装置が、必要とされている。
【００１７】
【発明の概要】
本発明は、第１のアドレス領域中の第１のアプリケーションと、異なるアドレス領域中の第２のアプリケーションと、の間の通信を容易にするための、ネットワーク・アドレス変換デバイスを含む。このデバイスは、変換規則に基づいて、第１のアドレス領域で有効なアドレスを、第２のアドレス領域で有効なアドレスに変換し、かつ、第２のアドレス領域で有効なアドレスを第１の領域で有効なアドレスに変換するための、アドレス変換機構を使用する。また、第１のアドレス領域で有効なアドレスを第２のアドレス領域で有効なアドレスに関連付けることによって変換規則を確立する、アドレス・マネージャを使用する。アドレス・マネージャと通信する制御チャネルが存在し、この制御チャネルは、第１のアプリケーションから、第１の領域で有効な指定アドレスに関連付けることができる第２のアドレス領域で有効なアドレスを求める要求を受け取り、かつ、第２のアプリケーションへの第２の領域で有効なアドレスの伝達を容易にするために、第１のアプリケーションに第２のアドレス領域で有効なアドレスへのアクセスを提供する。
【００１８】
本発明の一実施形態において、アプリケーションは、ＩＰ電話に接続されたエンティティである。本発明の別の実施形態において、アドレス・マネージャは、より複雑な変換規則を確立し、それによって、外部で有効な宛先アドレスは、着信ソース・アドレスに応じて、ある値または別の値の、内部で有効なアドレスに、変換することができる。特定の複数リモート・アドレス、より大きなリモート・アドレス・セット、あるいは、任意の単一リモート・アドレスは、特定のより複雑なＮＡＴ規則を使用するためのトリガとして、使うことができる。さらなる実施形態において、アプリケーションは、アドレス・マネージャが確立した変換規則を特定の範囲内で制御するように、プログラムされる。
【００１９】
【詳細な説明】
Ｉ．ピア・ツー・ピア・アプリケーション
本発明を使ったシステムは、一方のデバイスが周知のロケーション（ＩＰアドレス）にあり、もう一方を周知のロケーション（ＩＰアドレス）に位置することも位置しないこともあるという伝統的なモデルとは異なり、ピア・ツー・ピア（いずれかの場所に位置し、基本的に対称的に通信を行う１つまたは複数のデバイス）方式で動作する新しい種類のインターネット・アプリケーションにとって、少なくとも、役に立つ。
【００２０】
新世代のインターネット・アプリケーション（例えば、ＩＰ電話、インスタント・メッセージングなど）によって、異なるアドレス領域内のネットワーク上の複数のユーザが、直接、互いのコンピュータに接続することが可能となり、データを共用し、又は、共同して働き、或いは、持続的なリアルタイム対話で、単にチャットすることができる。これらのプロトコルにおいて、各ユーザのコンピュータは、マイクロ・サーバと呼ばれることがあるアプリケーションをセットアップし、次いで、異なるアドレス領域に位置する別のコンピュータに、マイクロ・サーバに到達することができるＩＰアドレスおよびポートを伝達する。（これが、従来のＮＡＴデバイスが扱っていない「割り振られたばかりのポート番号」の「作成されたばかりの内部サーバ」である。）ピア・ツー・ピア接続を完了するために、各ユーザのコンピュータは、次いで、クライアント・アプリケーションを立ち上げて、別のアドレス領域中のマイクロ・サーバに接続する。それぞれのクライアント・アプリケーションは、次いで、その別のアドレス領域中のその別のコンピュータ上のマイクロ・サーバに到達できるアドレスを保有しなければならない。その後、異なるアドレス領域を扱うＮＡＴを使って、２つのクライアント／マイクロ・サーバのペアの間で、双方向通信が開始可能になる。
【００２１】
上述のように、図１は、従来のＮＡＴが使用されている状況を示す。通常、解決すべき一般的な問題は、大規模な内部ネットワーク１０に関する問題であり、その内部ネットワーク１０は、非公式の、即ち割り当てられていないＩＰアドレスであって、グローバル・インターネットにとっては未知である、またはグローバル・インターネットによっては正しく経路指定されないＩＰアドレスの領域５０中に存在している。ＮＡＴデバイス２０は、内部ネットワーク１０のグローバル・インターネット３０への単一相互接続点（または複数相互接続点）に、配置されている。ＮＡＴ２０は、公式に割り当てられたアドレスの小プールを使って、グローバル・インターネット３０に対し、公式に割り当てられたＩＰアドレスを使って、小規模デバイス・ネットワークという幻想（イルージョン）を作り出す。また、ＮＡＴ２０は、内部ネットワーク１０内のデバイスの多くまたはすべてに、グローバル・インターネット３０への特定のアクセスを提供する。
【００２２】
１つには、アプリケーションおよびその対応するＮＡＴが通信する方法が、限定されたものであるために、ピア・ツー・ピア・アプリケーションは、現世代のＮＡＴデバイスを介して、作動しない。普通、ＮＡＴデバイスは、メッセージ・パケットのＩＰアドレス・フィールドのみを処理し、限定された１組の規則に従って、アドレス変換を行う。図２は、従来のＮＡＴ１２０の基本的なアドレス変換機能を示す。ホストＡ１１０は、従来のＮＡＴ１２０がサービスするアドレス領域１００の一部にある。アプリケーションＡ１ １２１は、ホストＡ上で実行している。それは、内部で有効であって、着信メッセージ・パケットをそれに経路指定するために使用する、宛先アドレスまたは終了アドレスを有する。また、アプリケーションＡ１は、アプリケーションＡ１を、それが送信したメッセージ・パケットのソースとして識別するために使用される、送信元アドレスも有する。上述のように、ＩＰメッセージ・パケットは５つの部分から成るＩＰヘッダを含む。したがって、アプリケーションＡ１が、遠隔の外部アドレス領域中のホストＲ２１０に送ることを望む発信パケット１３０は、そのＩＰヘッダ１４０中に次の構成要素を有する：
１）ソースＩＰアドレス
２）宛先ＩＰアドレス
３）ソースポート番号
４）宛先ポート番号
５）トランスポート・プロトコル。
【００２３】
このＩＰヘッダの後に、メディアであってよいデータ１４２が続く。アプリケーションＡ１が、発信メッセージ１３０をＮＡＴ１２０に提供すると、ＮＡＴ１２０は、内部で有効なアドレスおよびポート番号をいずれも、外部で有効なアドレスおよびポート番号に、置き換えなければならない。ＮＡＴ１２０は、任意の形態（例えば、対応テーブル１２４など）で記憶されているその変換規則を適用する、ハードウェアおよびソフトウェア１２２を備えることができる。一般に、アプリケーションＡ１ １２１は、内部で有効なソースＩＰアドレスおよびソースポート番号（その送信元アドレス）しか持っておらず、ＮＡＴ１２０は、それらをホストＲ２１０に伝送する前に、いずれかの発信メッセージ１３０中に挿入するとき、パケット２３０の外部で有効なアドレス・ヘッダ２４０に変換しなければならない。簡単にするために、ホストＲが、公式ＩＰアドレスを使用するアドレス領域２００中にあると想定する。この場合、ＮＡＴ及びアドレス変換のいずれも、外部で有効なアドレス・ヘッダ２４０を有するパケット２３０を、ホストＲのアドレス領域２００中の指定宛先ＩＰアドレスおよびポートに送達するために、不必要である。
【００２４】
ホストＲの返信パケット２５０は、そのアドレス・ヘッダ２６０中に、外部で有効なＩＰアドレスを使用する。ＮＡＴ１２０は、これらの外部で有効なアドレスを、アドレス領域１００のための内部で有効なＩＰアドレスに変換する必要がある。この場合も、ＮＡＴは、任意の形態（例えば、対応テーブル１２４など）で記憶されたその変換規則を適用する、ハードウェアおよびソフトウェア１２２を使用する。ホストＲからホストＡに伝送されると、その結果、内部で有効なパケット１５０は、内部で有効な宛先アドレスおよびポート（すなわち、アプリケーションＡ１の終了アドレス）を有する、適切に変換されたアドレス・ヘッダ１６０を備える。これによって、データ・コンテンツ１６２を備えた内部で有効なパケット１５０が、アプリケーションＡ１に到達することができる。
【００２５】
本発明により容易になるピア・ツー・ピア通信のためのマイクロ・サーバは、潜在的に、組織の内部ネットワーク内の任意のホストデバイス上に、常駐している。これらのマイクロ・サーバは、一般に、基礎をなすオペレーティング・システムによって（オペレーティング・システム固有の方法で）、そのサービスのために使用するポートとして、ランダムな、利用可能ポート番号を、割り当てられる；この番号は、マイクロ・サーバが実行しているホストデバイス上のどの他のアプリケーションも、現在、使用していない番号である。実際、マイクロ・サーバは、そのマイクロ・サーバのアドレスを伝達するアプリケーションと同じデバイス上に常駐していなければならない理由もない。また、別のアドレス領域中のマイクロ・サーバのクライアントは、データ交換のセットアップのためにそのマイクロ・サーバのアドレスが伝達されるべきデバイスと同じデバイス上に、常駐していなければならない必要もない。しかし、このような分離が生じる場合、すべてのアプリケーションが、それらが知る必要があるすべてのアドレスおよびポート情報を知るように、特定のイントラ・ネットワーク通信が、必要になる。
【００２６】
本明細書において「ピア・ツー・ピア・アプリケーション」として説明しているアプリケーションの種類について言及する。この種のアプリケーションは、２つのアプリケーションがネットワーク上で基本的に対称的な方式で通信を行うような、すべてのアプリケーションを含むことを意図されている。この場合、アプリケーションが、サービスを提供する、またはサービスを受け取るという意味でのサーバでもクライアントでもないことは明らかである。そうではなく、両方のアプリケーションは、他方のために、同じまたは同様の機能を実行する。なお、本明細書の残りの部分において、データ転送セッションを開始するアプリケーションという意味で「クライアント」という用語を使用し、また、クライアントからのデータ転送セッションの開始を受け付けるアプリケーションという意味で「サーバ」という用語を使っていることに留意されたい。これは、２つのアプリケーション間を通る初期データパケットが、どちらの方向に進むのかを定義するために役立つ、便利な用語である。この開始ステップは、ＮＡＴの挙動を説明するために重要である。別途記載がない限り、「クライアント」という用語は、データ転送の初期セッションパケットを送るアプリケーションまたはデバイスを意味し、「サーバ」は、その初期パケットが向けられる先のアプリケーションまたはデバイスを意味することを、出願人は、意図している。
【００２７】
ＩＰ電話は、ピア・ツー・ピア・アプリケーションの著名な例である。この例において、各エンドポイント・アプリケーションは、いわゆる「メディア」接続を開始して、ディジタル化された音声を含むパケットを別のアプリケーションに送ることによって、クライアントとして動作する。その別のアプリケーションは、ディジタル化された音声を含むパケットを、サーバとして受け取る。ディジタル化された音声は、両方向に通るため、この関係は、多かれ少なかれ、対称的である。
【００２８】
ＩＰ電話おいて、内部ネットワーク上のマイクロ・サーバ（例えば、リモート電話からのディジタル化された音声パケットのストリームを待ちうけるＩＰ電話）は、通常、そのホストデバイスのＩＰアドレスを、リモート・クライアント（別のＩＰ電話、あるいは、特定の別のデバイス（例えば、別の電話のために動作する、仮想ＰＢＸまたはその他のＩＰ電話ゲートウェイなど））に、伝達する必要がある。マイクロ・サーバの、内部で有効なネットワーク・アドレスは、グローバル・インターネット上のクライアントにとって、役に立たない。なぜならば、このアドレスは、公式に割り当てられたＩＰアドレスではないからである。マイクロ・サーバが、初期パケットによってリモート・クライアントに伝達することができる公式ＩＰアドレスを、何とか独立して検出または計算できたとしても、従来のＮＡＴは、リモート・クライアント・アプリケーションが送ってきた最初の返信パケットをどのように処置すべきかに関する手順または規則を、依然として何も持っていない。すなわち、ＮＡＴ自体が、この初期パケット中の公式ＩＰアドレスの検出または計算に関与していない限り、ＮＡＴは、内部ネットワーク・アドレスと着信メッセージ中のいずれかの公式ＩＰアドレスとを関連付ける変換規則を何も持っていない。
【００２９】
ＩＩ．改良ピア・ツー・ピア・ネットワーク・アドレス変換デバイス
以下の記載において、図３を参照して、本発明が、どのようにして改良ＮＡＴ装置および方法を使用し、ピア・ツー・ピア・インターネット通信を確立するかを説明する。
【００３０】
異なるアドレス領域間の効率的なピア・ツー・ピア・アプリケーション通信は、アプリケーション（簡単にするために、１対多数または多数対多数の交換ではなく、２つの間でデータを交換する２つのアプリケーションに限定して説明を行う）が、その通信において使用する、公式な、外部で有効なＩＰアドレスの情報にアクセスできることが必要である。最も単純なケースにおいて、第１のアプリケーションは、（１）他のアプリケーションがそれに到達するために使用する、外部で有効なアドレスの情報にアクセスすることが必要であり、それによって、このような第１のアプリケーションが、そのアドレス情報を別のアドレス領域中の第２のアプリケーションに伝達できる。また、第１のアプリケーションは、（２）第２のアプリケーションの外部で有効なアドレスにアクセスすることが必要である。実際、対称であるために、またセキュリティおよびその他の機能を容易にするために、第１および第２のアプリケーションのそれぞれは、２つのアドレスを持っているとよりよい：ここで、２つのアドレスは、送信元アプリケーションのデバイスおよびポートを、アウトバウンド・メッセージ・パケットのソースとして識別するために使用する送信元アドレスＡOと、インバウンド・メッセージ・パケットを受け取る、別のデバイスおよびポートを識別するために使用する、別個の終了アドレスＡTとである。したがって、第１および第２のアプリケーションのそれぞれが、２つの関連する公式アドレス（送信アドレスおよび終了アドレス）を持ち、それらを伝達することによって、理想的な通信は、確立される。さらに、第１および第２のアプリケーションのそれぞれは、ピア・ツー・ピア通信を行うことを望んでいる相手側の送信アドレスおよび終了アドレスにアクセスする。
【００３１】
図３は、異なるアドレス領域中の２つのピア・ツー・ピア・アプリケーション間における改良された通信を容易にするためのシステムを示す。ホストＡ１１０およびホストＢ３１０は、ともにアドレス領域１００の一部である。ホストＡは、その中で実行している１つまたは複数のアプリケーションを有する。例として、アプリケーションＡ１ １２１およびアプリケーションＡ２ １２２を示してある。そのアプリケーションのそれぞれは、内部で有効な終了アドレスおよび内部で有効な送信元アドレスを持っている。ホストＢも、その中で実行している１つまたは複数のアプリケーションを有することができる。例として、アプリケーションＢ１ ３２１およびアプリケーションＢ２ ３２２を示してある。ホストＡおよびホストＢは、同じネットワーク上にあってもよいし、あるいは、そうでない場合、ホストＡとホストＢとの間の通信用のチャネル３７０が存在するように接続される（例えば、一般的な通信ネットワークへの接続）。さらなるホストが、このアドレス領域１００に存在することもあるが、図示していない。
【００３２】
改良ＮＡＴ３２０は、アドレス領域１００を取り扱う。改良ＮＡＴ３２０は、２つの機能セクションを有する。１つは、アドレス変換セクション３２２であり、これは、図２のＮＡＴ１２０に関して説明した従来のアドレス変換機能を実行する。もう一方は、アドレス・マネージャ・セクション３２４である。ＩＰメッセージ・チャネル３６０は、ホストＡ１１０をアドレス変換セクションに接続する。このチャネル３６０は、ＮＡＴ３２０によって取り扱われるホストＡ又はその他の任意のホスト上のアプリケーションが、発信メッセージを送り出す必要があり、かつ、内部で有効なアドレスが、外部で有効なアドレスに変換されることを必要とする場合に、使用される。また、チャネル３６０は、外部で有効なアドレスを有する着信メッセージが、到着し、ＮＡＴ３２０が、着信メッセージ中の外部で有効なアドレスを内部で有効なアドレスに変換して、アドレス領域１００中の該当するアプリケーションにそのメッセージを転送する必要がある場合にも、使用される。
【００３３】
アドレス変換セクション３２２は、「外側」のアドレス領域に接続されている。例として、図３は、アドレス変換セクション３２２に接続されているグローバル・インターネット領域４００を示す。アドレス領域４００内に、別のアドレス領域２００があり、アドレス領域２００は、ホストＡまたはホストＢが通信し得る他のアプリケーション（アプリケーションＲ１、Ｒ２、Ｓ１、およびＳ２が、例として示されている）をホストするホストＲ４１０およびホストＳ５１０を含む。チャネル４７０（例えば、一般的なネットワーク接続）は、ホストＲ４１０とホストＳ５１０との間の通信を提供する。
【００３４】
制御チャネル３５０は、ホストＡ１１０を（および、間接的にホストＢ３１０を）、アドレス・マネージャ・セクション３２４に接続する。制御チャネル３５０は、ＮＡＴ３２０によって取り扱われるホストＡ又は他の任意のホスト上のアプリケーションが、アドレス・マネージャ３２４のサービスを要求するためにＮＡＴ３２０と通信する必要がある場合に、使用される。アドレス・マネージャは、要求しているアプリケーションのために、いくつかのサービスを実施することができる。第１に、要求しているアプリケーションは、内部で有効なアドレス（送信元アドレスまたは終了アドレスのいずれか一方）を提供し、また、アドレス・マネージャ３２４に対して、内部で有効なそのアドレスと組み合わされた外部で有効なアドレスを提供するように要求し、且つアドレス変換セクション３２２にこの組合せ（ペアリング）へのアクセス権を与えるように要求する。これは、アドレス変換セクション３２２が、着信および発信メッセージ・パケットの変換規則としてこの対応を使うように、行うことができる。
【００３５】
第２に、アプリケーションは、アドレス・マネージャ３２４に、単純な内部／外部の組合せを超えるように、ＮＡＴ３２０中で使用されている変換規則に対して、さらなる、またはより複雑な変換規則を、追加させることができる。例えば、単に、対応する内部で有効な宛先アドレスまたはポートを、着信メッセージの中で見つけられた外部で有効な宛先アドレスまたはポートに、無条件に置き換える代わりに、より複雑な変換規則を、アプリケーションの要求で、アドレス・マネージャ３２４によって、構築することができる。アドレス変換セクション３２２が、着信したソース・アドレスおよび／またはポートを調べ、そのフィールドの内容に応じて異なる変換規則を適用するように、規則を、策定することができる。例えば、ＮＡＴ３２０で受信されたパケット中の、外部で有効なアドレスＡEは、もしそのパケット中に特定のソース・アドレスが存在するならば、内部で有効なＡI1に変換されるが、そのソース・アドレスが存在しないならば、変換は行われず、パケットは廃棄される。これはセキュリティのために役立つことがある。あるいは、外部で有効な宛先ポート番号ＰEを、着信したソース・アドレスに応じて、ある値ＰI1または異なる値ＰI2の、内部で有効なポート番号に変換することができる。特定の複数リモート・アドレス、より大きなリモート・アドレス・セット、またはいずれかの単一リモート・アドレスを、特定のＮＡＴ規則を使用するためのトリガとして使うことができる。
【００３６】
第３に、アプリケーションは、内部で有効なアドレスと関連付けるために要求される外部で有効なアドレスに関する必要な特性又は所望の特性を、アドレス・マネージャ３２４に、指定することができる。これは、変換によって得られる外部ＩＰアドレスが特定のＩＰアドレスでなければならないこと、または指定したＩＰアドレス範囲内になければならないことを、アプリケーションに指定させる際に、役に立ち得る。したがって、適切な要求によって、アプリケーションは、メッセージ・パケットが、公衆グローバル・インターネット中の特定の外部サーバに向けられ、または押し進められことを要求するＮＡＴ規則を確立し、同様に、メッセージ・パケットが、再び公衆グローバル・インターネットに転送される前に、そのメッセージ・パケットが、特定のタイプの伝送または請求書作成が発生するような特定のプライベート・ネットワークに向けられるＮＡＴ規則を確立することができる。
【００３７】
したがって、制御チャネル３５０およびアドレス・マネージャ３２４は、従来のＮＡＴでは得られない情報と、ＮＡＴのアドレス変換セクション３２２のために特定の変換規則を確立するための権能との両方を、アプリケーションに提供するための柔軟性に富んだ機能を表していることがわかろう。アドレス・マネージャ３２４は、ハードウェアまたはソフトウェア、あるいはその両方の組合せで実装することができる。例えば、アドレス・マネージャ３２４は、マイクロプロセッサと、アプリケーションからの制御メッセージに応答して、どのサービスおよび機能が利用可能かを判定するコードを記憶するメモリと、を備えていることが望ましいことがある。さらに、アドレス・マネージャ３２４と通信を行う各アプリケーションが、制御チャネル３５０を介して要求がなされることを可能にし、また、要求した情報またはステータス情報がそのアプリケーションに返されることを可能にする、ハードウェアおよび／またはソフトウェアを必要とすることがわかるであろう。
【００３８】
ＩＩＩ．制御チャネルを使ったピア・ツー・ピア交換のサンプル
上述のサーバとクライアントの関係の説明に戻ると、いくつかの異なる例示的状況における、制御チャネル３５０の機能と、アプリケーション、アドレス・マネージャ３２４およびアドレス変換セクション３２２間の通信とを、説明することができる。各例を、図３を参照して説明する。
【００３９】
（サーバのアドレス／ポートの割り振りおよび検出の例）：
アドレス領域１００中のホストＡ１１０は、マイクロ・サーバのアプリケーションＡ１ １２１を起動する。このとき、アプリケーションＡ１ １２１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＲ４１０に、アドレス情報を伝達することを意図している。ホストＲ４１０は、このアドレス情報を使って、マイクロ・サーバのアプリケーションＡ１に接続することができる。ホストＲに有用なアドレス情報を提供するために、以下のステップが存在する：
１．アプリケーションＡ１ １２１は、制御チャネル３５０を介してＮＡＴデバイス３２０と交信し、アプリケーションＡ１が使用している内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる；
２．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスおよびポート番号を、アプリケーションＡ１がその要求の中で提供している内部で有効な終了アドレスに変換する；
３．アプリケーションＡ１（これが、ＩＰメッセージ・パケットを、ホストＲのアプリケーションＲ１ ４２１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴ３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、アプリケーションＡ１にパケットを送る方法を、ホストＲ４１０のアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む；
４．ホストＲ４１０のアプリケーションＲ１ ４２１は、アプリケーションＡ１によって与えられた外部で有効なＩＰアドレスおよびポート番号によって、接続要求を送る。これは（公式ＩＰアドレスに正しくアドレス指定されているので）ＮＡＴ３２０に到着し、そこで、外部で有効なアドレスが、アプリケーションＡ１の、内部で有効なアドレスおよびポートに変換される；
５．ＮＡＴ３２０は、アプリケーションＲ１ ４２１からの返信パケットを、ホストＡ上のアプリケーションＡ１ １２１に送る。
【００４０】
（クライアントのアドレス／ポートの割り振りおよび検出の例）：
アドレス領域２００中の外部ホストＲ４１０は、マイクロ・サーバ、例えばアプリケーションＲ１ ４２１を起動する。アプリケーションＡ１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＲに、アドレス情報を伝達することを意図している。ホストＲは、このアドレス情報を使って、ホストＡからの着信した接続の妥当性を確認することができる。ホストＲ ４２０に有用なアドレス情報を提供するために、以下のステップが存在する。
【００４１】
１．アプリケーションＲ１ ４２１は、ホストＡのアプリケーションＡ１ １２１から、アプリケーションＡ１ １２１からの接続がどのＩＰアドレスおよびポートから行われるかに関する情報を要求するホストＡに、パケットを送る。この送信元アドレス情報は、セキュリティのために有用であり、また、アプリケーションＲ１によって、それ自体の目的（例えば、通信プロトコルへの準拠など）のために、必要とされることもある。
【００４２】
２．ホストＡ上のアプリケーションＡ１ １２１は、制御チャネル３５０を介してＮＡＴデバイス３２０に交信し、アプリケーションＡ１がホストＲ上のマイクロ・サーバと通信を行うために使用する、内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる。
【００４３】
３．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスおよびポート番号を、アプリケーションＡ１がその要求の中で提供している内部で有効な送信元アドレスに変換する。
【００４４】
４．アプリケーションＡ１ １２１（これが、ＩＰメッセージ・パケットをホストＲのアプリケーションＲ１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴデバイス３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、どのＩＰアドレスおよびポートから、アプリケーションＡ１ １２１からのパケットを送信するかを、ホストＲのアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む。
【００４５】
５．アプリケーションＡ１ １２１は、次いで、ホストＲのアプリケーションＲ１ ４２１にアドレス指定した発信パケットを送ることによって、接続を開始し、このパケットは、ＮＡＴデバイス３２０のアドレス変換セクション３２２に到着する。
【００４６】
６．ＮＡＴデバイス３２０のアドレス変換セクション３２２は、パケットのソース・アドレスおよびポート（アプリケーションＡ１の内部ＩＰアドレスおよびポートを表す）を、これらの外部で有効なバージョン（ステップ３でアプリケーションＡ１に渡され、ステップ４で、アプリケーションＡ１がアプリケーションＲ１に送ったもの）に変換する。
【００４７】
７．アドレス変換セクション３２２は、アプリケーションＲ１がこの場合に期待しているソース情報とともに、パケットを、ホストＲのアプリケーションＲ１に送る。
【００４８】
（別個のリクエスタ／サーバを用いた、サーバのアドレス／ポートの割り振りおよび検出の例）：
この例において、ホストＡおよびホストＢは、それらの間の通信チャネル３７０を使用する。これによって、ホストＡ上のアプリケーションは、ホストＢ上のアプリケーションのプロキシとして動作することが可能になる。例えば、ホストＢ上のアプリケーションが、あまり知能を備えていないＩＰ電話の場合、ホストＡは、ＩＰ電話が必要とする様々なサービス（例えば、電話番号案内、電話番号とＩＰアドレスの関連付け）を扱うことが可能であるアプリケーションを備える仮想ＰＢＸであり得り、或いは、何か他の形態のＩＰ電話ゲートウェイであり得る。プロキシを使うと、要求しているエンティティが実際に所有または使用しているアドレスおよびポートと、アドレス・マネージャ３２４への要求で呼び出しているアドレスおよびポートとの間の関係は、何も必要でないことが明らかである。
【００４９】
アドレス領域１００中のホストＢ３１０は、マイクロ・サーバ、例えば、アプリケーションＢ１ ３２１を起動する。このとき、アプリケーションＢ１ ３２１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＲに、アドレス情報を伝達することを意図している。ホストＲ（クライアントとして動作する）は、このアドレス情報を使って、マイクロ・サーバ、アプリケーションＢ１に接続する。ホストＲに有用なアドレス情報を提供するために、以下のステップが存在する。
【００５０】
１．アプリケーションＡ１ １２１は、チャネル３７０を介してアプリケーションＢ１と通信を行って、アプリケーションＢ１ ３２１に交信するのに、どの内部で有効なアドレスおよびポートを使用できるかを検出する。
【００５１】
２．アプリケーションＡ１ １２１は、アドレス領域２００中のアプリケーションＲ１に交信して、アプリケーションＢ１の、外部で有効なアドレスの情報をアプリケーションＲ１に提供する必要がある。アプリケーションＡ１は、制御チャネル３５０を介してＮＡＴデバイス３２０に交信し、アプリケーションＢ１が使用している内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる。
【００５２】
３．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスおよびポート番号を、アプリケーションＡ１がその要求の中で提供している、アプリケーションＢ１の、内部で有効な終了アドレスに変換する。
【００５３】
４．アプリケーションＡ１ １２１（これが、ＩＰメッセージ・パケットをホストＲのアプリケーションＲ１ ４２１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴデバイス３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、アプリケーションＢ１ ３２１にパケットを送る方法を、ホストＲのアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む。
【００５４】
５．ホストＲのアプリケーションＲ１ ４２１は、アプリケーションＡ１ １２１によって与えられた外部で有効なＩＰアドレスおよびポート番号によって、接続要求を送る。これは（公式ＩＰアドレスに正しくアドレス指定されているので）ＮＡＴ３２０に到着し、そこで、外部で有効なアドレスが、アプリケーションＢ１の、内部で有効なアドレスおよびポートに変換される。
【００５５】
６．ＮＡＴ３２０は、アプリケーションＲ１からの返信を、ホストＢ上のアプリケーションＢ１に送る。
【００５６】
（交渉中のエンティティとは別個のクライアント／サーバを用いた、クライアントのアドレス／ポートの割り振りおよび検出の例）：
この例において、ホストＲ４１０およびホストＳ５１０は、それらの間の通信チャネル４７０を使う。これによって、ホストＲ４１０上のアプリケーションは、ホストＳ５１０上のアプリケーションのプロキシとして、動作することができる。例えば、ホストＳ上のアプリケーションが、あまり知能を備えていないＩＰ電話の場合、ホストＲ４１０は、ＩＰ電話が必要とする様々なサービス（例えば、電話番号案内、電話番号とＩＰアドレスの関連付け）を扱うことが可能であるアプリケーションを備える仮想ＰＢＸであり得り、或いは、何か他の形態のＩＰ電話ゲートウェイであり得る。
【００５７】
アドレス領域１００中のホストＳ５１０は、マイクロ・サーバ、例えば、アプリケーションＳ１を起動する。アプリケーションＢ１は、アドレス領域１００の外側にあるアドレス領域２００中のホストＳ５１０に、アドレス情報を伝達することを意図する。ホストＳ５１０は、このアドレス情報を使って、ホストＢから着信した接続の妥当性を確認することができる。ホストＳ５１０に有用なアドレス情報を提供するために、以下のステップが存在する。
【００５８】
１．アプリケーションＲ１ ４２１は、ホストＡのアプリケーションＡ１ １２１から、アプリケーションＢ１ ３２１からの接続がどのＩＰアドレスおよびポートから行われるかに関する情報を要求するホストＡに、パケットを送る。この送信元アドレス情報は、セキュリティのために有用であり、また、アプリケーションＳ１によって、それ自体の目的（例えば、通信プロトコルへの準拠など）のために、必要とされることもある。
【００５９】
２．アプリケーションＡ１ １２１は、チャネル３７０を介してアプリケーションＢ１ ３２１と通信を行って、アプリケーションＳ１ ５２１に交信するのに、どの内部で有効なアドレスおよびポートをアプリケーションＢ１ ３２１が使用するかを検出する。
【００６０】
３．ホストＡ上のアプリケーションＡ１ １２１は、チャネル３５０を介してＮＡＴデバイス３２０に交信し、アプリケーションＢ１がホストＳ５１０上のマイクロ・サーバと通信を行うために使用する、内部で有効なＩＰアドレスおよびポートを、アドレス・マネージャ３２４に知らせる。
【００６１】
４．アプリケーションＡ１ １２１は、アドレス・マネージャ３２４から、返答として、外部で有効なＩＰアドレスおよびポート番号を受け取る。ＮＡＴデバイス３２０は、そのＩＰアドレスよびポート番号を、アプリケーションＡ１ １２１がその要求の中で提供している内部で有効な送信元アドレスに変換する。
【００６２】
５．アプリケーションＡ１ １２１（これが、ＩＰメッセージ・パケットをホストＲのアプリケーションＲ１ ４２１にアドレス指定する能力を有すると想定する）は、次いで、ＮＡＴデバイス３２０のアドレス変換セクション３２２を介して、ＩＰメッセージ・パケットを送る。パケットのデータ部分は、どのＩＰアドレスおよびパケットから、アプリケーションＢ１ ３２１からのパケットを送信するかを、ホストＲのアプリケーションＲ１ ４２１に知らせるために、外部で有効なＩＰアドレスおよびポート番号を含む。
【００６３】
６．アプリケーションＲ１ ４２１は、通信チャネル４７０を介してアプリケーションＳ１ ５２１と通信を行って、アプリケーションＢ１ ３２１がアプリケーションＳ１ ５２１と通信を行うのに使用するＩＰアドレスおよびポートを、アプリケーションＳ１ ５２１に伝達する。
【００６４】
７．アプリケーションＢ１ ３２１は、次いで、ホストＳのアプリケーションＳ１ ５２１にアドレス指定した発信パケットを送ることによって、接続を開始し、このパケットは、ＮＡＴデバイス３２０のアドレス変換セクション３２２に到着する。
【００６５】
８．ＮＡＴデバイス３２０のアドレス変換セクション３２２は、パケットのソース・アドレスおよびポート（アプリケーションＢ１の内部ＩＰアドレスおよびポートを表す）を、これらの外部で有効なバージョン（ステップ４でアプリケーションＡ１ １２１に渡され、ステップ５でアプリケーションＡ１がアプリケーションＲ１ ４２１に送ったもの）に変換する。
【００６６】
９．アドレス変換セクション３２２は、アプリケーションＳ１がこの場合に期待しているソース情報とともに、パケットを、ホストＲ４１０を経由して、ホストＳのアプリケーションＳ１ ５２１に送る。
【００６７】
ＩＶ．音声通信アプリケーション
（Ａ．ＮＡＴ不使用の場合）
本発明のＩＰ電話への適用をさらに詳細に説明するには、ＳＩＰと呼ばれるプロトコルを使った単純な電話の呼が、どのように動作するかを説明することが助けになる。ＳＩＰとは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のことである。しかしながら、ＳＩＰは、一般に、ＳＩＰと、これと一緒になって動作することによって、ユーザがデータ・ネットワーク（例えば、ＩＰ）を介して電話をかける（および何か別のことを行う）ことを可能にするすべての関連プロトコルと、に対する容認された略語である。
【００６８】
ある単純な例において、基本的に、電話の呼を確立するために送られるメッセージが２つある。（この説明において、特定の詳細については触れない。実際には、さらにずっと続く場合がある。）ここで関係がある２つのメッセージは、ＩＮＶＩＴＥ（招待）メッセージと、それに対するＯＫ応答とである。
【００６９】
ＳＩＰ電話（電話Ａと呼ぶ）を使っているある人が、電話番号又は何か別の識別子（例えば、電子メールアドレスなど）で識別できる誰か別の人に、電話をかけたいと思っていると想定する。電話をかけようとする人は、電話番号又は他の識別子を打ち込むことによって、所望のターゲットである相手を入力する。もちろん、電話Ａは、ターゲットである相手がどこにいるかについて、何も知らないが、プロキシ・サーバと呼ばれるより高性能な装置がどこにあるのか、知っている。したがって、電話Ａは、ターゲットが誰なのかに関する情報、特定のその他の情報、および−−これが重要である−−ターゲットが突き止められ、電話が鳴って、電話を取ったときにいつでも、電話Ａがどこでターゲットからメディア・パケットの受け取りを待つのかに関する宛先情報を含む、ＩＮＶＩＴＥメッセージを策定する。電話Ａは、一般に、この情報を、それ自体のＩＰアドレスおよびポート番号という形で、供給する。これらは、それぞれ１．１．１．１および１１１１であると仮定する。
【００７０】
電話Ａが交信したプロキシ・サーバは、ターゲットを突き止めるまで、たいてい、特定のネットワーク・サーチ・パスをたどって、ＩＮＶＩＴＥを他のプロキシ・サーバ・デバイスに送る。この時点で、最初に電話Ａが策定したＩＮＶＩＴＥメッセージは、ターゲットに送達される。このターゲットを電話Ｂと呼ぶ。電話Ｂは、おそらく、しばらくの間、鳴るであろう。そして（幸運にも）誰かがそれを取る。この時点で、電話Ｂは、ＯＫメッセージで応答する。このＯＫメッセージは、電話Ｂがそこでメディアの受け取りを待つ宛先アドレスを含めて、様々な情報を含む。これは、ＩＰアドレス２．２．２．２、ポート番号２２２２であると仮定する。
【００７１】
電話Ｂは、ディジタル化された音声を備えたメディア・パケットを、直ちに１．１．１．１／１１１１に送り始めることができる。なぜならば、電話Ｂは、この情報を、ＩＮＶＩＴＥメッセージ内で、受け取っているからである。ＯＫメッセージが、電話Ａに戻ると（プロキシ・サーバを介して）、その電話は、同様のメディア・パケットを２．２．２．２／２２２２に、送り始めることができる。この時点で、ディジタル・オーディオ・データは、両方向に送られており、その後、推定できるように、会話が行われる。
【００７２】
（Ｂ．ＮＡＴ使用の場合）
図中のＮＡＴを用いた３つのケースが考えられる。第１のケースにおいて、ターゲット電話は、結局、プロキシ・サーバによって、特定のＮＡＴデバイスの内側で捜し出される。第２のケースにおいて、ソースの電話が、（特定の）ＮＡＴデバイスの内側に位置している。第３のケースにおいて、どちらの電話も、ＮＡＴデバイスの「内側」に位置していないが、それらの間のメディア・トラフィックは、ＮＡＴデバイスの内側に配置されているネットワークを通る必要がある。以下に説明する例において、すべてのＮＡＴデバイスは、図３で説明した種類のものである。
【００７３】
もちろん、その様々なケースを組み合わせることができる。一般に、特定のプロキシ・サーバは、ネットワーク中のその他のプロキシ・サーバ、および関与している電話に、ＮＡＴデバイスが全くないという幻想（イルージョン）を、与える。これがうまく行われるので、実際に多数のＮＡＴデバイスは、多数のプロキシ・サーバとともに動作させることができ、そのそれぞれが、自分が唯一のＮＡＴであると確信し、かつネットワークの残りの部分に、結局「ここにはＮＡＴが全くない」と確信させるのである。
【００７４】
１．ターゲット電話がＮＡＴの内側にある場合
この場合、ターゲット電話であり、ＮＡＴのアドレス領域の内側にある電話Ｂは、送信元電話にデータを送ることについて、何の問題もない。なぜならば、ＮＡＴは、一般に、外側のアドレスにアドレス指定することによって、トラフィックをどこにでも送る能力を、その「内側」にあるものに、与えるからである。問題は、送信元電話に何を伝えるべきかを、選別することにある。なぜならば、ターゲット電話は、ＮＡＴの「内側」にあるため、ＮＡＴから何か手助けがない限り、外側から到達することができないからである。ターゲット電話は、グローバルに経路指定可能なＩＰアドレスを使っていない；たいてい、それは、世界の残りの部分にとっては、そこにパケットを送達する方法が全くわからないアドレスである、プライベートＩＰアドレスを使っている。ターゲット電話のローカル・ネットワーク上のデバイスのみが、そこにデータが送達されるという期待を持って、ターゲット電話の実際のＩＰアドレスに、データをアドレス指定することができる。
【００７５】
この場合、ターゲット電話のネットワーク内にあるプロキシ・サーバが、関与しなければならない。もちろん、それは、ＩＮＶＩＴＥをローカル・ネットワーク内の正しい電話に経路指定して呼を完了する責任を持っているので、いずれにしても常に関与している。このプロキシ・サーバは、ターゲット電話からのＯＫ応答の処理も行う。なお、ターゲット電話が、そのアドレスおよびポートである２．２．２．２／２２２２を、このＯＫメッセージ内に書き込むことを思い出されたい。この場合、２．２．２．２は、プライベートであり、内部でのみ有効なため、送信元電話にとって役立つアドレスではない。したがって、プロキシ・サーバは、別の外部で有効なアドレスを入手して、ＯＫメッセージを送信元電話に送り返す前に、その中に含まれているアドレス（および可能にはポート）を取り替えなければならない。
【００７６】
プロキシ・サーバは、ターゲット電話のＮＡＴデバイスに、「サーバ・アドレス／ポートの割り振り／検出」要求を行う。ＮＡＴは、アドレスおよびポート、例えば３．３．３．３／３３３３で応答する。これによって、ＮＡＴデバイスのもう一方の側（「外側」）にあるデバイスは、２．２．２．２／２２２２にあるデバイス（ターゲット電話）に到達することができる。プロキシ・サーバは、２．２．２．２／２２２２の代わりに３．３．３．３／３３３３を表すようにＯＫメッセージを書き直して、この新しいＯＫメッセージを電話Ａに送る。
【００７７】
次に、電話Ｂが、電話Ａにメディア・パケットを送る場合、それは、１．１．１．１／１１１１にアドレス指定され、ＮＡＴは、これがうまく行われるようにする。すなわち、アウトバウンド・トラフィックが、単に、「正しい」外部で有効なアドレスにアドレス指定されるようにする。しかし、電話Ａが、メディア・パケットを電話Ｂに送る場合、ＯＫメッセージ内で受け取られる宛先エンドポイント情報である、３．３．３．３／３３３３に、送られる。正しい構成を前提とすると、このパケットは、ＮＡＴデバイスに到着し、ＮＡＴデバイスは、パケットがプロキシ・サーバの要求によって、２．２．２．２／２２２２にアドレス指定され、ネットワークの内側に送られるように、パケットを変換する。メディア・パケットは、これで、正しくアドレス指定されて、この「プライベートにアドレス指定された」メディア・パケットの送達の仕方を知っているローカル・ネットワーク内に存在する。したがって、所望通りに、メディア・パケットは、電話Ｂに到着する。
【００７８】
２．ターゲット電話がＮＡＴの外側にある場合
これは前の例とほぼ全く同じである。しかし、この場合、電話Ａ（この場合はＮＡＴの「内側」の電話であり、そのローカル・ネットワーク内でのみ有用なプライベートＩＰアドレスを有する）の近くのプロキシ・サーバは、ＮＡＴデバイスに外部で有効なアドレスを照会した後、ＩＮＶＩＴＥメッセージを書き直さなければならない。場合によって、１．１．１．１／１１１１というアドレスは、要求されたＮＡＴ規則のもとで、４．４．４．４／４４４４に書き直される（この場合、１．１．１．１／１１１１は、プライベートＩＰアドレスであり、４．４．４．４／４４４４は、そうではないと想定する）。
【００７９】
電話Ａからのメディア・パケットは、変更されないままＮＡＴデバイスを通って外部に進むが、ＮＡＴの外側にある電話Ｂからのメディア・パケットは、４．４．４．４／４４４４にアドレス指定されて、ＮＡＴデバイスに到着し、１．１．１．１／１１１１に変換されて、最終的に内側の電話Ａに送達される。
【００８０】
３．両方の電話が外側にあって、通過ネットワーク（トランジット・ネットワーク：ｔｒａｎｓｉｔ ｎｅｔｗｏｒｋ）がＮＡＴデバイスを備える場合
この場合、両方の電話はどこか「外」にあり、ＮＡＴ装置を備えたネットワークは通過ネットワーク、おそらくＩＰ電話のための長距離キャリアであることを前提とする。さらに、このネットワークが、ＩＮＶＩＴＥメッセージおよびＯＫメッセージの処理および経路指定に、関与していることも前提とする。おそらく、このネットワークは、パーソン−ロケーション（ｐｅｒｓｏｎ−ｌｏｃａｔｉｏｎ）・サービスを提供し、また、メディアの処理を行う。
【００８１】
電話Ａおよび電話Ｂを、それぞれ１．１．１．１／１１１１および２．２．２．２／２２２２とする。
電話ＡからのＩＮＶＩＴＥが、考慮中の、ＮＡＴを備えた通過ネットワーク中にある特定のプロキシ・サーバに、到着すると想定する。これは、この例では「インバウンド」のＩＮＶＩＴＥを処理するため、進入プロキシ・サーバと呼ぶことができる。進入プロキシ・サーバは、前の諸例と同様に、同じ「サーバのアドレス／ポートの検出」を行って、通過ネットワークの内側のデバイスが電話Ａに到達するために使用できるアドレスを検出する。この動作は、通過ネットワークから電話Ａへの出口ポイントにある、ＮＡＴ Ａと呼ぶ特定のＮＡＴデバイス上で行われると想定する。例えば、ＮＡＴ Ａが、１０．１０．１０．１０／１０１０というアドレス／ポートを返すとする。これは、通過ネットワークの内側にあるものが電話Ａに到達するために使うことができる、通過ネットワーク内において有用なプライベート・アドレスである。すなわち、１０．１０．１０．１０／１０１０にアドレス指定された、通過ネットワーク内のメッセージ・パケットはどれも、そのネットワークによって、ＮＡＴ Ａに経路指定される。ＮＡＴ Ａは、それらのアドレスを１．１．１．１／１１１１に変換して、それらのパケットを電話Ａに送る。
【００８２】
ＩＮＶＩＴＥメッセージ（この場合、電話Ａが１０．１０．１０．１０／１０１０でメディアを受け取ることを望んでいることを表す）は、通過ネットワーク上を、通過する。別のプロキシ・サーバが、ある点で、このＩＮＶＩＴＥを受け取る。なお、通過ネットワークから出る道の上にあるＩＮＶＩＴＥを処理するため、この別のプロキシ・サーバを、退出プロキシ・サーバと呼ぶ。この退出プロキシ・サーバは、電話Ｂへのトラフィック及び電話Ｂからのトラフィックを提供するようにうまく適合化された別のＮＡＴデバイス（例えば、ＮＡＴ Ｂ）上で、さらに別の要求を実行して、ＮＡＴ Ｂの「外側」にあるものが、ＩＮＶＩＴＥ中に現在含まれているエンドポイント（１０．１０．１０．１０／１０１０）に到達できるためのアドレスを、検出する。ＮＡＴ Ｂは、特定のアドレス、例えば２０．２０．２０．２０／２０２０で応答する。このアドレスの重要な点は、外側にあるもの（例えば、電話Ｂ）によって２０．２０．２０．２０／２０２０にアドレス指定されて送られたパケットが、ＮＡＴ Ｂに到着すると、アドレスを書き換えられ、具体的に、１０．１０．１０．１０／１０１０というアドレスに、変換されるということである。したがって、通過ネットワークは、このデータをＮＡＴ Ａに経路指定し（このように経路指定するように設定されているため）、ＮＡＴ Ａは、前のパラグラフで指摘したように、この場合もそのデータのアドレスを、１．１．１．１／１１１１に書き直す。
【００８３】
次いで、ＩＮＶＩＴＥは電話Ｂに送られ、電話Ｂは、ＩＮＶＩＴＥの内容によって、メディア・パケットを、アドレス２０．２０．２０．２０／２０２０に送る。メディア・パケットは、アドレス２０．２０．２０．２０に進み、アドレス２０．２０．２０．２０は、ネットワーク構成が正しいとすると、それをＮＡＴ Ｂに到着させる。ＮＡＴ Ｂで、それは１０．１０．１０．１０／１０１０に変換され、したがってＮＡＴ Ａに到着する。ＮＡＴ Ａはそれを１．１．１．１／１１１１に変換して、電話Ａに送る。
【００８４】
結果として得られるアドレスは異なるが、全く同じ１組の動作が、電話Ｂから戻ってくるＯＫにも、適用される。ただし、その方向は反対である。最初に、退出プロキシ・サーバが、ＮＡＴ Ｂに、通過ネットワークの内側にあるものが電話Ｂ（２．２．２．２／２２２２にある）に到達できるためのアドレスを要求する。場合によって、ＮＡＴ Ｂは、４０．４０．４０．４０／４０４０というアドレスを返す。ＯＫメッセージは、これを示すように退出プロキシ・サーバによって書き換えられて、進入プロキシ・サーバに送られる。このプロキシ・サーバは、外側にあるもの（例えば電話Ａ）がアドレス４０．４０．４０．４０／４０４０に到達できるためのアドレスを、ＮＡＴ Ａに要求する。ＮＡＴ Ａは、５０．５０．５０．５０／５０５０というアドレスを返すかもしれない。この場合も、ＯＫは、これを示すように書き換えられて、電話Ａに送られる。電話Ａは、次いで、そのメディア・パケットのすべてを、アドレス５０．５０．５０．５０／５０５０に送る。
【００８５】
要するに、電話Ｂがそのメディア・パケットを２０．２０．２０．２０／２０２０に送り、電話Ａがそのメディア・パケットを５０．５０．５０．５０／５０５０に送り、すべてのアドレスが、最終的に、メディア・パケットが正しい場所に到着するように変換されるということである。
【００８６】
これを行うことの利点は、２０．２０．２０．２０および５０．５０．５０．５０などのＩＰアドレスを、ＮＡＴを制御する能力を備えたアプリケーションによって、通過ネットワーク自体に属するアドレスに、強制的にして選択することができることである。それによって、２つの電話からのパケットが、通過ネットワーク自体への適切な進入ポイントに到着することを保証し、通過ネットワークが、そのメディアデータを実際に処理することを保証し、さらに、各メディアストリームの進入ポイントを保証することができる。これなしには、メディア・パケットがどのように電話の１つから他の電話に到着するかを、通過ネットワークが、事前にコントロールする方法はない。
【００８７】
ＩＶ．結論、および代替実施形態
本発明の原理および趣旨から逸脱することなく、これらの実施形態および原理の無数の変形、変更、応用、および拡張形態が可能であることが、当業者には明らかであろう。したがって、本発明の範囲は、頭記の特許請求の範囲によって余儀なくされる場合にしか、限定されることはない。
【図面の簡単な説明】
【図１】 複数のデバイスまたはアプリケーションを備えた内部ネットワークをインターネットに接続するための、従来技術のネットワークで使用されているＮＡＴデバイスを示す構成図である。
【図２】 従来技術に従ってアドレス変換を行うＮＡＴデバイスを示す構成図である。
【図３】 ＮＡＴがサービスするアドレス領域中のアプリケーションと、別のアドレス領域中のアプリケーションとの間における通信を容易にするための、本発明の実施形態によるＮＡＴデバイスを示す構成図である。
Claims (67)
- 内部アドレス領域中において有効な内部アドレスを有する第１のアプリケーションと外部アドレス領域中における１又は複数のアプリケーションとの間のメッセージ・パケット通信を容易にするためのネットワーク・アドレス変換デバイスであって、該内部アドレス領域は該外部アドレス領域中における利用に有効な利用可能なアドレスのセットに利用可能であり、該ネットワーク・アドレス変換デバイスは、
前記内部アドレス領域及び前記外部アドレス領域の不適合性を解決する変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセージ・パケットのヘッダに含まれるアドレスを変換するアドレス変換機構と、
前記変換規則を確立し記憶するアドレス・マネージャであって、前記外部アドレス領域中における利用に有効な利用可能なアドレスのセットへのアクセスを有するアドレス・マネージャと、
前記アドレス・マネージャと通信する制御チャネルであって、前記第１のアプリケーションからサービス要求メッセージを受け取って、前記第１のアプリケーション・サービス要求に応答して前記第１のアプリケーションにより指定される変換規則を確立し、および発信メッセージ・パケットのデータ部分に用いて前記外部アドレス領域のアプリケーションとの通信を開始するために、前記第１アプリケーションの内部アドレスとペアになる外部アドレスを前記第１アプリケーションに運搬する、制御チャネルと、
を備える、ネットワーク・アドレス変換デバイス。 - 請求項１記載のネットワーク・アドレス変換デバイスにおいて、前記第１のアプリケーションは、確立される前記変換規則が、前記第１のアプリケーションの内部アドレスを、特定のＩＰアドレスである、又は指定されたＩＰアドレスの範囲内にある利用可能な外部アドレスと関連付けることを指定する、ネットワーク・アドレス変換デバイス。
- 請求項１記載のネットワーク・アドレス変換デバイスにおいて、前記第１のアプリケーションは、前記変換規則が着信メッセージ・パケットに適用可能な２以上の変換規則の内の１つであることを指定し、どの変換規則が適用されるかの選択は前記着信メッセージ・パケット内のアドレス情報による、ネットワーク・アドレス変換デバイス。
- 請求項２記載のネットワーク・アドレス変換デバイスにおいて、前記第１のアプリケーションが要求する前記利用可能な外部アドレスは、宛先アドレスである、ネットワーク・アドレス変換デバイス。
- 請求項２記載のネットワーク・アドレス変換デバイスにおいて、前記第１のアプリケーションが要求する前記利用可能な外部アドレスは、送信元アドレスである、ネットワーク・アドレス変換デバイス。
- 請求項１記載のネットワーク・アドレス変換デバイスにおいて、前記内部アドレス領域はプライベート・ネットワークであり、前記外部アドレス領域はインターネットである、ネットワーク・アドレス変換デバイス。
- 請求項１記載のネットワーク・アドレス変換デバイスにおいて、前記内部アドレス領域はプライベート・ネットワークであり、前記外部アドレス領域はインターネットであり、前記アドレス・マネージャは前記プライベート・ネットワーク領域中において有効なアドレスを前記インターネット中において有効なアドレスと関連付けることによって変換規則を確立する、ネットワーク・アドレス変換デバイス。
- 請求項３記載のネットワーク・アドレス変換デバイスにおいて、どの変換規則が適用されるかの選択は、前記着信メッセージ中の指定送信元アドレス情報の存在又は欠如に応答してなされる、ネットワーク・アドレス変換デバイス。
- 請求項１記載のネットワーク・アドレス変換デバイスにおいて、容易になる前記通信は、ピア・ツー・ピア・アプリケーション通信である、ネットワーク・アドレス変換デバイス。
- 請求項１記載のネットワーク・アドレス変換デバイスにおいて、容易になる前記通信は、ピア・ツー・ピア電話通信である、ネットワーク・アドレス変換デバイス。
- 請求項２記載のネットワーク・アドレス変換デバイスにおいて、確立される前記変換規則は、発信メッセージ・パケットに通過ネットワーク中の宛先アドレスを有するよう強制する、ネットワーク・アドレス変換デバイス。
- 請求項２記載のネットワーク・アドレス変換デバイスにおいて、確立される前記変換規則が、前記第１のアプリケーションと前記第２のアプリケーションとの間の前記パケット通信の少なくとも一部を、指定したネットワーク介して強制的に通過させる、ネットワーク・アドレス変換デバイス。
- 内部アドレス領域中において有効な内部アドレスを有する第１のアプリケーションと外部アドレス領域中における１又は複数のアプリケーションとの間のメッセージ・パケット通信を容易にする方法であって、該内部アドレス領域は該外部アドレス領域中における利用に有効なアドレスのセットに利用可能であり、該方法は、
前記内部アドレス領域及び前記外部アドレス領域の不適合性を解決する変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセー
ジ・パケットのヘッダに含まれるアドレスを変換するアドレス変換機構を有するネットワーク・アドレス変換デバイスを、前記内部アドレス領域に提供するステップと、
前記変換規則を確立し記憶するために、前記外部アドレス領域中における利用に有効な利用可能なアドレスのセットへのアクセスを有するアドレス・マネージャを提供するステップと、
前記アドレス・マネージャと通信する制御チャネルを提供するステップであって、前記第１のアプリケーションからサービス要求メッセージを受け取って、前記第１のアプリケーション・サービス要求に応答して前記第１のアプリケーションにより指定される変換規則を確立し、および発信メッセージ・パケットのデータ部分に用いて前記外部アドレス領域のアプリケーションとの通信を開始するために、前記第１アプリケーションの内部アドレスとペアになる外部アドレスを前記第１アプリケーションに運搬する、ステップと、
を含む、方法 - 請求項１３記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、確立される前記変換規則が、前記第１のアプリケーションの内部アドレスを、特定のＩＰアドレスである、又は指定されたＩＰアドレスの範囲内にある利用可能な外部アドレスと関連付けることを指定する要求を前記第１のアプリケーションから受け取ることを含む、方法。
- 請求項１３記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、前記変換規則が着信メッセージ・パケットに適用可能な２以上の変換規則の内の１つである要求を前記第１のアプリケーションから受け取るステップを含み、どの変換規則が適用されるかの選択は前記着信メッセージ・パケット内のアドレス情報による、方法。
- 請求項１３記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、宛先アドレスに対する変換規則を求める要求を前記第１のアプリケーションから受け取ることを含む、方法。
- 請求項１３記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、送信元アドレスに対する変換規則を求める要求を前記第１のアプリケーションから受け取ることを含む、方法。
- 請求項１３記載の方法において、前記内部アドレス領域はプライベート・ネットワークであり、前記アドレス・マネージャを提供するステップはインターネット中において有効な利用可能なアドレスのセットへのアクセスを有するアドレス・マネージャを提供することを含む、方法。
- 請求項１３記載の方法において、前記内部アドレス領域はプライベート・ネットワークであり、前記外部アドレス領域はインターネットであり、前記アドレス・マネージャを提供するステップは、前記プライベート・ネットワーク中において有効なアドレスをインターネット中において有効なアドレスと関連付けることによって変換規則を確立する、アドレス・マネージャを提供することを含む、方法。
- 請求項１５記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、前記変換規則が着信メッセージに適用可能な２以上の変換規則の内の１つである要求を前記第１のアプリケーションから受け取るステップを含み、どの変換規則が適用されるかの選択は、前記着信メッセージ中の指定送信元アドレス情報の存在又は欠如に応答してなされる、方法。
- 請求項１３記載の方法において、容易になる前記通信は、ピア・ツー・ピア・アプリケーション通信である、方法。
- 請求項１３記載の方法において、容易になる前記通信は、ピア・ツー・ピア・電話通信である、方法。
- 請求項１４記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、確立される前記変換規則が、前記発信メッセージ・パケットに通過ネットワーク中の宛先アドレスを有するよう強制する要求を、前記第１のアプリケーションから受け取ることを含む、方法。
- 請求項１４記載の方法において、要求を受け取るために前記制御チャネルを提供するステップは、確立される前記変換規則が、前記第１のアプリケーションと前記第２のアプリケーションとの間の前記パケット通信の少なくとも一部を、指定したネットワーク介して強制的に通過させる要求を、前記第１のアプリケーションから受け取ることを含む、方法。
- 内部アドレス領域中において有効な内部アドレスを有する第１のアプリケーションと外部アドレス領域中における１又は複数のアプリケーションとの間のメッセージ・パケット通信を容易にする方法であって、該内部アドレス領域は該外部アドレス領域中における利用に有効なアドレスのセットに利用可能であり、該方法は、
前記内部アドレス領域及び前記外部アドレス領域の不適合性を解決する変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセージ・パケットのヘッダに含まれるアドレスを変換するアドレス変換機構を有するネットワーク・アドレス変換デバイスを、前記内部アドレス領域に提供するステップと、
前記変換規則を確立し記憶するために、前記外部アドレス領域中における利用に有効な利用可能なアドレスのセットへのアクセスを有するアドレス・マネージャを提供するステップと、
前記第１のアプリケーションからサービス要求メッセージを受け取り、前記第１のアプリケーション・サービス要求に応答して前記第１のアプリケーションにより指定される変換規則を確立するために前記アドレス・マネージャと通信する制御チャネルを提供するステップと、
を含み、前記アドレス・マネージャは前記サービス要求に応答して、前記第１のアプリケーションへ、前記外部アドレス領域中における利用に有効な第１のアドレスを伝送し、前記第１のアプリケーションは前記第１のアドレスがＳＩＰメッセージ中において前記外部アドレス領域へ伝送されるようにする、方法。 - 請求項２５記載の方法において、前記ＳＩＰメッセージはＳＩＰ ＩＮＶＩＴＥメッセージである、方法。
- 請求項２５記載の方法において、前記第１アプリケーションは前記ＳＩＰメッセージが前記外部アドレス領域内で第２のアプリケーションへ伝送されるようにする、方法。
- 請求項２５記載の方法において、前記第１のアドレスはＩＰアドレスおよびポート番号を含む、方法。
- 請求項２５記載の方法において、ＳＩＰプロキシ・サーバは前記ＳＩＰメッセージを前記外部アドレス領域内の第２のアプリケーションへ伝送する場合に呼び出される、方法。
- 請求項２５記載の方法において、前記ＳＩＰメッセージはピア・ツー・ピア通信セッションを確立するために用いられる、方法。
- 請求項２５記載の方法において、前記ＳＩＰメッセージはＩＰ電話通信セッションを確立するために用いられる、方法。
- 請求項２５記載の方法において、前記ＳＩＰメッセージはインスタント・メッセージング・セッションを確立するために用いられる、方法。
- 内部アドレス領域中において有効な内部アドレスを有する第１のホストと外部アドレス領域中における１又は複数のホストとの間のメッセージ・パケット通信を容易にする第１のＳＩＰ−ａｗａｒｅアプリケーションであって、該内部アドレス領域は該外部アドレス領域中における利用に有効な利用可能なアドレスのセットに利用可能であり、該第１のアプリケーションはステップを行うためにプロセッサにより実行可能な命令を有し、前記ステップが、
前記内部アドレス領域中でネットワーク・アドレス変換デバイスへサービス要求を伝送するステップであって、これにより変換規則は前記ネットワーク変換デバイスのアドレス・マネージャに確立され、前記ネットワーク変換デバイスは、前記内部アドレス領域と外部アドレス領域との間の不適合性を解決する変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセージ・パケットのヘッダに含まれるアドレスを変換するよう適合される、ステップと、
前記サービス要求に応答して、前記内部アドレス領域中で前記ネットワーク変換デバイスから前記外部アドレス領域における利用に有効な第１のアドレスを受け取るステップと、
前記第１のアドレスをＳＩＰメッセージ中の前記外部アドレス領域へ伝送されるようにするステップと、
を含む、第１のＳＩＰ−ａｗａｒｅアプリケーション。 - 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、前記ＳＩＰメッセージはＳＩＰ ＩＮＶＩＴＥメッセージである、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、前記ＳＩＰメッセージは前記外部アドレス領域中で第２のＳＩＰ−ａｗａｒｅアプリケーションへ伝送される、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、前記第１のアドレスはＩＰアドレスおよびポート番号を含む、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、ＳＩＰプロキシ・サーバは、前記外部アドレス領域内で、前記第１のアドレスを第２のＳＩＰ−ａｗａｒｅアプリケーションへ伝送する場合に呼び出される、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、前記ＳＩＰメッセージはピア・ツー・ピア通信セッションを確立するよう用いられる、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、前記ＳＩＰメッセージはＩＰ電話通信セッションを確立するよう用いられる、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 請求項３３記載の第１のＳＩＰ−ａｗａｒｅアプリケーションにおいて、前記ＳＩＰメッセージはインスタント・メッセージング・セッションを確立するよう用いられる、第１のＳＩＰ−ａｗａｒｅアプリケーション。
- 内部アドレス領域中において有効な内部アドレスを有する第１のホストと外部アドレス領域中における１又は複数のホストとの間のメッセージ・パケット通信を容易にする方法であって、該内部アドレス領域は外部アドレス領域中における利用に有効なアドレスのセットに利用可能であり、該方法は、
前記内部アドレス領域中における前記第１のホストに関連付けられる開始するアプリケーションからネットワーク・アドレス変換デバイスのアドレス・マネージャへ、前記ネットワーク変換デバイスに関する変換規則を確立するためのサービス要求を伝送するステップであって、前記ネットワーク変換デバイスは、前記内部アドレス領域と外部アドレス領域との間の不適合性を解決する変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセージ・パケットのヘッダに含まれるアドレスを変換するよう適合される、伝送するステップと、
前記サービス要求に応答して、前記外部アドレス領域内で自身を識別する前記開始するアプリケーションによる利用に有効な第１のアドレスを、前記ネットワーク変換デバイスから受け取るステップと、
前記第１のアドレスが、ＳＩＰメッセージ内で前記外部アドレス領域へ伝送されるようにするステップと、
を含む、方法。 - 請求項４１記載の方法において、前記ＳＩＰメッセージはＳＩＰ ＩＮＶＩＴＥメッセージである、方法。
- 請求項４１記載の方法において、前記第１アドレスは前記外部アドレス領域内でＳＩＰ−ａｗａｒｅアプリケーションへ伝送される、方法。
- 請求項４１記載の方法において、前記第１のアドレスはＩＰアドレスおよびポート番号を含む、方法。
- 請求項４１記載の方法において、ＳＩＰプロキシ・サーバは、前記外部アドレス領域内で、前記第１のアドレスをＳＩＰ−ａｗａｒｅアプリケーションへ伝送する場合に呼び出される、方法。
- 請求項４１記載の方法において、前記ＳＩＰメッセージはピア・ツー・ピア通信セッションを確立するよう用いられる、方法。
- 請求項４１記載の方法において、前記ＳＩＰメッセージはＩＰ電話通信セッションを確立するよう用いられる、方法。
- 請求項４１記載の方法において、前記ＳＩＰメッセージはインスタント・メッセージ・セッションを確立するよう用いられる、方法。
- 内部アドレス領域中において有効な内部アドレスを有する第１のアプリケーションと外部アドレス領域中における１又は複数のアプリケーションとの間のメッセージ・パケット通信を容易にする方法であって、該内部アドレス領域は該外部アドレス領域中における利用に有効なアドレスのセットに利用可能であり、該方法は、
ネットワーク・アドレス変換デバイスにおいて前記第１のアプリケーションからサービス要求を受け取るステップであって、前記ネットワーク・アドレス変換デバイスは、前記内部アドレス領域と外部アドレス領域との間のアドレス指定の対応をマッピングする少なくとも１つの変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセージ・パケットのヘッダに含まれるアドレスを変換するアドレス変換機構を有する、受け取るステップと、
前記ネットワーク・アドレス変換デバイスにより受け取られる前記第１のアプリケーションからの前記サービス要求に応答して、前記サービス要求が指定する変換規則を確立するステップであって、該サービス要求は発信メッセージのデータ部で用いるよう前記第１のアプリケーションの内部アドレスとペアになる外部アドレス領域アドレスを前記第１のアプリケーションに供給して、前記外部アドレス領域内のアプリケーションとの通信を開始、および前記外部アドレス領域内のアプリケーションからの着信メッセージを容易にする、確立するステップと、
を含む、方法。 - 請求項４９記載の方法において、前記サービス要求は前記ネットワーク・アドレス変換デバイスに、前記変換規則に含まれる前記外部アドレス領域アドレスを前記第１のアプリケーションへ伝達するよう命令することを含む、方法。
- 請求項４９記載の方法において、新しい変換規則用の仕様でサービス要求を受け取ることをさらに含む、方法。
- 請求項４９記載の方法において、変換規則の所望の特性でサービス要求を受け取ることをさらに含む、方法。
- 請求項５２記載の方法において、前記変換規則の前記所望の特性は指定されたＩＰアドレスの範囲を識別する、方法。
- 請求項５２記載の方法において、前記変換規則の前記所望の特性は特定の外部ＩＰアドレスを識別する、方法。
- 請求項４９記載の方法において、前記メッセージ・パケット通信はメディア・パケット通信である、方法。
- 請求項４９記載の方法において、前記メッセージ・パケット通信はディジタル化された音声パケット通信である、方法。
- 着信ソース・アドレスに応じて異なる変換されたアドレス値を有する変換規則を確立することをさらに含む、請求項４９記載の方法。
- 請求項４９記載の方法において、前記サービス要求を受け取るステップは、プロキシ・サーバから伝達された要求を受け取ることを含む、方法。
- 内部アドレス領域と外部アドレス領域との間のメッセージ・パケット通信を容易にする方法であって、
ネットワーク・アドレス変換デバイスにおいて前記内部アドレス領域において有効な内
部アドレスを有する第１のアプリケーションからサービス要求を受け取るステップであって、前記ネットワーク・アドレス変換デバイスは、前記内部アドレス領域と外部アドレス領域との間のアドレス指定の対応をマッピングする、少なくとも１つの変換規則に従って、前記内部アドレス領域へ入ってくる及び前記内部アドレス領域から出ていくメッセージ・パケットのヘッダに含まれるアドレスを変換するアドレス変換機構を有する、受け取るステップと、
前記第１のアプリケーションからの前記サービス要求に対して前記ネットワーク・アドレス変換デバイスにおいて変換規則を確立するステップであって、該変換規則は、発信メッセージ内で用いるよう外部アドレス領域中における利用に有効で、かつ前記第１のアプリケーションの内部アドレスとペアの外部アドレスを含み、前記外部アドレス領域中のアプリケーションからの着信メッセージを容易にする、確立するステップと、
発信メッセージ・パケットのデータ部に用いて前記外部アドレス領域のアプリケーションとの通信を開始するために、前記第１のアプリケーションへ前記外部アドレスを供給するステップと、
を含む、方法。 - 新しい変換規則の仕様でサービス要求を受け取ることをさらに含む、請求項５９に記載の方法。
- 変換規則の所望の特性でサービス要求を受け取ることをさらに含む、請求項５９に記載の方法。
- 請求項６１記載の方法において、前記変換規則の前記所望の特性は指定されたＩＰアドレスの範囲を識別する、方法。
- 請求項６１記載の方法において、前記変換規則の前記所望の特性は特定の外部ＩＰアドレスを識別する、方法。
- 請求項５９記載の方法において、前記メッセージ・パケット通信はメディア・パケット通信である、方法。
- 請求項５９記載の方法において、前記メッセージ・パケット通信はディジタル化された音声パケット通信である、方法。
- 請求項５９記載の方法において、前記ネットワーク・アドレス変換デバイスにおいて変換規則を確立するステップは、着信ソース・アドレスに応じて異なる変換されたアドレス値を有する変換規則を確立することを含む、方法。
- 請求項５９記載の方法において、前記ネットワーク・アドレス変換デバイスにおいてサービス要求を受け取るステップは、プロキシ・サーバから伝達された要求を受け取ることを含む、方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/661,070 US6661799B1 (en) | 2000-09-13 | 2000-09-13 | Method and apparatus for facilitating peer-to-peer application communication |
| US09/661,070 | 2000-09-13 | ||
| PCT/US2001/027382 WO2002023822A1 (en) | 2000-09-13 | 2001-09-04 | Method and apparatus for facilitating peer-to-peer application communication |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004509517A JP2004509517A (ja) | 2004-03-25 |
| JP2004509517A5 JP2004509517A5 (ja) | 2008-10-16 |
| JP4908724B2 true JP4908724B2 (ja) | 2012-04-04 |
Family
ID=24652085
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002527139A Expired - Lifetime JP4908724B2 (ja) | 2000-09-13 | 2001-09-04 | ピア・ツー・ピア・アプリケーション通信を容易にするための方法および装置 |
Country Status (7)
| Country | Link |
|---|---|
| US (3) | US6661799B1 (ja) |
| EP (3) | EP1323261B1 (ja) |
| JP (1) | JP4908724B2 (ja) |
| CN (2) | CN100512165C (ja) |
| AU (1) | AU2001287054A1 (ja) |
| DE (2) | DE60127276T2 (ja) |
| WO (1) | WO2002023822A1 (ja) |
Families Citing this family (114)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2800224B1 (fr) * | 1999-10-21 | 2002-12-27 | Ibm | Procede et systeme de mise en antememoire de donnees http transportees avec des donnees de socks dans des datagrammes ip |
| US7797433B2 (en) * | 2000-06-30 | 2010-09-14 | Net2Phone | System, method, and computer program product for resolving addressing in a network including a network address translator |
| US6661799B1 (en) | 2000-09-13 | 2003-12-09 | Alcatel Usa Sourcing, L.P. | Method and apparatus for facilitating peer-to-peer application communication |
| US6870841B1 (en) * | 2000-09-18 | 2005-03-22 | At&T Corp. | Controlled transmission across packet network |
| US7594030B2 (en) * | 2000-11-22 | 2009-09-22 | Microsoft Corporation | Locator and tracking service for peer to peer resources |
| US20020062336A1 (en) * | 2000-11-22 | 2002-05-23 | Dan Teodosiu | Resource coherency among resources cached in a peer to peer environment |
| US7072982B2 (en) * | 2000-11-22 | 2006-07-04 | Microsoft Corporation | Universal naming scheme for peer to peer resources |
| US20020085550A1 (en) * | 2000-12-28 | 2002-07-04 | Steven Rhodes | Scalable switch |
| US7054304B2 (en) * | 2001-01-19 | 2006-05-30 | Terited International , Inc. | Method and protocol for managing broadband IP services in a layer two broadcast network |
| US7293108B2 (en) * | 2001-03-15 | 2007-11-06 | Intel Corporation | Generic external proxy |
| US20020138552A1 (en) * | 2001-03-21 | 2002-09-26 | Debruine Timothy S. | Method and system for optimizing private network file transfers in a public peer-to-peer network |
| US6983319B1 (en) * | 2001-04-06 | 2006-01-03 | Permeo Technologies, Inc. | Dynamic port management |
| US7272650B2 (en) * | 2001-04-17 | 2007-09-18 | Intel Corporation | Communication protocols operable through network address translation (NAT) type devices |
| US20030041175A2 (en) * | 2001-05-03 | 2003-02-27 | Singhal Sandeep K | Method and System for Adapting Short-Range Wireless Access Points for Participation in a Coordinated Networked Environment |
| US7283526B2 (en) * | 2001-07-19 | 2007-10-16 | International Business Machines Corporation | Method and system for providing a symmetric key for more efficient session identification |
| EP1421766B1 (de) * | 2001-08-30 | 2015-10-21 | Unify GmbH & Co. KG | Vorabaushandlung von nat-adressen |
| US7228337B1 (en) * | 2001-09-11 | 2007-06-05 | Cisco Technology, Inc. | Methods and apparatus for providing a network service to a virtual machine |
| US7269663B2 (en) * | 2001-09-28 | 2007-09-11 | Intel Corporation | Tagging packets with a lookup key to facilitate usage of a unified packet forwarding cache |
| US8095668B2 (en) * | 2001-11-09 | 2012-01-10 | Rockstar Bidco Lp | Middlebox control |
| US7006436B1 (en) * | 2001-11-13 | 2006-02-28 | At&T Corp. | Method for providing voice-over-IP service |
| US7278157B2 (en) * | 2002-03-14 | 2007-10-02 | International Business Machines Corporation | Efficient transmission of IP data using multichannel SOCKS server proxy |
| KR100496734B1 (ko) * | 2002-05-02 | 2005-06-22 | 김철동 | 네트워크를 통한 이미지 전송 방법 |
| US7676579B2 (en) * | 2002-05-13 | 2010-03-09 | Sony Computer Entertainment America Inc. | Peer to peer network communication |
| US7243141B2 (en) | 2002-05-13 | 2007-07-10 | Sony Computer Entertainment America, Inc. | Network configuration evaluation |
| KR20030088253A (ko) * | 2002-05-14 | 2003-11-19 | (주)크라베르 | 피투피 기반의 원격지 컴퓨터 관리를 위한 연결요청중계시스템 및 그 방법 |
| US6801528B2 (en) * | 2002-07-03 | 2004-10-05 | Ericsson Inc. | System and method for dynamic simultaneous connection to multiple service providers |
| DE10230684A1 (de) * | 2002-07-08 | 2004-01-29 | Siemens Ag | Netzwerk mit in Kommunikationskomponenten integrierten Suchfunktionen |
| US7836205B2 (en) * | 2002-07-11 | 2010-11-16 | Hewlett-Packard Development Company, L.P. | Method and device for use with a virtual network |
| EP1383294A1 (de) * | 2002-07-16 | 2004-01-21 | Siemens Aktiengesellschaft | Verfahren zur Adressumsetzung in Paketnetzen und Steuerelement für Kommunikationsnetzwerke |
| US8224985B2 (en) * | 2005-10-04 | 2012-07-17 | Sony Computer Entertainment Inc. | Peer-to-peer communication traversing symmetric network address translators |
| DE10244710A1 (de) * | 2002-09-25 | 2004-04-08 | Siemens Ag | Verfahren zur Protokollauswahl für eine Übermittlung von Datennpaketen |
| TW200412101A (en) * | 2002-12-23 | 2004-07-01 | Shaw-Hwa Hwang | Directly peer-to peer transmission protocol between two virtual network |
| WO2004063843A2 (en) * | 2003-01-15 | 2004-07-29 | Matsushita Electric Industrial Co., Ltd. | PEER-TO-PEER (P2P) CONNECTION DESPITE NETWORK ADDRESS TRANSLATOR (NATs) AT BOTH ENDS |
| US7899932B2 (en) * | 2003-01-15 | 2011-03-01 | Panasonic Corporation | Relayed network address translator (NAT) traversal |
| JP4110977B2 (ja) * | 2003-01-21 | 2008-07-02 | 松下電器産業株式会社 | サーバ |
| KR100514196B1 (ko) * | 2003-02-14 | 2005-09-13 | 삼성전자주식회사 | 네트웍 어드레스 변환 및 세션 관리 시스템 및 그 방법 |
| DE10321227A1 (de) | 2003-05-12 | 2004-12-09 | Siemens Ag | Verfahren zum Datenaustausch zwischen Netzelementen |
| US7251745B2 (en) * | 2003-06-11 | 2007-07-31 | Availigent, Inc. | Transparent TCP connection failover |
| JP4115354B2 (ja) * | 2003-07-04 | 2008-07-09 | 富士フイルム株式会社 | ピア・ツー・ピア通信システム |
| EP3328021A1 (en) * | 2003-12-01 | 2018-05-30 | InterDigital Technology Corporation | Session initiation protocol (sip) based user initiated handoff |
| CN100454882C (zh) * | 2003-12-19 | 2009-01-21 | 华为技术有限公司 | 多isp局域网的出口选择方法及装置 |
| WO2005088466A1 (en) * | 2004-03-09 | 2005-09-22 | Clique Communications Llc | System and method for peer-to-peer connection of clients behind symmetric firewalls |
| US20060007912A1 (en) * | 2004-07-06 | 2006-01-12 | Heng-Chien Chen | Ip-based pbx system and connecting method thereof |
| US8990311B2 (en) * | 2004-07-27 | 2015-03-24 | International Business Machines Corporation | Enhanced instant message connectivity |
| US20060023727A1 (en) * | 2004-07-30 | 2006-02-02 | George David A | Method and apparatus for anonymous data transfers |
| US20060023646A1 (en) * | 2004-07-30 | 2006-02-02 | George David A | Method and apparatus for anonymous data transfers |
| US8542813B2 (en) * | 2004-11-02 | 2013-09-24 | Cisco Technology, Inc. | Method and system for providing a camp-on service in telecommunications |
| US20060104259A1 (en) * | 2004-11-15 | 2006-05-18 | Cisco Technology, Inc. | System and method for executing a multi-modal transfer in a session initiation protocol (SIP) environment |
| US7853696B2 (en) * | 2004-11-19 | 2010-12-14 | Cisco Technology, Inc. | System and method for providing an eCamp feature in a session initiation protocol (SIP) environment |
| US7639681B2 (en) * | 2004-11-23 | 2009-12-29 | Microsoft Corporation | System and method for a distributed server for peer-to-peer networks |
| US7656878B2 (en) * | 2004-12-03 | 2010-02-02 | Cisco Technology, Inc. | System and method for providing enhanced caller ID in a session initiation protocol (SIP) environment |
| US20060146790A1 (en) * | 2004-12-30 | 2006-07-06 | Cisco Technology, Inc. | System and method for providing reach me cover me feature in a session initiation protocol (SIP) environment |
| US8254552B2 (en) * | 2005-01-06 | 2012-08-28 | Cisco Technology, Inc. | System and method for providing a recovery mode in a session initiation protocol (SIP) environment |
| CN100426769C (zh) * | 2005-01-12 | 2008-10-15 | 腾讯科技（深圳）有限公司 | 一种建立对等直连通道的方法 |
| JP4708036B2 (ja) * | 2005-01-21 | 2011-06-22 | パナソニック株式会社 | 通信システム、情報処理装置、サーバ、及び情報処理方法 |
| US7778404B2 (en) * | 2005-01-27 | 2010-08-17 | Cisco Technology, Inc. | System and method for providing a dial plan conversion in a session initiation protocol (SIP) environment |
| US7899175B2 (en) * | 2005-01-27 | 2011-03-01 | Cisco Technology, Inc. | System and method for providing a dial plan conversion in a session initiation protocol (SIP) environment |
| US7912046B2 (en) * | 2005-02-11 | 2011-03-22 | Microsoft Corporation | Automated NAT traversal for peer-to-peer networks |
| US7853001B2 (en) * | 2005-04-08 | 2010-12-14 | Cisco Technology, Inc. | Method and system for providing a camp-on service |
| US7769156B2 (en) * | 2005-04-27 | 2010-08-03 | Cisco Technology, Inc. | System and method for providing a reverse camp-on feature in a communications environment |
| US7684434B2 (en) * | 2005-05-03 | 2010-03-23 | Cisco Technology, Inc. | System and method for providing a presence based Camp-On feature in a communications environment |
| KR100743055B1 (ko) | 2005-05-16 | 2007-07-26 | 주식회사 프리챌 | 방화벽 내 검색을 위한 ｐ２ｐ 검색 방법 및 ｐ２ｐ 검색시스템 |
| US7894597B2 (en) | 2005-10-12 | 2011-02-22 | Cisco Technology, Inc. | Categorization of telephone calls |
| WO2007048344A1 (fr) * | 2005-10-28 | 2007-05-03 | Huawei Technologies Co., Ltd. | Procede d’etablissement de la connexion poste a poste, procede, dispositif et systeme de realisation de nat de traversee de communication reseau |
| US8102985B2 (en) * | 2005-11-11 | 2012-01-24 | Cisco Technology, Inc. | Method and system for providing a camp-on hold service |
| EP1793564A1 (en) * | 2005-11-30 | 2007-06-06 | Thomson Telecom Belgium | Device and method to detect applications running on a local network for automatically performing the network address translation |
| US20070162552A1 (en) * | 2006-01-10 | 2007-07-12 | Cisco Technology, Inc. | Method and system for providing an instant messaging camp-on service |
| US20070189294A1 (en) * | 2006-01-28 | 2007-08-16 | Sadler Jonathan B | Methods and Apparatus for Signaling Between Independent Control Networks |
| US8280961B2 (en) * | 2006-02-09 | 2012-10-02 | Cisco Technology, Inc. | Method and system for providing a camp-on service for a network service |
| US20070189329A1 (en) * | 2006-02-14 | 2007-08-16 | Nokia Corporation | System for combining networks of different addressing schemes |
| US7596150B2 (en) * | 2006-02-27 | 2009-09-29 | Cisco Technology, Inc. | System and method for consolidating media signaling to facilitate internet protocol (IP) telephony |
| US7701971B2 (en) * | 2006-02-27 | 2010-04-20 | Cisco Technology, Inc. | System and method for providing a compatibility feature in a session initiation protocol (SIP) environment |
| US7729482B2 (en) * | 2006-02-27 | 2010-06-01 | Cisco Technology, Inc. | Method and system for providing communication protocol interoperability |
| US20070201459A1 (en) * | 2006-02-27 | 2007-08-30 | Cisco Technology, Inc. | System and method for providing status notification for conventional telephony devices in a session initiation protocol environment |
| US7778274B2 (en) * | 2006-02-27 | 2010-08-17 | Cisco Technology, Inc. | System and method for providing a compatibility feature in a session initiation protocol (SIP) environment |
| US7995559B2 (en) * | 2006-02-27 | 2011-08-09 | Cisco Technology, Inc. | System and method for interworking communication protocols to provide supplementary services |
| US7764669B2 (en) * | 2006-02-27 | 2010-07-27 | Cisco Technology, Inc. | System and method providing for interoperability of session initiation protocol (SIP) and H.323 for secure realtime transport protocol (SRTP) session establishment |
| US20070201367A1 (en) * | 2006-02-27 | 2007-08-30 | Cisco Technology, Inc. | System and method for interworking H.323 flow control with SIP |
| US9967129B1 (en) | 2006-03-09 | 2018-05-08 | Cisco Technology, Inc. | System and method for communicating call information in a sessions initiation protocol (SIP) environment |
| US20070226299A1 (en) * | 2006-03-24 | 2007-09-27 | Cisco Technology, Inc. | Method and system for providing an instant messaging quorum monitoring service |
| US8036360B1 (en) | 2006-04-28 | 2011-10-11 | Cisco Technology, Inc. | System and method for hook state notification |
| US8495231B1 (en) | 2006-05-16 | 2013-07-23 | Cisco Technology, Inc. | System and method for remote call control |
| US8015305B1 (en) | 2006-06-28 | 2011-09-06 | Cisco Technology, Inc. | System and method for implementing a session initiation protocol feature |
| CA2657094C (en) * | 2006-07-07 | 2018-05-01 | Fringland Ltd. | Identifying network entities in a peer-to-peer network |
| US8139566B2 (en) * | 2006-07-21 | 2012-03-20 | Cisco Technology, Inc. | System and method for establishing a communication session between two endpoints that do not both support secure media |
| US7769009B1 (en) * | 2006-12-11 | 2010-08-03 | Sprint Communications Company L.P. | Automatic peer to peer mobile device data replication |
| US10171889B2 (en) | 2006-12-21 | 2019-01-01 | Bce Inc. | Method and system for managing internal and external calls for a group of communication clients sharing a common customer identifier |
| US7995478B2 (en) | 2007-05-30 | 2011-08-09 | Sony Computer Entertainment Inc. | Network communication with path MTU size discovery |
| US7933273B2 (en) * | 2007-07-27 | 2011-04-26 | Sony Computer Entertainment Inc. | Cooperative NAT behavior discovery |
| US8112516B2 (en) * | 2007-08-23 | 2012-02-07 | Cisco Technology, Inc. | Selective user notification based on IP flow information |
| CN101127720B (zh) * | 2007-09-25 | 2010-09-01 | 中兴通讯股份有限公司 | 保证网络地址转换负载均衡内部本地地址可达的方法 |
| CN101132424B (zh) * | 2007-09-29 | 2011-08-31 | 杭州华三通信技术有限公司 | 网络地址转换的方法及装置 |
| EP2048847A1 (en) * | 2007-10-08 | 2009-04-15 | Nokia Siemens Networks Oy | Methods, apparatuses, system, and related computer program product for policy control |
| US7908393B2 (en) * | 2007-12-04 | 2011-03-15 | Sony Computer Entertainment Inc. | Network bandwidth detection, distribution and traffic prioritization |
| JP5222573B2 (ja) * | 2008-01-29 | 2013-06-26 | 株式会社日立製作所 | サーバ計算機及びネットワーク処理方法 |
| US7856506B2 (en) | 2008-03-05 | 2010-12-21 | Sony Computer Entertainment Inc. | Traversal of symmetric network address translator for multiple simultaneous connections |
| US8239550B2 (en) | 2008-05-14 | 2012-08-07 | Nokia Corporation | Methods, apparatuses, and computer program products for facilitating establishing a communications session |
| US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
| CN102137171A (zh) * | 2010-01-22 | 2011-07-27 | 正文科技股份有限公司 | 用于多媒体串流的网络地址转换方法、转换器及通信*** |
| WO2011141993A1 (ja) * | 2010-05-11 | 2011-11-17 | 株式会社チェプロ | 双方向通信システムおよびこれに用いるサーバ装置 |
| JP2012156957A (ja) * | 2011-01-28 | 2012-08-16 | Hitachi Ltd | ネットワークシステム、制御装置、計算機、及び、ネットワーク装置 |
| US9667713B2 (en) * | 2011-03-21 | 2017-05-30 | Apple Inc. | Apparatus and method for managing peer-to-peer connections between different service providers |
| US20130138813A1 (en) * | 2011-11-28 | 2013-05-30 | Microsoft Corporation | Role instance reachability in data center |
| WO2014001871A1 (en) * | 2012-06-27 | 2014-01-03 | Ciphergraph Networks Inc. | System and method for facilitating communication between multiple networks |
| US9621495B1 (en) * | 2012-12-10 | 2017-04-11 | Jeffrey Brian Shumate | Anonymous messaging proxy |
| US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
| WO2016000162A1 (zh) * | 2014-06-30 | 2016-01-07 | 华为技术有限公司 | 网页页面的推送方法、装置及终端 |
| US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
| EP4020940A1 (en) | 2017-08-28 | 2022-06-29 | Bright Data Ltd. | Content fetching by selecting tunnel devices |
| EP4053717A3 (en) | 2019-02-25 | 2022-10-26 | Bright Data Ltd. | System and method for url fetching retry mechanism |
| EP4027618A1 (en) | 2019-04-02 | 2022-07-13 | Bright Data Ltd. | Managing a non-direct url fetching service |
| US10986173B1 (en) * | 2019-04-25 | 2021-04-20 | Edjx, Inc. | Systems and methods for locating server nodes for edge devices using latency-based georouting |
| US11916995B1 (en) * | 2019-11-04 | 2024-02-27 | Edjx, Inc. | Systems and methods for locating microserver nodes in proximity to edge devices using georouting |
| US11089083B1 (en) * | 2019-11-04 | 2021-08-10 | Edjx, Inc. | Systems and methods for locating microserver nodes in proximity to edge devices using georouting |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1056482A (ja) * | 1996-08-12 | 1998-02-24 | Nippon Telegr & Teleph Corp <Ntt> | インタワーク装置 |
| JPH11150566A (ja) * | 1997-11-14 | 1999-06-02 | Hitachi Ltd | インタネットワーク装置 |
| JP2000059430A (ja) * | 1998-08-07 | 2000-02-25 | Matsushita Electric Works Ltd | ネットワークアドレス変換方法及びその装置 |
| JP2000138696A (ja) * | 1998-10-29 | 2000-05-16 | Mitsubishi Materials Corp | ネットワークアドレス変換装置およびその記録媒体 |
| JP2000209278A (ja) * | 1999-01-12 | 2000-07-28 | Fujitsu Ltd | ル―タ及びル―タを用いたパケット中継システム |
| JP2000224219A (ja) * | 1999-01-29 | 2000-08-11 | Internatl Business Mach Corp <Ibm> | 仮想プライベ―ト・ネットワ―クの動作方法およびシステム |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5227778A (en) | 1991-04-05 | 1993-07-13 | Digital Equipment Corporation | Service name to network address translation in communications network |
| US5793763A (en) | 1995-11-03 | 1998-08-11 | Cisco Technology, Inc. | Security system for network address translation systems |
| US5732078A (en) | 1996-01-16 | 1998-03-24 | Bell Communications Research, Inc. | On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network |
| US5781550A (en) * | 1996-02-02 | 1998-07-14 | Digital Equipment Corporation | Transparent and secure network gateway |
| CN1216657A (zh) * | 1996-04-24 | 1999-05-12 | 北方电讯有限公司 | 互联网协议过滤器 |
| US5883891A (en) | 1996-04-30 | 1999-03-16 | Williams; Wyatt | Method and apparatus for increased quality of voice transmission over the internet |
| JP3531367B2 (ja) * | 1996-07-04 | 2004-05-31 | 株式会社日立製作所 | トランスレータ |
| US6477179B1 (en) * | 1997-05-09 | 2002-11-05 | Sony Corporation | Data receiving device and data receiving method |
| US6094676A (en) | 1997-05-30 | 2000-07-25 | Hilgraeve Incorporated | Method and apparatus for peer-to-peer communication |
| US6141749A (en) | 1997-09-12 | 2000-10-31 | Lucent Technologies Inc. | Methods and apparatus for a computer network firewall with stateful packet filtering |
| JPH11122301A (ja) * | 1997-10-20 | 1999-04-30 | Fujitsu Ltd | アドレス変換接続装置 |
| US6047325A (en) | 1997-10-24 | 2000-04-04 | Jain; Lalit | Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks |
| DE69835353T2 (de) * | 1997-11-04 | 2007-07-05 | Koninklijke Philips Electronics N.V. | Übertragungsnetz mit erhöhter routingflexibilität |
| US6006272A (en) | 1998-02-23 | 1999-12-21 | Lucent Technologies Inc. | Method for network address translation |
| US6055236A (en) | 1998-03-05 | 2000-04-25 | 3Com Corporation | Method and system for locating network services with distributed network address translation |
| US6058431A (en) | 1998-04-23 | 2000-05-02 | Lucent Technologies Remote Access Business Unit | System and method for network address translation as an external service in the access server of a service provider |
| US6717949B1 (en) * | 1998-08-31 | 2004-04-06 | International Business Machines Corporation | System and method for IP network address translation using selective masquerade |
| US6141341A (en) | 1998-09-09 | 2000-10-31 | Motorola, Inc. | Voice over internet protocol telephone system and method |
| US6581108B1 (en) | 1999-11-30 | 2003-06-17 | Lucent Technologies Inc. | Managing multiple private data networks using network and payload address translation |
| US6779035B1 (en) | 2000-03-06 | 2004-08-17 | Microsoft Corporation | Application programming interface and generalized network address translator for translation of transport-layer sessions |
| US6772210B1 (en) * | 2000-07-05 | 2004-08-03 | Nortel Networks Limited | Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment |
| US6661799B1 (en) | 2000-09-13 | 2003-12-09 | Alcatel Usa Sourcing, L.P. | Method and apparatus for facilitating peer-to-peer application communication |
| US7224687B2 (en) | 2002-02-28 | 2007-05-29 | Lucent Technologies Inc. | Method and apparatus for voice over IP network address translation |
| FR2866497B1 (fr) | 2004-02-18 | 2006-08-18 | Cit Alcatel | Controleur de bande passante, reseau et procede de gestion de sous-reseau ip |
| EP1613024A1 (en) | 2004-06-29 | 2006-01-04 | Alcatel Alsthom Compagnie Generale D'electricite | Method and call server for establishing a bidirectional peer-to-peer communication link |
| FR2908001B1 (fr) | 2006-10-26 | 2009-04-10 | Alcatel Sa | Traversee d'un equipement de traduction d'adresse nat pour messages de signalisation conformes au protocole sip par redondance d'informations d'adresses. |
-
2000
- 2000-09-13 US US09/661,070 patent/US6661799B1/en not_active Ceased
-
2001
- 2001-09-04 EP EP01966550A patent/EP1323261B1/en not_active Expired - Lifetime
- 2001-09-04 WO PCT/US2001/027382 patent/WO2002023822A1/en active IP Right Grant
- 2001-09-04 EP EP07005187A patent/EP1793533B8/en not_active Expired - Lifetime
- 2001-09-04 JP JP2002527139A patent/JP4908724B2/ja not_active Expired - Lifetime
- 2001-09-04 CN CNB018175201A patent/CN100512165C/zh not_active Expired - Lifetime
- 2001-09-04 EP EP09003817.5A patent/EP2068499B1/en not_active Expired - Lifetime
- 2001-09-04 AU AU2001287054A patent/AU2001287054A1/en not_active Abandoned
- 2001-09-04 CN CN200910145424.6A patent/CN101668051B/zh not_active Expired - Lifetime
- 2001-09-04 DE DE60127276T patent/DE60127276T2/de not_active Expired - Lifetime
- 2001-09-04 DE DE60138058T patent/DE60138058D1/de not_active Expired - Lifetime
-
2005
- 2005-12-09 US US11/299,236 patent/USRE43057E1/en not_active Ceased
-
2011
- 2011-12-30 US US13/340,938 patent/USRE44593E1/en not_active Expired - Lifetime
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1056482A (ja) * | 1996-08-12 | 1998-02-24 | Nippon Telegr & Teleph Corp <Ntt> | インタワーク装置 |
| JPH11150566A (ja) * | 1997-11-14 | 1999-06-02 | Hitachi Ltd | インタネットワーク装置 |
| JP2000059430A (ja) * | 1998-08-07 | 2000-02-25 | Matsushita Electric Works Ltd | ネットワークアドレス変換方法及びその装置 |
| JP2000138696A (ja) * | 1998-10-29 | 2000-05-16 | Mitsubishi Materials Corp | ネットワークアドレス変換装置およびその記録媒体 |
| JP2000209278A (ja) * | 1999-01-12 | 2000-07-28 | Fujitsu Ltd | ル―タ及びル―タを用いたパケット中継システム |
| JP2000224219A (ja) * | 1999-01-29 | 2000-08-11 | Internatl Business Mach Corp <Ibm> | 仮想プライベ―ト・ネットワ―クの動作方法およびシステム |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1793533B1 (en) | 2009-03-18 |
| USRE43057E1 (en) | 2012-01-03 |
| EP1793533A1 (en) | 2007-06-06 |
| EP2068499A1 (en) | 2009-06-10 |
| WO2002023822A1 (en) | 2002-03-21 |
| USRE44593E1 (en) | 2013-11-12 |
| CN100512165C (zh) | 2009-07-08 |
| CN1531801A (zh) | 2004-09-22 |
| EP1793533B8 (en) | 2009-07-01 |
| EP1323261B1 (en) | 2007-03-14 |
| DE60127276D1 (de) | 2007-04-26 |
| JP2004509517A (ja) | 2004-03-25 |
| EP2068499B1 (en) | 2015-08-26 |
| DE60138058D1 (de) | 2009-04-30 |
| EP1323261A1 (en) | 2003-07-02 |
| CN101668051B (zh) | 2014-07-02 |
| US6661799B1 (en) | 2003-12-09 |
| DE60127276T2 (de) | 2007-12-20 |
| CN101668051A (zh) | 2010-03-10 |
| EP1323261A4 (en) | 2005-02-23 |
| AU2001287054A1 (en) | 2002-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4908724B2 (ja) | ピア・ツー・ピア・アプリケーション通信を容易にするための方法および装置 | |
| US8489751B2 (en) | Middlebox control | |
| US6360265B1 (en) | Arrangement of delivering internet protocol datagrams for multimedia services to the same server | |
| JP4349766B2 (ja) | アドレス変換装置 | |
| US6822957B1 (en) | Distributed network address translation for a network telephony system | |
| US7577144B2 (en) | Dynamic network address translation system and method of transparent private network device | |
| US20020085561A1 (en) | Method and system for supporting global IP telephony system | |
| US20070076729A1 (en) | Peer-to-peer communication traversing symmetric network address translators | |
| US6879593B1 (en) | Connections of nodes on different networks | |
| US7224696B2 (en) | Access nodes in packet-based communications networks | |
| US7411917B1 (en) | Method and system for providing registration-based SIP NAT traversal | |
| US8224995B2 (en) | Method and system for providing an accurate address of a device on a network | |
| US7499448B2 (en) | Method for data exchange between network elements in networks with different address ranges | |
| Chen et al. | Design of SIP application level gateway for IPv6 translation | |
| JP3928664B2 (ja) | アドレス変換装置、メッセージ処理方法および装置 | |
| KR20030057095A (ko) | 게이트키퍼와 ｎａｔ－ｐｔ 연동을 위한 서로 상이한ｉｐ 주소 연동 방법 | |
| JP2003046530A (ja) | アドレス空間の異なるｉｐネットワーク間の通信方法およびグローバルｉｐアドレスを持つ装置 | |
| JP4350029B2 (ja) | アドレス変換システム | |
| JP3928663B2 (ja) | アドレス変換装置、メッセージ処理方法および装置 | |
| JP5904965B2 (ja) | 通信装置及び通信システム | |
| KR20040066333A (ko) | 복합 네트워크에서의 디엔에스(ｄｎｓ) 메시지 처리 시스템 | |
| Mellouk et al. | A new methodology to adapt SIP Protocol for voice traffic transported over IP Network | |
| De Marco et al. | SIP-H323: a solution for interworking saving existing architecture |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080826 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080826 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110322 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110330 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110628 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110705 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110801 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110808 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110830 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110906 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110930 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111215 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150120 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4908724 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |