JP6376724B2 - ファクシミリ装置、制御方法及びプログラム - Google Patents

Description

本発明は、ファクシミリ装置、制御方法及びプログラムに関する。

近年、ＩＰ網を利用してファクシミリ（以下、ＦＡＸという）通信を行う方法が確立されてきている。ＩＰ網を利用したＦＡＸ通信においては、呼接続プロトコルにはＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、データ通信にはＴ．３８プロトコルが使用される。ＩＰ網を利用したＦＡＸは、ＩＰ網を介して通信を行うため、従来のＧ３ＦＡＸと比べて高速な通信が可能になっている。そして、これらＳＩＰ及びＴ．３８に対応したインターネットファクシミリ装置（以下、ＩＰＦＡＸという）も販売されてきている。
また、ＳＩＰ及びＴ．３８準拠のＩＰＦＡＸと従来のＧ３ＦＡＸとが通信が可能なように、Ｇ３ＦＡＸのアナログＦＡＸ信号をリアルタイムにＴ．３８プロトコルに変換するＴ．３８ゲートウェイ（以下、Ｔ．３８ＧＷという）も販売されている。
Ｔ．３８通信はトランスポート層にＴＣＰ／ＴＰＫＴ又はＵＤＰ／ＵＤＰＬＴのプロトコルを使用する。
ここで、ＴＣＰ／ＴＰＫＴは、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ Ｐａｃｋｅｔの略である。また、ＵＤＰ／ＵＤＰＬＴは、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ／ＵＤＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌの略である。

ＩＰＦＡＸ通信を行う環境の仕様により以下のようにＴ．３８で使用可能なプロトコルが決まっている。
・公衆ＩＰ網 ：ＴＣＰ／ＴＰＫＴ、ＵＤＰ／ＵＤＰＴＬ
・構内ＩＰ網Ａ（所定の交換機利用時） ：ＵＤＰ／ＵＤＰＴＬ
・構内ＩＰ網Ｂ（Ｐ２Ｐ利用時） ：ＴＣＰ／ＴＰＫＴ、ＵＤＰ／ＵＤＰＴＬ
・Ｔ．３８ＧＷ ：ＵＤＰ／ＵＤＰＴＬ
ここで所定の交換機とは、ＳＩＰサーバを備え、構内ＩＰ網において相手先電話番号から接続先アドレス解決をしてくれる構内ＩＰ交換機である。また、Ｐ２ＰとはＩＰ網上で端末どうしを直接接続し、お互いのＩＰアドレスを用いてデータを送受信する通信方式である。
ＴＣＰ／ＴＰＫＴ、ＵＤＰ／ＵＤＰＬＴプロトコル共に、ＩＦＰパケットサイズを大きくしてパケット数を減らした方が、ネットワークに送出される余分なヘッダ部のデータが減るため、スループットが向上する。また、ＵＤＰ／ＵＤＰＴＬの場合はエラーリカバリ用の冗長パケットの数を増やしたほうがパケットロスに対する耐性は高まる。しかし、あまり増やしすぎるとスループットの低下が起きてしまうため、リアルタイム性が損なわれてしまう恐れがある。
このため、Ｔ．３８通信が行われる環境に従って適切にパケットサイズを決定することが重要である。

パケットサイズの決定方法に関するＧＷ装置及びルーター装置の先行技術として特許文献１がある。特許文献１では、音声通話等のリアルタイム通信時のパケット遅延時間を小さくすると同時に、ファイル転送等データ通信に代表される非リアルタイム通信におけるスループットを向上させることを目的としている。そのため、特許文献１では、リアルタイム通信時はパケットを分割して送信する技術が提案されている。

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

