JP4127351B2 - ゲートウェイ装置及びその制御方法 - Google Patents
ゲートウェイ装置及びその制御方法 Download PDFInfo
- Publication number
- JP4127351B2 JP4127351B2 JP2001254472A JP2001254472A JP4127351B2 JP 4127351 B2 JP4127351 B2 JP 4127351B2 JP 2001254472 A JP2001254472 A JP 2001254472A JP 2001254472 A JP2001254472 A JP 2001254472A JP 4127351 B2 JP4127351 B2 JP 4127351B2
- Authority
- JP
- Japan
- Prior art keywords
- network
- facsimile
- communication
- bandwidth
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、電話網及びパケット網経由のリアルタイムファクシミリ通信を行う、ゲートウェイ装置及びその制御方法に関する。
【０００２】
【従来の技術】
公衆回線網を介したファクシミリ通信、具体的には、例えば、ＩＴＵ−Ｔ勧告Ｔ．３０に準拠したＧ（グループ）３ファクシミリ通信は、送信側端末と受信側端末とが直接ファクシミリ制御信号をやりとりしつつファクシミリメッセージの送受信を行う、リアルタイムの通信形態のため、送信側端末と受信側端末との間の能力交換が可能であり、また、通信中に受信側端末に受信エラーが生じれば、送信側端末でもファクシミリ制御信号の受信側端末とのやりとりに障害がでて送信エラーとなるため、送信側端末としては、ファクシミリメッセージを受信側端末に正しく送信できたか否かの判断が容易であるという利点がある。
【０００３】
その反面、公衆回線網を介したファクシミリ通信は、通信時間に応じた通信料金が課金されしまう欠点がある。
【０００４】
一方、インターネット等のパケット網においては、電子メールによる通信がよく用いられる。電子メールによるネットワーク通信は、通信料金が基本的に無料であるという利点がある。
【０００５】
その反面、電子メールによるネットワーク通信は、送信側端末と最終的な受信側端末との間にメールサーバが介在して、送信側端末からメールサーバへの電子メールの送信と、電子メールを最終的に受信する受信側端末のメールサーバからの自装置宛電子メールの受信とが、同時には行われない、非リアルタイムの通信形態であるため、送信側端末と受信側端末との間の能力交換が不可能であり、また、受信側端末における電子メールのメールサーバからの受信中に受信エラーが生じても、送信側端末では、既に電子メールの送信は正常に終了しているため、送信側端末としては、メッセージを電子メールにより受信側端末に正しく送信できたか否かの判断ができないという欠点がある。
【０００６】
そのため、例えば、送信側端末から電子メールにより送信した文書データの形式（ファイル形式、符号化形式、解像度等）に、受信側端末が未対応であるために、送信側端末における文書データの電子メールによる送信は成功したのに、受信側端末において受信文書データを正しく処理できず、結果的に文書データの送信が失敗に終わってしまうという不具合が生じてしまうことがあった。
【０００７】
そこで、公衆電話網を介したファクシミリ通信の利点である端末間の能力交換及びリアルタイム性と、ネットワークを介した通信の、通信料金がかからないという利点とを両立した通信形態として、１９９９年４月に、パケット化したファクシミリ制御信号をパケット網上でやり取りするためのITU-T勧告T.38/H.323 AnnexDが制定された。
【０００８】
このITU-T勧告T.38/H.323 AnnexDに基づいた通信を行うことにより、端末間のファクシミリ通信に関する能力交換および通信のリアルタイム性が保証された通信をネットワーク上で行うことができるようになった。
【０００９】
ITU-T勧告T.38/H.323 AnnexDに従うネットワーク端末（Ｔ．３８端末）には、ネットワーク直結型のＩＡＦ（Internet Aware Fax）タイプと、専用線や公衆回線等の電話網へリアルタイムに転送するＧＷ（Gateway）タイプとの２種類が存在する。
【００１０】
ＩＡＦタイプの端末は、いわば、相手端末装置（ＩＡＦまたはＧＷ）との間でパケット化されたファクシミリ制御信号としてのＴ．３０信号をリアルタイムでやりとりして、自装置が相手端末装置にとっての最終宛先として文書データを受信するネットワークファクシミリ装置である。
【００１１】
一方、ＧＷタイプの端末は、ネットワークを介して相手端末（ＩＡＦまたはＧＷ）から受信したパケットから抽出したＴ．３０信号をモデム信号に変換して電話網を介して最終宛先となるＧ３ファクシミリ装置へ転送し、また電話網を介して前記Ｇ３ファクシミリ装置からモデム信号として受信したＴ．３０信号をパケット化してネットワークを介して相手端末に転送することで、ネットワーク上のＴ．３８端末と電話網上の従来型のファクシミリ装置との間でのリアルタイム通信を可能とするものである。
【００１２】
Ｔ．３８準拠のＧＷタイプの端末は、受信したＩＰパケットを、情報内容はそのままにＴ．３０信号に変換して電話網へ転送し、また電話網から受けたＴ．３０信号を情報内容はそのままにＩＰパケットに変換してパケット網に転送することで、ＩＰネットワーク上のＴ．３８端末と電話網上の従来型のＧ３ファクシミリ装置との間でのリアルタイム通信を可能とするものに過ぎないため、ファクシミリメッセージ伝送時の高速モデムでの通信速度は、電話網を介して自装置と回線接続される、従来型のＧ３ファクシミリ装置と、パケット網を介して自装置とネットワーク接続されるＩＡＦタイプの端末、または、パケット網を介して自装置とネットワーク接続されるＧＷタイプの端末から更に電話網を介して接続される従来型のＧ３ファクシミリ装置との間のＴ．３０に基づいたプロトコル手順により設定される。
【００１３】
具体的には、着信側装置がディジタル識別信号ＤＩＳにより、対応している通信速度を含む自機能力を発信側装置に通知し、その発信側装置がその通知された着信側装置の能力と自機能力との範囲内で通信条件を設定すると同時にその設定した通信条件をディジタル送信命令信号ＤＣＳにより着信側装置にも通知して設定させる。
【００１４】
したがって、ＧＷタイプの端末が接続されるパケット網における当該ＧＷタイプの端末が使用を許されるネットワーク帯域は、終端の端末間でＴ．３０に基づいたプロトコル手順により設定された通信速度でのメッセージデータの伝送を実現できるだけの十分な広さが確保されることがＴ．３８準拠のリアルタイムネットワークファクシミリ通信の前提となっていた。
【００１５】
そのため、仮に、ＧＷタイプの端末がパケット網上で使用可能なネットワーク帯域が終端の端末間でＴ．３０に基づいたプロトコル手順により設定された通信速度でのメッセージデータの伝送に十分でない場合、設定された通信速度でのメッセージデータの送受信を行うことができず、通信エラーとなってしまうという問題がある。
【００１６】
一方、ファクシミリ通信が頻繁に行われていないオフィス等においては、ファクシミリ通信用の十分なネットワーク帯域（64Kbps程度）をＧＷタイプの端末に割り当てることは、他のアプリケーションの帯域を縮小することにつながるため効率的ではないという事情がある。特にＩＳＤＮルータなどを使用して構築しているパケット網などではベースとなる帯域が64K〜128Kbps程度と狭いため、その中からファクシミリ通信のための十分な帯域を確保すること自体が難しくなるという問題がある。
【００１７】
それらの問題は、ITU-T勧告T.38/H.323 AnnexD準拠のものに限らず、電話網上でやりとりされるＴ．３０信号とパケット網上でやりとりされるパケット化されたＴ．３０信号とをリアルタイムに相互変換して行われるリアルタイムネットワークファクシミリ通信においては、同様に生じ得る問題である。
【００１８】
【発明が解決しようとする課題】
そこで、本願発明の発明者は、ゲートキーパが有するネットワーク帯域管理機能を用いてその問題の解決を図った技術を提案しているが（特願２０００−４０２４９４号）、現状ではまだ高価なゲートキーパを必要とする技術のため、設備投資の費用が増大してしまうという課題があった。また、現状では帯域管理機能を有しないゲートキーパも市販されているという課題もあった。
【００１９】
一方、ITU-T勧告H.323のAppendixIIではRSVP(Resource ReSerVation Protocol=ネットワークリソースを管理するプロトコル）を用いて通信に必要なネットワーク帯域の予約をルータに対して行う方法についての記述がある。なお、RSVPの仕様についてはRFC2205にて規定されている。
【００２０】
本発明は係る事情に鑑みてなされたものであり、前記ファクシミリ装置と前記相手端末装置との間で設定される通信速度でのリアルタイムネットワークファクシミリ通信を実現するために前記パケット網において必要とされるネットワーク帯域として十分なネットワーク帯域を、ルータへのネットワーク帯域予約により、確保することができるゲートウェイ装置及びその制御方法を提供することを目的とする。
【００２１】
【課題を解決するための手段】
請求項１に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、着信側の前記ファクシミリ装置から前記電話網を介して受信したファクシミリ制御信号内の通信速度能力に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、前記ファクシミリ制御信号内の通信速度能力を、前記確保ネットワーク帯域に相当する通信速度以下に書き換えた上でパケット化して前記パケット網上の相手端末装置に送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２２】
請求項２に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、着信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の通信速度能力に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、前記ファクシミリ制御信号内の通信速度能力を、前記確保ネットワーク帯域に相当する通信速度以下に書き換えた上でモデム信号化して前記電話網上の発信側の前記ファクシミリ装置に送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２３】
請求項３に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、発信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記相手端末装置から前記パケット網を介して受信したモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側の相手端末装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２４】
請求項４に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、発信側の前記ファクシミリ装置から前記電話網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記ファクシミリ装置から前記電話網を介して受信した所定のモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側のファクシミリ装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２５】
請求項５に記載のゲートウェイ装置は、請求項１、２、３または４のいずれかに記載のゲートウェイ装置において、前記通信速度／ネットワーク帯域調節手段は、前記ルータに要求して確保する前記確保ネットワーク帯域を、前記相手端末装置と前記ファクシミリ装置との間のリアルタイムファクシミリ通信におけるファクシミリ伝送手順の各フェーズで変更することを特徴とする。
【００２６】
請求項６に記載のゲートウェイ装置は、請求項３に記載のゲートウェイ装置において、前記通信速度／ネットワーク帯域調節手段は、前記パケット網上の発信側の前記相手端末装置と、前記電話網上の着信側のファクシミリ装置との間のリアルタイムネットワークファクシミリ通信を中継する場合に、前記ルータに要求して確保した前記確保ネットワーク帯域が、ファクシミリ通信に必要な所定の最低限帯域以下の場合には、前記ファクシミリ装置への前記電話網を介した発呼を行わないで通信を中止することを特徴とする。
【００２７】
請求項７に記載のゲートウェイ装置は、請求項１、２、３または４のいずれかに記載のゲートウェイ装置において、前記通信速度／ネットワーク帯域調節手段は、前記ルータにネットワーク帯域を要求した結果、前記ルータが帯域予約機能を備えていなかった場合、予め記憶登録しておいた帯域情報を前記確保ネットワーク帯域とすることを特徴とする。
【００２８】
請求項８に記載のゲートウェイ装置の制御方法は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置の制御方法であって、発信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記相手端末装置から前記パケット網を介して受信したモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側の相手端末装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手順を含むことを特徴とする。
請求項９に記載のゲートウェイ装置の制御方法は、請求項８に記載のゲートウェイ装置の制御方法において、前記通信速度／ネットワーク帯域調節手順は、前記ルータに要求して確保する前記確保ネットワーク帯域を、前記相手端末装置と前記ファクシミリ装置との間のリアルタイムファクシミリ通信におけるファクシミリ伝送手順の各フェーズで変更することを特徴とする。
請求項１０に記載のゲートウェイ装置の制御方法は、請求項８に記載のゲートウェイ装置の制御方法において、前記通信速度／ネットワーク帯域調節手順は、前記パケット網上の発信側の前記相手端末装置と、前記電話網上の着信側のファクシミリ装置との間のリアルタイムネットワークファクシミリ通信を中継する場合に、前記ルータに要求して確保した前記確保ネットワーク帯域が、ファクシミリ通信に必要な所定の最低限帯域以下の場合には、前記ファクシミリ装置への前記電話網を介した発呼を行わないで通信を中止することを特徴とする。
【００２９】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を詳細に説明する。
【００３０】
なお、以下説明する実施の形態においては、電話網上の、ITU-T勧告T.30準拠のＧ３ファクシミリ装置と、パケット網上のITU-T勧告T.38/H.323 AnnexD準拠の相手端末装置（ゲートウェイ装置またはネットワークファクシミリ装置）との間にITU-T勧告T.38/H.323 AnnexD準拠のゲートウェイ装置が介在して行われるリアルタイムネットワークファクシミリ通信に本発明を適用している。
【００３１】
しかし、今後勧告の進展により、Ｇ３ファクシミリ装置以外のファクシミリ装置（例えばＧ４ファクシミリ装置）と、パケット網上の相手端末装置との間のゲートウェイ装置を介したリアルタイムネットワークファクシミリ通信が、Ｔ．３８に代わる新たな勧告が規定される等して実現されたような場合には、本発明を、本発明の趣旨を逸脱せず本質的に同じ構成で適用することができるのはいうまでもない。
【００３２】
先ず、図１に、本発明の実施の形態に係るゲートウェイ装置１を含むリアルタイムネットワークファクシミリ通信システムの構成例について示す。
【００３３】
同図に示すシステムは、説明の便宜上、左側の着信側システムと、右側の発信側システムとが、一定のネットワーク帯域（例えば64kbbs）の通信ライン７０により接続されたシステムとなっている。
【００３４】
発信側のＧ３ファクシミリ装置であるＧ３ファクス４０ａは、電話網５０ａを介して、発信側Ｔ．３８端末装置としてのゲートウェイ装置（ＧＷ）１ａに発呼して宛先指定を行う。
【００３５】
発信側Ｔ．３８端末装置としてのネットワークファクシミリ装置（ＩＡＦ）２０ａは、自装置の操作部等から宛先指定を直接受ける。
【００３６】
発信側Ｔ．３８端末装置としてのＧＷ１ａやＩＡＦ２０ａは、パケット網６０ａにおいてルータ８０ｂを介して通信を行い、宛先の着信側Ｔ．３８端末装置としてのＧＷ１ｂやＩＡＦ２０ｂに通信ライン７０及びパケット網６０ｂを介してT.38/H.323 AnnexDパケット信号を送信する。
【００３７】
一方、着信側Ｔ．３８端末装置としてのＧＷ１ｂやＩＡＦ２０ｂは、パケット網６０ｂにおいてルータ８０ｂを介して通信を行い、発信側Ｔ．３８端末装置としてのＧＷ１ａやＩＡＦ２０ａ（を介したＧ３ファクス４０ａ）との間でパケット網６０ｂ及び通信ライン７０を介してT.38/H.323 AnnexDパケット信号をやりとりしてリアルタイムネットワークファクシミリ通信を行う。
【００３８】
なお、ＧＷ１ｂは、更に、発信側からＳＥＴＵＰパケットにより通知される電話網５０ｂ上の着信側のＧ３ファクス４０ｂに発呼して、Ｇ３ファクス４０ｂと、発信側Ｔ．３８端末装置との間のリアルタイムネットワークファクシミリ通信を中継する。
【００３９】
ＧＷ１ａは、パケット網６０ａ上から渡されたT.38/H.323 AnnexDパケット信号をT.30信号に変換して、電話網５０ａ上のＧ３ファクス４０ａに転送する一方、電話網５０ａ上から渡されたT.30信号をT.38/H.323 AnnexDパケット信号に変換してパケット網６０ａを介して転送する。
【００４０】
ＧＷ１ｂは、パケット網６０ｂ上から渡されたT.38/H.323 AnnexDパケット信号をT.30信号に変換して、電話網５０ｂ上のＧ３ファクス４０ｂに転送する一方、電話網５０ｂ上から渡されたT.30信号をT.38/H.323 AnnexDパケット信号に変換してパケット網６０ｂを介して転送する。
【００４１】
本発明は、ＧＷ１ｂまたはＩＡＦ２０ｂの着信側Ｔ．３８端末装置にとっての発信側ＧＷ１ａとなって、発信側Ｇ３ファクス４０ａと着信側Ｔ．３８端末装置との間のリアルタイムネットワークファクシミリ通信を中継する場合、または、ＧＷ１ａまたはＩＡＦ２０ａの発信側Ｔ．３８端末装置にとっての着信側ＧＷ１ｂとなって、着信側Ｇ３ファクス４０ｂと発信側Ｔ．３８端末装置との間のリアルタイムネットワークファクシミリ通信を中継する場合についてのものである。
【００４２】
図２に発信側ゲートウェイ装置１ａまたは着信側ゲートウェイ装置１ｂとなるゲートウェイ装置１のブロック構成について示す。
【００４３】
同図において、ゲートウェイ装置１は、システム制御部２、ＲＯＭ３、ＲＡＭ４、記憶装置５、オペポート６、ＬＡＮコントローラ７、トランス８、モデム９、網制御部１０、及び、システムバス１１により構成されている。
【００４４】
システム制御部２は、ＲＯＭ３に書き込まれた制御プログラムに従って、ＲＡＭ４を作業領域として使用しながら、装置各部を制御するマイクロコンピュータである。
【００４５】
ＲＯＭ３は、前述したように、システム制御部２が上記装置各部を制御するための制御プログラムが記憶されているリードオンリメモリである。ＲＡＭ４は、前述したようにシステム制御部２の作業領域として使用されるランダムアクセスメモリである。
【００４６】
記憶装置５は、ハードディスク装置等により構成され、データを蓄積するためのものである。操作表示部６は、装置の動作状態の表示や各種操作入力を受け付けるためのものである。
【００４７】
ＬＡＮコントローラ１０は、トランス８を介してパケット網６０から受信したデータのデコード、またパケット網６０へ送信するデータのエンコードを行ったり、送信フレームや受信フレームのバッファリングを行うことで、パケット網６０からのデータを送受信するためのトランスフォーマーであるトランス８を介したＬＡＮプロトコルを制御して、そのＬＡＮプロトコル上でシステム制御部２がＴＣＰ／ＩＰプロトコルを制御して、T.38/H.323 AnnexDに基づいたリアルタイムネットワークファクシミリ通信を行えるようにするためのものである。
【００４８】
モデム９は、Ｇ３ファクシミリモデムで、網制御部１０を介して電話網５０に送信するデータを変調する一方、網制御部１０を介して電話網５０から受信した信号を復調するものである。また、モデム９は、相手先番号に対応するＤＴＭＦ信号の送出も行う。
【００４９】
網制御部１０は、電話網５０に接続されて、電話網５０の回線の極性反転の検出、回線の直流ループの閉結・解放や、回線解放の検出、発信音の検出、ビジートーン等のトーン信号の検出、呼出信号の検出等の回線との接続制御や、相手先番号に対応する選択信号の、２０ＰＰＳまたは１０ＰＰＳのダイヤル回線に対応したダイヤルパルス信号による送出を行うものである。システムバス１１は、上記各部がデータをやり取りするための信号ラインである。
【００５０】
図３に、ゲートウェイ装置１におけるソフトウェア構成を示す。
【００５１】
ゲートウェイ装置１は、T.38/H.323 AnnexDに従うＧＷタイプのネットワーク端末であり、電話網５０を介したT.30に基づいたＧ３ファクシミリ通信機能と、そのＧ３ファクシミリ通信機能と並行して実行される、パケット網６０を介したT.38/H.323 AnnexDにもとづいたパケット通信機能とを備えたものとして構成されている。
【００５２】
そのため、図３に示すソフトウェア構成においては、「ファクスプロトコル（Ｔ．３０）制御」は、電話網でのファクスデータ通信を行う「ＭＯＤＥＭ制御」と、「ＬＡＮコントローラ制御」、ネットワークを制御するための「ＴＣＰ／ＩＰ」プロトコル、及びリアルタイムネットワークファクシミリ通信を制御するための「Ｔ．３８パケット制御」より構成されるプロトコルスタックとの双方の上に位置する。更に、「ファクスプロトコル（Ｔ．３０）制御」の上には、「オペポート制御」、及び、装置動作全体の統括的制御を行う「全体制御」が位置する。
【００５３】
次に、本発明を実現するために使用するRSVP(Resource ReSerVation Protocol=ネットワークリソースを管理するプロトコル）を用いた通信の基本シーケンスについて、図４に示す。なお、RSVPは、ITU-T勧告H.323のAppendixIIに記述された、通信に必要なネットワーク帯域の予約をルータに対して行うことが可能なプロトコルで、その仕様についてはRFC2205にて規定されている。
【００５４】
図４において、ゲートウェイ装置ＧＷやＩＡＦ等のＨ．３２３端末が、パケット網内のルータを介して、相手先のＨ．３２３端末であるゲートウェイ装置ＧＷを介して、電話網上の電話（Ｔｅｌ）／ファクス（ＦＡＸ）との間で通信を行う場合、Ｈ．３２３端末間で呼制御用ＴＣＰチャンネルを確立し（フェーズＦ１）、ＯＬＣ(OpenLogicalChannel)メッセージを送信・受信する（フェーズＦ２）。ＯＬＣを受信したゲートウェイ装置ＧＷは、Ｔｅｌ／ＦＡＸに対して発呼し（フェーズＦ３）、Ｔｅｌ／ＦＡＸが応答すると（フェーズＦ４）、ＯＬＣ＿Ａｃｋメッセージを返す（フェーズＦ５）。
【００５５】
そして、発信側から着信側に各ルータを介してRSVP_Pathメッセージを送信し（フェーズＦ６ａ、Ｆ６ｂ、Ｆ６ｃ）、それに対して着信側が、帯域確保要求のRSVP_Resvメッセージを各ルータを介して返信することにより（フェーズＦ７ａ、７ｂ、７ｃ）、ネットワーク待機の確保要求を行う。発信側は、それに対して、各ルータを介して帯域確保成功を示す応答（RSVP_Conf）を行い（フェーズＦ８ａ、Ｆ８ｂ、Ｆ８ｃ）、以後、その確保されたネットワーク帯域を用いて、音声／データ通信を行う（フェーズＦ９）。
【００５６】
フェーズＦ９の通信が終了すると、発信側はＣＬＣ（CloseLogicalChannel）メッセージを送信し、それを着信側が受信すると（フェーズＦ１０）、着信側のゲートウェイ装置ＧＷは、Ｔｅｌ／ＦＡＸとの間で接続されている回線を切断すると共に（フェーズＦ１１）、帯域解放を示すRSVP_Tearメッセージを発信側のＨ．３２３端末に返信してリソースの解放を行い通信を終了する。
【００５７】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、第１実施形態に係る着信側処理について、図５及び図６を参照して説明する。また、図５及び図６に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図７に示す。
【００５８】
図５において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図７のフェーズＦ１０）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理１０１：図７のフェーズＦ１１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【００５９】
着信側ＧＷ１ｂは、処理１０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、続いて、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理１０２：図７のフェーズＦ１２）、その発呼に対する応答を受ける（処理１０３：図７のフェーズＦ１３）。
【００６０】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理１０４：図７のフェーズＦ１４）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【００６１】
その後、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理１０５：図７のフェーズＦ１５）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１０６：図７のフェーズＦ１６）。
【００６２】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【００６３】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理１０７：図７のフェーズＦ１７）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１０８のＮｏ）、リトライ回数が満了していない限り、処理１０６に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１１０のＮｏ）。
【００６４】
リトライ回数が満了してしまった場合には（判断１１０のＹｅｓ）、通信エラーとして、図６の処理２０８に移行する。
【００６５】
リトライ回数の満了までに帯域予約が成功した場合には（判断１０８のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存し（処理１１１：図７のフェーズＦ１８）、図６の処理２０１に移行する。
【００６６】
これにより、以後の着信側ＧＷ１ｂにおけるパケット網６０ｂを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【００６７】
図６の処理２０１では、図７のフェーズＦ１９で確立されたデータチャンネルを使用して、フェーズＦ２０のファクスプロトコル処理を開始する（処理２０１）。
【００６８】
そして、処理２０１で開始されたフェーズＦ２０のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理２０２：図７のフェーズＦ２０ｃ）。
【００６９】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側、すなわち、Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理２０３）。
【００７０】
そして、処理２０３で取得した必要ネットワーク帯域Ｂが、処理１１１で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断２０４）。
【００７１】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断２０４のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図７のフェーズＦ２０ｆのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理２０２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理２０６：図７のフェーズＦ２０ｅ）、以後のフェーズＦ２０のファクスプロトコル処理を行う（処理２０７）。
【００７２】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断２０４のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理２０２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理２０５：図７のフェーズＦ２０ｄ）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理２０６：図７のフェーズＦ２０ｅ）、以後フェーズＦ２９のファクスプロトコル処理を継続する。
【００７３】
処理２０７のフェーズＦ２０の通信が終了した後、または、判断１１０がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理２０８）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理２０９）、処理を終了する。
【００７４】
このように、着信側Ｇ３ファクス４０ｂから受信したディジタル識別信号ＤＩＳの内容を着信側ＧＷ１ｂが変換することにより、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）に対して、着信側Ｇ３ファクス４０ｂの通信速度能力が低いとみせかけて、帯域オーバーとなるような通信速度が発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）において設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず、常に正常なリアルタイムネットワーク通信の中継が可能となる。
【００７５】
次に、本発明の実施の形態に係るゲートウェイ装置１が発信側ゲートウェイ装置１ａとして行う、第２実施形態に係る発信側処理について、図８及び図９を参照して説明する。また、図８及び図９に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１０に示す。
【００７６】
図８において、発信側ＧＷ１ａは、図１０のフェーズＦ３０に示す発信側Ｇ３ファクス４０ａからの電話網５０ａを介した着呼を受け（処理３０１）、その着呼に対して図１０のフェーズＦ３１に示す応答を行う（処理３０２）。
【００７７】
そして、図１０のフェーズＦ３２により着信側の宛先（ＩＰアドレス（及びファクス番号））を取得すると、発信側ＧＷ１ａは、呼制御用ＴＣＰチャンネルの確立後（図１０のフェーズＦ３３）、着信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）に対してＳＥＴＵＰパケットを送信する（処理３０３：図１０のフェーズＦ３４）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を通知する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、自端末がRSVPをサポートしていることを相手に通知する。
【００７８】
そして、着信側Ｔ．３８端末装置からＣＯＮＮＥＣＴパケットを受信する（処理３０４：図１０のフェーズＦ３５）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、着信側もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージが返されるものとする）。
【００７９】
着信側がRSVプロトコルをサポートしていないことが分かった場合には、従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【００８０】
相手端末がRSVプロトコルをサポートしている場合、続いて、RSVP_Pathメッセージを送信し（処理３０５：図１０のフェーズＦ３６）、ネットワーク上のルータのパスを通知し帯域予約要求を行う。このとき、経路途中のルータにより、エラー（PathError）が返ってきた場合、通常手順通信あるいはエラー終了するが、RSVP_Resvメッセージが受信されると、リソースの予約要求が受け入れられるたことになる（処理３０６：図１０のフェーズＦ３７）。
【００８１】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【００８２】
RSVP_Resvメッセージが受信されて帯域予約が成功すると、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存すると共に（処理３０７：図１０のフェーズＦ３８）、帯域確保成功を示す応答（RSVP_Conf）を相手端末に送信する（処理３０８：図１０のフェーズＦ３９）。
【００８３】
これにより、以後の発信側ＧＷ１ａにおけるパケット網６０ａを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【００８４】
処理３０９では、図１０のフェーズＦ４０で確立されたデータチャンネルを使用して、フェーズＦ４１のファクスプロトコル処理を開始する（処理３０９）。
【００８５】
そして、処理３０９で開始されたフェーズＦ４１のファクスプロトコル処理、すなわち、パケット網６０ａを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等の、ファクシミリ制御信号としてのＴ．３０信号のパケットを受信し、モデム信号へ変換し、電話網５０ａを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのパケットを受信する（処理４０１：図１０のフェーズＦ４１ｃ）。
【００８６】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側、すなわち、ＩＡＦ２０ｂ、または、ＧＷ１ｂを介したＧ３ファクス４０ｂの通信速度能力に対応する必要ネットワーク帯域Ｂを調査する（処理４０２）。
【００８７】
そして、処理４０２で取得した必要ネットワーク帯域Ｂが、処理３０７で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断４０３）。
【００８８】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断４０３のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側Ｇ３ファクス４０ａにより、図１０のフェーズＦ４１ｆのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ａにおいて帯域オーバーが生じることがないため、処理４０１でパケットとして受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側Ｇ３ファクス４０ａにモデム信号として送信し（処理４０５：図１０のフェーズＦ４１ｅ）、以後のフェーズＦ４１のファクスプロトコル処理を行う（処理２０７）。
【００８９】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断４０３のＹｅｓ）、そのままでは、着信側Ｔ．３８端末の通信速度能力以上の通信速度能力を、発信側Ｇ３ファクス４０ａが備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ａにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理４０１でパケットとして受信したディジタル識別信号ＤＩＳのファクシミリ情報フィールドの情報内容のうちの、通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂか゜なるような通信速度能力（例えば7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理４０４：図１０のフェーズＦ４１ｄ）、その書換え変換後のディジタル識別信号ＤＩＳを、モデム信号に変換して発信側Ｇ３ファクス４０ａに送信し（処理４０５：図１０のフェーズＦ４１ｅ）、以後フェーズＦ４１のファクスプロトコル処理を継続する。
【００９０】
処理４０６のフェーズＦ４１の通信が終了した後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを送信し（処理４０７）、それに対する相手端末からの帯域解放（RSVP_Tear）のパケットを受信してリソースの解放が行われて（処理４０８）、処理が終了する。
【００９１】
このように、着信側Ｔ．３８端末から受信したディジタル識別信号ＤＩＳの内容を発信側ＧＷ１ａが変換することにより、発信側Ｇ３ファクス４０ａに対して、着信側Ｔ．３８端末の通信速度能力が低いとみせかけて、帯域オーバーとなるような通信速度が発信側Ｇ３ファクス４０ａにおいて設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず、常に正常なリアルタイムネットワーク通信の中継が可能となる。
【００９２】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、第３実施形態に係る着信側処理について、図１１及び図１２を参照して説明する。また、図１１及び図１２に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１３に示す。
【００９３】
図１１において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図１３のフェーズＦ５０）、発信側Ｔ．３８端末（ＩＡＦ６０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理５０１：図１３のフェーズＦ５１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【００９４】
着信側ＧＷ１ｂは、処理５０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、続いて、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理５０２：図１３のフェーズＦ５２）、その発呼に対する応答を受ける（処理５０３：図１３のフェーズＦ５３）。
【００９５】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理５０４：図１３のフェーズＦ５４）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【００９６】
その後、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理５０５：図１３のフェーズＦ５５）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理５０６：図１３のフェーズＦ５６）。
【００９７】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【００９８】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理５０７：図１３のフェーズＦ５７）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断５０８のＮｏ）、リトライ回数が満了していない限り、処理５０６に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断５１０のＮｏ）。
【００９９】
リトライ回数が満了してしまった場合には（判断５１０のＹｅｓ）、通信エラーとして、図１２の処理６０８に移行する。
【０１００】
リトライ回数の満了までに帯域予約が成功した場合には（判断５０８のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存し（処理５１１：図１３のフェーズＦ５８）、図１３のフェーズＦ５９により確立されたデータチャンネル上でフェーズＦ６０のファクスプロトコル処理を開始して、着信側Ｇ３ファクス４０ｂからディジタル識別信号ＤＩＳのモデム信号を受信すると（処理５１２：図１３のフェーズＦ６０ｃ）、その受信したディジタル識別信号ＤＩＳのモデム信号を内容の変更なしにそのままパケットに変換して発信側Ｔ．３８端末に送信してしまう（処理５１３：図１３のフェーズＦ６０ｄ）。
【０１０１】
すると、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）は、フェーズＦ６０ｄで通知された着信側の通信速度能力と自装置の通信速度能力の範囲内の通信速度（通常は最大の通信速度）を設定して、その他の通信パラメータの設定と共にディジタル送信命令信号ＤＣＳにより送信してくるため、そのディジタル送信命令信号ＤＣＳを受信する（図１２の処理６０１：図１３のフェーズＦ６０ｅ）。
【０１０２】
そして、その受信したディジタル送信命令信号ＤＣＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される発信側が対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理６０２）。
【０１０３】
そして、処理６０２で取得した必要ネットワーク帯域Ｂが、処理５１１で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断６０３）。
【０１０４】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以上の場合には（判断６０３のＹｅｓ）、発信側Ｔ．３８端末からトレーニングチェック信号ＴＣＦのパケットを受信する（処理６０４：図１３のフェーズＦ６０ｆ）。ただし、その場合受信したＴＣＦ信号のパケットについては、モデム信号に変換して着信側Ｇ３ファクス４０ｂに送信する処理は行わない。
【０１０５】
そして、その受信したＴＣＦ信号のパケットに対して、トレーニングエラー信号ＦＴＴのパケットを発信側Ｔ．３８端末に送信して（処理６０５：図１３のフェーズＦ６０ｇ）、処理６０１に戻る。その場合処理６０１で受信するディジタル送信命令信号ＤＣＳの通信速度の設定は、トレーニングエラー信号ＦＴＴの受信を受けて、発信側Ｔ．３８端末（を介したＧ３ファクス４０ａ）において前に設定した速度よりも遅く設定されていることになる。
【０１０６】
そのため、判断６０３がＹｅｓとなった場合でも、判断６０３のＹｅｓのループが１回または複数回繰り返されることで、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも狭くなり、判断６０３がＮｏとなる。
【０１０７】
判断６０３がＮｏとなって初めて、処理６０１でパケットとして受信したディジタル識別信号ＤＩＳをモデム信号に変換して、着信側Ｇ３ファクス４０ｂに送信し（処理６０６：図１３のフェーズＦ６０ｉ）、以後フェーズＦ６０のファクスプロトコル処理を継続する（処理６０７）。
【０１０８】
処理６０７のフェーズＦ６０の通信が終了した後、または、判断５１０がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理６０８）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理６０９）、処理を終了する。
【０１０９】
このように、発信側Ｔ．３８端末から受信したディジタル送信命令信号ＤＣＳにより設定された通信速度ではモデムトレーニングが失敗してしまうとみせかけて、帯域オーバーとなるような通信速度が発信側Ｔ．３８端末（を介したＧ３ファクス４０ａ）において設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず常に正常なリアルタイムネットワーク通信の中継が可能となり、また、発信側のＴ．３８端末（を介したＧ３ファクス４０ａ）において最終的に設定される通信速度に合わせて必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下になるように調節されるため、確保ネットワーク帯域Ａを無駄なく使用して効率的なファクシミリ通信が可能となる。
【０１１０】
次に、本発明の実施の形態に係るゲートウェイ装置１が発信側ゲートウェイ装置１ａとして行う、第４実施形態に係る発信側処理について、図１４及び図１５を参照して説明する。また、図１４及び図１５に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１６に示す。
【０１１１】
図１４において、発信側ＧＷ１ａは、図１６のフェーズＦ７０に示す発信側Ｇ３ファクス４０ａからの電話網５０ａを介した着呼を受け（処理７０１）、その着呼に対して図１６のフェーズＦ７１に示す応答を行う（処理７０２）。
【０１１２】
そして、図１６のフェーズＦ７２により着信側の宛先（ＩＰアドレス（及びファクス番号））を取得すると、発信側ＧＷ１ａは、呼制御用ＴＣＰチャンネルの確立後（図１６のフェーズＦ７３）、着信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）に対してＳＥＴＵＰパケットを送信する（処理７０３：図１６のフェーズＦ７４）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を通知する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、自端末がRSVPをサポートしていることを相手に通知する。
【０１１３】
続いて、RSVP_Pathメッセージを送信し（処理７０４：図１６のフェーズＦ７５）、ネットワーク上のルータのパスを通知し帯域予約要求を行う。このとき、経路途中のルータにより、エラー（PathError）が返ってきた場合、通常手順通信あるいはエラー終了するが、RSVP_Resvメッセージが受信されると、リソースの予約要求が受け入れられたことになる（処理７０５：図１６のフェーズＦ７６）。
【０１１４】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【０１１５】
RSVP_Resvメッセージが受信されて帯域予約が成功すると、帯域確保成功を示す応答（RSVP_Conf）を相手端末に送信すると共に（処理７０６：図１６のフェーズＦ７７）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存する（処理７０７：図１６のフェーズＦ７８）。
【０１１６】
そして、着信側Ｔ．３８端末装置からＣＯＮＮＥＣＴパケットを受信する（処理７０８：図１６のフェーズＦ７９）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、着信側もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージが返されるものとする）。
【０１１７】
着信側がRSVプロトコルをサポートしていないことが分かった場合には、従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【０１１８】
これにより、以後の発信側ＧＷ１ａにおけるパケット網６０ａを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【０１１９】
処理７０９では、図１６のフェーズＦ８０で確立されたデータチャンネルを使用して、フェーズＦ８１のファクスプロトコル処理を開始する（処理７０９）。
【０１２０】
そして、着信側Ｔ．３８端末からディジタル識別信号ＤＩＳのパケットを受信すると（処理７１０：図１６のフェーズＦ８１ｃ）、その受信したディジタル識別信号ＤＩＳのパケットを内容の変更なしにそのままモデム信号に変換して発信側Ｇ３ファクス４０ａに送信してしまう（処理７１１：図１６のフェーズＦ８１ｄ）。
【０１２１】
すると、発信側Ｇ３ファクス４０ａは、フェーズＦ８１ｄで通知された着信側の通信速度能力と自装置の通信速度能力の範囲内の通信速度（通常は最大の通信速度）を設定して、その他の通信パラメータの設定と共にディジタル送信命令信号ＤＣＳにより送信してくるため、そのディジタル送信命令信号ＤＣＳを受信する（図１５の処理８０１：図１３６フェーズＦ８１ｅ）。
【０１２２】
そして、その受信したディジタル送信命令信号ＤＣＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される発信側が対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理８０２）。
【０１２３】
そして、処理８０２で取得した必要ネットワーク帯域Ｂが、処理７０７で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断８０３）。
【０１２４】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以上の場合には（判断８０３のＹｅｓ）、発信側Ｇ３ファクス４０ａからトレーニングチェック信号ＴＣＦのモデム信号を受信する（処理８０４：図１６のフェーズＦ８１ｆ）。ただし、その場合受信したＴＣＦ信号のモデム信号については、パケットに変換して着信側Ｔ．３８端末に送信する処理は行わない。
【０１２５】
そして、その受信したＴＣＦ信号のモデム信号に対して、トレーニングエラー信号ＦＴＴのモデム信号を発信側Ｇ３ファクス４０ａに送信して（処理８０５：図１６のフェーズＦ８１ｇ）、処理８０１に戻る。その場合処理８０１で受信するディジタル送信命令信号ＤＣＳの通信速度の設定は、トレーニングエラー信号ＦＴＴの受信を受けて、発信側Ｇ３ファクス４０ａにおいて前に設定した速度よりも遅く設定されていることになる。
【０１２６】
そのため、判断８０３がＹｅｓとなった場合でも、判断８０３のＹｅｓのループが１回または複数回繰り返されることで、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも狭くなり、判断８０３がＮｏとなる。
【０１２７】
判断８０３がＮｏとなって初めて、処理８０１でモデム信号として受信したディジタル識別信号ＤＩＳをパケットに変換して、着信側Ｔ．３８端末に送信し（処理８０６：図１６のフェーズＦ８１ｉ）、以後フェーズＦ８１のファクスプロトコル処理を継続する（処理８０７）。
【０１２８】
処理８０７のフェーズＦ８１の通信が終了した後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを送信し（処理８０８）、それに対する相手端末からの帯域解放（RSVP_Tear）のパケットを受信してリソースの解放が行われて（処理８０９）、処理が終了する。
【０１２９】
このように、発信側Ｇ３ファクス４０ａから受信したディジタル送信命令信号ＤＣＳにより設定された通信速度ではモデムトレーニングが失敗してしまうとみせかけて、帯域オーバーとなるような通信速度が発信側３ファクス４０ａにおいて設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず常に正常なリアルタイムネットワーク通信の中継が可能となり、また、発信側のＧ３ファクス４０ａにおいて最終的に設定される通信速度に合わせて必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下になるように調節されるため、確保ネットワーク帯域Ａを無駄なく使用して効率的なファクシミリ通信が可能となる。
【０１３０】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、図５及び図６に示した第１実施形態に係る着信処理の変形例である、第５実施形態に係る着信側処理について、図１７及び図１８を参照して説明する。また、図１７及び図１８に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１９に示す。
【０１３１】
図１７において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図１９のフェーズＦ９０）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理９０１：図１９のフェーズＦ９１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【０１３２】
着信側ＧＷ１ｂは、処理９０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、続いて、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理９０２：図１９のフェーズＦ９２）、その発呼に対する応答を受ける（処理９０３：図１９のフェーズＦ９３）。
【０１３３】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理９０４：図１９のフェーズＦ９４）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【０１３４】
その後、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理９０５：図１９のフェーズＦ９５）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理９０６：図１９のフェーズＦ９６）。
【０１３５】
このとき予約する帯域としては、ファクシミリメッセージの伝送時に必要となる高速モデム（例えば33.6Kbps）用の帯域ではなく、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１３６】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理９０７：図１９のフェーズＦ９７）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断９０８のＮｏ）、リトライ回数が満了していない限り、処理９０６に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断９１０のＮｏ）。
【０１３７】
リトライ回数が満了してしまった場合には（判断９１０のＹｅｓ）、通信エラーとして、図１８の処理１０１４に移行する。
【０１３８】
リトライ回数の満了までに帯域予約が成功した場合には（判断９０８のＹｅｓ）、図１８の処理１００１に移行する。
【０１３９】
図１８の処理１００１では、図１９のフェーズＦ９８で確立されたデータチャンネルを使用して、フェーズＦ９９のファクスプロトコル処理を開始する（処理１００１）。
【０１４０】
そして、処理１００１で開始されたフェーズＦ９９のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理１００２：図１９のフェーズＦ９９ｃ）。
【０１４１】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理１００３）。
【０１４２】
そして、その必要ネットワーク帯域Ｂ（この場合V.34の33.6Kbps）を、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１００４：図１９のフェーズＦ９９ｄ）。
【０１４３】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理１００５：図１９のフェーズＦ９９ｅ）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１００６のＮｏ）、リトライ回数が満了していない限り、処理１００４に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１００８のＮｏ）。
【０１４４】
リトライ回数が満了してしまった場合には（判断１００８のＹｅｓ）、通信エラーとして、処理１０１４に移行する。
【０１４５】
リトライ回数の満了までに帯域予約が成功した場合には（判断１００６のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存する（処理１００９）。
【０１４６】
そして、処理１００３で取得した必要ネットワーク帯域Ｂが、処理１００９で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断１００４）。
【０１４７】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断１０１０のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図１９のフェーズＦ９９ｇのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理１００２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理１０１２：図１９のフェーズＦ９９ｆ）、以後のフェーズＦ９９のファクスプロトコル処理を行う（処理１０１３）。
【０１４８】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断１０１０のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理１００２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理１０１１）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理１０１２：図１９のフェーズＦ９９ｆ）、以後フェーズＦ９９のファクスプロトコル処理を継続する（処理１０１３）。
【０１４９】
なお、処理１０１３におけるファクスプロトコル処理においては、図１９に示すように、フェーズＦ９９ｉ、Ｆ９９ｊの画情報のファクシミリメッセージの伝送終了後、伝送後手順に移行する前に、フェーズＦ９９ｋ及びフェーズＦ９９ｌにより、確保するネットワーク帯域を、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、フェーズＦ９９ｍ以降の伝送後手順においても、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１５０】
処理１０１３のフェーズＦ９９の通信が終了した後、または、判断１００８がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理１０１４）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理１０１５）、処理を終了する。
【０１５１】
このように、リアルタイムネットワークファクシミリ通信の開始から終了まで一定のネットワーク帯域を確保するのではなく、呼制御フェーズや能力交換フェーズなど、データフェーズ以外の通信手順を行っているときに、ルータに要求するネットワーク帯域を減らすことで、トータルではより少ないネットワーク帯域で通信することができるようになる。
【０１５２】
なお、この第５実施形態は、第１実施形態の変形例であるが、同様の変形は、第２、第３及び第４実施形態にたいしても同様に適用できるのはいうまでもない。また、ＤＩＳ／ＤＣＳの値に関わらず画情報転送前に固定の値（例えば64Kbps）の帯域予約要求（RSVP_Resv）送出するなど本発明のみを実施することも可能である。
【０１５３】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、図１７及び図１８に示した第５実施形態に係る着信処理の変形例である、第６実施形態に係る着信側処理について、図２０、図２１及び図２２を参照して説明する。また、図２０、図２１及び図２２に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図２３に示す。
【０１５４】
図２０において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図２３のフェーズＦ１００）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理１１０１：図２３のフェーズＦ１０１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【０１５５】
着信側ＧＷ１ｂは、処理１１０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理１１０２：図２３のフェーズＦ１０１）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【０１５６】
そして、タイマＴ１の計時をスタートさせ、（処理１１０３）、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理１１０４：図２３のフェーズＦ１０３）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１１０５：図２３のフェーズＦ１０４）。
【０１５７】
このとき予約する帯域としては、ファクシミリメッセージの伝送時に必要となる高速モデム（例えば33.6Kbps）用の帯域ではなく、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１５８】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理１１０６：図２３のフェーズＦ１０５）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１１０７のＮｏ）、リトライ回数が満了していない限り、処理１１０５に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１１０９のＮｏ）。
【０１５９】
リトライ回数が満了してしまった場合には（判断１１０９のＹｅｓ）、通信エラーとして、図２２の処理１３０８に移行する。
【０１６０】
リトライ回数の満了までに帯域予約が成功した場合には（判断１１０７のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存して（処理１１１０）、図２１の処理１２０１に移行し、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼する（処理１２０１：図２３のフェーズＦ１０６）。
【０１６１】
そのように、ネットワーク帯域が確保できて初めて、着信側のＧ３ファクス４０ｂに発呼するようにしているため、ネットワーク帯域が確保できず、結果的に通信エラーとなってしまうような電話網を介した発呼を行わないで済み、その分無駄な電話代を節約することができる。
【０１６２】
次に、処理１２０１における発呼に対する応答があるかを判断し（判断１２０２：図２３のフェーズＦ１０７）、応答があった場合には（判断１２０２のＹｅｓ）、通話／通信中や発呼トーンＣＮＧに対する応答がない等のエラーがあれば（判断１２０５のＹｅｓ）、図２２の処理１３０８に移行するが、それらのエラーがなければ（判断１２０５のＮｏ）、図２２の処理１３０１に移行する。
【０１６３】
判断１２０２において、応答がない場合には（判断１２０２のＮｏ）、処理１１０３で計時を開始したタイマＴ１の計時が満了するまで（判断１２０３のＹｅｓ）、ダミーのディジタル識別信号ＤＩＳのパケットを発信側のＴ．３８端末に対して送信する（判断１２０３のＮｏ、処理１２０４：図２３のフェーズＦ１０９ｂ）。タイマＴ１の計時が満了した場合は（判断１２０３のＹｅｓ）、図２２の処理１３０８に移行する。
【０１６４】
これは、電話網５０ｂ上の着信側Ｇ３ファクス４０ｂとは呼接続が完了していないのにパケット網上のＴ．３８端末とは、図２３のフェーズＦ１０８で呼接続が完了しているという不整合が一時的に生じている状態で、着信側Ｇ３ファクス４０ｂのリンギング検出回数が多めに設定されていた場合など、発信側Ｔ．３８端末がタイムアウトを起こしてしまう場合があることに鑑みての処理である。
【０１６５】
また、実際に発呼して回線接続されてみたらファクシミリ装置ではなく電話機だったということもあり、そのような場合に、パケット網上の発信側相手端末にＴ１タイムアウトが発生する前にダミーのＤＩＳを送出し、電話網上の着信側ファクスから応答がくるまでの間の時間を稼ぎ、着信側ファクスから正常にＤＩＳを受け取ったときにそれを発信側Ｔ．３８端末に対して再送することで、着信側ＧＷ１ｂと着信側ファクス４０ｂとのやりとりのに要する時間のために、発信側Ｔ．３８端末におけるタイムアウトが発生してしまうのを防止することができる。
【０１６６】
図２２の処理１３０１では、図２３のフェーズＦ１０８で確立されたデータチャンネルを使用して、フェーズＦ１０９のファクスプロトコル処理を開始する（処理１３０１）。
【０１６７】
そして、処理１３０１で開始されたフェーズＦ１０９のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理１３０２：図２３のフェーズＦ１０９ｅ）。
【０１６８】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理１３０３）。
【０１６９】
そして、処理１３０３で取得した必要ネットワーク帯域Ｂが、処理１１１０で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断１３０４。
【０１７０】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断１３０４のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図２３のフェーズＦ１０９ｇのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理１３０２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理１３０６：図２３のフェーズＦ１０９ｆ）、以後のフェーズＦ１０９のファクスプロトコル処理を行う（処理１３０７）。
【０１７１】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断１３０４のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理１３０２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理１３０５）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理１３０６：図２３のフェーズＦ１０９ｆ）、以後フェーズＦ１０９のファクスプロトコル処理を継続する（処理１３０７）。
【０１７２】
なお、処理１３０７におけるファクスプロトコル処理においては、図２３に示すように、フェーズＦ１０９ｉ、Ｆ１０９ｊの画情報のファクシミリメッセージの伝送終了後、伝送後手順に移行する前に、フェーズＦ１０９ｋ及びフェーズＦ１０９ｌにより、確保するネットワーク帯域を、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、フェーズＦ１０９ｍ以降の伝送後手順においても、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１７３】
処理１３０７のフェーズＦ１０９の通信が終了した後、判断１１０９がＹｅｓとなった後、判断１２０３がＹｅｓとなった後、または、判断１２０５がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理１３０８）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理１３０９）、処理を終了する。
【０１７４】
なお、この第６実施形態は、第５実施形態の変形例であるが、同様の変形は、第１及び第３実施形態にたいしても同様に適用できるのはいうまでもない。
【０１７５】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、図５及び図６に示した第１実施形態に係る着信処理の変形例である、第７実施形態に係る着信側処理について、図２４及び図２５を参照して説明する。また、図２４及び図２５に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図２６に示す。
【０１７６】
図２４において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図２６のフェーズＦ１１０）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理１４０１：図２６のフェーズＦ１１１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。
【０１７７】
相手端末がRSVに対応していなかった場合には（判断１４０２のＮｏ）、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理１４０３：図２６のフェーズＦ１１２）、その発呼に対する応答を受ける（処理１４０４：図２６のフェーズＦ１１３）。
【０１７８】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信し（処理１４０５：図２６のフェーズＦ１１４）、処理１４１０で、記憶装置５に予め記憶・登録していたネットワーク帯域を、確保ネットワーク帯域としてのbit_rate（＝Ａ）として取得し（処理１４１０）、図２６の処理１５０１に移行する。
【０１７９】
判断１４０２において、相手端末がRSVに対応していた場合には（判断１４０２のＹｅｓ）、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理１４０６）、その発呼に対する応答を受ける（処理１４０７）。
【０１８０】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理１４０８）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【０１８１】
その後、発信側の相手端末からRSVP_Pathメッセージを受信しない場合には（判断１４０９のＮｏ）、記憶装置５に予め記憶・登録していたネットワーク帯域を、確保ネットワーク帯域としてのbit_rate（＝Ａ）として取得し（処理１４１０）、図２６の処理１５０１に移行する。
【０１８２】
発信側の相手端末からRSVP_Pathメッセージを受信した場合には（判断１４０９のＹｅｓ）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１４１１）。
【０１８３】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【０１８４】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られることになるが、そのRSVP_Confのパケットが受信されない場合には（判断１４１２のＹｅｓ）、記憶装置５に予め記憶・登録していたネットワーク帯域を、確保ネットワーク帯域としてのbit_rate（＝Ａ）として取得し（処理１４１０）、図２６の処理１５０１に移行する。
【０１８５】
RSVP_Confのパケットが受信された場合には（判断１４１２のＹｅｓ）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１４１３のＮｏ）、リトライ回数が満了していない限り、処理１４１１に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１４１５のＮｏ）。
【０１８６】
リトライ回数が満了してしまった場合には（判断１４１５のＹｅｓ）、通信エラーとして、図２５の処理１５０８に移行する。
【０１８７】
リトライ回数の満了までに帯域予約が成功した場合には（判断１４１３のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存し（処理１４１６）、図２５の処理１５０１に移行する。
【０１８８】
これにより、以後の着信側ＧＷ１ｂにおけるパケット網６０ｂを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【０１８９】
図２５の処理１５０１では、図２６のフェーズＦ１１６で確立されたデータチャンネルを使用して、フェーズＦ１１７のファクスプロトコル処理を開始する（処理１５０１）。
【０１９０】
そして、処理１５０１で開始されたフェーズＦ１１７のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理１５０２：図２６のフェーズＦ１１７ｃ）。
【０１９１】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側、すなわち、Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理１５０３）。
【０１９２】
そして、処理１５０３で取得した必要ネットワーク帯域Ｂが、処理１４１６で保持していた、または、処理１４１０で取得した確保ネットワーク帯域Ａより広いか否かを判断する（判断１５０４）。
【０１９３】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断１５０４のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図２６のフェーズＦ１１７ｆのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理１５０２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理１５０６：図２６のフェーズＦ１１７ｅ）、以後のフェーズＦ１１７のファクスプロトコル処理を行う（処理１５０７）。
【０１９４】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断１５０４のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理１５０２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理１５０５：図２６のフェーズＦ１１７ｄ）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理１５０６：図２６のフェーズＦ１１７ｅ）、以後フェーズＦ１１７のファクスプロトコル処理を継続する。
【０１９５】
処理１５０７のフェーズＦ１１７の通信が終了した後、または、判断１４１５がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理１５０８）、相手端末がRSVP対応でない場合には（判断１５０９のＮｏ）、それで処理を終了するが、相手端末がRSVP対応の場合には（判断１５０９のＹｅｓ）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理１５０９）、処理を終了する。
【０１９６】
このように、確保ネットワーク帯域Ａをパケット網内のルータを介してを得るためには、前記パケット網上の相手端末装置が帯域予約機能対応でなければならず、また経路途中に介在するルータも帯域予約機能対応でなければならないことに鑑みて、あらかじめ確保すべきネットワーク帯域についての情報を自装置において記憶登録しておくことで、ファクシミリ通信に割り当てるネットワーク帯域をゲートウェイ装置自身が管理することができ、前記パケット網上の相手端末装置やルータが帯域予約機能に対応していない場合でも、ファクシミリ通信に必要な帯域を制限することができるようになる。
【０１９７】
なお、この第７実施形態は、第１実施形態の変形例であるが、同様の変形は、第２実施形態にたいしても同様に適用できるのはいうまでもない。また、従来のゲートウェイ装置に対して単にファクシミリ通信に割り当てる帯域を制限する目的のみの場合には、この第７実施形態を、第１または第２実施形態のRSVP手順を除いたものと組み合わせることも有用である。
【０１９８】
また、Ｇ３ファクシミリ通信においては、呼接続完了（SETUP/CONNECT）後、発信側においては、相手ファクシミリからのフラグ受信までの時間（35±5秒）、着信側においては、発信側からのDCS受信までの時間（35±5秒）としてのタイマーＴ１、ＣＦＲ送信から最初のPIX受信（6±1秒）までの時間としてのタイマーＴ２、コマンドに対する応答（3秒±15%）までの時間としてのタイマＴ４等の各種タイマ値が規定されているが、ファクシミリ通信では通信の各フェーズで許容する応答信号の最大タイムアウト値が異なるため、常に同じネットワーク遅延率を要求する必要はないことに鑑みて、以上説明した第１ないし第７実施形態において、上記タイマーの計時を開始する直前のタイミングで最大許容遅延率を変更したRSVP_resvメッセージを送出するようにすることで、すなわち、ルータに要求する許容する最大遅延率をファクシミリ伝送手順に定められた各タイマーに連動して変更することで、呼制御フェーズや能力交換フェーズ、データフェーズなどで、相手端末からの応答を待っているときに、ルータに要求する最大遅延率を個別に設定でき、より効率的にネットワーク資源を使用することができるようになる。
【０１９９】
なお、以上説明した実施の形態においては、ＧＷタイプのＴ．３８端末であるゲートウェイ装置１に本発明を適用したが、本発明はそれに限らず、ゲートウェイ装置１と同様なリアルタイムファクシミリ通信の中継機能を兼ね備えたＩＡＦタイプのＴ．３８端末（ネットワークファクシミリ装置）、ゲートウェイ装置１と同様なリアルタイムファクシミリ通信の中継機能を兼ね備えたＧ３ファクシミリ装置等に対しても同様に適用可能であることはいうまでもない。
【０２００】
【発明の効果】
請求項１に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、着信側の前記ファクシミリ装置から受信したファクシミリ制御信号の通信速度能力を書き換えて、発信側の前記相手端末装置に送信して、前記着信側のファクシミリ装置の通信速度能力を低く見せかけるようにすることにより、前記発信側の相手端末装置（当該相手端末装置がゲートウェイ装置の場合には電話網を介した発信側のファクシミリ装置）が自装置の通信速度能力と着信側からのファクシミリ制御信号により通知された通信速度能力との範囲内で決定・設定する実際の通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。
【０２０１】
請求項２に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、着信側の前記相手端末装置から受信したファクシミリ制御信号の通信速度能力を書き換えて、発信側の前記ファクシミリ装置に送信して、前記着信側の相手端末装置の通信速度能力を低く見せかけるようにすることにより、前記発信側のファクシミリ装置が自装置の通信速度能力と着信側からのファクシミリ制御信号により通知された通信速度能力との範囲内で決定・設定する実際の通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。
【０２０２】
請求項３に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、発信側の前記相手端末装置からファクシミリ制御信号で設定された通信速度でのモデムトレーニングが失敗したかのようにみせかけて最終的な設定通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。また、着信側からのファクシミリ制御信号による通信速度能力ではなく、発信側からのファクシミリ制御信号による設定通信速度により通信速度を調節するようにしているため、前記確保ネットワーク帯域の範囲内でネットワーク帯域の無駄のない最適通信速度に調節することができる利点がある。
【０２０３】
請求項４に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、発信側の前記ファクシミリ装置からファクシミリ制御信号で設定された通信速度でのモデムトレーニングが失敗したかのようにみせかけて最終的な設定通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。また、着信側からのファクシミリ制御信号による通信速度能力ではなく、発信側からのファクシミリ制御信号による設定通信速度により通信速度を調節するようにしているため、前記確保ネットワーク帯域の範囲内でネットワーク帯域の無駄のない最適通信速度に調節することができる利点がある。
【０２０４】
請求項５に係る発明によれば、ファクシミリ通信では通信手順の各フェーズで伝送速度が異なるため、データ転送フェーズで必要なネットワーク帯域を通信開始時から終了時まで占有してしまう必要はないことに鑑みて、一定のネットワーク帯域を確保するのではなく、呼制御フェーズや能力交換フェーズなど、データフェーズ以外の通信手順を行っているときに、ルータに要求するネットワーク帯域を減らすことで、トータルではより少ないネットワーク帯域で通信することが可能になり、より効率的にネットワーク資源を使用することが可能となる効果が得られる。
【０２０５】
請求項６に係る発明によれば、ネットワーク環境が劣悪な場合、ファクシミリ通信に必要な最低限の帯域を確保できないことがり、そのようなときに前記電話網上のファクシミリ装置に発呼することは電話代の無駄遣いになってしまうことに鑑みて、ファクシミリ通信がいずれ失敗することが推測できるような場合には前記電話網上のファクシミリ装置に発呼する前に通信を中止するようにしたため、無駄な電話代を節約することが可能となる効果が得られる。
【０２０６】
請求項７に係る発明によれば、前記確保ネットワーク帯域を得るためには、前記パケット網上の相手端末装置が帯域予約機能対応でなければならず、また経路途中に介在するルータも帯域予約機能対応でなければならないことに鑑みて、あらかじめ確保すべきネットワーク帯域についての情報を自装置において記憶登録しておくことで、ファクシミリ通信に割り当てるネットワーク帯域を本発明に係るゲートウェイ装置自身が管理することができ、前記パケット網上の相手端末装置やルータが帯域予約機能に対応していない場合でも、ファクシミリ通信に必要な帯域を制限することが可能となる効果が得られる。
【０２０７】
請求項８に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、発信側の前記相手端末装置からファクシミリ制御信号で設定された通信速度でのモデムトレーニングが失敗したかのようにみせかけて最終的な設定通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。また、着信側からのファクシミリ制御信号による通信速度能力ではなく、発信側からのファクシミリ制御信号による設定通信速度により通信速度を調節するようにしているため、前記確保ネットワーク帯域の範囲内でネットワーク帯域の無駄のない最適通信速度に調節することができる利点がある。
請求項９に係る発明によれば、ファクシミリ通信では通信手順の各フェーズで伝送速度が異なるため、データ転送フェーズで必要なネットワーク帯域を通信開始時から終了時まで占有してしまう必要はないことに鑑みて、一定のネットワーク帯域を確保するのではなく、呼制御フェーズや能力交換フェーズなど、データフェーズ以外の通信手順を行っているときに、ルータに要求するネットワーク帯域を減らすことで、トータルではより少ないネットワーク帯域で通信することが可能になり、より効率的にネットワーク資源を使用することが可能となる効果が得られる。
請求項１０に係る発明によれば、ネットワーク環境が劣悪な場合、ファクシミリ通信に必要な最低限の帯域を確保できないことがり、そのようなときに前記電話網上のファクシミリ装置に発呼することは電話代の無駄遣いになってしまうことに鑑みて、ファクシミリ通信がいずれ失敗することが推測できるような場合には前記電話網上のファクシミリ装置に発呼する前に通信を中止するようにしたため、無駄な電話代を節約することが可能となる効果が得られる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るゲートウェイ装置を含むリアルタイムネットワークファクシミリ通信システムの構成について示す図である。
【図２】本発明の実施の形態に係るゲートウェイ装置のブロック構成について示す図である。
【図３】本発明の実施の形態に係るゲートウェイ装置におけるソフトウェア構成について示す図である。
【図４】ＲＳＶＰを使用したＨ．３２３シーケンスの一例について示す図である。
【図５】本発明の実施の形態に係るゲートウェイ装置における第１実施形態に係る着信側処理手順について示すフローチャートである。
【図６】図５と共に、本発明の実施の形態に係るゲートウェイ装置における第１実施形態に係る着信側処理手順について示すフローチャートである。
【図７】図５及び図６の処理手順に対応する通信シーケンスについて示す図である。
【図８】本発明の実施の形態に係るゲートウェイ装置における第２実施形態に係る発信側処理手順について示すフローチャートである。
【図９】図８と共に、本発明の実施の形態に係るゲートウェイ装置における第２実施形態に係る発信側処理手順について示すフローチャートである。
【図１０】図８及び図９の処理手順に対応する通信シーケンスについて示す図である。
【図１１】本発明の実施の形態に係るゲートウェイ装置における第３実施形態に係る着信側処理手順について示すフローチャートである。
【図１２】図１１と共に、本発明の実施の形態に係るゲートウェイ装置における第３実施形態に係る着信側処理手順について示すフローチャートである。
【図１３】図１１及び図１２の処理手順に対応する通信シーケンスについて示す図である。
【図１４】本発明の実施の形態に係るゲートウェイ装置における第４実施形態に係る発信側処理手順について示すフローチャートである。
【図１５】図１４と共に、本発明の実施の形態に係るゲートウェイ装置における第４実施形態に係る発信側処理手順について示すフローチャートである。
【図１６】図１４及び図１５の処理手順に対応する通信シーケンスについて示す図である。
【図１７】本発明の実施の形態に係るゲートウェイ装置における第５実施形態に係る着信側処理手順について示すフローチャートである。
【図１８】図１７と共に、本発明の実施の形態に係るゲートウェイ装置における第５実施形態に係る着信側処理手順について示すフローチャートである。
【図１９】図１７及び図１８の処理手順に対応する通信シーケンスについて示す図である。
【図２０】本発明の実施の形態に係るゲートウェイ装置における第６実施形態に係る着信側処理手順について示すフローチャートである。
【図２１】図２０と共に、本発明の実施の形態に係るゲートウェイ装置における第６実施形態に係る着信側処理手順について示すフローチャートである。
【図２２】図２０及び図２１と共に、本発明の実施の形態に係るゲートウェイ装置における第６実施形態に係る着信側処理手順について示すフローチャートである。
【図２３】図２０、図２１及び図２２の処理手順に対応する通信シーケンスについて示す図である。
【図２４】本発明の実施の形態に係るゲートウェイ装置における第７実施形態に係る着信側処理手順について示すフローチャートである。
【図２５】図２４と共に、本発明の実施の形態に係るゲートウェイ装置における第７実施形態に係る着信側処理手順について示すフローチャートである。
【図２６】図２４及び図２５の処理手順に対応する通信シーケンスについて示す図である。
【符号の説明】
１、１ａ、1ｂ ゲートウェイ装置
２ システム制御部
３ ＲＯＭ
４ ＲＡＭ
５ 記憶装置
６ オペポート
７ ＬＡＮコントローラ
８ トランス
１２ モデム
１３ 網制御部
１４ システムバス
２０ａ、２０ｂ ＩＡＦ
３０ａ、３０ｂ ゲートキーパ装置
４０ａ、４０ｂ Ｇ３ファクス
５０、５０ａ、５０ｂ 電話網
６０、６０ａ、６０ｂ パケット網
７０ 通信ライン
８０ａ、８０ｂ ルータ
【発明の属する技術分野】
本発明は、電話網及びパケット網経由のリアルタイムファクシミリ通信を行う、ゲートウェイ装置及びその制御方法に関する。
【０００２】
【従来の技術】
公衆回線網を介したファクシミリ通信、具体的には、例えば、ＩＴＵ−Ｔ勧告Ｔ．３０に準拠したＧ（グループ）３ファクシミリ通信は、送信側端末と受信側端末とが直接ファクシミリ制御信号をやりとりしつつファクシミリメッセージの送受信を行う、リアルタイムの通信形態のため、送信側端末と受信側端末との間の能力交換が可能であり、また、通信中に受信側端末に受信エラーが生じれば、送信側端末でもファクシミリ制御信号の受信側端末とのやりとりに障害がでて送信エラーとなるため、送信側端末としては、ファクシミリメッセージを受信側端末に正しく送信できたか否かの判断が容易であるという利点がある。
【０００３】
その反面、公衆回線網を介したファクシミリ通信は、通信時間に応じた通信料金が課金されしまう欠点がある。
【０００４】
一方、インターネット等のパケット網においては、電子メールによる通信がよく用いられる。電子メールによるネットワーク通信は、通信料金が基本的に無料であるという利点がある。
【０００５】
その反面、電子メールによるネットワーク通信は、送信側端末と最終的な受信側端末との間にメールサーバが介在して、送信側端末からメールサーバへの電子メールの送信と、電子メールを最終的に受信する受信側端末のメールサーバからの自装置宛電子メールの受信とが、同時には行われない、非リアルタイムの通信形態であるため、送信側端末と受信側端末との間の能力交換が不可能であり、また、受信側端末における電子メールのメールサーバからの受信中に受信エラーが生じても、送信側端末では、既に電子メールの送信は正常に終了しているため、送信側端末としては、メッセージを電子メールにより受信側端末に正しく送信できたか否かの判断ができないという欠点がある。
【０００６】
そのため、例えば、送信側端末から電子メールにより送信した文書データの形式（ファイル形式、符号化形式、解像度等）に、受信側端末が未対応であるために、送信側端末における文書データの電子メールによる送信は成功したのに、受信側端末において受信文書データを正しく処理できず、結果的に文書データの送信が失敗に終わってしまうという不具合が生じてしまうことがあった。
【０００７】
そこで、公衆電話網を介したファクシミリ通信の利点である端末間の能力交換及びリアルタイム性と、ネットワークを介した通信の、通信料金がかからないという利点とを両立した通信形態として、１９９９年４月に、パケット化したファクシミリ制御信号をパケット網上でやり取りするためのITU-T勧告T.38/H.323 AnnexDが制定された。
【０００８】
このITU-T勧告T.38/H.323 AnnexDに基づいた通信を行うことにより、端末間のファクシミリ通信に関する能力交換および通信のリアルタイム性が保証された通信をネットワーク上で行うことができるようになった。
【０００９】
ITU-T勧告T.38/H.323 AnnexDに従うネットワーク端末（Ｔ．３８端末）には、ネットワーク直結型のＩＡＦ（Internet Aware Fax）タイプと、専用線や公衆回線等の電話網へリアルタイムに転送するＧＷ（Gateway）タイプとの２種類が存在する。
【００１０】
ＩＡＦタイプの端末は、いわば、相手端末装置（ＩＡＦまたはＧＷ）との間でパケット化されたファクシミリ制御信号としてのＴ．３０信号をリアルタイムでやりとりして、自装置が相手端末装置にとっての最終宛先として文書データを受信するネットワークファクシミリ装置である。
【００１１】
一方、ＧＷタイプの端末は、ネットワークを介して相手端末（ＩＡＦまたはＧＷ）から受信したパケットから抽出したＴ．３０信号をモデム信号に変換して電話網を介して最終宛先となるＧ３ファクシミリ装置へ転送し、また電話網を介して前記Ｇ３ファクシミリ装置からモデム信号として受信したＴ．３０信号をパケット化してネットワークを介して相手端末に転送することで、ネットワーク上のＴ．３８端末と電話網上の従来型のファクシミリ装置との間でのリアルタイム通信を可能とするものである。
【００１２】
Ｔ．３８準拠のＧＷタイプの端末は、受信したＩＰパケットを、情報内容はそのままにＴ．３０信号に変換して電話網へ転送し、また電話網から受けたＴ．３０信号を情報内容はそのままにＩＰパケットに変換してパケット網に転送することで、ＩＰネットワーク上のＴ．３８端末と電話網上の従来型のＧ３ファクシミリ装置との間でのリアルタイム通信を可能とするものに過ぎないため、ファクシミリメッセージ伝送時の高速モデムでの通信速度は、電話網を介して自装置と回線接続される、従来型のＧ３ファクシミリ装置と、パケット網を介して自装置とネットワーク接続されるＩＡＦタイプの端末、または、パケット網を介して自装置とネットワーク接続されるＧＷタイプの端末から更に電話網を介して接続される従来型のＧ３ファクシミリ装置との間のＴ．３０に基づいたプロトコル手順により設定される。
【００１３】
具体的には、着信側装置がディジタル識別信号ＤＩＳにより、対応している通信速度を含む自機能力を発信側装置に通知し、その発信側装置がその通知された着信側装置の能力と自機能力との範囲内で通信条件を設定すると同時にその設定した通信条件をディジタル送信命令信号ＤＣＳにより着信側装置にも通知して設定させる。
【００１４】
したがって、ＧＷタイプの端末が接続されるパケット網における当該ＧＷタイプの端末が使用を許されるネットワーク帯域は、終端の端末間でＴ．３０に基づいたプロトコル手順により設定された通信速度でのメッセージデータの伝送を実現できるだけの十分な広さが確保されることがＴ．３８準拠のリアルタイムネットワークファクシミリ通信の前提となっていた。
【００１５】
そのため、仮に、ＧＷタイプの端末がパケット網上で使用可能なネットワーク帯域が終端の端末間でＴ．３０に基づいたプロトコル手順により設定された通信速度でのメッセージデータの伝送に十分でない場合、設定された通信速度でのメッセージデータの送受信を行うことができず、通信エラーとなってしまうという問題がある。
【００１６】
一方、ファクシミリ通信が頻繁に行われていないオフィス等においては、ファクシミリ通信用の十分なネットワーク帯域（64Kbps程度）をＧＷタイプの端末に割り当てることは、他のアプリケーションの帯域を縮小することにつながるため効率的ではないという事情がある。特にＩＳＤＮルータなどを使用して構築しているパケット網などではベースとなる帯域が64K〜128Kbps程度と狭いため、その中からファクシミリ通信のための十分な帯域を確保すること自体が難しくなるという問題がある。
【００１７】
それらの問題は、ITU-T勧告T.38/H.323 AnnexD準拠のものに限らず、電話網上でやりとりされるＴ．３０信号とパケット網上でやりとりされるパケット化されたＴ．３０信号とをリアルタイムに相互変換して行われるリアルタイムネットワークファクシミリ通信においては、同様に生じ得る問題である。
【００１８】
【発明が解決しようとする課題】
そこで、本願発明の発明者は、ゲートキーパが有するネットワーク帯域管理機能を用いてその問題の解決を図った技術を提案しているが（特願２０００−４０２４９４号）、現状ではまだ高価なゲートキーパを必要とする技術のため、設備投資の費用が増大してしまうという課題があった。また、現状では帯域管理機能を有しないゲートキーパも市販されているという課題もあった。
【００１９】
一方、ITU-T勧告H.323のAppendixIIではRSVP(Resource ReSerVation Protocol=ネットワークリソースを管理するプロトコル）を用いて通信に必要なネットワーク帯域の予約をルータに対して行う方法についての記述がある。なお、RSVPの仕様についてはRFC2205にて規定されている。
【００２０】
本発明は係る事情に鑑みてなされたものであり、前記ファクシミリ装置と前記相手端末装置との間で設定される通信速度でのリアルタイムネットワークファクシミリ通信を実現するために前記パケット網において必要とされるネットワーク帯域として十分なネットワーク帯域を、ルータへのネットワーク帯域予約により、確保することができるゲートウェイ装置及びその制御方法を提供することを目的とする。
【００２１】
【課題を解決するための手段】
請求項１に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、着信側の前記ファクシミリ装置から前記電話網を介して受信したファクシミリ制御信号内の通信速度能力に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、前記ファクシミリ制御信号内の通信速度能力を、前記確保ネットワーク帯域に相当する通信速度以下に書き換えた上でパケット化して前記パケット網上の相手端末装置に送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２２】
請求項２に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、着信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の通信速度能力に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、前記ファクシミリ制御信号内の通信速度能力を、前記確保ネットワーク帯域に相当する通信速度以下に書き換えた上でモデム信号化して前記電話網上の発信側の前記ファクシミリ装置に送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２３】
請求項３に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、発信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記相手端末装置から前記パケット網を介して受信したモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側の相手端末装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２４】
請求項４に記載のゲートウェイ装置は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、発信側の前記ファクシミリ装置から前記電話網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記ファクシミリ装置から前記電話網を介して受信した所定のモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側のファクシミリ装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とする。
【００２５】
請求項５に記載のゲートウェイ装置は、請求項１、２、３または４のいずれかに記載のゲートウェイ装置において、前記通信速度／ネットワーク帯域調節手段は、前記ルータに要求して確保する前記確保ネットワーク帯域を、前記相手端末装置と前記ファクシミリ装置との間のリアルタイムファクシミリ通信におけるファクシミリ伝送手順の各フェーズで変更することを特徴とする。
【００２６】
請求項６に記載のゲートウェイ装置は、請求項３に記載のゲートウェイ装置において、前記通信速度／ネットワーク帯域調節手段は、前記パケット網上の発信側の前記相手端末装置と、前記電話網上の着信側のファクシミリ装置との間のリアルタイムネットワークファクシミリ通信を中継する場合に、前記ルータに要求して確保した前記確保ネットワーク帯域が、ファクシミリ通信に必要な所定の最低限帯域以下の場合には、前記ファクシミリ装置への前記電話網を介した発呼を行わないで通信を中止することを特徴とする。
【００２７】
請求項７に記載のゲートウェイ装置は、請求項１、２、３または４のいずれかに記載のゲートウェイ装置において、前記通信速度／ネットワーク帯域調節手段は、前記ルータにネットワーク帯域を要求した結果、前記ルータが帯域予約機能を備えていなかった場合、予め記憶登録しておいた帯域情報を前記確保ネットワーク帯域とすることを特徴とする。
【００２８】
請求項８に記載のゲートウェイ装置の制御方法は、パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置の制御方法であって、発信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記相手端末装置から前記パケット網を介して受信したモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側の相手端末装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手順を含むことを特徴とする。
請求項９に記載のゲートウェイ装置の制御方法は、請求項８に記載のゲートウェイ装置の制御方法において、前記通信速度／ネットワーク帯域調節手順は、前記ルータに要求して確保する前記確保ネットワーク帯域を、前記相手端末装置と前記ファクシミリ装置との間のリアルタイムファクシミリ通信におけるファクシミリ伝送手順の各フェーズで変更することを特徴とする。
請求項１０に記載のゲートウェイ装置の制御方法は、請求項８に記載のゲートウェイ装置の制御方法において、前記通信速度／ネットワーク帯域調節手順は、前記パケット網上の発信側の前記相手端末装置と、前記電話網上の着信側のファクシミリ装置との間のリアルタイムネットワークファクシミリ通信を中継する場合に、前記ルータに要求して確保した前記確保ネットワーク帯域が、ファクシミリ通信に必要な所定の最低限帯域以下の場合には、前記ファクシミリ装置への前記電話網を介した発呼を行わないで通信を中止することを特徴とする。
【００２９】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を詳細に説明する。
【００３０】
なお、以下説明する実施の形態においては、電話網上の、ITU-T勧告T.30準拠のＧ３ファクシミリ装置と、パケット網上のITU-T勧告T.38/H.323 AnnexD準拠の相手端末装置（ゲートウェイ装置またはネットワークファクシミリ装置）との間にITU-T勧告T.38/H.323 AnnexD準拠のゲートウェイ装置が介在して行われるリアルタイムネットワークファクシミリ通信に本発明を適用している。
【００３１】
しかし、今後勧告の進展により、Ｇ３ファクシミリ装置以外のファクシミリ装置（例えばＧ４ファクシミリ装置）と、パケット網上の相手端末装置との間のゲートウェイ装置を介したリアルタイムネットワークファクシミリ通信が、Ｔ．３８に代わる新たな勧告が規定される等して実現されたような場合には、本発明を、本発明の趣旨を逸脱せず本質的に同じ構成で適用することができるのはいうまでもない。
【００３２】
先ず、図１に、本発明の実施の形態に係るゲートウェイ装置１を含むリアルタイムネットワークファクシミリ通信システムの構成例について示す。
【００３３】
同図に示すシステムは、説明の便宜上、左側の着信側システムと、右側の発信側システムとが、一定のネットワーク帯域（例えば64kbbs）の通信ライン７０により接続されたシステムとなっている。
【００３４】
発信側のＧ３ファクシミリ装置であるＧ３ファクス４０ａは、電話網５０ａを介して、発信側Ｔ．３８端末装置としてのゲートウェイ装置（ＧＷ）１ａに発呼して宛先指定を行う。
【００３５】
発信側Ｔ．３８端末装置としてのネットワークファクシミリ装置（ＩＡＦ）２０ａは、自装置の操作部等から宛先指定を直接受ける。
【００３６】
発信側Ｔ．３８端末装置としてのＧＷ１ａやＩＡＦ２０ａは、パケット網６０ａにおいてルータ８０ｂを介して通信を行い、宛先の着信側Ｔ．３８端末装置としてのＧＷ１ｂやＩＡＦ２０ｂに通信ライン７０及びパケット網６０ｂを介してT.38/H.323 AnnexDパケット信号を送信する。
【００３７】
一方、着信側Ｔ．３８端末装置としてのＧＷ１ｂやＩＡＦ２０ｂは、パケット網６０ｂにおいてルータ８０ｂを介して通信を行い、発信側Ｔ．３８端末装置としてのＧＷ１ａやＩＡＦ２０ａ（を介したＧ３ファクス４０ａ）との間でパケット網６０ｂ及び通信ライン７０を介してT.38/H.323 AnnexDパケット信号をやりとりしてリアルタイムネットワークファクシミリ通信を行う。
【００３８】
なお、ＧＷ１ｂは、更に、発信側からＳＥＴＵＰパケットにより通知される電話網５０ｂ上の着信側のＧ３ファクス４０ｂに発呼して、Ｇ３ファクス４０ｂと、発信側Ｔ．３８端末装置との間のリアルタイムネットワークファクシミリ通信を中継する。
【００３９】
ＧＷ１ａは、パケット網６０ａ上から渡されたT.38/H.323 AnnexDパケット信号をT.30信号に変換して、電話網５０ａ上のＧ３ファクス４０ａに転送する一方、電話網５０ａ上から渡されたT.30信号をT.38/H.323 AnnexDパケット信号に変換してパケット網６０ａを介して転送する。
【００４０】
ＧＷ１ｂは、パケット網６０ｂ上から渡されたT.38/H.323 AnnexDパケット信号をT.30信号に変換して、電話網５０ｂ上のＧ３ファクス４０ｂに転送する一方、電話網５０ｂ上から渡されたT.30信号をT.38/H.323 AnnexDパケット信号に変換してパケット網６０ｂを介して転送する。
【００４１】
本発明は、ＧＷ１ｂまたはＩＡＦ２０ｂの着信側Ｔ．３８端末装置にとっての発信側ＧＷ１ａとなって、発信側Ｇ３ファクス４０ａと着信側Ｔ．３８端末装置との間のリアルタイムネットワークファクシミリ通信を中継する場合、または、ＧＷ１ａまたはＩＡＦ２０ａの発信側Ｔ．３８端末装置にとっての着信側ＧＷ１ｂとなって、着信側Ｇ３ファクス４０ｂと発信側Ｔ．３８端末装置との間のリアルタイムネットワークファクシミリ通信を中継する場合についてのものである。
【００４２】
図２に発信側ゲートウェイ装置１ａまたは着信側ゲートウェイ装置１ｂとなるゲートウェイ装置１のブロック構成について示す。
【００４３】
同図において、ゲートウェイ装置１は、システム制御部２、ＲＯＭ３、ＲＡＭ４、記憶装置５、オペポート６、ＬＡＮコントローラ７、トランス８、モデム９、網制御部１０、及び、システムバス１１により構成されている。
【００４４】
システム制御部２は、ＲＯＭ３に書き込まれた制御プログラムに従って、ＲＡＭ４を作業領域として使用しながら、装置各部を制御するマイクロコンピュータである。
【００４５】
ＲＯＭ３は、前述したように、システム制御部２が上記装置各部を制御するための制御プログラムが記憶されているリードオンリメモリである。ＲＡＭ４は、前述したようにシステム制御部２の作業領域として使用されるランダムアクセスメモリである。
【００４６】
記憶装置５は、ハードディスク装置等により構成され、データを蓄積するためのものである。操作表示部６は、装置の動作状態の表示や各種操作入力を受け付けるためのものである。
【００４７】
ＬＡＮコントローラ１０は、トランス８を介してパケット網６０から受信したデータのデコード、またパケット網６０へ送信するデータのエンコードを行ったり、送信フレームや受信フレームのバッファリングを行うことで、パケット網６０からのデータを送受信するためのトランスフォーマーであるトランス８を介したＬＡＮプロトコルを制御して、そのＬＡＮプロトコル上でシステム制御部２がＴＣＰ／ＩＰプロトコルを制御して、T.38/H.323 AnnexDに基づいたリアルタイムネットワークファクシミリ通信を行えるようにするためのものである。
【００４８】
モデム９は、Ｇ３ファクシミリモデムで、網制御部１０を介して電話網５０に送信するデータを変調する一方、網制御部１０を介して電話網５０から受信した信号を復調するものである。また、モデム９は、相手先番号に対応するＤＴＭＦ信号の送出も行う。
【００４９】
網制御部１０は、電話網５０に接続されて、電話網５０の回線の極性反転の検出、回線の直流ループの閉結・解放や、回線解放の検出、発信音の検出、ビジートーン等のトーン信号の検出、呼出信号の検出等の回線との接続制御や、相手先番号に対応する選択信号の、２０ＰＰＳまたは１０ＰＰＳのダイヤル回線に対応したダイヤルパルス信号による送出を行うものである。システムバス１１は、上記各部がデータをやり取りするための信号ラインである。
【００５０】
図３に、ゲートウェイ装置１におけるソフトウェア構成を示す。
【００５１】
ゲートウェイ装置１は、T.38/H.323 AnnexDに従うＧＷタイプのネットワーク端末であり、電話網５０を介したT.30に基づいたＧ３ファクシミリ通信機能と、そのＧ３ファクシミリ通信機能と並行して実行される、パケット網６０を介したT.38/H.323 AnnexDにもとづいたパケット通信機能とを備えたものとして構成されている。
【００５２】
そのため、図３に示すソフトウェア構成においては、「ファクスプロトコル（Ｔ．３０）制御」は、電話網でのファクスデータ通信を行う「ＭＯＤＥＭ制御」と、「ＬＡＮコントローラ制御」、ネットワークを制御するための「ＴＣＰ／ＩＰ」プロトコル、及びリアルタイムネットワークファクシミリ通信を制御するための「Ｔ．３８パケット制御」より構成されるプロトコルスタックとの双方の上に位置する。更に、「ファクスプロトコル（Ｔ．３０）制御」の上には、「オペポート制御」、及び、装置動作全体の統括的制御を行う「全体制御」が位置する。
【００５３】
次に、本発明を実現するために使用するRSVP(Resource ReSerVation Protocol=ネットワークリソースを管理するプロトコル）を用いた通信の基本シーケンスについて、図４に示す。なお、RSVPは、ITU-T勧告H.323のAppendixIIに記述された、通信に必要なネットワーク帯域の予約をルータに対して行うことが可能なプロトコルで、その仕様についてはRFC2205にて規定されている。
【００５４】
図４において、ゲートウェイ装置ＧＷやＩＡＦ等のＨ．３２３端末が、パケット網内のルータを介して、相手先のＨ．３２３端末であるゲートウェイ装置ＧＷを介して、電話網上の電話（Ｔｅｌ）／ファクス（ＦＡＸ）との間で通信を行う場合、Ｈ．３２３端末間で呼制御用ＴＣＰチャンネルを確立し（フェーズＦ１）、ＯＬＣ(OpenLogicalChannel)メッセージを送信・受信する（フェーズＦ２）。ＯＬＣを受信したゲートウェイ装置ＧＷは、Ｔｅｌ／ＦＡＸに対して発呼し（フェーズＦ３）、Ｔｅｌ／ＦＡＸが応答すると（フェーズＦ４）、ＯＬＣ＿Ａｃｋメッセージを返す（フェーズＦ５）。
【００５５】
そして、発信側から着信側に各ルータを介してRSVP_Pathメッセージを送信し（フェーズＦ６ａ、Ｆ６ｂ、Ｆ６ｃ）、それに対して着信側が、帯域確保要求のRSVP_Resvメッセージを各ルータを介して返信することにより（フェーズＦ７ａ、７ｂ、７ｃ）、ネットワーク待機の確保要求を行う。発信側は、それに対して、各ルータを介して帯域確保成功を示す応答（RSVP_Conf）を行い（フェーズＦ８ａ、Ｆ８ｂ、Ｆ８ｃ）、以後、その確保されたネットワーク帯域を用いて、音声／データ通信を行う（フェーズＦ９）。
【００５６】
フェーズＦ９の通信が終了すると、発信側はＣＬＣ（CloseLogicalChannel）メッセージを送信し、それを着信側が受信すると（フェーズＦ１０）、着信側のゲートウェイ装置ＧＷは、Ｔｅｌ／ＦＡＸとの間で接続されている回線を切断すると共に（フェーズＦ１１）、帯域解放を示すRSVP_Tearメッセージを発信側のＨ．３２３端末に返信してリソースの解放を行い通信を終了する。
【００５７】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、第１実施形態に係る着信側処理について、図５及び図６を参照して説明する。また、図５及び図６に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図７に示す。
【００５８】
図５において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図７のフェーズＦ１０）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理１０１：図７のフェーズＦ１１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【００５９】
着信側ＧＷ１ｂは、処理１０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、続いて、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理１０２：図７のフェーズＦ１２）、その発呼に対する応答を受ける（処理１０３：図７のフェーズＦ１３）。
【００６０】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理１０４：図７のフェーズＦ１４）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【００６１】
その後、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理１０５：図７のフェーズＦ１５）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１０６：図７のフェーズＦ１６）。
【００６２】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【００６３】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理１０７：図７のフェーズＦ１７）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１０８のＮｏ）、リトライ回数が満了していない限り、処理１０６に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１１０のＮｏ）。
【００６４】
リトライ回数が満了してしまった場合には（判断１１０のＹｅｓ）、通信エラーとして、図６の処理２０８に移行する。
【００６５】
リトライ回数の満了までに帯域予約が成功した場合には（判断１０８のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存し（処理１１１：図７のフェーズＦ１８）、図６の処理２０１に移行する。
【００６６】
これにより、以後の着信側ＧＷ１ｂにおけるパケット網６０ｂを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【００６７】
図６の処理２０１では、図７のフェーズＦ１９で確立されたデータチャンネルを使用して、フェーズＦ２０のファクスプロトコル処理を開始する（処理２０１）。
【００６８】
そして、処理２０１で開始されたフェーズＦ２０のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理２０２：図７のフェーズＦ２０ｃ）。
【００６９】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側、すなわち、Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理２０３）。
【００７０】
そして、処理２０３で取得した必要ネットワーク帯域Ｂが、処理１１１で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断２０４）。
【００７１】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断２０４のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図７のフェーズＦ２０ｆのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理２０２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理２０６：図７のフェーズＦ２０ｅ）、以後のフェーズＦ２０のファクスプロトコル処理を行う（処理２０７）。
【００７２】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断２０４のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理２０２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理２０５：図７のフェーズＦ２０ｄ）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理２０６：図７のフェーズＦ２０ｅ）、以後フェーズＦ２９のファクスプロトコル処理を継続する。
【００７３】
処理２０７のフェーズＦ２０の通信が終了した後、または、判断１１０がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理２０８）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理２０９）、処理を終了する。
【００７４】
このように、着信側Ｇ３ファクス４０ｂから受信したディジタル識別信号ＤＩＳの内容を着信側ＧＷ１ｂが変換することにより、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）に対して、着信側Ｇ３ファクス４０ｂの通信速度能力が低いとみせかけて、帯域オーバーとなるような通信速度が発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）において設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず、常に正常なリアルタイムネットワーク通信の中継が可能となる。
【００７５】
次に、本発明の実施の形態に係るゲートウェイ装置１が発信側ゲートウェイ装置１ａとして行う、第２実施形態に係る発信側処理について、図８及び図９を参照して説明する。また、図８及び図９に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１０に示す。
【００７６】
図８において、発信側ＧＷ１ａは、図１０のフェーズＦ３０に示す発信側Ｇ３ファクス４０ａからの電話網５０ａを介した着呼を受け（処理３０１）、その着呼に対して図１０のフェーズＦ３１に示す応答を行う（処理３０２）。
【００７７】
そして、図１０のフェーズＦ３２により着信側の宛先（ＩＰアドレス（及びファクス番号））を取得すると、発信側ＧＷ１ａは、呼制御用ＴＣＰチャンネルの確立後（図１０のフェーズＦ３３）、着信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）に対してＳＥＴＵＰパケットを送信する（処理３０３：図１０のフェーズＦ３４）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を通知する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、自端末がRSVPをサポートしていることを相手に通知する。
【００７８】
そして、着信側Ｔ．３８端末装置からＣＯＮＮＥＣＴパケットを受信する（処理３０４：図１０のフェーズＦ３５）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、着信側もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージが返されるものとする）。
【００７９】
着信側がRSVプロトコルをサポートしていないことが分かった場合には、従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【００８０】
相手端末がRSVプロトコルをサポートしている場合、続いて、RSVP_Pathメッセージを送信し（処理３０５：図１０のフェーズＦ３６）、ネットワーク上のルータのパスを通知し帯域予約要求を行う。このとき、経路途中のルータにより、エラー（PathError）が返ってきた場合、通常手順通信あるいはエラー終了するが、RSVP_Resvメッセージが受信されると、リソースの予約要求が受け入れられるたことになる（処理３０６：図１０のフェーズＦ３７）。
【００８１】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【００８２】
RSVP_Resvメッセージが受信されて帯域予約が成功すると、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存すると共に（処理３０７：図１０のフェーズＦ３８）、帯域確保成功を示す応答（RSVP_Conf）を相手端末に送信する（処理３０８：図１０のフェーズＦ３９）。
【００８３】
これにより、以後の発信側ＧＷ１ａにおけるパケット網６０ａを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【００８４】
処理３０９では、図１０のフェーズＦ４０で確立されたデータチャンネルを使用して、フェーズＦ４１のファクスプロトコル処理を開始する（処理３０９）。
【００８５】
そして、処理３０９で開始されたフェーズＦ４１のファクスプロトコル処理、すなわち、パケット網６０ａを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等の、ファクシミリ制御信号としてのＴ．３０信号のパケットを受信し、モデム信号へ変換し、電話網５０ａを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのパケットを受信する（処理４０１：図１０のフェーズＦ４１ｃ）。
【００８６】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側、すなわち、ＩＡＦ２０ｂ、または、ＧＷ１ｂを介したＧ３ファクス４０ｂの通信速度能力に対応する必要ネットワーク帯域Ｂを調査する（処理４０２）。
【００８７】
そして、処理４０２で取得した必要ネットワーク帯域Ｂが、処理３０７で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断４０３）。
【００８８】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断４０３のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側Ｇ３ファクス４０ａにより、図１０のフェーズＦ４１ｆのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ａにおいて帯域オーバーが生じることがないため、処理４０１でパケットとして受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側Ｇ３ファクス４０ａにモデム信号として送信し（処理４０５：図１０のフェーズＦ４１ｅ）、以後のフェーズＦ４１のファクスプロトコル処理を行う（処理２０７）。
【００８９】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断４０３のＹｅｓ）、そのままでは、着信側Ｔ．３８端末の通信速度能力以上の通信速度能力を、発信側Ｇ３ファクス４０ａが備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ａにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理４０１でパケットとして受信したディジタル識別信号ＤＩＳのファクシミリ情報フィールドの情報内容のうちの、通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂか゜なるような通信速度能力（例えば7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理４０４：図１０のフェーズＦ４１ｄ）、その書換え変換後のディジタル識別信号ＤＩＳを、モデム信号に変換して発信側Ｇ３ファクス４０ａに送信し（処理４０５：図１０のフェーズＦ４１ｅ）、以後フェーズＦ４１のファクスプロトコル処理を継続する。
【００９０】
処理４０６のフェーズＦ４１の通信が終了した後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを送信し（処理４０７）、それに対する相手端末からの帯域解放（RSVP_Tear）のパケットを受信してリソースの解放が行われて（処理４０８）、処理が終了する。
【００９１】
このように、着信側Ｔ．３８端末から受信したディジタル識別信号ＤＩＳの内容を発信側ＧＷ１ａが変換することにより、発信側Ｇ３ファクス４０ａに対して、着信側Ｔ．３８端末の通信速度能力が低いとみせかけて、帯域オーバーとなるような通信速度が発信側Ｇ３ファクス４０ａにおいて設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず、常に正常なリアルタイムネットワーク通信の中継が可能となる。
【００９２】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、第３実施形態に係る着信側処理について、図１１及び図１２を参照して説明する。また、図１１及び図１２に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１３に示す。
【００９３】
図１１において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図１３のフェーズＦ５０）、発信側Ｔ．３８端末（ＩＡＦ６０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理５０１：図１３のフェーズＦ５１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【００９４】
着信側ＧＷ１ｂは、処理５０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、続いて、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理５０２：図１３のフェーズＦ５２）、その発呼に対する応答を受ける（処理５０３：図１３のフェーズＦ５３）。
【００９５】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理５０４：図１３のフェーズＦ５４）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【００９６】
その後、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理５０５：図１３のフェーズＦ５５）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理５０６：図１３のフェーズＦ５６）。
【００９７】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【００９８】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理５０７：図１３のフェーズＦ５７）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断５０８のＮｏ）、リトライ回数が満了していない限り、処理５０６に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断５１０のＮｏ）。
【００９９】
リトライ回数が満了してしまった場合には（判断５１０のＹｅｓ）、通信エラーとして、図１２の処理６０８に移行する。
【０１００】
リトライ回数の満了までに帯域予約が成功した場合には（判断５０８のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存し（処理５１１：図１３のフェーズＦ５８）、図１３のフェーズＦ５９により確立されたデータチャンネル上でフェーズＦ６０のファクスプロトコル処理を開始して、着信側Ｇ３ファクス４０ｂからディジタル識別信号ＤＩＳのモデム信号を受信すると（処理５１２：図１３のフェーズＦ６０ｃ）、その受信したディジタル識別信号ＤＩＳのモデム信号を内容の変更なしにそのままパケットに変換して発信側Ｔ．３８端末に送信してしまう（処理５１３：図１３のフェーズＦ６０ｄ）。
【０１０１】
すると、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）は、フェーズＦ６０ｄで通知された着信側の通信速度能力と自装置の通信速度能力の範囲内の通信速度（通常は最大の通信速度）を設定して、その他の通信パラメータの設定と共にディジタル送信命令信号ＤＣＳにより送信してくるため、そのディジタル送信命令信号ＤＣＳを受信する（図１２の処理６０１：図１３のフェーズＦ６０ｅ）。
【０１０２】
そして、その受信したディジタル送信命令信号ＤＣＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される発信側が対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理６０２）。
【０１０３】
そして、処理６０２で取得した必要ネットワーク帯域Ｂが、処理５１１で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断６０３）。
【０１０４】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以上の場合には（判断６０３のＹｅｓ）、発信側Ｔ．３８端末からトレーニングチェック信号ＴＣＦのパケットを受信する（処理６０４：図１３のフェーズＦ６０ｆ）。ただし、その場合受信したＴＣＦ信号のパケットについては、モデム信号に変換して着信側Ｇ３ファクス４０ｂに送信する処理は行わない。
【０１０５】
そして、その受信したＴＣＦ信号のパケットに対して、トレーニングエラー信号ＦＴＴのパケットを発信側Ｔ．３８端末に送信して（処理６０５：図１３のフェーズＦ６０ｇ）、処理６０１に戻る。その場合処理６０１で受信するディジタル送信命令信号ＤＣＳの通信速度の設定は、トレーニングエラー信号ＦＴＴの受信を受けて、発信側Ｔ．３８端末（を介したＧ３ファクス４０ａ）において前に設定した速度よりも遅く設定されていることになる。
【０１０６】
そのため、判断６０３がＹｅｓとなった場合でも、判断６０３のＹｅｓのループが１回または複数回繰り返されることで、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも狭くなり、判断６０３がＮｏとなる。
【０１０７】
判断６０３がＮｏとなって初めて、処理６０１でパケットとして受信したディジタル識別信号ＤＩＳをモデム信号に変換して、着信側Ｇ３ファクス４０ｂに送信し（処理６０６：図１３のフェーズＦ６０ｉ）、以後フェーズＦ６０のファクスプロトコル処理を継続する（処理６０７）。
【０１０８】
処理６０７のフェーズＦ６０の通信が終了した後、または、判断５１０がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理６０８）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理６０９）、処理を終了する。
【０１０９】
このように、発信側Ｔ．３８端末から受信したディジタル送信命令信号ＤＣＳにより設定された通信速度ではモデムトレーニングが失敗してしまうとみせかけて、帯域オーバーとなるような通信速度が発信側Ｔ．３８端末（を介したＧ３ファクス４０ａ）において設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず常に正常なリアルタイムネットワーク通信の中継が可能となり、また、発信側のＴ．３８端末（を介したＧ３ファクス４０ａ）において最終的に設定される通信速度に合わせて必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下になるように調節されるため、確保ネットワーク帯域Ａを無駄なく使用して効率的なファクシミリ通信が可能となる。
【０１１０】
次に、本発明の実施の形態に係るゲートウェイ装置１が発信側ゲートウェイ装置１ａとして行う、第４実施形態に係る発信側処理について、図１４及び図１５を参照して説明する。また、図１４及び図１５に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１６に示す。
【０１１１】
図１４において、発信側ＧＷ１ａは、図１６のフェーズＦ７０に示す発信側Ｇ３ファクス４０ａからの電話網５０ａを介した着呼を受け（処理７０１）、その着呼に対して図１６のフェーズＦ７１に示す応答を行う（処理７０２）。
【０１１２】
そして、図１６のフェーズＦ７２により着信側の宛先（ＩＰアドレス（及びファクス番号））を取得すると、発信側ＧＷ１ａは、呼制御用ＴＣＰチャンネルの確立後（図１６のフェーズＦ７３）、着信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）に対してＳＥＴＵＰパケットを送信する（処理７０３：図１６のフェーズＦ７４）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を通知する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、自端末がRSVPをサポートしていることを相手に通知する。
【０１１３】
続いて、RSVP_Pathメッセージを送信し（処理７０４：図１６のフェーズＦ７５）、ネットワーク上のルータのパスを通知し帯域予約要求を行う。このとき、経路途中のルータにより、エラー（PathError）が返ってきた場合、通常手順通信あるいはエラー終了するが、RSVP_Resvメッセージが受信されると、リソースの予約要求が受け入れられたことになる（処理７０５：図１６のフェーズＦ７６）。
【０１１４】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【０１１５】
RSVP_Resvメッセージが受信されて帯域予約が成功すると、帯域確保成功を示す応答（RSVP_Conf）を相手端末に送信すると共に（処理７０６：図１６のフェーズＦ７７）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存する（処理７０７：図１６のフェーズＦ７８）。
【０１１６】
そして、着信側Ｔ．３８端末装置からＣＯＮＮＥＣＴパケットを受信する（処理７０８：図１６のフェーズＦ７９）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、着信側もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージが返されるものとする）。
【０１１７】
着信側がRSVプロトコルをサポートしていないことが分かった場合には、従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【０１１８】
これにより、以後の発信側ＧＷ１ａにおけるパケット網６０ａを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【０１１９】
処理７０９では、図１６のフェーズＦ８０で確立されたデータチャンネルを使用して、フェーズＦ８１のファクスプロトコル処理を開始する（処理７０９）。
【０１２０】
そして、着信側Ｔ．３８端末からディジタル識別信号ＤＩＳのパケットを受信すると（処理７１０：図１６のフェーズＦ８１ｃ）、その受信したディジタル識別信号ＤＩＳのパケットを内容の変更なしにそのままモデム信号に変換して発信側Ｇ３ファクス４０ａに送信してしまう（処理７１１：図１６のフェーズＦ８１ｄ）。
【０１２１】
すると、発信側Ｇ３ファクス４０ａは、フェーズＦ８１ｄで通知された着信側の通信速度能力と自装置の通信速度能力の範囲内の通信速度（通常は最大の通信速度）を設定して、その他の通信パラメータの設定と共にディジタル送信命令信号ＤＣＳにより送信してくるため、そのディジタル送信命令信号ＤＣＳを受信する（図１５の処理８０１：図１３６フェーズＦ８１ｅ）。
【０１２２】
そして、その受信したディジタル送信命令信号ＤＣＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される発信側が対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理８０２）。
【０１２３】
そして、処理８０２で取得した必要ネットワーク帯域Ｂが、処理７０７で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断８０３）。
【０１２４】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以上の場合には（判断８０３のＹｅｓ）、発信側Ｇ３ファクス４０ａからトレーニングチェック信号ＴＣＦのモデム信号を受信する（処理８０４：図１６のフェーズＦ８１ｆ）。ただし、その場合受信したＴＣＦ信号のモデム信号については、パケットに変換して着信側Ｔ．３８端末に送信する処理は行わない。
【０１２５】
そして、その受信したＴＣＦ信号のモデム信号に対して、トレーニングエラー信号ＦＴＴのモデム信号を発信側Ｇ３ファクス４０ａに送信して（処理８０５：図１６のフェーズＦ８１ｇ）、処理８０１に戻る。その場合処理８０１で受信するディジタル送信命令信号ＤＣＳの通信速度の設定は、トレーニングエラー信号ＦＴＴの受信を受けて、発信側Ｇ３ファクス４０ａにおいて前に設定した速度よりも遅く設定されていることになる。
【０１２６】
そのため、判断８０３がＹｅｓとなった場合でも、判断８０３のＹｅｓのループが１回または複数回繰り返されることで、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも狭くなり、判断８０３がＮｏとなる。
【０１２７】
判断８０３がＮｏとなって初めて、処理８０１でモデム信号として受信したディジタル識別信号ＤＩＳをパケットに変換して、着信側Ｔ．３８端末に送信し（処理８０６：図１６のフェーズＦ８１ｉ）、以後フェーズＦ８１のファクスプロトコル処理を継続する（処理８０７）。
【０１２８】
処理８０７のフェーズＦ８１の通信が終了した後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを送信し（処理８０８）、それに対する相手端末からの帯域解放（RSVP_Tear）のパケットを受信してリソースの解放が行われて（処理８０９）、処理が終了する。
【０１２９】
このように、発信側Ｇ３ファクス４０ａから受信したディジタル送信命令信号ＤＣＳにより設定された通信速度ではモデムトレーニングが失敗してしまうとみせかけて、帯域オーバーとなるような通信速度が発信側３ファクス４０ａにおいて設定されてしまうことを防止することで、ルータに対して要求することにより確保されるネットワーク帯域の広さによらず常に正常なリアルタイムネットワーク通信の中継が可能となり、また、発信側のＧ３ファクス４０ａにおいて最終的に設定される通信速度に合わせて必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下になるように調節されるため、確保ネットワーク帯域Ａを無駄なく使用して効率的なファクシミリ通信が可能となる。
【０１３０】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、図５及び図６に示した第１実施形態に係る着信処理の変形例である、第５実施形態に係る着信側処理について、図１７及び図１８を参照して説明する。また、図１７及び図１８に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図１９に示す。
【０１３１】
図１７において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図１９のフェーズＦ９０）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理９０１：図１９のフェーズＦ９１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【０１３２】
着信側ＧＷ１ｂは、処理９０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、続いて、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理９０２：図１９のフェーズＦ９２）、その発呼に対する応答を受ける（処理９０３：図１９のフェーズＦ９３）。
【０１３３】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理９０４：図１９のフェーズＦ９４）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【０１３４】
その後、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理９０５：図１９のフェーズＦ９５）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理９０６：図１９のフェーズＦ９６）。
【０１３５】
このとき予約する帯域としては、ファクシミリメッセージの伝送時に必要となる高速モデム（例えば33.6Kbps）用の帯域ではなく、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１３６】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理９０７：図１９のフェーズＦ９７）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断９０８のＮｏ）、リトライ回数が満了していない限り、処理９０６に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断９１０のＮｏ）。
【０１３７】
リトライ回数が満了してしまった場合には（判断９１０のＹｅｓ）、通信エラーとして、図１８の処理１０１４に移行する。
【０１３８】
リトライ回数の満了までに帯域予約が成功した場合には（判断９０８のＹｅｓ）、図１８の処理１００１に移行する。
【０１３９】
図１８の処理１００１では、図１９のフェーズＦ９８で確立されたデータチャンネルを使用して、フェーズＦ９９のファクスプロトコル処理を開始する（処理１００１）。
【０１４０】
そして、処理１００１で開始されたフェーズＦ９９のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理１００２：図１９のフェーズＦ９９ｃ）。
【０１４１】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理１００３）。
【０１４２】
そして、その必要ネットワーク帯域Ｂ（この場合V.34の33.6Kbps）を、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１００４：図１９のフェーズＦ９９ｄ）。
【０１４３】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理１００５：図１９のフェーズＦ９９ｅ）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１００６のＮｏ）、リトライ回数が満了していない限り、処理１００４に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１００８のＮｏ）。
【０１４４】
リトライ回数が満了してしまった場合には（判断１００８のＹｅｓ）、通信エラーとして、処理１０１４に移行する。
【０１４５】
リトライ回数の満了までに帯域予約が成功した場合には（判断１００６のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存する（処理１００９）。
【０１４６】
そして、処理１００３で取得した必要ネットワーク帯域Ｂが、処理１００９で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断１００４）。
【０１４７】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断１０１０のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図１９のフェーズＦ９９ｇのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理１００２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理１０１２：図１９のフェーズＦ９９ｆ）、以後のフェーズＦ９９のファクスプロトコル処理を行う（処理１０１３）。
【０１４８】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断１０１０のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理１００２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理１０１１）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理１０１２：図１９のフェーズＦ９９ｆ）、以後フェーズＦ９９のファクスプロトコル処理を継続する（処理１０１３）。
【０１４９】
なお、処理１０１３におけるファクスプロトコル処理においては、図１９に示すように、フェーズＦ９９ｉ、Ｆ９９ｊの画情報のファクシミリメッセージの伝送終了後、伝送後手順に移行する前に、フェーズＦ９９ｋ及びフェーズＦ９９ｌにより、確保するネットワーク帯域を、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、フェーズＦ９９ｍ以降の伝送後手順においても、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１５０】
処理１０１３のフェーズＦ９９の通信が終了した後、または、判断１００８がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理１０１４）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理１０１５）、処理を終了する。
【０１５１】
このように、リアルタイムネットワークファクシミリ通信の開始から終了まで一定のネットワーク帯域を確保するのではなく、呼制御フェーズや能力交換フェーズなど、データフェーズ以外の通信手順を行っているときに、ルータに要求するネットワーク帯域を減らすことで、トータルではより少ないネットワーク帯域で通信することができるようになる。
【０１５２】
なお、この第５実施形態は、第１実施形態の変形例であるが、同様の変形は、第２、第３及び第４実施形態にたいしても同様に適用できるのはいうまでもない。また、ＤＩＳ／ＤＣＳの値に関わらず画情報転送前に固定の値（例えば64Kbps）の帯域予約要求（RSVP_Resv）送出するなど本発明のみを実施することも可能である。
【０１５３】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、図１７及び図１８に示した第５実施形態に係る着信処理の変形例である、第６実施形態に係る着信側処理について、図２０、図２１及び図２２を参照して説明する。また、図２０、図２１及び図２２に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図２３に示す。
【０１５４】
図２０において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図２３のフェーズＦ１００）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理１１０１：図２３のフェーズＦ１０１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。相手端末がRSVPをサポートしていなかった場合は従来技術で通信を行うが、このとき通信エラーとすることも可能である。
【０１５５】
着信側ＧＷ１ｂは、処理１１０１でＳＥＴＵＰパケットを受信して、それにより、相手端末がRSVPをサポートしていることがわかった場合、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理１１０２：図２３のフェーズＦ１０１）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【０１５６】
そして、タイマＴ１の計時をスタートさせ、（処理１１０３）、発信側の相手端末からRSVP_Pathメッセージを受け取り（処理１１０４：図２３のフェーズＦ１０３）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１１０５：図２３のフェーズＦ１０４）。
【０１５７】
このとき予約する帯域としては、ファクシミリメッセージの伝送時に必要となる高速モデム（例えば33.6Kbps）用の帯域ではなく、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１５８】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られるが（処理１１０６：図２３のフェーズＦ１０５）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１１０７のＮｏ）、リトライ回数が満了していない限り、処理１１０５に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１１０９のＮｏ）。
【０１５９】
リトライ回数が満了してしまった場合には（判断１１０９のＹｅｓ）、通信エラーとして、図２２の処理１３０８に移行する。
【０１６０】
リトライ回数の満了までに帯域予約が成功した場合には（判断１１０７のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存して（処理１１１０）、図２１の処理１２０１に移行し、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼する（処理１２０１：図２３のフェーズＦ１０６）。
【０１６１】
そのように、ネットワーク帯域が確保できて初めて、着信側のＧ３ファクス４０ｂに発呼するようにしているため、ネットワーク帯域が確保できず、結果的に通信エラーとなってしまうような電話網を介した発呼を行わないで済み、その分無駄な電話代を節約することができる。
【０１６２】
次に、処理１２０１における発呼に対する応答があるかを判断し（判断１２０２：図２３のフェーズＦ１０７）、応答があった場合には（判断１２０２のＹｅｓ）、通話／通信中や発呼トーンＣＮＧに対する応答がない等のエラーがあれば（判断１２０５のＹｅｓ）、図２２の処理１３０８に移行するが、それらのエラーがなければ（判断１２０５のＮｏ）、図２２の処理１３０１に移行する。
【０１６３】
判断１２０２において、応答がない場合には（判断１２０２のＮｏ）、処理１１０３で計時を開始したタイマＴ１の計時が満了するまで（判断１２０３のＹｅｓ）、ダミーのディジタル識別信号ＤＩＳのパケットを発信側のＴ．３８端末に対して送信する（判断１２０３のＮｏ、処理１２０４：図２３のフェーズＦ１０９ｂ）。タイマＴ１の計時が満了した場合は（判断１２０３のＹｅｓ）、図２２の処理１３０８に移行する。
【０１６４】
これは、電話網５０ｂ上の着信側Ｇ３ファクス４０ｂとは呼接続が完了していないのにパケット網上のＴ．３８端末とは、図２３のフェーズＦ１０８で呼接続が完了しているという不整合が一時的に生じている状態で、着信側Ｇ３ファクス４０ｂのリンギング検出回数が多めに設定されていた場合など、発信側Ｔ．３８端末がタイムアウトを起こしてしまう場合があることに鑑みての処理である。
【０１６５】
また、実際に発呼して回線接続されてみたらファクシミリ装置ではなく電話機だったということもあり、そのような場合に、パケット網上の発信側相手端末にＴ１タイムアウトが発生する前にダミーのＤＩＳを送出し、電話網上の着信側ファクスから応答がくるまでの間の時間を稼ぎ、着信側ファクスから正常にＤＩＳを受け取ったときにそれを発信側Ｔ．３８端末に対して再送することで、着信側ＧＷ１ｂと着信側ファクス４０ｂとのやりとりのに要する時間のために、発信側Ｔ．３８端末におけるタイムアウトが発生してしまうのを防止することができる。
【０１６６】
図２２の処理１３０１では、図２３のフェーズＦ１０８で確立されたデータチャンネルを使用して、フェーズＦ１０９のファクスプロトコル処理を開始する（処理１３０１）。
【０１６７】
そして、処理１３０１で開始されたフェーズＦ１０９のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理１３０２：図２３のフェーズＦ１０９ｅ）。
【０１６８】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理１３０３）。
【０１６９】
そして、処理１３０３で取得した必要ネットワーク帯域Ｂが、処理１１１０で保持していた確保ネットワーク帯域Ａより広いか否かを判断する（判断１３０４。
【０１７０】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断１３０４のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図２３のフェーズＦ１０９ｇのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理１３０２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理１３０６：図２３のフェーズＦ１０９ｆ）、以後のフェーズＦ１０９のファクスプロトコル処理を行う（処理１３０７）。
【０１７１】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断１３０４のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理１３０２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理１３０５）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理１３０６：図２３のフェーズＦ１０９ｆ）、以後フェーズＦ１０９のファクスプロトコル処理を継続する（処理１３０７）。
【０１７２】
なお、処理１３０７におけるファクスプロトコル処理においては、図２３に示すように、フェーズＦ１０９ｉ、Ｆ１０９ｊの画情報のファクシミリメッセージの伝送終了後、伝送後手順に移行する前に、フェーズＦ１０９ｋ及びフェーズＦ１０９ｌにより、確保するネットワーク帯域を、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに使用される低速モデム（300bps）用の帯域に抑える。これにより、フェーズＦ１０９ｍ以降の伝送後手順においても、Ｔ．３０信号をやりとりするために必要な最低限の帯域だけを確保でき、Ｔ．３０に基づいた伝送制御手順における制御信号のやりとりに必要な分以上の無駄に広い帯域を確保してしまうことがない。
【０１７３】
処理１３０７のフェーズＦ１０９の通信が終了した後、判断１１０９がＹｅｓとなった後、判断１２０３がＹｅｓとなった後、または、判断１２０５がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理１３０８）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理１３０９）、処理を終了する。
【０１７４】
なお、この第６実施形態は、第５実施形態の変形例であるが、同様の変形は、第１及び第３実施形態にたいしても同様に適用できるのはいうまでもない。
【０１７５】
次に、本発明の実施の形態に係るゲートウェイ装置１が着信側ゲートウェイ装置１ｂとして行う、図５及び図６に示した第１実施形態に係る着信処理の変形例である、第７実施形態に係る着信側処理について、図２４及び図２５を参照して説明する。また、図２４及び図２５に示す処理手順に対応するリアルタイムネットワークファクシミリ通信の通信シーケンスについて図２６に示す。
【０１７６】
図２４において、着信側ＧＷ１ｂは、呼制御用ＴＣＰチャンネルの確立後（図２６のフェーズＦ１１０）、発信側Ｔ．３８端末（ＩＡＦ２０ａまたはＧＷ１ａ）からＳＥＴＵＰパケットを受信する（処理１４０１：図２６のフェーズＦ１１１）。また、ＳＥＴＵＰパケットにより、着信側の宛先（ファクス番号）を取得する。また、受信ＳＥＴＵＰパケットは、fastConnect手順のもので、そのＳＥＴＵＰ内のOLC(OpenLogicalChannel)により、相手端末がRSVPを使用できるかどうか調査する。
【０１７７】
相手端末がRSVに対応していなかった場合には（判断１４０２のＮｏ）、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理１４０３：図２６のフェーズＦ１１２）、その発呼に対する応答を受ける（処理１４０４：図２６のフェーズＦ１１３）。
【０１７８】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信し（処理１４０５：図２６のフェーズＦ１１４）、処理１４１０で、記憶装置５に予め記憶・登録していたネットワーク帯域を、確保ネットワーク帯域としてのbit_rate（＝Ａ）として取得し（処理１４１０）、図２６の処理１５０１に移行する。
【０１７９】
判断１４０２において、相手端末がRSVに対応していた場合には（判断１４０２のＹｅｓ）、着信側Ｇ３ファクス４０ｂに対して電話網５０ｂを介して発呼し（処理１４０６）、その発呼に対する応答を受ける（処理１４０７）。
【０１８０】
そして、発信側Ｔ．３８端末装置に対してＣＯＮＮＥＣＴパケットを送信する（処理１４０８）。なお、その場合送信するＣＯＮＮＥＣＴパケットは、fastConnect手順のもので、そのＣＯＮＮＥＣＴ内のOLC(OpenLogicalChannel)により、自端末もRSVプロトコルをサポートしていることを示すOLC_Ack(OpenLogicalChannelAck)メッセージを返す。
【０１８１】
その後、発信側の相手端末からRSVP_Pathメッセージを受信しない場合には（判断１４０９のＮｏ）、記憶装置５に予め記憶・登録していたネットワーク帯域を、確保ネットワーク帯域としてのbit_rate（＝Ａ）として取得し（処理１４１０）、図２６の処理１５０１に移行する。
【０１８２】
発信側の相手端末からRSVP_Pathメッセージを受信した場合には（判断１４０９のＹｅｓ）、ネットワーク上のルータに対してRSVP_Resvメッセージによりリソースの予約要求を行う（処理１４１１）。
【０１８３】
このとき予約する帯域は現状G3ファクシミリ通信の最大速度がV.34で33.6Kbps、ISDNのG3で64Kbpsであることと、パケットネットワークでの遅延を考慮し、現状では64K〜128Kbps程度が望ましい値である。この値については、ユーザのネットワーク環境や将来のファクシミリプロトコルの拡張を考慮して、ユーザ設定した値を記憶装置に保存することを可能とする。
【０１８４】
予約要求が受け付けられれば、帯域確保成功を示す応答（RSVP_Conf）が得られることになるが、そのRSVP_Confのパケットが受信されない場合には（判断１４１２のＹｅｓ）、記憶装置５に予め記憶・登録していたネットワーク帯域を、確保ネットワーク帯域としてのbit_rate（＝Ａ）として取得し（処理１４１０）、図２６の処理１５０１に移行する。
【０１８５】
RSVP_Confのパケットが受信された場合には（判断１４１２のＹｅｓ）、予約要求に対して、帯域確保が失敗した場合（RSVP Error)（判断１４１３のＮｏ）、リトライ回数が満了していない限り、処理１４１１に戻って、帯域幅を少なくするなど内容を変更して帯域確保要求（RSVP_Resv）を再度発行する（判断１４１５のＮｏ）。
【０１８６】
リトライ回数が満了してしまった場合には（判断１４１５のＹｅｓ）、通信エラーとして、図２５の処理１５０８に移行する。
【０１８７】
リトライ回数の満了までに帯域予約が成功した場合には（判断１４１３のＹｅｓ）、確保できた帯域幅（確保ネットワーク帯域）としてのbit_rate（＝Ａ）を記憶装置５に保存し（処理１４１６）、図２５の処理１５０１に移行する。
【０１８８】
これにより、以後の着信側ＧＷ１ｂにおけるパケット網６０ｂを介した通信は、確保ネットワーク帯域Ａの範囲内で行われ、また、行う必要がある。
【０１８９】
図２５の処理１５０１では、図２６のフェーズＦ１１６で確立されたデータチャンネルを使用して、フェーズＦ１１７のファクスプロトコル処理を開始する（処理１５０１）。
【０１９０】
そして、処理１５０１で開始されたフェーズＦ１１７のファクスプロトコル処理、すなわち、電話網５０ｂを介して受信した被呼局識別信号ＣＥＤ、被呼端末識別信号ＣＳＩ、ディジタル識別信号ＤＩＳ等のＴ．３０信号のモデム信号を受信し、パケットに変換し、パケット網６０ｂを介して送信する処理や逆の処理を行っている間に、ディジタル識別信号ＤＩＳのモデム信号を受信する（処理１５０２：図２６のフェーズＦ１１７ｃ）。
【０１９１】
そして、その受信したディジタル識別信号ＤＩＳのＦＩＦ（ファクシミリ情報フィールド）の内容のうちのビット１１、１２、１３及び１４の組合せにより通知される着信側、すなわち、Ｇ３ファクス４０ｂが対応している、必要ネットワーク帯域としての通信速度（＝Ｂ）を調査する（処理１５０３）。
【０１９２】
そして、処理１５０３で取得した必要ネットワーク帯域Ｂが、処理１４１６で保持していた、または、処理１４１０で取得した確保ネットワーク帯域Ａより広いか否かを判断する（判断１５０４）。
【０１９３】
そして、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａ以下の場合には（判断１５０４のＮｏ）、ディジタル識別信号ＤＩＳで通知される通信速度能力の最高速度が、発信側T.38/H.323 AnnexD端末、つまり、ＩＡＦ２０ａ、または、ＧＷ１ａ（を介したＧ３ファクス４０ａ）により図２６のフェーズＦ１１７ｆのディジタル送信命令信号ＤＣＳにより設定されたとしても、以後のファクシミリメッセージデータの伝送時にパケット網６０ｂにおいて帯域オーバーが生じることがないため、処理１５０２でモデム信号として受信したディジタル識別信号ＤＩＳを内容を書き換えることなくそのまま発信側端末にパケット送信し（処理１５０６：図２６のフェーズＦ１１７ｅ）、以後のフェーズＦ１１７のファクスプロトコル処理を行う（処理１５０７）。
【０１９４】
必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い場合には（判断１５０４のＹｅｓ）、そのままでは、着信側Ｇ３ファクス４０ｂの通信速度能力と同じかそれ以上の通信速度能力を、発信側Ｔ．３８端末（を介した発信側Ｇ３ファクス４０ａ）が備えている場合には、必要ネットワーク帯域Ｂが確保ネットワーク帯域Ａよりも広い状態のまま、以後のファクシミリメッセージデータの伝送が行われてしまい、パケット網６０ｂにおいて帯域オーバーが生じて通信エラーとなるおそれがあるため、処理１５０２でモデム信号として受信したディジタル識別信号ＤＩＳの通信速度能力についての内容（ビット番号１１ないし１４のビット列により定義されている）を確保ネットワーク帯域Ａ（例えば9,000bps）以下に、必要ネットワーク帯域Ｂがなるような通信速度能力（7,200bps：ビット列では例えば「1,1,0,1」）に書換え変換し（処理１５０５：図２６のフェーズＦ１１７ｄ）、その書換え変換後のディジタル識別信号ＤＩＳをパケットに変換して発信側Ｔ．３８端末に送信し（処理１５０６：図２６のフェーズＦ１１７ｅ）、以後フェーズＦ１１７のファクスプロトコル処理を継続する。
【０１９５】
処理１５０７のフェーズＦ１１７の通信が終了した後、または、判断１４１５がＹｅｓとなった後、fastConnect手順により、CLC(CloseLogicalChannel)を含むRELCOMPメッセージを受信すると（処理１５０８）、相手端末がRSVP対応でない場合には（判断１５０９のＮｏ）、それで処理を終了するが、相手端末がRSVP対応の場合には（判断１５０９のＹｅｓ）、相手端末に対して帯域解放（RSVP_Tear）のパケット送出し、リソースの解放を行って（処理１５０９）、処理を終了する。
【０１９６】
このように、確保ネットワーク帯域Ａをパケット網内のルータを介してを得るためには、前記パケット網上の相手端末装置が帯域予約機能対応でなければならず、また経路途中に介在するルータも帯域予約機能対応でなければならないことに鑑みて、あらかじめ確保すべきネットワーク帯域についての情報を自装置において記憶登録しておくことで、ファクシミリ通信に割り当てるネットワーク帯域をゲートウェイ装置自身が管理することができ、前記パケット網上の相手端末装置やルータが帯域予約機能に対応していない場合でも、ファクシミリ通信に必要な帯域を制限することができるようになる。
【０１９７】
なお、この第７実施形態は、第１実施形態の変形例であるが、同様の変形は、第２実施形態にたいしても同様に適用できるのはいうまでもない。また、従来のゲートウェイ装置に対して単にファクシミリ通信に割り当てる帯域を制限する目的のみの場合には、この第７実施形態を、第１または第２実施形態のRSVP手順を除いたものと組み合わせることも有用である。
【０１９８】
また、Ｇ３ファクシミリ通信においては、呼接続完了（SETUP/CONNECT）後、発信側においては、相手ファクシミリからのフラグ受信までの時間（35±5秒）、着信側においては、発信側からのDCS受信までの時間（35±5秒）としてのタイマーＴ１、ＣＦＲ送信から最初のPIX受信（6±1秒）までの時間としてのタイマーＴ２、コマンドに対する応答（3秒±15%）までの時間としてのタイマＴ４等の各種タイマ値が規定されているが、ファクシミリ通信では通信の各フェーズで許容する応答信号の最大タイムアウト値が異なるため、常に同じネットワーク遅延率を要求する必要はないことに鑑みて、以上説明した第１ないし第７実施形態において、上記タイマーの計時を開始する直前のタイミングで最大許容遅延率を変更したRSVP_resvメッセージを送出するようにすることで、すなわち、ルータに要求する許容する最大遅延率をファクシミリ伝送手順に定められた各タイマーに連動して変更することで、呼制御フェーズや能力交換フェーズ、データフェーズなどで、相手端末からの応答を待っているときに、ルータに要求する最大遅延率を個別に設定でき、より効率的にネットワーク資源を使用することができるようになる。
【０１９９】
なお、以上説明した実施の形態においては、ＧＷタイプのＴ．３８端末であるゲートウェイ装置１に本発明を適用したが、本発明はそれに限らず、ゲートウェイ装置１と同様なリアルタイムファクシミリ通信の中継機能を兼ね備えたＩＡＦタイプのＴ．３８端末（ネットワークファクシミリ装置）、ゲートウェイ装置１と同様なリアルタイムファクシミリ通信の中継機能を兼ね備えたＧ３ファクシミリ装置等に対しても同様に適用可能であることはいうまでもない。
【０２００】
【発明の効果】
請求項１に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、着信側の前記ファクシミリ装置から受信したファクシミリ制御信号の通信速度能力を書き換えて、発信側の前記相手端末装置に送信して、前記着信側のファクシミリ装置の通信速度能力を低く見せかけるようにすることにより、前記発信側の相手端末装置（当該相手端末装置がゲートウェイ装置の場合には電話網を介した発信側のファクシミリ装置）が自装置の通信速度能力と着信側からのファクシミリ制御信号により通知された通信速度能力との範囲内で決定・設定する実際の通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。
【０２０１】
請求項２に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、着信側の前記相手端末装置から受信したファクシミリ制御信号の通信速度能力を書き換えて、発信側の前記ファクシミリ装置に送信して、前記着信側の相手端末装置の通信速度能力を低く見せかけるようにすることにより、前記発信側のファクシミリ装置が自装置の通信速度能力と着信側からのファクシミリ制御信号により通知された通信速度能力との範囲内で決定・設定する実際の通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。
【０２０２】
請求項３に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、発信側の前記相手端末装置からファクシミリ制御信号で設定された通信速度でのモデムトレーニングが失敗したかのようにみせかけて最終的な設定通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。また、着信側からのファクシミリ制御信号による通信速度能力ではなく、発信側からのファクシミリ制御信号による設定通信速度により通信速度を調節するようにしているため、前記確保ネットワーク帯域の範囲内でネットワーク帯域の無駄のない最適通信速度に調節することができる利点がある。
【０２０３】
請求項４に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、発信側の前記ファクシミリ装置からファクシミリ制御信号で設定された通信速度でのモデムトレーニングが失敗したかのようにみせかけて最終的な設定通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。また、着信側からのファクシミリ制御信号による通信速度能力ではなく、発信側からのファクシミリ制御信号による設定通信速度により通信速度を調節するようにしているため、前記確保ネットワーク帯域の範囲内でネットワーク帯域の無駄のない最適通信速度に調節することができる利点がある。
【０２０４】
請求項５に係る発明によれば、ファクシミリ通信では通信手順の各フェーズで伝送速度が異なるため、データ転送フェーズで必要なネットワーク帯域を通信開始時から終了時まで占有してしまう必要はないことに鑑みて、一定のネットワーク帯域を確保するのではなく、呼制御フェーズや能力交換フェーズなど、データフェーズ以外の通信手順を行っているときに、ルータに要求するネットワーク帯域を減らすことで、トータルではより少ないネットワーク帯域で通信することが可能になり、より効率的にネットワーク資源を使用することが可能となる効果が得られる。
【０２０５】
請求項６に係る発明によれば、ネットワーク環境が劣悪な場合、ファクシミリ通信に必要な最低限の帯域を確保できないことがり、そのようなときに前記電話網上のファクシミリ装置に発呼することは電話代の無駄遣いになってしまうことに鑑みて、ファクシミリ通信がいずれ失敗することが推測できるような場合には前記電話網上のファクシミリ装置に発呼する前に通信を中止するようにしたため、無駄な電話代を節約することが可能となる効果が得られる。
【０２０６】
請求項７に係る発明によれば、前記確保ネットワーク帯域を得るためには、前記パケット網上の相手端末装置が帯域予約機能対応でなければならず、また経路途中に介在するルータも帯域予約機能対応でなければならないことに鑑みて、あらかじめ確保すべきネットワーク帯域についての情報を自装置において記憶登録しておくことで、ファクシミリ通信に割り当てるネットワーク帯域を本発明に係るゲートウェイ装置自身が管理することができ、前記パケット網上の相手端末装置やルータが帯域予約機能に対応していない場合でも、ファクシミリ通信に必要な帯域を制限することが可能となる効果が得られる。
【０２０７】
請求項８に係る発明によれば、前記パケット網の残ネットワーク帯域が少ない等の理由で、前記必要ネットワーク帯域よりも、前記パケット網内のルータを介した所定のやりとりにより確保されたネットワーク帯域である前記確保ネットワーク帯域のほうが狭くなってしまうような場合には、発信側の前記相手端末装置からファクシミリ制御信号で設定された通信速度でのモデムトレーニングが失敗したかのようにみせかけて最終的な設定通信速度に相当する前記必要ネットワーク帯域が前記確保ネットワーク帯域以下になるように調節することができ、前記確保ネットワーク帯域が狭い場合でも、通信エラーの発生を防止した正常な通信が可能となる効果が得られる。また、着信側からのファクシミリ制御信号による通信速度能力ではなく、発信側からのファクシミリ制御信号による設定通信速度により通信速度を調節するようにしているため、前記確保ネットワーク帯域の範囲内でネットワーク帯域の無駄のない最適通信速度に調節することができる利点がある。
請求項９に係る発明によれば、ファクシミリ通信では通信手順の各フェーズで伝送速度が異なるため、データ転送フェーズで必要なネットワーク帯域を通信開始時から終了時まで占有してしまう必要はないことに鑑みて、一定のネットワーク帯域を確保するのではなく、呼制御フェーズや能力交換フェーズなど、データフェーズ以外の通信手順を行っているときに、ルータに要求するネットワーク帯域を減らすことで、トータルではより少ないネットワーク帯域で通信することが可能になり、より効率的にネットワーク資源を使用することが可能となる効果が得られる。
請求項１０に係る発明によれば、ネットワーク環境が劣悪な場合、ファクシミリ通信に必要な最低限の帯域を確保できないことがり、そのようなときに前記電話網上のファクシミリ装置に発呼することは電話代の無駄遣いになってしまうことに鑑みて、ファクシミリ通信がいずれ失敗することが推測できるような場合には前記電話網上のファクシミリ装置に発呼する前に通信を中止するようにしたため、無駄な電話代を節約することが可能となる効果が得られる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るゲートウェイ装置を含むリアルタイムネットワークファクシミリ通信システムの構成について示す図である。
【図２】本発明の実施の形態に係るゲートウェイ装置のブロック構成について示す図である。
【図３】本発明の実施の形態に係るゲートウェイ装置におけるソフトウェア構成について示す図である。
【図４】ＲＳＶＰを使用したＨ．３２３シーケンスの一例について示す図である。
【図５】本発明の実施の形態に係るゲートウェイ装置における第１実施形態に係る着信側処理手順について示すフローチャートである。
【図６】図５と共に、本発明の実施の形態に係るゲートウェイ装置における第１実施形態に係る着信側処理手順について示すフローチャートである。
【図７】図５及び図６の処理手順に対応する通信シーケンスについて示す図である。
【図８】本発明の実施の形態に係るゲートウェイ装置における第２実施形態に係る発信側処理手順について示すフローチャートである。
【図９】図８と共に、本発明の実施の形態に係るゲートウェイ装置における第２実施形態に係る発信側処理手順について示すフローチャートである。
【図１０】図８及び図９の処理手順に対応する通信シーケンスについて示す図である。
【図１１】本発明の実施の形態に係るゲートウェイ装置における第３実施形態に係る着信側処理手順について示すフローチャートである。
【図１２】図１１と共に、本発明の実施の形態に係るゲートウェイ装置における第３実施形態に係る着信側処理手順について示すフローチャートである。
【図１３】図１１及び図１２の処理手順に対応する通信シーケンスについて示す図である。
【図１４】本発明の実施の形態に係るゲートウェイ装置における第４実施形態に係る発信側処理手順について示すフローチャートである。
【図１５】図１４と共に、本発明の実施の形態に係るゲートウェイ装置における第４実施形態に係る発信側処理手順について示すフローチャートである。
【図１６】図１４及び図１５の処理手順に対応する通信シーケンスについて示す図である。
【図１７】本発明の実施の形態に係るゲートウェイ装置における第５実施形態に係る着信側処理手順について示すフローチャートである。
【図１８】図１７と共に、本発明の実施の形態に係るゲートウェイ装置における第５実施形態に係る着信側処理手順について示すフローチャートである。
【図１９】図１７及び図１８の処理手順に対応する通信シーケンスについて示す図である。
【図２０】本発明の実施の形態に係るゲートウェイ装置における第６実施形態に係る着信側処理手順について示すフローチャートである。
【図２１】図２０と共に、本発明の実施の形態に係るゲートウェイ装置における第６実施形態に係る着信側処理手順について示すフローチャートである。
【図２２】図２０及び図２１と共に、本発明の実施の形態に係るゲートウェイ装置における第６実施形態に係る着信側処理手順について示すフローチャートである。
【図２３】図２０、図２１及び図２２の処理手順に対応する通信シーケンスについて示す図である。
【図２４】本発明の実施の形態に係るゲートウェイ装置における第７実施形態に係る着信側処理手順について示すフローチャートである。
【図２５】図２４と共に、本発明の実施の形態に係るゲートウェイ装置における第７実施形態に係る着信側処理手順について示すフローチャートである。
【図２６】図２４及び図２５の処理手順に対応する通信シーケンスについて示す図である。
【符号の説明】
１、１ａ、1ｂ ゲートウェイ装置
２ システム制御部
３ ＲＯＭ
４ ＲＡＭ
５ 記憶装置
６ オペポート
７ ＬＡＮコントローラ
８ トランス
１２ モデム
１３ 網制御部
１４ システムバス
２０ａ、２０ｂ ＩＡＦ
３０ａ、３０ｂ ゲートキーパ装置
４０ａ、４０ｂ Ｇ３ファクス
５０、５０ａ、５０ｂ 電話網
６０、６０ａ、６０ｂ パケット網
７０ 通信ライン
８０ａ、８０ｂ ルータ
Claims (10)
- パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、
着信側の前記ファクシミリ装置から前記電話網を介して受信したファクシミリ制御信号内の通信速度能力に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、前記ファクシミリ制御信号内の通信速度能力を、前記確保ネットワーク帯域に相当する通信速度以下に書き換えた上でパケット化して前記パケット網上の相手端末装置に送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とするゲートウェイ装置。 - パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、
着信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の通信速度能力に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、前記ファクシミリ制御信号内の通信速度能力を、前記確保ネットワーク帯域に相当する通信速度以下に書き換えた上でモデム信号化して前記電話網上の発信側の前記ファクシミリ装置に送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とするゲートウェイ装置。 - パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、
発信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記相手端末装置から前記パケット網を介して受信したモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側の相手端末装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とするゲートウェイ装置。 - パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置であって、
発信側の前記ファクシミリ装置から前記電話網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記ファクシミリ装置から前記電話網を介して受信した所定のモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側のファクシミリ装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手段を備えることを特徴とするゲートウェイ装置。 - 前記通信速度／ネットワーク帯域調節手段は、前記ルータに要求して確保する前記確保ネットワーク帯域を、前記相手端末装置と前記ファクシミリ装置との間のリアルタイムファクシミリ通信におけるファクシミリ伝送手順の各フェーズで変更することを特徴とする請求項１、２、３または４のいずれかに記載のゲートウェイ装置。
- 前記通信速度／ネットワーク帯域調節手段は、前記パケット網上の発信側の前記相手端末装置と、前記電話網上の着信側のファクシミリ装置との間のリアルタイムネットワークファクシミリ通信を中継する場合に、前記ルータに要求して確保した前記確保ネットワーク帯域が、ファクシミリ通信に必要な所定の最低限帯域以下の場合には、前記ファクシミリ装置への前記電話網を介した発呼を行わないで通信を中止することを特徴とする請求項３に記載のゲートウェイ装置。
- 前記通信速度／ネットワーク帯域調節手段は、前記ルータにネットワーク帯域を要求した結果、前記ルータが帯域予約機能を備えていなかった場合、予め記憶登録しておいた帯域情報を前記確保ネットワーク帯域とすることを特徴とする請求項１、２、３または４のいずれかに記載のゲートウェイ装置。
- パケット網及び電話網に接続され、前記パケット網上の相手端末装置と前記電話網上のファクシミリ装置との間のリアルタイムファクシミリ通信を可能とするゲートウェイ装置の制御方法であって、
発信側の前記相手端末装置から前記パケット網を介して受信したファクシミリ制御信号内の設定通信速度に相当する必要ネットワーク帯域が、前記パケット網内のルータにより確保された確保ネットワーク帯域より広い場合には、発信側の前記相手端末装置から前記パケット網を介して受信したモデムトレーニング信号に対して、前記確保ネットワーク帯域に相当する通信速度以下になるまで、前記発信側の相手端末装置に対してダミーのトレーニング失敗信号を送信する通信速度／ネットワーク帯域調節手順を含むことを特徴とするゲートウェイ装置の制御方法。 - 前記通信速度／ネットワーク帯域調節手順は、前記ルータに要求して確保する前記確保ネットワーク帯域を、前記相手端末装置と前記ファクシミリ装置との間のリアルタイムファクシミリ通信におけるファクシミリ伝送手順の各フェーズで変更することを特徴とする請求項８に記載のゲートウェイ装置の制御方法。
- 前記通信速度／ネットワーク帯域調節手順は、前記パケット網上の発信側の前記相手端末装置と、前記電話網上の着信側のファクシミリ装置との間のリアルタイムネットワークファクシミリ通信を中継する場合に、前記ルータに要求して確保した前記確保ネットワーク帯域が、ファクシミリ通信に必要な所定の最低限帯域以下の場合には、前記ファクシミリ装置への前記電話網を介した発呼を行わないで通信を中止することを特徴とする請求項８に記載のゲートウェイ装置の制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001254472A JP4127351B2 (ja) | 2001-08-24 | 2001-08-24 | ゲートウェイ装置及びその制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001254472A JP4127351B2 (ja) | 2001-08-24 | 2001-08-24 | ゲートウェイ装置及びその制御方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003069651A JP2003069651A (ja) | 2003-03-07 |
| JP2003069651A5 JP2003069651A5 (ja) | 2006-08-17 |
| JP4127351B2 true JP4127351B2 (ja) | 2008-07-30 |
Family
ID=19082631
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001254472A Expired - Fee Related JP4127351B2 (ja) | 2001-08-24 | 2001-08-24 | ゲートウェイ装置及びその制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4127351B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007104524A (ja) * | 2005-10-07 | 2007-04-19 | Kyocera Mita Corp | Ｉｐゲートウェイ、通信方法、プログラム及びその記録媒体 |
| JP5071049B2 (ja) * | 2007-10-31 | 2012-11-14 | 富士通株式会社 | 呼制御装置、コンピュータプログラム、呼制御方法及び呼制御システム |
| JP2012004811A (ja) * | 2010-06-16 | 2012-01-05 | Fuji Xerox Co Ltd | 通信装置、そのプログラム |
-
2001
- 2001-08-24 JP JP2001254472A patent/JP4127351B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003069651A (ja) | 2003-03-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7218424B2 (en) | Facsimile transmission over packet networks with delivery notification | |
| US8098672B2 (en) | Internet telephone system ensuring communication quality and path setting method | |
| US7907708B2 (en) | Voice and fax over IP call establishment in a communications network | |
| CA2312592C (en) | Method for determining the security status of transmissions in a telecommunications network | |
| JP4298765B2 (ja) | アナログファックス装置のためのデジタルネットワークインターフェイス | |
| KR20060121764A (ko) | 신호 유형에 좌우되는 실시간 팩스 릴레이 | |
| JP3873048B2 (ja) | リングバックトーン伝送方法、端末機、リングバックトーン生成方法、およびリングバックトーンを生成するためのシステム | |
| US6285466B1 (en) | Facsimile communication system | |
| US7639403B2 (en) | Technique for connecting fax machines with advanced capabilities over a network which is not adapted to handle certain protocols | |
| JP3907945B2 (ja) | ゲートウェイ装置及びその制御方法、並びに、通信システム | |
| US5835579A (en) | Apparatus and methods for preventing disconnection of facsimile transmission over a network | |
| JP4127351B2 (ja) | ゲートウェイ装置及びその制御方法 | |
| US6335803B1 (en) | Facsimile communication system | |
| US6570879B1 (en) | Communications system and method of controlling same | |
| WO2003010953A1 (fr) | Procede de telecopie ip limitation de vitesse et procede de realisation d'une limitation de vitesse de passerelle dans la telecopie ip | |
| JP2003258879A (ja) | 通信帯域予約システム、ｓｉｐ中継装置および帯域予約方法 | |
| JP4564881B2 (ja) | 音声通信システム | |
| JP3738763B2 (ja) | 画像通信装置 | |
| JP4013153B2 (ja) | 通信装置及びプログラム | |
| US6937709B2 (en) | Fax transmission over congested or corrupted wideband network, or narrowband network, using ECM error block flow control | |
| JP3857033B2 (ja) | 通信端末装置及びその制御方法、並びに、通信システム | |
| JPH1098495A (ja) | 通信システム | |
| JP5328624B2 (ja) | 画像通信装置及び画像通信装置を制御するためのプログラム | |
| JP3977160B2 (ja) | ネットワークファクシミリ装置 | |
| JP2000341342A (ja) | 通信装置および通信方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060704 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060704 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080425 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080507 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080507 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140523 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |