JP2008252246A - 画像通信システム及び画像通信方法 - Google Patents

Abstract

【課題】ＩＰ電話サービスネットワークを利用したＦＡＸ画像データの通信において、通信品質を安定化させること。
【解決手段】本発明に係る画像通信システムは、送信側ＢＡＳと受信側ＢＡＳとを備える。送信側ＢＡＳは、ＲＴＰパケットの内容を解析し、画像データのＨＤＬＣフレーム内のプリアンブルを検出した場合、検出箇所を画像データの開始と判定する。また、送信側ＢＡＳは、画像データの開始以降、ＲＴＰパケットをＴＣＰパケットにプロトコル変換し、それを示すタグ情報をＴＣＰパケットに付与する。受信側ＢＡＳは、タグ情報が付与されたＴＣＰパケットを検出する。受信側ＢＡＳは、検出されたＴＣＰパケットからタグ情報を削除し、ＴＣＰ形式からＲＴＰ形式に戻すプロトコル変換を行う。
【選択図】図１

Description

本発明は、ＦＡＸ画像データを通信する画像通信システムに関する。特に、本発明は、ＩＰ電話サービスネットワークを利用した画像通信システムに関する。

公衆電話ネットワークでの使用を前提としたＧ３−ＦＡＸ（ファクシミリ）が知られている。そのＧ３−ＦＡＸ間で、ＩＰ電話サービスネットワークを利用して、みなし音声方式でＦＡＸ画像データの通信を行う技術が知られている（例えば特許文献１参照）。その場合、公衆電話ネットワークでの使用ではあり得ないパケット欠落・遅延が発生し、通信品質が著しく劣化する可能性がある。

ＩＰ電話サービスとは、ＩＰプロトコルベースのネットワークを利用する電話ネットワークの総称であり、途中のネットワークが通信事業者の専用ネットワークで閉じる場合とインターネットを経由する場合の主に二つに分けられる。専用ネットワークの場合は、ＩＰ電話サービス向けに一定のＱｏＳ（Quality of Service）を確保する手段（例えば、ＲＳＶＰ（Resource reSerVation Protocol））が存在する。しかしながら、インターネット経由の場合、インターネットでは基本的にどのデータも平等に扱われるという性質上、パケットの欠落・遅延の発生は免れない。

また、ＩＰ電話サービスで通常用いられるプロトコルである「ＲＴＰ（Real-Time Transport Protocol）」では、通信の信頼性よりもリアルタイム性が重視されている。そのＲＴＰの性質上、ＩＰ電話サービスネットワーク内のパケット欠落・遅延により、通信品質が著しく劣化する事がある。

但し、音声通話に関しては、リアルタイムな通話が実現されていれば、通信品質の劣化はある限度許容される傾向にある。しかしながら、画像通信がＩＰ電話サービスネットワークを利用したみなし音声方式で行われる場合は、そのＩＰ電話サービスネットワーク内のパケット欠落・遅延は致命的な欠点となる。

ＩＰ電話サービスネットワークを利用したみなし音声方式による画像通信は、公衆電話ネットワークが利用される場合と同様に、音声通話として扱われる。この時、ＦＡＸ画像データは当然ながら先頭から順番に流れるシーケンシャル・アクセスが前提であり、「ノイズによるエラー（欠落）」はともかくとして「データの一部だけ順序が入れ替わるエラー（遅延）」は想定外の現象となる。

以上に説明されたように、「ネットワークのＱｏＳ」及び「ＲＴＰの性質」の二点から、ＩＰ電話サービスネットワークは、Ｇ３−ＦＡＸ本来の画像品質確保において不利となる根本的な問題を抱える。