Ｔ．３８に準拠したＩＰＦＡＸとＧ３ＦＡＸとで通信を行うために使用されるＴ．３８ＧＷの中にはＧＷが受信可能なパケットサイズに制限があるものが存在する。より具体的にはパケットの全体サイズが３２０ｂｙｔｅ未満であること、かつ、ＩＦＰパケットのサイズが１２８ｂｙｔｅ未満であること、という制限である。
このため、上記パケットサイズの制限を満たさないパケットはＴ．３８ＧＷ側で破棄されてしまい、正常にＩＰＦＡＸ通信が行えないという問題がある。先に示した先行技術にはこれらのデータ部によるサイズ制限に関してパケットサイズを調整する等は言及されていない。
なお、Ｔ．３８ＧＷとの通信時にＴ．３８で使用可能なトランスポート層のプロトコルは通常ＵＤＰ／ＵＤＰＴＬである。音声通話で使用されるＶｏＩＰＧＷ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ Ｇａｔｅｗａｙ）の場合、ＶｏＩＰでは多少パケットロスが発生しても問題ないため、通常はＵＤＰが使用される。Ｔ．３８ＧＷはＶｏＩＰＧＷのバリエーションであるため、Ｔ．３８ＧＷでも通常はＵＤＰが使用される。
したがって、上記サイズ制限をクリアするためには、ＵＤＰＴＬのＩＦＰパケットサイズを小さくし、かつ、エラーリカバリ用の冗長パケット数を減らす等してパケット化を行えばよい。しかし、接続先によらず一律にパケットサイズを小さくしてしまうと、相対的にネットワークに送出するヘッダ部のデータ量が増加してしまい、Ｔ．３８ＧＷ以外の環境でスループットが低下してしまう。また、エラーリカバリ用の冗長パケット数が少ないとパケットロスに対する耐性も低下してしまう問題がある。

本発明はこのような問題点に鑑みなされたもので、ＩＰネットワーク上でリアルタイムにＦＡＸ通信を行うためのプロトコルのゲートウェイに対しては正常に通信が行えるようにすることを目的とする。また、更に、前記ゲートウェイ以外の接続先に対してはスループット及びパケットロスへの耐性を低下させないことを目的とする。

そこで、本発明のファクシミリ装置は、ＩＰ網に接続するためのインターフェースと、前記インターフェースを介してパケットを送信することでファクシミリ通信を実行する通信手段と、前記ファクシミリ通信のためのパケットの送信先が、前記ＩＰ網を介して受信したパケットをアナログ信号に変換してアナログ網に送信するゲートウェイ装置であるか否かを判定する判定手段と、前記判定手段により送信先が前記ゲートウェイ装置であると判定された場合、前記通信手段により前記インターフェースを介して送信されるパケットのサイズを、前記ゲートウェイ装置により受信可能なサイズとするよう制御する制御手段と、を有することを特徴とする。

本発明によれば、ＩＰネットワーク上でリアルタイムにＦＡＸ通信を行うためのプロトコルのゲートウェイに対しては正常に通信が行えるようにすることができる。また、更に、前記ゲートウェイ以外の接続先に対してはスループット及びパケットロスへの耐性を低下させないことができる。

Ｔ．３８に準拠したＩＰＦＡＸのハードウェア構成とＩＰＦＡＸを含むシステムのシステム構成の一例を示す図である。 パケット構造の一例を示す図である。 宛先表のデータ構造を示した一例を示す図である。 新規宛先が入力された際に、接続先種別を決定するための優先設定の一例を示す図である。 Ｔ．３８パケットサイズの決定処理の一例を示すフローチャートである。 パケット生成及びパケット送信を示す処理の一例を示すフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。

＜実施形態１＞
図１は、Ｔ．３８に準拠したＩＰＦＡＸのハードウェア構成とＩＰＦＡＸを含むシステムのシステム構成の一例を示す図である。
Ｔ．３８に準拠したＩＰＦＡＸ１ ３０１は、構内ＩＰ網５０１に接続されている。
ＩＰＦＡＸ１ ３０１はＳＩＰサーバ５０３を介してＴ．３８に準拠したＩＰＦＡＸ２ ５０２と通信可能である。
Ｔ．３８ＧＷ５０４は、モデムを内蔵しており、受信したＴ．３８パケットからＩＦＰパケットに含まれるＦＡＸの制御信号情報、及び画像の符号化データを取り出し、モデムを使って変調しアナログのＦＡＸ信号に変換する。また、Ｔ．３８ＧＷ５０４は、受信したアナログのＦＡＸ信号をモデムによりデジタルデータに復調して取り出し、Ｔ．３８パケットに変換する。
構内ＩＰ網５０１は、Ｔ．３８ＧＷ５０４を介して公衆電話網（ＰＳＴＮ）５０５と接続される。
Ｇ３ＦＡＸ５０６は、アナログのＦＡＸ通信のみに対応した端末であり、ＰＳＴＮ５０５に接続されている。
ＩＰＦＡＸ１ ３０１は、Ｔ．３８ＧＷ５０４を介してＧ３ＦＡＸ５０６と通信可能である。

