JP4942976B2 - インターネットゲートウェイ - Google Patents

Description

この発明は、インターネットをはじめとする外部ネットワークに接続された受信装置が内部ネットワークに接続されたカメラの映像データを受信する際に、命令や映像データの中継を行うインターネットゲートウェイに関するものである。

従来のインターネットゲートウェイは、主として複数の独自プロトコルで通信している内部ネットワーク同士をインターネット経由で接続する場合に使用され、例えば特許文献１に示された広域監視制御システムでは、中間のインターネット区間において、独自プロトコルを汎用のＨＴＴＰ（Hyper Text Transfer Protocol）に変換することにより双方のネットワークを接続している。

接続する内部ネットワークの規模が同規模で相互に通信を行う場合は、上記特許文献１に示すように、双方にインターネットゲートウェイを設置することにより通信が可能であるが、例えば、内部ネットワークに多数の監視カメラを設置し、インターネット等の外部ネットワークを経由して、この監視カメラの映像を受信する場合には、外部ネットワーク側にインターネットゲートウェイを設置することは難しいために前記方法をとることはできない。

また、監視カメラの映像のインターネット経由での配信を考えた場合に、外部ネットワーク側のネットワーク構成は単一のものとならないことが予想されるため、インターネットゲートウェイには外部ネットワークの構成にあわせて最適な映像の配信プロトコルを選択する必要がある。

特開２００３−２２９８８０号公報（段落００４５、段落００４８、図１）

従来のインターネットゲートウェイは、以上のように構成され、同規模の複数の内部ネットワーク同士をインターネットを経由して相互接続することを目的としているので、接続するネットワークの数だけインターネットゲートウェイが必要となるという課題があった。例えば、内部ネットワークに接続された監視カメラの映像をインターネット等の外部ネットワークに接続した受信装置に配信する場合は、内部ネットワークは大規模で固定的な構成、外部ネットワークは小規模で様々なネットワーク構成が要件となるが、内部ネットワーク及び外部ネットワークの双方にインターネットゲートウェイを設置し固定的な構成で運用をする必要があるという課題があった。

この発明は上記のような課題を解決するためになされたもので、接続するネットワークの数だけ必要としないインターネットゲートウェイを得ることを目的とする。

この発明に係るインターネットゲートウェイは、カメラの映像データをカメラ側ＩＰネットワークを介して受信し、受信した映像データを、ファイアウォールを経由したネットワーク構成の端末側ＩＰネットワークを介して映像データを要求した受信装置に配信するインターネットゲートウェイにおいて、上記受信装置からの要求を解釈するメディア制御部と、上記カメラの配信プロトコル等のカメラ情報を保持するカメラ情報テーブルと、上記受信装置からの要求を解釈した上記メディア制御部の指示に基づき、上記カメラ情報テーブルに保持されたカメラ情報を検索して上記カメラの配信プロトコルを入手し、入手した上記カメラの配信プロトコルがＲＴＰ（Real-Time Protocol）の場合に、ＵＤＰ（User Datagram Protocol）でデータ部分のないパケットによりテスト用ストリームを作成して上記端末側ＩＰネットワークを介して上記受信装置に配信し、上記受信装置からのＨＴＴＰの正常応答又は上記端末側ＩＰネットワークからのエラー通知により、上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できるか否かを検出するネットワーク構成検出部と、上記カメラからカメラ側ＩＰネットワークを介して配信された映像データを受信し、上記ネットワーク構成検出部により上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できると検出された場合には上記ＲＴＰを変更せずに上記映像データを上記端末側ＩＰネットワークを介して上記受信装置に配信し、上記ネットワーク構成検出部により上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できないと検出された場合には上記ＲＴＰをＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に変更して上記映像データを上記端末側ＩＰネットワークを介して上記受信装置に配信するメディア中継部とを備えたものである。

