T.38

T.38 は、 IP ネットワーク(FoIP)経由のFAXをリアルタイムで 送信できるようにするためのITU勧告です。

T.38 FAX リレー規格は、既存のグループ 3 (G3) FAX端末間で IP ネットワークを介して FAX を転送できるようにする方法として 1998 年に考案されました。T.4 および関連する FAX 規格は、インターネットが普及する前の 1980 年に ITU によって公開されました。1990 年代後半には、VoIP (Voice over IP) が従来の公衆交換電話網(PSTN)の代替として普及し始めました。ただし、ほとんどの VoIP システムは (帯域幅を節約する積極的な非可逆圧縮を使用することで) データ通話ではなく音声用に最適化されているため、従来の FAX マシンは、遅延、ジッター、パケット損失などのネットワーク障害のために、それらのシステムではうまく機能しなかったり、まったく機能しなかったりしました。そのため、IP 経由で FAX を送信する何らかの方法が必要でした。

実際のシナリオでは、T.38 FAX 通話の少なくとも一部は PSTN 経由で行われますが、これは T.38 定義では必須ではなく、2 つの T.38 デバイスが相互に FAX を送信できます。この特定のタイプのデバイスは、インターネット対応 FAX デバイス( IAF)と呼ばれ、IP ネットワークへの FAX 通話を開始または完了できます。

T.38 が使用される一般的なシナリオは、T.38 ファックス リレーです。T.30ファックスデバイスが PSTN 経由でファックスを T.38 ファックス ゲートウェイに送信し、ゲートウェイが T.30 プロトコルを T.38 データ ストリームに変換またはカプセル化します。その後、ファックス マシンやファックス サーバーなどの T.38 対応エンドポイント、または別の T.38 ゲートウェイに送信され、そこで PSTN PCM またはアナログ信号に変換されて、T.30 デバイスでファックスが終了します。

T.38 勧告では、T.38 パケットを転送するためにTCPとUDPの両方を使用することが定義されています。TCP には確認応答パケットが必要であり、パケット損失時に再送信が発生して遅延が発生するため、実装では UDP が使用される傾向があります。UDP を使用する場合、T.38 は冗長データ パケットを使用してパケット損失に対処します。

T.38 はコールセットアッププロトコルではないため、T.38 デバイスは、 H.323、SIP、MGCPなどの標準のコールセットアップ プロトコルを使用して T.38 コールをネゴシエートする必要があります 。

パケット ネットワークを介して FAX トランザクションを伝送する方法は主に 2 つあります。T.37標準では、FAX イメージを電子メールにカプセル化し、中間エンティティを介してストア アンド フォワード プロセスを使用して最終的に受信者に転送する方法が指定されています。一方、T.38 では、送信側と受信側の両方の端末で T.30 プロトコルの使用をサポートするプロトコルが定義されています (上の図を参照)。T.38 を使用すると、元の G3 FAX 標準が従来の (時分割多重 (TDM)) ネットワーク (公衆交換電話網またはPSTNとも呼ばれる) に対して行ったのと同様に、IP ネットワークを介してリアルタイムで FAX を送信できます。

既存のファックス端末は、IP パケットの不安定な到着とは対照的に、情報の流れが通常スムーズで中断のない PSTN 接続のみをサポートしていたため、IP (インターネット プロトコル) 経由のリアルタイム ファックスには特別なプロトコルが必要です。その秘訣は、エンドポイント ファックス端末に対して IP ネットワークを「見えない」ようにするプロトコルを考案することでした。つまり、従来のファックス端末のユーザーは、ファックス通話が IP ネットワークを通過していることを知る必要がないということです。

T.38 でサポートされるネットワーク相互接続は、上図のとおりです。図の両側にある 2 つの FAX 端末は、1980 年に ITU によって公開された T.30 FAX プロトコルを使用して通信します。PSTN と IP パケット ネットワークを相互接続するには、PSTN と IP ネットワークの間に「ゲートウェイ」が必要です。PSTN-IP ゲートウェイは、PSTN 側で TDM 音声をサポートし、パケット側で VoIP と FoIP をサポートします。

音声セッションの場合、ゲートウェイは IP 側で音声パケットを受け取り、いくつかのパケットを蓄積して、リリース時に TDM データがスムーズに流れるようにし、その後 TDM 経由で測定して、最終的に人間が聞くか、後で再生するためにコンピューターに保存します。ゲートウェイは、ネットワーク エラーが発生した場合でも、パケット管理技術を使用して、リスナーが時折パケットが欠落したり重複したりしても実際には聞き取れないという自然な能力を利用して、音声の品質を向上させます。

しかし、ファクシミリデータはモデムによって伝送されますが、モデムは人間の耳が音声に対して寛容であるのと同じくらい寛容ではありません。パケットの欠落により、最悪の場合、ファクシミリセッションが失敗したり、最良の場合でも 1 つ以上の画像ラインがエラーになったりすることがよくあります。したがって、T.38 の役割は、端末を「だまして」、別の T.30 端末と直接通信していると「思わせる」ことです。また、いわゆるスプーフィング技術を使用してネットワークの遅延を修正したり、ファクシミリ対応のバッファ管理技術を使用してパケットの欠落や遅延を修正したりします。