ＩＰＦＡＸ１ ３０１は、画像の入出力機能を有するものであり、紙原稿の入力及び紙への印刷出力を行うものである。
ＩＰＦＡＸ１ ３０１は、入力した画像情報を紙に印刷したり、デジタルデータとして保存したりＩＰ網やＦＡＸを経由して他の機器へ転送したりすることもできる。
ＩＰＦＡＸ１ ３０１は、構内ＩＰ網５０１に常時接続して、他の画像処理装置やＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やサーバと一緒に運用されることが一般的である。
ＩＰＦＡＸ１ ３０１は、ＰＣからのプリントデータや、他の端末からの画像情報を受信し、紙へ印刷出力することができる。
ＩＰＦＡＸ１ ３０１は、ユーザーインターフェース（以下、ＵＩという）３０２を介したユーザーからの指示に応じた処理も行うことができる。

ＩＰＦＡＸ１ ３０１の内部構成を説明する。
ＩＰＦＡＸ１ ３０１は、商用電源に接続され電源部３１５よりＩＰＦＡＸ１ ３０１内部に電力を供給し動作する。
バス３１０は、スキャナＩ／Ｆ制御部３０７、ＣＰＵ３１４、ＲＯＭ３１１、ＲＡＭ３１２、ＨＤＤ３１３、プリンタＩ／Ｆ制御部３０５、ＵＩ制御部３０３、画像処理部３０８、ネットワークＩ／Ｆ制御部３０９を電気信号で接続しデータ伝送することができる。バス３１０は、ＣＰＵ３１４からの制御信号や各ユニット間のデータ信号が送受信されるシステムバスとして利用される。

ＣＰＵ３１４は、ＩＰＦＡＸ１ ３０１の制御ソフトウェアプログラムをＲＯＭ３１１やＨＤＤ３１３から読み込みＲＡＭ３１２に展開して実行し装置全体の制御を行う。
ＲＯＭ３１１は、リードオンリーメモリであり、装置のブートプログラムや固定パラメータ等が格納されておりフラッシュメモリが用いられることが多い。
ＲＡＭ３１２は、ランダムアクセスメモリの機能を持ち半導体メモリが接続されており、ＣＰＵ３１４がＩＰＦＡＸ１ ３０１を制御する際の一時的な作業データや画像データや印刷データの格納等に使用される。
ＨＤＤ３１３は、ハードディスクドライブであり、画像データ、印刷データ、宛先登録情報の格納等、様々なデータの格納に使用される。
また、ＲＡＭ３１２、ＨＤＤ３１３は、ＣＰＵ３１４が画像データの画像処理や符号化復号化や解像度変換の作業を行う作業領域としても使用される。

画像処理部３０８は、画像データを高画質化する画像処理や解像度変換や符号化復号化をハードウェアで行うものである。
また、ＲＡＭ３１２、ＨＤＤ３１３は、ＣＰＵ３１４が伝送するデータの符号化復号化やＩＰパケットを処理する作業を行う作業領域としても使用される。
ＵＩ制御部３０３は、ＵＩ３０２を制御し、各種情報の表示、ユーザーからの指示入力を行う。
プリンタＩ／Ｆ制御部３０５は、プリンタ３０４を制御する装置である。
スキャナＩ／Ｆ制御部３０７は、スキャナ３０６を制御する装置である。
ネットワークＩ／Ｆ制御部３０９は、構内ＩＰ網５０１とのデータの送受信を制御し、ＴＣＰやＵＤＰ等のＩＰパケットの解析や生成を行う。
ＩＰパケットの送受信により送信或いは受信するデータは一旦、ＲＡＭ３１２やＨＤＤ３１３に保存された後、ＣＰＵ３１４で解釈されてプロトコル規定に従って処理される。
またＩＰＦＡＸ１ ３０１は、ネットワークＩ／Ｆ制御部３０９及び構内ＩＰ網５０１を経由して、ＳＩＰセッションを利用して相手機との呼接続及びデータ通信を行うことができる。
ＣＰＵ３１４は、構内ＩＰ網５０１からネットワークＩ／Ｆ制御部３０９でＴ．３８パケットを受信して解析を行う。