この発明により、映像データの配信途中で配信が途切れにくく、有効に映像データをリアルタイム配信するインターネットゲートウェイを得ることができるという効果が得られる。

実施の形態１．
図１はこの発明の実施の形態１によるインターネットゲートウェイの構成を示すブロック図である。図１において、インターネットゲートウェイ１は、ネットワークインタフェース部１１、カメラ情報テーブル１２、メディア制御部１３、ネットワーク構成検出部１４及びメディア中継部１５を備えている。

ネットワークインタフェース部１１は、カメラ側ＩＰネットワーク１００に接続されたカメラ３と端末側ＩＰネットワーク２００に接続された受信装置４との間で通信を行う。カメラ情報テーブル１２はカメラ３のカメラＩＤ、カメラ名、映像形式、ＩＰアドレス、配信プロトコル、ポート番号等のカメラ情報を保持している。

メディア制御部１３は、端末側ＩＰネットワーク２００に接続された受信装置４からの要求をネットワークインタフェース部１１を介して受信し、受信した要求の内容を解釈し、カメラ情報テーブル１２に保持されたカメラ情報を検索して、ネットワーク構成検出部１４及びメディア中継部１５に、受信した要求の内容に応じて指示を与える。

ネットワーク構成検出部１４は、受信装置４からの要求を解釈したメディア制御部１３の指示に基づき、カメラ情報テーブル１２に保持されたカメラ情報を検索してカメラの配信プロトコルを入手し、テスト用ストリームを作成して端末側ＩＰネットワーク２００を介して受信装置４に配信し、受信装置４又は端末側ＩＰネットワーク２００からの応答により、端末側ＩＰネットワーク２００のネットワーク構成がカメラの配信プロトコルを利用できるか否かを検出する。

メディア中継部１５は、受信装置４からの要求を解釈したメディア制御部１３からの指示に基づき、カメラ情報テーブル１２を検索し、カメラ３からカメラ側ＩＰネットワーク１００を介して配信された映像データを受信し、ネットワーク構成検出部１４の検出結果に基づき配信プロトコルを決定して、受信した映像データを端末側ＩＰネットワーク２００を介して受信装置４に配信する。

図２はインターネットゲートウェイ１を利用した監視映像配信システムにおける典型的なネットワーク構成例を示す図である。図２の例では、受信装置４とインターネットゲートウェイ１を接続する端末側ＩＰネットワーク２００はファイアウォール２を経由したネットワーク構成となっている。したがって、通常の場合には、受信装置４からインターネットゲートウェイ１への要求はＨＴＴＰ（Hyper Text Transfer Protocol）を利用することにより、ファイアウォール２の設定を変更せずに通信を行うことができる。

図３はインターネットゲートウェイ１が受信装置４から受信する要求と応答の例を示す図である。図３に示すように、要求はコマンドとそのコマンドに付与された引数により構成されている。インターネットゲートウェイ１のメディア制御部１３は受信した要求の内容を解釈し、その処理結果を応答として受信装置４に送信する。

次に、図３における各コマンドの概要について説明する。
「ｏｐｅｎ」コマンドは受信装置４からインターネットゲートウェイ１に対して最初に接続を行う際に送信する命令で、この応答として、受信装置４はインターネットゲートウェイ１からセッションＩＤを受け取る。受信装置４は、一旦、セッションＩＤを受け取ると、「ｃｌｏｓｅ」コマンドを実行するまでは、要求に受け取ったセッションＩＤを引数として付与する。受信装置４側でカメラ３のカメラＩＤが未知の場合は、受信装置４はカメラ名からカメラＩＤの検索を行う「ｌｏｏｋｕｐ」コマンドをインターネットゲートウェイ１に送信してカメラＩＤを得る。

