(57)【要約】【課題】パケットをトンネリングして送信する時に通信帯域を効率よく使用できるようにする。【解決手段】トンネリングパケット生成部１０６が、ＲＴＰパケット生成部１０５において生成した複数のＲＴＰパケットのペイロードデータを１つに結合して、ＦＷを通過可能なＨＴＴＰＳパケットを生成し、パケットの送信要求を行った受信装置に対してＨＴＴＰＳパケットを送信するようにして、パケットヘッダのオーバーヘッドを小さく抑え、通信帯域を効率よく使用することができるようにする。【選択図】図１
2008311942.tif 000002
【特許請求の範囲】
【請求項１】
自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成または取得し、前記生成または取得した複数のパケットのペイロードデータを１つに結合して、パケットの送信要求を行った受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するパケット生成手段と、
前記パケット生成手段によって生成されたパケットを前記受信装置に送信するパケット送信手段とを有することを特徴とするデータ送信装置。
【請求項２】
ネットワークに接続された受信装置からパケットの送信要求を受信する送信要求受信手段と、
前記送信要求受信手段によって受信されたパケットの送信要求に応じて、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成する第１のパケット生成手段と、
前記第１のパケット生成手段によって生成された複数のパケットのペイロードデータを１つに結合して、前記受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成する第２のパケット生成手段と、
前記第１のパケット生成手段または第２のパケット生成手段によって生成されたパケットを前記受信装置に送信するパケット送信手段とを有することを特徴とするデータ送信装置。
【請求項３】
前記第２のパケット生成手段は、前記第１のパケット生成手段によって生成された複数のパケットのペイロードデータをＭＴＵサイズの範囲内で最大になるように１つに結合してパケットを生成することを特徴とする請求項２に記載のデータ送信装置。
【請求項４】
前記送信要求受信手段によって受信されたパケットの送信要求において指定されたデータ形式がトンネリング方式であるか否かを判定する判定手段を有し、
前記第２のパケット生成手段は、前記判定手段による判定の結果、トンネリング方式の指定がされている場合に、前記受信装置へ送信するパケットとして、トンネリングしたパケットを生成することを特徴とする請求項２に記載のデータ送信装置。
【請求項５】
前記送信要求受信手段によって受信されたパケットの送信要求において指定された送信先ＩＰアドレス及びポート番号をもとに、前記第１のパケット生成手段によって生成されたパケットがファイアウォールを通過可能であるか否かを判定する判定手段を有し、
前記第２のパケット生成手段は、前記判定手段による判定の結果、前記第１のパケット生成手段によって生成されたパケットが前記ファイアウォールを通過できない場合に、前記受信装置へ送信するパケットとして、トンネリングしたパケットを生成することを特徴とする請求項２に記載のデータ送信装置。
【請求項６】
前記第１のパケット生成手段は、符号化された動画像データまたは符号化された音声データからパケットを生成することを特徴とする請求項２に記載のデータ送信装置。
【請求項７】
前記第１のパケット生成手段は、ＲＴＰパケットを生成することを特徴とする請求項２に記載のデータ送信装置。
【請求項８】
前記第２のパケット生成手段は、ＨＴＴＰパケットまたはＨＴＴＰＳパケットを生成することを特徴とする請求項２に記載のデータ送信装置。
【請求項９】
前記パケット送信手段は、ＴＣＰ／ＩＰパケットまたはＵＤＰ／ＩＰパケットとしてパケットを送信することを特徴とする請求項１または２に記載のデータ送信装置。
【請求項１０】
自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成または取得し、前記生成または取得した複数のパケットのペイロードデータを１つに結合して、パケットの送信要求を行った受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するパケット生成工程と、
前記パケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とを有することを特徴とするデータ送信方法。
【請求項１１】
ネットワークに接続された受信装置からパケットの送信要求を受信する送信要求受信工程と、
前記送信要求受信工程において受信したパケットの送信要求に応じて、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成する第１のパケット生成工程と、
前記第１のパケット生成工程において生成した複数のパケットのペイロードデータを１つに結合して、前記受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成する第２のパケット生成工程と、
前記第１のパケット生成工程または第２のパケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とを有することを特徴とするデータ送信方法。
【請求項１２】
自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成または取得し、前記生成または取得した複数のパケットのペイロードデータを１つに結合して、パケットの送信要求を行った受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するパケット生成工程と、
前記パケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とをコンピュータに実行させることを特徴とするプログラム。
【請求項１３】
ネットワークに接続された受信装置からパケットの送信要求を受信する送信要求受信工程と、
前記送信要求受信工程において受信したパケットの送信要求に応じて、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成する第１のパケット生成工程と、
前記第１のパケット生成工程において生成した複数のパケットのペイロードデータを１つに結合して、前記受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成する第２のパケット生成工程と、
前記第１のパケット生成工程または第２のパケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とをコンピュータに実行させることを特徴とするプログラム。
【請求項１４】
請求項１２または１３に記載のプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ送信装置、データ送信方法、プログラム、及び記録媒体に関し、特に、通信帯域を効率よく利用しながらトンネリングによりデータ送信するために用いて好適な技術に関する。
【背景技術】
【０００２】
従来、インターネットを経由してプライベートなネットワークを接続する技術としては、トンネリング技術が一般的であった。トンネリング技術は、本来通信を行いたいプロトコルでは通信不可能な場合にも、別のプロトコルのパケットでパケットを包み込んでカプセル化することにより、通信を可能にするものである。
【０００３】
例えば、ＲＴＰ（RealTime Transport Protocol）パケットを用いてファイアウォール（Firewall、以下単にＦＷと称す）を越える手段として、ＨＴＴＰトンネリングが利用されている。ＲＴＰは、ＩＥＴＦ（The Internet Engineering Task Force）により定義されたプロトコルである。また、ＲＴＰは、動画像や音声などのマルチメディアデータをネットワークを介してリアルタイムに送信するためのプロトコルである（例えば、非特許文献１参照）。
【０００４】
ところが、ＦＷはプライベートなネットワークを保護するために設計されており、ＲＴＰパケットを遮断するように通常は設定されている。そのため、ＲＴＰパケットを用いて送信する場合は、ＨＴＴＰまたはＨＴＴＰＳでＲＴＰパケットを包み込んでカプセル化することによりＦＷを越えて通信するＨＴＴＰトンネリングという方法が用いられている。
【０００５】
【非特許文献１】Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:  A Transport Protocol for Real-Time Applications", RFC3550, July 2003.
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、動画像や音声などのマルチメディアデータのような容量の大きなデータを、前記ＨＴＴＰトンネリング方法を用いて送信するとパケット数が非常に大きくなる。このため、例えば、ＲＴＰパケットをそのまま単純にＨＴＴＰなどで包み込んでカプセル化しただけでは、パケットヘッダのオーバーヘッドが大きく、その結果、通信帯域を無駄に使用してしまうという問題点があった。
【０００７】
本発明は前述の問題点に鑑み、パケットをトンネリングして送信する時に通信帯域を効率よく使用できるようにすることを目的としている。
【課題を解決するための手段】
【０００８】
本発明のデータ送信装置は、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成または取得し、前記生成または取得した複数のパケットのペイロードデータを１つに結合して、パケットの送信要求を行った受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するパケット生成手段と、前記パケット生成手段によって生成されたパケットを前記受信装置に送信するパケット送信手段とを有することを特徴とする。
本発明のデータ送信装置の他の特徴とするところは、ネットワークに接続された受信装置からパケットの送信要求を受信する送信要求受信手段と、前記送信要求受信手段によって受信されたパケットの送信要求に応じて、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成する第１のパケット生成手段と、前記第１のパケット生成手段によって生成された複数のパケットのペイロードデータを１つに結合して、前記受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成する第２のパケット生成手段と、前記第１のパケット生成手段または第２のパケット生成手段によって生成されたパケットを前記受信装置に送信するパケット送信手段とを有することを特徴とする。
【０００９】
本発明のデータ送信方法は、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成または取得し、前記生成または取得した複数のパケットのペイロードデータを１つに結合して、パケットの送信要求を行った受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するパケット生成工程と、前記パケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とを有することを特徴とする。
本発明のデータ送信方法の他の特徴とするところは、ネットワークに接続された受信装置からパケットの送信要求を受信する送信要求受信工程と、前記送信要求受信工程において受信したパケットの送信要求に応じて、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成する第１のパケット生成工程と、前記第１のパケット生成工程において生成した複数のパケットのペイロードデータを１つに結合して、前記受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成する第２のパケット生成工程と、前記第１のパケット生成工程または第２のパケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とを有することを特徴とする。
【００１０】
本発明のプログラムは、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成または取得し、前記生成または取得した複数のパケットのペイロードデータを１つに結合して、パケットの送信要求を行った受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するパケット生成工程と、前記パケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とをコンピュータに実行させることを特徴とする。
また、本発明のプログラムの他の特徴とするところは、ネットワークに接続された受信装置からパケットの送信要求を受信する送信要求受信工程と、前記送信要求受信工程において受信したパケットの送信要求に応じて、自装置が属するネットワークセグメントのプロトコルに従った複数のパケットを生成する第１のパケット生成工程と、前記第１のパケット生成工程において生成した複数のパケットのペイロードデータを１つに結合して、前記受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成する第２のパケット生成工程と、前記第１のパケット生成工程または第２のパケット生成工程において生成したパケットを前記受信装置に送信するパケット送信工程とをコンピュータに実行させることを特徴とする。
【００１１】
本発明の記録媒体は、前記の何れかに記載のプログラムを記録したことを特徴とする。
【発明の効果】
【００１２】
本発明によれば、複数のパケットのペイロードデータを１つに結合して受信装置からトンネリング方式によるデータ形式の指定が行なわれている場合には、トンネリングしたパケットを生成するようにした。これにより、パケットをトンネリングして送信する時にパケットヘッダのオーバーヘッドを小さく抑えることができる。したがって、通信帯域を効率よく使用することができる。
【発明を実施するための最良の形態】
【００１３】
（第１の実施形態）
以下、図面を参照しながら、本発明のデータ送信装置を、動画像データまたは音声データを送信する装置に適用した好適な実施形態について詳細に説明する。なお、以下では、データ送信のプロトコルとしてＲＴＰとＨＴＴＰＳとを用いたデータ送信装置に本発明を適用した実施形態について説明する。しかし、利用するプロトコルはＲＴＰ及びＨＴＴＰＳに限らず、ＯＳＩ参照モデルの同一レイヤの他のプロトコルまたは別レイヤの他のプロトコルに適用することが可能である。
【００１４】
本実施形態のデータ送信装置の機能構成について、図１に示すブロック図を参照しながら説明する。本実施形態のデータ送信装置はそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにＬＡＮ（Local Area Network）などで構成されているものとする。
【００１５】
図１に示すように、データ送信装置１００は、動画像符号化部１０１と、音声符号化部１０２と、パケット構成判定部１０３と、パケット生成部１０４と、送信要求受信部１０７と、パケット送信部１０８とから構成されている。また、パケット生成部１０４は、ＲＴＰパケット生成部１０５とトンネリングパケット生成部１０６とから構成されている。また、図１において、１１１及び１１２は各種ネットワークに代表される伝送路であり、本実施形態においては、受信装置から送られる送信要求を受信したり、パケット化した動画像データや音声データを送信したりするネットワークである。
【００１６】
動画像符号化部１０１は、ビデオカメラやＷｅｂカメラ等の映像入力装置１０９から入力された動画像データを、例えば、ＭＰＥＧ−４方式により圧縮符号化する。動画像データの圧縮方式としては、ＭＰＥＧ−４方式に限らず、ＭＰＥＧ−２方式やＨ．２６４方式などの符号化方式を用いることができる。
【００１７】
一方、音声符号化部１０２は、マイクロフォンなどの音声入力装置１１０から入力された音声データを、例えば、ＡＤＰＣＭ方式により圧縮符号化する。音声データの符号化方式としては、ＡＤＰＣＭ方式に限らず、ＰＣＭ方式やＡＭＲ方式などの符号化方式を用いることができる。そして、動画像符号化部１０１において圧縮符号化された動画像データ、または音声符号化部１０２において圧縮符号化された音声データは、パケット生成部１０４へ入力されてパケット化される。
【００１８】
図２は、本実施形態のデータ送信装置１００がパケットを送信するまでの処理手順の一例を示すフローチャートである。
まず、データ送信装置１００は、受信装置から送信された送信要求を送信要求受信部１０７において受信する（ステップＳ２０１）。この送信要求を制御するためのプロトコルとしては、例えば、ＲＴＳＰ（Real Time Streaming Protocol）やＨＴＴＰなどのプロトコルを利用することができる。
【００１９】
送信要求受信部１０７が受信装置からの送信要求を受信すると、パケット構成判定部１０３は、動画像符号化部１０１または音声符号化部１０２から入力されたデータをパケット化するようにパケット生成部１０４へ指示する（ステップＳ２０２）。パケット化の指示を受けたパケット生成部１０４は、まず、第１のパケット生成手段として機能し、ＲＴＰパケット生成部１０５において、ＲＴＰパケットを生成する（ステップＳ２０３）。
【００２０】
次に、パケット構成判定部１０３は、受信装置から受信した送信要求を解析する（ステップＳ２０４）。そして、受信装置へ送信するパケットの構成がトンネリングパケットであるか否かを判定する（ステップＳ２０５）。ここでの判定は、送信要求において指定されたデータ形式（例えば、ＭＩＭＥタイプなど）の情報から判定することが可能である。すなわち、トンネリング方式によるデータ形式の指定がなされている場合はトンネリングパケット化し、指定されていなければトンネリングしないと判定することができる。また、データ形式以外にも、送信要求において指定された送信先ＩＰアドレス及びポート番号からも判定することが可能である。これら送信先ＩＰアドレス及びポート番号をもとに、ＦＷを通過できなければトンネリングパケット化し、ＦＷを通過できればトンネリングしないと判定することも可能である。
【００２１】
ステップＳ２０５の判定の結果、パケットの構成がトンネリングパケットでない場合は、ＲＴＰパケット生成部１０５において生成したＲＴＰパケットをそのまま受信装置へ送信するため、ステップＳ２０７へ処理を移行する。一方、ステップＳ２０５の判定の結果、パケットの構成がトンネリングパケットである場合は、パケット生成部１０４は第２のパケット生成手段として機能し、トンネリングパケット生成部１０６は、トンネリングパケットを生成する（ステップＳ２０４）。なお、トンネリングパケットを生成する方法の詳細は、図３を参照しながら後述する。
【００２２】
最後に、パケット送信部１０８は、ＲＴＰパケット生成部１０５において生成したＲＴＰパケットまたはトンネリングパケット生成部１０６において生成したトンネリングパケットを所定の宛先へ送信する（ステップＳ２０７）。この時、パケット送信部１０８は、ＴＣＰ／ＩＰパケットまたはＵＤＰ／ＩＰパケットとして送信する。
【００２３】
図３は、本実施形態において、トンネリングパケット生成部１０６がパケットを生成する処理手順の一例を示すフローチャートである。
トンネリングパケット生成部１０６は、まず、結合するＲＴＰパケットのペイロードデータ数ｎを「０」にして初期化する（ステップＳ３０１）。次に、ＲＴＰパケット生成部１０５において生成されたＲＴＰパケットを取得する（ステップＳ３０２）。そして、ペイロードデータ数ｎに１を加算する（ステップＳ３０３）。
【００２４】
そして、ｎ個のＲＴＰパケットのペイロードサイズの総和に、トンネリングパケットのヘッダサイズを加えたサイズｓを計算する（ステップＳ３０４）。ここでトンネリングパケットのヘッダは、例えば下位層から順にＥｔｈｅｒｎｅｔ（登録商標）ヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ＨＴＴＰＳヘッダ、ＲＴＰヘッダなどで構成され、サイズｓはトンネリングパケット全体のサイズである。なお、トンネリングに使用するプロトコルとしては、ＨＴＴＰＳに限らずＨＴＴＰなどのプロトコルを用いることが可能である。
【００２５】
次に、サイズｓとＭＴＵ（Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）サイズとを比較し、サイズｓがＭＴＵサイズよりも大きいか否かを判定する（ステップＳ３０５）。ＭＴＵサイズは、通信ネットワークにおいて一度の転送で送信可能なデータの最大値であり、Ｅｔｈｅｒｎｅｔフレームでは１５００バイト程度が最適とされ、ダイヤルアップ接続では５７６バイト程度が最適とされている。
【００２６】
ステップＳ３０５の判定の結果、サイズｓがＭＴＵサイズ以下（ＭＴＵサイズの範囲内）である場合は、次のＲＴＰパケットを取得するために、ステップＳ３０２へ処理を戻す。一方、ステップＳ３０５の判定の結果、サイズｓがＭＴＵサイズよりも大きい場合は、取得したｎ個のＲＴＰパケットのペイロードデータの全てを現在のトンネリングパケットとして構成することはできない。そこで、これまでにＲＴＰパケット生成部１０５から取得した（ｎ−１）個のＲＴＰパケットのペイロードデータを結合し、ＨＴＴＰＳヘッダを付加することにより１つのＨＴＴＰＳパケットを生成する（ステップＳ３０６）。そして、トンネリングパケット生成処理を終了する。なお、ＨＴＴＰＳパケットではなくＨＴＴＰパケットを生成するときも同様の手順で行う。
【００２７】
図４は、本実施形態のデータ送信装置１００により送信されるパケットの詳細構造、及び従来のトンネリングパケットの詳細構造の例を示す図である。
図４（ａ）は、データ送信装置１００がＦＷを経由しない同一ネットワークセグメント内の受信装置へ送信する場合のパケットの構造を示す図であり、各パケットはＲＴＰヘッダとＲＴＰペイロードとから構成されるＲＴＰパケットである。なお、図４（ａ）において、ＲＴＰヘッダよりも下位層のプロトコルヘッダ（例えば、Ｅｔｈｅｒｎｅｔヘッダ、ＩＰヘッダ、及びＵＤＰヘッダなど）は図示しない。また、各ＲＴＰパケットのＲＴＰヘッダのサイズは１２バイト、ペイロードのサイズは４００バイトであるものとする。なお、ＲＴＰヘッダのサイズは標準で１２バイトであるが、オプションが付加されると１２バイトを超えることがある。
【００２８】
図４（ｂ）は、本実施形態のデータ送信装置１００が図４（ａ）に示すＲＴＰパケットから生成するトンネリングパケットの構造を示す図である。図４（ｂ）に示すように、本実施形態のトンネリングパケットは、図４（ａ）に示すＲＴＰパケットのペイロード（１）からペイロード（３）までを結合したＲＴＰパケットに、ＨＴＴＰＳヘッダを付加してカプセル化した構成となる。なお、図４（ｂ）において、ＨＴＴＰＳヘッダよりも下位層のプロトコルヘッダ（例えば、Ｅｔｈｅｒｎｅｔヘッダ、ＩＰヘッダ、及びＴＣＰヘッダなど）は図示しない。
【００２９】
なお、図４（ａ）に示す各ＲＴＰパケットのペイロードサイズが４００バイトの場合、ペイロード（１）からペイロード（４）までを結合すると、パケットの合計サイズがＥｔｈｅｒｎｅｔフレームのＭＴＵサイズの１５００バイトを越えてしまう。そのため、本実施形態では、トンネリングパケットをペイロード（１）からペイロード（３）までを結合した構成とし、ペイロード（４）は次のトンネリングパケットで構成するようにする。
【００３０】
一方、図４（ｃ）は、図４（ａ）に示すパケットから生成される従来のトンネリングパケットの構造を示す図である。なお、図４（ｃ）においても図４（ｂ）と同様に、ＨＴＴＰＳヘッダよりも下位層のプロトコルヘッダ（例えば、Ｅｔｈｅｒｎｅｔヘッダ、ＩＰヘッダ、及びＴＣＰヘッダなど）は図示しない。図４（ｃ）に示すように、従来の各トンネリングパケットは、図４（ａ）に示す各ＲＴＰパケットにＨＴＴＰＳヘッダを付加してカプセル化しただけの単純な構成である。
【００３１】
次に、図４（ｂ）に示すトンネリングパケットの構造と図４（ｃ）に示すトンネリングパケットの構造とを比較する。図４（ｂ）に示すトンネリングパケットは図４（ｃ）に示すトンネリングパケットに比べ、２×（トンネリングパケットヘッダサイズ＋ＲＴＰヘッダサイズ）バイト分のヘッダ情報を削減することが可能になる。そこで、トンネリング時に結合するＲＴＰパケットのペイロードデータ数をｎとする。この場合、本実施形態によるトンネリングパケットは、従来技術によるトンネリングパケットに比べ、（ｎ−１）×（トンネリングパケットヘッダサイズ＋ＲＴＰヘッダサイズ）バイトのヘッダ情報を削減することが可能になる。
【００３２】
図５は、本実施形態のデータ送信装置を含むシステム全体の構成例を示す図である。
互いに隔離された第１のネットワークセグメント５００及び第２のネットワークセグメント５０２は、インターネット５０１を介して相互に接続されている。また、第１のネットワークセグメント５００内のデータ送信装置５０４及び受信装置５０３は、ＦＷ５０５を介してインターネット５０１に接続されている。また、第２のネットワークセグメント５０２内の受信装置５０７及び受信装置５０８は、ＦＷ５０６を介してインターネット５０１に接続されている。
【００３３】
ＦＷ５０５及びＦＷ５０６は、通常のＷｅｂ用ポートが開いているように設定され、それ以外の通信は遮断するように設定されているものとする。通常のＷｅｂ用ポート番号としては、一般的には、ＨＴＴＰに８０番ポートなどが利用され、ＨＴＴＰＳに４４３番ポートなどが利用される。
【００３４】
受信装置５０３は、第１のネットワークセグメント５００内のデータ送信装置５０４から送信されるＲＴＰパケット５０９〜５１１を受信することが可能である。しかし、ＲＴＰパケット５０９〜５１１は、ＦＷ５０５において遮断される。このため、第２のネットワークセグメント５０２内の受信装置５０７及び受信装置５０８は、異なる第１のネットワークセグメント５００内のデータ送信装置５０４から送信されるＲＴＰパケット５０９〜５１１を受信することができない。
【００３５】
しかしながら、本実施形態に係るデータ送信装置５０４により送信されるトンネリングパケット５１２は、通常のＷｅｂ用ポートが開いているように設定されているＦＷなら通過することができる。よって、データ送信装置５０４から送信されるトンネリングパケット５１２は、設定を何ら変えることなくＦＷ５０５及びＦＷ５０６を通過する。そして、異なる第２のネットワークセグメント５０２内の受信装置５０７及び受信装置５０８へ送信される。
【００３６】
以上のようにして本実施形態のデータ送信装置によれば、複数のＲＴＰパケットのペイロードデータを１つのペイロードデータに結合して、ＦＷを通過可能なＨＴＴＰＳパケットを生成するようにした。これにより、通常はＦＷで遮断されるＲＴＰパケットを、トンネリング時にはＷｅｂの通信に見せかけてＦＷを通過させることができる。また、パケットヘッダのオーバーヘッドを小さく抑え、通信帯域を効率よく使用することができる。
【００３７】
（第２の実施形態）
第１の実施形態におけるデータ送信装置１００では、パケット生成部１０４は動画像符号化部１０１において圧縮符号化された動画像データ、または音声符号化部１０２において圧縮符号化された音声データを入力してパケットを生成した。本実施形態では、図６に示すように、パケット生成部１０４が、動画像符号化部及び音声符号化部以外から動画像データまたは音声データを取得する構成について説明する。
【００３８】
図６は、本実施形態におけるデータ送信装置６００の基本構成例を示すブロック図である。図６において、図１と同じ構成については同じ番号を付与している。
図６において、マルチメディアデータ記憶装置６０２には、マルチメディアコンテンツ（マルチメディアデータ）が記録されている。マルチメディアデータ抽出部６０１は、マルチメディアデータ記憶装置６０２に記憶されているマルチメディアデータを読み出し、パケット生成部１０４へ出力する。パケット生成部１０４に入力されたマルチメディアデータを、第１の実施形態と同様に、送信先の受信装置に応じて最適なパケット構成にして送信する。
【００３９】
本実施形態のデータ送信装置６００は、マルチメディアデータ記憶装置６０２に記録されたマルチメディアデータを読み出してパケットを生成し、受信装置へ送信する。これにより、記録済みのマルチメディアデータについても、通常はＦＷで遮断されるＲＴＰパケットを、トンネリング時にはＷｅｂの通信に見せかけてＦＷを通過させることができる。また、パケットヘッダのオーバーヘッドを小さく抑え、通信帯域を効率よく使用することができる。
【００４０】
（第３の実施形態）
図５に示した第１の実施形態におけるデータ送信装置を含むシステム全体の構成では、データ送信装置５０４はＲＴＰパケット及びトンネリングパケットの両方を生成する機能を有していた。本実施形態では、図７に示すように、パケット生成装置とは異なる装置においてトンネリングパケットを生成する例について説明する。
【００４１】
図８は、本実施形態におけるトンネリングサーバの機能構成例を示すブロック図である。
図８において、パケット受信部８０１は、パケット生成装置７０１から送信されたＲＴＰパケットを受信する。そして、トンネリングパケット生成部８０２は、取得したＲＴＰパケットからトンネリングパケットを生成する。トンネリングパケットの生成方法は、第１の実施形態と同様であるため、説明は省略する。そして、パケット送信部８０３は、生成したトンネリングパケットを伝送路８０４を介して送信する。
【００４２】
図７は、本実施形態におけるトンネリングサーバ（データ送信装置）を含むシステム全体の構成を示す図である。図７において、図５と同じ構成については同じ番号を付与している。
図７において、互いに隔離された第１のネットワークセグメント７００及び第２のネットワークセグメント５０２は、インターネット５０１を介して相互に接続されている。また、第１のネットワークセグメント７００内のパケット生成装置７０１とＦＷ５０５との間には、トンネリングサーバ７０２が設置されている。
【００４３】
本実施形態のパケット生成装置７０１は、トンネリングパケット生成機能を有していない。異なる第２のネットワークセグメント５０２内の受信装置５０７及び受信装置５０８宛てにパケット生成装置７０１から送信されたＲＴＰパケット５０９〜５１１は、まず、トンネリングサーバ７０２に入力される。そして、トンネリングサーバ７０２において、第１の実施形態と同様に最適なパケット構成にしてカプセル化され、トンネリングパケット５１２が生成される。トンネリングサーバ７０２において生成されたトンネリングパケット５１２は、ＦＷ５０５及びＦＷ５０６で遮断されることなく、異なる第２のネットワークセグメント５０２内の受信装置５０７及び受信装置５０８へ送信される。
【００４４】
本実施形態で示したトンネリングサーバ７０２によれば、トンネリングパケット生成機能を持たないパケット生成装置７０１から受信したＲＴＰパケットからトンネリングパケットを生成して、受信装置へ送信する。このように、トンネリングパケット生成機能を持たないパケット生成装置によりシステム全体が構成される場合にも、パケット生成装置とＦＷとの間にトンネリングサーバを設置するだけで、第１の実施形態と同様の効果が得られる。
【００４５】
以上のように本実施形態によれば、トンネリングサーバ７０２において複数のＲＴＰパケットのペイロードデータを１つに結合して、ＦＷを通過可能なＨＴＴＰＳパケットを生成するようにした。これにより、通常はＦＷで遮断されるＲＴＰパケットを、トンネリング時にはＷｅｂの通信に見せかけてＦＷを通過させることができる。また、パケットヘッダのオーバーヘッドを小さく抑え、通信帯域を効率よく使用することができる。
【００４６】
（本発明に係る他の実施形態）
本発明の目的は前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶したコンピュータ読み取り可能な記録媒体は本発明を構成することになる。
【００４７】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【００４８】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現される。また、これだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれる。
【００４９】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００５０】
以上、この発明の実施形態について、図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００５１】
【図１】本発明の第１の実施形態におけるデータ送信装置の機能構成例を示すブロック図である。
【図２】本発明の第１の実施形態において、データ送信装置によるパケットを送信する処理手順の一例を示すフローチャートである。
【図３】本発明の第１の実施形態において、トンネリングパケット生成部がパケットを生成する処理手順の一例を示すフローチャートである。
【図４】本発明の第１の実施形態におけるデータ送信装置により送信されるパケットの詳細構造を示す図である。
【図５】本発明の第１の実施形態におけるデータ送信装置によるシステム全体の構成例を示す図である。
【図６】本発明の第２の実施形態におけるデータ送信装置の機能構成例を示すブロック図である。
【図７】本発明の第３の実施形態におけるトンネリングサーバによるシステム全体の構成例を示す図である。
【図８】本発明の第３の実施形態におけるトンネリングサーバの機能構成例を示すブロック図である。
【符号の説明】
【００５２】
１００  データ送信装置
１０１  動画像符号化部
１０２  音声符号化部
１０３  パケット構成判定部
１０４  パケット生成部
１０５  ＲＴＰパケット生成部
１０６  トンネリングパケット生成部
１０７  送信要求受信部
１０８  パケット送信部
１０９  映像入力装置
１１０  音声入力装置
１１１  伝送路
１１２  伝送路
【図１】
2008311942.tif 000003
【図２】
2008311942.tif 000004
【図３】
2008311942.tif 000005
【図４】
2008311942.tif 000006
【図５】
2008311942.tif 000007
【図６】
2008311942.tif 000008
【図７】
2008311942.tif 000009
【図８】
2008311942.tif 000010