Loading article…
T.38 ファックスリレー規格は、既存のグループ 3 (G3)ファックス端末間で IP ネットワークを介してファックスを転送する方法として 1998 年に考案されました。T.4 および関連するファックス規格は、インターネットの台頭以前の 1980 年に ITU によって発行されました。1990 年代後半には、VoIP (Voice over IP) が従来の公衆交換電話網(PSTN)の代替として普及し始めました。しかし、ほとんどの VoIP システムは (積極的な損失のある帯域幅節約圧縮を使用することで) データ通話ではなく音声通話に最適化されているため、従来のファックス機は、遅延、ジッター、パケット損失などのネットワーク障害により、VoIP 上でうまく動作しないか、まったく動作しませんでした。そのため、IP を介してファックスを送信する何らかの方法が必要でした。
実際のシナリオでは、T.38 ファックス通話の少なくとも一部は PSTN を介して行われますが、これは T.38 の定義では必須ではありません。また、2 つの T.38 デバイス間でファックスを送受信することも可能です。この種のデバイスはインターネット対応ファックスデバイス( IAF)と呼ばれ、IP ネットワークへのファックス通話の開始または完了が可能です。
T.38が使用される典型的なシナリオは、 T.38ファックスリレーです。これは、 T.30ファックス端末がPSTN経由でファックスをT.38ファックスゲートウェイに送信し、ゲートウェイがT.30プロトコルをT.38データストリームに変換またはカプセル化するものです。その後、このデータはファックス機やファックスサーバーなどのT.38対応エンドポイント、またはPSTN PCMまたはアナログ信号に変換し、T.30端末でファックスを終端する別のT.38ゲートウェイに送信されます。
T.38勧告では、 T.38パケットの転送にTCPとUDPの両方を使用することが規定されています。TCPは確認応答パケットを必要とし、パケット損失時に再送信が発生するため遅延が生じることから、実装ではUDPを使用する傾向があります。UDPを使用する場合、T.38は冗長データパケットを使用することでパケット損失に対処します。
T.38は通話設定プロトコルではないため、T.38デバイスはT.38通話をネゴシエートするために、 H.323、SIP、MGCPなどの標準的な通話設定プロトコルを使用する必要があります。
パケットネットワークを介してファックス トランザクションを伝送する主な方法は 2 つあります。T.37規格では、ファックス イメージを電子メールにカプセル化し、中間エンティティを介してストア アンド フォワード プロセスを使用して最終的に受信者に転送する方法が規定されています。一方、T.38 では、送信端末と受信端末の両方で T.30 プロトコルの使用をサポートするプロトコルが定義されています。（上の図を参照。）T.38 を使用すると、従来の G3 ファックス規格が従来の（時分割多重（TDM））ネットワーク（公衆交換電話網またはPSTNとも呼ばれる）で行っていたのと同様に、IP ネットワークを介してファックスをリアルタイムで送信できます。
リアルタイムのIP（インターネットプロトコル）ファックスを実現するには、特別なプロトコルが必要です。既存のファックス端末はPSTN接続のみをサポートしており、PSTN接続では情報フローは一般的にスムーズで途切れることがなかったのに対し、IPパケットは不安定な到着となるためです。そこで、エンドポイントのファックス端末からIPネットワークを「見えない」ようにするプロトコルを開発する必要がありました。つまり、従来のファックス端末のユーザーは、ファックス通話がIPネットワークを経由していることを意識する必要がなくなるということです。
T.38でサポートされるネットワーク相互接続を図に示します。図の両側にある2台のファックス端末は、1980年にITUが発行したT.30ファックスプロトコルを使用して通信します。PSTNとIPパケットネットワークを相互接続するには、PSTNとIPネットワークの間に「ゲートウェイ」が必要です。PSTN-IPゲートウェイは、PSTN側ではTDM音声、パケット側ではVoIPとFoIPをサポートします。
音声セッションの場合、ゲートウェイはIP側で音声パケットを受信し、TDMデータがスムーズに流れるようにパケットを蓄積した後、TDM経由でパケットを分配します。最終的に、これらのパケットは人間の耳に届くか、後で再生するためにコンピュータに保存されます。ゲートウェイはパケット管理技術を用いて、ネットワークエラーが発生した場合でも、リスナーが時折発生するパケットの欠落や重複をほとんど聞き取れないという特性を利用し、音声品質を向上させます。
しかし、ファクシミリデータはモデムを介して送信されるため、人間の耳が音声を聞き取るほど寛容ではありません。パケットが欠落すると、最悪の場合ファクシミリセッションが失敗したり、最良の場合でも1つ以上の画像ラインにエラーが発生したりします。そこで、T.38の役割は、端末を「だまして」、別のT.30端末と直接通信していると「思わせる」ことです。また、いわゆるスプーフィング技術でネットワーク遅延を補正し、ファクシミリ対応のバッファ管理技術でパケットの欠落や遅延を補正します。
スプーフィングとは、T.38リレーのプロトコルエンジンに実装されたロジックを指し、TDM側のプロトコルコマンドと応答を改変することで、IP側のネットワーク遅延によってトランザクションが失敗しないようにするものです。例えば、画像行にパディングを追加したり、意図的にメッセージを再送信したりすることで、送受信ファックス端末からネットワーク遅延の影響を透過的に受けないようにします。
パケット損失や過度の遅延がないネットワークでは、すべてのゲートウェイのPCMクロックの精度が非常に高い場合（後述）、T.38を使用しなくても許容できるファックス性能を発揮できます。T.38は、PCMクロックの同期不良の影響を取り除くだけでなく、必要なネットワーク帯域幅を10分の1に削減し、パケット損失と遅延を補正します。
下の図に示すように、T.38ゲートウェイは、ファックス モデムと T.38 サブシステムという 2 つの主要要素で構成されています。ファックス モデムは、アナログ データの PCM サンプルを変調および復調し、ファックス端末のアナログ信号のサンプリング データ表現をバイナリに変換し、またその逆も行います。PSTN ネットワークは、音声またはモデム信号 (違いは認識しません) のアナログ信号を毎秒 8,000 回 (SPS) サンプリングし、8 ビットのデータ バイトとしてエンコードします。これは、1 方向のモデム (または音声) データを表現するために、毎秒 8,000 サンプル × 1 サンプルあたり 8 ビット、つまり毎秒 64,000 ビット (bit/s) が必要であることを意味します。両方向のモデム トランザクションは、128,000 ビットのネットワーク帯域幅を消費します。
しかし、一般的なファックス端末のモデムは画像データを33,600ビット/秒で送信するため、アナログデータをまずデジタルコンテンツに変換すれば、必要なのは33,600ビット（加えて数バイトのネットワークオーバーヘッド）だけで済みます。また、T.30ファックスは半二重通信プロトコルであるため、ネットワークは一度に一方向のみで済みます。
RFC 3261を参照してください。
上の図では、ファックス端末とゲートウェイのモデムにそれぞれサンプリングレートクロックがあり、アナログ回線のサンプリングを毎秒 8,000 回トリガーするために使用されます。これらのクロックは通常非常に正確ですが、一部の低価格端末アダプタ（1 回線または 2 回線のゲートウェイ）では、PCM クロックの精度が驚くほど低い場合があります。端末がゲートウェイにデータを送信しているときに、ゲートウェイのクロックが遅すぎると、ゲートウェイ内のバッファ（ジッタバッファ）が最終的にオーバーフローし、トランザクションが失敗します。この差は多くの場合非常に小さいため、この問題は、長い詳細なファックス画像で発生し、クロックがゲートウェイ内のジッタバッファをアンダーフローまたはオーバーフローさせる時間が長くなります。これは、パケットの欠落または重複と同じ結果になります。
T.38は、データ冗長性によってパケット損失の影響を排除する機能を提供します。パケットが送信される際、以前に送信されたパケットのうち、0個、1個、2個、3個、あるいはそれ以上のパケットが繰り返されます（仕様では制限は設けられていません）。これにより必要なネットワーク帯域幅は増加しますが（T.38を使用しない場合よりははるかに少ない）、受信側のゲートウェイは、かなり高いレベルのパケット損失が発生した場合でも、完全なパケットシーケンスを再構築できます。