インターネットゲートウェイ１は、「ｓｅｔｕｐ」コマンドで指定されたカメラＩＤのカメラ３の配信準備を行い、その応答として受信装置４の受信ポート番号を指定し、「ｐｌａｙ」コマンドにより指定されたカメラＩＤのカメラ３によるカメラ映像の配信処理を受け付ける。また、インターネットゲートウェイ１は、「ｐａｕｓｅ」コマンドにより指定されたカメラＩＤのカメラ３によるカメラ映像の配信静止を行い、「ｓｔｏｐ」コマンドにより指定されたカメラＩＤのカメラ３によるカメラ映像の配信停止を行う。

図４はカメラ情報テーブル１２の例を示す図である。このカメラ情報テーブル１２は、カメラ３のカメラＩＤ、カメラ名、映像形式、ＩＰアドレス、配信プロトコル、ポート番号等のカメラ情報を保持している。メディア制御部１３は、受信装置４より「ｓｅｔｕｐ」コマンド、「ｐｌａｙ」コマンド、「ｐａｕｓｅ」コマンド、「ｓｔｏｐ」コマンド、「ｌｏｏｋｕｐ」コマンドの要求を受信した場合には、カメラ情報テーブル１２を検索して該当するカメラＩＤやカメラ名が存在するかどうか確認し、存在する場合には、受信した要求を実行する正常処理を行い、存在しない場合には、受信した要求を実行せずに異常処理を行う。

例えば、カメラ情報テーブル１２の内容が図３の場合に、コマンドが「ｐｌａｙ」、引数が「ＳＩＤ１，ＣＡＭ＿００１」の要求を受信した場合に、メディア制御部１３がカメラ情報テーブル１２を検索すると、カメラＩＤが「ＣＡＭ＿００１」のカメラＡは存在するので、カメラ映像の配信処理を受け付けて正常処理を実行する。同じコマンドが「ｐｌａｙ」でも、引数が「ＳＩＤ１，ＣＡＭ＿１００」の要求を受信した場合には、メディア制御部１３がカメラ情報テーブル１２を検索すると、カメラＩＤが「ＣＡＭ＿１００」のカメラは存在しないため、カメラ映像の配信処理を受け付けずに異常処理を実行し、メディア制御部１３は応答としてＮＧメッセージを返す。

図１において、メディア制御部１３が解釈した要求が「ｓｅｔｕｐ」コマンドの場合には、ネットワーク構成検出部１４は、メディア制御部１３の指示に基づき、端末側ＩＰネットワーク２００のネットワーク構成の検出処理を行う。この目的は、端末側ＩＰネットワーク２００のネットワーク構成に応じてカメラ映像の最適な配信プロトコルを選択することである。

ＩＰネットワークの配信プロトコルとしては、コネクション型のＴＣＰ（Transmission Control Protocol）とコネクションレス型のＵＤＰ（User Datagram Protocol）があるが、通常は、信頼性を必要とする制御データにはＴＣＰを使用し、映像データ等の性能を優先したデータにはＵＤＰを使用することが多い。

したがって、カメラ側ＩＰネットワーク１００では、カメラ３からの映像データの配信プロトコルはＵＤＰが使用されることが多い。また、映像データ等のリアルタイムデータを配信する場合は、ＵＤＰのデータ部分を映像データの配信を目的として再定義したＲＴＰ（Real-Time Protocol）が利用されている。一方、端末側ＩＰネットワーク２００は、例えば図２に示すように、中間にファイアウォール２を経由するネットワーク構成を取ることがほとんどであり、通過する配信プロトコルが制限されている場合が多い。そのため、カメラ３から配信された映像データの配信プロトコルをそのまま中継しても、端末側ＩＰネットワーク２００の構成により受信装置４に届くかどうかは不明である。

一般に、ＨＴＴＰの配信プロトコルは、映像データの配信のようなリアルタイムの配信に適しておらず、配信途中で配信が途切れてしまうことがある。その点ではＲＴＰの配信プロトコルの方が有利である。そこで、この実施の形態１では、端末側ＩＰネットワーク２００のネットワーク構成がＲＴＰの配信プロトコルを利用できる場合には、カメラ３の映像データを配信プロトコルを変更せずに受信装置４に送信し、端末側ＩＰネットワーク２００のネットワーク構成がＲＴＰの配信プロトコルを利用できない場合には、カメラ３の映像データを配信プロトコルをＨＴＴＰに変更して受信装置４に送信する。