ＩＰＦＡＸ１ ３０１がＴ．３８でＦＡＸ通信を行う時のデータの流れを説明する。
ＳＩＰサーバ５０３には予め電話番号とその番号が示す接続先ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）との対応が登録されているものとする。ここでＵＲＩとはＩＰ網上での相手先アドレスを示す識別子の事である。
はじめにＩＰＦＡＸ１ ３０１がＩＰＦＡＸ２ ５０２とＩＰＦＡＸ通信を行う場合について説明する。
ＣＰＵ３１４は、スキャナＩ／Ｆ制御部３０７を通じてスキャナ３０６を動作させて原稿の読み込みを行い、画像データを取得する。
画像データの取得が終わると、ネットワークＩ／Ｆ制御部３０９にて、ＳＩＰサーバ５０３に対してＳＩＰの接続要求（ＩＮＶＩＴＥ信号）が送信される。
ＳＩＰサーバ５０３ではそのＩＮＶＩＴＥ信号を受信し、ＩＮＶＩＴＥ信号に含まれる相手先電話番号から対応するＵＲＩを検索し、一致したＵＲＩ（ここではＩＰＦＡＸ２ ５０２）に対してＩＮＶＩＴＥ信号を転送する。

ＩＰＦＡＸ２ ５０２は、このＩＮＶＩＴＥ信号を受信可能であれば２００ＯＫ信号をＳＩＰサーバ５０３経由でＩＰＦＡＸ１ ３０１へ送信する。
これによりＩＰＦＡＸ１ ３０１とＩＰＦＡＸ２ ５０２との間で呼が張られたことになる。
その後、ＣＰＵ３１４は、スキャンした画像データを画像処理部３０８にてＪＢＩＧ等の符号化データに変換する。
そして符号化データはネットワークＩ／Ｆ制御部３０９でＴ．３８パケットに変換され構内ＩＰ網５０１を経由してＩＰＦＡＸ２ ５０２へ転送される。
また、ＩＰＦＡＸ２ ５０２から送出されたＴ．３８パケットは構内ＩＰ網５０１を経由してネットワークＩ／Ｆ制御部３０９に到達し、符号化されたデジタルの画像データが取り出されＣＰＵ３１４へ送られる。
ＣＰＵ３１４は、ＪＢＩＧ等で符号化されたデジタル画像データを生の画像データに復号化し受信データとしてプリンタＩ／Ｆ制御部３０５へ送りプリンタ３０４でプリントさせる。

次に、ＩＰＦＡＸ１ ３０１がＧ３ＦＡＸ５０６とＦＡＸ通信を行う場合について説明する。
ＣＰＵ３１４は、スキャナＩ／Ｆ制御部３０７を通じてスキャナ３０６を動作させて原稿の読み込みを行い、画像データを取得する。
画像データの取得が終わると、ネットワークＩ／Ｆ制御部３０９にて、Ｔ．３８ＧＷ５０４に対してＩＮＶＩＴＥ信号が送信される。
それを受けＴ．３８ＧＷ５０４は、ＩＮＶＩＴＥ信号から宛先の電話番号を取得し、ＰＳＴＮ５０５にダイヤルを行う。
Ｇ３ＦＡＸ５０６は、着信を受けると着呼し回線を閉結する。
Ｔ．３８ＧＷ５０４は、このことを検知するとＩＮＶＩＴＥ信号に対する２００ＯＫを、構内ＩＰ網５０１を介してＩＰＦＡＸ１ ３０１へ送信する。
これによりＩＰＦＡＸ１ ３０１とＧ３ＦＡＸ５０６との間に呼が張られた状態になる。

ＣＰＵ３１４は、スキャンした画像データを画像処理部３０８にてＪＢＩＧ等の符号化データに変換する。
そして符号化データはネットワークＩ／Ｆ制御部３０９でＴ．３８パケットに変換され、Ｔ．３８ＧＷ５０４に送信される。
このときのＴ．３８パケットはＴ．３８ＧＷ５０４の仕様に合わせてＵＤＰ／ＵＤＰＴＬに従う。
Ｔ．３８ＧＷ５０４は、受信したＴ．３８パケットを解析してＩＦＰパケット部のデータを取り出す。更にＴ．３８ＧＷ５０４は、そのデータを内蔵しているモデムを使ってＴ．３０のアナログＦＡＸ信号にリアルタイムに変調する。変調されたアナログＦＡＸ信号は、ＰＳＴＮ５０５を介してＧ３ＦＡＸ５０６へ送出される。また、Ｇ３ＦＡＸ５０６から送出されたＴ．３０のアナログＦＡＸ信号は、ＰＳＴＮ５０５を介してＴ．３８ＧＷ５０４に送信される。