特許文献２には、ファクシミリ通信品質を向上させるためのゲートウェイが記載されている。そのゲートウェイは、揺らぎ吸収バッファを備えている。そのゲートウェイは、パケットの受信側がファクシミリ装置である場合、そのパケットを蓄積する揺らぎ吸収バッファのバッファ長を、音声通話時よりも長くする。また、そのゲートウェイは、揺らぎ吸収バッファから読み出したパケットを逆パケット化することにより再現したＰＩＸ情報（画像データ）を、そのプリアンブルを延長した後、ファクシミリ装置へ送信する。この場合、ゲートウェイに新規機能を追加する必要がある。

特許文献３には、インターネットプロトコルネットワークを介したファクシミリデータ伝送方法が記載されている。そのファクシミリデータ伝送方法は、（１）送信側ファクシミリ装置から呼設定時に送信される受信側ファクシミリ装置の電話番号から対応するＩＰアドレスへアドレス変換を行う過程と、（２）送信側ファクシミリ装置からファクシミリデータの送信を示す識別信号を受信した場合に、上記ＩＰアドレス先への中継装置に対し、フロー制御及び再送機能を有するＴＣＰコネクション確立要求を行う過程と、（３）ＴＣＰコネクションにより、上記ＩＰアドレス先への中継装置に対して、ファクシミリデータを伝送する過程と、を含む。

特開２００５−５７５０５号公報 特開２００６−１２１１７６号公報 特開２０００−２７８４７３号公報

本発明の目的は、ＩＰ電話サービスネットワークを利用したＦＡＸ画像データの通信において、通信品質を安定化させることができる技術を提供することにある。

以下に、［発明を実施するための最良の形態］で使用される番号・符号を用いて、［課題を解決するための手段］を説明する。これらの番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために括弧付きで付加されたものである。ただし、それらの番号・符号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明の第１の観点において、画像通信システム（１）が提供される。その画像通信システム（１）は、送信側ＢＡＳ（Broadband Access Server）（１３）と、受信側ＢＡＳ（２３）とを備える。

送信側ＢＡＳ（１３）は、第１検出部（１４）と第１変換部（１５）とを有する。第１検出部（１４）は、ＲＴＰ形式のパケット（５０）の内容を解析し、ＦＡＸ画像データのＨＤＬＣフレーム内のプリアンブル（４０）を検出した場合、その検出箇所をＦＡＸ画像データの開始と判定する。第１変換部（１５）は、ＦＡＸ画像データの開始の後、パケット（５０）をＲＴＰ形式からＴＣＰ形式へ変換するプロトコル変換を行う。更に、第１変換部（１５）は、プロトコル変換が実施されたことを示すタグ情報（６２）をＴＣＰ形式のパケット（６０）に付与する。

受信側ＢＡＳ（２３）は、第２検出部（２４）と第２変換部（２５）とを有する。第２検出部（２４）は、タグ情報（６２）が付与されたＴＣＰ形式のパケット（６０）を検出する。第２変換部（２５）は、検出されたパケット（６０）からタグ情報（６２）を削除し、検出されたパケット（６０）をＴＣＰ形式からＲＴＰ形式に戻すプロトコル変換を行う。

本発明によれば、ＩＰ電話サービスネットワーク（３０）を利用したＦＡＸ画像データの通信において、ＴＣＰ形式が用いられる。その結果、パケットの欠落や遅延に対する耐久性が向上する。すなわち、ＦＡＸ画像データの通信品質が安定化し、信頼性が向上する。また、送受信両側においてＧ３−ＦＡＸ（１１、２１）及び宅内ゲートウェイ（１２、２２）に新規機能を追加する必要がない。従って、システム導入にかかる費用を削減することができる。