ネットワーク構成検出部１４は、カメラ３の映像データの配信プロトコルに基づきテスト用ストリームを作成し、端末側ＩＰネットワーク２００を介して受信装置４に向けて作成したテスト用ストリームを配信する。そのテスト用ストリームを受信装置４が正常に受信でき、受信装置４から正常応答を受信した場合は、端末側ＩＰネットワーク２００のネットワーク構成がカメラの配信プロトコルを利用できると判断し、メディア中継部１５は、ネットワーク構成検出部１４の検出結果に基づき、カメラ３の映像データの配信プロトコルを変更せずに、パケットの宛先（ＩＰアドレスとポート番号）のみを変更して配信する。テスト用ストリームが受信装置４に届かず、受信装置４から正常応答を受信しない場合には、メディア中継部１５はカメラ３の映像データの配信プロトコルを別の配信プロトコルに変更し、パケットの宛先を変更して配信する。

図５はネットワーク構成検出部４のネットワーク構成の検出処理の流れを示すフローチャートである。ステップＳＴ１１において、ネットワーク構成検出部１４は、メディア制御部１３からカメラＩＤと受信装置４のＩＰアドレスを入手する。

ステップＳＴ１２において、ネットワーク構成検出部１４は、カメラ情報テーブル１２をカメラＩＤに基づき検索し、対応するカメラ３の配信プロトコルを入手する。例えば、図４の例では、カメラＩＤ「ＣＡＭ＿００１」のカメラＡの配信プロトコルが「ＲＴＰ」で、カメラＩＤ「ＣＡＭ＿００２」のカメラＢの配信プロトコルが「ＲＴＰ」である。

ステップＳＴ１３において、ネットワーク構成検出部１４は、入手したカメラ３の配信プロトコルがＲＴＰベースの場合、ＵＤＰ形式でデータ部分のないパケットによりテスト用ストリームを作成する。ここで、ＵＤＰ形式を使用するのは、パケットを容易に作成できることと、ＵＤＰ形式のパケットが端末側ＩＰネットワーク２００を通過できれば、ＲＴＰ形式のパケットが端末側ＩＰネットワーク２００を通過できることがわかっているからである。

ステップＳＴ１４において、ネットワーク構成検出部１４は、作成したテスト用ストリームを、受信装置４のＩＰアドレスとポート番号を指定して配信し、内部のタイマーをリセットする。

ステップＳＴ１５において、ネットワーク構成検出部１４は、作成したテスト用ストリームを連続的に配信すると共に、タイマーの時間を進めながら、受信装置４からの応答を待ち、タイマーの設定時間内に、受信装置４からテスト用ストリームの正常応答を受信するか否かを判定する。正常応答を受信した場合には、ネットワーク構成検出部１４は、端末側ＩＰネットワーク２００のネットワーク構成が、カメラ３の映像データの配信プロトコルを利用できることを検出する。受信装置４からの正常応答の通信プロトコルとしては、要求と同様にＨＴＴＰを利用することにより、通常の場合、ファイアウォール２の設定を変更せずに通信を行うことができる。

一方、上記ステップＳＴ１５で正常応答を受信せずに、ステップＳＴ１６において、ネットワーク構成検出部１４は、中間のファイアウォール２等のネットワーク装置から、設定によりテスト用ストリームを通過させることができないない内容のエラー通知を受信した場合には、端末側ＩＰネットワーク２００のネットワーク構成がカメラ３の映像データの配信プロトコルを利用できないことを検出する。中間のネットワーク機器からのエラー通知として通常使用される通知プロトコルの例としては、ＩＣＭＰ（Internet Control Message Protocol）メッセージが利用される。