Ｔ．３８ＧＷ５０４では受信したアナログＦＡＸ信号を内蔵しているモデムを使ってリアルタイムに復調し、デジタルデータを取り出す。そして、Ｔ．３８ＧＷ５０４は、取り出したデータをＴ．３８パケットに変換し、構内ＩＰ網５０１経由でＩＰＦＡＸ１ ３０１に送出する。
送出されたＴ．３８パケットはネットワークＩ／Ｆ制御部３０９に到達し、ＣＰＵ３１４がそのパケットを解析する。ＣＰＵ３１４は、画像データであればそれを取り出し、ＪＢＩＧ等で符号化されたデジタル画像データを生の画像データに復号化して、受信データとしてプリンタＩ／Ｆ制御部３０５へ送り、プリンタ３０４でプリントさせる。

ＴＣＰ／ＴＰＫＴ、ＵＤＰ／ＵＤＰＴＬそれぞれは図２に示すパケット構造を持っており、次のような特徴がある。
ＴＣＰ／ＴＰＫＴではＩＰ網上でパケットロスが発生した場合でもパケットの再送が行われるため、データの欠損が起こらないというメリットがある。その反面、パケットの再送が発生するとそれによる遅延が起こるため、リアルタイム性に欠けるというデメリットがある。一方、ＵＤＰ／ＵＤＰＴＬはリアルタイム性を重視したプロトコルで、パケットロスが発生した場合でもパケットの再送は行われない。但し、パケットロスによるデータ欠損を防ぐために、既に送信したデータを後から送るパケットにエラーリカバリ用の冗長パケット２０３として付加して送信するという特徴がある。エラーリカバリ用の冗長パケット２０３は複数個付加することが可能になっており、付加した数まではパケットロスが発生してもデータ欠損を防ぐことが出来るようになっている。

Ｔ．３８のデータ（手順信号及び画像）は図２のＩＦＰパケット部２０１、２０２に入っている。ＩＦＰパケットサイズは通常約３００ｂｙｔｅ弱に設定される。これはＴ．３８通信がＥＣＭ（誤り訂正）モードの場合はデータがＨＤＬＣ（Ｈｉｇｈ−ｌｅｖｅｌ Ｄａｔａ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ｐｒｏｃｅｄｕｒｅ）に従ってフレーム分割化される事に基づく。つまり通常は、ＨＤＬＣの１フレーム単位（２５６ｂｙｔｅ＋ヘッダ部）でパケット化が行われる。非ＥＣＭモードの場合もＥＣＭに合わせて３００ｂｙｔｅ弱で区切りパケット化されたり、画像１ライン分の符号化データ毎にパケット化されたりすることが多い。

図３は、宛先表のデータ構造を示した一例を示す図である。
６０１は宛先の電話番号である。
６０２はＩＰＦＡＸの場合にＳＩＰのＩＮＶＩＴＥ信号を送信する接続先種別情報である。接続先種別６０２にはＳＩＰサーバを示す「Ｉｎｔｒａｎｅｔ」や、Ｐ２Ｐでの接続を示す「Ｉｎｔｒａｎｅｔ（Ｐ２Ｐ）」、Ｔ．３８ＧＷのアドレスを示す「Ｔ．３８ＧＷ」がある。Ｔ．３８ＧＷアドレスが複数登録可能な場合は接続先種別として「Ｔ．３８ＧＷ１」、「Ｔ．３８ＧＷ２」等が設定されても良い。
６０３はＦＡＸの通信の誤り訂正（ＥＣＭ）モードの有効・無効を示す情報である。
６０４は送信開始スピード情報である。
宛先表は電話帳の一例である。

図４は、新規宛先が入力された際に、接続先種別を決定するための優先設定（以下、優先リストという）の一例を示す図である。
優先リストには前方一致で検索に使用する番号条件４０３が登録されており、ＩＰＦＡＸ１ ３０１は、新規宛先が入力されるとその電話番号を優先順位４０１の一番高い方から順に検索していき、一致するものを探す。ＩＰＦＡＸ１ ３０１は、一致するものが見つかった場合は、その項目に登録されている接続先種別４０２を選択する。なお、ＩＰＦＡＸ１ ３０１は、優先リスト中のどの項目にも一致しなかった場合は、４０４の「不一致時の接続先」に決定する。
例えば、新規宛先として０３−４８１−０００１が入力されたとする。この場合、優先リストの２項目目に一致するので接続先は「Ｔ．３８ＧＷ２」となる。また、０３−１２３−０００２が入力された場合は、４項目目と一致するので接続先は「Ｉｎｔｒａｎｅｔ」になる。更に、６１１−０００３が入力された場合は、リストの何れにも一致しないため、接続先は不一致時の接続先として指定されている「Ｉｎｔｒａｎｅｔ」となる。