本発明の第２の観点において、画像通信方法が提供される。その画像通信方法は、（Ａ）送信側ＢＡＳ（１３）において、ＲＴＰ形式のパケット（５０）の内容を解析し、画像データのＨＤＬＣフレーム内のプリアンブル（４０）を検出した場合、検出箇所を画像データの開始と判定するステップと、（Ｂ）送信側ＢＡＳ（１３）において、画像データの開始の後、パケット（５０）をＲＴＰ形式からＴＣＰ形式へ変換するプロトコル変換を行い、且つ、プロトコル変換が実施されたことを示すタグ情報（６２）をＴＣＰ形式のパケット（６０）に付与するステップと、（Ｃ）受信側ＢＡＳ（２３）において、タグ情報（６２）が付与されたＴＣＰ形式のパケット（６０）を検出するステップと、（Ｄ）受信側ＢＡＳ（２３）において、検出されたパケット（６０）からタグ情報（６２）を削除し、検出されたパケット（６０）をＴＣＰ形式からＲＴＰ形式に戻すプロトコル変換を行うステップと、を有する。

本発明によれば、ＩＰ電話サービスネットワークを利用したＦＡＸ画像データの通信において、パケットの欠落や遅延に対する耐久性を向上させることができる。その結果、ＦＡＸ画像データの通信品質が安定化し、信頼性が向上する。また、送受信両側においてＧ３−ＦＡＸ及び宅内ゲートウェイに新規機能を追加する必要がない。従って、システム導入にかかる費用を削減することができる。

添付図面を参照して、本発明の実施の形態に係る画像通信システム及び画像通信方法を説明する。

１．構成
図１は、本発明の実施の形態に係る画像通信システム１の構成を示すブロック図である。この画像通信システム１は、ＩＰ電話サービスネットワークを利用して、Ｇ３−ＦＡＸ間においてみなし音声方式でＦＡＸ画像データの通信を行う。

図１に示されるように、画像通信システム１は、送信側Ｇ３−ＦＡＸ１１、送信側宅内ゲートウェイ１２、送信側ＢＡＳ（Broadband Access Server）１３、受信側Ｇ３−ＦＡＸ２１、受信側宅内ゲートウェイ２２、受信側ＢＡＳ２３、及びＩＰ電話サービスネットワーク３０を備えている。送信側Ｇ３−ＦＡＸ１１は、送信側宅内ゲートウェイ１２を介して送信側ＢＡＳ１３に接続されている。一方、受信側Ｇ３−ＦＡＸ２１は、受信側宅内ゲートウェイ２２を介して受信側ＢＡＳ２３に接続されている。ＢＡＳは、ＩＰ電話サービス局設備である。送信側ＢＡＳ１３と受信側ＢＡＳ２３は、ＩＰ電話サービスネットワーク３０を介して互いに接続されている。

送信側Ｇ３−ＦＡＸ１１は、ＴＴＣ（Telecommunication Technology Committee）標準のＪＴ−Ｔ３０「一般電話交換網における文書ファクシミリ交換手順」などの規定に基づき製品化された通常のＧ３−ＦＡＸである。送信側宅内ゲートウェイ１２は、送信側Ｇ３−ＦＡＸ１１からの音声信号（画像通信はみなし音声方式）をＡ／Ｄ変換する。そして、送信側宅内ゲートウェイ１２は、得られたデジタルデータを、ＩＰ電話プロトコルであるＲＴＰ形式のパケットでネットワーク側へ送信する。以下、ＲＴＰ形式のパケットは、「ＲＴＰパケット」と参照される。ＲＴＰパケットとは、より詳細にはＲＴＰを実装したＵＤＰ（User Datagram Protocol）パケットである（後述される）。

受信側Ｇ３−ＦＡＸ２１は、送信側Ｇ３−ＦＡＸ１１と同様に、通常のＧ３−ＦＡＸである。受信側宅内ゲートウェイ２２は、ネットワーク側から受信したＲＴＰパケットをＤ／Ａ変換し、得られた音声信号（画像通信はみなし音声方式）を受信側Ｇ３−ＦＡＸ２１へ送信する。

これら送信側Ｇ３−ＦＡＸ１１、送信側宅内ゲートウェイ１２、受信側Ｇ３−ＦＡＸ２１、及び受信側宅内ゲートウェイ２２は従来のものと同様であり、それらに新規機能は追加されていない。本実施の形態によれば、画像品質を従来よりも安定化させるために、送信側ＢＡＳ１３及び受信側ＢＡＳ２３に新規機能が追加される。