図６はＩＣＭＰメッセージの構成を示す図である。ネットワーク構成検出部１４は、端末側ＩＰネットワーク２００の中間のネットワーク機器から受信したＩＣＭＰメッセージのヘッダ部分が「Ｔｙｐｅ：３」（Ｄｅｓｔｉｎａｔｉｏｎ Ｕｎｒｅａｃｈａｂｌｅ）で、「Ｃｏｄｅ：３」（Ｐｏｒｔ Ｕｎｒｅａｃｈａｂｌｅ）の場合は、指定したポートが閉じられているために、テスト用ストリームの到達が不能と判断し、端末側ＩＰネットワーク２００のネットワーク構成がカメラ３の映像データの配信プロトコルを利用できないことを検出する。

また、端末側ＩＰネットワーク２００の中間のネットワーク機器の設定によっては、ポートが閉じられているためにテスト用ストリームの中継をせず、ネットワークセキュリティ対策としてＩＣＭＰメッセージの返送も行わない機器が存在する場合には、図５のステップＳＴ１７において、ネットワーク構成検出部１４は、受信端末４からの正常応答も中間のネットワークからのＩＣＭＰメッセージも受け取らないままタイマーが設定時間を経過した場合は、中間のネットワーク機器の設定によりテスト用ストリームの到達が不能と判断し、端末側ＩＰネットワーク２００のネットワーク構成がカメラ３の映像データの配信プロトコルを利用できないものであることを検出する。

タイマーが設定時間まで経過していない場合には、ステップＳＴ１８において、ネットワーク構成検出部１４はタイマーの時間を進めて、上記ステップ１５の処理に戻り上記の処理を繰り返す。

一方、受信装置４においては、インターネットゲートウェイ１からの「ｓｅｔｕｐ」コマンドの応答を受信してからタイマーの設定時間内にテスト用ストリームを受信できるかどうかにより端末側ＩＰネットワーク２００のネットワーク構成を検出する。

図７は受信端末４の端末側ＩＰネットワーク２００のネットワーク構成の検出処理の流れを示すフローチャートである。ステップＳＴ２１において、受信装置４は、インターネットゲートウェイ１からの「ｓｅｔｕｐ」コマンドの応答を受信し、指定されたポート番号を空けて内部のタイマーをリセットする。ステップＳＴ２２において、受信装置４は、インターネットゲートウェイ１からのテスト用ストリームを正常に受信したか否かを判断し、正常に受信した場合には、テストＯＫである旨の正常応答をインターネットゲートウェイ１に送信し処理を終了する。

テスト用ストリームを正常に受信しない場合に、ステップＳＴ２３において、受信装置４は、タイマーが設定時間を経過しているか否かを判断し、経過した場合には、テストＮＧとして処理を終了する。タイマーが設定時間を経過していない場合には、ステップＳＴ２４において、受信装置４は、タイマーの時間を進めて、上記ステップＳＴ２２の処理に戻り上記の処理を繰り返す。

図１において、メディア制御部１３にて解釈した要求が「ｓｅｔｕｐ」コマンドの場合には、ネットワーク構成検出部１４は端末側ＩＰネットワーク２００のネットワーク構成の検出処理を実行する。次に受信端末４から「ｐｌａｙ」コマンドを受信した際に、メディア中継部１５は、カメラ３から受信した映像データを、ネットワーク構成検出部１４のネットワーク構成の検出結果にあわせて最適な配信プロトコルを選択し、端末側ＩＰネットワーク２００を介して配信を行う。

ネットワーク構成検出部１４の検出結果により、テスト用ストリームの配信プロトコルが利用可能なネットワークにおいて、メディア制御部１３が「ｐｌａｙ」コマンドを受けると、メディア中継部１５は、カメラ３の映像データの配信プロトコルを変更せずに、ＩＰパケットの宛先のＩＰアドレスとポート番号を受信装置４のＩＰアドレスとポート番号に指定するだけで映像データの中継、配信が可能となる。