次に図５を使って、Ｔ．３８パケットサイズの決定に係る情報処理の一例を説明する。なお、送信先の判別方法はあくまで実施形態の１つを上げているだけなので、他の方法でも良い。
以下のフローチャートの処理はＣＰＵ３１４がＩＰＦＡＸ１ ３０１の制御ソフトウェアのプログラムをＲＯＭ３１１やＨＤＤ３１３から読み込みＲＡＭ３１２に展開して実行することで実現される。図６も同様である。
Ｓ１００において、ユーザーから宛先入力を受け付けたＵＩ３０２は、その情報をＣＰＵ３１４に送る。ＣＰＵ３１４は、宛先が宛先表から選択されたものか、電話番号のみ入力された新規宛先かを判定する。
宛先表から選択された場合はＳ１０１に進み、ＣＰＵ３１４は、宛先表に登録されている接続先種別情報を取得し、その情報を接続先の値としてＲＡＭ３１２に保存する。

Ｓ１００にてＵＩ３０２より伝えられた宛先が新規宛先であると判定された場合、ＣＰＵ３１４はＳ１０２に進む。Ｓ１０２にて、ＣＰＵ３１４は、ＨＤＤ３１３に保存されている優先リストを取得し、優先順位４０１の一番高いほうから順に新規宛先の電話番号の値と番号条件４０３の値とを前方一致で検索を行う。ＣＰＵ３１４は、一致する優先リストの項目を見つけると、接続先種別４０２の値を接続先の値としてＲＡＭ３１２に保存する。もし、優先リストの検索でどれも一致するものが見つからなかった場合は、ＣＰＵ３１４は、ＨＤＤ３１３に保存されている不一致時の接続先４０４の値を参照し、接続先の値としてＲＡＭ３１２に保存する。
次に、Ｓ１０３において、ＣＰＵ３１４は、Ｓ１０１又はＳ１０２にてＲＡＭ３１２に保存した接続先がＴ．３８ＧＷ５０４かどうかの判別を行う。Ｔ．３８ＧＷ５０４の場合は、Ｓ１０４において、ＣＰＵ３１４は、次に示す２つのパケットサイズ調整処理を実行する。１つ目は、ＣＰＵ３１４は、ＵＤＰＴＬのＩＦＰパケット部２０２のサイズが１２８ｂｙｔｅ未満（つまり予め設定されたサイズ未満）になるようにサイズＮを１２７ｂｙｔｅに決定する。更に２つ目として、ＣＰＵ３１４は、パケット全体２０４のサイズが３２０ｂｙｔｅ未満になるようにエラーリカバリ用の冗長パケット２０３の数を削減する。本実施形態においてＣＰＵ３１４は、冗長パケット数Ｍを３から１に削減する。
Ｓ１０３の判定で接続先がＴ．３８ＧＷ５０４でないと判定された場合はＳ１０５に進み、ＣＰＵ３１４は、パケットサイズの削減を行わず、次のようにパケットサイズ決定を行う。ＣＰＵ３１４は、ＩＦＰパケットサイズＮを、ＥＣＭの場合はＨＤＬＣのフレーム単位（３００ｂｙｔｅ弱）に、非ＥＣＭの場合は３００ｂｙｔｅに決定する。また、ＣＰＵ３１４は、ＵＤＰＴＬの場合の冗長パケット数Ｍは３に設定する。

図６は、パケット生成及びパケット送信を示す処理の一例を示すフローチャートである。
まずＳ２００において、ＣＰＵ３１４は、ＳＩＰの呼接続時に決定されたＴ．３８のトランスポート層のプロトコルがＴＣＰかＵＤＰかを判定する。ＴＣＰであればＳ２０１に進み、ＣＰＵ３１４は、図５の処理で決定されたＩＦＰパケットサイズＮに基づきＩＦＰパケットを生成する。
Ｓ２００の判定がＵＤＰであればＳ２０２に進み、ＣＰＵ３１４は、図５の処理で決定されたＩＦＰパケットサイズＮ及び冗長パケット数Ｍに基づきＩＦＰパケットの生成と、冗長パケットの生成と、を行う。
最後に、ＣＰＵ３１４は、生成されたパケットをネットワークに送出する（Ｓ２０３）。