送信側ＢＡＳ１３は、送信側宅内ゲートウェイ１２から送信されるＲＴＰパケット（ＲＴＰを実装したＵＤＰパケット）を受け取る。この送信側ＢＡＳ１３は、ＩＰ電話サービスネットワーク３０の種類及び規定に基づいた従来のＢＡＳとしての機能に加えて、次の機能を有する。つまり、送信側ＢＡＳ１３は、検出部１４及び変換部１５を備えている。検出部１４は、ＲＴＰパケットの内容を解析し、画像データのＨＤＬＣ（High-Level Data Link Control）フレーム内のプリアンブルを検出した場合、その検出箇所を画像データの開始と判定する機能を有する。変換部１５は、パケットをＲＴＰ形式からＴＣＰ（Transmission Control Protocol）形式にプロトコル変換を行う機能を有する。更に、変換部１５は、得られたＴＣＰ形式のパケット（以下、「ＴＣＰパケット」と参照される）に、送信側ＢＡＳ１３内でプロトコル変換が実施されたことを示すタグ情報を付与する機能を有する。

受信側ＢＡＳ２３は、ＩＰ電話サービスネットワーク３０の種類及び規定に基づいた従来のＢＡＳとしての機能に加えて、次の機能を有する。つまり、受信側ＢＡＳ２３は、検出部２４及び変換部２５を有している。検出部２４は、上述のタグ情報が付与されたＴＣＰパケットを検出する機能を有する。変換部２５は、検出されたＴＣＰパケットからタグ情報を削除し、ＴＣＰパケットをＲＴＰパケットに戻すプロトコル変換を行う機能を有する。

図２は、Ｇ３−ＦＡＸ画像データ（ＰＩＸ情報）のＨＤＬＣフレームの一例を示している（ＪＴ−Ｔ３０参照）。ＨＤＬＣフレームは、プリアンブル４０を有している。プリアンブル４０は、ＨＤＬＣフレームの先頭に位置する、クロック同期のためのトレーラ部分であり、「同期信号」とも呼ばれている。つまり、プリアンブル４０とは、信号の始まりを示す特定の信号のことである。ＴＴＣ標準ＪＴ−Ｔ３０では、ＰＩＸ情報のＨＤＬＣフレームは、「０１１１１１１０」のフラグシーケンスの連続と規定される。また、プリアンブル４０の持続時間は、１秒±１５秒と規定されている。本実施の形態において、上述の送信側ＢＡＳ１３の検出部１４が、このプリアンブル４０を利用して画像データの開始を判定する。

図３は、上述の送信側ＢＡＳ１３の変換部１５によるプロトコル変換を説明するための概念図であり、ＲＴＰを実装したＵＤＰパケット５０とＴＣＰパケット６０とのヘッダフォーマットの比較を示している。変換部１５は、ＵＤＰパケット５０のＵＤＰヘッダ５１をＴＣＰヘッダ６１にプロトコル変換する機能を有する。更に、変換部１５は、プロトコル変換が行われたことを示すタグ情報（変換タグ）６２を、ＴＣＰパケット６０に付与する。このタグ情報６２は、本実施の形態に係る送信側ＢＡＳ１３及び受信側ＢＡＳ２３においてのみ有効な独自の規格である。

尚、上述のプリアンブル４０を一部として有するＨＤＬＣフレームは、図３中の「データ」で示される箇所に格納されている。検出部１４がＲＴＰを実装したＵＤＰパケット５０を解析する際、このＵＤＰパケット５０中の「データ」部分を解析してプリアンプル４０を検出する。