図８はメディア中継部１５の配信プロトコルを変更しない場合のストリームの中継処理の流れを示すフローチャートである。ステップＳＴ３１において、メディア中継部１５は、ネットワーク構成検出部１４からカメラＩＤ、受信装置４のＩＰアドレス、宛先ポート番号を入手する。ステップＳＴ３２において、メディア中継部１５は、入手したカメラＩＤを元にカメラ情報テーブル１２を検索して、対応するカメラ３のＩＰアドレス、ポート番号、配信プロトコルを入手する。

ステップＳＴ３３において、メディア中継部１５は、入手したカメラ３のＩＰアドレス、ポート番号、配信プロトコルに基づき、カメラ３からの映像データを受信する。ステップＳＴ３４において、メディア中継部１５は、カメラ３から受信した映像データのデータ部分の内容を変更せずに、ＩＰパケットの宛先のＩＰアドレスとポート番号を入手した受信装置４のＩＰアドレスとポート番号に変更する。

ステップＳＴ３５において、メディア中継部１５は、端末側ＩＰネットワーク２００を介して、宛先を変更したパケットを受信装置４に配信する。ステップＳＴ３６において、メディア中継部１５は、受信装置４から「ｓｔｏｐ」、「ｐａｕｓｅ」コマンドを受信したか否かを判断し、受信した場合には処理を終了し、受信しない場合には、上記ステップＳＴ３３の処理に戻り上記の処理を繰り返す。

ネットワーク構成検出部１４の検出結果により、テスト用ストリームの配信プロトコルが利用不可能なネットワークにおいて、受信装置４から「ｐｌａｙ」コマンドを受けると、メディア中継部１５にてカメラ３の映像データの配信プロトコルを変更して配信する必要が出てくる。

図９はメディア中継部１５の配信プロトコルを変更する場合のストリームの中継処理の流れを示すフローチャートである。図９のステップＳＴ３１〜ＳＴ３３，ＳＴ３６の処理は、図８のステップＳＴ３１〜ＳＴ３３，ＳＴ３６の処理と同じである。

図９のステップＳＴ３３で、メディア中継部１５は、カメラ３からの映像データを受信すると、ステップＳＴ４１において、メディア中継部１５は、カメラ３の映像データの配信プロトコルをそのまま中継することができないので、受信した映像データのパケットから映像データ部分を取り出して、別の配信プロトコルに変更し、ＩＰパケットの宛先のＩＰアドレスとポート番号を入手した受信装置４のＩＰアドレスとポート番号に変更する。ステップＳＴ４２において、メディア中継部１５は、配信プロトコルを変更した映像データを受信装置４に配信する。

図１０はＲＴＰのパケットの構成を示す図である。メディア中継部１５は受信したＲＴＰパケットを解析してＲＴＰペイロード部分から映像データを取り出す必要があるが、通常の場合、ＲＴＰヘッダを取り出して「ｐａｙｌｏａｄ ｔｙｐｅ」からＲＴＰペイロードの内容を判断する。また、「ｓｅｑｕｅｎｃｅ ｎｕｍ」を解析して、その順にＲＴＰペイロード部分を組み立てることによって、カメラ映像の映像データを順次取り出していく。メディア中継部１５は取り出した映像データの配信プロトコルを変更して受信装置４に配信する。この場合の映像データの配信プロトコルはＨＴＴＰを用いることにより、端末側ＩＰネットワークのファイアウォール２等の設定を変更することなく、映像データの配信が可能となる。

以上のように、この実施の形態１によれば、ネットワーク構成検出部１４は端末側ＩＰネットワーク２００のネットワーク構成がカメラの配信プロトコルを利用できるか否かを検出し、メディア中継部１５は、ネットワーク構成検出部１４の検出結果に基づき配信プロトコルを決定して、カメラ３からの映像データを端末側ＩＰネットワーク２００を介して受信装置４に配信することにより、接続するネットワークの数だけ必要としないインターネットゲートウェイを得ることができるという効果が得られる。