以上により、接続先がＴ．３８ＧＷ５０４の場合はＧＷ側でパケットが破棄されず、正常に通信を行うことが可能になる。また、接続先がＴ．３８ＧＷ５０４以外の場合は必要以上にパケット分割を行わないのでスループットが低下しないように送信することが可能になる。更にＵＤＰＴＬのエラーリカバリ用の冗長パケット数も必要以上に削減せずに送信するため、パケットロスに対する耐性も低下しない。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

以上、上述した各実施形態によれば、ＩＰネットワーク上でリアルタイムにＦＡＸ通信を行うためのプロトコルのゲートウェイに対しては正常に通信が行えるようにすることができる。また、更に、前記ゲートウェイ以外の接続先に対してはスループット及びパケットロスへの耐性を低下させないことができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (15)

1. ＩＰ網に接続するためのインターフェースと、
   前記インターフェースを介してパケットを送信することでファクシミリ通信を実行する通信手段と、
   前記ファクシミリ通信のためのパケットの送信先が、前記ＩＰ網を介して受信したパケットをアナログ信号に変換してアナログ網に送信するゲートウェイ装置であるか否かを判定する判定手段と、
   前記判定手段により送信先が前記ゲートウェイ装置であると判定された場合、前記通信手段により前記インターフェースを介して送信されるパケットのサイズを、前記ゲートウェイ装置により受信可能なサイズとするよう制御する制御手段と、
   を有することを特徴とするファクシミリ装置。
2. 前記判定手段により送信先が前記ゲートウェイ装置でないと判定された場合、前記制御手段は、前記通信手段により前記インターフェースを介して送信されるパケットのサイズを、前記ゲートウェイ装置により受信できないサイズとすることが可能であることを特徴とする請求項１に記載のファクシミリ装置。
3. 前記ファクシミリ通信は、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）パケットを用いて通信するＵＤＰ通信であることを特徴とする請求項１又は２に記載のファクシミリ装置。
4. 前記通信手段は、前記インターフェースを介して、Ｉｎｔｅｒｎｅｔ Ｆａｃｓｉｍｉｌｅ Ｐｒｏｔｏｃｏｌ（ＩＦＰ）パケットが含まれるＵＤＰパケットを送信し、
   前記ゲートウェイ装置により受信可能なＵＤＰパケットは、第１のサイズ未満のサイズのＩＦＰパケットを含むものに制限されており、
   前記判定手段により送信先が前記ゲートウェイ装置であると判定された場合、前記制御手段は、更に、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットに含まれるＩＦＰパケットのサイズを、前記第１のサイズ未満とするよう制御することを特徴とする請求項３に記載のファクシミリ装置。
5. 前記ゲートウェイ装置により受信可能なＵＤＰパケットは、前記第１のサイズよりも大きい第２のサイズ未満のサイズのものに制限されており、
   前記判定手段により送信先が前記ゲートウェイ装置であると判定された場合、前記制御手段は、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットのサイズを、前記第２のサイズ未満とするよう制御することを特徴とする請求項４に記載のファクシミリ装置。
6. 前記判定手段により送信先が前記ゲートウェイ装置でないと判定され、かつ、前記ファクシミリ通信が誤り訂正モードの場合、前記制御手段は、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットに含まれるＩＦＰパケットのサイズを、ｈｉｇｈ−ｌｅｖｅｌ ｄａｔａ ｌｉｎｋ ｃｏｎｔｒｏｌ（ＨＤＬＣ）のフレーム単位のサイズとするよう制御することを特徴とする請求項４に記載のファクシミリ装置。
7. 宛先の電話番号を入力する入力部を更に有し、
   前記判定手段は、前記入力部に対して入力された電話番号に基づいて、送信先が前記ゲートウェイ装置であるか否かを判定することを特徴とする請求項１乃至６の何れか１項に記載のファクシミリ装置。
