(57)【特許請求の範囲】
【請求項１】
コンピュータネットワークに接続され、パケット通信によってファクシミリ画像を送信するリアルタイム型インターネットファクシミリ装置において、
ネットワークトランスポートとしてＵＤＰを使用するときに送信する冗長パケット数を、通信中に任意に変更できるようにしたことを特徴とするリアルタイム型インターネットファクシミリ装置。
【請求項２】
画情報送信フェーズの冗長パケット数と画情報送信フェーズ以外のフェーズでの冗長パケット数を異なる数に設定し、画情報送信フェーズ以外のフェーズでの冗長パケット数をゼロとすることを特徴とする請求項１記載のリアルタイム型インターネットファクシミリ装置。
【請求項３】
受信側から受信が失敗したことを示す信号が送られてきたとき、冗長パケット数を増加させるようにしたことを特徴とする請求項１又は２記載のリアルタイム型インターネットファクシミリ装置。
【請求項４】
前記受信が失敗したことを示す信号はＲＴＮ信号であることを特徴とする請求項３記載のリアルタイム型インターネットファクシミリ装置。
【請求項５】
受信側から受信が成功したことを示す信号が送られてきたとき、冗長パケット数を低減させるようにしたことを特徴とする請求項１または２記載のリアルタイム型インターネットファクシミリ装置。
【請求項６】
前記受信が成功したことを示す信号はＭＣＦ信号であることを特徴とする請求項５記載のリアルタイム型インターネットファクシミリ装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、パケット通信網でＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）を使ってファクス情報の送受信を行うリアルタイム型インターネットファクシミリ装置に関する。
【０００２】
【従来の技術】
近年、インターネット上でやりとりする電子メールを用いて、ファクシミリ画情報を通信する通信システム（以下、「メール型インターネットファクシミリ通信システム」という。）が実用されるようになってきている。
【０００３】
このような通信システムについては、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）というインターネットに関する技術内容をまとめている組織から発行されているＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）２３０１〜２３０６により、その技術内容が規定されている。
【０００４】
しかしながら、このメール型インターネットファクシミリ通信システムでは、送信側ファクシミリ装置と受信側ファクシミリ装置が直接通信するわけではないので、ファクシミリ装置相互間における通信能力の確認が即時的に行えず、そのために、ファクシミリ装置の種々の機能（解像度、画像処理能力など）を利用した画情報通信を行えないという事態を生じる。
【０００５】
また、通信結果の通知も即時的に行えないので、送信側ユーザに通信結果が通知されるまで時間がかかり、再送信などの必要性が生じた場合の対処が遅れるという事態も生じる。
【０００６】
そこで、インターネットを利用したファクシミリ通信システムとして、インターネットを介してファクシミリ通信をリアルタイムに実現するリアルタイム型のインターネットファクシミリ通信システムが提案されつつある。
【０００７】
かかるリアルタイム型インターネットファクシミリ通信システムの提案の詳細は、ＩＴＵ−Ｔ勧告Ｔ．３８にまとまり公表されている。
【０００８】
このようなリアルタイム型インターネットファクシミリ通信システムでは、送信側リアルタイムインターネットファクシミリ装置は、受信側リアルタイムインターネットファクシミリ装置との間でリアルタイム性の高いファクシミリ通信を行うことができ、リアルタイムインターネットファクシミリ装置相互間における通信能力の確認がリアルタイムに行えるので、送信側リアルタイムインターネットファクシミリ装置は、受信側リアルタイムインターネットファクシミリ装置の通信能力に応じた画情報を送信できるとともに、通信結果を即時に得るので、再送動作などを迅速に行うことができる。
【０００９】
【発明が解決しようとする課題】
上記リアルタイム型インターネットファクシミリはインターネット上のＩＰパケット通信により従来のファクス同様の文書送信を行う装置であり、トランスポートとしてＴＣＰ／ＵＤＰ両方のサポートが必須機能となっていて、ＵＤＰ使用時には冗長パケットを送信してエラー回復を行う手順が規定されている。
【００１０】
しかし、その冗長パケットの使用方法が適切に規定されておらず、通信上の問題（通信の切断）を引き起こしていた。
【００１１】
例えば、図６は冗長パケット数を４個の場合のＵＤＰパケットの構成を示した図で、連続番号４５のヘッダを持つ主要メッセージが最初にセットされ、次に４個前までの送信パケットが冗長パケットとして添付されて、図７に示すように画情報送信時のエラー回復が行われる。
【００１２】
図７では１０番目と１２番目のＵＤＰパケットがネットワーク上で破棄され、その時の連続番号１０と１２の主要メッセージがエラー（相手端末に届かない状態）となったが、次の１１番目、１３番目のパケット到達によってエラー回復されている。
【００１３】
しかし、このように単純に前のパケットを付加して送信するだけでは、以下のようにプロトコル上の混乱を招いてしまう問題がある。
【００１４】
図４は、勧告Ｔ．３８で規定されている通信プロトコルの一例を示している。
これによると、仮にＴＳＩ／ＤＣＳパケットがネットワーク上で紛失すると、受信側ＲＴｉｆａｘはＤＩＳパケットを再送することになるが、その冗長パケットもＤＩＳ情報を持つことになる。
【００１５】
また、受信側からのＣＦＲパケットが紛失すると、送信側はＤＣＳパケットを再送するが、もしそのパケットが紛失すると、受信側はＣＦＲパケットを再送する。
【００１６】
しかし、その冗長パケットにはＤＩＳ情報（すでにフェーズ的に不要である）を持つ場合もあり、またＥＯＰパケットを受信後、受信ＲＴｉｆａｘはＭＣＦパケットを送信するが、その冗長パケット内容はＣＦＲやＤＩＳパケットを持つかもしれない。
【００１７】
このように冗長パケットによるエラー回復は極めて無意味な情報要素を再送するばかりでなく、プロトコル全体が破綻する危険性がある。
【００１８】
また、上述した問題は特に冗長パケットを勧告Ｔ．３０のコマンドシーケンス部分に適用した場合に顕著になり、この部分の解決方法が特に重要となっている。
【００１９】
また、画情報送受信フェーズにおいても、ＵＤＰパケットがネットワークにおいて破棄されると画情報の劣化となり、破棄が頻繁に発生すれば通信切断となる問題があり、冗長パケット数の最適化が必要となる。
【００２０】
また、通信が正常に進んでいる場合は見かけ上問題ないが、ネットワーク全体の負荷の観点から、不要な冗長パケットを送信している可能性があり、冗長パケット数の最適化が必要となる。
【００２１】
そこで、本発明は、付加する冗長パケット数を設定可能にして、信頼性の高い通信が行えるようにしたリアルタイム型インターネットファクシミリ装置を提供することを目的とする。
【００２２】
【課題を解決するための手段】
上記課題を解決するため、本願発明は、コンピュータネットワークに接続され、パケット通信によってファクシミリ画像を送信するリアルタイム型インターネットファクシミリ装置において、ネットワークトランスポートとしてＵＤＰを使用するときに送信する冗長パケット数を、通信中に任意に変更できるようにして、信頼性の高い通信が行えるようにしたことを特徴とする。
【００２３】
この場合、画情報送信フェーズの冗長パケット数と画情報送信フェーズ以外のフェーズでの冗長パケット数を異なる数に設定し、画情報送信フェーズ以外のフェーズでの冗長パケット数をゼロとして、勧告Ｔ．３０のフェーズＣ部分にのみ冗長パケットを付加することで、プロトコルの破綻の危険性や無意味な情報の再送を防ぐようにすることができる。
【００２４】
また、受信側からＲＴＮ信号が送られてきたとき、冗長パケット数を増加させるようにして、受信側でエラーが多発したときは、冗長パケット数を増やしてエラー回復機能を強化し、良好な通信を行うことができるようにしてもよい。
【００２５】
さらに、受信側からＭＣＦの信号が送られてきたとき、冗長パケット数を低減させるようにして、受信側でエラーが発生しないときに送信パケットを小さくしてネットワーク全体の負荷を小さくできるようすることもできる。
【００２６】
【発明の実施の形態】
本発明の実施の形態を図を参照して説明する。リアルタイム型インターネットファクシミリ通信の形態には、図１に示したように両端に通常のＧ３ファクスが接続されていて、公衆網（ＰＳＴＮ）とインターネットを経由して直接通信するいわゆるゲートウェイ型と、図１から両端のＧ３ファクスを除いて、図２のようにインターネットのみを介して２つの装置が通信するものがある。
【００２７】
図１及び図２ともインターネット上での通信プロトコルは同じでＩＴＵ−Ｔ勧告Ｔ．３８で規定されているが、図１の形態の通信では、両端のＧ３通信を保持するためにさまざまなプロトコル（勧告Ｔ．３０）上の工夫が必要となる。
【００２８】
そこで、本発明は図１、図２のいずれの形態にも適用可能になるように構成されていることを先ず付言する。
【００２９】
図２の通信機能（インターネットを経由した直接通信）を通常のＧ３ファクスに付加した装置の構成としては、例えば図３に示す構成が例示できる。
【００３０】
同図において、システム全体の制御を行うＣＰＵ１、当該ＣＰＵ１のプログラムが格納されているＲＯＭ２、プログラムが動作するのに必要な作業領域やテンポラリ記憶領域をなすＲＡＭ３、バッテリー等でバックアップされ、電源断に対して保証すべき情報を記憶するＳＲＡＭ４、システム全体で使用するタイマ制御（割り込み）の時間管理を行うタイマ制御５等を有している。
【００３１】
また、画情報の圧縮及び再生はＣＯＤＥＣ６で行われ、ファクシミリではＭＨ／ＭＲ／ＭＭＲ等が使用される。
【００３２】
通常、画情報はハードディスクＨＤ８に蓄積され、当該ハードディスクＨＤ８は、ハードディスクコントローラＨＤＣ７により制御されている。
【００３３】
そして、プログラムを実行するに当たり、操作部とのソフト的及びハード的なインターフェースは操作部ｉ／ｆ９で行い、ユーザーが実際に送信や登録等の操作は操作部１０で行う。
【００３４】
画情報はスキャナ１２で読取り、画情報を読込むに当たり、スキャナ１２とのソフト的及びハード的なインターフェースはスキャナｉ／ｆ１１により行なわれる。
【００３５】
画情報の印刷はプロッタ１４で行い、画情報を印刷するに当たり、プロッタ１４とのソフト的及びハード的なインターフェースはプロッタｉ／ｆ１３で行われる。
【００３６】
Ｇ３通信制御部１５には、通常ＣＰＵ／ＲＯＭ／ＲＡＭ等が実装されており、メインボード側（１〜７）とハード的及びソフト的なインターフェースをとって、画情報のやり取り等を行い、勧告Ｔ．３０手順に従ったプロトコルを制御する。
【００３７】
また網制御部１６は、ＰＳＴＮとの電気的なインターフェースをとり、Ｇ３通信制御部１５がＰＳＴＮ経由で相手側のＧ３ＦＡＸと通信できるようにする。
【００３８】
ＬＡＮ通信制御部１７は、通常ＣＰＵ／ＲＯＭ／ＲＡＭ等が実装されており、メインボード側（１〜７）とハード的及びソフト的なインターフェースをとって、画情報のやり取り等を行い、勧告Ｔ．３８手順に従ったプロトコルを制御する。
【００３９】
また、ここではＴＣＰ／ＵＤＰ／ＩＰプロトコルというインタ−ネットアクセスのためのプロトコル制御も行う。
【００４０】
ＬＡＮ制御部１８は、ＬＡＮとの電気的なインターフェースをとり、ＬＡＮ通信制御部１７がＬＡＮ経由で相手側のリアルタイム型インターネットファクシミリと通信することを可能にする。
【００４１】
図４は勧告Ｔ．３８で規定されている通信プロトコルの一例である。図２のファクシミリをＲＴｉｆａｘと表記している。
【００４２】
まず、送信側ＲＴｉｆａｘは、受信側ＲＴｉｆａｘに対し接続要求パケットを送信して接続要求し、それにより、受信側ＲＴｉｆａｘは、接続確認パケットを送信側ＲＴｉｆａｘへ送信して、呼接続を確認する。
【００４３】
これにより、送信側ＲＴｉｆａｘと受信側ＲＴｉｆａｘとの間の通信パスが確立するので、受信側ＲＴｉｆａｘは、ＩＴＵ−Ｔ勧告Ｔ．３０の所定のトーン信号ＣＥＤ（被呼局識別信号）に対応した信号（Ｔ３０ＩＮＤ：ＣＥＤ）を送信側ＲＴｉｆａｘへ送信するとともに、フラグ信号に対応した信号（Ｔ３０ＩＮＤ：Ｆｌａｇ）に続き、グループ３ファクシミリ伝送手順信号であり、自端末のオプション的な伝送機能を通知するための信号ＮＳＦ、自端末の識別信号を通知するための信号ＣＳＩ、および、自端末の標準的な伝送機能を通知するための信号ＤＩＳにそれぞれ対応する信号（Ｖ２１ＨＤＬＣ：ＮＳＦ／ＣＳＩ／ＤＩＳ）を、送信側ＲＴｉｆａｘへと順次送信する。
【００４４】
それにより、送信側ＲＴｉｆａｘは、受信側ＲＴｉｆａｘの識別信号および伝送機能を知るので、その通知された伝送機能に基づき、そのときに使用する伝送機能およびモデム速度などを設定する。
【００４５】
次いで、送信側ＲＴｉｆａｘは、フラグ信号に対応する信号（Ｔ３０ＩＮＤ：Ｆｌａｇｓ）に続き、グループ３ファクシミリ伝送手順信号であり、自端末の識別信号を通知するための信号ＴＳＩ、および、使用する伝送機能を通知するための信号ＤＣＳにそれぞれ対応する信号（Ｖ２１ＨＤＬＣ：ＴＳＩ／ＤＣＳ）を受信側ＲＴｉｆａｘへ送信する。
【００４６】
それにより、受信側ＲＴｉｆａｘは信号（Ｖ２１ＨＤＬＣ：ＴＳＩ／ＤＣＳ）を受信すると、相手端末（送信側ＲＴｉｆａｘ）の識別情報、および、そのときに使用する伝送機能を取得する。
【００４７】
そして、受信側ＲＴｉｆａｘは、フラグ信号に対応する信号（Ｔ３０ＩＮＤ：Ｆｌａｇｓ）に続き、グループ３ファクシミリ伝送手順信号であり、受信準備が完了した旨を通知するための信号ＣＦＲに対応する信号（Ｖ２１ＨＤＬＣ：ＣＦＲ）を送信側ＲＴｉｆａｘへ送信する。
【００４８】
このようにして、画情報の送信準備が整うと、送信側ＲＴｉｆａｘは、モデムのリトレーニングのためのトレーニング（Ｔｒａｉｎｉｎｇ）信号に対応した信号（Ｔ３０ＩＮＤ：Ｓｐｅｅｄ）を受信側ＲＴｉｆａｘへ送信し、続いて、送信画情報の画像データを複数に分割し、それぞれの分割された画情報をパケットデータ（図示では、「Ｖ．１７  ｎｏｎ  ＥＣＭ：Ｉｍａｇｅ  ｄａｔａ」と表示。）として、受信側ＲＴｉｆａｘへ送信する。
【００４９】
そして、画情報の送信を終了すると、フラグ信号に対応した信号（Ｔ３０ＩＮＤ：Ｆｌａｇｓ）を受信側ＲＴｉｆａｘへ送信するとともに、グループ３ファクシミリ手順信号であり画情報送信を終了する旨をあらわす信号ＥＯＰに対応した信号（Ｖ２１ＨＤＬＣ：ＥＯＰ）を受信側ＲＴｉｆａｘへ送信する。
【００５０】
一方、受信側ＲＴｉｆａｘは、信号（Ｔ３０ＩＮＤ：Ｓｐｅｅｄ）を受信すると、画情報の受信準備に移行し、画情報を運ぶパケットを受信すると、それに含まれている分割画情報を順次取り出し、連結した画情報を作成し、その画情報を、画像蓄積装置９へと蓄積する。また、画情報受信後の伝送後信号として、この場合には、信号（Ｖ２１ＨＤＬＣ：ＥＯＰ）を受信するので、画情報受信が終了する旨を確認する。
【００５１】
そして、受信側ＲＴｉｆａｘは、そのときの画情報の受信結果が良好な場合には、フラグ信号に対応した信号（Ｔ３０ＩＮＤ：Ｆｌａｇｓ）に続き、グループ３ファクシミリ手順信号であり画情報の受信が正常に終了した旨をあらわす信号ＭＣＦに対応した信号（Ｖ２１ＨＤＬＣ：ＥＯＰ）を送信側ＲＴｉｆａｘへ送信する。
【００５２】
それにより、送信側ＲＴｉｆａｘは、受信側ＲＴｉｆａｘで画情報を正常に受信されたことを認識する。この後は、送信側ＲＴｉｆａｘは、フラグ信号に対応した信号（Ｔ３０ＩＮＤ：Ｆｌａｇｓ）に続き、グループ３ファクシミリ手順信号であり回線復旧を指令するための信号ＤＣＮに対応した信号（Ｖ２１ＨＤＬＣ：ＤＣＮ）を受信側ＲＴｉｆａｘへ送信する。
【００５３】
そして、受信側ＲＴｉｆａｘは、信号（Ｔ３０ＩＮＤ：Ｆｌａｇｓ）および信号（Ｖ２１ＨＤＬＣ：ＤＣＮ）を受信すると、画情報受信動作を終了する。
【００５４】
そして、最後に、送信側ＲＴｉｆａｘは、通信パスを切断する旨を要求する切断通知パケットを受信側ＲＴｉｆａｘへ送出し一連の通信動作を終了する。
【００５５】
このようにして、送信側ＲＴｉｆａｘから受信側ＲＴｉｆａｘへの画情報の送信がなされる。
【００５６】
また、図５は、勧告Ｔ．３８でファクス画像をやり取りする場合のプロトコルスタックを示す図である。
【００５７】
勧告Ｔ．３０プロトコルは、モデム及び網制御装置等のＰＳＴＮ（電話回線）向けネットワークデバイスを経由してＰＳＴＮアクセスを実現し、ＩＰはＬＡＮ（Ｅｔｈｅｒｎｅｔ等）のネットワークドライバを経由してネットワークアクセスを実現する。勧告Ｈ．３２３呼制御手順は図４の接続要求及び応答パケットや切断通知パケットの手順を与える。
【００５８】
そして、プロトコルは、通常ソフトウェアとして実装され、ＲＯＭ２に書き込まれる。
【００５９】
図６は冗長パケットを含むＵＤＰパケットの構造を示し、図７はそれによって行われる画情報送信時のエラー回復を模式的に示したものである。
【００６０】
図６及び図７で示す冗長パケット数は４個であり、連続番号４５のヘッダ（実際にはＵＤＰパケットに含まれる）を持つ主要メッセージが最初にセットされ、次に４個前までの送信パケット（先に主要メッセージとして送信されたもの）が冗長パケットとして添付される。
【００６１】
従って、次に送信するＵＤＰパケットには連続番号４６のパケットが主要メッセージとしてセットされ、４２〜４５までのパケットが冗長パケットして添付されることになる。
【００６２】
図７では、１０番目と１２番目のＵＤＰパケットがネットワーク上で破棄され、その時の連続番号１０と１２の主要メッセージがエラー（相手端末に届かない状態）となったが、次の１１番目、１３番目のパケット到達によってエラー回復している。
【００６３】
このような構成において、ネットワークトランスポートとしてＵＤＰを使用するときに送信する冗長パケット数を通信中に任意に変更可能とする場合を図８を参照して説明する。
【００６４】
先ず、ユーザーの送信操作によって送信制御指示部が起動し（ステップＳ１）、Ｔ．３０信号／画情報生成部に勧告Ｔ．３０に準拠した情報を生成させると共に（ステップＳ２）、冗長パケット付加制御部に冗長パケット数（図７の例では４個）を通知する（ステップＳ３）。
【００６５】
そして、Ｔ．３０信号／画情報生成部で生成された情報は、ＵＤＰパケットの一部を形成するＴ．３８主要パケット生成部に送られ、勧告Ｔ．３８に準拠したメッセージフォーマットに変換されて（ステップＳ４）、Ｔ．３８ＵＤＰパケット生成部に送られる。
【００６６】
なお、この主要パケットは、次のＵＤＰパケットの冗長パケットとなるので、冗長パケット記憶部にも送られる（ステップＳ５）。
【００６７】
そして、Ｔ．３８ＵＤＰパケット生成部は最終的な送信パケットを生成するため、冗長パケット付加制御部に冗長パケット数を問い合わせ、冗長パケット記憶部から必要な数のパケットを得て、冗長パケットを付加し、ＵＤＰパケットを生成する（ステップＳ６）。
【００６８】
このようにして生成されたＴ．３８ＵＤＰパケットは、ネットワーク送信制御部に渡され、ＵＤＰ／ＩＰのプロトコルスタックに制御されて、ネットワークへの送信を行う（ステップＳ７）。
【００６９】
ところで、上記処理中に送信制御指示部が送信フェーズに従って適宜冗長パケット付加制御部に冗長パケット数を通知（変更）することで、通信中に任意に冗長パケット数を変更することができるようになる。
【００７０】
無論、通信中の変更だけでなく、例えば通信前にＰｉｎｇコマンドを送出し、その応答メッセージまでの時間を計測することで、冗長パケット数を適切な値に設定することも可能である。
【００７１】
また、図９に示すように、Ｔ．３８ＵＤＰパケット生成部自身がプロトコルフェーズを解析し、勧告Ｔ．３０のフェーズＣ（画情報転送フェーズ）以外の場合は、冗長パケット付加を行わないように制御することも可能である。
【００７２】
なお、図９は、図８におけるＴ．３８ＵＤＰパケット生成部の動作を示したフローチャートである。
【００７３】
即ち、Ｔ．３８主要パケット生成部から主要パケットを受信すると（ステップＳ１１）、フェーズＣ情報の有無が判断される（ステップＳ１２）。
【００７４】
そして、フェーズＣ情報が有る場合には、上述したように送信パケットを生成するため、冗長パケット付加制御部に冗長パケット数を問い合わせ（ステップＳ１３）、冗長パケット記憶部から必要な数のパケットを得て、冗長パケットを付加し、ＵＤＰパケットを生成する（ステップＳ１４）。
【００７５】
これにより生成されたＴ．３８ＵＤＰパケットは、ネットワーク送信制御部に渡され、ＵＤＰ／ＩＰのプロトコルスタックに制御されて、ネットワークへの送信を行う（ステップＳ１５）。
【００７６】
これにより、勧告Ｔ．３０のフェーズＣ部分にのみ冗長パケットを付加するよう制御することができて、プロトコルの破綻の危険性や無意味な情報の再送を防ぐことが可能となる。
【００７７】
なお、図１０に示すように、受信側からＲＴＮ（Ｒｅｔｒａｉｎ  Ｎｅｇａｔｉｖｅ）の信号が送られてきたとき付加する冗長パケット数を増加するようにしてもよい。
【００７８】
図１０は、図９に相当するフローチャートで当該図１０におけるＲＴＮ信号受信応答の有無の条件分岐の情報は、図８における送信制御指示部が設定するものとする。
【００７９】
ＲＴＮ信号とは、受信側でエラーが多発した場合に、そのページの受信が失敗したことを示す信号であり、通常は勧告Ｔ．３０のフェーズＢに戻って通信速度をシフトダウンするものである。
【００８０】
図２に示す形態の通信では、例えばＵＤＰトランスポート使用時の回線（Ｉｎｔｅｒｎｅｔ）状況が悪く、パケットの紛失が多発した場合に当該ＲＴＮ信号が送信され、図７の例で言えば、５個の連続するＵＤＰパケットが紛失した場合は、１個のパケットはエラー回復されない。
【００８１】
また、図１に示す形態では、さらに受信側Ｇａｔｅｗａｙと受信Ｇ３ＦＡＸ間の電話回線状況によってもＲＴＮ信号が送信される。
【００８２】
図１に示す形態の場合において、モデム通信速度のシフトダウンはエラーの原因が電話回線側にあるときは有効であるが、エラーの原因がＵＤＰトランスポートにあるときは当該シフトダウンは意味のないものとなってしまう。
【００８３】
そこで、このような場合には、図１０に示すフローチャートでは、図９に示した場合と同様にフェーズＣ以外の情報送信で冗長パケットは付加しないようになっている。
【００８４】
一方、プロトコルフェーズでＲＴＮ信号に受信応答している場合は、冗長パケット付加制御部から得た冗長パケット数を増加し、その数を通知すると共に冗長パケット記憶部から冗長パケットを獲得する。
【００８５】
即ち、図１０においてＴ．３８主要パケット生成部から主要パケットを受信すると（ステップＳ２１）、フェーズＣ情報の有無が判断される（ステップＳ２２）。
【００８６】
そして、フェーズＣ情報が有る場合には、送信パケットを生成するため、冗長パケット付加制御部に冗長パケット数を問い合わせ（ステップＳ２３）、ＲＴＮ信号受信応答の有無を判断する（ステップＳ２４）。
【００８７】
このとき、ＲＴＮ信号応答受信が有る場合には、エラー回復が十分に行われなかったので冗長パケット制御部に付加するパケット数を増加して更新することを通知する（ステップＳ２５）。
【００８８】
そして、この数の冗長パケットを冗長パケット記憶部から読出して主要パケットに付加し、ＵＤＰパケットを生成する（ステップＳ２６）。
【００８９】
これにより生成されたＴ．３８ＵＤＰパケットは、ネットワーク送信制御部に渡され、ＵＤＰ／ＩＰのプロトコルスタックに制御されて、ネットワークへの送信を行う（ステップＳ２７）。
【００９０】
一方、ステップＳ２４でＲＴＮ信号受信応答がない場合には、付加する冗長パケット数の変更が必要ないので、そのままステップＳ２６、ステップＳ２７に進む。
【００９１】
また、ステップＳ２２での判断でフェーズＣ情報でない場合には、そのままステップＳ２７に進む。
【００９２】
これによりエラー回復の可能性が大きくなり、送信エラーを避けることができ、受信側でエラーが多発したときは、冗長パケット数を増やしてエラー回復機能を強化し、良好な通信を行うことが可能となる。
【００９３】
一方、付加している冗長パケット数が多いような場合には、図１１に示すように、受信成功信号であるＭＣＦ（Ｍｅｓｓａｇｅ  Ｃｏｎｆｉｒｍ）信号受信応答の有無により冗長パケット数を低減することが可能である。なお、図１１は図１０に相当するフローチャートである。
【００９４】
即ち、図１１においてＴ．３８主要パケット生成部から主要パケットを受信すると（ステップＳ３１）、フェーズＣ情報の有無が判断される（ステップＳ３２）。
【００９５】
そして、フェーズＣ情報が有る場合には、送信パケットを生成するため、冗長パケット付加制御部に冗長パケット数を問い合わせ（ステップＳ３３）、ＭＣＦ信号受信応答の有無を判断する（ステップＳ３４）。
【００９６】
このとき、ＭＣＦ信号応答受信が有る場合には、エラー回復が十分に行われているので冗長パケット制御部に付加するパケット数を低減して更新することを通知する（ステップＳ３５）。
【００９７】
そして、この数の冗長パケットを冗長パケット記憶部から読出して主要パケットに付加し、ＵＤＰパケットを生成する（ステップＳ３６）。
【００９８】
これにより生成されたＴ．３８ＵＤＰパケットは、ネットワーク送信制御部に渡され、ＵＤＰ／ＩＰのプロトコルスタックに制御されて、ネットワークへの送信を行う（ステップＳ３７）。
【００９９】
一方、ステップＳ３４でＭＣＦ信号受信応答がない場合には、付加する冗長パケット数の変更が必要ないので、そのままステップＳ３６、ステップＳ３７に進む。
【０１００】
また、ステップＳ３２での判断でフェーズＣ情報でない場合には、そのままステップＳ３７に進む。
【０１０１】
このように、冗長パケット数の低減はＴ．３８ＵＤＰパケットを小さくすることを意味し、Ｉｎｔｅｒｎｅｔ全体のネットワーク負荷を下げる効果がある。
【０１０２】
なお、図示していないが、冗長パケット数の最低が「ゼロ」であるのは言うまでもない。
【０１０３】
【発明の効果】
以上説明したように、本願発明によれば、通信中に任意に冗長パケット数を設定可能にしたので冗長パケット数の最適化を行うことが可能になり、通信の信頼性が向上する。
【図面の簡単な説明】
【図１】公衆網とインターネットを経由して直接通信する通信形態を示す図である。
【図２】インターネットのみを介して２つの装置が通信する通信形態を示す図である。
【図３】図２におけるブロック図である。
【図４】勧告Ｔ．３８で規定されている通信プロトコルの一例を示す図である。
【図５】勧告Ｔ．３８でファクス画像をやり取りする場合のプロトコルスタックを示す図である。
【図６】ＵＤＰパケットの構成を示す図である。
【図７】ＵＤＰパケットによる通信を説明する図である。
【図８】冗長パケット数を通信中に任意に変更できるようにした構成図である。
【図９】Ｔ．３８ＵＤＰパケット生成部自身がプロトコルフェーズを解析して冗長パケット付加を行う場合のフローチャートである。
【図１０】ＲＴＮ信号により付加する冗長パケット数を増加する場合のフローチャートである。
【図１１】ＭＣＦ信号により付加する冗長パケット数を低減する場合のフローチャートである。
【符号の説明】
１  ＣＰＵ
２  ＲＯＭ
３  ＲＡＭ
４  ＳＲＡＭ
５  タイマ制御
６  ＣＯＤＥＣ
７  ハードディスクコントローラＨＤＣ
８  ハードディスクＨＤ
９  操作部ｉ／ｆ
１０  操作部
１１  スキャナｉ／ｆ
１２  スキャナ
１３  プロッタｉ／ｆ
１４  プロッタ
１５  Ｇ３通信制御部
１６  網制御部
１７  ＬＡＮ通信制御部
１８  ＬＡＮ制御部
【図１】
0003944761.tif 000002
【図２】
0003944761.tif 000003
【図３】
0003944761.tif 000004
【図４】
0003944761.tif 000005
【図５】
0003944761.tif 000006
【図６】
0003944761.tif 000007
【図７】
0003944761.tif 000008
【図８】
0003944761.tif 000009
【図９】
0003944761.tif 000010
【図１０】
0003944761.tif 000011
【図１１】
0003944761.tif 000012