この発明の実施の形態１によるインターネットゲートウェイの構成を示すブロック図である。 この発明の実施の形態１によるインターネットゲートウェイを利用した監視映像配信システムにおける典型的なネットワーク構成例を示す図である。 この発明の実施の形態１によるインターネットゲートウェイが受信装置から受信する要求と応答の例を示す図である。 この発明の実施の形態１によるインターネットゲートウェイのカメラ情報テーブルの例を示す図である。 この発明の実施の形態１によるインターネットゲートウェイのネットワーク構成検出部のネットワーク構成の検出処理の流れを示すフローチャートである。 この発明の実施の形態１によるインターネットゲートウェイが受信するＩＣＭＰメッセージの構成を示す図である。 この発明の実施の形態１において受信端末の端末側ＩＰネットワークのネットワーク構成の検出処理の流れを示すフローチャートである。 この発明の実施の形態１によるインターネットゲートウェイのメディア中継部の配信プロトコルを変更しない場合のストリームの中継処理の流れを示すフローチャートである。 この発明の実施の形態１によるインターネットゲートウェイのメディア中継部の配信プロトコルを変更する場合のストリームの中継処理の流れを示すフローチャートである。 この発明の実施の形態１によるインターネットゲートウェイが中継するＲＴＰのパケットの構成を示す図である。

符号の説明

１ インターネットゲートウェイ、２ ファイアウォール、３ カメラ、４ 受信装置、１１ ネットワークインタフェース部、１２ カメラ情報テーブル、１３ メディア制御部、１４ ネットワーク構成検出部、１５ メディア中継部、１００ カメラ側ＩＰネットワーク、２００ 端末側ＩＰネットワーク。

Claims (2)

1. カメラの映像データをカメラ側ＩＰネットワークを介して受信し、受信した映像データを、ファイアウォールを経由したネットワーク構成の端末側ＩＰネットワークを介して映像データを要求した受信装置に配信するインターネットゲートウェイにおいて、
   上記受信装置からの要求を解釈するメディア制御部と、
   上記カメラの配信プロトコル等のカメラ情報を保持するカメラ情報テーブルと、
   上記受信装置からの要求を解釈した上記メディア制御部の指示に基づき、上記カメラ情報テーブルに保持されたカメラ情報を検索して上記カメラの配信プロトコルを入手し、入手した上記カメラの配信プロトコルがＲＴＰ（Real-Time Protocol）の場合に、ＵＤＰ（User Datagram Protocol）でデータ部分のないパケットによりテスト用ストリームを作成して上記端末側ＩＰネットワークを介して上記受信装置に配信し、上記受信装置からのＨＴＴＰの正常応答又は上記端末側ＩＰネットワークからのエラー通知により、上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できるか否かを検出するネットワーク構成検出部と、
   上記カメラからカメラ側ＩＰネットワークを介して配信された映像データを受信し、上記ネットワーク構成検出部により上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できると検出された場合には上記ＲＴＰを変更せずに上記映像データを上記端末側ＩＰネットワークを介して上記受信装置に配信し、上記ネットワーク構成検出部により上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できないと検出された場合には上記ＲＴＰをＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に変更して上記映像データを上記端末側ＩＰネットワークを介して上記受信装置に配信するメディア中継部とを備えたことを特徴とするインターネットゲートウェイ。
2. 上記ネットワーク構成検出部は、予め設定された設定時間内に上記受信装置からの上記正常応答又は上記端末側ＩＰネットワークからの上記エラー通知がない場合に、上記端末側ＩＰネットワークのネットワーク構成が上記ＲＴＰを利用できないことを検出することを特徴とする請求項１記載のインターネットゲートウェイ。

Images