２．動作
図１〜図３を参照して、本実施の形態に係る画像通信システム１の動作を説明する。ここでは、送信側Ｇ３−ＦＡＸ１１と受信側Ｇ３−ＦＡＸ２１との間で、みなし音声方式で画像通信（ＦＡＸ通信）が行われる。

まず、送信側Ｇ３−ＦＡＸ１１により画像データが取り込まれる。取り込まれた画像データは、音声信号で送信側宅内ゲートウェイ１２に送信される。その画像データ通信は、みなし音声方式で行われる。尚、画像データは、図２で示されたＨＤＬＣフレームとなっている。

次に、送信側宅内ゲートウェイ１２は、画像データ（音声信号）をＡ／Ｄ変換する。得られたデジタルデータは、ＩＰ電話プロトコルであるＲＴＰで送信側ＢＡＳ１３に送信される。つまり、送信側宅内ゲートウェイ１２は、図３で示されるＵＤＰパケット５０を送信側ＢＡＳ１３に送信する。

送信側ＢＡＳ１３の検出部１４は、受け取ったＵＤＰパケット５０を解析する。ＵＤＰパケット５０の「データ」にはＨＤＬＣフレームが格納されており、そのＨＤＬＣフレームには図２で示されたようにプリアンブル４０（同期信号）が含まれている。検出部１４は、ＨＤＬＣフレーム内のプリアンブル４０を検出した場合、その検出箇所を画像データの開始と判定する。画像データの開始後、変換部１５は、図３で示されたように、ＵＤＰパケット５０をＴＣＰパケット６０に変換するプロトコル変換を行う。この時、変換部１５は、送信側ＢＡＳ１３内でプロトコル変換が行われたことを示すタグ情報６２をＴＣＰパケット６０に付与する。得られたＴＣＰパケット６０は、ＩＰ電話サービスネットワーク３０へ送信される。

ＴＣＰパケット６０は、ＩＰ電話サービスネットワーク３０を経由して、受信側ＢＡＳ２３に到達する。

受信側ＢＡＳ２３の検出部２４は、タグ情報６２が付与されたＴＣＰパケット６０を検出する。検出部２４は、受け取ったＴＣＰパケット６０に含まれるタグ情報６２から、そのＴＣＰパケット６０が変換部１５のプロトコル変換により作成されたことを検出する。この場合、変換部２５は、そのＴＣＰパケット６０からタグ情報６２を削除し、また、ＴＣＰパケット６０をＵＤＰパケット５０に戻すプロトコル変換を行う。ＲＴＰを実装したＵＤＰパケット５０は、受信側宅内ゲートウェイ２２に送信される。

受信側宅内ゲートウェイ２２は、受け取ったＵＤＰパケット５０をＤ／Ａ変換し、画像データを取得する。得られた画像データは、音声信号で受信側Ｇ３−ＦＡＸ２１へ送信される。その画像データ通信は、みなし音声形式で行われる。

受信側Ｇ３−ＦＡＸ２１は、受け取った画像データに応じた画像を出力する。

図４は、送信側ＢＡＳ１３におけるパケット処理手順を示すフローチャートである。尚、送信側ＢＡＳ１３に実装されている従来のＩＰ電話セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）により、通信が確立しているとする。

まず、通話が開始される（ステップＳ１０）。その後、送信側ＢＡＳ１３の検出部１４は、送信側ＢＡＳ１３に流入するＲＴＰパケット（ＵＤＰパケット５０）の解析を開始する（ステップＳ１１）。検出部１４がＵＤＰパケット５０内にＦＡＸ送信を示すプリアンブル４０を検出した場合（ステップＳ１２；Ｙｅｓ）、変換部１５は、そのＵＤＰパケット５０をＴＣＰパケット６０に変換する（ステップＳ１３）。更に、変換部１５は、タグ情報６２をＴＣＰパケット６０に付与する（ステップＳ１４）。ＴＣＰパケット６０は、ＴＣＰにてＩＰ電話サービスネットワーク３０へ送信される（ステップＳ１５）。