スプーフィングとは、T.38 リレーのプロトコル エンジンに実装されたロジックのことで、TDM 側のプロトコル コマンドと応答を変更して、IP 側のネットワーク遅延によってトランザクションが失敗しないようにします。これは、たとえば、イメージ ラインを埋め込んだり、意図的にメッセージを再送信して、送信側と受信側の FAX 端末にネットワーク遅延が透過的になるようにしたりすることで行われます。

パケット損失や過度の遅延がないネットワークでは、すべてのゲートウェイの PCM クロックが非常に高精度であれば (以下で説明)、T.38 がなくても許容できる FAX パフォーマンスを発揮できます。T.38 は、PCM クロックの同期化の影響を排除するだけでなく、パケット損失と遅延を修正しながら、必要なネットワーク帯域幅を 10 分の 1 に削減します。

下の図に示すように、T.38ゲートウェイは、ファックス モデムと T.38 サブシステムという 2 つの主要な要素で構成されています。ファックス モデムは、アナログ データの PCM サンプルを変調および復調し、ファックス端末のアナログ信号のサンプル データ表現をバイナリ変換に変換し、その逆も行います。PSTN ネットワークは、音声またはモデム信号 (違いは認識しません) のアナログ信号を 1 秒あたり 8,000 回 (SPS) サンプリングし、8 ビットのデータ バイトとしてエンコードします。つまり、1 方向のモデム (または音声) データを表すには、1 秒あたり 8,000 サンプル × サンプルあたり 8 ビット、つまり 1 秒あたり 64,000 ビット (bit/s) が必要です。両方向のモデム トランザクションでは、128,000 ビットのネットワーク帯域幅が消費されます。

ただし、FAX 端末の一般的なモデムは、画像データを 33,600 ビット/秒で送信するため、アナログ データを最初にデジタル コンテンツに変換すると、必要なのは 33,600 ビット (および数バイトのネットワーク オーバーヘッド) だけです。また、T.30 FAX は半二重プロトコルであるため、ネットワークは一度に 1 方向のみで必要になります。

RFC 3261を参照

上の図では、ファックス端末とゲートウェイのモデムにサンプルレート クロックがあり、アナログ回線のサンプリングを 1 秒あたり 8,000 回トリガーするために使用されます。これらのクロックは通常非常に正確ですが、一部の低価格の端末アダプタ (1 回線または 2 回線のゲートウェイ) では、PCM クロックが驚くほど不正確になることがあります。端末がゲートウェイにデータを送信しているときに、ゲートウェイのクロックが遅すぎると、ゲートウェイのバッファ (ジッタ バッファ) が最終的にオーバーフローし、トランザクションが失敗します。この差は多くの場合非常に小さいため、この問題は長くて詳細なファックス画像で発生し、クロックにより多くの時間を与えてゲートウェイのジッタ バッファがアンダーフローまたはオーバーフローすることになります。これは、パケットの欠落または重複と同じです。

T.38 は、データの冗長性によってパケット損失の影響を排除する機能を提供します。パケットが送信されると、以前に送信されたパケットの 0、1、2、3、またはそれ以上が繰り返されます (仕様では制限は課されていません)。これにより、必要なネットワーク帯域幅が増加しますが (それでも T.38 を使用しない場合よりはるかに少ないです)、パケット損失のレベルがかなり高い場合でも、受信ゲートウェイは完全なパケット シーケンスを再構築できます。

• T.4 は、ファックスの包括的な仕様です。標準画像サイズ、2 種類の画像データ圧縮 (エンコード) 形式、画像データ形式、および参照、T.30、およびさまざまなモデム標準を指定します。
• T.6 は、画像の送信に必要な時間を約 50 パーセント短縮する圧縮方式を指定します。
• T.30 は、送信側と受信側の端末が FAX 通話の設定、画像サイズ、エンコード、転送速度の決定、ページ間の区切り、通話の終了に使用する手順を規定しています。T.30 は、さまざまなモデム標準も参照しています。
• V.21、V.27ter、V.29、V.17、V.34 : ファクシミリで使用されるITUモデム規格。最初の3つは1980年以前に批准され、元のT.4およびT.30規格で指定されていました。V.34は1994年にファクシミリ用に発行されました。^[1]
• T.37ファックス画像ファイルを電子メールでファックスの宛先に送信するための ITU 標準。
• G.711パススルー - T.30 FAX 通話がオーディオとしてエンコードされた VoIP 通話で伝送されます。これは、ネットワークパケット損失、ジッター、およびクロック同期の影響を受けます。G.729 などの音声高圧縮エンコード技術を使用する場合、一部の FAX トーン信号がパケット ネットワークを介して正しく転送されない場合があります。
• RFC 3362 は、セッション記述プロトコルで使用するためのimage/t38メディア タイプ(以前は MIME タイプと呼ばれていました)を定義します。

• Asterisk (PBX)オープンソース PBX は T.38 ファックスをサポート
• Freeswitchソフトスイッチ / PBX も T.38 をサポート
• ICTFax T.38 をサポートする Web FAX / 電子メールから FAX へのゲートウェイ

• インターネットファックス
• 電話

• ITU-T T.38 ページ
• spandsp著者のFoIPに関する科学論文