(57)【要約】【課題】単一擬似ステートフルTCP接続を用いてデータをトンネリングする方法及び機器。【解決手段】パケットベースのマルチメディア通信標準規格と関連付けられたデータをトンネリングするための方法及びシステムを提供する。この方法は、修正されたTCP/IPスタック内のマルチメディア通信標準規格と関連付けられたライブラリ呼び出しを傍受し、ライブラリ呼び出しと関連付けられた識別データを登録することを含む。識別データに関係したデータパケットの予め存在しているヘッダの上に修正されたTCP/IPヘッダがアペンドされる。この方法はまた、TCP/IPヘッダを有するデータパケットをファイアウォールを介して通信できる。TCP/IPヘッダはステートフル接続を提供するためにTCP SEQ番号及びTCP ACK番号を含む。【選択図】図３
2006166426.tif 000002
【特許請求の範囲】
【請求項１】
パケットベースのマルチメディア通信標準規格と関連付けられたデータをトンネリングするための方法であって、
マルチメディア通信標準規格と関連付けられたライブラリ呼び出しを傍受し、
ライブラリ呼び出しと関連付けられた識別データを登録し、
識別データに関係したデータパケットの予め存在しているヘッドの上にTCP/IPヘッダを付け加え、
TCP/IPヘッダを有するデータパケットをファイアウォールを介して送信する操作を含み、
TCP/IPヘッダはTCP SEQ番号及びTCP ACK番号を含む、方法。
【請求項２】
ライブラリ呼び出しと関連付けられた識別データを登録する方法操作は、
ポート番号及びプロトコルタイプがテーブルに定義されているかチェックし、
ポート番号及びプロトコルタイプがテーブルに定義されていなければ、
ポート番号及びプロトコルタイプをテーブルに追加する操作を含む、
請求項１に記載の方法。
【請求項３】
識別データはデータパケットと関連付けられたポート番号及びプロトコルタイプを含む、請求項１に記載の方法。
【請求項４】
識別データに関係したデータパケットの予め存在しているヘッドの上にTCP/IPヘッダを付け加える方法操作は、
識別している事前定義の値をTCP/IPヘッダのウィンドウサイズフィールドの上位バイトに挿入し、
チェックサムをTCP/IPヘッダのウィンドウサイズフィールドの下位バイトに挿入し、
TCP SEQ番号を挿入し、
TCP ACK番号を挿入する操作を含み、
TCP SEQ番号の初期割当ての後に、送信されたデータの量に従ってTCP SEQ番号及びTCP ACK番号が決定される、
請求項１に記載の方法。
【請求項５】
ポート番号はポート８０で、プロトコルタイプはTCPである、請求項２に記載の方法。
【請求項６】
ライブラリ呼び出しと関連付けられた識別データを登録する方法操作は、ライブラリ呼び出しと関連付けられたデータをパケットベースのマルチメディア通信標準規格のプロトコルスタックのアプリケーションレベルからドライバレベルに進める前に行なわる、請求項１に記載の方法。
【請求項７】
単一のHTTPポートを介してポートトラフィックを通信するための方法であって、
a）第１及び第２コンピューティングデバイス間の接続を確立し、
b）ポートトラフィックと関連付けられた割当てデータをトンネリングドライバに送信し、
c)ポートトラフィックをデータグラムにセグメント化し、
d）データグラムの一つずつに第１ヘッダをアペンドし、
e）第１ヘッダの上にTCP/IPヘッダをアペンドする方法操作を含み、
TCP/IPヘッダはTCP SEQ番号及びTCP ACK番号を含み、データグラムの一つずつを単一HTTPポートに方向付けるように構成されている、方法。
【請求項８】
接続はステートフルTCP接続で、単一HTTPポートはポート８０である、請求項７に記載の方法。
【請求項９】
割当てデータを送信する方法操作は、
ポートトラフィックと関連付けられたポート番号及びプロトコルタイプを定義することを含む、請求項７に記載の方法。
【請求項１０】
第１及び第２コンピューティングデバイス間の接続の確立は、TCPプロトコルに従ってSYNハンドシェイクシーケンス及びSYN+ACKハンドシェイクシーケンスによって開始される、請求項７に記載の方法。
【請求項１１】
第１ヘッダの上にTCP/IPヘッダをアペンドする方法操作は、
TCP/IPヘッダのウィンドウサイズフィールドの上位バイトにフラグを挿入し、
TCP/IPヘッダのウィンドウサイズフィールドの下位バイトにチェックサムを挿入し、
TCP SEQ番号を挿入し、
TCP ACK番号を挿入することを含み、
初期TCP SEQ番号に続いて、TCP SEQ番号及びTCP ACK番号がTCPプロトコルに従って決定される、請求項７に記載の方法。
【請求項１２】
パケットベースのマルチメディア通信標準規格と関連付けられたデータをトンネリングするためのプログラム命令を有するコンピュータ判読可能な媒体であって、
マルチメディア通信標準規格と関連付けられたライブラリ呼び出しを傍受するためのプログラム命令と、
ライブラリ呼び出しと関連付けられた識別データを登録するためのプログラム命令と、
識別データに関係したデータパケットの予め存在しているヘッダの上にTCP/IPヘッダを付け加えるためのプログラム命令と、
TCP/IPヘッダを有するデータパケットをファイアウォールを介して通信するためのプログラム命令とを含み、
TCP/IPヘッダは擬似ステートフルTCP/IPヘッダで、TCP SEQ番号及びTCP ACK番号を含む、コンピュータ判読可能な媒体。
【請求項１３】
ライブラリ呼び出しと関連付けられた識別データを登録するプログラム命令は、
ポート番号及びプロトコルタイプがテーブルに定義されているかチェックするためのプログラム命令と、
ポート番号及びプロトコルタイプをテーブルに追加するためのプログラム命令とを含む。
【請求項１４】
識別データはデータパケットと関連付けられたポート番号及びプロトコルタイプを含む、請求項１２に記載のコンピュータ判読可能な媒体。
【請求項１５】
識別データに関係したデータパケットの予め存在しているヘッダの上にTTCP/IPヘッダを付け加えるプログラム命令は、
TCP/IPヘッダのウィンドウサイズフィールドの上位バイトに識別値フラグを挿入するためのプログラム命令と、
TCP/IPヘッダのウィンドウサイズフィールドの下位バイトにチェックサムを挿入するためのプログラム命令と、
TCP/IPヘッダにTCP SEQ番号を挿入するためのプログラム命令と、
TCP/IPヘッダにTCP ACK番号を挿入するためのプログラム命令とを含み、
初期TCP SEQ番号割当て後に、TCP/IPプロトコルに従ってTCP SEQ番号及びTCP ACK番号が決められる、請求項１２に記載のコンピュータ判読可能な媒体。
【請求項１６】
ポート番号はポート８０で、プロトコルタイプはTCPである、請求項１３に記載のコンピュータ判読可能な媒体。
【請求項１７】
ライブラリ呼び出しと関連付けられた識別データを登録するための命令プログラムは、ライブラリ呼び出しと関連付けられたデータをパケットベースのマルチメディア通信標準規格のプロトコルスタックのアプリケーションレベルからドライバレベルに進める前に完了する、請求項１２に記載のコンピュータ判読可能な媒体。
【請求項１８】
単一のHTTPポートを介してポートトラフィックを通信するためのプログラム命令を有するコンピュータ判読可能な媒体であって、
a）第１及び第２コンピューティングデバイス間の接続を確立するためのプログラム命令と、
b）ポートトラフィックと関連付けられた割当てデータをトンネリングドライバに送信するためのプログラム命令と、
c）ポートトラフィックをデータグラムにセグメント化するためのプログラム命令と、
d）データグラムの一つずつに第１ヘッダをアペンドするためのプログラム命令と、
e）第１ヘッダの上にTCP/IPヘッダをアペンドするためのプログラム命令とを含み、TCP/IPヘッダはTCP SEQ番号及びTCP ACK番号を有する擬似ステートフルTCP/IPヘッダで、データグラムの一つずつを単一のHTTPポートに方向付けるように構成されている、コンピュータ判読可能な媒体。
【請求項１９】
接続はTCP接続で、ポート番号はポート８０である、請求項１８に記載のコンピュータ判読可能な媒体。
【請求項２０】
割当てデータを送信するためのプログラム命令は、
ポートトラフィックと関連付けられたポート番号及びプロトコルタイプを定義するためのプログラム命令を含む、請求項１８に記載のコンピュータ判読可能な媒体。
【請求項２１】
第１ヘッダはTCPヘッダ及びUDPヘッダのうちの一つである、請求項１８に記載のコンピュータ判読可能な媒体。
【請求項２２】
第１ヘッダの上にTCP/IPヘッダをアペンドするためのプログラム命令は、
TCP/IPヘッダのウィンドウサイズフィールドの上位バイトに事前定義の識別値を挿入するためのプログラム命令と、
TCP/IPヘッダのウィンドウサイズフィールドの下位バイトにチェックサムを挿入するためのプログラム命令と、
TCP SEQ番号及びTCP ACK番号を決めるためのプログラム命令とを含み、初期TCP SEQ番号はランダムに割り当てられ、後続のTCP SEQ番号とTCP ACK番号とはTCPプロトコルに従って決められる、請求項１８に記載のコンピュータ判読可能な媒体。
【請求項２３】
複数のポートに宛てられたポートトラフィックを単一ポートを介してトンネリングするためのシステムであって、
パケットヘッダとは別にさらに各々トンネリングヘッダを有するデータパケットを送信するように構成されたサーバと、
ブロックされていないTCPポートの数を限定するファイアウォールとを含み、ファイアウォールはトンネリングヘッダを分析する機能を有し、トンネリングヘッダはファイアウォールがデータパケットを通すように単一のポートと関連付けられており、さらに、
単一ポートを介してファイアウォールからデータパケットを受け取るように構成されたクライアントを含み、クライアントはさらにパケットヘッダにアクセスできるようにトンネリングヘッダを取り除くためにトンネリングヘッダと関連付けられたフラグ及びチェックサムを識別するように構成され、
トンネリングヘッダはTCP SEQ番号及びTCP ACK番号を有してステートフルである、システム。
【請求項２４】
フラグ及びチェックサムはトンネリングヘッダのウィンドウサイズフィールドに組み込れる、請求項２３に記載のシステム。
【請求項２５】
パケットヘッダはUDPヘッダである、請求項２３に記載のシステム。
【請求項２６】
単一ポートはHTTPポート８０である、請求項２３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはインターネットでの情報の送信に関し、より具体的にはインターネットでの及びネットワーク及びネットワーク型システム内での情報の高速なリアルタイム送信のための方法、システム、及び機器に関する発明である。
【背景技術】
【０００２】
多くのインターネットベースのアプリケーションは、有効なインプリメンテーションを得るためにリアルタイムのデータの送信及び交換を必要とする。例として、H.323インターネットビデオ会議は、ローカル及び遠隔設定で参加者に映像及び音声データを提示するために高速なリアルタイムのデータ交換を提供する。典型的には、必要なリアルタイムのデータ交換のメリットを実現するために、データは信頼性のないUser Datagram Protocol/Internet Protocol（UDP/IP、または単にUDP）で送信される。信頼性のあるTransmission Control Protocol（TCP、またはTCP/IP）に優先して信頼性のないUDPを使用するメリットは主としてスピードである。UDPは、パケットの受信確認、パケットの検証、パケットの再送信要求などを送信しないから、オーバーヘッドが少ない。リアルタイムのメディア送信及びプレイバックでは、そうした送信及び検証のプロセスはシステムの性能に好ましくない影響を与える。
【０００３】
TCPは、基本的に、ほとんどのインターネットでのデータ通信の標準規格となっている。TCPは、全てのデータが受信され、正しい順序で受信され、受信したデータは正確で送信したデータと一致していることを確認することで最高度の信頼性を保つ。多くのアプリケーションにおいて、そうした信頼性は有効なデータ送信に一番重要なことである。しかし、スピードが一番重要となるH.323インターネットビデオ会議などのアプリケーションには、最高度の信頼性は必要ではない。ほとんどのビデオ会議アプリケーションは、普通は気付かない、時折届かなかった音声データを簡単に補償することができるし、同様に、ビデオデータが時折届かなかったり化けた部分があっても普通は耐えられるし、ビデオ会議に妨害になることはほとんどない。
【０００４】
図１は、ファイアウォールを使わずに情報を交換するコンピュータの簡易概略図である。コンピュータ１００及び１０２は、ハンドシェイク信号１０４をやりとりした後、TCP接続を確立する。例えば、H.323などビデオ会議の標準規格に関して言えば、音声及び映像データの通信のために複数のUDPポート番号が確立される。コンピュータ１００及び１０２の各々には、音声及び映像の制御／データ信号用に少なくとも４つのUDPポート、０１８‐１から１０８‐４及び１１０‐１から１１０‐４が開かれる。ポート１０８nと１１０nで示したように、コンピュータ１００及び１０２の各々について普通は４つ以上のポートが開かれる。
【０００５】
しかし、オフィスや家庭のネットワークはファイアウォール環境の内側に保護されている場合が多い。概して知られているように、ファイアウォールは、ブロックされていないポートの数を限定することでネットワークから望まないInternet Protocol（IP）トラフィックを中に入れないように設計されている。これは、ビデオ会議の標準規格は多数のTCP及びUDPポートがブロックされていないことが必要なので、ビデオ会議の標準規格には問題となる。図２は、ファイアウォールを介して通信している２つのコンピュータの簡易概略図である。図２に示すように、コンピュータ１００はファイアウォール１１２の背後にあり、コンピュータ１０２はネットワーク１１４でファイアウォールと通信する。上に述べたように、ファイアウォール１１２はUDP接続には欠かせない複数のポートが開いている状態を許可しない。さらに、ファイアウォール１１２はブロックされていないポートを限定するので、ファイアウォールは、その全てがビデオ会議アプリケーションに使用される可能性のあるUDPポート番号１０２４〜６５，５３８といったUDPポートをどれも認識しない。
【０００６】
高速なリアルタイム送信が望ましい時に、ファイアウォールは望ましいビデオ会議の機能を限定又は妨げることがあり、またそうすることが多い。ある特定のファイアウォールがTCP/IP以外の入ってくる全てのインターネットトラフィックをブロック又は拒否する場合には、ビデオ会議又はその他のデータ交換を信頼性は高いけれども速度がはるかに遅いTCP/IPを用いて行なうか、何らかの形で問題点を克服してUDPデータ送信及び交換を行なければならない。この問題点を解決する一つのやり方は、データ用のTCP/IP接続を使用することである。しかし、TCP接続は、肯定応答、検証、及び届かなかったパケットの再送信要求の送信が原因で、つまり、TCP接続の信頼性特性に起因して、質の悪いビデオになる。
【０００７】
【特許文献１】米国特許第2001/0032270号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記に鑑み、必要なのは、音声及び映像データの送信、又はシステムアドミニストレータの管理負担に及ぼす影響を最小に抑えて、既存のファイアウォールを介してビデオ会議データを通信できる方法及びシステムである。
【課題を解決するための手段】
【０００９】
おおまかに言えば、本発明は、ブロックされていないデータ送信用ポートの数を限定するように構成されたファイアウォールを通れるように、データを単一HTTPポートを介してトンネリングするための方法、システム、及び通信プロトコルを提供することでこうしたニーズに応えるものである。本発明の実施例は、特定のファイアウォールがトンネリングされたTCPパケットを誤解して放棄する可能性が少ない明らかにステートフルなTCP接続を提供する。本発明は、システムとして、方法として、或いはコンピュータ判読可能な媒体としてなど、いろいろなやり方で実施可能である。本発明のいくつかの実施例を以下に説明する。
【００１０】
一つの実施例において、パケットベースのマルチメディア通信標準規格と関連付けられたデータをトンネリングするための方法を提供する。この方法は、マルチメディア通信標準規格と関連付けられたライブラリ呼び出しを傍受し、ライブラリ呼び出しと関連付けられた識別データを登録することを含む。この方法はさらに、識別データに関係したデータパケットの予め存在しているヘッダの上にTCP/IPヘッダを追加することにも対応している。この方法は次に、TCP/IPヘッダを有するデータパケットをファイアウォールを介して送信することを含む。TCP/IPヘッダは、TCP SEQ番号及びTCP ACK番号を含む。
【００１１】
別の実施例において、単一のHTTPポートを介してポートトラフィックを通信するための方法を提供する。この方法は、第１及び第２コンピューティングデバイス間の接続を確立し、ポートトラフィックと関連付けられた割当てデータをトンネリングドライバに送信し、データグラムの一つずつに第１ヘッダをアペンドし、その第１ヘッダの上にTCP/IPをアペンドすることを含む、一連の操作を提供する。TCP/IPヘッダは、TCP SEQ番号とTCP ACK番号を含み、データグラムの一つずつを単一のHTTPポートに向かわせるように構成されている。
【００１２】
更に別の実施例において、パケットベースのマルチメディア通信標準規格と関連付けられたデータをトンネリングするためのプログラム命令を有するコンピュータ判読可能な媒体を提供する。このコンピュータ判読可能な媒体は、マルチメディア通信標準規格と関連付けられたライブラリ呼び出しを傍受するためのプログラム命令と、そのライブラリ呼び出しと関連付けられた識別データを登録するためのプログラム命令を含む。識別データに関係したデータパケットの予め存在しているヘッダの上にTCP/IPヘッダを追加するためのプログラム命令と、TCP/IPヘッダを有するデータパケットをファイアウォールを介して送信するためのプログラム命令も提供している。TCP/IPヘッダは擬似（simulated）ステートフルTCP/IPヘッダで、TCP SEQ番号及びTCP ACK番号を含む。
【００１３】
また別の実施例において、単一のHTTPポートを介してポートトラフィックを通信するためのプログラム命令を有するコンピュータ判読可能なメディアを提供する。このコンピュータ判読可能なメディアは、第１及び第２コンピューティングデバイス間の接続を確立するためのプログラム命令を含む。コンピュータ判読可能なメディアはさらに、ポートトラフィックと関連付けられた割当てデータをトンネリングドライバに送信するためのプログラム命令と、ポートトラフィックをデータグラムにセグメント化するためのプログラム命令を含む。さらに、コンピュータ判読可能なメディアは、データグラムの一つずつに第１ヘッダをアペンドするためのプログラム命令と、その第１ヘッダの上にTCP/IPヘッダをアペンドするためのプログラム命令を含む。TCP/IPヘッダは、TCP SEQ番号及びTCP ACK番号を含む擬似ステートフルTCP/IPヘッダで、データグラムの一つずつを単一のHTTPポートに向かわせるように構成される。
【００１４】
さらにまた別の実施例において、複数のポートに宛てられたポートトラフィックを単一ポートを介してトンネリングするためのシステムを提供する。このシステムは、パケットヘッダとは別にさらにトンネリングヘッダをそれぞれ有するデータパケットを送信するように構成されたサーバと、ブロックされていないTCPポートの数を限定するファイアウォールを含む。このファイアウォールはトンネリングヘッダを分析する機能を有する。トンネリングヘッダはファイアウォールがデータパケットを通過させるように単一ポートと関連付けられている。さらに、システムは単一ポートを介してファイアウォールからデータパケットを受け取るように構成されたクライアントを含む。クライアントはさらに、パケットヘッダにアクセスできるようにトンネリングヘッダを取り除くために、トンネリングヘッダと関連付けられたフラグ及びチェックサムを識別するように構成される。トンネリングヘッダはステートフルで、TCP SEQ番号及びTCP ACK番号を有する。
【００１５】
発明の効果は、発明の原理を例を挙げて説明している図面と共に、以下に述べる詳細な説明から明白になる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施形態を図面に基づいて説明する。
【実施例１】
【００１７】
ファイアウォールを通れるように単一「ステートフル」TCPポートを介して複数のTCP/UDPポートへのデータをトンネリングするための方法及びシステムに関する発明を提供する。以下の説明において、本発明を完全に理解できるように、多くの具体的な詳細を述べる。しかし、当業者ならば、これらの具体的な詳細を部分的に或いは全く知らなくても本発明を実施できるだろうことを理解するだろう。他の場合には、本発明を不要に曖昧にしないために、よく知られたプロセスの操作については詳細に説明していない。図１及び２については、「背景技術」の項に説明がある。
【００１８】
関連出願である米国特許出願番号10/681,523の中で、ファイアウォール環境で送信できるように、単一トンネリングTCP接続を確立し、複数のTCP及びUDP接続をその単一トンネリングTCP接続に方向付ける発明を説明している。本発明の実施例は、前の「ステートレス」TCP接続に基づいて構築し、ある特定のファイアウォールがトンネリングされたTCPパケットを”out of state”と誤解して放棄する可能性が少ない擬似「ステートフル」TCP接続を提供する。ここで使用しているように、「ステートフル」TCP接続という表現は正しいTCP接続状態に従うトンネリングパケットを意味する。「ステートフル」は、２つのホスト間の初期ハンドシェイク（SYN、SYN+ACK、及びACK）と、PSH+ACKまたはACKフラグセットを有する正しいSeq #及びACK #値を有するデータパケットの転送と、正しいSeq #及びACK #を有する接続解除メッセージの交換とからなる。関連出願番号10/681,732で説明した無接続TCPデータ交換では、データ交換を開始するホストからのパケットは全てSYNフラグセットを有し、遠隔ホストからのパケットは全てSYN+ACKフラグセットを有する。Seq #及びACK #値は、存在する場合には、セッション中ずっと同じままである。
【００１９】
セキュリティの心配があるので、ファイアウォールはインターネットアクセスを有するほとんどのシステム及びネットワークの不可欠な構成要素であり、データを保護しシステム保全を維持するための価値あるツールである。しかし、セキュリティを高めるとデータ交換のスピードに影響を及ぼす。ファイアウォールはどれでも好ましいレベルのセキュリティを確立して維持するための独特の方法を有しているが、ファイアウォールはTCP/IP送信以外の全ての送信へのアクセスを拒絶またはブロックするか、UDPデータ交換に特定のポートまたは一連のポートだけを指定するのが普通である。それでも他のファイアウォールはステートフルTCP接続を必要とし、さもなければ”out of state”であるとして、もっとひどい場合にはウィルスの襲撃と誤解されて、パケットが放棄されてしまう。
【００２０】
ここで説明する実施例は、単一のHTTPポートを介して、例えば、H.323、SIPといったマルチメディア電話会議の標準規格、または適切なパケットベースの標準規格と関連付けられたデータをトンネリングするためのスキームを提供する。別のH.323クライアント、つまりオフィスまたはホームネットワークからH.323会議サーバに接続しているH.323アプリケーションの最も一般的な問題の一つは、ほとんどのサイトがファイアウォールで保護されていることである。ファイアウォールは、あるネットワークから不要なIPトラフィックを締め出すように設計されている。しかし、H.323プロトコルは、正しく機能するには多数のTCP及びUDPポートがブロックされていないことが必要である（例えば、１０２４〜６５５３８の全てのUDPポートがブロックされていない状態でなければならない）。それほど多くのポートを開くと、ローカルネットワークのセキュリティを危険にさらす。
【００２１】
一つの解決法は、H.323プロトコルを使える特別なファイアウォールをインストールすることである。残念ながら、この種のファイアウォールを有するサイトは多くないし、そうした専用ファイアウォールは実用的な解決法とはならない。これに対して、（全部ではないとしても）ほとんどのファイアウォールは汎用ウェブブラウジング用のHTTPポートを開かない。HTTPポートは、事実上、ポート８０でのTCP接続である。全てのTCP及びUDP接続をポート８０での単一TCP接続にトンネリングするようにH.323アプリケーションを構成できる場合には、そのアプリケーションは、パケットをもともとファイアウォールの外で送信されたデータに変換するように同じように構成された別のH.323アプリケーションと通信可能である。
【００２２】
プロキシソケットライブラリ呼び出しとオペレーティングシステム（OS）のTCP/IPスタックに挿入されるカーネルモードデバイスドライバとを組合せることによって、既存のマルチメディア電話会議アプリケーションは最小のコード修正で済む。以下に説明するように、トンネリングドライバはTCP/IPドライバとネットワークインタフェースカード（NIC）ドライバとの間に挟まれている。したがって、以下に説明するIPデータグラム変換は両ドライバから見えない。そのために、TCP/IPドライバとNICドライバはあたかも両者の間に別のドライバがないかのように機能する。
【００２３】
図３は、発明の一つの実施例による、信頼性のない接続能力及び信頼性のある接続能力の両方を提供するために、無接続送信制御プロトコルスキームとの統合が可能な修正アプリケーションモジュールスタックを含むシステムの簡易概略図である。クライアント１２０はファイアウォール１２４の裏側にある。サーバ１２８はネットワーク１２６及びファイアウォール１２４を介してクライアント１２０と通信する。例えば、H.323アプリケーションなど、マルチメディア電話会議アプリケーションでは、少なくとも２つのタイプの接続がなければならない。すなわち、呼び出しセットアップと呼び出し制御データには信頼性のある接続が必要なのに対し、データのスループットが極めて重要な音声及び映像のようなマルチメディアデータを送信するには信頼性のない接続が必要である。しかし、無接続TCP接続で信頼性のある接続を提供するために、パケットの再送信、パケットの並べ替え、パケットの受信通知のメカニズムの大部分はTCP/IPスタックで実施される。TCP/IPスタックは現代のオペレーティングシステム、つまり、MICROSOFT WINDOWS（登録商標）, LINUXなどのほとんどで標準として含まれている。したがって、修正したプロトコルスタック１２２は、電話会議アプリケーションにとって信頼性のある接続と信頼性のない接続とが可能な通信を提供することができる。図４A及び４Bに関してより詳細に説明するように、修正アプリケーションスタックは、アプリケーション１２２aと、ダイアミックリンクライブラリ（dll）１２２b、その他のライブラリ及びドライバ１２２c、及びトンネリングドライバ１２２dを含む。言うまでもなく、モジュールスタック１２２は、ネットワークカードなどハードウェアの上にある。
【００２４】
ビデオ会議アプリケーションがTCPまたはUDP接続を行なうとき、ポートで実際にデータを送信する前にプロトコル及びポート番号がトンネリングドライバに送られる。本発明の実施例によれば、以下により詳細に説明するように、マスタトンネリングTCP接続が確立される。
【００２５】
図４Aは、標準規格H.323アプリケーションモジュールのモジュールスタックを図示している簡易概略図である。モジュールスタック１３０はH.323アプリケーション１３０aを含み。H.323アプリケーション１３０aはWinsock32.dll（１３０b）より上にある。概して知られているように、Winsock32.dllはダイナミックリンクライブラリで、小型プログラムの集まりであって、そのどれでもコンピュータでランしている大型プログラムが必要とする際に呼び出すことができる。H.323アプリケーション１３０a及びWinsock32.dll（１３０b）はアプリケーションレベルまたはユーザモード１３２にある。ドライバレベルとも呼ばれるカーネルモード１３４では、TCP/IPドライバモジュール１３０cがネットワークインタフェースカード（NIC）ドライバモジュール１３０dの上にある。ハードウェアレベル１３６にあるのはネットワークカード１３０eである。
【００２６】
図４Bは、発明の一つの実施例による、ポートトンネリングアプリケーションモジュールスタックを図示している簡易概略図である。このポートトンネリングアプリケーションモジュールスタックは、以下に説明するように、アプリケーションレベルの余分のモジュールとドライバレベルの余分のドライバを含む。図４Bに示すように、アプリケーションモジュール１２２aは、任意の適したマルチメディア電話会議アプリケーションで構わないが、Winsockproxy.dll（１２２b）の上にある。アプリケーションモジュール１２２aはWinsockproxy.dll（１２２b）とリンクしている。アプリケーションモジュール１２２aが、例えば、bind()、connect()、closesocket()など標準的なソケットライブラリ呼び出しを行なうと、アプリケーションモジュールが割り当てるポート番号及びプロトコルタイプを登録／登録解除するために、Winsockproxy.dll（１２２b）は呼び出しを傍受し、IPパケットトンネリングドライバ１２２dと通信する。したがって、アプリケーションレベルからWinsock32.dllモジュール１３０bを介してドライバレベルに通信データを送るよりも前に、Winsockproxy.dllモジュール１２２bはトンネリングドライバ１２２dと通信する。その通信データはWinsockproxy.dll（１２２b）からWinsock32.dll（１３０b）に渡され、最終的にドライバレベル、つまりカーネルモード１３４に渡され、そこでTCP/IPドライバ１３０cが最初にそのデータを受け取る。TCP/IPドライバは次にデータを、図６A及び６Bに示すように、データグラムとも呼ばれるしかるべきサイズのパケット、またはセグメントに分ける。さらに、TCP/IPドライバはソケットタイプいかんによりしかるべきメディアアクセスコントロール（MAC）、IP、TCP（又はUDP）のヘッダをデータグラムにアペンドする。TCP/IPドライバ１３０cはパケットをIPパケットトンネリングドライバ１２２dに渡す。パケットトンネリングドライバ１２２dはTCP/IPポートをチェックし、ポートが登録済みポート番号及びプロトコルタイプのリストに載っているか判定する。
【００２７】
Winsockproxy.dllモジュール１２２bからトンネリングドライバ１２２dへのその時点より前の通信がポート番号及びプロトコルタイプを登録すると理解するべきである。ポート番号及びプロトコルタイプがリストに載っていれば、図６Bにおいて図示されているように、トンネリングドライバ１２２dがデータグラムに４０バイトのトンネリングIP+TCPヘッダを挿入する。さらに、トンネリングドライバ１２２dはデータグラムの宛先IPをチェックする。宛先IPがファイアウォールIPマッピングテーブルに載っている場合には、トンネリングドライバ１２２dがトンネリングIP+TCPヘッダの中の宛先IP及びポート番号をファイアウォールIP及びファイアウォールポートで置き換える。その後、NICドライバ１３０dに送る前に、データグラムのチェックサムを算定しなおす。その後、データはNICドライバ１３０dからハードウェアレベル１３６のネットワークカード１３０eに送られる。
【００２８】
H.323アプリケーション１２２aは、セッションを終えると、アプリケーション１２２aがセッション中に開いた各TCP又はUDPソケットのclosesocket()関数を呼び出す。Winsockproxy.dllライブラリ１２２bがこのclosesocket()関数呼び出しを傍受し、その情報をトンネリングドライバ１２２dに渡す。トンネリングドライバ１２２dは削除するポートに印を付ける。次に、トンネリングドライバ１２２dはそのポート宛てのFIN+ACK及びACKパケットをモニタする。タイムアウト時間（一つの実施例では２０秒）が過ぎると、トンネリングドライバ１２２dは対応するポート及びプロトコル情報をテーブルから除去し、必要ならばファイアウォールIP及びファイアウォールポートマッピングもクリーンアップする。
【００２９】
図５は、典型的なH.323 TCP/IP接続シーケンスを図示している簡易概略図である。この例で、H.323アプリケーションはTCPポート７２０で接続待ちしている[listening]別のH.323アプリケーションにTCP/IP接続を行なう。例えば、クライアントA（１４０）が送信１４４を介してクライアントB（１４２）にポート１７２０へのTCP接続を要求する。呼び出しセットアップ及び呼び出し制御の送信１４４及び１４６が信頼性のある接続で進行する。次に、モジュール１５０によって示したように、後続のデータ交換で、制御データ及びメディアデータの送信のために両方のアプリケーションがさらに多くのTCP及びUDPポートを開くことがある。したがって、図４Aについて言えば、H.323アプリケーションがオープンソケット（TCPかUDPかどちらか）にデータを書き込み、Winsock32.dllモジュールがこのデータをTCP/IPドライバに渡す。
【００３０】
図６Aは、入ってくるデータのブロック１５２の標準アプリケーションモジュールスタックを介してのセグメンテーションを図示したものである。この例で、入ってくるデータのブロック１５２はブロック１５２aから１５２cによって表わしたデータのセグメントに分割される。分かるように、標準アプリケーションモジュールスタックは入ってくるデータのブロック１５２をWinsock32.dllを介してTCP/IPドライバ１３０cに渡し、TCP/IPドライバ１３０cがデータをセグメント化する。さらに、データの各セグメント１５２a、１５２b、１５２cにヘッダを追加する。したがって、図示しているように、データのセグメント１５２bはTCP（又はUDP）ヘッド１５４、IPヘッダ１５６、及びMACヘッダ１５８を含む。
【００３１】
図６Bは、発明の一つの実施例による、修正アプリケーションモジュールスタックがファイアウォールを介してデータをトンネリングできるようにするためのセグメンテーション及びヘッダの追加を図示している。入ってくるデータのブロック１５２はデータセグメント１５２aから１５２cにセグメント化される。図６Aに関して上に説明したように、データセグメント１５２a、１５２b、１５２cの各々にはヘッダが追加されている。その後、IPパケットトンネリングドライバ１２２は、ヘッダが有する各データセグメント１５２a、１５２b、１５２cにトンネリングヘッダを追加する。図示しているように、データセグメント１５２bは、TCP（又はUDP）ヘッダ１５２、IPヘッダ１５６、及びトンネリングIP+TCPヘッダ１６０を含み、トンネリングIP+TCPヘッダ１６０はMACヘッダ１５８とIPヘッダ１５６との間に挿入されている。一つの実施例において、トンネリングヘッダ１６０は、例えば、ポート番号８０といった特定のハイパーテキストトランスファプロトコル（HTTP）ポート番号、又はテルネット用の２３などその他の公知のポートを示す４０バイトのヘッダである。
【００３２】
複数のTCP及びUDP接続ストリームを一つのストリームに方向付けるためのステートフルTCP接続を生成するには、図７に関して以下により詳細に説明するように、TCP接続はSYN, SYN+ACK, ACKのハンドシェイクシーケンスによってスタートさせる必要がある。トンネリングTCP接続を用いる後続のデータ送信は、正しいIP ID、TCP SEQ番号、ACK番号、及び初期設定ハンドシェイクで使用したTCPフラグフィールドを有するTCP/IPヘッダ内にデータがカプセル化されることを必要とする。フィールドを図８に関して図示し、以下により詳細に説明する。さらに、H.323セッションを終え、トンネリングTCP接続を閉じるとき、接続を正しく閉じるにはFIN+ACK及びACKパケットを他の関係者に送信する必要がある。
【００３３】
正規のTCP接続を模擬するには、２つのホスト間に接続を確立しなければならない。必要な接続を確立する一つの方法は、特定のユニークなパケットハンドシェイクメカニズムを生成することである。しかし、本発明の実施例はホスト間に正規のTCP接続を生成することが可能である。図７は、ホストA（１６６）及びホストB（１６８）間の典型的なTCP接続で使用したハンドシェイクシーケンス及び接続状態の概略図１６５である。本発明の実施例によれば、SEQ及びACKフィールド（図８参照）はTCP/IPドライバ１３０cによってランダムに初期値が割り当てられ、それからステートフル接続をシミュレートするためにインクリメント及びトラッキングされる。以下により詳細に説明するように、TCP接続を確立するために、図示しているように通常のTCPプロトコルがホストA（１６６）及びホストB（１６８）間のSYN（１７０）、SYN+ACK（１７２）、及びACK（１７４）のハンドシェイクを呼び出す。初期SEQ値をX及びYで示しており、初期ACK値は０である。TCPプロトコルに従って、表示しているようにSYN及びACK値が増分する。
【００３４】
一つの実施例において、安定し且つ途切れることのない映像及び音声データのストリームを維持するために、ビデオ会議の音声及び映像データを含んでいるような、UDPデータグラムが可能な限り高速で送信及び処理される。したがって、本発明の一つの実施例において、UDPデータグラムは、図７の１７６及び１７８によって示すように、PSH+ACKパケットとしてパッケージ化及び処理される。ステートフルなTCP接続を維持するために、PSH+ACKパケットはしかるべく増分されたSEQ及びACK値を含む。
【００３５】
発明の一つの実施例において、ステートフルTCP接続は標準TCPプロトコルに従って閉じられる。図７に示すように、最後のハンドシェイクシーケンスはFIN+ACK（１８０）、ACK（１８２）、FIN+ACK（１８４）、ACK（１８６）を含む。図７に示すように、SEQ値は変数M及びNに設定されており、セッションの進行中に到着した値を表わしている。変数M及びNはセッションを閉じるためにTCPプロトコルに従ってしかるべく増分される。
【００３６】
ステートフルなトンネリングTCP接続の目的は、単一の正規のTCP接続と同じ状態遷移を模擬することである。本発明の実施例で実施したアプローチは、H.323TCP及びUDPデータがネットワークで送られる前にクライアント及びサーバ間のマスタトンネリングTCP接続を生成することを含む。一つの実施例において、状態情報（例えば、フラグ、ID、SEQ番号、ACK番号など）が、マスタトンネリングTCP接続のセットアップ中に記録される。H.323アプリケーションがデータをTCP又はUDPポートを介して送り始めると、トンネリングドライバが、「正規の」TCP接続の動作を正確に模擬するように設定されたフィールドを有するトンネリングTCPヘッダをアペンドする。アプリケーションがH.323セッションを終えると、このセッションに関係した他のTCP又はUDP接続を全て閉じた後、WinSockProxy.dllがマスタトンネリングTCP接続を閉じる。トンネリングドライバがマスタトンネリングTCP接続からFIN+ACKパケットを受け取ると、ドライバは、パケットがファイアウォールを通って接続の向こう側にいるホストに到着するように、SEQ番号及びACK番号のフィールドを修正する。接続の向こう側にいるホストはFIN+ACKパケットを受け取ると、TCP/IPスタックドライバに渡す前にSEQ番号及びACK番号をもともとの値に修正しなおす。
【００３７】
発明の一つの実施例において、WinSockProxy.dll（１２２b）（図４B、６B参照）はH.323アプリケーションが接続されているピアIPアドレスを記録しておく。H.323アプリケーションが遠隔ホストにTCP接続しようとすると、WinSockProxy.dllはこの遠隔ホストにすでに確立されたマスタ接続があるか判定する。そうならば、この遠隔ホストの接続カウントがインクリメントされる。そうでなければ、意図するTCP接続が確立される前に遠隔ホストへのマスタトンネリングTCP接続が生成され、接続カウントが１に設定される。本明細書で使用しているように、接続カウントとは同じ遠隔ホストIPアドレス宛先を有するTCP接続数である。一つの実施例において、以下に詳細に説明するように、接続カウントは、例えば、接続カウントがゼロになるときなど、いつマスタトンネリングTCP接続を閉じるかを判定するためにWinSockProxy.dllによって使用される。本発明の実施例はTCPポート４８２４を特別なマスタトンネリングポートとして使用しているが、しかるべきどんなポートでもそのように使用できることを理解するべきである。
【００３８】
図８は、本発明の一つの実施例による無接続TCPヘッダ１８８の簡易概略図である。無接続TCPヘッダ１８８は正規のTCPヘッダに類似しているが、ウィンドウサイズフィールドが修正されている。ウィンドウサイズフィールドは上位バイトセクション１９０と下位バイトセクション１９２に細分されている。発明の一つの実施例において、事前に定義された値がウィンドウサイズフィールドの上位バイト１９０に書き込まれ、チェックサムが下位バイト１９２に書き込まれる。事前に定義された値及びチェックサムはデータグラムを無接続TCP/IPデータグラムとして識別している。すなわち、ウィンドウサイズフィールドの上位バイト１９０に書き込まれた事前定義の値はデータグラムを無接続TCP/IP送信として識別して、データグラムと標準TCP/IP送信を区別している。ウィンドウサイズフィールドの上位バイト１９０の中の事前定義の値とは別にさらに、ウィンドウサイズフィールドの下位バイト１９２は、データグラムが無接続TCP/IPデータグラムであることを検証及び確認する特殊なチェックサムを含んでいる。一つの実施例において、ウィンドウサイズフィールドの上位バイト１９０の事前定義の値が受信パケットを無接続TCP/IPデータグラムとして識別し、無接続TCP/IPヘッダのウィンドウサイズフィールドの下位バイト１９２のチェックサムがその識別をバリデートしている場合には、そのデータグラムは無接続TCP/IP送信として取り扱われ、処理される。
【００３９】
本発明の実施例はさらに、図７に関して上に説明したTCPプロトコルに従ってステートフルTCP接続を生成するために状態フィールド１９４を用いる。無接続TCPヘッダの一般的な構成については、引用により組み込まれている米国特許出願番号10/681,732にさらに詳細な説明がある。
【００４０】
一つの実施例では、トンネリングTCP接続の状態を記録しておくために、トンネリングドライバがトンネリング接続ごとに接続状態エントリを生成する。例として、トンネリングドライバは宛先ポート番号４８２４のTCP/IPスタックからTCPパケットを受け取る。発明の一つの実施例において、ポート４８２４はマスタトンネリングポート番号である。TCPパケットがSYNに設定されたTCPフラグを有し、TCPパケットがその接続状態テーブルに未だ存在していないIPアドレスを含んでいる場合には、トンネリングドライバはアプリケーションがトンネリング接続を行なうつもりであると仮定する。トンネリングドライバはその接続テーブルに接続状態エントリを生成し、遠隔IPアドレスと、遠隔ポート番号、ローカルポート番号、初期SEQ番号、及びTCP状態フラグを記録する。それから、トンネリングドライバは（アペンドする代わりに）宛先ポート番号を８０（HTTPポート）に変更し、チェックサム法を用いてTCP Windowサイズの下位バイト１９２を更新し、パケットチェックサムを算定しなおす。Windowサイズの上位バイト１９０は、上に述べたように、パケットをトンネリングパケットとして識別している事前定義の値を含んでいることに注目するべきである。ステートフル接続を維持するために、本発明の実施例はファイアウォールの両側で実行／スライディングウィンドウサイズをトラッキングする。したがって、ウィンドウサイズフィールドの上位バイト１９０の中の事前定義の値はウィンドウサイズの制約条件に対応できるだけの大きさでなければならない。言い換えれば、スライディングウィンドウサイズが接続間で隔たりがありすぎる状態になっていることをファイアウォールが検出した場合には、ファイアウォールはウィンドウサイズに最後のACK番号を足したものを超えるシーケンス番号を有するTCPパケットをストップ／拒絶する。十分に大きな上位バイト１９０ウィンドウサイズフィールドにある事前定義の識別値が十分に大きければ、ファイアウォール上に十分大きなスライディングウィンドウを確保できる。
【００４１】
典型的なTCP接続の初期化の際に、TCP/IPドライバ１３０c（図４A参照）はあるポート番号（例えば、４８２４）をもつTCPパケットを生成し、それをネットワークで宛先ホストに送る。宛先ホストにあるTCP/IPドライバ１３０cはこのTCPパケットを受け取る。TCPヘッダの中のポート番号（例えば、４８２４）から、TCP/IPドライバ１３０cはどのソケット／アプリケーションがパケットをディスパッチするか、或いはどのローカルソケットが接続できるように初期化を開始するかを知る。しかし、ポート８０宛て以外のTCPパケットトラフィックを全てブロックするファイアウォールを用いると、パケットがファイアウォールを通れるように、トンネリングドライバ１２２d（図４B参照）はもともとのTCPパケットのポート番号を（例えば、４８２４から）ポート番号８０に変更しなければならない。宛先ホストがトンネリングTCP SYKパケット（例えば、図７の１７０）を受け取ると、宛先ホストにあるトンネリングドライバ１２２dはポート番号をポート番号８０からもともとのポート番号に（例えば、ポート番号４８２４に）戻さなければならない。トンネリングドライバ１２２dがポート番号をもともとのポート番号に戻そうとしないで、その代わりに単純にTCP/IPドライバ１３０cに変換後のポート番号（ポート８０）をもつTCPパケットを渡そうとした場合には、TCP/IPドライバ１３０cはパケットを間違ったアプリケーション／ソケットにディスパッチするか、パケットをディスパッチする先のアプリケーション／ソケットを見出さないか、どちらかである。いずれの場合も、もともとのTCPポート番号（例えば、４８２４）を接続待ちしているアプリケーション／ソケットはパケットを決して受け取らないので、正しく初期化しない。
【００４２】
本発明の一つの実施例では、トンネリングドライバ１２２d（図４B参照）がTCP FlagがSYNに設定されたトンネリングTCPパケットをネットワークから受け取り、しかもこの遠隔IPには状態エントリがないときには、ドライバは接続テーブルに接続状態エントリを生成する。ドライバはSYNパケットからのSEQ番号を遠隔ホストからの初期ACK番号として記録する。ドライバはまた、この遠隔IPの今のトンネリング接続状態をSYN状態に設定し、エントリに遠隔ポート番号を記録し、宛先ポート番号をポート８０（HTTPポート）からポート４８２４、つまりマスタトンネリングポート番号にリセットする。ドライバはそれから、上位レイヤーにあるTCP/IPスタックにパケットを渡す前に、パケットチェックサムを算定しなおす。
【００４３】
発明の一つの実施例では、トンネリングドライバがTCP FlagがSYN+ACKに設定されたTCPパケットを受け取り、しかもその遠隔IPアドレスにはすでに接続状態エントリがあり、さらに状態がSYNになっているときには、トンネリングドライバは記録されている初期SEQ番号を受信パケットからのSEQ番号に更新し、状態をSYN+ACKに設定する。次に、宛先ポート番号がポート８０に設定され、TCP Windowサイズフィールドの下位バイト１９２（図８参照）がしかるべきチェックサムによって修正され、パケットチェックサムが算定しなおされる。
【００４４】
発明の一つの実施例では、トンネリングドライバがTCP FlagがSYN+ACKに設定されたTunneling TCPパケットを受け取り、しかもその遠隔IPアドレスにはすでに接続状態エントリがあり、さらに接続がSYN状態になっているときには、ドライバは初期ACK番号の接続状態をパケットのSEQ番号に更新する。ドライバはまた、遠隔IPの今のトンネリング接続状態をSYN+ACK状態に更新し、ソースポート番号をポート８０（HTTPポート）からポート４８２４、つまりマスタトンネリングポート番号にリセットする。ドライバはそれから、上位レイヤーのTCP/IPスタックにパケットを渡す前に、パケットチェックサムを算定しなおす。
【００４５】
一つの実施例では、トンネリングドライバがACK FlagをもつTCPパケット又はトンネリングTCPパケットをTCP/IPスタック又はネットワークから受け取ると、ドライバはその遠隔IPの接続状態エントリの状態及びデータに従ってTCPヘッダを修正する。
【００４６】
TCP/IPスタックドライバ又はネットワークから正規のTCP及びUDPデータがトンネリングドライバに到着すると、ドライバはTCP FlagがPSH+ACKに設定されているトンネリングTCPヘッダをアペンド（除去）し、その遠隔IPの接続状態エントリの値に従ってSEQ番号及びACK番号を更新する。パケットの送信及び受信ごとに、トンネリングドライバは新たなトンネリングパケットに使用するために一番新しいSEQ番号及びACK番号を更新する。
【００４７】
マスタトンネリングTCP接続を閉じるプロセス時に、トンネリングドライバはTCP/IPスタックドライバからマスタトンネリングTCP接続用（ポート４８２４用）のFIN+ACK TCPパケットを受け取る。接続確立してからSEQ番号及びACK番号は実施されているから、ドライバはその遠隔IPアドレスの接続状態エントリの一番新しいSEQ番号及びACK番号を用いてSEQ番号及びACK番号を入れ替える。今では、そのパケットはファイアウォールを通り抜ける。しかし、これらのパケットをTCP/IPスタックドライバに渡す前に、SEQ番号及びACK番号をそのもともとの値に変換しなす必要がある。そうするのに、トンネリングドライバは、FIN+ACKパケットのFIN+ACKパケット及び後続のACKパケットのSEQ番号及びACK番号を正しいインプリメントによって初期SEQ番号及びACK番号に修正する。
【００４８】
多数の信頼性のないUDP接続を単一のTCP接続に方向付ける際、TCPは依然としてそのデータスループットを規制する。信頼性のないUDP接続環境で、アプリケーションはアプリケーション又はネットワークがハンドルできる限りの高速でデータを送る。しかし、信頼性のあるTCP接続環境では、TCP/IPスタックドライバがスライディングウィンドウを保持し、スライディングウィンドウがACKパケットをピア側で受け取らなければならなくなる前にデータをどれだけ受け取り、どれだけこのホストに送信できるかをそのピアに教える。今のSEQ番号と受け取ったACK番号との差が所定数を超えると、TCP/IPスタックドライバは新たなデータの今回のパケット送信動作を中止し、遠隔ピア側からのACK番号が遅れを取り戻すまで前に送ったデータを再送信する。一旦ACK番号が追いついたら、新たなデータの送信を再開する。
【００４９】
UDP接続の性能を達成するために、本発明の実施例によるトンネリングTCP接続はピアがACK番号カウントに遅れてもパケットの送信を一時停止することはできない。しかし、一方の側からのSEQ番号とACK番号との差がWindowサイズを超えると、ファイアウォールは最後のACK番号＋Windowサイズを超えるSEQ番号をもつトンネリングTCPパケットを全て放棄するのが普通である。パケットが放棄されるとその結果、有意義な映像及び音声の品質の低下になる。Windowサイズを基本的に任意の望ましい値に設定できるにしても、Windowサイズは上限が６４キロバイトである。アプリケーションが音声及び映像データを送信しているとき、６４K値を超えるのは簡単である。
【００５０】
本発明の一つの実施例では、信頼性のないUDP接続の性能を維持しながらWindowサイズの問題を克服するために、トンネリングドライバは、遠隔ピアからのACK番号が遅れている場合には、送信者側でSEQ番号をインクリメントするのを一時停止する。ドライバは遠隔ピアから受け取ったACK番号をモニタする。接続状態エントリのACK番号と今のSEQ番号との差が事前定義の値（６４キロバイト以下の値）に達すると、送信者は新たなデータパケットのパケットサイズに応じたSEQ番号のインクリメントを行なわない。したがって、ファイアウォールはパケットは紛失パケットの再送信パケットであると考えてブロックしない。最終的に、遠隔ピアからのACK番号が遅れを取り戻したら（ギャップが事前定義の値以下になったら）、送信者は新たなトンネリングパケット上のSEQ番号のインクリメントを再開する。
【００５１】
なお、本発明では、H.323セッションが完了すると判定するためには少なくとも２つのアプローチが可能である。一つの実施例では、H.323アプリケーションが特別なAPI関数を呼び出してH.323セッションが終了したことをWinSockProxy.dllに知らせるので、ライブラリはクリーンアップを開始できる。別の実施例では、WinSockProxy.dllがH.323セッションの存続期間中に確立されたTCP接続数の数を覚えている（TCP接続カウント作業）。カウント数が０からXになり、それからまた０に戻った場合には、WinSockProxy.dllがアプリケーションはセッションを終えてマスタトンネリングTCP接続を閉じると判定する。本発明の好適な実施例は、アプリケーションがH.323セッションを終えると判定するためにTCP接続数カウント法を実施する。
【００５２】
H.323セッションの存続期間中、多くのTCP及びUDPセッションが開かれ閉じられる。典型的なUDP接続はステートレスで、ある特定の遠隔IPに結びついているわけではないので、トラッキングするのは難しい。その一方で、接続後のTCP接続はある特定の遠隔IPに結びついている。したがって、TCP接続が結びついている遠隔セッションを識別するのはより簡単である。H.323アプリケーションは先ず最初に遠隔ホストに接続を行なう時点で、その特定のIPアドレスには接続エントリがない。それがこの遠隔ホストへの最初の接続であることをWinSockProxy.dllが識別する。マスタトンネリングTCP接続が生成され、続いて正規のTCP接続が生成される。H.323セッション中、この遠隔ホストへのTCP接続がもっと多く生成される。マスタトンネリングTCP接続がすでに存在しているから、新たなTCP接続はマスタトンネリングTCP接続に方向付けられる。この遠隔ホスト用のTCP接続が全て閉じられると、アプリケーションは今のH.323セッションが終わったのでそれ以上マスタトンネリングTCP接続は必要ないと考える。この時点で、WinSockProxy.dllはマスタトンネリング接続のクリーンアップを開始する。
【００５３】
発明の一つの実施例においては、WinSockProxy.dllがマスタトンネリングTCP接続を閉じると、トンネリングドライバが直ちに接続状態エントリをクリアすることはできない。FIN+ACK又はACKパケットが失われ、再送信しなければならない可能性があることが可能である。しかし、一旦接続状態エントリが接続状態テーブルから削除されてしまうと、トンネリングドライバはそれ以上これらのパケットを認識しない。その結果、これらのパケットはファイアウォールを通るように修正されずに放棄される。したがって、発明の一つの実施例では、WinSockProxy.dllがマスタトンネリングTCP接続を閉じると、対応する接続状態エントリには削除するように印を付けられる。エントリの実際の削除は事前に定義されたタイムアウト後に起きる。
【００５４】
典型的なH.323のシナリオは、状況によっては、両クライアントが互いにデータを送信し合う、つまり、データパケットを交換することを含むけれども、一方のピアは送るデータの量が他方よりも大きい。例えば、あるホストがセッション用の音声及び映像の選択を解除するか、オフにしているかの場合には、音声及び映像をオンにしている関係者から送信されるトンネリングデータが有意に多い。こうした状況では、他のホストがAcknowledgement番号を送るチャンスが十分にないことがある。発明の一つの実施例では、トンネリングドライバがこうした状況を検出して特別なトンネリング肯定応答パケットを生成する。この特別なトンネリング肯定応答パケットには、ウィンドウサイズの事前に定義された定数フィールド（図８の１９０参照）を除いて、データは入っておらず、有しているのはトンネリングTCPパケットのあらゆる属性である。一つの実施例において、パケットをトンネリングTCPパケットとして識別していると説明した事前定義の値とは違う別個の、もしくは異なる事前定義の値をウィンドウサイズフィールドの上位バイト１９０に提供する。別の実施例では、特別なトンネリング肯定応答パケットがトンネリングTCPパケットとして識別されると共に特別な肯定応答パケットとしても識別される。このようにして、受信しているトンネリングドライバが特別なパケットを簡単に識別して、そうしたパケットを放棄する。
【００５５】
本発明のまた別の実施例において、Multiple Conferencing Unit Server（MCU Server）として知られる特別なタイプのH.323アプリケーションを実施する。MCU Serverは入ってくる複数のH.323接続に対応できる。次に、入ってくるデータの全てが処理されミックスされて、各クライアントに返信するために結合データストリームが生成される。MCU Serverのインプリメンテーションにおいて、トンネリングシステムは、処理するためのトンネリングTCPストリームと、通常の処理のための「正規の」又は「その他の」H.323接続ストリームとを認識し区別する必要がある。
【００５６】
MCU Serverインプリメンテーションの一つの実施例において、H.323接続セットアップポート（１７２０）はWinSockProxy.dll及びトンネリングドライバにおいて特別なポートとして識別される。TCPパケットがトンネリングドライバに入り、１７２０と設定された宛先ポートを有していると、トンネリングドライバはそのクライアントの遠隔IPを特別なテーブルに追加する。この遠隔IP宛ての後続のTCP及びUDPパケットはトンネリングドライバによって処理されない。これらのパケットはネットワークドライバ又は修正されていないTCP/IPスタックドライバに渡される。
【００５７】
図９〜１２は、本発明の実施例に従って、擬似ステートフルトンネリングTCP接続を確立するときの、擬似ステートフルトンネリングTCP接続を用いてパケット交換を行なうときの、そして擬似ステートフルトンネリングを終了するときの、データの流れを示す論理フロー図である。
【００５８】
図９は、本発明の実施例によるマスタトンネリング接続の確立を示すデータフロー論理図２５０である。上に説明したように、２つのホスト間で接続が確立され（例えば、図３及び５参照）、図９に、H.323 ApplicationからNICカード２６０までの一方のホストのデータの流れを図示している。擬似ステートフルトンネリングTCP接続を提供する接続を確立する際、どちらにしても、図示したデータフローに従うのは基本的に接続を開始する側のホストであることを理解するべきである。図９に示すデータフローはマスタトンネリング接続の確立を表わしており、一方のホストの側でのH.323アプリケーション２５２と、Winsockproxy.dll（２５４）と、TCP/IPスタック２５６と、トンネリングドライバ２５８と、NICカード２６０との間のデータフローを含む。上述の図３、４A、４Bは識別されたデータポイントを図で説明したものである。図９は、マスタトンネリングTCP接続が確立されている間に生じるイベントを強調したものである。TCPポート１７２０の接続がWinsockproxy.dll（２５４）をトリッガしてTCPポート４８２４のマスタトンネリング接続を生成する。次に、TCPポート４８２４接続の結果生じたTCPパケットがトンネリングドライバ２５８によって処理される（つまり、トンネリングされる）。
【００５９】
図１０は、本発明の実施例によるマスタトンネリング接続の確立をさらに説明するデータフロー論理図２６５である。図１０に、一方のホストのTCP/IPスタック２６６と他方のホストのTCP/IPスタック２７４との間のデータフローを示している。すなわち、本発明の実施例による、第１のホストのTCP/IPスタック２６６から、第１のホストのトンネリングドライバ／ネットワーク２６８、ファイアウォール２７０、第２のホストのトンネリングドライバ／ネットワーク２７２、そして第２のホストのTCP/IPスタック２７４に至るまでのマスタトンネリング接続を確立する際のデータフロー、及び後続のパケット交換を示している。さらに、図１０は、マスタトンネル接続プロセス中２７６、マスタトンネル接続の成立２７８、H.323アプリケーション接続プロセス中２８０、H.323アプリケーション接続の成立２８２、H.323データの送受信２８４を含む時間点又はイベント点でのデータフローを表示している。図１２は、複数のTCP及びUDPポートからの「正規の」（つまり、トンネリングでない）H.323データがマスタトンネリングTCP接続を通る／トンネリングされるときに、どのようにSEQ番号及びACK番号が変わるか又は更新されるかを強調した図である。
【００６０】
図１１は、本発明の実施例によるマスタトンネリング接続の終了を図示しているデータフロー論理図２８５である。図９に関して上に説明したように、一方のホストのH.323アプリケーション２８６からNICカード２９４までのデータフローを説明している。確立している接続を終了する際、どちらにしても基本的に接続の終了を開始する側のホストが図示しているデータフローに従うことを理解するべきである。図１１に示したデータフローはマスタトンネリング接続の終了を表わし、一方のホストの側のH.323アプリケーション２８６と、Winsockproxy.dll（２８８）と、TCP/IPスタック２９０と、トンネリングドライバ２９２と、NICカード２９４との間のデータフローを含む。図９に関して上に説明したように、上述の図３、４A、４Bは識別されたデータポイントを図で説明したものである。
【００６１】
最後に、図１２は、本発明の実施例によるマスタトンネリング接続の終了をさらに示すデータフロー論理図２９５である。図１２に、一方のホストのTCP/IPスタック２９６と他方のホストのTCP/IPスタック３０４との間のデータフローを示している。すなわち、本発明の実施例による、第１のホストのTCP/IPスタック２９６から、第１のホストのトンネリングドライバ／ネットワーク２９８、ファイアウォール３００、第２のホストのトンネリングドライバ／ネットワーク３０２、そして第２のホストのTCP/IPスタック３０４までのマスタトンネリング接続を終了する際のデータフロー、及び最終のパケット交換を示している。図１２は、一つの実施例による、第２又は最終ホストの終了時のマスタトンネリング接続の終了を図示している。上の図１０と同様に、さらに、最終H.323接続解除プロセス中３０６、最終H.323接続解除の成立３０８、マスタトンネリング接続解除プロセス中３１０、マスタトンネリング接続解除の成立でそれ以上のパケット交換なし３１２を含む時間点又はイベント点でのデータフローを表示している。なお、図１２は、アプリケーションスタックのいろいろなレイヤーを通るとき、FIN+ACK及びACKパケットのSEQ番号及びACK番号が修正されることを示している。FIN+ACK及びACKパケットはもともとTCPポート４８２４用のパケットであり、接続が確立してからインプリメントされていないことを思い出すべきである。しかし、H.323データ送信によってTCPポート４８２４接続のSEQ番号及びACK番号がファイアウォール上では異なる値になっている。これらのFIN+ACK及びACKパケットをファイアウォールを通すには、トンネリングドライバはネットワークに送る前にこれらのパケットのSEQ番号及びACK番号を修正する必要がある。しかし、受信側では、実際にTCPポート４８２４接続を通ったデータはないから、もともとのTCP接続は異なる値を有するFIN+ACK及びACKパケットを待っている。そのために、トンネリングドライバは、受け取った後でTCP/IPドライバに渡す前に、これらのFIN+ACK及びACKパケットのSEQ番号及びACK番号をそのもともとのSEQ番号及びACK番号に戻す必要がある。
【００６２】
要約すれば、本発明の実施例は、TCP及びUDP接続を、例えば、HTTPポート８０といったHTTPポートでの単一のステートフルTCP接続にトンネリングすることを可能にする。単一ステートフルTCP接続は複数のUDP及びTCP接続からの全てのデータを方向付ける。したがって、パケットベースのマルチメディア会議アプリケーションは、マルチメディアデータのクライアント又は受信者を保護するファイアウォールをうまく通り抜けることができる。接続がステートフルだから、ファイアウォールがトンネリングされたTCPデータパケットを”out of state”或いはウィルスの襲撃と誤解して放棄する可能性が少なくなる。
【００６３】
２つのモジュール、つまり、上述のWinsockProxy.dllとトンネリングドライバをアプリケーションモジュールスタックに追加したことにより、ここで説明している機能性を達成する。上述のごとく、Winsock32.dllではなく、WinsockProxy.dllにリンクする電話会議アプリケーションを修正することで、Winsock32.dllを呼び出す前にあらゆる関数呼び出しのシミュレーションが可能になる。TCP/IPドライバを介して信頼性のある接続メカニズムが全て維持されることを理解するべきである。一つの実施例において、ここで説明したトンネリングの実施例によってステートフルな無接続TCPスキームを達成することができる。この例で、UDPデータグラムはステートフルな無接続TCP/IPヘッダにパッケージ化されるが、基本的に正規のTCP/IPヘッダ及びデータグラムのように見える。受信時に、データグラムは無接続TCP/IPデータグラムとして識別され、無接続TCP/IPヘッダがデータグラムから取り除かれ、データは無接続TCP/IPヘッダが取り除かれた後に残っているもともとの又は基礎をなすプロトコルに従って処理される。無接続TCP/IPヘッダはSYN番号及びACK番号が正しくインクリメントされてステートフルに見えるので、肯定応答、検証、再送信要求などといった応答を自動的に開始しない。
【００６４】
一つの実施例において、無接続TCP/IPヘッダはTCP/IPプロトコルを優先又は必要とすることのあるインターネットやその他のネットワークでの送信を可能にする。しかし、データグラムが無接続TCP/IPデータグラムとして識別される結果、基礎をなすデータグラムからヘッダが取り除かれことになり、伝統的な肯定応答やその他の信頼性データの交換を不可能にする。実施例はクライアント・サーバの関係を説明しているが、関係を任意の適切なデータの受信者及び送信者に広げることができるので、この関係は限定を意味するものではない。
【００６５】
上記の実施例を考えれば、発明はコンピュータシステムに格納されたデータを必要とする様々なコンピュータで実現される操作を用いることができることを理解するべきである。これらの操作は物理的な数量の物理的な操作を要するものである。必ずしもそうとは限らないが、普通は、こうした数量は、格納、転送、結合、比較、及びそれ以外の操作が可能な電気又は磁気信号の形をとる。さらに、実行される操作は、生成、識別、判定、又は比較といった表現で呼ばれることが多い。
【００６６】
発明は、コンピュータ判読可能な媒体上にコンピュータ判読可能なコードとして実施することもできる。コンピュータ判読可能な媒体は後からコンピュータシステムで読み取り実行できるデータを記憶できるどんなデータストレージデバイスでも構わない。コンピュータ判読可能な媒体はコンピュータコードを含んだ電磁搬送波も含む。コンピュータ判読可能な媒体の例としては、ハードドライブ、ネットワーク接続ストレージ（NAS）、読み取り専用メモリ、ランダムアクセスメモリ、CD-ROM、CD-R、CD-RW、磁気テープや、その他の光学的及び非光学的データストレージデバイスなどがある。コンピュータ判読可能な媒体は、コンピュータ判読可能なコードを分散して記憶及び実行できるように、ネットワーク接続コンピュータシステムで分散することもできる。
【００６７】
明確に理解できるように前記の発明をいくらか詳細に説明してきたが、添付の特許請求の範囲内で一定の変更及び修正を実施できることは明白であろう。したがって、本実施例は例証のためであって限定のためではないと考えるべきであり、発明はここで述べた詳細に限定されるものではなく、添付の特許請求の範囲及び均等物の範囲内で修正が可能である。特許請求の範囲において、明記されていない限り、要素及び／又はステップは操作の何ら特定の順序を暗に示すものではない。
【図面の簡単な説明】
【００６８】
【図１】ファイアウォールを使用せずに情報をやりとりするコンピュータの簡易概略図。
【図２】２つのコンピュータがファイアウォールを介して通信している簡易概略図。
【図３】発明の一つの実施例による、信頼性のない接続能力及び信頼性のある接続能力を共に提供するために、無接続送信制御プロトコルスキームとの統合が可能な修正されたアプリケーションモジュールスタックを含むシステムの簡易概略図。
【図４】Ａは標準規格H.323アプリケーションモジュールのモジュールスタックを示す簡易概略図、Ｂは発明の一つの実施例によるポートトンネリングアプリケーションモジュールスタックを示す簡易概略図。
【図５】典型的なH.323 TCP/UDP接続シーケンスを示す簡易概略図。
【図６】Ａは入ってくるデータのブロックを標準のアプリケーションモジュールスタックを介してセグメント化することを説明する図、Ｂは発明の一つの実施例による、修正アプリケーションモジュールスタックがファイアウォールを介してデータをトンネリングできるようにするためのセグメンテーション及びヘッダの追加を説明する図。
【図７】模式的なホストA及びホストB間の典型的なTCP接続で使用したハンドシェイクシーケンス及び接続状態の概略図。
【図８】発明の一つの実施例による、無接続TCPヘッダの簡易概略図。
【図９】発明の一つの実施例による、マスタトンネリング接続の確立を説明するデータフロー論理図。
【図１０】発明の一つの実施例による、マスタトンネリング接続の確立をさらに説明するデータフロー論理図。
【図１１】発明の一つの実施例による、マスタトンネリング接続の終了を説明するデータフロー論理図。
【図１２】発明の一つの実施例による、マスタトンネリング接続の終了をさらに説明するデータフロー論理図。
【符号の説明】
【００６９】
100  コンピュータ１
102  コンピュータ２
112  ファイアウォール／NAT
132  ユーザモード
134  カーネルモード
136  ハードウェア
140  クライアントA
142  クライアントB
144  ポート172へのTCP接続
146  H.425のTCP接続
148  UDP接続：呼び出しパラメータ
152  データのブロック
154  TCP（又はUDP）ヘッダ
156  IPヘッダ
158  MACヘッダ
160  ポート80のトンネリングIP + TCPヘッダ
166  ホストA
168  ホストB
190  8ビット（上位バイト）ウィンドウサイズ
192  8ビット（下位バイト）ウィンドウサイズ
252  H.323アプリケーション
254  WinsockProxy.dll
256  TCP/IPスタック
258  トンネリングドライバ
260  NICカード
266  TCP/IPスタック
268  トンネリングドライバ／ネットワーク
270  ファイアウォール
272  トンネリングドライバ／ネットワーク
274  TCP/IPスタック
276  マスタトンネリング接続プロセス中
278  マスタトンネリング接続の確立
280  H.323接続プロセス中
282  H.323接続の確立
284  H.323データの送受信
286  H.323アプリケーション
288  WinsockProxy.dll
290  TCP/IPスタック
292  トンネリングドライバ
294  NICカード
296  TCP/IPスタック
298  トンネリングドライバ／ネットワーク
300  ファイアウォール
302  トンネリングドライバ／ネットワーク
304  TCP/IPスタック
306  後半、H.323接続解除プロセス中。前半にFIN+ACKのやりとりがすでに行なわれたと想定
308  H.323接続解除成立
310  マスタトンネリング接続解除プロセス中
312  マスタトンネリング接続解除成立
122a  アプリケーション
122b  ライブラリ
122d  トンネリングドライバ
130a  H.323アプリケーション
130b  Winsock32.dll
130c  TCP/IPドライバ
130d  NICドライバ
130e  ネットワークカード
152a  データのセグメント
152b  データのセグメント
152c  データのセグメント
【図１】
2006166426.tif 000003
【図２】
2006166426.tif 000004
【図３】
2006166426.tif 000005
【図４】
2006166426.tif 000006
【図５】
2006166426.tif 000007
【図６】
2006166426.tif 000008
【図７】
2006166426.tif 000009
【図８】
2006166426.tif 000010
【図９】
2006166426.tif 000011
【図１０】
2006166426.tif 000012
【図１１】
2006166426.tif 000013
【図１２】
2006166426.tif 000014