一方、ＵＤＰパケット５０内にプリアンブル４０を検出しなかった場合（ステップＳ１２；Ｎｏ）、検出部１４は、そのＵＤＰパケット５０を通常の音声通話のパケットと判断する。従って、そのＵＤＰパケット５０は、ＲＴＰにてＩＰ電話サービスネットワーク３０へ送信される（ステップＳ１６）。

図５は、受信側ＢＡＳ２３におけるパケット処理手順を示すフローチャートである。受信側では、流入するパケットとして３種類を考慮する必要がある：即ち、（１）送信側ＢＡＳ１３でプロトコル変換されたＦＡＸ送信用のＴＣＰパケット６０、（２）通常の音声通話用のＵＤＰパケット５０（ＲＴＰパケット）、及び（３）それ以外のデータ通信（ＳＩＰ等）用のＴＣＰパケットである。

受信側ＢＡＳ２３は、パケットを受信する（ステップＳ２０）。受信側ＢＡＳ２３の検出部２４は、受信したパケットの解析を行い、そのパケットの種類を判別する（ステップＳ２１）。ＴＣＰパケットの場合（ステップＳ２２；Ｙｅｓ）、検出部２４は、そのＴＣＰパケットにタグ情報６２が付与されているかどうか判定する（ステップＳ２３）。タグ情報６２が付与されている場合（ステップＳ２３；Ｙｅｓ）、そのＴＣＰパケットは、送信側ＢＡＳ１３においてプロトコル変換されたＦＡＸ送信用のパケットである。従って、変換部２５は、そのＴＣＰパケット６０からタグ情報６２を削除する（ステップＳ２４）。更に、変換部２５は、ＴＣＰパケット６０をＵＤＰパケット５０に変換する（ステップＳ２５）。そのＵＤＰパケット５０は、ＲＴＰにて受信側宅内ゲートウェイ２２に送信される（ステップＳ２６）。

一方、受信したパケットがＴＣＰパケットでない場合（ステップＳ２２；Ｎｏ）、そのパケットは、そのままの形式で受信側宅内ゲートウェイ２２に送信される（ステップＳ２７）。また、タグ情報６２が付与されていないＴＣＰパケットの場合（ステップＳ２３；Ｎｏ）、そのＴＣＰパケットは、そのままの形式で受信側宅内ゲートウェイ２２に送信される（ステップＳ２７）。

３．効果
宅内ゲートウェイとＢＡＳとの間で信頼性が高いインフラ設備が利用されている場合、ＲＴＰによる画像データ通信の信頼性低下は、主にＩＰ電話サービスネットワーク通過時に発生する。何故なら、宅内ゲートウェイとＢＡＳとの間は１対１通信であり、著しい回線ノイズ等のエラー要因以外はパケット欠落・遅延は起こり難い環境にあるからである。それに対して、ＩＰ電話サービスネットワークでは、様々な宛先のパケットが同一経路を共用するため、パケット移送途中の欠落・遅延の発生は免れない。

本発明によれば、ＲＴＰによる画像データ通信は、宅内ゲートウェイとＢＡＳとの間で閉じる。そして、ＩＰ電話サービスネットワーク通過時にはＴＣＰを利用することにより、ＲＴＰによる信頼性低下を抑える事が可能となる。言い換えれば、ＴＣＰ形式を用いることにより、ＩＰ電話サービスネットワーク通過時のパケット欠落・遅延に対する耐久性が向上する。結果として、画像データの通信品質が安定化し、信頼性が向上する。

更に、本発明によれば、送受信両側においてＧ３−ＦＡＸ及び宅内ゲートウェイに新規機能を追加する必要がない。従って、システム導入にかかる費用を削減することができる。特に、エンドユーザにとって、導入費用の削減が見込める。ＢＡＳに本発明に係る新規機能を追加することにより、導入費用を削減しながら、通話品質を安定化させることが可能となる。