8. 宛先表を記憶する記憶部を更に有し、
   宛先が前記記憶部に記憶された前記宛先表から選択された場合は、前記判定手段は、前記宛先表に含まれる種別情報に基づいて、送信先が前記ゲートウェイ装置であるか否かを判定することを特徴とする請求項１乃至７の何れか１項に記載のファクシミリ装置。
9. ＩＰ網に接続するためのインターフェースと、
   前記インターフェースを介してＵｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）パケットを送信することで誤り訂正モードによるＩＰファクシミリ通信を実行する通信手段と、
   前記ＩＰファクシミリ通信のためのＵＤＰパケットの送信先が、前記ＩＰ網を介して受信したＴ．３８プロトコルのパケットをＧ３ファクシミリ信号に変換するＴ．３８ゲートウェイ装置であるか否かを判定する判定手段と、
   前記判定手段により送信先が前記Ｔ．３８ゲートウェイ装置であると判定された場合、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットのサイズを、前記ゲートウェイ装置により受信可能なサイズにするよう制御し、前記判定手段により送信先が前記ゲートウェイ装置でないと判定された場合、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットのサイズとして、前記Ｔ．３８ゲートウェイ装置により受信可能なサイズよりも大きいサイズを設定することが可能な制御手段と、
   を有することを特徴とするファクシミリ装置。
10. 前記通信手段は、前記インターフェースを介して、Ｉｎｔｅｒｎｅｔ Ｆａｃｓｉｍｉｌｅ Ｐｒｏｔｏｃｏｌ（ＩＦＰ）パケットを含むＵＤＰパケットを送信し、
    前記ゲートウェイ装置により受信可能なＵＤＰパケットは、第１のサイズ未満のサイズのＩＦＰパケットを含むものに制限されており、
    前記判定手段により送信先が前記Ｔ．３８ゲートウェイ装置であると判定された場合、前記制御手段は、更に、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットに含まれるＩＦＰパケットのサイズを、前記第１のサイズ未満とするよう制御することを特徴とする請求項９に記載のファクシミリ装置。
11. 前記ゲートウェイ装置により受信可能なＵＤＰパケットは、前記第１のサイズよりも大きい第２のサイズ未満のサイズのものに制限されており、
    前記判定手段により送信先が前記Ｔ．３８ゲートウェイ装置であると判定された場合、前記制御手段は、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットのサイズを、前記第２のサイズ未満とするよう制御することを特徴とする請求項１０に記載のファクシミリ装置。
12. 前記判定手段により送信先が前記Ｔ．３８ゲートウェイ装置でないと判定された場合、前記制御手段は、前記通信手段により前記インターフェースを介して送信されるＵＤＰパケットに含まれるＩＦＰパケットのサイズを、ｈｉｇｈ−ｌｅｖｅｌ ｄａｔａ ｌｉｎｋ ｃｏｎｔｒｏｌ（ＨＤＬＣ）のフレーム単位のサイズとするよう制御することを特徴とする請求項１０に記載のファクシミリ装置。
13. ＩＰ網に接続するためのインターフェースを有するファクシミリ装置の制御方法であって、
    ファクシミリ通信のためのパケットの送信先が、前記ＩＰ網を介して受信したパケットをアナログ信号に変換してアナログ網に送信するゲートウェイ装置であるか否かを判定する判定ステップと、
    前記判定ステップでパケットの送信先が前記ゲートウェイ装置であると判定された場合、前記インターフェースを介して送信されるパケットのサイズを、前記ゲートウェイ装置により受信可能なサイズとするよう制御する制御ステップと、
    を含む制御方法。
14. ＩＰ網に接続するためのインターフェースを有し、前記インターフェースを介してＵｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）パケットを送信することで誤り訂正モードによるＩＰファクシミリ通信を実行するするファクシミリ装置の制御方法であって、
    前記ＩＰファクシミリ通信のためのＵＤＰパケットの送信先が、前記ＩＰ網を介して受信したＴ．３８プロトコルのパケットをＧ３ファクシミリ信号に変換するゲートウェイ装置であるか否かを判定する判定ステップと、
    前記判定ステップで送信先が前記Ｔ．３８ゲートウェイ装置であると判定された場合、前記インターフェースを介して送信されるＵＤＰパケットのサイズを、前記Ｔ．３８ゲートウェイ装置により受信可能なサイズになるよう制御する制御ステップと、
    を含む制御方法。
15. コンピュータを、請求項１乃至１２の何れか１項に記載のファクシミリ装置の各手段として機能させるためのプログラム。

Images