また、Ｇ３−ＦＡＸや宅内ゲートウェイはエンドユーザ宅に設置されるため、仮にこれらに障害が発生した時には、場合によってはエンドユーザ宅まで調査に訪問する必要が生じる。本発明によれば、Ｇ３−ＦＡＸ／宅内ゲートウェイからＢＡＳまでのシステムでは、サービス事業者にとって既知のプロトコル（ＩＰ電話におけるＳＩＰやＲＴＰ、データ通信におけるＴＣＰ等）に限定される。そこでは特殊なプロトコルは使用されない。想定外の障害に対する復旧作業は、調査が容易な自局設備（ＢＡＳ）内に留めることが可能である。従って、ユーザ・サポート体制の負担が軽減される。

図１は、本発明に係る画像通信システムの構成を示すブロック図である。 図２は、Ｇ３−ＦＡＸ画像データ（ＰＩＸ情報）のＨＤＬＣフレームの一例を示す概念図である。 図３は、ＲＴＰを実装したＵＤＰパケットからＴＣＰパケットへのプロトコル変換を示す概念図である。 図４は、送信側ＢＡＳにおけるパケット処理手順を示すフローチャートである。 図５は、受信側ＢＡＳにおけるパケット処理手順を示すフローチャートである。

符号の説明

１ 画像通信システム
１１ 送信側Ｇ３−ＦＡＸ
１２ 送信側宅内ゲートウェイ
１３ 送信側ＢＡＳ
１４ 検出部
１５ 変換部
２１ 受信側Ｇ３−ＦＡＸ
２２ 受信側宅内ゲートウェイ
２３ 受信側ＢＡＳ
２４ 検出部
２５ 変換部
３０ ＩＰ電話サービスネットワーク
４０ プリアンブル
５０ ＵＤＰパケット
５１ ＵＤＰヘッダ
６０ ＴＣＰパケット
６１ ＴＣＰヘッダ
６２ タグ情報

Claims (2)

1. 送信側ＢＡＳと、
   受信側ＢＡＳと
   を備え、
   前記送信側ＢＡＳは、
   ＲＴＰ形式のパケットの内容を解析し、画像データのＨＤＬＣフレーム内のプリアンブルを検出した場合、検出箇所を前記画像データの開始と判定する第１検出部と、
   前記画像データの開始の後、パケットをＲＴＰ形式からＴＣＰ形式へ変換するプロトコル変換を行い、且つ、前記プロトコル変換が実施されたことを示すタグ情報を前記ＴＣＰ形式のパケットに付与する第１変換部と
   を有し、
   前記受信側ＢＡＳは、
   前記タグ情報が付与された前記ＴＣＰ形式のパケットを検出する第２検出部と、
   前記検出されたパケットから前記タグ情報を削除し、前記検出されたパケットをＴＣＰ形式からＲＴＰ形式に戻すプロトコル変換を行う第２変換部と
   を有する
   画像通信システム。
2. （Ａ）送信側ＢＡＳにおいて、ＲＴＰ形式のパケットの内容を解析し、画像データのＨＤＬＣフレーム内のプリアンブルを検出した場合、検出箇所を前記画像データの開始と判定するステップと、
   （Ｂ）前記送信側ＢＡＳにおいて、前記画像データの開始の後、前記パケットをＲＴＰ形式からＴＣＰ形式へ変換するプロトコル変換を行い、且つ、前記プロトコル変換が実施されたことを示すタグ情報を前記ＴＣＰ形式のパケットに付与するステップと、
   （Ｃ）受信側ＢＡＳにおいて、前記タグ情報が付与された前記ＴＣＰ形式のパケットを検出するステップと、
   （Ｄ）前記受信側ＢＡＳにおいて、前記検出されたパケットから前記タグ情報を削除し、前記検出されたパケットをＴＣＰ形式からＲＴＰ形式に戻すプロトコル変換を行うステップと
   を有する
   画像通信方法。

Images