JT-T38
ＩＰネットワーク上のリアルタイム
グループ３ファクシミリ通信手順
Procedures for real-time Group 3 facsimile
communication over IP networks

第7版

2018 年 5 月 24 日制定

一般社団法人

情報通信技術委員会
THE TELECOMMUNICATION TECHNOLOGY COMMITTEE本書は、一般社団法人情報通信技術委員会が著作権を保有しています。
内容の一部又は全部を一般社団法人情報通信技術委員会の許諾を得ることなく複製、転載、改変、転用
及びネットワーク上での送信、配布を行うことを禁止します。

目次＜参考＞ .......................................................................................................................................................................... 6
１．適用範囲 .................................................................................................................................................................. 9
２．参照規格 .................................................................................................................................................................. 9
３．定義 ........................................................................................................................................................................ 12
3.1 送信ゲートウェイ： ....................................................................................................................................... 12
3.2 受信ゲートウェイ： ....................................................................................................................................... 12
3.3 Ｇ３ファクシミリ装置（Ｇ３ＦＥ）：........................................................................................................ 12
3.4 ＪＴ－Ｔ３８／Ｇ３： ................................................................................................................................... 12
3.5 ＪＴ－Ｔ３８／Ｖ．３４Ｇ３： ................................................................................................................... 13
3.6 Ｔ３８トランスポートモード： ................................................................................................................... 13
４．略語 ........................................................................................................................................................................ 13
５．はじめに ................................................................................................................................................................ 14
5.1 コンベンション ............................................................................................................................................... 17
5.1.1 ＳＤＰオファー／アンサープロトコルの変形 ..................................................................................... 17
６．ゲートウェイ間通信 ............................................................................................................................................ 17
6.1 インターネットプロトコル－ＴＣＰまたはＵＤＰ .................................................................................... 17
6.2 ゲートウェイファクシミリデータ転送機能................................................................................................ 17
6.2.1 非標準機能要求の取り扱い .................................................................................................................... 17
７．ＩＦＴプロトコルの定義と使用 ........................................................................................................................ 177.1 概要 ................................................................................................................................................................... 17
7.1.1 ビットとオクテット伝送順序 ................................................................................................................ 18
7.1.2 ＪＴ－Ｔ３０ビットストリームの配置 ................................................................................................. 18
7.1.3 ＴＣＰ／ＩＰとＵＤＰ／ＩＰのためのＩＦＰパケットレイヤ ......................................................... 18
7.2 ＩＦＰパケットフォーマット ....................................................................................................................... 20
7.2.1 ＪＴ－Ｔ３８パケット ............................................................................................................................ 20
7.2.2 種別 ............................................................................................................................................................ 20
7.2.3 データフィールド .................................................................................................................................... 21
7.3 種別定義 ........................................................................................................................................................... 21
7.3.1 Ｔ３０＿ＩＮＤＩＣＡＴＯＲ ................................................................................................................ 21
7.3.2 Ｔ３０＿ＤＡＴＡ種別 ............................................................................................................................ 23
7.4 ＩＦＰデータ要素 ........................................................................................................................................... 23
7.5 Ｖ．２１フレームパケットサイズの制限.................................................................................................... 26
８．Ｖ．１７以下のファクシミリ変調のためのＩＦＰメッセージフロー ......................................................... 27
8.1 データ転送速度管理方法１ ........................................................................................................................... 27
8.2 データ転送速度管理方法２ ........................................................................................................................... 28
９．ＵＤＰトランスポート上でのＩＦＴ：ＩＦＴ／ＵＤＰ ................................................................................. 29
9.1 ＵＤＰＴＬを使ったＵＤＰトランスポート上のＩＦＴ：ＩＦＴ／ＵＤＰＴＬ／ＵＤＰ ..................... 29
9.1.1 ＵＤＰＴＬプロトコルの概要 ................................................................................................................ 29
9.1.2 ＵＤＰＴＬヘッダセクションフォーマット ......................................................................................... 29
9.1.3 ＵＤＰＴＬペイロードセクションフォーマット ................................................................................. 29
9.1.4 ＩＦＰ／ＵＤＰファクシミリデータ転送機能 ..................................................................................... 30
9.2 ＲＴＰを使ったＵＤＰトランスポート上のＩＦＴ：ＩＦＴ／ＲＴＰ／ＵＤＰ .................................... 31-2-

ＪＴ－Ｔ３８

１０．Ｖ．８信号とＪＴ－Ｔ３０付属資料Ｅ／Ｖ．３４ファクシミリのためのメッセージフロー .............. 33
10.1 Ｖ．８能力交換 ............................................................................................................................................. 33
10.2 Ｖ．３４データレート管理 ......................................................................................................................... 35
10.2.1 コントロールチャネルの開始 .............................................................................................................. 35
10.2.2 コントロールチャネルの再トレーニング ........................................................................................... 35
10.3 ファクシミリモード ..................................................................................................................................... 37
10.3.1 コントロールチャネル .......................................................................................................................... 37
10.3.2 コントロールチャネルからプライマリチャネルへの切り替え ....................................................... 37
10.3.3 プライマリチャネル .............................................................................................................................. 37
10.3.4 プライマリチャネルからコントロールチャネルへの切り替え ....................................................... 37
10.3.5 ターンアラウンドポーリングモード................................................................................................... 37
10.3.6 ＪＴ－Ｔ３０付属資料Ｅ（Ｖ．３４動作）への手動での開始 ....................................................... 38
10.3.7 切断 .......................................................................................................................................................... 38
10.4 本標準の以前の版との機器適合についての互換性 .................................................................................. 39
１１．セキュリティの考慮 ........................................................................................................................................ 39
付属資料 Ａ （ＪＴ－Ｔ３８に対する） 抽象構文記法１（ＡＳＮ．１） ....................................................... 40
A.1

ＪＴ－Ｔ３８(第３．１版)抽象構文記法１（ＡＳＮ．１） .................................................................... 40

A.2

ＪＴ－Ｔ３８(第１版)抽象構文記法１（ＡＳＮ．１） ............................................................................ 41

付属資料 Ｂ （ＪＴ－Ｔ３８に対する） ＪＴ－Ｈ３２３呼の確立手順 .......................................................... 43
B.1 はじめに .......................................................................................................................................................... 43
B.2 ファクシミリ装置とゲートウェイ間の通信 ............................................................................................... 43
Ｂ.2.1 アドレス情報の伝送 .............................................................................................................................. 43
B.3 ゲートウェイ間の通信................................................................................................................................... 43
B.3.1 概要 ........................................................................................................................................................... 43
B.3.2 基本的な呼設定 ....................................................................................................................................... 44
B.3.3 能力ネゴシエーション ............................................................................................................................ 45
B.3.4 呼設定ＯＬＣの例.................................................................................................................................... 48
B.3.5 必須な呼設定メッセージ ........................................................................................................................ 48
B.3.6 呼経過信号のマッピング ........................................................................................................................ 49
B.3.7 メッセージ内maxBitRateの使用 ............................................................................................................. 50
B.3.8 ＤＴＭＦ送信 ........................................................................................................................................... 51
B.3.9 相互接続性 ............................................................................................................................................... 51
付属資料 Ｃ （ＪＴ－Ｔ３８に対する） ＵＤＰＴＬのためのオプションの前方エラー訂正機構 ................ 52
C.1 オプションの前方エラー訂正方法の概要 ................................................................................................... 52
C.2 パリティ符号化／復号化機構の動作と特徴 ............................................................................................... 52
C.2.1 ＦＥＣメッセージの生成と送信 ............................................................................................................ 53
C.2.2 受信ＦＥＣメッセージとプライマリＩＦＰパケットの再組み立て ................................................. 55
付属資料 Ｄ （ＪＴ－Ｔ３８に対する） ＳＩＰ／ＳＤＰ呼の確立手順 ........................................................... 56
D.1

はじめに ........................................................................................................................................................ 56

D.2 ゲートウェイ間の通信 .................................................................................................................................. 56
D.2.1 概要 ........................................................................................................................................................... 56
D.2.2

基本的な呼設定 .................................................................................................................................... 58

D.2.3

能力ネゴシエーション ........................................................................................................................ 64-3-

ＪＴ－Ｔ３８

D.2.4

呼設定の例 ............................................................................................................................................ 70

D.2.5 最低限の呼設定メッセージ.................................................................................................................... 82
D.2.6 発呼経過信号のマッピング.................................................................................................................... 82
D.2.7

ＤＴＭＦ送信 ........................................................................................................................................ 83

D.2.8

相互接続性 ............................................................................................................................................ 83

付属資料 Ｅ （ＪＴ－Ｔ３８に対する） ＪＴ－Ｈ２４８．１呼の確立手順 ................................................... 84
E.1 はじめに ............................................................................................................................................................ 84
E.2 ゲートウェイ間の通信 ................................................................................................................................... 84
E.2.1

概要 ........................................................................................................................................................ 84

E.2.2

基本呼設定の準備 ................................................................................................................................ 85

E.2.3 イベントと信号の表示 ............................................................................................................................ 95
E.2.4 能力ネゴシエーション ............................................................................................................................ 96
E.2.5 呼設定の例................................................................................................................................................ 96
E.2.6 最低限の発呼メッセージ ........................................................................................................................ 96
E.2.7 発呼経過表示信号のマッピング ............................................................................................................ 96
E.2.8 ＤＴＭＦ送信 ............................................................................................................................................ 96
E.2.9 相互接続性................................................................................................................................................ 96
付属資料

Ｆ （ＪＴ－Ｔ３８に対する） 相互に作用する手順：同一ゲートウェイ内のＪＴ－Ｔ３８とＶ．

１５０．１ .................................................................................................................................................................... 97
F.1 はじめに........................................................................................................................................................... 97
F.2 ＪＴ－Ｔ３８遷移のためのＳＳＥ原因識別コード.................................................................................... 98
F.3 Ｖ．３４グループ３ファクシミリから標準のグループ３ファクシミリへの遷移方式 ........................ 99
F.4 外部シグナリング ......................................................................................................................................... 101
付属資料 Ｇ （ＪＴ－Ｔ３８に対する） ＲＴＰ上のＪＴ－Ｔ３８のためのＪＴ－Ｈ２４５能力定義 ...... 102
付属資料 Ｈ （ＪＴ－Ｔ３８に対する） 通知や提供されるＪＴ－Ｔ３８プロトコルパラメータ .............. 105
H.1 はじめに ........................................................................................................................................................ 105
H.2 トランスポート条件付きＪＴ－Ｔ３８パラメータ ................................................................................. 105
H.2.1 ＪＴ－Ｔ３８ ＩＦＰパケットのトランスポートモード ................................................................. 105
H.2.2 トランスポート依存 のＪＴ－Ｔ３８パラメータの概要 ................................................................. 106
H.3 ＪＴ－Ｔ３８プロトコルパラメータを通知するためのガイドライン .................................................... 111
H.4 ＳＤＰパラメータのレガシーな解釈............................................................................................................ 111
H.4.1 T38MaxBitRate .......................................................................................................................................... 111
付録 Ⅰ （ＪＴ－Ｔ３８に対する） セッションの例 ......................................................................................... 112
I.1 セッションの例 .............................................................................................................................................. 112
I.1.1 ＥＣＭで通信する２台の従来のファクシミリ装置............................................................................ 112
I.1.2 従来のファクシミリ装置とインターネット対応ファクシミリ装置 ................................................ 112
I.1.3 複数フレームを使用する２台の従来のファクシミリ装置 ................................................................ 112
I.2 インターネット対応ファクシミリ装置（ＩＡＦ） .................................................................................. 117
I.2.1 送信側がＩＡＦ、受信側がＧ３ファクシミリ ................................................................................... 117
Ⅰ.2.2

受信側がＩＡＦ、送信側がＧ３ファクシミリ ............................................................................... 118

付録 Ⅱ （ＪＴ－Ｔ３８に対する） ＪＴ－Ｔ３８付属資料Ｂに記載する呼確立手順の例.......................... 119
Ⅱ.1 呼確立手順シーケンス例 ........................................................................................................................... 119
Ⅱ.1.1 ＪＴ－Ｔ３８付属資料Ｂゲートウェイ間シーケンス ..................................................................... 119-4-

ＪＴ－Ｔ３８

Ⅱ.1.2 ＪＴ－Ｔ３８付属資料ＢとＪＴ－Ｈ３２３付属資料Ｄゲートウェイ間シーケンス .................. 120
Ⅱ.1.3

ファクシミリをサポートするＪＴ－Ｔ３８付属資料Ｂと同じゲートキーパーに登録されたＪＴ－Ｈ３２３付属資料Ｄ間シーケンス .............................................................................................................. 123
Ⅱ.2 呼確立手順で用いられるプロトコルデータ ............................................................................................ 124
Ⅱ.2.1 概要 ........................................................................................................................................................ 124
Ⅱ.2.2 プロトコルデータ例 ............................................................................................................................ 124
付録

Ⅲ （ＪＴ－Ｔ３８に対する） ファクシミリ機能を有するメディアゲートウェイのＨ．２４８呼の確立手順例 ...................................................................................................................................................................... 131
Ⅲ.1 はじめに ....................................................................................................................................................... 131
Ⅲ.2 呼設定の例 ................................................................................................................................................... 131
Ⅲ.2.1

ＪＴ－Ｔ３８遷移方式を使用したＨ．２４８エンドポイントでの音声からファクシミリへの呼設定 ...................................................................................................................................................................... 131
Ⅲ.2.2 Ｈ．２４８とＪＴ－Ｈ３２３の間でのファクシミリのみの呼設定 ............................................. 143
Ⅲ.2.3

ＪＴ－Ｔ３８自動遷移方式をサポートするＨ．２４８を用いた音声からファクシミリへの呼設定 .......................................................................................................................................................................... 149
Ⅲ.2.4

Ｈ．２４８とＪＴ－Ｈ３２３エンドポイント間における音声端末からファクシミリへの呼設定のためのＪＴ－Ｔ３８自動遷移方式 .............................................................................................................. 158
付録 Ⅳ （ＪＴ－Ｔ３８に対する） Ｖ．３４を用いた セッション例 ......................................................... 164
Ⅳ.１

Ｖ．３４を用いた セッション例 ............................................................................................................ 164

付録 Ⅴ （ＪＴ－Ｔ３８に対する） ＪＴ－Ｔ３８実装ガイドライン ............................................................. 175
Ⅴ.1 一般的な問題 ............................................................................................................................................... 175
Ⅴ.1.1 伝送ビット順序 .................................................................................................................................... 175
Ⅴ.1.2 パケットの間隔 .................................................................................................................................... 175
Ⅴ.1.3 ＪＴ－Ｔ３０信号の間のプリアンブルパケット ............................................................................. 175
Ⅴ.1.4 パケット中の信号の分割 .................................................................................................................... 175
Ⅴ.1.5 パケットサイズの制限 ........................................................................................................................ 176
Ⅴ.1.6 送信されたＴＣＦのパケット ............................................................................................................ 176
Ⅴ.1.7 ネットワーク技術ガイドライン......................................................................................................... 176
Ⅴ.2 ＩＡＦの問題 ............................................................................................................................................... 179
Ⅴ.2.1 ＪＴ－Ｔ３０タイマ値 ........................................................................................................................ 179
Ⅴ.2.2 ＩＡＦ間のデータレート .................................................................................................................... 179
Ⅴ.2.3 ＩＡＦとゲートウェイ間のデータレート ......................................................................................... 179
Ⅴ.3 呼設定の問題 ............................................................................................................................................... 179
V.3.1 SetupメッセージのCalledPartyNumber （付属資料Ｂ） .................................................................... 179
V.3.2 音声能力の宣言 ..................................................................................................................................... 179
V.3.3 ＪＴ－Ｔ３８付属資料Ｄの属性におけるコロン「：」の不正確な使用について ....................... 179
V.3.4 ＳＩＰとＪＴ－Ｈ２４８．１におけるＵＤＰＴＬとT38MaxBitRateとの相違について ............. 180
V.4 その他 ............................................................................................................................................................ 180
V.4.1 ＭＧＣへのＤＣＮ通知の遅延について .............................................................................................. 180
付録 Ⅵ （ＪＴ－Ｔ３８に対する） セキュリティに関する経緯 ..................................................................... 181
Ⅵ.1 ＪＴ-Ｔ３８の起源と使用 .......................................................................................................................... 181
Ⅵ.2 アプリケーション対ネットワーク／トランスポートレベル セキュリティ .......................................... 183-5-

ＪＴ－Ｔ３８

＜参考＞１．国際勧告等との関連
本標準は、IP ネットワーク上のリアルタイムグループ３ファクシミリ通信手順について記述しており、Ｉ
ＴＵ－Ｔ勧告Ｔ．３８（１１／２０１５）に準拠したものである。

２．上記国際勧告等に対する追加項目等
2.1 オプション選択項目なし

2.2 ナショナルマター決定項目なし

2.3 先行している項目なし

2.4 追加した項目なし

2.5 削除した項目なし

2.6 その他（１） 国際勧告に対する修正内容
本標準を審議するに当たり基本とした国際勧告において、その内容より判断して明らかに誤りと思われる下記項目に関して、修正を行った。

本標準中の箇所

国際勧告中の表記

修正後（本標準で）の表記

６．２．１

NSF, NCS and NSS

ＮＳＦ、ＮＳＣおよびＮＳＳ

（２箇所）

（２箇所）

E.2.1.2 の（１）D.2.2.1

E.2.2.1

Ⅲ．２．１の（２）

F1

G3FE1

Ⅴ．３．４

ｕｐｄｔｌ

ｕｄｐｔｌ

H.2.2.1
付表Ｈ．２
番号：９

If T38FaxMaxIFP is included in an offer, then T38FaxMaxIFP をオファーに含むとinclusion of this parameter is Mandatory in that き、T38FaxMaxDatagram もオファーに必須で含むべきである
offer.

-6-

ＪＴ－Ｔ３８

（２） 参照する勧告、標準等
ＴＴＣ標準：
ＪＴ－Ｅ１６４，ＪＴ－Ｇ７１１，ＪＴ－Ｇ７２６，ＪＴ－Ｇ７２９，ＪＴ－Ｈ２２５．０，
ＪＴ－Ｈ２４５，ＪＴ－Ｈ２４８．１，ＪＴ－Ｈ３２３，ＪＴ－Ｑ８５０，ＪＴ－Ｑ９３１，
ＪＴ－Ｔ４，ＪＴ－Ｔ３０，ＪＴ－Ｈ４５０．１，ＪＴ－Ｈ４５０．２，ＪＴ－Ｈ４５０．３，
ＪＴ－Ｈ４５０．４，ＪＴ－Ｈ４５０．５，ＪＴ－Ｈ４５０．６，ＪＴ－Ｈ４５０．７，
ＪＴ－Ｈ４５０．８

ＩＴＵ－Ｔ勧告：
Ｅ．１８０／Ｑ．３５，Ｆ．１８５，Ｇ．７９９．３，Ｈ．２４８．２，Ｔ．６，Ｔ．３７，
Ｔ．６６，Ｖ．８，Ｖ．３３，Ｖ．３４，Ｖ．１５０．１，Ｖ．１５２，Ｖ．１５３，Ｘ．３８，
Ｘ．４２０，Ｘ．６８０，Ｘ．６９１，

ＲＦＣ文書：
ＲＦＣ７６８，ＲＦＣ７９１，ＲＦＣ７９３，ＲＦＣ１００６，ＲＦＣ２１９８，ＲＦＣ２３２７，
ＲＦＣ３２６１，ＲＦＣ３２６４，ＲＦＣ３５５０，ＲＦＣ４６１２，ＲＦＣ４７３３，ＲＦＣ４
７３４，
ＲＦＣ５１０９，ＲＦＣ５９３９，ＲＦＣ６４６６，ＲＦＣ６８７１

３．改版の履歴

版

数

第１版

制

定

日

改

２００１年４月１９日

版

内

制

定

容

ＲＦＣ２５４３（ＳＩＰ）、ＲＦＣ２３２７（ＳＤＰ）
および、ＩＴＵ－Ｔ勧告Ｈ．２４８による呼確立手順の第２版

２００２年５月３０日

追加、

T30INDICATOR 必須、付属資料 B の手順の明確化、バージョン番号を２に更新、ＭＧのための呼確立
手順例による明確化等による改版

image/t38 の IANA への登録、付属資料 D の例のエラー
第３版

２００３年４月２３日

訂正と表現の適正化、付録Ⅲの例の明確化と表現の適正化およびその他の国際勧告の修正による改版

第３．１版

２００４年４ 月２０日

付属資料 A のＪＴ－Ｔ３８(第３．１版)
抽象構文記法１（ＡＳＮ．１）追加による改版
Ｖ．８、Ｖ．３４モデム対応、ＲＴＰサポート、ＳＩＰ

第４版

２００６年６月１日／ＳＤＰ呼設定ベンダー情報、実装ガイドラインおよびその他の国際勧告の修正による改版-7-

ＪＴ－Ｔ３８

第５版

２００７年５月３１日

h245Tunnelling の扱いについて追記、および付図Ⅲの誤
記修正
ＪＴ－Ｈ３２３、ＪＴ－Ｈ２４８．１ 、ＳＩＰ、ＳＤＰ
呼の確立の説明適正化、Ｖ．３４からのフォールバック

第６版

２００８年５月２９日

手順を含むゲートウェイとＧ３ファクシミリ間の互換性の改良、 およびその他の国際勧告の修正による改版

第７版

２０１８年５月２４日

２０１５年までに実施された国際勧告の修正による改版

４．工業所有権本標準に関わる「工業所有権等の実施の権利に係る確認書」の提出状況は、ＴＴＣホームページで御覧に
なれます。

-8-

ＪＴ－Ｔ３８

ＴＴＣ標準ＪＴ－Ｔ３８
ＩＰネットワーク上のリアルタイムグループ３ファクシミリ通信手順

１．適用範囲本標準により、PSTN または ISDN だけでなく、端末の間で使われた伝送パスの部分が IP ネットワーク、
例えばインターネットを含む端末の間のＧ３ファクシミリ伝送を許すために適用される手順が定義される。

２．参照規格以下のＩＴＵ－Ｔ勧告および他の参照規格は、このテキストでの参照を通じて、本標準の規定を構成している規定が記述されているものである。出版時においては、下記の版は有効であった。すべての標準および他の参照規格は改訂版にしたがう。そのため、本標準のユーザには、以下に挙げた標準と参照規格の最新版の適用を推奨する。現在有効なＴＴＣ標準およびＩＴＵ－Ｔ勧告のリストは定期的に出版されている。
－ ＴＴＣ標準ＪＴ－Ｅ１６４（２０１５）

国際公衆電気通信番号計画－ ＩＴＵ－Ｔ勧告

Ｅ．１８０／Ｑ．３５（１９９８）

Technical characteristics of tones for the telephone service
電話サービスのためのトーンの技術特性－ ＩＴＵ－Ｔ勧告

Ｆ．１８５（１９９８）

Internet facsimile: Guidelines for the support of the communication of facsimile documents
インターネットファクシミリ：サービスの操作と定義－ ＴＴＣ標準

ＪＴ－Ｇ７１１（２０１１）

音声周波数帯域信号のＰＣＭ符号化方式－ ＴＴＣ標準

ＪＴ－Ｇ７２６（２００５）

４０，３２，２４，１６Ｋｂｉｔ／ｓ 適応差分パルス符号変調方式－ ＴＴＣ標準

ＪＴ－Ｇ７２９（２００６）

８ｋｂｉｔｓ／ｓ ＣＳ－ＡＣＥＬＰを用いた音声符号化方式－ ＩＴＵ－Ｔ勧告

Ｇ．７９９．３（２０１１）

Signal processing functionality and performance of an IP-to-IP voice gateway optimized for the transport of voice
and voiceband data
音声及び音声帯域データの転送に最適化されたＩＰネットワーク間音声ゲートウェイの信号処理機能
及び性能－ ＴＴＣ標準

ＪＴ－Ｈ２２５．０（２００８）

パケットに基づくマルチメディア通信システムのためのシグナリングプロトコルとメディア信号のパケット化－ ＴＴＣ標準

ＪＴ－Ｈ２４５（２００８）

マルチメディア通信制御プロトコル－ ＴＴＣ標準

ＪＴ－Ｈ２４８．１（２００６）

メディアゲートウェイ制御プロトコル－ ＩＴＵ－Ｔ勧告

Ｈ．２４８．２（２０１３）

Gateway control protocol: Facsimile, text conversation and call discrimination packages
ゲートウェイ制御プロトコル：ファクシミリ、テキスト会話およびコール識別パッケージ－ ＴＴＣ標準

ＪＴ－Ｈ３２３（２００８）

パケットに基づくマルチメディア通信システム-9-

ＪＴ－Ｔ３８

－ ＴＴＣ標準ＪＴ－Ｑ８５０（１９９６）

ディジタル加入者線信号方式Ｎｏ．１およびＮｏ．７信号方式ＩＳＤＮユーザ部における理由表示の使用法および生成源－ ＴＴＣ標準

ＪＴ－Ｑ９３１（１９９８）

ＩＳＤＮユーザ・網インタフェース－ ＴＴＣ標準

レイヤ３仕様ＪＴ－Ｔ４（２００４）

文書伝送用グループ３ファクシミリ装置の端末特性－ ＩＴＵ－Ｔ勧告

Ｔ．６（１９８８）

Facsimile coding schemes and coding control functions for Group 4 facsimile apparatus
Ｇ４ファクシミリ装置のためのファクシミリ符号化方式と符号化制御機能－ ＴＴＣ標準

ＪＴ－Ｔ３０（２００８）

一般交換電話網における文書ファクシミリ伝送手順－ ＴＴＣ標準

ＪＴ－Ｔ３７（２０１０）

蓄積交換型のインターネットファクシミリデータ伝送手順－ ＩＴＵ－Ｔ勧告

Ｔ．６６（２００２）

Facsimile code points for use with Recommendations V.8 and V.8 bis
Ｖ．８やＶ．８ｂｉｓの勧告で使用されるファクシミリコードのポイント－ ＩＴＵ－Ｔ勧告

Ｖ．８（２０００）

Procedures for starting sessions of data transmission over the public switched telephone network
一般電話交換網におけるデータ伝送のセッション開始手順－ ＩＴＵ－Ｔ勧告

Ｖ．２１（１９８８）300 bits per second duplex modem standardized for use in the general switched telephone network
一般電話交換網用に標準化された３００ｂｉｔ／ｓ全二重モデム－ ＩＴＵ－Ｔ勧告

Ｖ．３３（１９８８）

14 400 bits per second modem standardized for use on point-to-point 4-wire leased telephone-type circuits
ポイントツウポイント４線式専用電話形回線用に標準化された１４４００ｂｉｔ／ｓモデム－ ＩＴＵ－Ｔ勧告

Ｖ．３４（１９９８）

A modem operating at data signalling rates of up to 33 600 bit/s for use on the general switched telephone networkand on leased point-to-point 2-wire telephone-type circuits
一般交換電話網および２線式ポイントツウポイント電話形専用回線で使用する３３６００ｂｉｔ／ｓ
までのデータ信号速度で動作するモデム－ ＩＴＵ－Ｔ勧告

Ｖ．１５０．１（２００３）

Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs
ＩＰネットワーク上のモデム：ＶシリーズＤＣＥのエンドツーエンド接続の手順－ ＩＴＵ－Ｔ勧告

Ｖ．１５２（２０１０）

Procedures for supporting voice-band data over IP networks
ＩＰネットワーク上で音声帯域データをサポートする手順－ ＩＴＵ－Ｔ勧告

Ｖ．１５３（２００９）

Interworking between ITU-T T.38 and ITU-T V.152 using IP peering for real-time facsimile services
リアルタイムファクシミリサービスのＩＰピアリングを使用したＩＴＵ－Ｔ

Ｔ．３８とＩＴＵ－Ｔ

Ｖ．１５２との間のインターワーキング－ ＩＴＵ－Ｔ勧告

Ｘ．３８（１９９６）

G3 facsimile equipment/DCE interface for G3 facsimile equipment accessing the Facsimile Packet- 10 -

ＪＴ－Ｔ３８Assembly/Disassembly facility (FPAD) in a public data network situated in the same country
同一国にある公衆データネットワーク内のファクシミリパケットアセンブリ/ディスアセンブルファシ
リティ（FPAD）にアクセスするＧ３ファクシミリ装置のＤＣＥインタフェース－ ＩＴＵ－Ｔ勧告

Ｘ．４２０（１９９９）

Information technology – Message Handling Systems (MHS): Interpersonal Messaging System
情報技術：メッセージハンドリングシステム（ＭＨＳ）－個人間メッセージ通信システム－ ＩＴＵ－Ｔ勧告

Ｘ．６８０（２０１５）

Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation
情報技術：抽象構文表記法（ＡＳＮ．１）基本表記法の仕様－ ＩＴＵ－Ｔ勧告

Ｘ．６９１（２０１５）｜ＩＳＯ／ＩＥＣ８８２５－２：２０１５

Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)
情報技術：ＡＳＮ．１符号化規則－パック符号化規則（ＰＥＲ）の仕様－ ＲＦＣ７６８（１９８０）
User Datagram Protocol
ユーザデータグラムプロトコル－ ＲＦＣ７９１（１９８１）
Internet Protocol
インターネットプロトコル－ ＲＦＣ７９３（１９８１）
Transmission Control Protocol
伝送制御プロトコル－ ＲＦＣ１００６（１９８７）
ISO Transport Service on top of the TCP Version: 3
ＴＣＰ上のＩＳＯトランスポートサービス－ ＲＦＣ２１９８（１９９７）
RTP Payload for Redundant Audio Data
冗長オーディオデータ用の RTP ペイロード－ ＲＦＣ２３２７（１９９８）
SDP: Session Description Protocol
ＳＤＰ：セッション記述プロトコル－ ＲＦＣ３２６１（２００２）
SIP: Session Initiation Protocol
ＳＩＰ：セッション開始プロトコル－ ＲＦＣ３２６４（２００２）
An Offer/Answer Model with Session Description Protocol (SDP)
セッション記述プロトコル（ＳＤＰ）を使ったオファー/アンサーモデル－ ＲＦＣ３５５０（２００３）
RTP: A Transport Protocol for Real-Time Applications
ＲＴＰ：リアルタイムアプリケーションのためのトランスポートプロトコル－ ＲＦＣ４６１２（２００６）
Real-Time Facsimile(T.38)-audio/t38 MIME subtype Registration
リアルタイムファクシミリ（Ｔ．３８）「audio/t38」の MIME サブタイプ登録- 11 -

ＪＴ－Ｔ３８

－ ＲＦＣ４７３３（２００６）
RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
ＤＴＭＦディジット、電話トーン、電話信号のためのＲＴＰペイロード－ ＲＦＣ４７３４（２００６）
Definition of Events for Modem, Fax, and Text Telephony Signals
モデム、ファクス、およびテキストテレフォニー信号のイベント定義－ ＲＦＣ５１０９（２００７）
RTP Payload Format for Generic Forward Error Correction
一般的な前方エラー訂正のためのＲＴＰペイロードフォーマット
－ ＲＦＣ５９３９（２０１０）
Session Description Protocol (SDP) Capability Negotiation
ＳＤＰのケーパビリティネゴシエーション－ ＲＦＣ６４６６（２０１１）
IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)
セッション記述プロトコル（ＳＤＰ）の「image」メディアタイプのＩＡＮＡ登録－ ＲＦＣ６８７１（２０１３）
Session Description Protocol (SDP) Media Capabilities Negotiation
ＳＤＰのメディアケーパビリティネゴシエーション（注）以下、本標準中における上記参照規格の引用では、「ＴＴＣ標準」や「ＩＴＵ―Ｔ勧告」を省略した表現とする。

３．定義
とくに言及されない限り、Ｆ．１８５の定義が適用されなければならない。

3.1 送信ゲートウェイ：
発信Ｇ３ＦＥのためのＩＦＴサービスを開始するＩＦＰピア。
これは、IFT セッションを開始するために受信ゲートウェイとのＴＣＰまたはＵＤＰ接続を初期化する。

3.2 受信ゲートウェイ：
着信側のＧ３ＦＥへのＩＦＴサービスを提供して送信ゲートウェイからＴＣＰまたはＵＤＰ接続を受け入れるＩＦＰピア。

3.3 Ｇ３ファクシミリ装置（Ｇ３ＦＥ）：
本標準において、Ｇ３ＦＥは、ＪＴ－Ｔ３０、ＪＴ－Ｔ４、およびオプションでＴ．６に対応している通信インタフェースをもつ実際の機器とみなすことが出来る。Ｇ３ＦＥは、従来のＧ３ファクシミリ装置、Ｊ
Ｔ－Ｔ３０プロトコルエンジンを持つアプリケーション、またはＩＰファクシミリのためのネットワークモ
デルにおいて提案された他の機器のいずれにもなり得る。

3.4 ＪＴ－Ｔ３８／Ｇ３：
本標準において、ＪＴ－Ｔ３８／Ｇ３は、Ｇ３ＦＥをサポートするがＪＴ－Ｔ３０／Ｖ．３４手順を含んでいないＪＴ－Ｔ３８エンドポイントを指す。

- 12 -

ＪＴ－Ｔ３８

3.5 ＪＴ－Ｔ３８／Ｖ．３４Ｇ３：
本標準において、ＪＴ－Ｔ３８／Ｖ．３４Ｇ３は、Ｇ３ＦＥをサポートし、ＪＴ－Ｔ３０／Ｖ３４半二重
手順を含むＪＴ－Ｔ３８エンドポイントを指す。

3.6 Ｔ３８トランスポートモード：
実際のプロトコルは、ＪＴ－Ｔ３８プロトコル層の下にスタックされる。「ＵＤＰＴＬ／ＵＤＰ」、「ＲＴＰ／ＵＤＰ」そして「ＴＰＫＴ／ＴＣＰ」というラベルの付いた３つの主なＴ３８トランスポートモードがある。

（注）Ｔ３８トランスポートモードのバリエーションが存在する可能性がある。
例として、セキュリティ強化されたＴ３８トランスポートモードの場合：「ＵＤＰＴＬ／ＤＴＬＳ／ＵＤＰ」、「ＳＲＴＰ／ＵＤＰ」そして「ＴＰＫＴ／ＴＬＳ／ＴＣＰ」

４．略語
本標準においては次の略語を用いる。
ＡＮＳａｍ

振幅変調応答トーン

ＣＩ

起呼表示（信号）ＣＭ

起呼メニュー（信号）ＣＪ

起呼メニュー終端子（信号）ＤＴＬＳ

データグラムトランスポートレイヤーセキュリティ

ＥＣＭ

エラー訂正モードＦＤ

ファクシミリ装置

ＦＥＣ

前方エラー訂正

ＦｏＩＰ

ＩＰ上のファクシミリ装置

Ｇ３ＦＥ

グループ３ファクシミリ装置

ＧＷ

ゲートウェイ

ＩＡＦ

インターネット対応ファクシミリ装置

ＩＦＰ

インターネットファクシミリプロトコル

ＩＦＴ

インターネットファクシミリ転送

ＩＮＦＯｈ

半二重ＩＮＦＯシーケンス

ＩＰ

インターネットプロトコル

ＪＢＩＧ

階層的二値画像圧縮方式

ＪＭ

共通メニュー（信号）ＬＳＢ

最下位ビットＭＧ

メディアゲートウェイ

ＭＧＣ

メディアゲートウェイコントローラ

ＭｏＩＰ

ＩＰ上のモデム

ＭＭＲ

拡張二次元符号化方式

ＭＰｈ

Ｖ３４半二重変調パラメータシーケンス

ＭＳＢ

最上位ビット

Ｏ／Ａ

オファー／アンサー

ＯＬＣ

開放論理チャネル

ＲＴＣＰ

リアルタイム制御プロトコル- 13 -

ＪＴ－Ｔ３８

ＲＴＰ

リアルタイムプロトコル

ＳＤＰ

セッション記述プロトコル

ＳＤＰ Ｏ／Ａ

ＳＤＰオファー／アンサー

ＳＩＰ

セッション開始プロトコル

ＳＵＢ

サブアドレス

ＴＣＦ

トレーニングチェック

ＴＣＰ

伝送制御プロトコル

ＴＬＳ

トランスポートレイヤセキュリティ

ＴＰＫＴ

トランスポートレイヤプロトコルデータパケット

ＵＤＰ

ユーザデータグラムプロトコル

ＵＤＰＴＬ

ＵＤＰトランスポートレイヤ

ＶＢＤ

音声帯域データ

ＶＢＤｏＩＰ

ＩＰ上の音声帯域データ

５．はじめにインターネットなどの国際的なＩＰネットワークの利用により、通信端末間のＧ３ファクシミリメッセー
ジ転送にこの通信メディアを使用する可能性が出てきている。ＩＰネットワークの特徴は、ＰＳＴＮまたはＩＳＤＮによって提供されていたものと異なるため、ファクシミリオペレーションを維持するためには、いくつかの付加的な規格が標準化される必要がある。
本標準において定義されたプロトコルは、ファクシミリゲートウェイおよび／またはＩＰネットワークを経て接続された複数のＩＡＦ間で交換されたメッセージとデータを規定する。本標準のための参照モデルは
図１／ＪＴ－Ｔ３８に示される。
このモデルは、従来のＧ３ファクシミリ装置がＩＰネットワークを通してファクシミリ通信を送信するゲー
トウェイと接続し、着信側Ｇ３ファクシミリ機器にＰＳＴＮ発信を行う受信ゲートウェイにファクシミリ通
信を送信している状態である。いったん両方の端末においてＰＳＴＮ通信が確立されたら、仮想的に２つのＧ３端末が接続される。
すべてのＪＴ－Ｔ３０セッションの確立とネゴシエーションは、端末間で実行される。
Ｖ．３４に対応していないＧ３ＦＥ機器においては、ＴＣＦはゲートウェイとＧ３ＦＥ機器間の変調速度を同期させるオペレーションのモードによってローカルに生成されるかまたは端末間で転送される。
他の事例として、ＩＰネットワークに直接接続しているファクシミリ通信が可能な機器（例えばＰＣ）との接続が示されている。この場合には、機器のファクシミリ可能化ソフトウェアおよび／またはハードウェ
アの一部として仮想的な受信ゲートウェイがある。他の事例として、機能が逆転する場合、または２つのファ
クシミリ通信が可能なネットワーク機器がある場合も想定される。本標準により定義されたプロトコルは、送信および受信ゲートウェイの間で直接動作する。ゲートウェイとファクシミリ装置および／または他機器間の通信は、本標準の範囲外である。
本標準において定義されたプロトコルは効率性と経済性を基準として選定された。最適な性能のために、
ＩＰ伝送パスは、Ｆ．１８５要件を満たすように、適度な低遅延でなければならない。良質な画像品質は、
ＪＴ－Ｔ３０プロトコルから提供された方式だけでなくネットワークにおけるエラーコントロールからも提供される。
信頼できるデータ伝送は２つの方式で提供される。すなわち、ＩＰネットワーク上のＴＣＰを使う方式と、またはエラーコントロールのためのオプション手段によってＩＰネットワーク上のＵＤＰを使う方式である。
呼制御手順は、ＪＴ－Ｈ３２３、ＳＩＰおよびＨ．２４８シリーズ（ＪＴ－Ｈ２４８．１およびＨ．２４- 14 -

ＪＴ－Ｔ３８８．２）の３種類がある。ＪＴ－Ｈ３２３システムは、付属資料Ｄ／ＪＴ－Ｈ３２３において述べられるよ
うに、どちらの方式でも利用できる。ＪＴ－Ｈ３２３環境は、ＰＳＴＮの代替としてＩＰ上の音声通信をサポートするために用いられている。一般にファクシミリは音声通信と同じ設備を使うので、ＩＰ上のファク
シミリ実装はＪＴ－Ｈ３２３環境を利用することが望ましい。

送信受信ゲートウェイゲートウェイ
受信側

送信側
ファクシミリG3 端末装置

Called端末装置
ファクシミリ
G3
PSTN

Heisfks dfjsl kj dfi owk fjks dfs
sdfksl dkfjls di xc ovsl kdjf
xc vkos fdjg woidfvl xc vx kj voisd

IP

PSTN
Heisfks dfjslkjdfiow ksdfjkow
fjksdfsdthiuo
ksdf
sdfksld kfjlsdixcovslkdjfweoijsdv kxcvl
xcvko sfdjgwoidfvlxcvxocivjosd
kjvois dfkldf
ijfg,dklk

ネットワーク

sdfj kowthiuos d
dks dfweoijs dvkxc vl kj xk
oci vjos dijfg,dkl kdj o
fkl dfg

sd
kjx k
djo

g

ＩＰ認識
ファクシミリ装置

Heisfks dfjslkjdfiow ksdfjkow thiuo sdsdfksld kfjlsdixcovslkdjfweoijsdv kxcvl
xcvko sfdjgwoidfvlxcvxocivjosd ijfg,dklkdjo

fjksdfsd ksdf
kjx k
kjvois dfkldfg

T082788098/d01

図 1／ＪＴ－Ｔ３８ ＩＰネットワーク上のファクシミリ伝送のためのモデル（ＩＴＵ－Ｔ Ｔ．３８）ある状況では、ゲートウェイとＧ３端末の間の手続に何らかの調整をする必要があるかもしれない。その調整もＪＴ－Ｔ３０プロトコルで可能な範囲を越えるべきではない。これらの調整は実装に依存する。
本標準において定義されたプロトコルは、インターネットプロトコルの上のリアルタイムファクシミリ文
書転送を実装している２つのピア（ゲートウェイまたはＩＡＦ）の間でネットワーク接続が設立された期間を中心に扱う。
管理関連の課題、たとえばディレクトリサービス（必要に応じたＰＳＴＮ番号のＩＰアドレス変換）、ネッ
トワーク探索、ユーザ認証およびＣＤＲ（発信詳細レコード）収集、およびネットワーク管理（ＳＮＭＰ他）は重要であるけれども、本標準においては扱わない。これらの課題の標準化により、標準を実装したネット
ワーク機器、たとえば、インターネット電話技術、ビデオ、リモートアクセス、電子メールなどを他のインターネットゲートウェイと共有することを含むサードパーティー機器のインプリメンテーションが行われる。
さらに、ユーザインターフェース面において、ファクシミリオペレータが宛先のＰＳＴＮ番号を選ぶか、またはシステムに（セキュリティ目的で）ファクシミリオペレータ自身を識別させる方式なども本標準の範囲外である。
しかし、ファクシミリオペレータはＧ３端末機器キーパッド（トーンシグナルを使って）またはインターネッ
ト対応ファクシミリ装置のキーボードを使用して必要な情報をゲートウェイに提供する、と仮定することが妥当である。
これらの課題の内、あるものは他のＴＴＣ標準、ＩＴＵ－Ｔ勧告およびＩＥＴＦに割り当てられている。特に、ＪＴ－Ｈ３２３、ＪＴ－Ｈ２２５．０、Ｈ．２４８シリーズ（ＪＴ－Ｈ２４８．１およびＨ．２４８．
２）とＳＩＰとゲートキーパー／コールエージェントに関する標準は、上記の標準の依存状態のうちのいく
つかに割り当てられている。
- 15 -

ＪＴ－Ｔ３８

本標準内のすべての手続は、Ｆ．１８５の要件に対応することを意図している。
本標準では送信ゲートウェイと受信ゲートウェイの間のプロトコルと通信手続を解説する。付属資料Ｂ、Ｄ、ＥおよびＦにおいては、発信制御手続と共に、ゲートウェイと発信および着信Ｇ３ＦＥ間の通信手続きが解説される。
本標準は、ＡＳＮ．１でサポートされている形態に依存している構文やバージョンで明示的に定義されるバージョン番号を提供する。本バージョン番号は、ＪＴ－Ｔ３８デバイスが特定の機能または機能をサポートすることではなく、ＪＴ－Ｔ３８の特定のバージョンで定義されたＡＳＮ．１を構文的に解析できることを意味する。

下記の表に、ＪＴ－Ｔ３８の版とバージョン番号の関係を示す。

ＪＴ－Ｔ３８の版とバージョン番号

内容

バージョン

ＪＴ－Ｔ３８の版

番号
0

第１版

抽象構文記法１・第１版（ＡＳＮ．１）
1

第１版

抽象構文記法１

・ＴＴＣ標準では使用しない（ＡＳＮ．１）, TPKT, IAF（注１）TPKT をサポートするバージョン番号０のサポート

端末が存在することに注意（注２）付属資料 D，Ｅをサポートするバージョン
番号１の端末が存在することに注意

2

第３．１版

・第２版、３版、３．１版

抽象構文記法１（ＡＳＮ． （注３）第１版の抽象構文記法１（ＡＳＮ．１）と１）

して動作するバージョン番号２の端末が存在する
ことに注意

3

２００２文法拡張・第４版、５版、６版

Ｖ．３４およびＶ．３３サ
ポート
4

付属資料Ｄでネゴシエー

・第７版

ションされたパラメータのためのデフォルト定義

ＪＴ－Ｔ３８のバージョン番号は必須な属性（付表Ｂ．１／ＪＴ－Ｔ３８参照）であり、送信ゲートウェ
イと受信ゲートウェイ間で交換されなければならない。エンドポイントがＪＴ－Ｔ３８バージョン属性でサポートするバージョン番号を提示しなければならない。受信側は、提示されたバージョン番号を受け入れる
か、または最初の応答を送信するときに、等しいかまたはより低いバージョン番号にバージョン属性を修正しなければならない。受信側は、提示されたバージョン番号より高いバージョン番号を含んでいる応答で返答してはならない。
ＪＴ－Ｔ３８ 装置の初期の実装は、ＪＴ－Ｔ３８のバージョン番号を供給しないかもしれない。バージョ
ン番号が無いＳＤＰの受信側では、エンドポイントはバージョン番号が０であると想定されなければならない。 バージョン番号０の装置はそれらのバージョン番号を明示的に公表することを推奨する。

- 16 -

ＪＴ－Ｔ３８

5.1 コンベンション
5.1.1 ＳＤＰオファー／アンサープロトコルの変形
本標準ではシグナリング構文の例を提供する。メディアとトランスポート能力の表示とネゴシエーション
に関するセッション記述プロトコル（ＳＤＰ）には、２つのモデルがある。
– 「レガシーなＳＤＰオファー／アンサー」という呼称は、ＲＦＣ３２６４に従うＳＤＰオファー／アンサーを示す。
– 「改訂されたＳＤＰオファー／アンサー」という呼称は、ＲＦＣ５９３９とＲＦＣ６８７１に従うＳＤＰ
オファー／アンサーを示す。

６．ゲートウェイ間通信
6.1 インターネットプロトコル－ＴＣＰまたはＵＤＰ
公共のインターネットサービスにより提供されるのはデータ通信の２つの主要なモードである。
（１）ＴＣＰ（伝送制御プロトコル）セッションベース、送達確認サービス。
（２）ＵＤＰ（ユーザデータグラムプロトコル）データグラムサービス、送達未確認サービス。
本標準では、サービス環境によりＴＣＰまたはＵＤＰの使用を許している。それは、ＴＣＰとＵＤＰ実装
により交換されるＪＴ－Ｔ３８メッセージが同一であるような階層化プロトコルを定義する。

6.2 ゲートウェイファクシミリデータ転送機能
送信ゲートウェイは、発信端末から受け取ったＪＴ－Ｔ３０通信を復調しなければならない。ＪＴ－Ｔ３
０ファクシミリコントロールとイメージデータは、オクテットストリーム構造で、転送プロトコル上でＩＦ
Ｐパケットを使って転送されなければならない（ＴＣＰまたはＵＤＰ）。信号ＣＮＧ、ＣＥＤ、および１つのモードのＴＣＦはゲートウェイの間で転送されないが、生成されるか、またはゲートウェイとＧ３ＦＥの間でローカルに処理される。

ゲートウェイは、他のゲートウェイがそれらを生成できるように、トーンシグナルＣＮＧとＣＥＤの検出を示すことができる。
受信ゲートウェイは、転送された情報を解読し、通常のＪＴ－Ｔ３０手続を使って、着信側ファクシミリ
装置との通信を確立しなければならない。受信ゲートウェイは、着信側端末からすべての適切な反応を送信
ゲートウェイに転送しなければならない。
ファクシミリデータ転送構造は７．１．３節において解説される。ゲートウェイの間の流れは８章において解説される。

6.2.1 非標準機能要求の取り扱い
送信ゲートウェイは、オプションでＮＳＦ、ＮＳＣおよびＮＳＳを無視するか、適切な動作を行うか、またはその情報を受信ゲートウェイに伝達するかもしれない。受信ゲートウェイは、オプションでＮＳＦ、Ｎ
ＳＣ、およびＮＳＳを無視するか、またはその情報を受信Ｇ３ＦＥに伝達するための適切な動作を行うかもしれない。これらのフレームと直接関連する他のフレームの情報は、ゲートウェイで変更されるかもしれない。

７．ＩＦＴプロトコルの定義と使用
7.1 概要本節にはＩＦＴプロトコルの詳細を含む。ＩＦＴプロトコルは付属資料ＡのＡＳＮ．１で定義されている。
ＡＳＮ．１とテキストが混在する場合、ＡＳＮ．１が優先される。付属資料ＡのＡＳＮ．１符号化はＸ．６- 17 -

ＪＴ－Ｔ３８９１による圧縮符号化規則（ＰＥＲ）のＢＡＳＩＣ－ＡＬＩＧＮＥＤバージョンを使用するべきである。

7.1.1 ビットとオクテット伝送順序
伝送順序はインターネットＲＦＣ７９１「インターネットプロトコル」に定義される。本標準で記述されるヘッダーとデータの伝送順序はオクテットレベルで決定される。図がオクテットグループを示すときは常に、それらオクテット伝送順序は英語で読める正常な順序である。例えば以下の図でオクテットは番号付けられた順序で伝送される。
001
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 82
3
9 0 1 2 3 4 5 6 7 8 9 0 1

1

2

3

4

5

6

7

8

9

10

11

12

図２／ＪＴ－Ｔ３８

オクテット伝送順序（図１０、ＲＦＣ７９１に基づく）（ＩＴＵ－Ｔ

Ｔ．３８）

オクテットが数量を表すときは常に、図で最も左のビットは高位、すなわち最上位ビットである。０とラベルされるビットは最上位ビットである。例えば以下の図は１７０（１０進）の値を表している。
0

1

2

3

4

5

6

7

1

0

1

0

1

0

1

0

図３／ＪＴ－Ｔ３８

ビットの意味（図１１、ＲＦＣ７９１に基づく）（ＩＴＵ－Ｔ

Ｔ．３８）

同様にマルチオクテットが数量を表すときは常に、フィールド全体で最も左のビットが最上位ビットである。
マルチオクテット量が伝送されるときは、最上位オクテットが最初に伝送される。

7.1.2 ＪＴ－Ｔ３０ビットストリームの配置
ＰＳＴＮとＩＰネットワーク間でビット順序が維持されるように、ＪＴ－Ｔ３０ビットストリームは移される。最初のビットが伝送されるこの方法は最初のオクテットのＭＳＢに格納され、ＭＳＢは７．１．１節のように定義される。

7.1.3 ＴＣＰ／ＩＰとＵＤＰ／ＩＰのためのＩＦＰパケットレイヤ
７．２節で記述されるＩＦＰパケットは図４／ＪＴ－Ｔ３８、図５／ＪＴ－Ｔ３８および図６／ＪＴ－Ｔ
３８で示されるようにＴＣＰ／ＩＰとＵＤＰ／ＩＰのための適切なヘッダーと結合される。図４／ＪＴ－Ｔ
３８に示されるように、ＲＦＣ１００６で定義されたＴＰＫＴヘッダーがＴＣＰ実装におけるＩＦＰパケッ
トに先行しなければならない。ＴＰＫＴを用いた実装は、バージョン番号に１以上を設定しなければならない。バージョン番号０の実装はＴＰＫＴを使ってはならない。

- 18 -

ＪＴ－Ｔ３８ａ）ＩＦＰ／ＴＣＰ／ＩＰ
パケットのレイヤモデル

ＴＰＫＴヘッダ

ＩＦＰパケット

ＴＣＰペイロード

ＴＣＰヘッダ

ＩＰヘッダ

ＩＰペイロードｂ）ＩＦＰ／ＴＣＰ／ＩＰ
プロトコルのフラットモデル
ＩＰヘッダ

ＴＣＰヘッダ

図４／ＪＴ－Ｔ３８

ＴＰＫＴヘッダ

ＩＦＰパケット

ハイレベルＴＣＰ／ＴＰＫＴ／ＩＰパケット構造（ＩＴＵ－Ｔ

Ｔ．３８）

ＵＤＰを使った転送のために、図５／ＪＴ－Ｔ３８に示されるように、ＩＦＰデータがＵＤＰＴＬ に入れられるか、あるいは、図６／ＪＴ－Ｔ３８に示されるように、代わりに ＲＴＰに入れられるかもしれない。
図５／ＪＴ－Ｔ３８で、ＵＤＰＴＬヘッダーはＵＤＰ上の誤り制御に必要である追加のヘッダー情報を表す。ＵＤＰＴＬカプセル化が使われるとき、ペイロード構造はＵＤＰＴＬパケットのための付属資料Ａで定義される。
ａ）ＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰ
パケットのレイヤモデル

ＵＤＰＴＬヘッダ

ＵＤＰＴＬペイロード＝ ＩＦＰパケット＋冗長／ＦＥＣ

ＵＤＰヘッダ

ＵＤＰペイロード

ＩＰペイロードＩＰヘッダｂ）ＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰ
プロトコルのフラットモデル
ＩＰヘッダ

ＵＤＰヘッダ

図５／ＪＴ－Ｔ３８

ＵＤＰＴＬヘッダ

ＩＦＰパケット＋ 冗長／ＦＥＣ

ハイレベルＵＤＰＴＬ／ＵＤＰ／ＩＰパケット構造（ＩＴＵ－Ｔ

Ｔ．３８）

もし両方のゲートウェイが呼接続時に能力交換を行うならば、ＪＴ－Ｔ３８ファクシミリ信号のＲＴＰカプセル化を使うだけでよい。この能力交換は付属資料Ｂ、Ｄ、Ｅあるいは付属資料Ｄ／ＪＴ－Ｈ３２３で記述される。ＲＴＰカプセル化では、オプションの冗長性とＦＥＣ機構はＲＦＣ２１９８で記述され、ＲＦＣ
５１０９を使用しても良い。
図６／ＪＴ－Ｔ３８で、任意のＲＴＰカプセル化が使われるときのパケット構造を表す。ＲＴＰパケットの中で、ＩＦＰパケットがオプションとして冗長なＩＦＰパケット（ＲＦＣ２１９８）あるいはＦＥＣパケッ
ト（ＲＦＣ５１０９とＲＦＣ２１９８）で一緒にされるかもしれない。もう１つの有効なＲＦＣ５１０９オ
プションは、図６／ＪＴ－Ｔ３８には示されないが、ＦＥＣパケットがＲＴＰパケットの中にＩＦＰ パケッ
トと一緒にされるよりむしろ別のＲＴＰストリームとして送られることを可能にする。ＲＦＣ２１９８がそれを不必要なＩＦＰパケットあるいはＦＥＣパケットで一緒にするために使われないとき、ＲＴＰペイロー- 19 -

ＪＴ－Ｔ３８ドは一つのＩＦＰパケットに対応する。

ａ）ＩＦＰ／ＲＴＰ／ＵＤＰ／ＩＰ
パケットのレイヤモデル

ＲＴＰヘッダ

ＲＴＰペイロード＝ ＩＦＰパケット＋冗長＊／ＦＥＣ＊＊

ＵＤＰペイロード

ＵＤＰヘッダ

ＩＰヘッダ

ＩＰペイロード＊ ＲＦＣ２１９８の冗長＊＊ＲＦＣ５１０９のＦＥＣｂ）ＩＦＰ／ＲＴＰ／ＵＤＰ／ＩＰ
プロトコルのフラットモデル
ＩＰヘッダ

ＵＤＰヘッダ

図６／ＪＴ－Ｔ３８

ＩＦＰパケット＋ 冗長＊／ＦＥＣ＊＊

ＲＴＰヘッダ

ハイレベルＲＴＰ／ＵＤＰ／ＩＰパケット構造（ＩＴＵ－Ｔ

Ｔ．３８）

7.2 ＩＦＰパケットフォーマット
以下の議論ではメッセージはプロトコルあるいは、単一期間にＧ３ＦＥからかゲートウェイから一方向に伝送されたデータ情報である。それは例えば、１個以上のＨＤＬＣフレーム、または１ページ分のフェーズ
Ｃデータを含むかもしれない。メッセージは複数パケットのＩＰネットワークの向こう側に送られるかもしれない。例えば、パケットは部分的かまたは完全か、単数または複数のＨＤＬＣフレームを含むかもしれな
い。複数パケットのサポートはこのプロトコルで提供される。データ要素は，部分的と完全なＨＤＬＣフレー
ムをサポートするフィールドを使用する。呼設定間で決定するポートを使用するＴＣＰ／ＩＰかＵＤＰ／Ｉ
Ｐ上でＩＦＰは動作する。ＩＦＰ間でのすべての通信がＩＦＰパケットと確認されるパケットを使用して行われる。表１／ＪＴ－Ｔ３８にＩＦＰパケットを要約する。（完全な説明については以下の節を参照）

表１／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

ＩＦＰパケット要素
Ｔ．３８）

フィールド

説明

種別

メッセージの種別

データ

種別に依存

7.2.1 ＪＴ－Ｔ３８パケット
ＪＴ－Ｔ３８パケット要素は、メッセージの始まりの呼出を提供し、メッセージ整列を確かめるために
ＩＦＰによって使用される。それはＡＳＮ．１のＪＴ－Ｔ３８関連のタグによって確認される。データがＴＣＰ／ＩＰかＵＤＰ／ＩＰスタックから読まれ、期待されたタグが存在しないとき，セッションは受信機によって直ちに中止されるべきである。

7.2.2 種別
種別要素がオプションのパケットデータの機能について記述している。種別が表２／ＪＴ－Ｔ３８で与えられている。各種別は以下の節で別々に説明されている。表はその種別がＴＣＰとＵＤＰを用いて必須かオ- 20 -

ＪＴ－Ｔ３８

プション実装であるのかを示している。
種別要素が認識されないならば、種別要素と関連するデータ要素は無視されなければならない。

表２／ＪＴ－Ｔ３８

ＩＦＰパケット種別フィールド（ＩＴＵ－Ｔ

種別
Ｔ３０＿ＩＮＤＩ

データ種別
正規

Ｔ．３８）

必須
Ｙｅｓ

ＣＡＴＯＲ

説明
ファクシミリ信号（ＣＥＤ／ＣＮＧ）、プリアン
ブルフラグまたは変調指示の存在に関して指示を伝送する

Ｔ３０＿ＤＡＴＡ

フィールド

Ｙｅｓ

ＪＴ－Ｔ３０ＨＤＬＣ制御とフェーズＣデータ（例ＪＴ－Ｔ４／Ｔ．６イメージセグメント）（注）ＤＩＳ／ＤＣＳ交換によって両方のＧ３ＦＥ装置がインターネット対応ファクシミリ装置（ＩＡＦ）と判断された場合は、Ｔ３０＿ＩＮＤＩＣＡＴＯＲの使用はオプションである。

7.2.3 データフィールド
データフィールド要素はＪＴ－Ｔ３０ＨＤＬＣ制御データとフェーズＣイメージ（またはＢＦＴ）データを含んでいる。データフィールドの構造は７．４節に定義される。ＨＤＬＣフレームの終端、ＨＤＬＣフレー
ムへのフレームチェックシーケンス（ＦＣＳ）の状態を示すことと、メッセージの終端を表すかどうかと同様にその構造で変調データが運ばれる。

7.3 種別定義
以下の節にメッセージ種別を記述する。

7.3.1 Ｔ３０＿ＩＮＤＩＣＡＴＯＲ
Ｔ３０＿ＩＮＤＩＣＡＴＯＲ種別はＣＥＤ、ＨＤＬＣプリアンブルフラグ、およびモデム変調トレーニン
グなどの信号の検出を示すためにゲートウェイによって使用されている。送信ゲートウェイへの受信ゲート
ウェイ、受信ゲートウェイへの送信ゲートウェイによってそれは送られている。このメッセージの使用はＤ
ＩＳ／ＤＣＳ交換によって両方のＧ３ＦＥ装置がインターネット対応ファクシミリ装置と判断される場合を除き必須である。それはやがて来るメッセージについて通知するためにこのメッセージを送るかもしれな
い。Ｔ３０＿ＩＮＤＩＣＡＴＯＲ種別は以下の値のひとつである。（表３／ＪＴ－Ｔ３８参照）- 21 -

ＪＴ－Ｔ３８表３／ＪＴ－Ｔ３８

Ｔ３０＿ＩＮＤＩＣＡＴＯＲ値の一覧表（ＩＴＵ－Ｔ

Ｔ．３８）

信号/指示
Ｎｏ

ｓｉｇｎａｌＣＮＧ（１１００Ｈｚ）

ＣＥＤ（２１００Ｈｚ）

Ｖ．２１

Ｐｒｅａｍｂｌｅ

Ｖ．２７

２４００

ｍｏｄｕｌａｔｉｏｎ

ｔｒａｉｎｉｎｇ

Ｖ．２７

４８００

ｍｏｄｕｌａｔｉｏｎ

ｔｒａｉｎｉｎｇ

Ｖ．２９

７２００

ｍｏｄｕｌａｔｉｏｎ

ｔｒａｉｎｉｎｇ

Ｖ．２９

９６００

ｍｏｄｕｌａｔｉｏｎ

ｔｒａｉｎｉｎｇ

Ｖ．１７

７２００

ｍｏｄｕｌａｔｉｏｎ

ｓｈｏｒｔ

Ｖ．１７

７２００

ｍｏｄｕｌａｔｉｏｎ

ｌｏｎｇ

Ｖ．１７

９６００

ｍｏｄｕｌａｔｉｏｎ

ｓｈｏｒｔ

Ｖ．１７

９６００

ｍｏｄｕｌａｔｉｏｎ

ｌｏｎｇ

Ｖ．１７

１２０００

ｍｏｄｕｌａｔｉｏｎ

ｓｈｏｒｔ

Ｖ．１７

１２０００

ｍｏｄｕｌａｔｉｏｎ

ｌｏｎｇ

Ｖ．１７

１４４００

ｍｏｄｕｌａｔｉｏｎ

ｓｈｏｒｔ

Ｖ．１７

１４４００

ｍｏｄｕｌａｔｉｏｎ

ｌｏｎｇ

Ｖ．８

ＡＮＳａｍ

Ｖ．８

ｓｉｇｎａｌｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ
ｔｒａｉｎｉｎｇ

ｓｉｇｎａｌＶ．３４－ｃｎｔｌ－ｃｈａｎｎｅｌ－１２００
Ｖ．３４－ｐｒｉ－ｃｈａｎｎｅｌ
Ｖ．３４－ＣＣ－ｒｅｔｒａｉｎ
Ｖ．３３

１２０００

ｍｏｄｕｌａｔｉｏｎ

ｔｒａｉｎｉｎｇ

Ｖ．３３

１４４００

ｍｏｄｕｌａｔｉｏｎ

ｔｒａｉｎｉｎｇ

ＴＤＭ入力に信号がないときはいつでも、“Ｎｏｓｉｇｎａｌ“表示を送っても良い。 例えば、 Ｖ．２

１モデムからＶ．１７モデムに変わったとき、あるいはＶ．１７モデムからＶ．２１モデムに変わったときに、それを使っても良い。
（注）適当なアナログ信号を適切に発生させることは、例えばＯＮ―ＯＦＦ等の適切に終了させることを含
み、指示を受けるゲートウェイの責任である。

- 22 -

ＪＴ－Ｔ３８

7.3.2 Ｔ３０＿ＤＡＴＡ種別
データ要素のデータを含むパケットであることや、そのデータを運ぶためにどの変調を用いたかを示すた
めにＴ３０＿ＤＡＴＡ種別は使われる。Ｔ３０＿ＤＡＴＡ種別はＨＤＬＣ制御データ、フェーズＣデータ（ＪＴ－Ｔ４／Ｔ．６か他の）、 Ｖ．３４変調が使われるときはいつもＶ．８制御信号データとＶ．３４コント
ロールチャネルとプライマリチャネルデータでも示すために使われる。それは以下の値がある。（表４／Ｊ
Ｔ－Ｔ３８参照）

表４／ＪＴ－Ｔ３８

Ｔ３０＿ＤＡＴＡ値の一覧表（ＩＴＵ－Ｔ

Ｔ．３８）

変調
Ｖ．２１

ｃｈａｎｎｅｌ２

Ｖ．２７ ｔｅｒ

２４００

Ｖ．２７ ｔｅｒ

４８００

Ｖ．２９

７２００

Ｖ．２９

９６００

Ｖ．１７

７２００

Ｖ．１７

９６００

Ｖ．１７

１２０００

Ｖ．１７

１４４００
Ｖ．８

Ｖ．３４－ｐｒｉ－ｒａｔｅ
Ｖ．３４－ＣＣ－１２００
Ｖ．３４－Ｐｒｉ－Ｃｈ
Ｖ．３３

１２０００

Ｖ．３３

１４４００

（注）ＤＩＳ／ＤＣＳ交換によって両方のＧ３ＦＥ装置がインターネット対応ファクシミリ装置と判断された場合は、Ｔ３０＿ＤＡＴＡは無視されなければならない。

7.4 ＩＦＰデータ要素
ＩＦＰパケットのデータ要素はＰＳＴＮ接続からのデータとそのデータフォーマットのいくつかの指示を含んでいる。データ要素はひとつ以上のフィールドにより構成される。各フィールドは２つの部分からなる。
一つ目はフィールド種別を示し、二つ目はフィールドデータを含む。フィールド種別の意味は表５／ＪＴ－
Ｔ３８に示される。

- 23 -

ＪＴ－Ｔ３８表５／ＪＴ－Ｔ３８フィールド種別とフィールドデータの説明（ＩＴＵ－Ｔ

Ｔ．３８）

フィールド種別

フィールド種別の説明

HDLCdata

データはＨＤＬＣとしてＰＳＴＮ接続の上で送信された。これはＥＣＭを用いて送信されたフェーズＣデータと同様にＪＴ－Ｔ３０コントロールメッセージを含む。
ＨＤＬＣフレームのアドレスフレームから始まる全てまたは単一のＨＤＬＣデータフレーム
を含むフィールドデータでＦＣＳを含まない。ビットスタッフィングは全てのデータから取り除かれる。フレームの終端はＦＣＳ指示フィールドにより示される。ＨＤＬＣデータをＧ３ＦＥに送るとき、ゲートウェイは、ビットスタッフィング、ＦＣＳ発生、１個あるいはそれ以上のフラグ（０ｘ７Ｅ）で分けられたフレームの分離に責任を持つ。ＦＣＳ－ｘｘ－Ｓ
ｉｇ－Ｅｎｄフィールドは最終フレームの終端を示す。

HDLC-Sig-End

ＨＤＬＣパワーレベルがターンオフ閾値より下まで低下したのを示す。このフィールド種別を用いたフィールドデータはない。

HDLC-FCS-OK

ＨＤＬＣフレームの終端を示し、適切なＦＣＳが受信された。またそれは、このフレームが最終フレームでないことを示す。このフィールド種別を用いたフィールドデータはない。

HDLC-FCS-Bad

ＨＤＬＣフレームの終端を示し、適切なＦＣＳは受信されていない。またそれは、このフレー
ムが最終フレームでないことを示す。このフィールド種別を用いたフィールドデータはない。

HDLC-FCS-OK-Sig-End

ＨＤＬＣフレームの終端を示し、適切なＦＣＳが受信された。非Ｖ．３４モードでは、また
それは、Ｖ．２１変調が終端されるべきであることを示す。Ｖ．３４モードでは、フラグがフレームに引き続き送信されなければならない。このフィールド種別を用いたフィールド
データはない。

HDLC-FCS-Bad-Sig-End

ＨＤＬＣフレームの終端を示し、適切なＦＣＳは受信されておらず、送信は終了すべきである。またそれは、このフレームが最終フレームであることを示す。このフィールド種別を用いたフィールドデータはない。

T.4-Non-ECM

速度整合の方法２の場合のＥＣＭまたはＴＣＦデータを使用して送信しないＪＴ－Ｔ４
フェーズＣデータ。またそれは、これがフェーズＣデータの終わりでないことを示す。
続くフィールドデータはフィルビットとＲＴＣを含む復調フェーズＣデータである。

T.4-Non-ECM-Sig-End

速度整合の方法２の場合のＥＣＭまたはＴＣＦデータを使用して送信しないＪＴ－Ｔ４
フェーズＣデータ。またそれは、これがフェーズＣデータの終わりであることを示す。
続くフィールドデータはフィルビットとＲＴＣを含む復調フェーズＣデータである。

cm-message

ＣＭ信号データはファクシミリアプリケーションプロファイルの中に変換される（表８／Ｊ
Ｔ－Ｔ３８参照）。
フィールドデータは表８／ＪＴ－Ｔ３８におけるプロファイル番号の一つのＩＡ５文字である。例えば、“１”はプロファイル１を示す。

jm-message

ＣＭメッセージに対する応答は、１０.１節で定義される。
フィールド - データは長さ２オクテットのＩＡ５文字列である。もしそれがＡＣＫなら最初の文字は“Ａ”であり、ｎＡＣＫなら“Ｎ”である。ＡＣＫの場合は“Ａ０”であり、ｎＡＣ
Ｋの場合は表９に示す値をとる。例えば、 ｎＡＣＫ（１）は“ Ｎ１”として表示される。

ci-message

Ｖ．８

ＣＩ信号で伝達されたデータはＩＡ５文字にマップされる。

フィールドデータはＣＩコールファンクションビットのビット６～８のデコードの結果に基づき、“４”ないし“５”オクテットのＩＡ５文字列を含む。注：ｂ８がＭＳＢでｂ６がＬＳＢである。

V.34-rate

決定された受信ゲートウェイと受信Ｇ３ＦＥ間のプライマリチャネルデータ信号レートを示す。
フィールドデータは長さ３オクテットのＩＡ５文字列でデータレートを示す。データレートの下位２桁は常に０で意味を持たないので、データレートの上位３桁をフィールドデータとする（例えば“０２４”は２４００ｂｉｔ／ｓを表す）。 （受信ゲートウェイと受信Ｇ３Ｆ
Ｅ間の２４００ｂｉｔ／ｓのレートはシンボルレート不適合の可能性のために拒否されることに注意）

複数のフィールドは単一のＩＦＰデータ要素に現れる。例として以下に単一のデータ要素で並べられた二つのＨＤＬＣフレームを示す。

- 24 -

ＪＴ－Ｔ３８表５．１／ＪＴ－Ｔ３８ ２つのＨＤＬＣフレームからなる単一のデータ要素の例（ＩＴＵ－Ｔ

Ｔ．３８）

フィールド種別

ＨＤＬＣ－Ｄａｔａ

ＦＣＳ－ＯＫ

ＨＤＬＣ－Ｄａｔａ

ＦＣＳ－ＯＫ－Ｓｉｇ－

フィールドの部分説明

最初のＨＤＬＣフレー

ＨＤＬＣフレームの終端

２番目のＨＤＬＣフレー

ＨＤＬＣフレームの終端

ム。ゼロであるＨＤＬＣと続くそれ以上のデータ

ムとＨＤＬＣデータの終端

オクテットとフィールド

を示す。

Ｅｎｄ

を示す。

データで取り除かれたＦ
ＣＳ。

（注）フィールド種別データ要素を受信しているとき、受信機は別々に各フィールドを調べることによりそれを分析するべきである。もし受信機が調べているフィールドの確実なフィールド種別を認識できな
ければ、全てのフィールドがスキップされなければならず、受信機は次のフィールドを続けなければならない。

ＩＦＰは、幾つかのパケットの中でメッセージデータを送信することを選択しても良い。比較的大きいパケットは送られるかもしれないが、より小さいデータパケットが勧められる。送られるパケットのサイズを決定するのは送信ゲートウェイ次第である。ｘｘ－Ｓｉｇ－Ｅｎｄフィールド種別はメッセージデータの終わりを示す。送信された各パケットについて全体のヘッダーが繰り返されることに注意する。
長さがゼロのデータフィールドがあるメッセージは、できるだけ早くＴ３０＿ＤＡＴＡメッセージが来るのを示すために送られるかもしれない。交互に、高速化のために適切なＴ３０＿ＩＮＤＩＣＡＴＯＲ信号が送信されうる。実装は両方の方法をサポートしなければならない。

部分的なＨＤＬＣフレームもまたサポートされる。次の例は二つのＨＤＬＣフレームが３つの連続したＩ
ＦＰパケットを用いてどのように伝送されるかを示す。（データトランスポートヘッダは示されない。）

表５．２／ＪＴ－Ｔ３８ ２つのＨＤＬＣフレームが３つの連続したＩＦＰパケットで電送される例（ＩＴＵ－Ｔ

Ｔ．３８）

種別要素
V.21Data

データ要素
Field-

HDLC

HDLC

HDLC

HDLC

HDLC

HDLC

HDLC

HDLC

Type:

Address

Control

Octet1

Octet2Octet3Octet4

Octet5Octet6

HDLC(0xff)DATA
V.21Data

Field-

HDLC

HDLC

HDLC

Field-

Type:

Octet7

Octet8Octet9TypeHDLC

FCS-OKDATA
V.21Data

Field-

HDLC

HDLC

HDLC

Field-

Type:

Address

Control

Octet1Type

HDLC(0xff)DATA

FCS-OKSig-End- 25 -

ＪＴ－Ｔ３８

7.5 Ｖ．２１フレームパケットサイズの制限
ネットワーク状況およびファクシミリ端末の互換性に従って柔軟にジッタバッファ調節を行なうには、相互接続されたゲートウェイ間において、ゲートウェイ処理遅延を縮小するために、より小さなＶ．２１フレー
ムデータパケットを使用することは、より有益である。最大のＶ．２１パケットサイズはＩＡＦを除いて、
7 バイトとしなければならない。より大きなＶ．２１フレームは多数のパケットで送られなければならない。
（注） 本標準の第５版（ＩＴＵ－Ｔ勧告Ｔ．３８の２００５年版準拠）及びそれ以前に適合する実装ではサイズを制限しない場合もある。

- 26 -

ＪＴ－Ｔ３８

８．Ｖ．１７以下のファクシミリ変調のためのＩＦＰメッセージフロー
ゲートウェイはＪＴ－Ｔ３０メッセージフローに従い、これらのメッセージを伝達するために７章のパケットフォーマットを使う。例えば、ＥＣＭモードでのエラー訂正は送信Ｇ３ＦＥと受信Ｇ３ＦＥとの間で行われることを意味する。ＰＰＳ，ＰＰＲその他の信号はＧ３ＦＥ装置間で送られる。もう１つの例として、
ＪＴ－Ｔ３０付属資料Ｈで禁止されているセキュリティキーのネゴシエーション、その他がＧ３ＦＥとの間で行われている。典型的なメッセージフローの例が付録Ｉに示されている。

高速データ転送速度を決定するＴＣＦ信号を処理するためには２つの方法がある。これらの方法はいずれも双方のＰＳＴＮファクシミリセッションが同じ速度で行われることを保証する。

8.1 データ転送速度管理方法１
データ転送速度管理の方法１は、ＴＣＦトレーニング信号が受信ゲートウェイによってローカルに生成されることを要求する。データ転送速度管理は、双方のＰＳＴＮ接続のトレーニング結果をもとに送信ゲート
ウェイによって行われる。

方法１はＴＣＰ実装のために使われ、ＵＤＰ実装についてはオプションである。

ＣＦＲ（受信準備確認）あるいはＦＴＴ（トレーニング失敗）が受信ゲートウェイでＧ３ＦＥから受信されたとき、ＪＴ－Ｔ３０ＨＤＬＣ パケット（それぞれＣＦＲあるいはＦＴＴを示している）は送信ゲート
ウェイに送られるべきである。

Ｇ３ＦＥから受信したＴＣＦの結果とＪＴ－Ｔ３０ＨＤＬＣ パケット（ＣＦＲあるいはＦＴＴ）が受信
ゲートウェイから送られるに従って、送信ゲートウェイは表６／ＪＴ－Ｔ３８に従ってＦＴＴあるいはＣＦＲを送信しなければならない。

表６／ＪＴ－Ｔ３８－送信ゲートウェイの信号速度決定テーブル（ＩＴＵ－Ｔ

Ｔ．３８）

受信ゲートウェイから送ら送信ゲートウェイで G3FE から

G3FE(送信端末)に転送される信れてくるＪＴ－Ｔ３０信号受信される TCF 信号

号

CFR

Success

CFR

FTT

Success

FTT

CFR

FailureFTT

FTT

Failure

FTT

メッセージ

送信装置がインターネット対応ファクシミリ装置であり送信ゲートウェイがない場合では、インターネット
対応ファクシミリ装置は受信ゲートウェイからのＦＴＴに対して適切なＤＣＳを使って応答すべきである。
このＤＣＳには、変調変更も含まれるかも知れない。
受信装置がインターネット対応ファクシミリ装置であり受信ゲートウェイがない場合では、インターネット
対応ファクシミリ装置は送信ゲートウェイからのＤＣＳに対してＣＦＲで応答すべきである。しかし、送信- 27 -

ＪＴ－Ｔ３８

ゲートウェイがＦＴＴを生成する場合に備えて、受信装置はＤＣＳの受信準備をすべきである。
送信装置と受信装置がインターネット対応ファクシミリ装置の場合は、送信装置はデータ信号速度のビット列が０にセットされたＤＣＳを送るべきであり、受信装置はＣＦＲで応答すべきである。ＩＰネットワーク
を介したデータレートは Call-setup において確立される。

8.2 データ転送速度管理方法２
データ転送速度管理方法２は、ローカルに受信ゲートウェイがＴＣＦを送信するよりむしろＴＣＦが送信
Ｇ３ＦＥから受信Ｇ３ＦＥに送信されることを要求する。速度選択は、通常のＰＳＴＮ接続と同様にＧ３Ｆ
Ｅ同志によって同一の方法で行われる。

送信装置がインターネット対応ファクシミリ装置であり送信ゲートウェイがない場合では、インターネット
対応ファクシミリ装置は受信ゲートウェイからのＦＴＴに対して適切なＤＣＳ＋ＴＣＦを使って応答しなければならない。このＤＣＳには、変調変更も含まれるかも知れない。
受信装置がインターネット対応ファクシミリ装置で、受信ゲートウェイがない場合には、インターネット対
応ファクシミリ装置は送信ゲートウェイからのＤＣＳに対して、受信されたＴＣＦ信号に従いＣＦＲまたはＦＴＴで応答しなければならない。
送信装置と受信装置がインターネット対応ファクシミリ装置の場合は、送信装置は変調方式のビット列が０にセットされたＤＣＳを送るべきであり、受信装置はＣＦＲで応答すべきである。ＩＰネットワークを介したデータレートは Call-setup において確立される。

データ転送速度管理方法２はＵＤＰを使用する場合には必須だが、ＴＣＰを使用する場合またはＤＩＳ／
ＤＣＳ交換によって両方のＧ３ＦＥ装置がインターネット対応ファクシミリ装置と判断された場合には推奨されない。

- 28 -

ＪＴ－Ｔ３８

９．ＵＤＰトランスポート上でのＩＦＴ：ＩＦＴ／ＵＤＰ
9.1 ＵＤＰＴＬを使ったＵＤＰトランスポート上のＩＦＴ：ＩＦＴ／ＵＤＰＴＬ／ＵＤＰ
9.1.1 ＵＤＰＴＬプロトコルの概要
以下のパケットは７．１．３節で公開されている全体的な構造を含んだ情報のブロックと見なされる。
図５／ＪＴ－Ｔ３８のａ）の階層モデルは、ＩＦＰペイロードを加えたヘッダーの複合物であるパケットを許容すれば同一の層としていっそう簡単に視覚化されるかもしれない［図５／ＪＴ－Ｔ３８のｂ）］。
それはゲートウェイの間にファクシミリ関連の情報を送るために使われるＩＦＰペイロードである；すべての他の情報が７章で記述したように安全な転送とＩＦＰメッセージの解釈に必要なオーバーヘッドと見なされるべきである。 本節はＵＤＰＴＬペイロードを記述する。ＩＰとＵＤＰヘッダーとペイロードに関す
る記述は、それぞれＲＦＣの７９１と７６８にある。
ＵＤＰＴＬパケットは、シーケンスナンバと可変な長さ、オクテット整合、ペイロードからなる。
ＵＤＰＴＬパケットはフレームの原理を基本としている。 それぞれのパケットがそのペイロードセクショ
ンで１あるいはそれ以上のＩＦＰパケットを含んでよい。

どのペイロードにおいても最初のパケットは、

常に７章の仕様に従いフォーマット化され、ヘッダーに与えられたシーケンスナンバに一致していなければならない。
（例えば、シーケンスナンバ１５でペイロード中の最初のフィールドはシーケンスナンバ１０のペイロード中の最初のフィールドより５つのペイロードが生成されていなければならない。）
ＵＤＰＴＬペイロードでのＩＦＰパケットは「プライマリ」と言われる。追加フィールドはプライマリの後のペイロードに含まれる可能性がある。これらのフィールドは「セカンダリ」と言われ、それらの形式に依存した７章の仕様ごとに形式化されても良い。

9.1.2 ＵＤＰＴＬヘッダセクションフォーマット
ＵＤＰＴＬシーケンスナンバはペイロードで順序付けを識別するために使われる。

9.1.2.1 ＵＤＰＴＬシーケンスナンバ要素
それぞれのパケットさもなければプライマリフィールドは、受信ゲートウェイで指示された仕様であるユ
ニークなシーケンスナンバと一致する。
いくつかのパケットの受信を同期させるようゲートウェイを有効にするために、転送される最初のプライマ
リフィールドはシーケンスナンバが０としなければならない。
正常なプライマリはシーケンスナンバ（隣接した整数）を線形的に増やして行かなければならない。

9.1.3 ＵＤＰＴＬペイロードセクションフォーマット
ＪＴ－Ｈ３２３の能力交換の間、ゲートウェイは利用可能なエラープロテクション機構、パリティＦＥＣ 、または冗長のサポートを示さなければならない。 これらの能力に基づいて、エラープロテクションとして使用される機構が選択されるかもしれない。もし能力がパリティエラー訂正フレームと冗長フレームの両方の受信を示されていたならば、いずれの機構が使われてもかまわない。もし、ゲートウェイが冗長エラー保護フレームだけを受信する能力を示しているなら、送信ゲートウェイはパリティＦＥＣフレームを送らないかもしれない。パリティＦＥＣのサポートは任意である；パリティＦＥＣ受信サービスを提供するゲート
ウェイは、冗長なメッセージを受け取ることができるべきである。ゲートウェイは、エラー訂正メッセージを送信しないことを選択することができる。
ＩＦＰペイロードセクションは１つあるいはそれ以上のフィールドを含む。ＵＤＰＴＬペイロードの基本的なフォーマットは図７／ＪＴ－Ｔ３８に示される。

- 29 -

ＪＴ－Ｔ３８図７／ＪＴ－Ｔ３８は異なったメッセージがＵＤＰＴＬペイロードへ組み立てられる順序を指定する。 同
じパケットの中で冗長とＦＥＣフィールドの両方を送信するのは無効である。

ｵﾌﾟｼｮﾅﾙﾘﾀﾞﾝﾀﾞﾝﾄ
ﾒｯｾｰｼﾞ
ｼｰｹﾝｽ
ﾅﾝﾊﾞ

ｵﾌﾟｼｮﾅﾙﾘﾀﾞﾝﾀﾞﾝﾄ
ﾒｯｾｰｼﾞ

ﾏﾝﾀﾞﾄﾘﾒｯｾｰｼﾞ(ﾌﾟﾗｲﾏﾘ)またはnﾊﾟｹｯﾄ…
ｵﾌﾟｼｮﾅﾙFEC
ﾒｯｾｰｼﾞ

または
ｵﾌﾟｼｮﾅﾙFECﾒｯｾｰｼﾞ

図７／ＪＴ－Ｔ３８ ＵＤＰＴＬペイロードセクションの基本フォーマット（ＵＤＰヘッダーを示していない）（ＩＴＵ－Ｔ Ｔ．３８）

9.1.3.1 ＵＤＰＴＬ

ＦＥＣメッセージフォーマット

ＦＥＣはプライマリの数のパリティをコード化された表示を含む。ＦＥＣフィールドによって表示された
プライマリＩＦＰパケットの数はＵＤＰＴＬパケットのＦＥＣｎ

パケットの要素によって与えられる。

9.1.4 ＩＦＰ／ＵＤＰファクシミリデータ転送機能
9.1.4.1 冗長メッセージの使用
各々のプライマリがＩＦＰパケットを含んでいる。そのためプライマリは、パケットとしてユニークなそ
して線形的に増加する連続数を割り当てられ、受信ゲートウェイはパケットの損失と再順序付けの要求を検出することができる。単純な構造を課すことによって、それぞれペイロードの中で事前にプライマリパケッ
ト形式で冗長な情報を伝達する手段によってエラーリカバリを提供することが可能となる。使用される手段
は単調に減少する連続数でプライマリの後に付加的なｎ個の事前のパケットを組み立てる。このように、もしそれぞれのペイロードがプライマリと２つまたはそれ以上のセカンダリフィールドを含んでいるのなら、２つの連続したＵＤＰＴＬパケットの損失を保護されるであろう。ＵＤＰＴＬで冗長性サービスを提供するために、新しいパケットの中に組み立てられた「古い」プライマリのバッファを保持することが必要となる。
このような例として冗長性の転送の原則を明示するためにバッファのイラストを図８／ＪＴ－Ｔ３８に示す。

- 30 -

ＪＴ－Ｔ３８

ｼｰｹﾝｽﾅﾝﾊﾞ
(45)
ｼｰｹﾝｽ
45

IFPﾒｯｾｰｼﾞ

44

IFPﾒｯｾｰｼﾞ

43

IFPﾒｯｾｰｼﾞ

42

IFPﾒｯｾｰｼﾞ

41

IFPﾒｯｾｰｼﾞ

ﾌﾟﾗｲﾏﾘﾒｯｾｰｼﾞ

ﾘﾀﾞﾝﾀﾞﾝｼ
ﾒｯｾｰｼﾞ1

ﾘﾀﾞﾝﾀﾞﾝｼ
ﾒｯｾｰｼﾞn

IFPﾒｯｾｰｼﾞｽﾄｱ

図８／ＪＴ－Ｔ３８ ＵＤＰＴＬパケットの中に含まれるＰｒｉｏｒ(secondary)ＩＦＰパケット(Field)（ＩＴＵ－Ｔ Ｔ．３８）

ＵＤＰＴＬスキームのシーケンス番号が連続している冗長なＩＦＰパケットのブロックを伝達することができるだけであることに注意しなさい。このように、もし現在のＩＦＰパケットがシーケンス番号Ｃを持って、そしてＵＤＰＴＬパケットシーケンス番号Ｃ－２から冗長的にＩＦＰパケットを伝達することが望まれるなら、ＵＤＰＴＬパケットは与えられた順にＣ、Ｃ－１、Ｃ－２からすべてのＩＦＰパケットを含まなくてはならない。ゲートウェイは冗長なパケットを伝達する必要がない。受信ゲートウェイは、それらを無視しても良い。

9.2 ＲＴＰを使ったＵＤＰトランスポート上のＩＦＴ：ＩＦＴ／ＲＴＰ／ＵＤＰ
ＵＤＰトランスポートの場合、ＵＤＰＴＬの代わりにＲＴＰ（ＲＦＣ３５５０）を使用することができる。
ＲＴＰは、両方のゲートウェイが呼設定の間にこの能力交換をするときに使われる。この能力交換は、付属
資料ＢおよびＤで記述される。これらが両方のゲートウェイによって能力交換される限り、ＲＴＰのストリームにとって利用可能な付加的な能力がオプションとして使われても良い。 これらは冗長性（ＲＦＣ２
１９８）およびＦＥＣ（ＲＦＣ５１０９）を含む。
ＵＤＰＴＬの代わりにＲＴＰを使うとき、考慮しなければならない幾つかの相違点がある。これらの相違
点は、ＲＴＰとＵＤＰＴＬのための操作手続きとペイロードフォーマットの違いに起因する。これらのフォーマット間の類似性に沿って、相違点を表７／ＪＴ－Ｔ３８に示す。

- 31 -

ＪＴ－Ｔ３８表７／ＪＴ－Ｔ３８

ＲＴＰとＵＤＰＴＬ間の類似性と相違点（ＩＴＵ－Ｔ機能
ペイロードフォーマット

Ｔ．３８）

UDPTL機構

RTP機構

ＵＤＰＴＬパケットは、付属資料Ａに定義される。

冗長性とＦＥＣを持たないＲＴＰペイ
ロードは、一つのＩＦＰパケットである。
ＦＥＣパケットが個々のストリーム（ＲＦＣ５１０９）を構成するとき、ＲＴＰペイ
ロードは一つのＩＦＰパケットである。
ＲＦＣ２１９８ベースの冗長性を持った
ＲＴＰペイロードは、ＲＦＣ２１９８で定義される。
ＲＦＣ２１９８のカプセル化を使ったＦ
ＥＣを持ったＲＴＰペイロード構造は、Ｒ
ＦＣ５１０９およびＲＦＣ２１９８に定義される。

ＲＴＰまたはＵＤＰＴＬプ
ロトコルを使うために必要な能力交換。

これが使われるために、ＵＤＰ
ＴＬベースのＪＴ－Ｔ３８能力
は１つのゲートウェイによって要求されて、そして他のゲートウェイによって選択または受諾されなくてはならない。能力宣言と能力交換手順はそれぞれ付
属資料Ｂ、ＤおよびＥまたはＪ
Ｔ－Ｈ３２３の付属資料Ｄに定義される。

これが使われるために、ＲＴＰベースのＪ
Ｔ－Ｔ３８能力は１つのゲートウェイによって要求され、そして他のゲートウェイ
によって選択または受領されなくてはならない。 能力宣言と能力交換手順は付属
資料Ｂ、ＤおよびＥまたはＪＴ－Ｈ３２３の付属資料Ｄに定義される。

ペイロードシーケンス

ＵＤＰＴＬシーケンス番号

ＲＴＰシーケンス番号

冗長性

９章で定義されたメカニズムを使う。

ＲＦＣ２１９８で定義される。

ＦＥＣ

使用機構は、付属資料Cに定義される。

ＲＦＣ２１９８カプセル化の有無にかか
わらずＲＦＣ５１０９で定義される。

それぞれのＲＴＰパケットが固定のＲＴＰヘッダーから始まる。ＲＴＰパケットがファクシミリをカプセ
ル化するとき、ＲＴＰの固定ヘッダーのペイロードの特定のフィールドに下記を記述する：（１）ペイロードタイプ（ＰＴ）：ファクシミリのためのペイロードタイプは、名前“t38”によって識別されるダイナミックなペイロードタイプである。 もし冗長性が ＲＦＣ２１９８によって使われるなら、ペイロードタイプは（ＲＦＣ２１９８に従って）ＲＥＤペイロードフォーマットを示さなくてはならない。
（２）マーカ（M）ビット：マーカビットはファクシミリのために使われず、そしてゼロに設定されなくてはならない。 マーカビットはパケットの受信側によって無視されるべきである。

- 32 -

ＪＴ－Ｔ３８

１０．Ｖ．８信号とＪＴ－Ｔ３０付属資料Ｅ／Ｖ．３４ファクシミリのためのメッセージフロー
10.1 Ｖ．８能力交換
Ｖ．８がファクシミリとモデム装置の能力交換手段として用いられる。これは変調と装置によってサポートされたアプリケーションを含む。能力交換手順の間にＡＮＳａｍ、ＣＩ、ＣＭ、ＪＭとＣＪ信号が発信Ｇ
３ＦＥと着信Ｇ３ＦＥ間で交換される。ＣＭとＪＭ信号はアプリケーションまたは能力が一致するかを完全に確認する為にエンドツーエンドで強制される。ＪＴ－Ｔ３８参照構成において、ＣＭ情報は発信Ｇ３ＦＥ
から送信ゲートウェイを経由して受信ゲートウェイに転送され、受信ゲートウェイは適切に（修正する可能性もある）ＣＭ情報を使い受信Ｇ３ＦＥに転送する。受信Ｇ３ＦＥは応答で、受信ゲートウェイにＪＭ信号を送信する。受信ゲートウェイは情報（必要なら、それを修正する）を送信ゲートウェイに順番に渡し、発信Ｇ３ＦＥ にそれを転送する。一旦、送信ゲートウェイがＪＭ情報を持つと、それは接続能力の全ての情報を持ったことになる。
呼の開始において、ＡＮＳａｍ 信号はＶ．３４ファクシミリとＶ．８ベースのモデムの両方のためにＶ．
８交換を始める。マルチモードゲートウェイでの呼の開始が、Ｖ．８ベースのモデムとＶ．３４Ｇ３ＦＥを含めて、付属資料Ｆで記述される。
この節は、ファクシミリ単機能のゲートウェイにおける呼の開始のためのＡＮＳａｍとＶ．８交換の取り扱いを記述し、同様に、Ｖ．３４ターンアラウンドポーリングのサポート（１０．３．５節参照）および手動モードでＶ．３４の再スタート（１０．３．６節参照）を記述する。
ＡＮＳａｍは受信ゲートウェイによって検出され、送信ゲートウェイによって生成されなければならない。
ＡＮＳａｍが受信ゲートウェイによって検出されたとき、もし送信ゲートウェイがＶ．３４能力を持っていれば、t30-indicator の v8-ansam を使って報告されなければならない。もし送信ゲートウェイがＶ．３４能力をもっていなければ、受信ゲートウェイはＡＮＳａｍを t30-indicator の ced を使って報告しなければならない。
送信ゲートウェイによって生成されたＡＮＳａｍの応答においてタイムアウトが発生した場合、ＤＩＳ
メッセージのＶ．８ ビット（最初のオクテットのビット６）をリセットしたＶ．２１応答を生じて、いずれかのゲートウェイがＶ．８能力交換へ戻る可能性を止めることを選択するかもしれない。
送信ゲートウェイが２つの同一/連続したＣＭ信号を検出したとき、および呼機能カテゴリオクテットがファクシミリ機能を含んでいることを確かめたとき、送信ゲートウェイはファクシミリアプリケーションプ
ロファイル（ＦＡＰ）を受信ゲートウェイに報告しなければならない。もし呼機能が有効なファクシミリ値
でないなら、サポートされない呼タイプとして、呼は終了しても良い。プロファイルは、受信Ｇ３ＦＥに送信するために再構築された、cm-message data Field-Type を使って受信ゲートウェイに送信される。
ファクシミリアプリケーションプロファイルは、ベースプロファイル数を含んでいる。 ベースプロファイ
ルは呼の機能の中身と V.8 ＣＭ信号の変調モードを表す。６つの可能な正当なファクシミリプロファイルを
表８／ＪＴ－Ｔ３８に示す。

- 33 -

ＪＴ－Ｔ３８表８／ＪＴ－Ｔ３８

ファクシミリプロファイル（ＩＴＵ－Ｔ種類

Ｔ．３８）

Ｖ．８識別コードポイント

G3ファクシミリ端末：（送信
ファクシミリ）Call Function = 4

G3ファクシミリ端末：（受信ファクシミリ）Call Function = 5

変調方式 = V.17, V.29, V.27 ter, V.21
変調方式 = V.17, V.29, V.27 ter, V.21

プロ
ファ
イル
番号
1

2

V.34 半二重および G3ファクシ Call Function = 4
ミリ端末：（送信ファクシミリ） 変調方式 = V.34 半二重, V.17, V.29, V.27 ter, V.21

3

V.34 半二重および G3ファクシ Call Function = 5
ミリ端末：（受信ファクシミリ） 変調方式 = V.34 半二重, V.17, V.29, V.27 ter, V.21

4

V.34 半二重だけのファクシミ Call Function = 4
リ端末：（送信ファクシミリ） 変調方式 = V.34 半二重のみ

5

V.34 半二重だけのファクシミ Call Function = 5
リ端末：（受信ファクシミリ） 変調方式 = V.34 半二重のみ

6受信ゲートウェイが２つの同一／連続したＪＭ信号を受信し、そして送信ゲートウェイによって求められているプロファイルが宛先端末によって受け入れ可能と決定したとき、受信ゲートウェイは肯定応答（ＡＣＫ）を送信しなければならない。受信ゲートウェイは、もしプロファイルが受け入れ可能でない場合は、送信ゲートウェイに否定応答（ＮＡＫ）を送信しなければならない。ＮＡＫの値は、JM 応答に依存する。 表
９／ＪＴ－Ｔ３８参照。

表９／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

ＮＡＫの説明Ｔ．３８）

NAK(0)

互換性モードが使用できない

NAK(1)

V.34ファクシミリでなく、Ｇ３ファクシミリである。
プロファイル１または２を用いて応答。

NAK(2)

V.34ファクシミリのみ。
プロファイル５または６を用いて応答。

上記の V.8 信号の完成において、送信および受信ゲートウェイは jm-message 応答によって明示的に表示された適切な変調方式を続けなければならない。

- 34 -

ＪＴ－Ｔ３８

10.2 Ｖ．３４データレート管理
Ｖ．３４の１２章で記述されるように、２つのゲートウェイは独立してＶ．３４半二重手順の第２フェー
ズそして第３フェーズを続けなければならない。
発呼端末（発信Ｇ３ＦＥ）から応答端末（受信Ｇ３ＦＥ）送信されるデータのオーバーフローを防止するために、発信Ｇ３ＦＥ／送信ゲートウェイの端末－ゲートウェイペアのプライマリチャネルデータシグナリ
ングレートは、受信ゲートウェイ／受信Ｇ３ＦＥ端末－ゲートウェイペアのプライマリチャネルデータシグ
ナリングレートと同じかそれ以下としなければならない。プリファレンスは、レートが等しく、かつ最も速い互換性のあるレートが選択されることを保証する。発信Ｇ３ＦＥ／送信ゲートウェイのレートが受信ゲー
トウェイ／受信Ｇ３ＦＥのレートより小さい、そして受信Ｇ３ＦＥ端末に送信しているよりも遅いレートでデータが到来する場合は、ギャップはフレーム間の ＨＤＬＣフラグで満たしても良い。データシグナリン
グレート非互換の唯一の可能性は、２４００ｂｉｔ／ｓのデータレートを認めない受信ゲートウェイによって避けることができることに注意。一旦、ＪＴ－Ｔ３０セッションが開始されると、データレートの変更は
これらの要求を維持するように管理されなければならない。

10.2.1 コントロールチャネルの開始
コントロールチャネルの再トレーニングによってプライマリチャネルデータレートの変更が要求されないなら、コントロールチャネルの開始は、プライマリチャネルのトレーニングの後、またはプライマリチャ
ネルの送信データ（ＪＴ－Ｔ３０フェーズＣ）の後に開始される。
コントロールチャンネルレートは１２００ｂｉｔ／ｓでなければならない。２４００ｂｉｔ／ｓコント
ロールチャンネルレートに対するサポートは今後の課題である。
データレートは、コントロールチャネルの開始またはＶ．３４半二重手順のコントロールチャネル再ト
レーニングにおいて能力交換されなければならない。送信ゲートウェイは、双方のＧ３ＦＥのプライマリ
チャネルのデータレートを正しく選択するための責任を持たねばならない。両端にある端末を同じシンボル
レートに限定する必要はない。送信ゲートウェイは一度トレーニングアップされると、v34-pri-rate メッセー
ジによってそれが受信ゲートウェイ／受信Ｇ３ＦＥペアのプライマリチャネルシグナリングレートを受信するまで、コントロールチャネルでＨＤＬＣフラグを交換しなければならない。一度送信ゲートウェイが、自身の能力交換されたデータレートと受信ゲートウェイ／受信Ｇ３ＦＥペアにより選択されたデータレー
ト両方の情報を持つと、送信ゲートウェイは、変更されたＭＰｈを持ったコントロールチャネルの再トレー
ニングによって自身と発信Ｇ３ＦＥ間のプライマリチャネルレートを変えなくてはならないかどうかを決定しなければならない。ローカルレートパラメータは、受信Ｇ３ＦＥ値未満もしくは（より好ましくは）同じ値にセットなければならない。一度レート選択基準が満たされると、受信ゲートウェイと送信ゲートウェ
イは通常のＪＴ－Ｔ３０のＤＩＳ、ＤＣＳ信号などを渡すことができる。もし、送信ゲートウェイと発信Ｇ
３ＦＥ間でのコントロールチャネルの再トレーニング中にＤＩＳのようなＪＴ－Ｔ３０メッセージを受信
ゲートウェイから受信すると、レート選択と能力交換手順が完了するまで、送信ゲートウェイは来たメッ
セージをバッファし、ＪＴ－Ｔ３０メッセージの送信を遅延させなければならない。一度完了すると、ＤＩ
Ｓなどが送信ゲートウェイから発信Ｇ３ＦＥに送信することができる。

10.2.2 コントロールチャネルの再トレーニング
一度、ＪＴ－Ｔ３０セッションが確立されると（すなわちＪＴ－Ｔ３０フェーズＢがＤＩＳの交換で始まった後）、プライマリチャネルデータレートはコントロールチャネルの再トレーニングによってページ間または部分ページ間で変えることができる。送信Ｇ３ＦＥまたは受信Ｇ３ＦＥは、AC を送ることによってデー
タレートの変更を始めることができる。双方のＧ３ＦＥからのコントロールチャネルの再トレーニングは、- 35 -

ＪＴ－Ｔ３８

v34-CC-retrain インジケータを使って表示される。ゲートウェイは、このインジケータの応答において適切なときに再トレーニングを開始しても良い。再トレーニングシーケンスは、ゲートウェイとＧ３ＦＥ間でＭＰ
ｈ交換の原因となり、結果としてプライマリチャネルの新しいデータ信号レートになる。
プライマリチャネルデータレートを変える動作に於いて、コントロールチャネル再トレーニングが発生する
ときには、１０．２節で定義されるように、データオーバーフローを防止すべき必要条件は維持されなければならない。
発信Ｇ３ＦＥまたは受信Ｇ３ＦＥは、考慮に入れるべき２つの主なケースにおいて、データレート変更要求
を始めてもよい。それぞれの場合で、そのレートは増加または減少するかもしれない。それぞれの場合のふるまいは下に定義される。
（１）発信Ｇ３ＦＥによって再トレーニングが開始された場合。
この場合、送信ゲートウェイから受信ゲートウェイに信号は送られない。
（ａ）発信Ｇ３ＦＥがレートの増加を求める。
もし、レート要求が結果として受信ゲートウェイと受信Ｇ３ＦＥ間のレートよりも発信Ｇ３ＦＥのレートが高くなるようであれば、送信ゲートウェイはレートの増加を許可してはならない、そうでなければそれは許可しても良い。
（ｂ）発信Ｇ３ＦＥがレートの減少を求める。
送信ゲートウェイは、要求されたとしてレートを変えてもよい。
（２）受信Ｇ３ＦＥによって再トレーニングが開始された場合。
この場合、受信ゲートウェイは、v34-pri-rate メッセージに続いて選択される新しいデータレートで
v34-CC-retrain インジケータを送らなければならない。
（ａ）受信Ｇ３ＦＥがレートの増加を求める。
受信ゲートウェイは、要求されたとしてレートを変えても良い。送信ゲートウェイは適切な時に送信Ｇ３ＦＥと共にコントロールチャネルの再トレーニングを開始しても良い。さらに、もし受信Ｇ
３ＦＥの新しいレートより低いか等しい場合は、発信Ｇ３ＦＥのデータレートを増加しても良い。
（ｂ）受信Ｇ３ＦＥがレートの減少を求める。
受信ゲートウェイは、要求されたとしてレートを変えても良い。もし v34-pri-rate メッセージによって示された新しいレートが発信Ｇ３ＦＥレートより小さければ、送信ゲートウェイは適切な時に送信Ｇ３ＦＥと共にコントロールチャネルの再トレーニングを開始しなければならず、受信Ｇ３ＦＥの新しいレートより小さ
いか等しくなるように、発信Ｇ３ＦＥプライマリチャネルデータレートを減少させなければならない。
コントロールチャネルの再トレーニングは、コントロールチャネルがアクティブのときはいつでも始めてよいことに注意。送信ゲートウェイが要求された再トレーニングの開始のために適切な時は、ポストページ
メッセージ交換の後であり、プライマリチャネルの始動の前ではない。

- 36 -

ＪＴ－Ｔ３８

10.3 ファクシミリモード
10.3.1 コントロールチャネル
コントロールチャネルのデータ交換は、ＭＰｈ交換が完了し、コントロールチャネル速度とプライマリ
チャネル速度が合意されてから開始される（付図Ⅳ．２参照）。
コントロールチャネルは、非Ｖ．３４ファクシミリモードとは違い全二重チャネルで、（非Ｖ．３４モードの無信号と比較して）データの存在しないときにはフラグ送出する。コントロールチャネル動作中に必要なフラグを生成することは、ゲートウェイまたはＩＡＦの責任である。
コントロールチャネルパケットは、hdlc-xxx フィールドタイプの値を持つ t30-data 値の変調を示す
v34-CC-1200 を使用して送信される。
hdlc-xxx-sig-end フィールドタイプはＨＤＬＣメッセージの終わりを示す。非Ｖ．３４動作の無信号の代わりにこの信号の後で、フラグは送信されなければならない。

10.3.2 コントロールチャネルからプライマリチャネルへの切り替え
ソース端末はコントロールチャネルを遮断する意思を示し、受信端末がフラグの送信を止めるまで少なく
とも４０個の連続した１を送信することでプライマリチャネルに切り替える。
送信ゲートウェイは、v34-primary-channel indicator を送信することでプライマリチャネルへの遷移が準備できたことを、受信ゲートウェイかＩＡＦに通知しなければならない。

10.3.3 プライマリチャネル
ＪＴ－Ｔ３０の付属資料Ｅは、ＥＣＭで画像データを送信することを要求している。これは、
v34-primary-channel データ値と hdlc-xxx のフィールドタイプを使用したパケットでプライマリチャネル
データが送信されなければならないことを意味する。
発信Ｇ３ＦＥ／送信ゲートウェイのプライマリレートが受信ゲートウェイ／受信Ｇ３ＦＥの速度より遅い場合は、受信Ｇ３ＦＥに送信するよりデータが遅い速度で到着することを引き起こし、ＨＤＬＣフラグはフレーム間を埋めるために使用されなければならない。

10.3.4 プライマリチャネルからコントロールチャネルへの切り替え
送信ゲートウェイは、プライマリチャネルのターンオフシーケンスが完了した後に、
v34-control-channel-1200 indicator を送信しなければならない。v34-control-channel-1200 indicator を受信した
ら、受信ゲートウェイは着信Ｇ３ＦＥとの間でプライマリチャネルのターンオフを開始しなければならない。
プライマリチャネルのビットレートの変更を望まないなら、１０．３．１節に従いコントロールチャネルを開始する。プライマリチャネルのビットレートの変更を望むなら、v34-control channel t30-indicator 無しに
１０．２．２節に従い v34-CC-retrain t30-indicator が送信される。

10.3.5 ターンアラウンドポーリングモード
ターンアラウンドポーリングは、ＤＴＣコマンドとＣＭによるＶ．８交換(ＡＮＳａｍは使用されない)を開始した後に、コントロールチャネルの遮断によって成し遂げられる（付図Ⅳ．９参照）。ソース端末(発信Ｇ３ＦＥ)は、ＤＴＣの送出でターンアラウンドポーリングをする意思を示し、連続した１を検知するまでフ
ラグを送出する。連続した１を検知したら、ソース端末は７０ｍｓ間無音としＣＭを開始する。受信端末は、コントロールチャネルを遮断する意思を示し、ソース端末がフラグ送出を止めることを検知するまで、少な
くとも４０個の連続した１を送信してＶ．８交換に切り替える。
ターンアラウンドポーリングは、下記に示すように発信Ｇ３ＦＥと受信Ｇ３ＦＥで提供されなければなら- 37 -

ＪＴ－Ｔ３８

ない。
受信ゲートウェイは、ＪＴ－Ｔ３０ＤＴＣ信号を検知しなければならない。ＤＴＣを受信した後、受信ゲー
トウェイは受信Ｇ３ＦＥから連続した１を検知することを準備しなければならない。連続した１の検知で送信ゲートウェイに v8 indicator を送信しなければならない。
受信ゲートウェイから v8 indicator を受信した後、Ｇ３ＦＥがフラグ送出を止めるまで、送信ゲートウェ
イは送信Ｇ３ＦＥに連続した１を送信しなければならない。送信ゲートウェイはコントロールチャネルを遮断し、送信Ｇ３ＦＥからＣＭメッセージの受信を準備する。ＣＭメッセージの受信で、受信ゲートウェイに
cm-message を使ってファクシミリアプリケーションプロファイル（ＦＡＰ）を転送しなければならない。
受信Ｇ３ＦＥからのコントロールチャネルの遮断を検知した受信ゲートウェイは、ファクシミリアプリ
ケーションプロファイルを受信するまで無音に移行しなければならない。プロファイルの受信で、受信Ｇ３ＦＥに適切なＣＭを送信しなければならない。
送信ゲートウェイは１０．１節に記載されたように送信Ｇ３ＦＥから２つの一致するＪＭ信号を受信してから受信ゲートウェイに(ACK か NACK)を送信しなければならない。.送信ゲートウェイと受信ゲートウェイの切替えのふるまいを除いて、動作は標準Ｖ．８ネゴシエーションに等しい。

10.3.6 ＪＴ－Ｔ３０付属資料Ｅ（Ｖ．３４動作）への手動での開始
受信Ｇ３ＦＥからのビット６が１にセットされたＤＩＳに、発信Ｇ３ＦＥが ＣＩで応答することにより、Ｖ．３４通信を手動で開始できる（付図Ⅳ．１０参照）。受信Ｇ３ＦＥは、１０．１節に記載された標準Ｖ．
８シーケンスを開始するように、ＣＩに対してＡＮＳａｍで応答する。
手動での開始を提供するために送信ゲートウェイは、非Ｖ．３４モードでＤＩＳ送出の後にＣＩ検知を対応しなければならない。ＤＩＳの応答でＣＩが受信されたならば、送信ゲートウェイは受信ゲートウェイへ
ci-message を送信することと、応答として V.8ANSam 信号を受信する準備をしなければならない。
非Ｖ．３４モードで動作している受信ゲートウェイで ci-message を受信したとき、受信Ｇ３ＦＥにＣＩ信号を再生することと、ＡＮＳａｍの受信準備をしなければならない。

10.3.7 切断
呼の終了時、ゲートウェイは宛先ゲートウェイに対して hdlc-xxx-sig-end か no-sig indicator でコントロール
チャネルの終わりを表示しなければならない。

- 38 -

ＪＴ－Ｔ３８

10.4 本標準の以前の版との機器適合についての互換性
ＪＴ－Ｔ３８（ＡＳＮ．１バージョン０、１、２）の以前の版に適合したＪＴ－Ｔ３８機器は、Ｖ．３４能力を可能とするために追加したメッセージを解釈できない。これは、ゲートウェイが呼設定交換の間は、Ｊ
Ｔ－Ｔ３８のどの版がサポートされているかを含んだそれぞれの能力を注意すべきなので、一般には問題は生じない（付属資料Ｂ、Ｄ及びＥの例を参照）。下表に可能な組合せと互換性の結果を示す。

送信ゲートウェイ Ｖ．

受信ゲートウェイ Ｖ．３

コメント

３４半二重 能力

４ 半二重 能力

無し

無し

標準Ｔ３８

無し

有り

標準Ｔ３８にフォールバック有り

無し

標準Ｔ３８にフォールバック有り

有り

Ｖ．３４ 半二重 ＪＴ－T３８手順を使用する

非Ｖ．３４（Ｖ．８）ファクシミリ機器はＡＮＳａｍ信号の振幅変調か位相反転を認知できず、ＣＥＤのような信号として扱う。本標準の以前の版に適合しているＪＴ－Ｔ３８機器は T30_INDICATOR V.8 ANSam
信号を理解することができない。
ＪＴ－Ｔ３８の本版に適合したＪＴ－Ｔ３８機器は、本標準の以前の版に適合した他の機器に対しては、
本標準の以前の版で定義された信号だけを送信しなければならない。
T30_INDICATOR V.8 ANSam 信号を検知したＪＴ－Ｔ３８機器は、バージョン０、１、２能力を表示したＪ
Ｔ－Ｔ３８機器に送信する前に、この信号を T30_INDICATOR CED 信号に対応させなければならない。ＪＴ－Ｔ３８のバージョン３に適合したゲートウェイは、バージョン０、１、２のＪＴ－Ｔ３８機器との相互接
続では、Ｖ．８能力を通知しないか外部のファクシミリ機器とＶ．８手順で応答しないかもしれない。

１１．セキュリティの考慮
歴史的な観点からのセキュリティの考慮事項については、付録Ⅵを参照。

- 39 -

ＪＴ－Ｔ３８

付属資料

Ａ（ＪＴ－Ｔ３８に対する）
抽象構文記法１（ＡＳＮ．１）（この付属資料は、本標準の必須部分を形成する）

A.1

ＪＴ－Ｔ３８(第３．１版)抽象構文記法１（ＡＳＮ．１）

T38 DEFINITIONS AUTOMATIC TAGS ::=BEGIN
IFPPacket ::= SEQUENCE{
type-of-msg
data-field}

Type-of-msg,
Data-Field OPTIONAL

Type-of-msg ::= CHOICE{
t30-indicator ENUMERATED{
no-signal,
cng,
ced,
v21-preamble,
v27-2400-training,v27-4800-training,v29-7200-training,v29-9600-training,v17-7200-short-training,v17-7200-long-training,v17-9600-short-training,v17-9600-long-training,v17-12000-short-training,v17-12000-long-training,v17-14400-short-training,v17-14400-long-training,…
v8-ansam,v8-signal,
v34-cntl-channel-1200,
v34-pri-channel,
v34-CC-retrain,
v33-12000-training,v33-14400-training},
t30-data ENUMERATED{
v21,
v27-2400,v27-4800,v29-7200,v29-9600,v17-7200,v17-9600,v17-12000,
v17-14400,…,
v8,v34-pri-rate,
v34-CC-1200,
v34-pri-ch,v33-12000,
v33-14400}- 40 -

ＪＴ－Ｔ３８}
Data-Field ::= SEQUENCE OF SEQUENCE{
field-type ENUMERATED{
hdlc-data,hdlc-sig-end,
hdlc-fcs-OK,
hdlc-fcs-BAD,
hdlc-fcs-OK-sig-end,
hdlc-fcs-BAD-sig-end,
t4-non-ecm-data,t4-non-ecm-sig-end,…,
cm-message,
jm-message,
ci-message,
v34rate},field-data OCTET STRING (SIZE(1..65535)) OPTIONAL}UDPTLPacket ::= SEQUENCE{
seq-number
INTEGER (0..65535),
primary-ifp-packet
TYPE-IDENTIFIER.&Type(IFPPacket),error-recovery CHOICE{
secondary-ifp-packets SEQUENCE OF TYPE-IDENTIFIER.&Type(IFPPacket),fec-info
SEQUENCE{
fec-npackets INTEGER,
fec-data
SEQUENCE OF OCTET STRING
}
}
}
END

A.2

ＪＴ－Ｔ３８(第１版)抽象構文記法１（ＡＳＮ．１）

T38 DEFINITIONS AUTOMATIC TAGS ::=BEGIN
IFPPacket ::= SEQUENCE{
type-of-msg
data-field}

Type-of-msg,
Data-Field OPTIONAL

Type-of-msg ::= CHOICE{
t30-indicator ENUMERATED{
no-signal,
cng,
ced,
v21-preamble,
v27-2400-training,v27-4800-training,v29-7200-training,v29-9600-training,v17-7200-short-training,v17-7200-long-training,v17-9600-short-training,v17-9600-long-training,v17-12000-short-training,v17-12000-long-training,- 41 -

ＪＴ－Ｔ３８v17-14400-short-training,v17-14400-long-training,…
},data ENUMERATED{
v21,
v27-2400,v27-4800,v29-7200,v29-9600,v17-7200,v17-9600,v17-12000,
v17-14400,…
}}
Data-Field ::= SEQUENCE OF SEQUENCE{
field-type ENUMERATED{
hdlc-data,hdlc-sig-end,
hdlc-fcs-OK,
hdlc-fcs-BAD,
hdlc-fcs-OK-sig-end,
hdlc-fcs-BAD-sig-end,
t4-non-ecm-data,t4-non-ecm-sig-end},
field-data OCTET STRING (SIZE(1..65535)) OPTIONAL}UDPTLPacket ::= SEQUENCE{
SE-NUMBER
INTEGER (0..65535),
primary-ifp-packet TYPE-IDENTIFIER.&Type(IFPPacket),error-recovery CHOICE{
secondary-ifp-packets SEQUENCE OF TYPE-IDENTIFIER.&Type(IFPPacket),fec-info
SEQUENCE{
fec-npackets INTEGER,
fec-data
SEQUENCE OF OCTET STRING
}
}
}
END

- 42 -

ＪＴ－Ｔ３８

付属資料

Ｂ（ＪＴ－Ｔ３８に対する）
ＪＴ－Ｈ３２３呼の確立手順（この付属資料は、本標準の必須部分を形成する）

B.1

はじめに

本付属資料では、システムレベルの要件、インターネット対応ファクシミリ装置の実装に関する手順およ
びＪＴ－Ｈ３２３付属資料Ｄと同様に本付属資料に定義された手順を用いるものを含む他のＪＴ－Ｔ３８の実装と呼を確立するためのＪＴ－Ｔ３８に適合するインターネット対応ファクシミリ装置ゲートウェイについて記述する。
B.2

ファクシミリ装置とゲートウェイ間の通信

送信Ｇ３ファクシミリ装置と着呼ゲートウェイ間の通信は、一般的にＰＳＴＮ上を、ダイヤルアップ手順
を用いて達成される。ＪＴ－Ｔ３０の基本およびオプション手順がサポートされる。
ゲートウェイが、ダイレクトダイヤルイン手順をサポートする場合、発信端末からのファクシミリ伝送をＰ
ＳＴＮのモデム信号として受信することができる。ゲートウェイが、ネットワーク内部に置かれている所では、ＰＣＭ符号化されたディジタルチャネルの形式で送信を受信することができる。インターネット対応
ファクシミリ装置（ＩＡＦ）の実装では、ＩＰ網に直接接続され、呼の確立の為にゲートウェイのように動作する。

B.2.1 アドレス情報の伝送
発呼端末から送信ゲートウェイへ、着呼端末のＪＴ－Ｅ１６４アドレスを伝達するには、プロンプトによる手動手順、第２ダイヤル手段、または他の適切な手段によるかもしれない。
また、その他にはＪＴ－Ｔ３０に記述されているようにＩＲＡ（インターネットルーティングアドレス）／
ＩＳＰ（インターネット選択ポーリングアドレス）信号中に宛先のＪＴ－Ｅ１６４アドレスを使用することで役立つアプリケーションがある。

B.3

ゲートウェイ間の通信

B.3.1 概要
B.3.1.1 呼設定
ＪＴ－Ｔ３８付属資料Ｂに準拠した実装のための呼設定は、ＪＴ－Ｈ３２３で定義されたファーストコネ
クト手順に基づいている。ＪＴ－Ｔ３８の実装は、２つの異なるＪＴ－Ｈ３２３互換環境の中で動作するかもしれない。

（１） ＩＰ環境でのファクシミリ単機能。この環境では、音声機能はサポートされない。本付属資料の手順や要件は、ＪＴ－Ｈ３２３付属資料Ｄの実装にとってかわられるのでなければ、本環境で機能する実装に適合しなければならない。
（２） ＩＰ環境でのファクシミリと音声。本環境での実装は、ＪＴ－Ｈ３２３付属資料Ｄに記述される方法を用いなければならない。

- 43 -

ＪＴ－Ｔ３８

ＪＴ－Ｔ３８付属資料Ｂの実装は、呼設定のファーストコネクト手順を使用しなければならず、ＪＴ－Ｈ２
４５ネゴシエーションを起動してはならない。一方、ＪＴ－Ｔ３８付属資料Ｂの端末は、対向の端末が、Ｊ
Ｔ－Ｔ３８付属資料Ｂの端末あるいは、ＪＴ－Ｈ２４５を開始することが必要な他の端末の場合には、ＪＴ－Ｈ２４５をサポートしなければならない。

B.3.1.2 メディアチャネル
ＪＴ－Ｈ３２３付属資料Ｄでは、ＪＴ－Ｔ３８ファクシミリパケットがＪＴ－Ｈ２２５．０発呼信号手順とは別のＴＣＰ／ＵＤＰポート上で送信されることを求めている。全ての要求されるポートは、通常、最初の fastStart の交換時に確立される。ＪＴ－Ｔ３８付属資料Ｂの最小限の実装では、発呼信号手順のためのＴ
ＣＰポートおよびＪＴ－Ｔ３８ファクシミリ情報のためのＵＤＰＴＬ用のＵＤＰポートまたはＲＴＰ用の２つのＵＤＰポート（一方はＲＴＰ用で、他方はＲＴＣＰ用）またはＴＣＰポートのどちらかを要求する。

B.3.1.3 ＪＴ－Ｈ２４５の使用法
本付属資料に準拠するエンドポイントには、ＪＴ－Ｈ２４５のサポートは要求されるが、ＪＴ－Ｈ２４５制御チャネルでの通信は開始してはならない。むしろ、ＪＴ－Ｔ３８付属資料Ｂの端末は、ＴＣＳメッセー
ジあるいは分離したＪＴ－Ｈ２４５制御チャネルでの起動要求のどちらか最初に受信した後に、ＪＴ－Ｈ２
４５制御チャネルでのＪＴ－Ｈ２４５メッセージのみを送信しなければならない。ＪＴ－Ｔ３８付属資料Ｂの端末は、全てのＪＴ－Ｈ３２３端末群との相互接続性を確保するためにＪＴ－Ｇ７１１のサポートを示すべき最初のＴＣＳメッセージで、本標準のサポートを通知しなければならない。
（注）本付属資料の以前の版では、端末はファーストコネクト手順のみをサポートしなければならないことを規定している。そのため、他の端末がＪＴ－Ｈ２４５の通信を最初に起動する場合を除き、新しい端末がＪＴ－Ｈ２４５通信を起動しないことは、他の古い端末との相互接続性のためには重要である。

B.3.2 基本的な呼設定
ＪＴ－Ｈ３２３の実装では、次のものを含む複数段階の呼設定手順がある。
（１）エンドポイントとゲートキーパー間のＵＤＰを用いたＲＡＳ（登録、承認および状況）信号手順（２）ＴＣＰ／ＩＰを用いて、直接エンドポイント間、あるいは、使用中の発呼モデルに依存するゲートキー
パーとエンドポイント間のどちらかでのＪＴ－Ｈ２２５．０に基づいた発呼手順（３）ＪＴ－Ｈ２２５．０呼制御チャネル内のトンネリング、あるいは、分離されたＴＣＰ／ＩＰ接続を介した送信でのメッセージを用いた、ＪＴ－Ｈ２４５の能力ネゴシエーションと論理チャネルの管理

ＲＡＳのサポートは必須であるが、ＪＴ－Ｈ３２３エンドポイントは、網中に存在してエンドポイントにサービスを提供するゲートキーパー無しにＲＡＳの使用は必須でない。従って、付属資料Ｂの実装は、ゲー
トキーパーの有無に関わらず使用可能である。ＬＤＡＰや私的なアドレス帳のように、希望する任意の様式
でＩＰアドレスを入手できる。しかしながら、ゲートキーパー環境に置かれた場合、ＪＴ－Ｈ３２３により登録し、操作を行うことになる。

本付属資料に準拠する実装は、ＪＴ－Ｈ３２３ ＲＡＳ信号手順に適合しなければならない。ＲＡＳ信号手
順は、ＪＴ－Ｔ３８の実装に、ＪＴ－Ｈ３２３の既知のＴＣＰポートを用いて、発呼する能力を与える。そして、ＪＴ－Ｔ３８のメッセージで使用するポートの動的割付け機能を提供する。

本付属資料に準拠した実装は、ＪＴ－Ｈ３２３の８．１．１節、どの端末も登録されない状況を想定する“基本呼設定－いずれのエンドポイントも未登録の場合”に記述されているＪＴ－Ｈ３２３の呼設定メッセージ- 44 -

ＪＴ－Ｔ３８

を利用する。ＪＴ－Ｈ３２３の８．１節の最初の部分、“フェーズ A－呼設定”もＪＴ－Ｔ３８の実装に関連する。ＪＴ－Ｈ３２３の８．１節の残りの部分は、一つあるいは両方のエンドポイントがゲートキーパーに登録されている場合に適用する。

本付属資料に準拠する実装では、ＴＣＰ／ＩＰセッションを開設し、ＪＴ－Ｈ３２３の８．１．７節に記述されたように書き込まれたファーストコネクトフィールドを持つＪＴ－Ｈ２２５．０のＳＥＴＵＰメッセー
ジを送信することで最初に呼を開始しなければならない。

受信端末は、ＪＴ－Ｈ３２３「ファーストコネクト」の手順により、ＪＴ－Ｈ２２５．０の ALERTING、
CALL PROCEEDING、PROGRESS、または CONNECT メッセージで応答する。付属資料Ｂの実装はビデオ、音声あるいはＯＬＣ要素のデータを「fastStart」構造の中に含んでもよいが、存在するならばデータタイプはファクシミリ規格を含むＯＬＣ要素に従わなければならない。ファクシミリに関するＯＬＣ要素は次節に記述される。

B.3.3 能力ネゴシエーション
ゲートウェイがサポートや使用するオプションを決定するためにネゴシエーションが必要ないくつかのオプションがある。付表Ｂ．１／ＪＴ－Ｔ３８を参照。

- 45 -

ＪＴ－Ｔ３８

付表Ｂ．１ ／ＪＴ－Ｔ３８

ゲートウェイのオプション能力サポートの指示（ＩＴＵ－Ｔ

Ｔ．３８）

オプション
データレート管理方法

説明
方法１、ＴＣＦのローカルな生成はＴＣＰの使用が要求される。
方法２、ＴＣＦの転送はＵＤＰの使用が要求される。方法２はＴＣＰの使用を推奨していない。

データ転送プロトコル

送信ゲートウェイは、ＪＴ－Ｔ３８ ＲＴＦパケット転送のためＵＤＰ／Ｕ
ＤＰＴＬあるいはＵＤＰ／ＲＴＰあるいはＴＣＰの選択を指示しても良い。受信装置が転送プロトコルを決定する。

フィルビットの削除

パケット網でのバンド幅削減のため、フェーズＣ、非ＥＣＭデータのフィルビット列削除と挿入する能力を指示する。オプション。注参照

ＭＭＲ変換符号化

データの圧縮向上とパケット網でのバンド幅削減のため、回線フォーマットからＭＭＲへ、ＭＭＲから回線フォーマットへ変換する能力の指示。
オプション。注参照

ＪＢＩＧ変換符号化

バンド幅削減のため、ＪＢＩＧを変換する能力の指示。オプション。注参照最大バッファサイズ

ＵＤＰ（ＵＤＰＴＬかＲＴＰ）モードのため、このオプションは、オーバー
フローの発生前にリモート装置に格納できる最大のオクテット数を指示する。オーバーフローを避けるため転送レートに制限を設けることは送信
アプリケーションの責務である。ネゴシエーションされたデータレートはバッファからデータが消されるレートを決定されるのに使用されるべきである。

最大データグラムサイズ

このオプションは、リモート装置により受けることができる一つのＵＤＰ
ＴＬパケットの最大サイズか、ＲＴＰのペイロードの最大サイズを指示す
る。

バージョン

ＪＴ－Ｔ３８のバージョン番号。新しいバージョンはそれ以前のバージョンとコンパチビリティがなければならない。

注 － バンド幅削減は、フェーズＣデータ、すなわちＭＨ、ＭＲ(この場合は、ＪＢＩＧに変換符号化される)及びＭＭＲが適当で、その場合のみ行われなければならない。ＭＭＲとＪＢＩＧはＴＣＰにより与えられるような確かなデータ転送を要求する。変換符号が選択されるとき、呼内の各々のページに適用されなければならない。

これらの能力は、ＪＴ－Ｈ２４５第７版またはその版以降の T38faxProfile で定義されるＯＬＣ要素を使用
してネゴシエーションされる。

付図Ｂ．１／ＪＴ－Ｔ３８で示される二つの片方向の信頼性または非信頼性の論理的なチャネル（送信側から受信側へのチャネルと受信側から送信側へのチャネル）、またはオプションとして付図Ｂ．２／ＪＴ－
Ｔ３８で示される一つの双方向で信頼性のあるチャネルは、ＪＴ－Ｔ３８パケットの転送のためにオープンされなければならない。ＪＴ－Ｔ３８パケットは、ＴＣＰまたは、ＵＤＰ（ＵＤＰＴＬかＲＴＰ）のどちらかを使用して転送される。一般的に、ＴＣＰの使用は、ファクシミリ通信のためのバンド幅が制限されているとき、あるいは、ＴＣＰがフロー制御を与えてからのＩＡＦからＩＡＦへの転送のために、より効果的である。一方、ＵＤＰ（ＵＤＰＴＬかＲＴＰ）の使用はファクシミリ通信のためのバンド幅が十分であるとき
により効果的となるであろう。
- 46 -

ＪＴ－Ｔ３８

送信側

送信論理チャネル

受信側

受信論理チャネル

付図Ｂ．１／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

送信側

一対の片方向チャネル
Ｔ．３８）

送信ストリーム

受信側

受信ストリーム

付図Ｂ．２／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

双方向チャネル

Ｔ．３８）

送信端末はＴＣＰかＵＤＰＴＬでＴ３８送信するとき、 Setup の fastStart 要素の OpenLogicalChannel 内でＴＣＰまたはＵＤＰポートを指定する。受信端末は、ＪＴ－Ｈ３２３の８．１．７節、ファーストコネクト
手順で示されたように、fastStart 要素の OpenLogicalChannel 内でＴＣＰ（あるいはＵＤＰ）を提供しなければならない。

受信側では送信側の選択に基づき、ＴＣＰまたはＵＤＰポートをオープンすべきである。もし、送信端末
がＵＤＰ（ＵＤＰＴＬまたはＲＴＰ）あるいはＴＣＰを選ぶのであれば、fastStart シーケンス内で適当なポートをもつ OpenLogicalChannel 内でその選択を与えなければならない。受信端末は、Connect の fastStart 要素内の OpenLogicalChannel の二つから、一つを指定することによって、ＴＣＰかＵＤＰ（ＵＤＰＴＬまたはＲＴＰ）かの転送を選択できる。
ＲＴＰでＴ３８送信するとき、OpenLogicalChannel は、付属資料Ｇで定義された汎用オーディオ能力を含み、ＪＴ－Ｈ３２３の８．１．７節のファーストコネクトで定義された Setup メッセージの fastStart 要素を含まなければならない。汎用オーディオ能力のパラメータ名は、ＪＴ－Ｈ２４５のＡＳＮ．１と同じに名付けられている。
全てのＪＴ－Ｔ３８付属資料Ｂ準拠の装置は、fastStart 内に t38FaxUdpOptions と transferredTCF の両方をもつＪＴ－Ｔ３８ファクシミリＯＬＣを含まなければならない。ＪＴ－Ｈ３２３付属資料Ｄ準拠でＪＴ－Ｔ
３８に対応した全ての装置も、この構造を含むことが要求される。付け加えて、ＪＴ－Ｔ３８付属資料Ｂの装置は t38FaxTcpOptions と localTCF の両方をもつＯＬＣと、t38FaxProtocol として選択した tcp を含むべきである。オプションとして、ＪＴ－Ｔ３８付属資料Ｂの装置は、fastStart 構造に含まれた transferredTCF で規定された T38RTP generic audio capability を持った ＯＬＣを含んでも良い。ＪＴ－Ｈ３２３の８．１．７節に示されるように、fastStart 要素内に含まれたＯＬＣの命令は送信側で選択を指示する。受信側はＣＯＮＮＥＣ
Ｔメッセージの fastStart 要素、あるいは、fastStart 要素を持つ他のメッセージに使用したいＯＬＣを含ませるだけである。
- 47 -

ＪＴ－Ｔ３８

（注） 付属資料Ｂの最初の版において、一つの双方向性の信頼性チャネルを使うことはできなかった。下位互換性を維持するために、
エンドポイントは t38FaxTcpOptions SEQUENCE を含み、t38TCPBidirectionalMode
フィールドに TRUE をセットすることによって双方向性の信頼性の高いチャネルのサポートを指定することができる。もし、他のエンドポイントが t38FaxTcpOptions SEQUENCE を含まないなら、エンドポイントは
ＪＴ－Ｔ３８のため、一つの双方向性信頼性チャネルがサポートされていないとみなすべきであり、２つの片方向の信頼性または非信頼性チャネルのいずれかを使用しなければならない。

B.3.4 呼設定ＯＬＣの例
本節での例は、色々な場合に送信されるＯＬＣ要素について説明している。ＪＴ－Ｈ３２３の８．１．７
節の規則は、ＪＴ－Ｈ２４５のＯＬＣ定義に従っている。ＡＳＮ．１の詳細はＪＴ－Ｈ２４５を参照のこと。

B.3.4.1 ＴＣＰ、ＵＤＰ（ＵＤＰＴＬ）、または ＲＴＰサポート
デフォルトはＴＣＰとＵＤＰ（ＵＤＰＴＬ）の両方をサポートすることが求められる。この場合、送信側
は T38/TCP&localTCF と T38/UDPTL&transferredTCF のためＯＬＣを送信しなければならない。オプションとして、送信側は T38/RTP&transferredTCF のためのＯＬＣを送信することができる。もし、受信側でＵＤＰの使用を望むならば、T38/UDPTL&transferredTCF のためのＯＬＣが返信される。もし、受信側でＲＴＰの使用を望むならば、T38/RTP&transferredTCF のためのＯＬＣが返信される。それ以外ならば、T38/TCP&localTCFのＯＬＣが返信される。

B.3.4.2 データレート管理方法１を持つＵＤＰ（ＵＤＰＴＬ）

サポート

送信側がデータレート管理方法１とデータ転送のＵＤＰ（ＵＤＰＴＬ）の使用を望む場合には、
T38/UDPTL&transferredTCF､T38/UDPTL&localTCF ､T38/TCP&localTCF のＯＬＣが送信されなければならな
い。もし、受信側で UDPTL&localTCF の使用に同意するならば､T38/UDPTL&localTCF のＯＬＣが返信される。

B.3.4.3 データレート管理方法１を持つＲＴＰサポート
送信側がデータレート管理方法１とデータ転送のＲＴＰの使用を望む場合には、T38/RTP&transferredTCFと T38/RTP&localTCF のＯＬＣが送信されなければならない。もし、受信側で RTP&localTCF の使用に同意するならば､T38/RTP&localTCF のためのＯＬＣが返信される。

B.3.5 必須な呼設定メッセージ
付属資料Ｂ準拠の装置は呼設定のため、ＪＴ－Ｈ２２５．０の以下の節をサポートしなければならない。
（１）表４／ＪＴ－Ｈ２２５．０の必須要素、 すなわち ALERTING， CONNECT， CALL PROCEEDING，SETUP, RELEASE COMPLETE などが、付属資料Ｂに従うＪＴ－Ｔ３８エンドポイントでサポートされなければならない。注、ＪＴ－Ｈ３２３に示されるように、もしも SETUP の受信の４秒以内にCONNECT､CALL PROCEEDING または RELEASECOMPLETE が送信されれば、ALERTING の送信は必要ない。注、ゲートウェイは CALL PROCEEDING を送信しなければならない。
（２）

FACILITY の情報要素はＪＴ－Ｈ２２５．０の７．４．１節に記述されている（３）

ALERTING の情報要素はＪＴ－Ｈ２２５．０の７．３．１節に記述されている（４）

CALL PROCEEDING の情報要素はＪＴ－Ｈ２２５．０の７．３．２節に記述されている（５）

CONNECT の情報要素はＪＴ－Ｈ２２５．０の７．３．３節に記述されている（６） PROGRESS の情報要素はＪＴ－Ｈ２２５．０の７．３．７節に記述されている- 48 -

ＪＴ－Ｔ３８（７）RELEASE COMPLETE の情報要素はＪＴ－Ｈ２２５．０の７．３．９節に記述されている（８）

SETUP の情報要素はＪＴ－Ｈ２２５．０の７．３．１０節に記述されている（９） ＪＴ－Ｈ２２５．０のＡＳＮ．１はＪＴ－Ｈ２２５．０に記述されている（注）ＪＴ－Ｈ２２５．０ ＡＳＮ．１は多数のオプション機能をサポートしている。 ＪＴ－Ｔ３８付属
資料Ｂ準拠の装置は、潜在的にもっている認証機能を含めて、オプションのＪＴ－Ｈ２２５．０の全機能を実装しても良い。また、ＪＴ－Ｈ４５０．ｘの補足サービスも実装しても良い。ＪＴ－Ｈ２２
５．０オプションはＯＬＣネゴシエーションの範囲外である。（すなわち、優先される。）もしも、
リアルタイムファクシミリのエンドポイント（ＪＴ－Ｈ３２３付属資料Ｄまたは、ＪＴ－Ｔ３８付属
資料Ｂ）がＪＴ－Ｈ４５０．ｘの補足サービスを使用しようとすると、リモートエンドポイントがそれらをサポートするか、あるいはしないかということを考慮しなければならない。最悪の場合、補足
サービスは受信側で無視される。従って、要求側のエンドポイントは、例えばタイムアウトメカニズ
ムを用いてこの状態を処理しなければならない。

B.3.6 呼経過信号のマッピング
呼設定と呼経過のため、返信信号は付表Ｂ．２／ＪＴ－Ｔ３８に示すセットとして簡単化することができる。これらは、接続メッセージより前か、またはその代わりに返信される。

CONNECT メッセージは、ゲートウェイが端末Ｇ３ＦＥとの接続が確立されたと判断されることによって返信される。もしも、ＣＥＤまたはＦＳＫフラグが見つかると、適当なＪＴ－Ｔ３８メッセージが送信される。呼設定や経過のこのレベルは、非ＪＴ－Ｈ３２３環境のみならずＪＴ－Ｈ３２３の両方で作用する。

- 49 -

ＪＴ－Ｔ３８

付表Ｂ．２／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ目

呼経過マッピング

Ｔ．３８）

的マッピング／コメント

ビジー１。Ｅ．１８０／Ｑ．３５に定義された加入者ビ

ＪＴ－Ｑ８５０で定義された理由種別１７

ジートーン。
ビジー２。いくつかのＰＡＢＸモデルでの“特有のビＪＴ－Ｑ８５０で定義された理由種別１７ジー”と時々称される。
Ｅ．１８０／Ｑ．３５で定義される輻輳ビジー。

ＪＴ－Ｑ８５０で定義された理由種別３４

リング１。

ALERTING

Ｅ．１８０／Ｑ．３５に定義されている呼び出しトーン。これは、中継の呼経過指示表示である。
あたかもエンドエンド間でＰＳＴＮ接続があったかのよ
うに、発呼Ｇ３ＦＥ端末へのリングバック信号を生成するために使用することができる。
リング２。一つの長い呼び出しトーンの代わりに二つのALERTING

短いトーンが発生させられるトーン１に似ている。これは中継の呼経過の結果である。
ＳＩＴインターセプト。この特別な情報トーンはＥ．１

ＪＴ－Ｑ８５０で定義された理由種別４８０／Ｑ．３５に定義されている。インターセプトトー

注 － ＳＩＴトーンは、一般に、ダイヤルされンは、周波数と周期のトーンの組み合わせである。

た番号との間で問題を起こすので識別されない。

ＳＩＴ空き。この特別な情報トーンはＥ．１８０／Ｑ．

ＪＴ－Ｑ８５０で定義された理由種別４

３５に記載されている。回線空きトーンは、周波数と周期のトーンの組み合わせである。
ＳＩＴ再要求。この特別な情報トーンはＥ．１８０／Ｑ． ＪＴ－Ｑ８５０で定義された理由種別４
３５に記載されている。再要求トーンは、周波数と周期のトーンの組み合わせである。
ＳＩＴ回線なし。この特別な情報トーンはＥ．１８０／

ＪＴ－Ｑ８５０で定義された理由種別４

Ｑ．３５に記載されている。回線なしトーンは、周波数と周期のトーンの組み合わせである。

B.3.7 メッセージ内 maxBitRate の使用
ＪＴ－Ｔ３８は、ＪＴ－Ｈ２４５に準拠したデータアプリケーション（ＵＤＰＴＬ、あるいは、ＴＣＰ）、
あるいは、オーディオ能力（ＲＴＰ）である。ＪＴ－Ｈ２４５のＯＬＣは、maxBitRate フィールドをセットすることが要求される。ゲートウェイの実装のため、このフィールドは、ゲートウェイで提供されるＴＤＭ
網のための最高モデム速度を表示すべきである。ＩＡＦのための速度は、未定義であるが、０にセットしてはならない。maxBitRate の単位が１００ ｂｉｔ／ｓであることに注意すること。maxBitRate フィールドはファクシミリ送信速度の能力交換には使用してはならず、着信側の最大要求帯域の参考情報としてのみが含まれる。

注１ ＪＴ－Ｈ３２３が適用されない他のＪＴ－Ｔ３８エンドポイント（例えば付属資料Ｈを参照）と単位値は異なる。これはＪＴ－Ｈ３２３ネットワークドメインに位置する２つのエンドポイント間のＪＴ－Ｔ３
８コールの場合に正しいシグナリング変換を意味する。このパラメータの使用方法の詳細についてはＨ４．
１節を参照のこと。
- 50 -

ＪＴ－Ｔ３８

B.3.8 ＤＴＭＦ送信
ＪＴ－Ｈ３２３の付属資料Ｄに記述されている UserInputIndication はＪＴ－Ｈ２４５の信号であり、ＪＴ－Ｈ２４５の制御チャネルが利用された場合に使用することができる。ＪＴ－Ｈ３２３、あるいは、ＪＴ－
Ｈ２２５．０に記載された他のメカニズムもまた、使用することができる。

B.3.9 相互接続性
ＪＴ－Ｈ３２３ダイレクトコールモデルやＪＴ－Ｔ３８ 付属資料Ｂでは、コールシグナルのためには既知のポートが要求される。ＪＴ－Ｈ２２５．０付録 IV の記述では、ＴＣＰでの呼制御によるＪＴ－Ｈ３２３の既知のポートは１７２０である。ＪＴ－Ｔ３８付属資料ＢでのエンドポイントはＪＴ－Ｈ３２３ の既知のポートを使用すべきである。マルチエンドポイントをサポートするためのシングル準拠の装置（ゲートウェ
イのような）のためには、ダイナミックポートが使用する必要がある。本付属資料に従うファクシミリゲー
トウェイはＪＴ－Ｈ３２３ ＲＡＳをサポートしなければならない。

ＪＴ－T ３８付属資料Ｂの実装は、ＪＴ－Ｈ２２５．０に関するメッセージの中で、h245Tunnelling を TRUEにセットしなければならない。

- 51 -

ＪＴ－Ｔ３８

付属資料

Ｃ（ＪＴ－Ｔ３８に対する）
ＵＤＰＴＬのためのオプションの前方エラー訂正機構（この付属資料は、本標準の必須部分を形成する）

C.1

オプションの前方エラー訂正方法の概要

パリティＦＥＣ方式は、符号化モードと復号化モードの両方で等しい、ということにおいて、対称であり、任意の数の任意サイズのＩＦＰメッセージに対して計算されてもよい。送信ゲートウェイは、いくつかのプ
ライマリＩＦＰパケットを渡すことによりＦＥＣメッセージを生成する。これらのＦＥＣメッセージは、図５／ＪＴ－Ｔ３８のようにパケットに組み立てられる。
ＦＥＣメッセージによりカバーされるプライマリＩＦＰパケット損失を検出した受信ゲートウェイは、残された（受信された）プライマリＩＦＰパケットとＦＥＣメッセージ自身を、パリティ符号化／復号化アルゴ
リズムに渡すことで、プライマリＩＦＰパケットの再組み立てを行うことができる。ある条件が、パリティの符号化／復号化を使用して復旧すべき、失われたプライマリＩＦＰパケットのために適用される。これらを、以下の章で論議しなければならない。

C.2

パリティ符号化／復号化機構の動作と特徴

パリティ方式は多くの任意のサイズのＩＦＰメッセージを受け入れる。垂直方向に整列し、付図Ｃ．１／
ＪＴ－Ｔ３８ ａ）に示される２次元マトリクスを生成するために、０が短い長さのメッセージを埋める。それから、１ビットの幅の加算が、マトリックスの幅にわたって一桁毎（排他的論理和機能に等価な）に実行される。各々の総和の結果は２進数のディジット（すなわち０か１）となる。この処理は、付図Ｃ．１／Ｊ
Ｔ－Ｔ３８ ｂ）に図示されている。パリティ機構の出力は、演算結果の２進データの列である。
基本的なエラー復旧機構は、ｎ個のパケット中に１個の損失が発生していることを想定して動作する。もし、（ｎ＋１）番目のパケットの中に、ｎ個の先行しているパケットのプライマリＩＦＰパケットから生成されたＦＥＣメッセージがあり、最初のパケット中のただ１つのパケットが失われたのなら、消失したどんなＩ
ＦＰメッセージでも再組み立てすることが出来る。以上で概略を述べたパリティ機構を使用したプライマリ
ＩＦＰパケットの生成と再組み立てを、以下の節に記述する。

- 52 -

ＪＴ－Ｔ３８ａ）データ長正規化の例

ｂ）パリティ機能アプリケーション

入力フレーム１0 1 0 0 1 1 1 0 1 0 0 0 1 0 1 1

入力フレーム１0 1 0 0 1 1 1 0 1 0 0 0 1 0 1 1

入力フレーム 2

1 0 1 1 1 0 0 0 1

入力フレーム 2

1 0 1 1 1 0 0 0 1 0 0 0 0 0 0 0

入力フレーム 3

0 0 0 1 1 0 1 0 0 1 0 0

入力フレーム 3

0 0 0 1 1 0 1 0 0 1 0 0 0 0 0 0

正規化

桁単位の２進和(繰上切捨て)

入力フレーム１0 1 0 0 1 1 1 0 1 0 0 0 1 0 1 1

入力フレーム 2

1 0 1 1 1 0 0 0 1 0 0 0 0 0 0 0

入力フレーム 3

0 0 0 1 1 0 1 0 0 1 0 0 0 0 0 0

結果の出力+ + + + + + + + + + + + + + + +1 1 1 0 1 1 0 0 0 1 0 0 1 0 1 1

付図Ｃ．１／ＪＴ－Ｔ３８ ａ）データ長正規化とｂ）パリティ機能操作の図（ＩＴＵ－Ｔ Ｔ．３８）

C.2.1 ＦＥＣメッセージの生成と送信
付図Ｃ．２／ＪＴ－Ｔ３８に示すものと類似のバッファを利用することにより、処理のためにパリティのＦＥＣアルゴリズムに以前に受信した複数のプライマリＩＦＰパケットを渡すことが出来る。ＦＥＣ機構は、
現在のプライマリＩＦＰパケットの後にパケットに組み立てられた符号化データフレームを返す。
送信ゲートウェイは、ＦＥＣ情報を生成するために使用すべき先行するＩＦＰメッセージの数を、前もって決定しなければならない。ｎ個の先行するプライマリＩＦＰパケットが、パリティ符号化機構へ送られる。
そこで、ｌオクテット長のＦＥＣデータの単一メッセージになる。このｌは、プライマリＩＦＰパケットリ
スト中での最も大きなメッセージ長に、２を加算したものである。最終的に、直近に生成されたＦＥＣメッ
セージが、付図Ｃ．２／ＪＴ－Ｔ３８で示されるように組み立てられ、パケットとしてプライマリＩＦＰパケットの後に挿入される。

- 53 -

ＪＴ－Ｔ３８順序番号(45)

プライマリメッセージ

FEC メッセージ

順序

IFP メッセージ蓄積

45

IFP メッセージ

44

IFP メッセージ

パリティ FEC機構

43

IFP メッセージ+

42

IFP メッセージ

41

IFP メッセージ

付図 Ｃ．２／ＪＴ－Ｔ３８ – 単一パリティＦＥＣフレームの生成とパケット化（ＩＴＵ－Ｔ Ｔ．３８）
複数のＦＥＣメッセージが単一パケットで送られるかもしれない。そのＦＥＣ各々は、ｆｅｃ＿ｎｐａｃｋ

ｅｔｓ個の先行するプライマリＩＦＰパケットから生成されている。（ここではｆｅｃ＿ｎｐａｃｋｅｔｓ
は先行するプライマリＩＦＰパケットの個数）、唯一１個のＦＥＣメッセージが存在している場合以外、複数のＦＥＣメッセージが単一のパケットで送信される時、各々のＦＥＣメッセージに対して提供されるプラ
イマリＩＦＰパケットは、連続しているのではなく、インターリーブされる。これは３個の連続したパケッ
ト損失に対する防御を提供する例として付図Ｃ．３／ＪＴ－Ｔ３８に示されている。

- 54 -

ＪＴ－Ｔ３８

C.2.2 受信ＦＥＣメッセージとプライマリＩＦＰパケットの再組み立てあるパケット中のＦＥＣメッセージを受信しようとするゲートウェイは、最初にＵＤＰＴＬパケットから次のことを決定せねばならない。
•

パケットに存在するＦＥＣメッセージの数。

•

各々のＦＥＣメッセージに含まれるプライマリＩＦＰパケットの順序番号。

•

ネットワーク上で失われてしまったいくつかのパケットの順序番号。
与えられたＦＥＣメッセージにおいて符号化されたプライマリＩＦＰパケットの順序番号を決定するために、受信ゲートウェイは、最初にフレームに含まれるプライマリＩＦＰパケットの数を取り出さねばならない。単一ＦＥＣメッセージを含むパケットにおいては、そのメッセージに含まれる順序番号は、単純に、［ｓｅｑ－１］から［ｓｅｑ－（ｎ＋１）］の番号であり、このｎは、ｆｅｃ＿ｎｐａｃｋｅｔｓ要素の値であり、ｓｅｑは seq-number 要素の値である。パケットの順序番号がｓｅｑでｍ個のＦＥＣメッセージを含みｎにセットしたメッセージ制御フィールドを持つＵＤＰＴＬパケットにおいては、ＦＥＣメッセージＩ（１≦Ｉ≦ｍ）のための順序番号の範囲は、以下の式により簡単に決定される。
ＳｔａｒｔＳｅｑ = Ｓｅｑ – Ｉ
ＥｎｄＳｅｑ =Ｓｅｑ– Ｉ – (n – 1) m
この範囲の間の順序番号は、線形でありｍの間隔がおかれる。ひとたび、ＦＥＣメッセージ中に符号化されたプライマリＩＦＰパケットの順序番号が決定されたなら、受信ゲートウェイは、リストされたプライマ
リＩＦＰパケットのどれかが到着していないかどうかを決定するために、チェックを行うことが出来る。もし、これらプライマリＩＦＰパケットの１個、それがただ１つだけが到着していないのなら、その後ＦＥＣ
メッセージと残っている（到着している）プライマリＩＦＰパケットが誤ったシーケンスを復旧するために
パリティアルゴリズムに送られる。
ＦＥＣメッセージ 数ｍは fec-data 要素 中に含まれるオクテット文字列か らなる数である。（これはSEQUENCE OF 構造体で符号化されている）- 55 -

ＪＴ－Ｔ３８

付属資料

Ｄ（ＪＴ－Ｔ３８に対する）
ＳＩＰ／ＳＤＰ呼の確立手順（この付属資料は、本標準の必須部分を形成する）

D.1

はじめに

本付属資料は、ＲＦＣ３２６１（ＳＩＰ）及びＲＦＣ２３２７（ＳＤＰ）に定義された手順並びにＲＦＣ
６４６６で定義された「image」メディアタイプを使用することで、他のＪＴ－Ｔ３８の実装で呼を確立するために、ＪＴ－Ｔ３８に準拠したインターネット対応ファクシミリ装置の実装や、インターネット対応
ファクシミリ装置のゲートウェイについてのシステムレベルの要求条件と手順について記述する。ＳＩＰは、組み込まれたＳＤＰオファー／アンサープロトコル（Ｄ．２．３．０節参照）をメディア構成の指示とネゴ
シエーションに使用する。（例えば、ある特定のＪＴ－Ｔ３８構成。）

D.2

ゲートウェイ間の通信

D.2.1 概要
D.2.1.1 呼設定
本付属資料に適合した実装の呼設定は、ＲＦＣ３２６１に定義されたＳＩＰ（セッション開始プロトコル）に基づく。付属資料Ｂの様に、実装は 2 つの異なる互換性をもつ環境で動作しても良い。
１）ＩＰ環境におけるファクシミリのみ
この環境では、音声が提供されない。Ｄ．２．２．３節の手順および要求条件はこの環境で動作する実装が適用されなければならない。
２）ＩＰ環境におけるファクシミリおよび音声
本付属資料の手順および要求条件は、この環境で動作する実装が適用されなければならない。

D.2.1.2 メディアチャネル及びシグナリングチャネル（注）「チャネル」という用語は、ＪＴ－Ｈ３２３の用語（付属資料Ｂ参照）から再利用されている。また、本付属資料の「ＩＰトランスポート接続」と同義語である。

ＪＴ－Ｔ３８のファクシミリパケットはＳＩＰコールシグナリングから個別のＴＣＰ／ＵＤＰポート上で送信される。本付属資料の最小限の実装は、以下のものを必要とする。
－ ＳＩＰのためのＩＰトランスポート 接続：コールシグナリングのためのＴＣＰ／ＵＤＰポート（デフォルトは５０６０）、そして－ メディアのためのＩＰトランスポート 接続（ＪＴ－Ｔ３８トランスポート モードによる）•

ＵＤＰＴＬ／ＵＤＰ用の１つのＵＤＰポート、または、•

ＲＴＰ／ＵＤＰ用の１つまたは２つのＵＤＰポート（ＲＴＣＰの使用による）、または、•

ＪＴ－Ｔ３８ファクシミリ情報のためのＴＰＫＴ／ＴＣＰ用の１つのＴＣＰポート

D.2.1.3 ＳＤＰの利用
本付属資料に準拠するエンドポイントは、以下に記述された拡張を含むＳＤＰをサポートすることが要求される。

- 56 -

ＪＴ－Ｔ３８

D.2.1.3.1 ＳＤＰパラメータ定義
付表Ｄ．１／ＪＴ－Ｔ３８に示すＳＤＰパラメータは、本標準によって定義される。

付表Ｄ．１／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

ＳＤＰパラメータ定義
Ｔ．３８）

定義
ＪＴ－Ｔ３８のバージョン番号。新しいバージョンは、それ以前のバージョンと、
1
T38FaxVersion
互換性を持たなければならない。このパラメータが存在しないときは、バージョン０を示している。バージョンは整数値で表現される。
エンドポイントによってサポートされる最大ファクシミリ伝送レートを示す。しか2
T38MaxBitRate
し、実際の伝送速度としてネゴシエーションのためには使用してはならない。（注１）
バンド幅削減のため、フェーズＣ（ＪＴ－Ｔ３０参照）、非ＥＣＭデータのフィル
3
T38FaxFillBitRemoval
ビット列削除と挿入する能力を示す。論理型パラメータ（能力あり=true、能力なし＝false）（注２）
4
T38FaxTranscodingMMR データの圧縮向上とパケット網でのバンド幅削減のため、回線フォーマットからＭ
ＭＲへ、ＭＭＲから回線フォーマットへ変換する能力を示す。論理型パラメータ（能力あり=true、能力なし＝false）（注２）
バンド幅を縮小するため、ＪＢＩＧを変換する能力を示す。論理型パラメータ（能5T38FaxTranscodingJBIG
力あり=true、能力なし＝false）（注２）
本標準で定義されたファクシミリレートマネージメントモデルを示す。値は、6
T38FaxRateManagement"localTCF"または、"transferredTCF"でもよい。
オーバーフロー発生前にリモート装置に格納できる最大のオクテット数を示す。
7
T38FaxMaxBuffer
オーバーフローを避けるため、転送レートに制限を設けることは、送信アプリケー
ションの責務である。ネゴシエーションされたデータレートは、バッファからデータが消されるレートを決定するために使用されるべきである。値は整数で表現される。
リモート装置が受信できる最大ペイロード長。整数値。
8
T38FaxMaxDatagram
このパラメータは、オファーのエンドポイントが受信できる最大ＩＦＰフレームサ
9T38FaxMaxIFP
イズを知らせる。
ＦＥＣ、冗長、または、無し のどれか望まれるエラー訂正方法かを示す。有効な
10
T38FaxUdpEC
オプションは、“t38UDPFEC”、“t38UDPRedundancy”、及び “t38UDPNoEC”である。このパラメータは、ＪＴ－Ｔ３８のためのトランスポートとして、ＵＤＰ
ＴＬを使用するときにのみ存在しなければならない。
このパラメータが指定される場合、「minred」値はオファーのエンドポイントが受
11
T38FaxUdpECDepth
信を望むＵＤＰＴＬデータグラムあたりの最小冗長フレーム数を示す。（アンサーのエンドポイントが t38UDPRedundancy のエラー訂正モードの使用を選択した場合。）または、オファーのエンドポイントが望むＵＤＰＴＬデータグラムあたりの最小ＦＥＣフレーム数を示す。（アンサーのエンドポイントが t38UDPFEC のエラー訂正モードの使用を選択した場合。）
さらに、「maxred」値が指定される場合、オファーのエンドポイントがＵＤＰＴＬ
データグラムあたりの指定された数以下の冗長フレームまたは ＦＥＣフレームの受信を望むことを示す。
12
T38FaxUdpFECMaxSpan オファーのエンドポイントが指定されたＩＦＰフレーム数以上におよぶＥＦＣフ
レームを正しく処理できないかもしれないことを示す。
エンドポイントの製造者を示す。
13
T38VendorInfo
ＪＴ－Ｔ３８エンドポイントがサポートするモデム能力を示す。有効なオプション
14
T38ModemType
は、“t38G3FaxOnly” (0) と“t38G3AndV34G3” (1) である。
注:指定されていなければ、このパラメータの暗黙の値は“t38G3FaxOnly”である。
（注１）パラメータ T38MaxBitRate が既存の実装でどのように解釈されているかについてはＨ．４節の参考注記も参照すること。
（注２）シグナリング内で省略された場合、デフォルト値（＝'false'）となる。
No.

パラメータ名

T38FaxRateManagement だけが必須パラメータであり、他は全てオプションのパラメータである。ＳＤＰオ
ファー／アンサーにおけるパラメータ使用に関してはＤ．２．３．５節と、付属資料Ｈの概要を参照のこと。

- 57 -

ＪＴ－Ｔ３８

D.2.2 基本的な呼設定
D.2.2.1 呼設定メカニズムの選択
付属資料Ｂは、ＪＴ－Ｈ３２３のファーストコールセットアップがＪＴ－Ｔ３８呼を確立するための基本的なメカニズムであることを示す。本付属資料に記述された方法は、分解されたゲートウェイモデルのこのメカニズムに関連して使用されることを意図している。さらに、受信ゲートウェイが本付属資料の呼の確立
メカニズムをサポートすることを送信ゲートウェイが知っている場合には、本付属資料を使用しても良い。

D.2.2.2 ＳＩＰ呼設定
ＲＦＣ３２６１の１章によれば、ＳＩＰは、呼の確立と終了のための５つのフェーズをサポートする。

付表Ｄ．２／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

ＳＩＰ呼設定Ｔ．３８）

ユーザの位置

通信のために使用されるエンドシステムの決定

ユーザの能力使用されるメディアとメディアのパラメータの決定

ユーザの有効性通信に参加するための着呼側の意志の決定

呼の設定

呼び出し、（組み込まれたＳＤＰオファー／アンサープロトコル
による）着呼と発呼の両方での呼パラメータの確立（Ｄ．２．３．０節を参照）

呼の取扱い

転送および呼の終了を含む

ＳＩＰもＨ．２４８からＪＴ－Ｈ３２３への相互接続機能の例のように、他の呼設定や信号手順と共に使用することができる。
ＳＩＰはユーザを、リソースの予約がある場合、および予約のない場合のセッションに招待することができる（組み込まれたＳＤＰオファー／アンサーの使用による。Ｄ．２．３．０節を参照）。ＳＩＰはリソースを予約しないが、しかし招待されたシステムにこれをするのに必要な情報を伝えることができる。

D.2.2.3 ファクシミリのみの接続
送信ゲートウェイは、受信ＳＩＰサーバとのＪＴ－Ｔ３８ファクシミリ接続のために（適切なオプションを備えた）ＳＩＰの INVITE リクエストを送る。受信サーバは恐らく受信ゲートウェイになるが、。しかし、それはＳＩＰあるいは他の手段によって実際のゲートウェイへＳＩＰ接続をプロキシまたはリダイレクトすることでも良い。どんな場合も、レスポンスは、リクエストに対する受理、転送あるいは失敗を示し、送信ゲートウェイへ送られる。
もし受理されれば(あるいは、転送された INVITE が受理されれば)、ＪＴ－Ｔ３８ファクシミリ呼は続く。
一旦呼が終了すれば、呼はＳＩＰの BYE コマンドで切断しても良い。
ＳＩＰ／ＳＤＰシグナリングの例についてはＤ．２．４．１節を参照のこと。

D.2.2.4 音声およびファクシミリ接続
ＳＩＰの INVITE（ＳＤＰオファーを含む）は、ＲＦＣ３２６１の要求条件によって着呼側へ音声接続が要求される。その後、音声接続は確立される（呼の開始時の 初期状態としてオーディオモード含んだ場合。
次の節を参照のこと）。

D.2.2.4.1 音声とファクシミリ呼のための状態モデル
付図Ｄ．１／ＪＴ－Ｔ３８はＳＩＰ装置に組み込まれた状態モデルを説明している。音声の呼とファクシ- 58 -

ＪＴ－Ｔ３８

ミリ呼のための 2 つの操作モードは以下の通りである。

-

オーディオモード（VoIP）、１つ又は複数の音声コーデックを持つ-

ファクスリレーモード（FoIP） １つ又は複数のＪＴ－Ｔ３８ 構成（ＪＴ－Ｔ３８ 構成は、
ＪＴ－Ｔ３８トランスポート変換と全てのＪＴ－Ｔ３８パラメータ設定からなる）を持つ。

ＩＴＵ－Ｔ勧告Ｖ．１５２

ＶＢＤｏＩＰや非Ｇ３ＦＥモデムのためのパケットリレーモードのような、追加のモードがあるかもしれないが、そのような状態遷移は本標準の範囲外である。

(1) SIP 端末の状態モデル(=JT-T38 IAF)

(2) PSTN-SIP JT-T38 ゲートウェイの状態モデル(V.152 サポート無し)

SIP JT-T38 IAF

PSTN-SIP JT-T38 ゲートウェイ

JT-T38 エンドポイン
トファクスリレー
モード(JT-T38 FoIP)

PSTN
エンドポイント
IP ﾍﾞｱﾗ接続

PSTN ﾍﾞｱﾗ接続

オーディオモード(VoIP)

JT-T38 エンドポイン
トファクスリレー
モード(JT-T38 FoIP)

IP ﾍﾞｱﾗ接続

オーディオモード(VoIP)(3) PSTN-SIP JT-T38 ゲートウェイの状態モデル(V.152 サポート有り)
PSTN-SIP JT-T38 ゲートウェイ

PSTN
エンドポイント

JT-T38 エンドポイント
ファクスリレー
モード(JT-T38 FoIP)
IP ﾍﾞｱﾗ接続

PSTN ﾍﾞｱﾗ接続
音声帯域
データモード（V.152VBDoIP）

オーディオモード(VoIP)

付図Ｄ．１／ＪＴ－Ｔ３８

音声及びファクシミリ呼のための状態モデル

例: ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

ＳＩＰ 装置Ｔ．３８）

呼の存続期間中に１回または複数回の状態変化があるかもしれない。
注）例：ＳＩＰドメインによる、ＰＳＴＮの “alternate speech-fax”呼のエミュレーションは連続した
speech-fax-speech の呼のフェーズを伴い “audio to fax relay to audio”の状態遷移に繋がるかもしれない。

状態遷移は、下記のいずれかになる。

-

ＳＩＰ／ＳＤＰシグナリングと緊密に連動している（例：着ＳＩＰメッセージは状態変化を実施しても良い）。Ｄ．２．２．４．２節参照。もしくは、- 59 -

ＪＴ－Ｔ３８-

自動 状態遷移（すなわち、おそらく事前の合意によるローカル側の判断） 。Ｄ．２．２．４．３参照。

ＳＩＰのための２つの状態遷移方式は付属資料Ｅの記述と一致する（ＳＩＰに制御されるＪＴ－Ｔ３８エンドポイントとＨ．２４８制御のＪＴ－Ｔ３８エンドポイントとの間の相互接続性を容易にできる）。
ＳＩＰ制御による状態遷移方式は、Ｈ．２４８ゲートウェイの場合の MGC-strict 制御による 遷移（Ｅ．２．
２．１節 ＪＴ－Ｔ３８メディアゲートウェイコントローラ（ＭＧＣ）方式を参照）と、Ｈ．２４８“ＭＧ自動遷移”コンセプト（Ｅ．２．２．２節 ＪＴ－Ｔ３８自動遷移方式を参照）への自動状態遷移に関係する。

D.2.2.4.2 ＳＩＰ制御による音声とファクシミリ間の状態遷移
受信ゲートウェイがファクシミリを検出すると、ＪＴ－Ｔ３８方式でのファクシミリ接続を実行するために（既存の音声接続と同じ Call-ID を備えた）送信ゲートウェイにＳＩＰの INVITE リクエストが送信される。
受信ゲートウェイは応答するファクシミリエンドポイントにより生成されたＶ．２１に準拠するプリアン
ブルのみを検出のトリガーとして使用すべきである。応答するファクシミリエンドポイントがＮＳＦ、ＣＳ
Ｉ、またはＤＩＳ信号の送信を開始する前にセッションがＪＴ－Ｔ３８モードに移行するまでの時間を最大限確保できるように、受信ゲートウェイはプリアンブルの開始後２００ｍｓ以内に INVITE リクエストを生成すべきである。
ファクシミリ呼の確立（Ｄ．２．２．３節で言及）が完了すると、通信の種類がＪＴ－Ｔ３８／Ｇ３であった場合、ＪＴ－Ｔ３８ファクシミリ呼は、ＪＴ－Ｔ３８ Ｖ．２１フラグインジケータパケットを使用して処理を続行する。
切り替え中、ファクシミリ接続への移行が成功または失敗するまでは受信ゲートウェイは音声チャネルを双方向でミュートにすべきである。この間、受信ゲートウェイは送信ゲートウェイ側及び応答するファクシ
ミリエンドポイントが無音状態であることを確実にすべきである。受信ゲートウェイは、ファクシミリの検出直後にチャネルのミュートを上記の通り開始すべきである。受信ゲートウェイがファクシミリを検出後（または応答するファクシミリエンドポイントにより生成されたＶ．２１プリアンブルの終了後）８００ｍ
ｓ以内に送信ゲートウェイ側への音声チャネルをミュートにすることができなかった場合であっても、受信ゲートウェイは当該音声チャネルをミュートのままにしても良い。ただし、応答するファクシミリエンドポ
イントがＮＳＦ、ＣＳＩ、またはＤＩＳ信号の送信を開始した後にミュートが発生すると、１つまたは双方のファクシミリエンドポイントによるセッションの終了を引き起こす可能性がある。
ファクシミリ送信の終了が検出されると、音声チャネルを再び使用しても良い。あるいは、実装方法によっては音声チャネルをファクシミリチャネルに換えることを選択しても良い。
呼が完了すれば、呼はＳＩＰの BYE コマンドによって切断してもよい。
ＳＩＰ及びＳＤＰシグナリングの例についてはＤ．２．４．２節も参照のこと。

D.2.2.4.3 音声およびファクシミリ間の自動状態遷移
自動状態遷移は下記の条件下においてのみ可能でなければならない。

-

ローカル側とリモート側の双方がＪＴ－Ｔ３８プロトコルをサポートしなければならない。

-

ローカル側とリモート側が事前に特定のＪＴ－Ｔ３８プロトコルの構成（例えばＪＴ－Ｔ３８トランス
ポート変数やＪＴ－Ｔ３８パラメータ設定など）について合意しなければならない。

上記の条件はいずれもＳＩＰメッセージの記述において改訂されたＳＤＰオファー／アンサーを使用することで満たすことができる（Ｄ．２．３．０節を参照のこと）。ＪＴ－Ｔ３８プロトコルは Latent configuration- 60 -

ＪＴ－Ｔ３８

として提供されるものとする。着信者から肯定応答があると、自動状態遷移を許可しても良い。
注 1 ） “Latent”という用語は、今後オーディオからファクスリレーに移行する可能性のあるもの、考えられるものを反映している。
注 2 ） １つ以上のＪＴ－Ｔ３８（Latent）構成がオファー側から指定される可能性がある（例えば、複数の
ＪＴ－Ｔ３８トランスポート能力がサポートされる場合など）。

D.2.2.5 ＪＴ－Ｔ３８およびＶ．３４Ｇ３ファクシミリのサポートおよびＪＴ－Ｔ３８／Ｇ３ファクシミリ
へのフォールバック
D.2.2.5.1 プロブレムステートメント
Ｖ．３４対応ファクシミリ端末とのＪＴ－Ｔ３８に基づくＦｏＩＰセッションをサポートするため、音声、
ファクシミリ、およびデータモデム接続を確立するネットワーク内のゲートウェイはＶ．８で定義される能力（ＣＭ／ＪＭ／ＣＪシーケンスの検出および転送）を持たなければならない。発信および受信ゲートウェ
イの双方がＪＴ－Ｔ３８／Ｖ３４Ｇ３ファクシミリに対応している場合、Ｖ．８ＣＭ／ＪＭ信号内の起呼機能についてのオクテット内に格納されているファクシミリ能力についてのデータを検出した後に、ＪＴ－Ｔ
３８及びＶ．３４Ｇ３へ移行し、１０節に従ってその後の処理を行っても良い。ネットワークがデータモデ
ム同士の接続を（Ｖ．１５０．１に基づくＭｏＩＰモードまたはＶ．１５２に基づくＶＢＤｏＩＰモードのどちらにおいても）サポートしていないことを受信ゲートウェイが把握している場合、受信ゲートウェイは
ＡＮＳａｍ信号の検出後にＪＴ－Ｔ３８モードへの移行を開始しても良い。

D.2.2.5.2 フォールバックシナリオ
一方または両方のゲートウェイがＶ．３４に対応していない場合、ＪＴ－Ｔ３８／Ｇ３セッションへのフォールバックが発生しなければならない。想定されるケースとしては以下の３つがある。

１） Ｖ．３４に対応するファクシミリ装置（発呼側）－ ＪＴ－Ｔ３８／Ｇ３に対応するゲートウェイ — Ｊ
Ｔ－Ｔ３８／Ｇ３に対応するゲートウェイ — Ｖ．３４に対応するファクシミリ装置（被呼側）
２） Ｖ．３４に対応するファクシミリ装置（発呼側） — ＪＴ－Ｔ３８／Ｖ．３４Ｇ３に対応するゲートウェ
イ — ＪＴ－Ｔ３８／Ｇ３に対応するゲートウェイ— Ｖ．３４に対応するファクシミリ装置（被呼側）
３） Ｖ．３４に対応するファクシミリ装置（発呼側） — ＪＴ－Ｔ３８／Ｇ３に対応するゲートウェイ — Ｊ
Ｔ－Ｔ３８／Ｖ．３４Ｇ３に対応するゲートウェイ — Ｖ．３４に対応するファクシミリ装置（被呼側）

上記の全てのケースにおいて、オフフック後、被呼側のファクシミリ装置はＡＮＳａｍ信号を受信ゲート
ウェイ（ＪＴ－Ｔ３８／Ｇ３対応またはＪＴ－Ｔ３８／Ｖ．３４Ｇ３対応）へ送信する。受信ゲートウェイ
はトーンリレーまたは音声帯域データ（ ＲＦＣ４７３３およびＶ．１５２に基づく）によりＡＮＳａｍ信号を送信ゲートウェイへ送る。ＡＮＳａｍ信号を検出すると、発呼側のＶ．３４対応のファクシミリ装置はＶ．
８に基づくＣＭシーケンスを送信し、自身がＶ．３４ファクシミリ及びＧ３ファクシミリの両方に対応していることを知らせる。送信ゲートウェイはこのＣＭシーケンスを検出する。また、送信ゲートウェイは音声
ＣＭ信号を遮断する役割を担う。被呼側のファクシミリ装置が誤ってＪＭ信号の送信を開始してしまうことがないよう、送信ゲートウェイは二つ以上の完全なＣＭシーケンスが受信ゲートウェイ（及び被呼側のファ
クシミリ装置）に送信されることを防ぐものとする。
ＣＭシーケンスが検出・抑制されると、送信ゲートウェイはＳＩＰネゴシエーションを開始し、音声から
ＪＴ－Ｔ３８ファクシミリへ切り替わるようにする。（ＳＤＰ オファー／アンサーモデルを使用して）ＳＩ
Ｐネゴシエーションが行われている間、Ｖ．３４対応モデムの能力交換が T38ModemType パラメータを用いて行われる（Ｄ．２．１．３．１節を参照のこと）。

- 61 -

ＪＴ－Ｔ３８

注）Ｖ．８に基づくオーディオのＣＭシーケンスを抑制する必要がある可能性がある。ただし、そのための方法および手順については将来の課題である。

-

上記のケース１およびケース２におけるコールフローを付図Ｄ．２／ＪＴ－Ｔ３８に示す。これらのケースにおいて、送信ゲートウェイはＪＴ－Ｔ３８／Ｇ３のみに対応するゲートウェイである。Ｖ．８に基づくＣＭシーケンスが検出されると直ちに、当該ゲートウェイはＳＩＰ／ＳＤＰネゴシエーションの結果を待たずにＧ３ファクシミリのみに対応することを表明するＪＭ信号を発呼側のファクシミリ
装置に送信することができる。

-

上記のケース３におけるコールフローは付図Ｄ．３／ＪＴ－Ｔ３８に示される。この場合、送信ゲート
ウェイはＪＴ－Ｔ３８／Ｖ．３４Ｇ３＋電送プロトコルとＪＴ－Ｔ３８／Ｇ３の両方を採用したゲートウェイである。Ｖ．８に基づくＣＭシーケンスが検出されると、送信ゲートウェイは（ＪＴ－Ｔ３８構
成の再ネゴシエーションのために、ＳＤＰオファー／アンサーモデルを使用して）ＳＩＰの ReInvite
要求の送信を開始し、ＪＴ－Ｔ３８チャネルを確立する。送信ゲートウェイはＳＩＰ／ＳＤＰネゴシ
エーションが完了するまで受信ゲートウェイがどの変調方式をサポートしているのか分からないため、送信ゲートウェイはＳＩＰ／ＳＤＰネゴシエーションの終了後に発呼側ファクシミリ装置にＪＭ信号を送信する。送信ゲートウェイはネットワークがＧ３ファクシミリのみをサポートする旨を通知するた
め、発呼側ファクシミリ装置にＶ．８に基づくＪＭ信号を送信しなければならない。

ネットワークがＧ３ファクシミリのみをサポートする旨のＪＭ信号を受信した後、発呼側のファクシミリ装置はＣＪシーケンスを送信して応答し、Ｖ．８に定められているセッション開始手順を終了するとともに、標準Ｇ３ファクシミリに自身を適応させる（ＪＴ－Ｔ３０の付図Ｅ－１０を参照のこと）。その後、被呼側のＶ．３４ファクシミリ装置でＡＮＳａｍタイムアウトが生じた後に、ＦｏＩＰセッションはＪＴ－Ｔ３８／Ｇ３モードにフォールバックする（ＪＴ－Ｔ３０の図３－５ａを参照のこと）。
ＣＭシーケンスが検出・抑制された後、送信ゲートウェイは音声からＪＴ－Ｔ３８ファクシミリに移行するためにＳＩＰネゴシエーションを開始する。ＳＩＰネゴシエーションの実施中、Ｖ．３４に対応するモデムの能力交換が T38ModemType パラメータを用いて行われる（Ｄ．２．１．３．１節を参照のこと）。

-

上記のケース１およびケース２におけるコールフローを付図Ｄ．２／ＪＴ－Ｔ３８に示す。これらのケースにおいて、送信ゲートウェイはＪＴ－Ｔ３８／Ｇ３のみに対応するゲートウェイである（ＳＤＰ
オファー／アンサーモデルにおけるＳＤＰオファー側の役割を果たす）。Ｖ．８に基づくＣＭシーケンスが検出されると直ちに、送信ゲートウェイはＳＩＰ／ＳＤＰネゴシエーションの結果（これは最終的に認知されたＳＤＰアンサーでなければならない）を待たずにＪＭ信号を発呼側ファクシミリ装置に送信し、自身がＧ３ファクシミリのみをサポートする旨を通知することができる。

-

ケース３のコールフローは付図Ｄ．３／ＪＴ－Ｔ３８に示される。このケースにおいて、送信ゲートウェ
イはＪＴ－Ｔ３８／Ｖ．３４Ｇ３＋ＪＴ－Ｔ３８／Ｇ３の両方を採用したゲートウェイである。Ｖ．８に基づくＣＭシーケンスが検知されると、送信ゲートウェイは（ＪＴ－Ｔ３８構成の再ネゴシエーションのために、ＳＤＰオファー／アンサーモデルを使用して）ＳＩＰの ReInvite 要求の送信を開始し、Ｊ
Ｔ－Ｔ３８チャネルを確立する。ＳＩＰ／ＳＤＰネゴシエーションが完了するまで受信ゲートウェイがどの変調方式をサポートしているのか分からないため、送信ゲートウェイはＳＩＰ／ＳＤＰネゴシエー
ションの終了後に発呼側ファクシミリ装置にＪＭ信号を送信する。送信ゲートウェイはネットワークがＧ３ファクシミリのみをサポートする旨を通知するため、発呼側ファクシミリ装置にＶ．８に基づくＪ
Ｍ信号を送信しなければならない。

- 62 -

ＪＴ－Ｔ３８

ネットワークがＧ３ファクシミリのみをサポートする旨のＪＭ信号を受信した後、発呼側のファクシミリ装置はＣＪシーケンスを送信して応答しＩＴＵ－Ｔ Ｖ．８に定められているセッション開始手順を終了するとともに、標準Ｇ３ファクシミリに自身を適応させる（ＪＴ－Ｔ３０の付図Ｆ－５～Ｆ－１０を参照のこと）。
その後、被呼側のＶ．３４対応ファクシミリ装置でＡＮＳａｍタイムアウトが生じた後に、ＦｏＩＰセッショ
ンはＪＴ－Ｔ３８／Ｇ３モードにフォールバックする（ＪＴ－Ｔ３０の図６ａを参照のこと）。

Voice to fax transition with SIP : Fallback to G3 from V.34 FAX
V.34FD1

GW2:JT-T38/V.34
or JT-T38/G3

GW1:JT-T38/G3

V.34FD2

OFF HOOKDIALING
Call setup via PSTN and SIP server
Voice mode
CNG

Tone relay or tone event or
JT-G711:CNG
Tone relay or tone event or
JT-G711:ANSam

CNG
ANSam

ANSam
V.8 CM (V.34 + G3 fax)
V.8 CM (G3 fax only)

Suppress V.8 CM
SIP : REINVITE
SIP : 200 OK
SIP : ACK

V.8 CJ
JT-T38/G3 mode
ANSam
CED

T30 IND : CED

ANSam Timeout
V.21 Flags

V.21 Flags
V.21 CSI/DIS
V.21 Flags

T30 IND : Flags
V.21 HDLC : CSI/DIS

T30 IND : Flags
V.21 Flags

V.21 TSI/DCS
V.21 HDLC : TSI/DCS

付図Ｄ．２／ＪＴ－Ｔ３８

V.21 CSI/DIS

V.21 TSI/DCS

ＳＩＰ呼設定（Ｖ．３４ファクシミリからＧ３へのフォールバック）
送信ゲートウェイはＧ３のみサポート（ＩＴＵ－Ｔ

Ｔ．３８）- 63 -

ＪＴ－Ｔ３８

Voice to fax transition with SIP : Fallback to G3 from V.34 FAX
GW1:JT-T38/V.34
or JT-T38/G3

V.34FD1

GW2:JT-T38/G3

V.34FD2

OFF HOOKDIALING
Call setup via PSTN and SIP server
Voice mode
CNG

Tone relay or tone event or
JT-G711:CNG
Tone relay or tone event or
JT-G711:ANSam

CNG
ANSam

ANSam
V.8 CM (V.34 + G3 fax)
Suppress V.8 CM
SIP : REINVITE(T38Modulationtype=0, V.34+G3)
SIP : 200 OK(T38Modulation type=2, G3 only)
V.8 CM (G3 fax only)
SIP : ACK
V.8 CJ
JT-T38/G3 mode
ANSam
CED

T30 IND : CED

ANSam Timeout
V.21 Flags

V.21 Flags
V.21 CSI/DIS
V.21 Flags

T30 IND : Flags
V.21 HDLC : CSI/DIS

T30 IND : Flags
V.21 Flags

V.21 TSI/DCS
V.21 HDLC : TSI/DCS

付図Ｄ．３／ＪＴ－Ｔ３８

V.21 CSI/DIS

V.21 TSI/DCS

ＳＩＰ呼設定（Ｖ．３４ファクシミリからＧ３へのフォールバック）
受信ゲートウェイはＧ３のみサポート（ＩＴＵ－Ｔ

Ｔ．３８）

D.2.3 能力ネゴシエーション
ゲートウェイがどのオプションをサポートし使用するかを決めるためにネゴシエーションする必要のある能力がある。これらは付表Ｂ．１／ＪＴ－Ｔ３８に記述される。
ＲＦＣ２３２７のセッション記述プロトコル（ＳＤＰ）は、ＳＩＰのためのセッションを記述するメカニ
ズムを提供する。ＪＴ－Ｔ３８メディアストリームの開始時点で、交渉できるＪＴ－Ｔ３８特有のパラメータがある。歴史的な理由で、ＵＤＰＴＬ／ＴＣＰトランスポートとＴＰＫＴ／ＴＣＰトランスポートはＲＴ
Ｐ／ＵＤＰトランスポートと区別して実行される。

- 64 -

ＪＴ－Ｔ３８

D.2.3.0 ＪＴ－Ｔ３８構成の表示とネゴシエーションのためのＳＤＰオファー／アンサープロトコル

ＳＩＰメッセージは、ＪＴ－Ｔ３８ 構成の表示とネゴシエーションのためのＳＤＰオファーを提供しなけ
ればならない。特に、ＪＴ－Ｔ３８に関するその利点のために（複数のＪＴ－Ｔ３８トランスポート変数などによる、オーディオへの潜在的なパラレルメディア構成として、または、スピーチ呼フェーズ後の可能性のある後構成として）、「改訂されたＳＤＰオファー／アンサー」プロトコル（５．１．１節参照）はサポー
トされるべきであり、その利点のため推奨される。
“レガシーなＳＤＰオファー／アンサー”プロトコル（５．
１．１節参照）は、限定されたＪＴ－Ｔ３８サービスを許可する、最小限の解決策として使用しても良い（例えば、可能な複数のＳＤＰ オファー／アンサーサイクルによる呼設定の遅延の増加（注１）、自動遷移方式がサポートされていないなど）。

注１）例えば、ＪＴ－Ｔ３８のひとつの「m=」行の中で、同じＪＴ－Ｔ３８トランスポート変数に対して複数のＪＴ－Ｔ３８パラメータ設定（すなわち、複数のＪＴ－Ｔ３８構成）を定義することはできない。

D.2.3.1 ＵＤＰＴＬ／ＵＤＰとＴＰＫＴ／ＴＣＰトランスポートのネゴシエーション
ＵＤＰＴＬかＴＣＰトランスポートを使用するとき、本標準をサポートするために新しい属性（ＳＤＰの６章（ＲＦＣ２３２７））が要求される。下記に定義されたその属性は、ＵＤＰＴＬまたはＴＣＰのトラン
スポートのどちらかによるＪＴ－Ｔ３８の利用が規定され、ＲＴＰ（Ｄ．２．３．２節）によるＪＴ－Ｔ３
８の利用を適用してはならないことに注意すること。特に、ＳＤＰ（ＲＦＣ２３２７）の付属資料Ｂに注記している手続きによって、有効な att-field および att-value としてオプションがＩＡＮＡで登録される。値のないオプションはブーリアン論理型であることに注意する必要がある。これはセッションで有効であることを示す。この能力は、本標準で使用するために定義された次のＡＢＮＦ要素を使用してネゴシエーションされる。

VersionAtt-field=T38FaxVersion
Att-value = 1*(DIGIT); ５章 ＪＴ－Ｔ３８ＡＳＮ．１ バージョン番号表を参照：; バージョン０（デフォルト）; バージョン１; バージョン２; バージョン３; バージョン４

Maximum Bit Rate
Att-field=T38MaxBitRate
Att-value = 1*(DIGIT)

Fill Bit Removal
Att-field=T38FaxFillBitRemoval

MMR Transcoding
Att-field=T38FaxTranscodingMMR

JBIG Transcoding
Att-field=T38FaxTranscodingJBIG

Data Rate Management Method
Att-field=T38FaxRateManagement
Att-value = localTCF | transferredTCF

UDPTL Options
Maximum Buffer Size
Att-field=T38FaxMaxBuffer
Att-value = 1*(DIGIT);オプション- 65 -

ＪＴ－Ｔ３８

Maximum Datagram Size
Att-field=T38FaxMaxDatagram
Att-value = 1*(DIGIT);オプション

Maximum Primary IFP Size
Att-field=T38FaxMaxIFP
Att-value = 1*(DIGIT)

Error Correction
Att-field=T38FaxUdpEC
Att-value = t38UDPNoEC | t38UDPFEC | t38UDPRedundancy

Error Correction Depth
att-field = T38FaxUdpECDepth
att-value = minred [ SP maxred ]minred = 1*(DIGIT)
maxred = 1*(DIGIT)

Error Correction Span
att-field = T38FaxUdpFECMaxSpan
att-value = 1*(DIGIT)

T38VendorInfo
Att-field=T38VendorInfo
Att-value = t35country-code SP t35extention SP manufacturer-code
t35country-code = 1*(DIGIT)
t35extension = 1*(DIGIT)
manufacturer-code = 1*(DIGIT);オプション;t35country-code と t35extension に対して０から２５５;t35country-code は、Ｔ．３５の付属資料Ａに定義する。
;t35extension は、Ｔ．３５の付属資料Ｂに定義する。
;manufacturer-code の値は国ごとに割り振られ、;装置製造者を識別する。
;例 a=T38VendorInfo:0 0 37

D.2.3.2 ＲＴＰ／ＵＤＰのネゴシエーション"audio/T38" の MIME type 登録は 、ＲＴＰによるＪＴ－Ｔ３８で使用され手も良いいくつかのオプションパ
ラメータを定義する。これらのパラメータは、ＳＤＰで定義された"a=fmtp" パラメータを使用した"parameter"か "parameter=value" の一対がセミコロンで区切られ一覧で提供される。ＡＢＮＦパラメータ形式は、存在が"true" で欠如が "false"に等しいブーリアン論理値が使用される。このパラメータ定義をここに再掲する。

Version
Name=T38FaxVersion
Value= 1*(DIGIT); ５章 ＪＴ－Ｔ３８ＡＳＮ．１ バージョン番号表を参照：; バージョン０（デフォルト）; バージョン１; バージョン２; バージョン３; バージョン４

Maximum Bit Rate
Name=T38MaxBitRate
Value= 1*(DIGIT)

Fill Bit Removal
Name=T38FaxFillBitRemoval;論理型

MMR Transcoding
Name=T38FaxTranscodingMMR;論理型

JBIG Transcoding- 66 -

ＪＴ－Ｔ３８Name=T38FaxTranscodingJBIG;論理型

Data Rate Management Method
Name=T38FaxRateManagement
Value = "localTCF" | "transferredTCF"

Maximum Buffer Size
Name=T38FaxMaxBuffer
Value = 1*(DIGIT);オプション

Maximum Datagram Size
Name=T38FaxMaxDatagram
Value = 1*(DIGIT);オプション

Maximum Primary IFP Size
Name = T38FaxMaxIFP
Value = 1*(DIGIT)

T38VendorInfo
Name =T38VendorInfo
Value = t35country-code SP t35extention SP manufacturer-code
t35country-code = 1*(DIGIT)
t35extension = 1*(DIGIT)
manufacturer-code = 1*(DIGIT);オプション; t35country-code と t35extension に対して０から２５５;t35country-code は、Ｔ．３５の付属資料Ａに定義する。
;t35extension は、Ｔ．３５の付属資料Ｂに定義する。
;manufacturer-code の値は国ごとに割り振られ、;装置製造者を識別する。
;例 a= fmtp:100 T38VendorInfo:0 0 37 ここで 100 はダイナミックペイロードタイプ値
注）ＲＴＰ冗長性を使った本標準で定義されたエラー訂正は無く、ＲＦＣ２１９８とＲＦＣ５１０９で定義されたＳＤＰの使用に関連したＲＴＰペイロードでＦＥＣは宣言できる。

D.2.3.3 ＳＤＰでのＪＴ－Ｔ３８の宣言
ＳＤＰでの image/t38 の MIME コンテントタイプは本標準を示す。
この選択は、ＪＴ－Ｔ３７で使用される image/tiff、およびＸ．４２０で使用された image/g3fax と矛盾しない。

D.2.3.4 ＴＣＰあるいはＵＤＰのいずれかの使用
2 つの論理チャネル(送信側から受信側へのチャネル及び受信側から送信側へのチャネル)が、ＪＴ－Ｔ３８
パケットの転送のために開かれなければならない。ＪＴ－Ｔ３８パケットはＴＣＰあるいはＵＤＰのいずれかを使用して転送することができる。一般に、ファクシミリ通信用の帯域幅が制限された場合、あるいはＴ
ＣＰがフロー制御を提供するのでＩＡＦからＩＡＦへの転送にとってはＴＣＰの使用法はより効果的である。他方では、ファクシミリ通信用の帯域幅が十分な場合は、ＵＤＰの使用法がより有効かもしれない。
ＳＩＰ呼設定中に、ＳＩＰの INVITE のＳＤＰ中のその最適な 1 番目のリストにより、発呼側がトランスポート(ＴＣＰまたはＵＤＰ)を示唆することに注意する必要がある。受信側は、送信側の優先権に基づいた
ＴＣＰ／ＵＤＰポートを開くべきであるが、それは受信側が決定する。

ＳＤＰ拡張のＵＤＰまたはＴＣＰトランスポートのＪＴ－Ｔ３８選択をサポートするうえで-有効なトランスポート値（第３のフィールド）としてＵＤＰＴＬ（ファクシミリユーザデータグラムプ
ロトコルトランスポート層）を示すこと。

-

有効なトランスポート値（第３のフィールド）としてＴＣＰ（送信制御プロトコル）を示すこと。
- 67 -

ＪＴ－Ｔ３８-

有効なトランスポート値（第３のフィールド）としてＲＴＰ／ＡＶＰ（Real Time Protocol/Audio-Video
Profile）を示すこと。

-

有効なトランスポート値（第３のフィールド）としてＲＴＰ／ＳＡＶＰ（Real Time Protocol/Secure
Audio-Video Profile）を示すこと。

-

有効なトランスポート値（第３のフィールド）として他のＲＴＰ プロファイル（すなわちＡＶＰＦとＳＡＶＰＦ）を示すこと。

-

有効なフォーマットタイプ値（第４のフィールド）として t38 を含めること。トランスポート値がＵＤ
ＰＴＬ かＴＣＰ のとき、この値が使用される。

-

有効なフォーマットタイプ値（第４のフィールド）としてＲＴＰペイロードタイプを含めること。トランスポート値がＲＴＰ／ＡＶＰかＲＴＰ／ＳＡＶＰのとき、この値が使用される。このペイロードタイプは 'rtpmap' 属性を通してＭＩＭＥタイプ の"audio/t38"に対応される。

トランスポート層がＲＴＰのとき、パケット冗長性（ＲＦＣ２１９８） とＦＥＣ保護（ＲＦＣ５１０９）のため標準ＲＴＰ機構 が使用され手も良い。ＳＤＰでのこれらの機構の宣言は、ＲＦＣ２１９８とＲＦＣ
５１０９に記載されている。

注） t38 がＲＴＰに定義された値でないので、それはメディアタイプのＭＩＭＥサブタイプでなければならない。その結果、ＳＤＰ（ＲＦＣ２３２７）の付属資料Ｂに注記した手続きに関するプロトタイプの有効なＭＩＭＥコンテンツタイプとしてＩＡＮＡで audio/t38 の登録を定義するためＩＥＴＦのＲＦＣ４６
１２が出版された。

D.2.3.5 ＳＩＰ／ＳＤＰ オファー／アンサーのネゴシエーションにおけるＳＤＰパラメータの使用法
この節（付属資料Ｈのサマリーも参照）では、ＳＩＰ／ＳＤＰオファー／アンサーモデルが利用されるときの、ＪＴ－Ｔ３８ＳＤＰパラメータの使用法を記述する。

T38MaxBitRate は宣言型であり、アンサーはオファーに依存しない。パラメータは、単にエンドポイントによってサポートされる最大伝送ビットレートを示している。

T38FaxFillBitRemoval はネゴシエーションされる。応答する実際の機器が、この能力をサポートしないか、またはオファーに能力が存在しないならば、このパラメータは、アンサーに存在してはならない。
注１）上記の場合、セマンティックな‘false’に従って、デフォルトのふるまいが適用される。

T38FaxTranscodingMMR はネゴシエーションされる。応答する実際の機器が、この能力をサポートしない
か、またはオファーに能力が存在しないならば、このパラメータは、アンサーに存在してはならない。
注２）上記の場合、セマンティックな‘false’に従って、デフォルトのふるまいが適用される。

T38FaxTranscodingJBIG はネゴシエーションされる。応答する実際の機器が、この能力をサポートしないか、またはオファーに能力が存在しないならば、このパラメータは、アンサーに存在してはならない。
注３）上記の場合、セマンティックな‘false’に従って、デフォルトのふるまいが適用される。

T38FaxRateManagement は宣言型であり、アンサーは同じ値を含まなければならない。

T38FaxVersion はネゴシエーションされる。オファーに応答する実際の機器は同じか、またはそれより低い- 68 -

ＪＴ－Ｔ３８バージョン番号を返さなければならない。

T38FaxMaxBuffer は宣言型であり、アンサーはオファーに依存しない。このパラメータは、単にオファーのエンドポイントとアンサーのエンドポイントの有効なバッファスペースを知らせる。アンサーのエンドポイ
ントは、オファーのエンドポイントより多いか、あるいは少ないバッファスペースを持っていてもよい。それぞれのエンドポイントは、相手のエンドポイントの有効なバッファスペースを考慮すべきである。

T38FaxMaxDatagram は宣言型であり、アンサーはオファーに依存しない。このパラメータは、オファーのエンドポイントとアンサーのエンドポイントのための、もっとも大きい受け入れることができるデータグラ
ムを通知する（すなわち、ＲＴＰペイロードの最大サイズ）。アンサーのエンドポイントは、オファーのエ
ンドポイントより大きいか、あるいは小さいデータグラムを受け入れてもよい。それぞれのエンドポイント
は、相手のエンドポイントの最大データグラムサイズを考慮すべきである。。オファーが T38FaxMaxIFP
パラメータを含む場合、このパラメータも同様に含まれなければならない。

T38FaxMaxIFP は宣言型であり、アンサーはオファーに依存しない。このパラメータは、フレーミング、エラー訂正、または、その他のオーバーヘッドを除いて、オファーのエンドポイントが受け入れることのできる最大のＩＦＲフレームサイズを知らせる。応答側は、提示側よりも大きい、または小さい、最大のＩＦＰ
サイズを指定しても良い。それぞれのエンドポイントは、相手側のエンドポイントに指定された最大のＩＦ
Ｐサイズを考慮すべきである。このパラメータがオファーに含まれている場合は、T38FaxMaxDatagram パラ
メータも同様にオファーに含まれなければならない。

T38FaxUdpEC は、トランスポートとしてＵＤＰＴＬが使われるときだけ、ネゴシエーションされる。
（注１）。このパラメータは t38UDPNoEC、t38UDPRedundancy、t38UDPFEC の３つの値のいずれかひとつを持つことができる（付表Ｄ．２／ＪＴ－Ｔ３８参照）。アンサーのエンドポイントが、オファーされたエラー訂正モードをサポートする場合、アンサーでは同じ値を返さなければならない。そうでない場合は、異なる値が返されなければならない。この能力交換に基づいて、以下の表の通りにエラー訂正のためにどのス
キームを使用するかの選択がされて良い。

付表Ｄ．２／ＪＴ－Ｔ３８ ＳＤＰパラメータ「T38FaxUdpEC」の値範囲（ＩＴＵ－Ｔ

Ｔ．３８）

T38FaxUdpEC

説明

t38UDPNoEC

セカンダリＩＰＦパケットは送信されない。ＵＤＰＴＬにおけるセカンダリメッ
セージの数は 0 に設定される。

t38UDPRedundancy

冗長なエラー訂正メッセージのみが送信されて良い。

t38UDPFEC

エンドポイントは冗長スキームまたはＦＥＣエラー訂正スキームのどちらかを使うことができる。
（注－この記載は、９．１．３節に準ずる。）

注４）複数のＪＴ－Ｔ３８エラー訂正スキームの宣言は、改訂されたＳＤＰオファー／アンサー（５．１．
１節参照）の場合は単一のＳＤＰオファー／アンサーサイクルで可能だが、レガシーのＳＤＰオファー／アンサーの場合は複数のＳＤＰオファー／アンサーサイクルで可能であることを意味している。
（同じＪＴ－Ｔ３８ＳＤＰ属性が複数回表示されることがなくなるかもしれないからである。）- 69 -

ＪＴ－Ｔ３８

T38FaxUdpECDepth は宣言型であり、アンサーはオファーに依存しない。また、ＵＤＰＴＬをトランスポー
トとして使用する時にのみ関係する。このパラメータが指定される場合、「minred」値はオファーのエンド
ポイントが受信を望むＵＤＰＴＬデータグラムあたりの最小冗長フレーム数を示す（アンサーのエンドポイ
ントが t38UDPRedundancy のエラー訂正モードの使用を選択した場合）。または、オファーのエンドポイン
トが望むＵＤＰＴＬデータグラムあたりの最小ＦＥＣフレーム数を示す（アンサーのエンドポイントがt38UDPFEC のエラー訂正モードの使用を選択した場合）。
さらに、「maxred」値が指定される場合、オファーのエンドポイントがＵＤＰＴＬデータグラムあたりの指定された数以下の冗長フレーム、または ＦＥＣフレームの受信を望むことを示す。応答側は、提示側が指定した最小または最大のエラー訂正スパンよりも大きいまたは小さい値を指定しても良い。それぞれのエンドポイントは、反対側のエンドポイントが指定した最小及び最大エラー訂正スパンを考慮するべきである。

T38FaxUdpFECMaxSpan は宣言型であり、アンサーはオファーに依存しない。また、ＵＤＰＴＬをトラン
スポートとして使用する時にのみ関係する。パラメータが指定される場合、オファーのエンドポイントが指定された数以上のＩＦＰフレームの範囲に及ぶＦＥＣフレームを正しく処理することができないかもしれないことを示す。また、アンサーのエンドポイントが指定された数以上のＩＦＰフレームの範囲に及ぶＦＥ
Ｃフレームを生成した場合、オファーのエンドポイントは、それらを無視するしかないかもしれない（結果、
有効なセッションのエラー訂正がされなくなる）。応答側は提示側よりも大きいもしくは小さい最大の範囲を指定してもよい。それぞれのエンドポイントは、反対側のエンドポイントが指定した最大の範囲を考慮するべきである。

T38VendorInfo は宣言型であり、アンサーはオファーに依存しない。パラメータは、エンドポイントの製造者を示しているだけである。

T38ModemType はネゴシエーションされる。パラメータがＳＩＰ／ＳＤＰネゴシエーションに存在しない場
合、グループ３のファクシミリのみ（t38G3FaxOnly）が想定される。

D.2.4 呼設定の例
D.2.4.1 ファクシミリのみの呼におけるＳＩＰの INVITE
デフォルトの場合は、ＴＣＰおよびＵＤＰの両方のサポートが要求される。ＵＤＰＴＬまたはＲＴＰのカ
プセル化方法は、ＵＤＰトランスポートに関連して使用して良い。この場合、優先される方を INVITE 中で１番目として２行の「m=」ラインがリストされる。メディア接続の拒否は、応答でポート番号が０に設定され示される（レガシーＳＤＰオファー／アンサーの場合）。

D.2.4.1.1 例１）ＵＤＰＴＬ／ＵＤＰ上のＪＴ－Ｔ３８に関する合意、提供される複数トランスポート変数
ＪＴ－Ｔ３８ゲートウェイの２者間のファクシミリのみの呼の場合、ＵＤＰトランスポートプロトコルと
ＵＤＰＴＬカプセル化を併用すると、次のようになる。

- 70 -

ＪＴ－Ｔ３８

付表Ｄ．３／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－レガシーのＳＤＰオファー／アンサー構文の例１（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＩＰ／ＳＤＰコード
1) オファー (SIP INVITE における):
C->S: INVITE sip:+1-212-555-1234@bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
Cseq: 1 INVITE
Subject: Mr. Watson, here is a fax
Content-Type: application/sdp
Content-Length: …
v=0
o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
e=+1-212-555-1234@bell-tel.com
t=2873397496 0c=IN IP4 128.59.19.68
m=image 49170 udptl t38
a=T38FaxRateManagement=transferredTCF
a=T38FaxUdpEC:t38UDPFEC
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF
2) アンサー (SIP 200 OK における):
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
Cseq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: …
v=0
o=faxwatson 4858949 4858949 IN IP4 192.1.2.3
c=IN IP4 boston.bell-tel.com
m=image 5002 udptl t38
a=T38FaxRateManagement=transferredTCF
a=T38FaxUdpEC:t38UDPFEC
m=image 0 tcp t38

コメント
オファー側は、下記２つのＪＴ－Ｔ３８ 構成をサポートしている。
・ＵＤＰＴＬ／ＵＤＰによるＪＴ－Ｔ３８
および・ＴＰＫＴ／ＴＣＰによるＪＴ－Ｔ３８（注）オファー側はＪＴ－Ｔ３８ パラメータを提供しているが、すべてではない。ＪＴ－Ｔ３８ 構成設定の曖昧さをなくすために、すべてのＪＴ－Ｔ３８パラメータを明示的に通知することを推奨する。

アンサー側は、（ＳＤＰ null ポートセマン
ティックを通じて）ＴＰＫＴ／ＴＣＰ オプ
ションを拒否し、ＵＤＰＴＬ／ＵＤＰトラン
スポートを受け入れる。

付表Ｄ．４／ＪＴ－Ｔ３８は、改訂されたＳＤＰオファー／アンサー構文における例１のコードを示す（ＳＩＰヘッダーラインを除いてＳＤＰ構文のみ記述）。

- 71 -

ＪＴ－Ｔ３８

付表Ｄ．４／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－改訂されたＳＤＰオファー／アンサー構文の例１（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＤＰコード（省略したＳＤＰ記述）
1) オファー (SIP INVITE に組み込まれた):…
; ACTUAL CONFIGURATION (due to backward compatibility)m=image 49170 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF;; POTENTIAL CONFIGURATIONs
a=tcap:1 udptl ; ITU-T T.38 FoUDPTL/UDP transport variant
a=tcap:2 tcp ; ITU-T T.38 FoTPKT/TCP transport variant
a=mcap:1 t38 ; ITU-T T.38 FoIP codec (subtype = 't38'); Transport-independent ITU-T T.38 parameters
a=acap:11 T38FaxVersion:4; Transport-dependent ITU-T T.38 parameters for UDPTL/UDP
a=acap:12 T38FaxUdpEC:t38UDPFEC
a=acap:13 (… additional ITU-T T.38 UDPTL attributes
should be included); Transport-dependent ITU-T T.38 parameters for TPKT/TCP
a=acap:21 T38FaxRateManagement:localTCF
a=acap:22 (… additionalITU-T T.38 TPKT attributes should
be included); Preferences
a=pcfg:1 t=1 m=1 a=-ms:11,12,13,14,…
a=pcfg:2 t=2 m=1 a=-ms:11,21,…

コメント
下記の２つのPOTENTIAL CONFIGURATIONが提示された:選択 1: ＪＴ－Ｔ３８ＦｏＵＤＰＴＬ／ＵＤ
Ｐ
選択 2: ＪＴ－Ｔ３８ＦｏＴＰＫＴ／ＴＣＰ
注）POTENTIAL CONFIGURATION("a=pcfg:") におけるメディアタイプは
ACTUAL CONFIGURATION (すなわち、ここでは 'image')と同一である。

アンサー側はＵＤＰＴＬ／ＵＤＰトランス
ポートと関連するパラメータ設定に同意する。

2) アンサー (SIP 200 OK に組み込まれた):…
a=acfg:1

改訂ｖｓレガシーのＳＤＰオファー／アンサーに関して、次の主な利点が注目されるかもしれない。
-

メディア構成を拒否するには、“null ポート” セマンティックは必要ない。

-

提供されるメディア構成に関して優先順位が明白に示されている-

レガシーのＳＤＰオファー／アンサーにおけるアンサー側は、主にＪＴ－Ｔ３８ 構成の両方の設定を選択できる（後続のオファー／アンサーサイクルが必要な場合がある）。

D.2.4.1.2 例２）ＲＴＰ前方エラー訂正を伴うＲＴＰ／ＵＤＰ上のＪＴ－Ｔ３８に関する合意
ＪＴ－Ｔ３８ゲートウェイの２者間のファクシミリのみの呼の場合、ＲＴＰカプセル化をＵＤＰトランス
ポートプロトコルと併用すると、次のようになる。

- 72 -

ＪＴ－Ｔ３８

付表Ｄ．５／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－レガシーのＳＤＰオファー／アンサー構文の例２（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＩＰ／ＳＤＰコード

コメント

1) オファー (SIP INVITE における):
C->S: INVITE sip:+1-212-555-1234@bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
Cseq: 1 INVITE
Subject: Mr. Watson, here is a fax
Content-Type: application/sdp
Content-Length: …
v=0
o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
e=+1-212-555-1234@bell-tel.com
t=2873397496 0c=IN IP4 128.59.19.68
m=audio 49170 RTP/AVP 100 101
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=rtpmap:101 parityfec/8000
a=fmtp:101 49173 IN IP4 128.59.19.68
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF
2) アンサー (SIP 200 OK における):
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
Cseq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: …
v=0
o=faxwatson 4858949 4858949 IN IP4 192.1.2.3
c=IN IP4 boston.bell-tel.com
m=audio 5002 RTP/AVP 100 101
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=rtpmap:101 parityfec/8000
a=fmtp:101 5004 IN IP4 192.1.2.3
m=image 0 tcp t38

この例は、ＲＦＣ５１０９のＲＴＰメディアストリームとして定義された前方エラー訂正（ＦＥＣ）を示す。
この場合、分離されたＵＤＰポートはＦＥＣストリームに配置される。ＦＥＣに関連してＲＦＣ２１９８のカプセル化が使用された場合では、この例のＳＤＰ記述はＲＦＣ５１０９に従った修正が必要である。
セキュアＲＴＰのためには、「m=」の行で第３フィールド（トランスポートプロトコル）は、ＲＴＰ／ＡＶ
Ｐ よりＲＴＰ／ＳＡＶＰ とすべきである。

付表Ｄ．５／ＪＴ－Ｔ３８は、改訂されたＳＤＰオファー／アンサー構文における例２のコードを示す（ＳＩＰヘッダーラインを除いてＳＤＰ構文のみ記述）。

- 73 -

ＪＴ－Ｔ３８

付表Ｄ．５ｒ／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－改訂されたＳＤＰオファー／アンサー構文の例２（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＤＰコード（省略したＳＤＰ記述）
1) オファー (SIP INVITE に組み込まれた):…
; ACTUAL CONFIGURATION (due to backward compatibility)
m=audio 49170 RTP/AVP 100 101
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=rtpmap:101 parityfec/8000
a=fmtp:101 49173 IN IP4 128.59.19.68
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF;; POTENTIAL CONFIGURATIONs
a=tcap:1 RTP/AVP ; ITU-T T.38 FoRTP/UDP transport variant
a=tcap:2 tcp ; ITU-T T.38 FoTPKT/TCP transport variant
a=mcap:1 t38 ; ITU-T T.38 FoIP codec (subtype = 't38'); Transport-independent ITU-T T.38 parameters
a=acap:11 T38FaxVersion:4; Transport-dependent ITU-T T.38 parameters for RTP/UDP
a=mcap:2 parityfec/8000 ; Forward Error Correction
a=mfcap:2 T38FaxRateManagement=transferredTCF
a=mfcap:2 49173 IN IP4 128.59.19.68
a=acap:12 (… additional ITU-T T.38 RTP attributes should
be included, if required); Transport-dependent ITU-T T.38 parameters for TPKT/TCP
a=acap:21 T38FaxRateManagement:localTCF
a=acap:22 (… additional ITU-T T.38 TPKT attributes should
be included); Preferences
a=pcfg:1 t=1 m=1,2 pt=1:100,2:101 a=-ms:11,…
a=pcfg:2 t=2 m=1 a=-ms:11,21,22,…

コメント
下記の２つのPOTENTIAL CONFIGURATIONがオファーされた:•優先 1: ＪＴ－Ｔ３８ＦｏＲＴＰ／ＵＤＰ包括的前方エラー訂正（ＦＥＣ）方式•優先 2: ＪＴ－Ｔ３８ＦｏＴＰＫＴ／ＴＣＰ

アンサー側はＲＴＰ／ＵＤＰトランスポートと関連するパラメータ設定に同意する。

2) アンサー (SIP 200 OK に組み込まれた):…
a=acfg:1＜ＴＴＣ注：原文は例２のレガシーのＳＤＰオファー／アンサー構文と改定版のＳＤＰオファー／アンサー
構文が共に TableD.5 が付されているが、識別のため付表Ｄ．５と付表Ｄ．５ｒをそれぞれ付した。＞

D.2.4.2 音声およびファクシミリ呼タイプのＳＩＰの INVITE
D.2.4.2.1 音声／ファクシミリ呼タイプのための改訂されたＳＤＰオファー／アンサー
音声およびファクシミリの呼はデュアルステートモデル(Ｄ．２．２．４．１節)を表し、Ｄ．２．２．４節にしたがって、常にオーディオモードで開始されなければならない。 ファクスリレーモードへの可能な遷移
はその呼の有効期間内における後の段階（呼の確立が成功したあとに）において行われる。そのため、オファー側とアンサー側の間で、少なくとも２つのメディア構成がネゴシエーションされる。しかしながら、ファクスリレーモードは、デュアルステートモデルにおいて、 potential configurationと、さらに latentconfiguration（後の使用による）を表している。
したがって、改訂されたＳＤＰオファー／アンサーは、このような構成概念のサポートにより、このようなネゴシエーションのために使用されなければならない。

- 74 -

ＪＴ－Ｔ３８

D.2.4.2.2 例３）ＪＴ－Ｇ７１１オーディオおよびＪＴ－Ｔ３８のためのＲＴＰパケット冗長を有するＲＴ
Ｐ／ＵＤＰ上のＪＴ－Ｔ３８における合意
注）この例は、歴史的には ”ファクシミリのみ” の呼（以前のＪＴ－Ｔ３８のＤ．２．４．１節に公開されている）の節に配置されていたが、”音声およびファクシミリ” の呼のタイプに属する。
ゲートウェイの２者間の音声とファクシミリの呼の場合、ＲＴＰカプセル化をＵＤＰトランスポートプロト
コルとともに併用すると、次のようになる。

付表Ｄ．６／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－レガシーのＳＤＰオファー／アンサー構文の例３（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＩＰ／ＳＤＰコード

コメント

1) オファー (SIP INVITE における):
C->S: INVITE sip:+1-212-555-1234@bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
Cseq: 1 INVITE
Subject: Mr. Watson, here is a fax
Content-Type: application/sdp
Content-Length: …
v=0
o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
e=+1-212-555-1234@bell-tel.com
t=2873397496 0c=IN IP4 128.59.19.68
m=audio 49170 RTP/AVP 121 0 100
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=rtpmap:121 red/8000
a=fmtp:121 100/100
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF
2) アンサー (SIP 200 OK における):
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:+1-519-555-1234@bell-tel.com>
To: T. Watson <sip:+1-212-555-1234@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
Cseq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: …
v=0
o=faxwatson 4858949 4858949 IN IP4 192.1.2.3
c=IN IP4 boston.bell-tel.com
m=audio 5002 RTP/AVP 121 0 100
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=rtpmap:121 red/8000
a=fmtp:121 100/100
m=image 0 tcp t38

この例は、ＲＦＣ２１９８で定義されたＲＴＰファクシミリのための冗長な符号化を示す。音声のＪＴ－Ｇ
７１１符号化のために冗長性は使用されない。

- 75 -

ＪＴ－Ｔ３８

付表Ｄ．７／ＪＴ－Ｔ３８は改訂されたＳＤＰオファー／アンサー構文における例３のコードを示す（ＳＩＰヘッダーラインを除いてＳＤＰ構文のみ記述）。

付表Ｄ．７／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－改訂されたＳＤＰオファー／アンサー構文の例３（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＤＰコード（省略したＳＤＰ記述）
1) オファー (SIP INVITE に組み込まれた):…
; SESSION CONFIGURATIONs
a=sescap:1 1,2 ; VoIP = ITU-T G.711, FoIP = ITU-T T.38
RTP/UDPa=sescap:2 1,3 ; VoIP = ITU-T G.711, FoIP = ITU-T T.38
TPKT/TCP; LATENT CONFIGURATIONs for ITU-T T.38
a=tcap:1 RTP/AVP ; ITU-T T.38 FoRTP/UDP transport variant
a=tcap:2 tcp ; ITU-T T.38 FoTPKT/TCP transport variant
a=mcap:2 t38 ; ITU-T T.38 FoIP codec (subtype = 't38')
a=mcap:3 red/8000 ; RTP packet redundancy
a=mfcap:3 %2%/%2% ; RFC 2198 redundancy format (ITU-T
T.38)
a=mfcap:2 T38FaxRateManagement=transferredTCF
a=acap:11 T38FaxVersion:4; Transport-dependent ITU-T T.38 parameters for RTP/UDP
a=acap:12 (… additional ITU-T T.38 RTP attributes should
be included, if required); Transport-dependent ITU-T T.38 parameters for TPKT/TCP
a=acap:21 T38FaxRateManagement:localTCF
a=acap:22 (… additional ITU-T T.38 TPKT attributes should
be included)
a=lcfg:2 mt=audio t=1 m=2,3 pt=2:121,3:100 a=-ms:11,…
a=lcfg:3 mt=image t=2 m=2 a=-ms:11,…
; ACTUAL CONFIGURATION (due to backward compatibility)
m=audio 49170 RTP/AVP 121 0 100
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=rtpmap:121 red/8000
a=fmtp:121 100/100
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF;; POTENTIAL CONFIGURATION
a=mcap:1 PCMU/8000 ; audio codec; Preferences
a=pcfg:1 t=1 m=1 pt=1:0 a=-ms:

コメント
下記の２つのPOTENTIAL CONFIGURATIONがオファーされた。
( '音声' および 'ファクシミリ'のためのSESSION CONFIGURATIONとして):•優先 1: 音声 (PCMU) および JT-T38
FoRTP/UDPパケット冗長能力あり•優先 2: 音声 (PCMU) および JT-T38
FoTPKT/TCP
２つのＪＴ－Ｔ３８オプションは、LATENTCONFIGURATION として示された。音声モードは"a=pcfg:1"として指定されている。これらは２つの SESSION CONFIGURATION に従って示された。

アンサー側は最初に提供された設定に同意している。

2) アンサー (SIP 200 OK に組み込まれた):…
a=sescap:1- 76 -

ＪＴ－Ｔ３８下記付図Ｄ．４／ＪＴ－Ｔ３８は、この例でオファーされる２つの可能な session configuration を図示している。
オーディオコーデック
JT-G711
μ-law 無信号
抑制なしおよびRTP 冗長なし

オーディオモード(VoIP)

１

Session configurations

ファクスリレー
モード(JT-T38 FoIP)

２

JT-T38
RTP 冗長性を備えた RTP/UDP

JT-T38
TPKT/TCP

ファクスリレーコーディック

付図Ｄ．４／ＪＴ－Ｔ３８

例３で提示された Potential session configuration（ＩＴＵ－Ｔ

Ｔ．３８）

D.2.4.2.3 例４）複数のオーディオコーデック、単一のＪＴ－Ｔ３８オプション
複数のオーディオコーデックオプションが "音声接続" のために要求されても良い。 付図Ｄ．５／ＪＴ－Ｔ３８にＪＴ－Ｇ７２９とＪＴ－Ｇ７１１

μ-law を用いた一例を図示する。

オーディオコーデック
オーディオ
モード
(VoIP)

JT-G729
無信号抑制なし(TP = 20ms)

Session configurations

JT-G711 μ-law
無信号抑制なし(TP = 10ms)

２

１

JT-T38UDPTL/UDP

ファクスリレーモード(JT-T38 FoIP)

ファクスリレーコーディック

付図Ｄ．５／ＪＴ－Ｔ３８

例４で提示された Potential session configuration（ＩＴＵ－ＴＴ．３８）

付表Ｄ．８／ＪＴ－Ｔ３８はＳＤＰ構文例を提供する。

- 77 -

ＪＴ－Ｔ３８

付表Ｄ．８／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－改訂されたＳＤＰオファー／アンサー構文の例４（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＤＰコード（省略したＳＤＰ記述）
1) オファー (SIP INVITE に組み込まれた):…
; SESSION CONFIGURATIONs
a=sescap:1 1,3 ; VoIP = G.729, FoIP = ITU-T T.38 UDPTL/UDP
a=sescap:2 2,3 ; VoIP = G.711, FoIP = ITU-T T.38 UDPTL/UDP; LATENT CONFIGURATION for T.38
a=tcap:2 udptl ; ITU-T T.38 FoUDPTL/UDP transport variant
a=mcap:5 t38 ; ITU-T T.38 FoIP codec (subtype = 't38')
a=acap:11 T38FaxVersion:4
a=acap:12 T38FaxRateManagement:transferredTCF
a=acap:13 T38FaxUdpEC:t38UDPRedundancy
a=acap:14 (… additional ITU-T T.38 attributes may beincl.)
a=lcfg:3 mt=image t=2 m=5 a=11,12,13,14,…
; ACTUAL CONFIGURATION (due to backward compatibility)… ommitted …
; POTENTIAL CONFIGURATIONs
a=tcap:1 RTP/AVP ; transport for VoIP
a=acap:1 ptime:20 ; forITU-T G.729
a=acap:2 ptime:10 ; for ITU-T G.711
a=mcap:1 G729/8000 ; audio codec 1
a=mcap:2 PCMU/8000 ; audio codec 2
a=pcfg:1 t=1 a=-ms:1 m=1 pt=1:18
a=pcfg:2 t=1 a=-ms:1 m=2 pt=1:0

コメント
下記の２つのPOTENTIAL CONFIGURATIONがオファーされた（ '音声' および 'ファクシミリ'のためのSESSION CONFIGURATIONとして）:• 優先 1: オーディオ（ＪＴ－Ｇ７２９） およびファクスリレー（ＪＴ－Ｔ３８ＦｏＵＤＰ
ＴＬ／ＵＤＰ）• 優先 2: オーディオ（ＰＣＭＵ）およびファクスリレー（ＪＴ－Ｔ３８ＦｏＵＤＰＴＬ／
ＵＤＰ）注）レガシーＳＤＰオファー／アンサー構文のオーディオコーデックの個別のパケット化
時間の問題は、メディア固有の"a=acap:" 属性
により改訂されたＳＤＰオファー／アンサーで解決されている。

アンサー側はＪＴ－Ｇ７２９をサポートせず、２番目のSESSION CONFIGURATIONに同意する。

2) アンサー (SIP 200 OK に組み込まれた):…
a=sescap:2

D.2.4.2.4 例５）付加的にＶ．１５２をサポートするＳＩＰデバイス
ＳＩＰデバイスは、非Ｇ３ＦＥモデムトラフィック用のメディア能力オプションとして、付加的にＶ．１
５２ＶＢＤｏＩＰ（例４と比較して）を追加サポートしても良い。２つのオーディオコーデックオプション（ＪＴ－Ｇ７２９およびＪＴ－Ｇ７１１μ－ｌａｗ）は無音圧縮なしで同一パケット化周期Ｔｐ ＝２０ｍｓ
ｅｃを使用しなければならない。ＪＴ－Ｇ７１１μ－ｌａｗはＶ．１５２ ＶＢＤコーデックとしても使用されなければならない。付図Ｄ．６／ＪＴ－Ｔ３８は４つの可能な session configuration を示している。
オーディオコーデック
オーディオ
モード
(VoIP)

１

Session configurations

音声帯域データ
モード(V.152 VBDoIP)

JT-G711 μ-law
無信号抑制なし

JT-G729
無信号抑制なし３

２

JT-T38UDPTL/UDP

JT-G711μ-law

VBD コーデック

付図Ｄ．６／ＪＴ－Ｔ３８

４

ファクスリレー
モード(JT-T38 FoIP)

ファクスリレーコーデック– 例５で提示された Potential session configuration（ＩＴＵ－Ｔ

Ｔ．３８）- 78 -

ＪＴ－Ｔ３８

）

付表Ｄ．９／ＪＴ－３８はＳＤＰ構文例を提供する。

付表Ｄ．９／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－改訂されたＳＤＰオファー／アンサー構文の例５（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＤＰコード（省略したＳＤＰ記述）
1) オファー (SIP INVITE に組み込まれた):…
; SESSION CONFIGURATIONs
a=sescap:1 1 ; VoIP = ITU-T G.729, VBDoIP = ITU-T V.152(ITU-T G.711)
a=sescap:2 2 ; VoIP = ITU-T G.711, VBDoIP = ITU-T V.152(ITU-T G.711)
a=sescap:3 3,5 ; VoIP = ITU-T G.729, FoIP = ITU-T T.38
UDPTL/UDP
a=sescap:4 4,5 ; VoIP = ITU-T G.711, FoIP = ITU-T T.38
UDPTL/UDP; LATENT CONFIGURATION for ITU-T T.38
a=tcap:2 udptl ; ITU-T T.38 FoUDPTL/UDP transport variant
a=mcap:5 t38 ; ITU-T T.38 FoIP codec (subtype = 't38')
a=acap:11 T38FaxVersion:4
a=acap:12 T38FaxRateManagement:transferredTCF
a=acap:13 T38FaxUdpEC:t38UDPRedundancy
a=acap:14 (… additional ITU-T T.38 attributes may beincl.)
a=lcfg:5 mt=image t=2 m=5 a=11,12,13,14,…
; ACTUAL CONFIGURATION (due to backward compatibility)… ommitted …
;; POTENTIAL CONFIGURATIONs
a=tcap:1 RTP/AVP ; transport for VoIP & VBDoIP
a=mcap:1 G729/8000 ; audio codec 1
a=mcap:2,3 PCMU/8000 ; audio codec 2 & VBD codec
a=mscap:3 gpmd vbd=yes ; for V.152 PCMU
a=pcfg:1 t=1 a=-ms m=1,3 pt=1:18,3:99
a=pcfg:2 t=1 a=-ms m=2,3 pt=2:0,3:99
a=pcfg:3 t=1 a=-ms m=1 pt=1:18
a=pcfg:4 t=1 a=-ms m=2 pt=2:0

コメント
下記の４つのPOTENTIAL CONFIGURATIONがオファーされた( '音声' および 'ファクシミリ'のためのSESSION CONFIGURATIONとして):• 優先 1: オーディオ（ＪＴ－Ｇ７２９）、Ｖ
ＢＤ（Ｖ．１５２ＰＣＭＵ） と ＮＴＥ（ＲＦＣ４７３３）• 優先 2: オーディオ（ＰＣＭＵ）、ＶＢＤ（Ｖ．
１５２ＰＣＭＵ）とＮＴＥ（ＲＦＣ４７３３）• 優先 3: オーディオ（ＪＴ－Ｇ７２９） およびファクスリレー（ＪＴ－Ｔ３８ＦｏＵＤＰ
ＴＬ／ＵＤＰ）• 優先 4: オーディオ（ＰＣＭＵ）およびファクスリレー （ＪＴ－Ｔ３８ＦｏＵＤＰＴＬ／
ＵＤＰ）

アンサー側は、４番目のSESSIONCONFIGURATIONを選択する。

2) アンサー (SIP 200 OK に組み込まれた):…
a=sescap:4

D.2.4.2.5 例６）単一のオーディオコーデック、３つのエラー訂正方法に関するＪＴ－Ｔ３８構成
ＳＩＰ装置は３つのＪＴ－Ｔ３８エラー訂正方法を代替として提供することができる。オーディオコー
デックにはＪＴ－Ｇ７２９を用いる。付図Ｄ．７ ／ＪＴ－Ｔ３８は３つの実現可能な session configuration を図示している。

- 79 -

ＪＴ－Ｔ３８

オーディオコーデック
オーディオモード(VoIP)

JT-G729

ファクスリレー
モード(JT-T38 FoIP)
JT-T38 構成

２

１

Session configurations

３

JT-T38UDPTL/UDP
エラー訂正方式“UDP 冗長”

JT-T38UDPTL/UDP
エラー訂正方式“なし”JT-T38UDPTL/UDP
エラー訂正方式"FEC”“CT.38.1“CT.38.2“CT.38.3

付図Ｄ．７／ＪＴ－Ｔ３８””Potential session configuration”
例６で提示された（ＩＴＵ－ＴＴ．３８）

付図Ｄ．８／ＪＴ－Ｔ３８ はＪＴ－Ｔ３８構成 CT.38,1, CT.38,2 および CT.38,3 の詳細なパラメータ／値を提供している。

Media “Voiceband data (if fax)”
JT-T38 configuration CT.38,1 :JT-T38 configuration CT.38,2 :JT-T38 configuration CT.38,3 :0) T38 transport mode
= UDPTL/UDP
1) T38FaxVersion=42) T38MaxBitRate= 14400
3) T38FaxFillBitRemoval= FALSE4) T38FaxTranscodingMMR = FALSE
5) T38FaxTranscodingJBIG= FALSE
6) T38FaxRateManagement= transferredTCF
7) T38FaxMaxBuffer= 1800
8) T38FaxMaxDatagram= 150
9) T38FaxUdpEC= t38UDPRedundancy10) T38VendorInfo=11) T38ModemType= t38G3FaxOnly0) T38 transport mode
1) T38FaxVersion
2) T38MaxBitRate
3) T38FaxFillBitRemoval
4) T38FaxTranscodingMMR
5) T38FaxTranscodingJBIG
6) T38FaxRateManagement
7) T38FaxMaxBuffer8) T38FaxMaxDatagram
9) T38FaxUdpEC10) T38VendorInfo11) T38ModemType0) T38 transport mode
1) T38FaxVersion
2) T38MaxBitRate
3) T38FaxFillBitRemoval
4) T38FaxTranscodingMMR
5) T38FaxTranscodingJBIG
6) T38FaxRateManagement
7) T38FaxMaxBuffer8) T38FaxMaxDatagram
9) T38FaxMaxIFP
10) T38 VendorInfo11) T38ModemType= UDPTL/UDP=4= 14400= FALSE= FALSE= FALSE= transferredTCF= 1800= 150= t38UDPNoEC== t38G3FaxOnly= UDPTL/UDP=4= 14400= FALSE= FALSE= FALSE= transferredTCF= 1800= 150= t38UDPFEC== t38G3FaxOnly

注）３つのＳＤＰパラメータ T38FaxMaxIFP, T38FaxUdpECDepth および T38FaxUdpFECMaxSpanare はこの例に示されていない。
付図Ｄ．８／ＪＴ－Ｔ３８

例６におけるＪＴ－Ｔ３８構成

CT.38,1, CT.38,2 および CT.38,3 (session configuration のために使用される)（ＩＴＵ－ＴＴ．３８）

付表Ｄ．１０／ＪＴ－Ｔ３８はＳＤＰ構文例を提供する。

- 80 -

ＪＴ－Ｔ３８

付表Ｄ．１０／ＪＴ－Ｔ３８

ＳＩＰ／ＳＤＰ記述例－改訂されたＳＤＰオファー／アンサー構文の例６（ＩＴＵ－Ｔ

Ｔ．３８）

ＳＤＰコード（省略したＳＤＰ記述）
1) オファー (SIP INVITE に組み込まれた):…
; SESSION CONFIGURATIONs
a=sescap:1 1,3 ; VoIP = G.729, FoIP = ITU-T T.38 UDPTL/UDP
with packet red
a=sescap:2 1,4 ; VoIP = G.729, FoIP = ITU-T T.38 UDPTL/UDP
with NoEC
a=sescap:3 1,5 ; VoIP = G.729, FoIP = ITU-T T.38 UDPTL/UDP
with FEC; LATENT CONFIGURATION for ITU-T T.38
a=tcap:2 udptl ; ITU-T T.38 FoUDPTL/UDP transport variant
a=mcap:5 t38 ; ITU-T T.38 FoIP codec (subtype = 't38')
a=acap:11 T38FaxVersion:4
a=acap:12 T38MaxBitRate:14400; Note: the exclusion of attributes"T38FaxFillBitRemoval","T38FaxTranscodingMMR" and"T38FaxTranscodingJBIG"
means value "FALSE" (see [ RFC 4612]).
a=acap:16 T38FaxRateManagement:transferredTCF
a=acap:17 T38FaxMaxBuffer:1800
a=acap:18 T38FaxMaxDatagram:150
a=acap:19 T38ModemType:t38G3FaxOnly
a=acap:21
T38FaxUdpEC:t38UDPRedundancy;
error
correction scheme 1
a=acap:22 T38FaxUdpEC:t38UDPNoEC ; error correction
scheme 2
a=acap:23 T38FaxUdpEC:t38UDPFEC ; error correction
scheme 3
a=lcfg:3 mt=image t=2 m=5 a=11,12,16,17,18,19,21 ; ITU-T
T.38 configuration #1
a=lcfg:4 mt=image t=2 m=5 a=11,12,16,17,18,19,22 ; ITU-T
T.38 configuration #2
a=lcfg:5 mt=image t=2 m=5 a=11,12,16,17,18,19,23 ; ITU-T
T.38 configuration #3; ACTUAL CONFIGURATION (due to backward compatibility)… ommitted …
;; POTENTIAL CONFIGURATIONs
a=tcap:1 RTP/AVP ; transport for VoIP
a=acap:1 ptime:10 ; for ITU-T G.711
a=mcap:1 G729/8000 ; audio codec 1
a=pcfg:1 t=1 a=-ms:1 m=1 pt=1:18

コメント
下記の３つのPOTENTIAL CONFIGURATIONがオファーされた:( '音声' および 'ファクシミリ'のためのSESSION CONFIGURATIONとして):• 優先 1: オーディオ（ＪＴ－Ｇ７２９）およびファクスリレー（エラー訂正方法がt38UDPRedundancy のＪＴ－Ｔ３８ＦｏＵＤ
ＰＴＬ／ＵＤＰ）
即ち、エラー訂正としてパケット冗長を使用したＪＴ－Ｔ３８• 優先 2: オーディオ（ＪＴ－Ｇ７２９） およびファクスリレー（エラー訂正方法がt38UDPNoECのＪＴ－Ｔ３８ＦｏＵＤＰＴＬ／ＵＤＰ）
即ち、エラー訂正がないＪＴ－Ｔ３８• 優先 3:オーディオ（ＪＴ－Ｇ７２９） およびファクスリレー（エラー訂正方法がt38UDPFEC のＪＴ－Ｔ３８ＦｏＵＤＰＴＬ／ＵＤＰ）
即ち、エラー訂正として前方エラー訂正（ＦＥＣ）を使用したＪＴ－Ｔ３８

アンサー側は、１番目のSESSIONCONFIGURATIONを選択する。

2) アンサー (SIP 200 OK に組み込まれた):…
a=sescap:1- 81 -

ＪＴ－Ｔ３８

D.2.5 最低限の呼設定メッセージ本付属資料の実装は、ＲＦＣ３２６１のＡ．１節およびＡ．２節に定義されるようなＳＩＰクライアント
およびサーバ用の最低限の要求条件をサポートしなければならない。
すべてのクライアントは INVITE と ACK リクエストを生成することができなければならない。クライアン
トは、Call-ID, Content-Length, Content-Type, CSeq, From 及び To ヘッダーを生成し解析できなければならない。
クライアントは Require ヘッダーを解析できなければならない。最小限の実装は、ＳＤＰ（ＲＦＣ２３２７）を理解しなければならない。そしてそれは１～６クラスのステータスコードを認識し動作できなければならない。
最小限のサーバに適合する実装は、INVITE、ACK、OPTIONS および BYE リクエストを理解しなければならない。プロキシサーバは、さらに CANCEL を理解しなければならない。そして、Call-ID, Content-Length,
Content-Type, CSeq, Expires, From, Max-Forwards, Require, To および Via ヘッダーを適切に、解析し生成しなければならない。レスポンスで CSeq および Timestamp のヘッダーを反復しなければならない。そのレスポン
スにはサーバヘッダを含むべきである。

D.2.6 発呼経過信号のマッピング
発呼準備および発呼経過のために、応答信号を次の組み合わせだけに単純化することができる（付表Ｄ．
１１／ＪＴ－Ｔ３８参照）。これらの応答信号は、全て INVITE リクエストに対する 200 OK レスポンスに先立つか、もしくはその代りに返される。

付表Ｄ．１１／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

発呼経過信号のマッピング
Ｔ．３８）

意味

ＳＩＰ応答マッピング

ビジー１。Ｅ．１８０で定義された加入者ビジートーン。

486 Busy here

ビジー２。時々ＰＡＢＸモデル特有のビジーとして参照される。

486 Busy here

Ｅ．１８０で定義される輻輳ビジー。

600 Busy everywhere

リング１。Ｅ．１８０において定義されたリンギングトーン。中間の発呼経過を示す。 180 Ringing
あたかもエンドエンド間でＰＳＴＮ接続があったかのように、発呼Ｇ３ＦＥ端末へのリングバック信号を生成するために使用することができる。
リング２．１つの長いリングの代わりに２つの短いリングが生成されるリング１に似180 Ringing

たリンギングトーン。これは中間の発呼経過の結果である。
ＳＩＴ インターセプト。この特別な情報トーンはＥ．１８０ に定義されている。イン503 Service Unavailable

ターセプトトーンは、周波数と周期のトーンの１つの組み合わせである。
ＳＩＴ 空き。この特別な情報トーンはＥ．１８０ に定義されている。回線空きトーン

503 Service Unavailable

は、周波数と周期のトーンの１つの組み合わせである。
ＳＩＴ 再要求。この特別な情報トーンはＥ．１８０ に定義されている。再要求トーン

503 Service Unavailable

は、周波数と周期のトーンの組み合わせである。
ＳＩＴ 回線なし。この特別な情報トーンはＥ．１８０ に定義されている。回線なしトー

503 Service Unavailable

ンは、周波数と周期のトーンの１つの組み合わせである。
注 ＳＩＴトーンは一般に、ダイヤルされた番号との間で問題を起こすので識別されない。

ゲートウェイが、何らかの方法によって、Ｇ３ＦＥ端末への接続が確立されたことを決定するとき、INVITE
リクエストに応答した 200 OK メッセージが返される。ＣＥＤまたはＦＳＫフラグが検出されれば、適切な- 82 -

ＪＴ－Ｔ３８

ＪＴ－Ｔ３８メッセージを送ることができる。

D.2.7 ＤＴＭＦ送信ＳＩＰはＲＦＣ３２６１の２章において定義されているように、以下のようにＳＩＰ ＵＲＬとして、集められたＤＴＭＦダイヤリングディジットを転送することができる。

sip:+1-212-555-1212@gateway.com;user=phone

音声やファクシミリ接続が確立している間のＤＴＭＦ送信は、ＲＦＣ４７３３において示されたＲＴＰトー
ンペイロードを用いて実現してもよい。

D.2.8 相互接続性
ＳＩＰと本付属資料Ｂの両方は、コールシグナリングを開始するのに既知のポートを必要とする。ＳＩＰに記述されているように、その既知のポートは５０６０である。本付属資料におけるエンドポイントは、デフォルトでＳＩＰの既知のポートを使わなければならない。

D.2.8.1 フォールバック手順
ＧＳＴＮにおけるファクシミリ呼の成功率を最大化するために、ゲートウェイ間のＪＴ－Ｔ３８セッショ
ンのネゴシエーション失敗の場合、ゲートウェイはＶＢＤとしてＪＴ－Ｇ７１１をもつＶ．１５２へフォー
ルバックすべきである。もし、Ｖ．１５２が実行できなければ、Ｖ．１５２ではないＪＴ－Ｇ７１１をもつ
音声符号化が替わりに実行される。これを実行する一例がＤ．２．４．２節に記述されている。

- 83 -

ＪＴ－Ｔ３８

付属資料

Ｅ（ＪＴ－Ｔ３８に対する）
ＪＴ－Ｈ２４８．１呼の確立手順（この付属資料は、本標準の必須部分を形成する）

E.1 はじめに本付属資料は、ＪＴ－Ｈ２４８．１によって定義された手順および、次の手順のどちらか１つを使用する
他のＪＴ－Ｔ３８の実装で呼を確立するために、ＪＴ－Ｔ３８に準拠するインターネット対応ファクシミリ
の実装とインターネット対応ファクシミリゲートウェイのためのシステムレベル要求及び手順について記述する。

ａ） メディアゲートウェイは、ＪＴ－Ｈ２４８．１によって定義される手順を通してパラダイムを制御する。このパラダイムは、ＪＴ－Ｔ３８ＭＧＣ遷移方式として参照されなければならない。この方式を使用する呼は、ＪＴ－Ｈ２４８．１に定義されるような標準手順を使用することで設定される。しかし、もしＪＴ－Ｔ３８がサポートされなければならないならば、Ｈ．２４８．２に記述されるようなパッケージが考慮される。そしてファクシミリトーンの生成と検出が可能になる。ファクシミリ信号の検出について、ＭＧＣは、イベントについて送信ＭＧによって通知される。そして、信号生成するために制御するＭＧＣを経て、受信部へコマンドを与える。応答信号は同じ方法で扱われる。必要とされる全ての信号が、ＭＧＣとＭＧを経由するファクシミリ端末の両方の間で通信されるとき、ＭＧ
Ｃは、それらをファクシミリモードへ移行するためにコンテキストを変更するだろう。この事例は、２０の Megaco コマンドまで受け取ることができる。

ｂ） メディアゲートウェイコントローラ（ＭＧＣ）のリアルタイムな介入なしで、ＪＴ－Ｔ３８をサポートするメディアゲートウェイ（ＭＧ）によって、ＶｏＩＰ呼とＦｏＩＰ呼（ＪＴ－Ｔ３８を使用する）の間を遷移することを考慮にいれるパラダイム。本付属資料を通じて、用語“メディアゲートウェイ
コントローラ”が、ＪＴ－Ｈ３２３に定義されるゲートキーパーと同じようにＨ．２４８に定義されるようなＭＧＣを表すために使用されることに注意すること。ＭＧＣのただ１つの関与は、ＳＤＰ記
述子を使用するメディアゲートウェイ同士間の初期接続能力ネゴシエーション中にあるだろう。この段階において、ＭＧとＭＧＣの両方は、接続のタイプを意識しない（すなわち、音声、ＦＡＸ、モデムなど）。この選択肢の中のメカニズムは、付属資料Ｂ（ＪＴ－Ｈ．３２３手順）、付属資料Ｄ（ＳＩＰ／ＳＤＰ手順）、付属資料Ｅ（ＪＴ－Ｈ２４８．１手順）、ＪＴ－Ｈ３２３付属資料Ｄにある既存メカニズムを補足するオプション手順である。このパラダイムは、ＪＴ－Ｔ３８自動遷移方式として参照されなければならない。

E.2 ゲートウェイ間の通信
E.2.1 概要
E.2.1.1 ゲートウェイアーキテクチャ
本付属資料で述べられる方法は、付図Ｅ．１において示されるような分散ゲートウェイモデルにおいて他の方法と共に使われることを意図している。このモデルにおいて、メディアゲートウェイコントローラ（ＭＧＣ）は、ドメイン中のエンドポイント全ての知識を持っており、メディアゲートウェイ（ＭＧ）で開始と終了が行われる接続を制御することができる。

- 84 -

ＪＴ－Ｔ３８

SS7

PSTN

SG

SG

MGC

MGC

IP
network

MG

付図Ｅ．１／ＪＴ－Ｔ３８

MG

 分散モデルの典型例

SS7

PSTN

T.38_FE.1（ＩＴＵ－Ｔ Ｔ．３８）

本付属資料におけるメカニズムは、ＪＴ－Ｈ３２３付属資料Ｄのメカニズムを補足する。（分散したゲートウェイなしでシンプルな場合を描写するメカニズム）。２つ以上のＭＧＣが発呼に関連している状況において、本付属資料におけるメカニズムは、それらの間の信号に使われる。（他の方法は継続検討）

E.2.1.2 呼設定
本付属資料に適合した実装の呼設定は、ＪＴ－Ｈ２４８．１に基づく。基本的付属資料 B と同様に、実装は以下の２つの異なった互換性のある環境のなかで動作してもよい。
（１） ＩＰ環境でのファクリミリのみ  この環境においては、音声はサポートされない。Ｅ．２．２．
１節の手順および条件は、この環境で動作する実装に適合しなければならない。
（２）

ＩＰ環境でのファクシミリと音声Ｅ．２．２．２節の手順および条件は、この環境で動作す

る実装に適合しなければならない。

E.2.1.3 メディアチャネル
ＪＴ－Ｔ３８ファクシミリパケットは、Ｈ．２４８メッセージトランスポートから別のＴＣＰ／ＵＤＰポートへ送られる。本付属資料に基づく最小限の実装は、コールシグナリング（Ｈ．２４８メッセージ）トラン
スポートのためのＴＣＰ、ＵＤＰまたはＳＣＴＰポートとＪＴ－Ｔ３８ファクシミリ情報のためのＴＣＰ
ポートかＵＤＰポートのいずれかを必要とする。

E.2.2 基本呼設定の準備-

本節は以下に引用するＪＴ－Ｈ２４８．１の６章に従う。1プロトコルの接続モデルは、メディアゲー
トウェイコントローラでコントロールできるメディアゲートウェイの中の論理的構成要素またはオ
ブジェクトを表す。接続モデルに使われる主な概念は、ターミネーション及びコンテキストである。

-

ターミネーションはメディアストリームのソースおよびまたはシンクとなる一つのオブジェクトで。

1TTC 註：原文（ＩＴＵ－Ｔ Ｔ．３８）に従えば「８．２．１節」となるが、接続モデル、ターミネーション、コン
テキストについてはＪＴ－Ｈ２４８．１では６章に記載されている内容のため本標準では「６章」としている。

- 85 -

ＪＴ－Ｔ３８-

コンテキストは一つの会議中のターミネーションの集合を表す。

ターミネーションは、他のイベントを作成するために、ＭＧＣによって応答を引き起こすイベントを検出する（例えば、オフフックを検出すると、ダイヤルトーンの再生が引き起こされる）。この相互作用はＭＧで開始された典型的な呼設定の間、処理される（例えば、ＪＴ－Ｈ３２３ファーストコネクト設定）。

次の２つのメカニズムのどちらかを使用することで、ＩＰネットワーク上のファクシミリ呼を確立することを可能としなければならない。

（１） ＪＴ－Ｔ３８ＭＧＣ遷移方式：ＭＧにより（ＪＴ－Ｈ２４８．１および、Ｈ．２４８．２に記述されるパッケージを経て）送信されたトーンイベントに基づき、ＶｏＩＰからＪＴ－Ｔ３８ ＦｏＩ
Ｐへの遷移を可能とするのがいつか、そしてどちらかをＭＧＣが決定するメカニズム。Ｈ．２４８に対してそれは、Ｅ．２．２．１節に記述される。ＪＴ－Ｈ３２３環境においては、ＪＴ－Ｔ３８
チャネルへの音声チャネルの置換は、ＪＴ－Ｈ３２３付属資料ＤのＤ．５節の手順に従って行われる。2（２） ＪＴ－Ｔ３８自動遷移方式：Ｅ．２．２．２節に記述されるようなメディアゲートウェイコントローラ（ＭＧＣ）の介入なしに、または、付属資料Ｄ（ＳＩＰ／ＳＤＰ）記述されるような呼の変更を要求することを必要としないでＭＧによるＦｏＩＰ呼（ＪＴ－Ｔ３８を使用する）とＶｏＩＰ呼間を遷移するためのメカニズム。この方式をサポートするとき、Ｈ．２４８．２に記述されるパッケー
ジは必要とされないことに注意すること。ＪＴ－Ｈ３２３環境においては、ＪＴ－Ｈ３２３付属資料ＤのＤ．３節（fastStart）または、ＪＴ－Ｈ３２３付属資料ＤのＤ．４節（non-fastStart）の手順が２つの平行するチャネルの設定のために使用される。

ＭＧは、以下に記述されるメカニズムを使用することで、audio と image/t38 メディアストリームの両方をサポートする呼設定メッセージまたは、最初の能力交換に含むことによって、ＪＴ－Ｔ３８自動遷移方式のサポートを示さなければならない。

能力交換（ＳＩＰまたは、Ｈ．２４８のＭＧのような、しかし限定されない）のためにＳＤＰ（ＲＦＣ２３
２７参照）を使用するメディアゲートウェイは、少なくとも２つのメディア記述子（すなわち、”m=...”の行）を交換されるための最初のＳＤＰに含めることによって、ＪＴ－Ｔ３８自動遷移方式のサポートを示さなければならない。image/t38 タイプのメディア記述子の１つと audio タイプの１つである。その中では、ポート番号を０にセットしない（これは、ＳＩＰ端末との互換性のためであり、ポートを０に設定することは、そのメディアタイプの非サポートを意味する）。これを次の例に示す。これは、ＳＤＰ部分だけを示し、そのなかでメディア行だけが重要である。その上、Ｈ．２４８を使用するとき、付録Ⅲに示されるように、メディア記述子はバージョン記述子（v=の行）によって分離されなければならないことに注意する。

2 TTC 註：原文（ＩＴＵ－Ｔ Ｔ．３８）に従えば「ＩＴＵ－Ｔ Ｈ２４８およびＩＴＵ－Ｔ Ｈ．２４８．１の付属資料Ｆに記載されるパッケージ」となるが、ＩＴＵ－Ｔ Ｈ２４８がＩＴＵ－Ｔ Ｈ．２４８．１とＩＴＵ－Ｔ Ｈ．２４８．２に再編された際に原文が正しく修正されなかったと考え、本標準では適正な引用先に修正した。

- 86 -

ＪＴ－Ｔ３８

（注）本付属資料の全ての例は、Ｈ．２４８テキスト符号化方式を説明し、それはＨ．２４８ローカルおよびリモートディスクリプタでＳＤＰシンタックスを使用する。ＪＴ－Ｔ３８（付属資料Ｄ参照）で定義される全てのＳＤＰ情報要素は、Ｈ．２４８シグナリングでも使用されるかもしれない。以下の例
は、典型的にサブセット（“等付加的な属性が含まれても良い”によって示される）を説明する。

- 87 -

ＪＴ－Ｔ３８

ＪＴ－Ｔ３８自動遷移方式のサポートを説明しているＳＤＰ例

例１

v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0（．．．等付加的な属性が含まれても良い）
m=image 4444 udptl t38
a=T38FaxVersion:1
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxMaxBuffer:2000
a=T38FaxMaxDatagram:512
a=T38MaxBitRate:14400（．．．等付加的な属性が含まれても良い）
例２

v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0 8 13
a=ptime:20（．．．等付加的な属性が含まれても良い）
m=audio 1111 RTP/AVP 18 129
a=ptime10
a=rtpmap:129 telephone-event/8000
a=fmtp:129 0-15(… additional attributes may be included)
m=image 4444 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC（．．．等付加的な属性が含まれても良い）
ＪＴ－Ｔ３８自動遷移方式の非サポートを説明しているＳＤＰ例

例３

v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0 8 13 140a=ptime:20
a=rtpmap:140 telephone-event/8000
a=fmtp:140 0-15（．．．等付加的な属性が含まれても良い）
m=image 0 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxMaxBuffer:1536
a=T38FaxMaxDatagram:512（．．．等付加的な属性が含まれても良い）- 88 -

ＪＴ－Ｔ３８例４v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0 8 13 140a=ptime:20
a=rtpmap:140 telephone-event/8000
a=fmtp:140 0-15（．．．等付加的な属性が含まれても良い）
例５v=0
c=IN IP4 124.124.124.222
m=image 8190 udptl t38
a=T38FaxVersion:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxMaxBuffer:2000（．．．等付加的な属性が含まれても良い）
例３と例４は、ＳＤＰを送信したメディアゲートウェイがＪＴ－Ｔ３８をサポートしていない（ときのその例で）ことを示しているのと同様に、交換されたＳＤＰの例では、ＪＴ－Ｔ３８自動遷移方式が使用されてはならないことを示しているものとして解釈されなければならないことに注意すること。

そのようなケースにおいて、呼は、使用されている呼確立制御プロトコルによって命令されたように進行するするだろう。（ＪＴ－Ｈ３２３、ＳＩＰまたは、Ｈ．２４８かもしれないが、しかし限定されない）。もし、それがＨ．２４８ならば、Ｅ．２．２．１節の手順が使用されなければならない。その上、例３と例４のＳＤＰがＪＴ－Ｔ３８のサポートを示していないにも関わらず、呼の後の段階において、ＭＧとＭＧＣのどちらかが、image/t38 タイプのメディア属性を含んでいる（付属資料Ｄまたは、Ｅ．２．２．１節のどちらかに記述されるような）新しいＳＤＰ（例えば、Ｈ．２４８Modify コマンドまたは、ＳＩＰの INVITE コマンド）を送ることによって、ＪＴ－Ｔ３８への遷移を要求できないことを意味していないことに注意すること。

例５は、両方のＭＧを、ＦｏＩＰ（ＪＴ－Ｔ３８を使用する）へ迅速に遷移させるだろう。しかしながら、任意の他の動作モードへの未来における遷移（例えば、音声、音声帯域データなど）がＭＧＣにより制御されなければならない。

ＪＴ－Ｈ３２３対応のメディアゲートウェイは、ＪＴ－Ｈ３２３付属資料ＤのＤ．３節（fastStart）または、
ＪＴ－Ｈ３２３付属資料ＤのＤ．４節（non-fastStart）に記述されるような、音声のための１つとＪＴ－Ｔ３８のためのその他、２つの平行するチャネルをそれぞれの方向にオープンすることによって、ＪＴ－Ｈ２４５の能力交換中に、ＪＴ－Ｔ３８自動遷移方式のサポートを示さなければならない。お互いにＪＴ－Ｔ３８
自動遷移方式をサポートする２つのＭＧは、適切なファクシミリ信号の検出においてまたは、ＪＴ－Ｔ３８
ＵＤＰ（または、ＴＣＰ）ポートでのＪＴ－Ｔ３８ＵＤＰ（または、ＴＣＰ）パケットの受信において、オー
ディオチャネルを抑え、ＪＴ－Ｔ３８チャネルへの遷移を自動的に行わなければならない。

メディアゲートウェイ間で上述のように交換された能力メッセージから導かれたデータに基づいて、メディアゲートウェイコントローラは、呼の開始において、どの方式を使用するか（すなわち、オーディオからファ- 89 -

ＪＴ－Ｔ３８

クシミリへの遷移を制御すべきか、またはＭＧに自動的に遷移させるかどうか）決定しなければならない。

結果的に、接続を確立している両方のＭＧが、それらが、ＪＴ－Ｔ３８自動遷移方式をサポートすることをお互いに示しているならばその場合のみ、ＭＧＣは、ＶｏＩＰとＦｏＩＰの間の遷移を制御してはならない（上述の意味により）。ＪＴ－Ｈ３２３のファーストスタートには、自動的または、ＭＧＣに基づくかどち
らかの方式を使用するための明白なネゴシエーションがないことに注意すること。ファーストスタートの要
素は、ＪＴ－Ｈ３２３付属資料ＤのＤ．３節により、呼が、純粋な音声呼か（結局、ＪＴ－Ｈ３２３付属資料ＤのＤ．５節を使用するＴ．３８呼へ切り替えてもよい）、音声のための分離されたチャネルおよび、Ｊ
Ｔ－Ｔ３８のための分離されたチャネルから成るかもしれない呼のどちらかを示すだろう。後者は、ＭＧがＪＴ－Ｔ３８自動遷移方式を使用しなければならないことを示すように、ＭＧＣ（換言すれば、ゲートキーパー）によって使用されなければならない。非ファーストスタート手順が使用されるとき、ＪＴ－Ｔ３８と音声を同時に使用されうるのかそうでないのかを端末の能力ネゴシエーションは示すだろう。（端末の能力
ネゴシエーションは、ファーストスタート呼設定後も使用されてよい。そして、自動的または、ＭＧＣ切り替え方式がサポートされるのかを示すことに役立つだろう。）

ＪＴ－Ｔ３８自動遷移方式のサポートを示しているＭＧがないことは、次の１つが可能な、使用されている
呼制御プロトコル（ＳＩＰ、ＪＴ－Ｈ３２３または、Ｈ．２４８）に依存する既存の呼確立手順を使用する
ための指示として、ＭＧとＭＧＣの両方によって、解釈されなければならない。

１）Ｅ．２．２．１節に記述される（Ｈ．２４８に対する）ＪＴ－Ｔ３８ＭＧＣ遷移方式
２）付属資料Ｂに記述される方式（ＪＴ－Ｈ３２３手順）
３）付属資料Ｄに記述される手順（ＳＩＰ／ＳＤＰ手順）

ＪＴ－Ｔ３８自動遷移方式が特別な呼のために使用されなければならないということをＭＧＣが知っている事実は、ファクシミリトーンの検出または、ＦｏＩＰ（ＪＴ－Ｔ３８を使用する）への遷移を示すＭＧからの通知を受信するために要求するＭＧＣの可能性を妨げない。起こりうるそのような通知の使用法は、本付属資料の範囲外である。

E.2.2.1 ＪＴ－Ｔ３８メディアゲートウェイコントローラ（ＭＧＣ）方式

このメカニズムの使用のために、以下の２つのケースが存在することに注意すること。

（１） もし、コールエージェント（ＭＧＣとゲートキーパー）が双方のＭＧをコントロールするなら、Ｊ
Ｔ－Ｈ２４８．１およびＩＴＵ－Ｔ Ｈ．２４８．２に記載されたパッケージは、２つのＭＧの間に存在する接続を変更するために使われる。3

3 TTC 註：原文（ＩＴＵ－Ｔ Ｔ．３８）に従えば「ＩＴＵ－Ｔ Ｈ２４８およびＩＴＵ－Ｔ Ｈ．２４８．１の付属資料Ｆに記載されるパッケージ」となるが、ＩＴＵ－Ｔ Ｈ２４８がＩＴＵ－Ｔ Ｈ．２４８．１とＩＴＵ－Ｔ Ｈ．２４８．２に再編された際に原文が正しく修正されなかったと考え、本標準では適正な引用先に修正した。

- 90 -

ＪＴ－Ｔ３８（２）異なる複数のコールエージェントが関係するとき（例えば、２つの異なるサービスプロバイダが、呼を確立することに関連しているとき）、ＭＧＣ－ＭＧＣ間通信が必要とされる（すなわち、ＪＴ－
Ｔ３８の付属資料Ｄのメカニズムを使用することである）。接続の確認に関して、オンランプ発呼エー
ジェントは、オフランプＭＧと共にＪＴ－Ｔ３８セッションを開始するように（Ｈ．２４８によって）そのメディアゲートウェイに命令する。

このＶｏＩＰからＦｏＩＰへの遷移方式は、ＭＧが本節で記述したメカニズムを用いて、相互にＪＴ－Ｔ３
８自動遷移方式のサポートを示さない限りはデフォルトの方式でなければならない。

E.2.2.1.1 ファクシミリのみの接続
ディジットは、メディアゲートウェイ（ＭＧ）によって集められ、ファクシミリの発呼に対する通信相手を呼び出すために、発呼エージェントに送られる。いったん接続した後は、その発呼はＪＴ－Ｔ３８の付属資料Ｂの手順に進む。

E.2.2.1.2 音声とファクシミリの接続
ディジットは、メディアゲートウェイ（ＭＧ）によって集められ、ＪＴ－Ｈ２４８．１において定義されているように、音声接続の通信相手を呼び出すために、発呼エージェントに送られる。音声接続が設定される。

送信メディアゲートウェイ（ＭＧ）によるＣＮＧの検出において、発呼エージェントは、（ＪＴ－Ｈ２４
８．１によって）このイベントを通知され、宛先ＭＧがＣＮＧを再生するように指示する。それから宛先Ｍ
ＧがＣＥＤ（あるいはＶ．２１フラグ）イベントをＭＧＣに通告し、ＪＴ－Ｔ３８の能力があるならば、Ｍ
ＧＣは各ＭＧがＪＴ－Ｔ３８の接続を開くことを要求する。ファクシミリ呼の識別に対する詳細説明は、Ｈ．
２４８．２の８章に示されている。またＭＧＣは、新しいＭＧがファクシミリ接続を扱うことを同じく要求してもよい。ＪＴ－Ｔ３８プロトコルは、ＪＴ－Ｔ３８のＶ．２１フラグインジケータパケット処理に進む。

ＪＴ－Ｔ３８がＭＧのうちの１つによってサポートされないならば、ＭＧＣがＶ．１５２で定義される手順及び方法を使用して、ファクスリレー接続を中止し、条件付きオーディオチャネル上で接続を試みることを選択してもよいことに注意すること。また、レガシーのシステムでは、非Ｖ．１５２／ＪＴ－Ｇ７１１コー
デック構成でパススルーサービスを使用してもよいことに注意すること。
もし、ＭＧＣにファクシミリイベントを通知されなければ、ＭＧ間の交換（例えば、音声＋ファクシミリ、
音声のみまたはファクシミリのみ）とオプション決定の完全な適用が望めないであろう（ＭＧが単独でファクシミリを検知してＪＴ－Ｔ３８手順に一方的に切り替える）。オフランプメディアゲートウェイ（ＭＧ）
によるファクシミリ呼の完了（ＪＴ－Ｔ３８完了）において、発呼エージェントは（ＪＴ－Ｈ２４８．１によって）このイベントを通知されたら、接続が音声に戻ることを要求してもよい。

E.2.2.2 ＪＴ－Ｔ３８自動遷移方式
この方式を使用するために、ＭＧは、呼の開始においてそうすることをお互いに認識しなければならない。
ＪＴ－Ｔ３８自動遷移方式のサポートをＭＧＣとリモートＭＧに示すためにＭＧによって使用されるメカ
ニズムのためにＥ．２．２節（基本呼設定の準備）を参照すること。
ＭＧは、呼の開始において、起こりうる全てのメディア記述子をネゴシエーションするだろう。
従って audio
記述子と image/t38 記述子の両方とも含まれているだろう。それ故、呼に続くファクシミリフェーズのＪＴ－Ｔ３８オプションは、オーディオパラメータのように同じ時にネゴシエーションされる。
- 91 -

ＪＴ－Ｔ３８

Ｈ．２４８呼設定手順を使用する場合については、両方のＭＧが、オーディオ（２つのメディア記述子の行で応答されて）と同様に、ＪＴ－Ｔ３８をサポートすることをオーディットにおいて示してもよいという事実が、ＪＴ－Ｔ３８自動遷移方式のサポートの表示として使用されてはならないという事実に注意すること。

ＪＴ－Ｔ３８自動遷移方式のサポートが示されるコンテキストの作成の中になければならない。結果的にＨ．
２４８能力をもつＭＧＣは、
ポート番号に＄をセット、LocalControl 記述子の ReserveGroup プロパティに True
をセットおよび、Add Ephemeral コマンド（１つの例として、付録Ⅲ２．２．３節参照）のローカル記述子部にオーディオとイメージ記述子の両方を含むことが必要だろう。それ故、ＭＧがオーディオとイメージ記
述子の両方のための資源を確保することを有効に求めている。しかしながら、いくつかの理由（例えば、資源の不足）のために、呼の開始時点で、オーディオとイメージの両方の資源が確保できないならば、応答Ｓ
ＤＰのイメージメディア記述子がポートを０にセットする（ＳＩＰ能力をもつ端末との互換性のために推奨される）か、すべてを省略しなければならない。それ故、音声呼の開始と同様、ＪＴ－Ｔ３８自動遷移方式の非サポートを示している。そして結果的に、デフォルトによりゲートウェイとメディアゲートウェイコン
トローラの両方は、ＭＧＣ方式を使用しなければならない。

E.2.2.2.1 ファクシミリのみの接続
ディジットは、メディアゲートウェイ（ＭＧ）によって集められ、ファクシミリの発呼に対する通信相手を呼び出すために、発呼エージェントに送られる。いったん接続した後は、その発呼は、ＪＴ－Ｔ３８の付属
資料Ｂの手順に進む。

E.2.2.2.2 音声とファクシミリの接続
ディジットは、メディアゲートウェイ（ＭＧ）によって集められ、ＪＴ－Ｈ２４８．１において定義されているように、音声接続の通信相手を呼び出すために、発呼エージェントに送られる。ＭＧＣとＭＧは、音声
呼または、ファクシミリ呼になるだろうという指示を行わないので、ＭＧは、音声接続の設定を行い、ＪＴ－Ｔ３８パケットは何も送られてはならない。それらファクシミリ呼が開始していると決定できるような評
価基準（Ｅ．２．２．２．２．１節参照）を検出するまでこのモードに留まる。ＭＧはこの時点において、オーディオ接続を抑制し、image/t38 接続を開始しなければならない。ＭＧは、ファクシミリ送信が完了されたと決定できるような評価基準を検出するまでファクシミリモードに留まるだろう。その時点で image/t38
接続を抑制し、再度 audio/RTP 接続を可能にさせるだろう。この手順は、呼が切断されるまで無限に続いてよい。

E.2.2.2.2.1 ファクシミリトーン／信号のＭＧからＭＧへの信号通信
ＪＴ－Ｇ７２９のような、しかし限定されない高圧縮音声符号化技術を使用するとき、あるファクシミリ
トーン信号は、パケット網を介して、正しく送信されないかもしれない。従って、他のメカニズムによってパケット網を介して、それらを送信し、信号を検出することが推奨される。次の方法は、パケット網を越え
相手ファクシミリ端末へ検出された信号とトーンについての情報を通過させるためにある。

方法１
トーンの透過：トーンは、音声帯域データ（ＶＢＤ）のために使用される１つのような低圧縮アルゴリズム、
例えば、ＲＴＰ／ＵＤＰ／ＩＰ上でＪＴ－Ｇ７１１または、ＪＴ－Ｇ７２６－３２Ｋｂｉｔ／ｓを使用する
符号化方式を使用してインバンドで送られる。

- 92 -

ＪＴ－Ｔ３８

トーン検出によって、ＭＧは、自動的にＶＢＤに切り替わり、そのモードにおいて適切なコーデック（例えばＪＴ－Ｇ７１１）が使用される。そして、音声ＲＴＰペイロードでトーンを透過させる。受信ゲートウェ
イは、パケット網から、トーンを検出しなければならない。そして、ファクシミリ端末へトーンを透過させるため、ＶＢＤへ切り替わらなければならない。
この方式は、両方のメディアゲートウェイが共通の低圧縮コーデックのサポートまたは、ＶＢＤ状態のサポートが示された場合だけ使用されるべきである。ＳＤＰ交換または、他のメカニズムによってそのようなサポートを指示するために使用されるメカニズムがあってよい。それは、本付属資料の範囲外である。

方法２
トーンの中継（ＲＦＣ４７３３を参照－ＤＴＭＦディジット、電話トーン、電話信号のためのＲＴＰペイロード）：トーンを再生成するために必要とされる全ての情報は、ＲＴＰペイロードで透過される。相手ＭＧにおいてのＢＩＷＦは、ファクシミリ端末へのトーン生成しなければならない。
この方式を使用する前に、メディアゲートウェイが、お互いにＳＤＰ（ＲＦＣ２３２７）交換または、他の呼能力交換メカニズムによって、この方式のサポートを示すべきことが推奨される。それは、本付属資料の範囲外である。
このＲＴＰペイロードタイプをサポートしないゲートウェイは、その動作に影響することなく、それらのパケットを破棄することができなければならない。

方法３
トーンの検出指示：（ＲＦＣ４７３３を参照－ＤＴＭＦディジット、電話トーン、電話信号のためのＲＴＰ
ペイロード）：イベントメッセージ（ＮＴＥ）は、ＲＦＣ４７３３の３．１１節（データモデムとファクシ
ミリイベント）に記述されるようなイベントを通すために使用される。相手のＭＧは、現状態に依存して、ＶＢＤまたは、ＪＴ－Ｔ３８へ切り替わるためにこのメッセージを使用してもよい。そして、ＪＴ－Ｔ３０に記述されるような特性を持つトーンを生成しなければならない。
この方式が使用されるとき、ＲＦＣ４７３３の表３に記述されるような次のイベントが送られる。

イベント

符号（１０進）

ＡＮＳ（＝ＣＥＤ）

３２

ＣＮＧ

３６

Ｖ．２１チャネル２“０”ビット

３９（注参照）

Ｖ．２１チャネル２“１”ビット

４０（注参照）

注－２０１０年以前に承認されＪＴ－Ｔ３８の本付属資料のバージョンで使用されていたＲＦＣ２８３３（現在は廃止され、別のＲＦＣに置き換えられている）には、Ｖ．２１プリアンブルフラグに関して ＲＦＣ
２８３３イベントは存在しなかった。送信ＭＧへ通されるＶ．２１チャネル２のビット“０”そしてビット“１”イベントだけがあった。ファクシミリ呼とデータ呼を識別できるために、受信ＭＧは、 ＲＴＰ Ｎ
ＴＥメッセージ外のプリアンブルフラグの復号ができなければならない。
しかしながら、ＲＦＣ４７３４（ ＲＦＣ２８３３を廃止する ＲＦＣの１つである）は、値５４（１０進）を持つＶ．２１プリアンブルフラグのためのイベントを提供する。以前の実装で必要とされるＶ．２１チャネル２ビット“０”及びビット“１”イベントの代わりに、実装に ＲＦＣ４７３４ Ｖ．２１プリアンブル
フラグイベントを使用することが推奨される。
ＪＴ－Ｔ３８に切り替わる前に、変更前に検出されるべきフラグの数は、受信ＭＧが、送信ＭＧへ十分なＲ
ＦＣ４７３３メッセージを送信するような方法で選択されなければならないパラメータである。

- 93 -

ＪＴ－Ｔ３８

ＪＴ－Ｔ３８へ切り替わった後、Ｖ．２１フラグは、ＵＤＰＴＬ上を通される。
この方式を使用する前に、メディアゲートウェイが、お互いにＳＤＰ交換または、他の呼能力交換メカニズ
ムによって、先に示したＲＴＰペイロードタイプのサポートを示すべきことが推奨される。それは、本付属資料の範囲外である。
これらのＲＴＰペイロードタイプをサポートしないゲートウェイは、その動作に影響することなく、それらのパケットを破棄することができなければならない。

方法４
ＪＴ－Ｔ３８へ切り替わった後、もし、トーン信号がまだあるならば、それから、メディアゲートウェイは、
ファクシミリ信号の存在を通知するために、t30-indicator タイプのＪＴ－Ｔ３８パケットを送信しなければな
らない。

E.2.2.2.2.2 ＶｏＩＰからＦｏＩＰへの遷移評価基準
送信メディアゲートウェイ（ＭＧ）によるＣＮＧの検出において、ＣＮＧは、Ｇ３ＦＥによって送信されるだけなので、それがファクシミリ呼であると十分な確信をもって決定することは可能である。従って、もし、
ＪＴ－Ｔ３８能力がＭＧとの間でお互いに、成功裏にネゴシエーションされているならば、そのＭＧは、Ｊ
Ｔ－Ｔ３８に切り替わり、そしてＪＴ－Ｔ３８プロトコルに従い、ＪＴ－Ｔ３８ＣＮＧインジケータパケッ
トをリモートＭＧへ送信するであろう。リモートＭＧは、ＪＴ－Ｔ３８ＵＤＰ（または、ＴＣＰ）ポート上
で、ＪＴ－Ｔ３８ＣＮＧインジケータパケットの受信により、ＪＴ－Ｔ３８へ切り替わるだろう。

audio/RTP モードの時、指定されるＪＴ－Ｔ３８ＵＤＰ（または、ＴＣＰ）ポート上の任意のＪＴ－Ｔ３８
パケットの受信は、image/t38 モード（Ｅ．２．２．２．２．１節参照）へ切り替わるための評価基準となるべきである。これを実行させる方法の実装は、本付属資料の範囲外である。しかしながら、１つ推奨される方式がある。それは、ＪＴ－Ｔ３８ＵＤＰＴＬパケットのみが、ネゴシエーションされた image/t38ＵＤＰポー
ト番号へ送られなければならないので、もし、そのパケットのソースＩＰアドレスと、ＪＴ－Ｔ３８自動遷移方式（ＪＴ－Ｔ３８能力同様に）がお互いに成功裏にネゴシエーションされたリモートＭＧのそれと一致するならば、ローカルのＵＤＰ（または、ＴＣＰ）ポート上の有効なＵＤＰ（または、ＴＣＰ）パケットの受信は、ＪＴ－Ｔ３８パケットと仮定されてよい。それ故にＪＴ－Ｔ３８への自動的な遷移が引き起こされる。ＪＴ－Ｔ３８ＴＣＰパケットに対しても同様に適用する。ＪＴ－Ｔ３８ＵＤＰ（または、ＴＣＰ）ポー
トは、呼を確立しているＭＧによって、ＪＴ－Ｔ３８自動遷移方式がサポートされている（そして、お互いにＪＴ－Ｔ３８能力をセットしている）ときに唯一活性化されるべきである（ＪＴ－Ｔ３８自動遷移方式がＭＧの間でお互いにサポートされていなければ、これは、任意の有効なＵＤＰパケットの受信による誤ったＪＴ－Ｔ３８への自動的な遷移をさけられるだろう）。

自動方式により動作しているＭＧは、ただ単にＣＮＧトーンの検出を頼りにしてはならない。このトーンは、
ＪＴ－Ｔ３０の１９９３バージョン以降に相当するＪＴ－Ｔ３０に適合する自動Ｇ３ＦＥおよび、手動Ｇ３ＦＥのために唯一必須であるためである。

ＣＮＧが提供されないならば、それから、ＭＧは、Ｖ．３４Ｇ３ＦＥを除く全てのＧ３ＦＥから送られる、
Ｖ．２１プリアンブルの検出によってＪＴ－Ｔ３８へ遷移しなければならない。Ｖ．３４ファクシミリが使用するＶ．８信号は、１０節の手順をサポートするために、ＭＧによって検出されなければならないだろう。
ＪＴ－Ｔ３８プロトコルは、ＪＴ－Ｔ３８ Ｖ．２１フラグインジケータパケットを続ける。ＪＴ－Ｔ３８
Ｖ．２１インジケータパケットの受信により、送信ＭＧは、すでにＪＴ－Ｔ３８モードでなければ、ＪＴ－- 94 -

ＪＴ－Ｔ３８

Ｔ３８へ遷移しなければならない。

付加的に、メディアゲートウェイによってお互いサポートされるものが、（ＳＤＰ交換または、他の手段によって）呼に関係したならば、メディアゲートウェイは、ＲＦＣ４７３３イベント（例えば、Ｅ．２．２．
２．２．１節に述べられた方式３）を使用して、パケット網上の相手のＭＧへＶ．２１プリアンブルを送信することを選択してもよい。ＲＦＣ４７３３は、チャネルごとにＦＳＫで符号化されたバイナリ情報を中継するために４つの専用のイベント（３７－４０）を定義している。この方式を使用するとき、ＲＦＣ４７３
３のＲＴＰパケットは、ＲＦＣ４７３３／ＲＦＣ２１９８に記述されるような冗長的なメカニズムを使用することによるのと同様にグループ化しているイベントによって生成されなければならない。
Ｖ．８信号ＣＩ／ＣＭ／ＪＭでのファクシミリへの呼機能設定の検出は、image/t38 モードへの遷移および、
１０章の手順も示さなければならない。付属資料Ｆも参照のこと。

ＪＴ－Ｔ３８自動遷移方式をサポートするメディアゲートウェイは、ＣＥＤトーンの検出に基づいてファク
シミリへの遷移を決定すべきではない。ＣＥＤトーンは、ＡＮＳトーン（Ｖ．２５に定義される）ような同じトーンである。後者のトーンは、ある非ファクシミリモデムによって送信される。

ＪＴ－Ｔ３８がＭＧの１つによってサポートされていないならば、ＭＧが、オーディオメディア記述子にＪＴ－Ｇ７１１が受信された場合だけ、ＪＴ－Ｇ７１１上のファクシミリ呼を試みてもよい（この場合にＪＴ－Ｇ７１１を用いることは本付属資料の範囲外である）ことに注意すること。

E.2.2.2.2.3 ＦｏＩＰからＶｏＩＰへの遷移評価基準
ＭＧが次の１つを検出したとき、ファクシミリ（image/t38 接続）から音声（audio/RTP 接続）へ自動的に遷移しなければならない。

ａ）ＪＴ－Ｔ３０ ＤＣＮメッセージの検出：ＪＴ－Ｔ３０ ＤＣＮメッセージの検出に続いて、Ｍ
Ｇは、対応するＪＴ－Ｔ３８パケットを送信するだろう。そして、その後、音声へ遷移する。Ｊ
Ｔ－Ｔ３８／ＪＴ－Ｔ３０ ＤＣＮパケットの受信に続いてＭＧは、ＪＴ－Ｔ３０ ＤＣＮを送出するだろう。そして、その後、音声へ遷移する。

ｂ）双方向の無音の検出：双方向の７秒以上の無音検出後、ＭＧが音声モードへ戻ることが推奨される。
（この値は、ＪＴ－Ｔ３０

Ｔ２タイマとして認められるために選択された）ｃ）ＭＧＣからのオーディオ呼へ変更する適切なコマンドの受信。Ｈ．２４８Modify コマンド、オー
ディオ記述子だけが提供されるＳＩＰの INVITE コマンドまたは、ＪＴ－Ｈ３２３付属資料ＤのＤ．５節によるような適切なメッセージがこれを実行できる。

E.2.3 イベントと信号の表示
ファクシミリの呼設定の間に ＭＧからＭＧＣへ（またはその逆へ）伝送される必要があるいくらかのイベ
ントと信号がある。これらのイベントは、Ｈ．２４８パッケージにおいて定義される。基本のパッケージは、
ＪＴ－Ｈ２４８．１付属資料Ｅにある。ファクシミリのための追加信号は、Ｈ．２４８．２によって定義される。

- 95 -

ＪＴ－Ｔ３８E.2.4 能力ネゴシエーション
メディアゲートウェイがどちらのオプションをサポートして使うかを決定するために、ネゴシエーションされる必要があるいくつかのオプションがある。これらは、付表Ｂ．１／ＪＴ－Ｔ３８に示され、Ｄ．２．３
節のＳＤＰ拡張として定義されている。それらはまた、Ｈ．２４８．２のＩＰファクシミリパッケージでバ
イナリタイプとして定義されている。

ＪＴ－Ｔ３８の付属資料Ｅの実装は、プロトコルのテキストモードにおいてファクシミリメディアターミ
ネーションを示すためにＳＤＰ拡張を使用してもよい。ＪＴ－Ｈ２４８．１の実装は、ファクシミリメディ
アターミネーションを示す優先される方法としてＩＰファクシミリパッケージを使わなければならない。これらのメディア記述子は、メディアゲートウェイ（例えば、ＴＣＰ、ＵＤＰＴＬまたはＲＴＰトランスポート）の能力または要求を示す。

さらに、呼がファクシミリのためにＪＴ－Ｔ３８トランスポートを使用していることを識別可能としているのと同様にＪＴ－Ｈ２４８．１もまた他のトランスポートを示してもよい。

E.2.5 呼設定の例
ＪＴ－Ｔ３８

ＭＧＣ手順の例は、付録Ⅲ．２．１節および、付録Ⅲ．２．２節で示される。

ＪＴ－Ｔ３８自動遷移方式の例は、付録Ⅲ．２．３節および、付録Ⅲ．２．４節に示される。

E.2.6 最低限の発呼メッセージ本付属資料の実装は、８．２節で示されたＪＴ－Ｈ２４８．１の最低限の必要条件をサポートしなければな
らない。

E.2.7 発呼経過表示信号のマッピング
呼設定と発呼経過のために、応答信号はＪＴ－Ｔ３８付属資料Ｂの信号（ＪＴ－Ｈ３２３ファーストコネク
ト設定のためのもの）と付属資料Ｄの信号（ＳＩＰのためのもの）が識別される。

E.2.8 ＤＴＭＦ送信
ＪＴ－Ｈ２４８．１は発呼するために、ＤＴＭＦディジットの収集をサポートする。音声とファクシミリ呼の接続が確立している間のＤＴＭＦトーンの送出は、ＪＴ－Ｈ２４８．１の付属資料Ｅ．５節とＥ．６節のＤＴＭＦパッケージ中で扱われる。

E.2.9 相互接続性
ＪＴ－Ｈ２４８．１と付属資料Ｂの両方は、コールシグナリングを開始するのに既知のポートを必要とする。
付属資料Ｅのエンドポイントは、テキストプロトコルのための２９４４とバイナリプロトコルのための２９４５のＪＴ－Ｈ２４８．１の既知のポートを使用しなければならない。

- 96 -

ＪＴ－Ｔ３８

付属資料

Ｆ（ＪＴ－Ｔ３８に対する）相互に作用する手順：同一ゲートウェイ内のＪＴ－Ｔ３８とＶ．１５０．１（この付属資料は、本標準の必須部分を形成する）

F.1 はじめに本付属資料は、同一のゲートウェイ内にＪＴ－Ｔ３８とＶ．１５０．１の能力を持っているゲートウェイが使用しなければならない手順について記述する。そのようなゲートウェイは、関連した勧告で定義される適
当な外部シグナリングメカニズム（ＪＴ－Ｈ３２３、Ｈ．２４８またはＳＩＰ／ＳＤＰ）の使用によってこれらの能力を示さなければならない。本付属資料で使用される「ＦｏＩＰ」と「ＭｏＩＰ(Modem Over IP)」の用語は、それぞれＪＴ－Ｔ３８とＶ．１５０．１と同義語である。
このタイプのゲートウェイはＭｏＩＰからＦｏＩＰへの遷移のみしなければならない。これらの手順は、直接オーディオからＦｏＩＰへの遷移を含まないし、また、付属資料Ｂ、ＤとＥで定義されるオーディオとＪ
Ｔ－Ｔ３８設定手順の置き換えもしない。

これらの結合能力を持ったゲートウェイは、最初にＶ．１５０．１ゲートウェイとして振舞わなければならない。それはＶ．１５０．１の２０章で定義され、ＪＴ－Ｔ３８手順が起動されるポイントまでの呼識別手
順のすべてである。
ＭｏＩＰからＦｏＩＰへの遷移は、ゲートウェイへの電話回線上でＶ．２１チャネル２のＨＤＬＣ符号化されたフラグやＶ．８ ＣＭシグナルのようなＪＴ－Ｔ３０ファクシミリ信号の存在がＭｏＩＰモードにある
ゲートウェイで検出され検証されたときに発生する。

この切り替えメカニズムはＶ．１５０．１付属資料Ｃに定義されるステータスシグナリングイベント（ＳＳＥ）手順を使用しなければならない。付図Ｆ．１／ＪＴ－Ｔ３８と付図Ｆ．２／ＪＴ－Ｔ３８では、２つのファクシミリのトリガーとなるイベントのための遷移を表している。付図Ｆ．１／ＪＴ－Ｔ３８は一般的なＧ３ファクシミリへの遷移を示し、付図Ｆ．２／ＪＴ－Ｔ３８は同様なＶ．３４ファクシミリへの遷移を示
す。

F1

G1

G2

F2
Audio

Audio
V21(H)flags
facsimile/JT-T38

SSE:f(V21Flags)
facsimile/JT-T38

SSE:f(p’)
Link1

JT-T38Link2

付図Ｆ．１／ＪＴ－Ｔ３８
ＪＴ－Ｔ３８ＦｏＩＰ（ＪＴ－Ｔ３０ファクシミリへのＭｏＩＰ遷移）（ＩＴＵ－Ｔ

Ｔ．３８）- 97 -

ＪＴ－Ｔ３８

F1

G1

G2
Audio

F2
Audio

V.8-CM=V.34 fax
SSE:f(V34 fax)

facsimile/JT-T38

facsimile/JT-T38
SSE:f(p’)
Link1

JT-T38Link2

付図Ｆ．２／ＪＴ－Ｔ３８
ＪＴ－Ｔ３８ＦｏＩＰ（Ｖ．３４ファクシミリへのＭｏＩＰ遷移）（ＩＴＵ－Ｔ

Ｔ．３８）

ファクシミリイベントを検出すると、ゲートウェイは対となるゲートウェイにＳＳＥ：ｆ（ＲＩＣ）を送信
しなければならない。ＳＳＥ：ｆはＦＡＸ ＲＥＬＡＹ ＳＳＥ遷移を示すものである。ＲＩＣは原因識別コードであり、Ｆ．２節に定義される。ＳＳＥの使用はＶ．１５０．１付属資料Ｃに従わなければならない。

Ｖ．１５０．１では、Ｖ．１５０．１のＣ．５．２節でＳＳＥ：ｆイベントコードを定義し、それは４の１０進値を持つ。

F.2 ＪＴ－Ｔ３８遷移のためのＳＳＥ原因識別コード
次のＲＩＣはＳＳＥ：ｆイベントで定義される：

Ｖ２１Ｆｌａｇｓ：このＲＩＣは、ゲートウェイがＪＴ－Ｔ３０で定義されるＶ．２１チャネル２で変調されたＨＤＬＣフラグを受信したことを検出し検証したことを示している。

Ｖ８Ｐｒｏｆｉｌｅ：このＲＩＣは、ゲートウェイが有効なファクシミリ接続要求であるＶ．８ ＣＭシー
ケンスを受信したことを示す。このＲＩＣは付加情報である－そのプロファイルと（もしあるのであれば）Ｔ．６６コード－それは、本標準での「t30-data(cm-message)」のなかで使用される。

Ｐ‘Ｓｔａｔｅ Ｔｒａｎｓｉｔｉｏｎ：これはＭｏＩＰで使用されているのと同じ信号である。Ａｃｋと同じ振る舞いをする。
下表はＪＴ－Ｔ３８

ＳＳＥでのＲＩＣの要約である。

名称

コード

付加情報の内容（１０進数）

Null

0

None

V21Flags

1

None

V8Profile2"cm-message"p' State Transition

19

None

両方の例では、ＳＳＥ：ｆの使用はＪＴ－Ｔ３８からの等しいシグナルとして使用してよい。例えばＳＳＥ：
ｆ（Ｖ２１ Ｆｌａｇ）は t30-indicator:FLAGS として使用してよい、そして、ＳＳＥ：ｆ（Ｖ８ｐｒｏｆｉ- 98 -

ＪＴ－Ｔ３８ｌｅ（ｃｍ－ｍｅｓｓａｇｅ））は t30-data:cm-message として使用してよい。

ゲートウェイは、そのＳＳＥ：ｆ要求の応答でＳＳＥ：ｆ（ｐ‘）メッセージを待つことを要求されない。
そのゲートウェイは、ＳＳＥ：ｆｒ要求を発行後直ちに等価なＪＴ－Ｔ３８ ＩＦＴメッセージを送信しなければならない。そのゲートウェイは、そのとき本標準で定義されている手順を継続しなければならない。

F.3 Ｖ．３４グループ３ファクシミリから標準のグループ３ファクシミリへの遷移方式
本付属資料では、Ｖ．３４半二重通信方式を持つ端末が、メディアゲートウェイによって強制的に標準のグ
ループ３方式へ遷移するための手続きを記述している。 この手続きは、両方のファクシミリ端末がＶ．３
４ Ｇ３ＦＥであり、ゲートウェイに接続されたどちらか一方または両方が、本標準の１０章に定義されているＪＴ－Ｔ３８やＶ．３４の制御を行うことの出来ない場合に使用することが出来る。

Ｖ．８のＣＭ信号を検出したとき、Ｃａｌｌ Ｆｕｎｃｔｉｏｎを確認することで、Ｖ．３４通信が可能なファクシミリ端末によって送信されたＣＭ信号であるかどうか、ゲートウェイが判断すべきである。
ここで判断されると、ゲートウェイは音声送信を停止して無音にしなければならない。 呼が切断しないよ
うに、ゲートウェイはＣＭ信号を送信してはならない。

応答した端末でタイムアウトが発生すると、ＣＭ信号を停止し、その結果として標準のＪＴ－Ｔ３０信号が送受信されるであろう（ＪＴ－Ｔ３０の図３－５ａ、および図３－５ｂ参照）。 電話回線上のＶ．２１フラグのようなＪＴ－Ｔ３０ファクシミリ信号が現れたことをゲートウェイが検出し、確認できるとＭｏＩＰからＦｏＩＰへの遷移が起こる。 さらに端末がＶ．３４を使用して接続しようとすることを防ぐためには、
ゲートウェイによって送られるＪＴ－Ｔ３０のＤＩＳ信号のＶ．８ビットを０にすべきである。

この切替えの仕組みは、Ｖ．１５０．１付属資料Ｃに定義されているステータスシグナリングイベント（ＳＳＥ）手順、もしくはＶ．１５２の１０章で定義されているペイロードタイプ手順を使用しなければならない。

付図Ｆ．３／ＪＴ－Ｔ３８にステータスシグナリングイベント手順を使った、標準のファクシミリへの遷移
を表す。
F1

G1

G2

F2

Audio
G1 Cut CM

Audio

V.8-CM=V.34 fax
V.21(H)flags
SSE:f(V21Flags)Facsimile/JT-T38
Facsimile/JT-T38
Link1

SSE:f(p’)
Link2

T.38
IFP:

DIS(v.8 bit = 0)

DIS hdlc-data

DIS(v.8 bit = 1)

付図Ｆ．３／ＪＴ－Ｔ３８
ＪＴ－Ｔ３８ ＦｏＩＰ(ＭｏＩＰからＪＴ－Ｔ３０ファクシミリへのＳＳＥによるフォールバックと遷移)（ＩＴＵ－Ｔ

Ｔ．３８）- 99 -

ＪＴ－Ｔ３８

付図Ｆ．４にペイロードタイプ切替え手順を使った、標準のファクシミリへの遷移を表す。

F1

G1

G2

F2

Voice mode
/ANSam/ANSam

IP:/ANSamVBD mode (or JT-G711)/ANSamIP JT-G711:/ANSam/ANSam/ANSam

CM

CM1

CM2

CM 信号の Call Function で
FAX であることを検出す

CM3

ると VBD 信号を停止する

タイム
アウト

V.21 flags

IP JT-G711:v21flags

V.21 flags

V.21

タイム
JT-T38 mode

アウト
V.21 flags

T30IND:Flags

flags

V.21 flags

V.21:HDLC: DIS/
DIS(V.8bit = 0)

FCS(reset V.8bit=0)

DIS

DIS

V.21 flags

T30IND:Flags

V.21 flags

V.21
flags

DCS

付図Ｆ．４／ＪＴ－Ｔ３８
ＪＴ－Ｔ３８ ＦｏＩＰ（ＭｏＩＰからＪＴ－Ｔ３０ファクシミリへのペイロードによるフォールバックと遷移）（ＩＴＵ－Ｔ

Ｔ．３８）- 100 -

ＪＴ－Ｔ３８

F.4 外部シグナリング
ＳＳＥの使用は、呼設定フェーズの間にネゴシエーションされる。Ｖ．１５０．１の付属資料ＥとＦは、結果的に、ＭｏＩＰ／ＦｏＩＰゲートウェイに組み込まれるためのＳＤＰとＨ．３２３構文を記述している。
（注）Ｖ．１５０．１のためのＨ．２４８構文の定義は定義されることになっている。

- 101 -

ＪＴ－Ｔ３８

付属資料

Ｇ（ＪＴ－Ｔ３８に対する）
ＲＴＰ上のＪＴ－Ｔ３８のためのＪＴ－Ｈ２４５能力定義（この付属資料は、本標準の必須部分を形成する）

本付属資料は、ＲＴＰ上のＪＴ－Ｔ３８転送を考慮した一般的なＪＴ－Ｈ２４５能力を定義する。この能力
がＪＴ－Ｈ２４５に基づいたシステム内の audioCapability として示されるであろうことが意図されている。

ＪＴ－Ｈ２４５はすでにＵＤＰとＴＣＰ上のＩＦＰパケット転送のためのＪＴ－Ｔ３８能力が定義されていることに注意する、それは dataApplicationCapability である。その能力の定義は本付属資料でその定義の置
き換えを意図していないが、ＲＴＰ上のＪＴ－Ｔ３８ ＩＦＰパケットを転送する方法を提供するのみである。

Capability name:

T38RTP

Capability class:

Audio Capability

Capability identifier type:

Standard

Capability identifier value:

itu-t(0) recommendation(0)t(20)38 h245-audio-capability(0)maxBitRate:

このパラメータはオプション。

collapsing:

このフィールドは含まれてはならない、もし受信しても無視されなければならない。

nonCollapsing:

このフィールドは存在しなければならず、以下で定義されたパラメータで構成される。

nonCollapsingRaw:

このフィールドは含まれないし、もし受信しても無視されなければならない。

transport:

このフィールドは含まれてはならない。

この能力のためのパラメータは次の表に定義される：

Parameter name:

BooleanOptions

Parameter description:

これは nonCollapsing 能力である。
伝えられなければならない様々なブール・オプションを含んでいる。

Parameter identifier value:0

Parameter status:

必須

Parameter type:

BooleanArrayLSB は bit0。Bit 値は１で TRUE。
Bit0-fillBitRemoval
Bit1-transcodingJBIG
Bit2-transcodingMMR
他の bits はすべて予約され、無視されなければならない。

Supersedes:－- 102 -

ＪＴ－Ｔ３８Parameter name:VersionParameter description:

これは nonCollapsing 能力である。
これはＪＴ－Ｔ３８プロトコルのバージョンを識別する。

Parameter identifier value:

1

Parameter status:

オプショナル。存在しない場合、バージョンは 0 に仮定される。

Parameter type:

UnsignedMin

Supersedes:－

Parameter name:

T38FaxRateManagement

Parameter description:

これは nonCollapsing 能力である。
これはファクシミリレートマネージメントモードを指定する。

Parameter identifier value:

2

Parameter status:

必須。T38FaxRateManagement の 1 つのサブパラメータのみがこのパラメータに含まれもよい。

Parameter type:genericParameter

Supersedes:－

Parameter name:

T38FaxRateManagement-localTCF

Parameter description:

これは T38FaxRateManagement の要素である nonCollapsing 能力である。

Parameter identifier value:0

Parameter status:

オプショナルParameter type:logicalSupersedes:－

Parameter name:

T38FaxRateManagement-transferredTCF

Parameter description:

これは T38FaxRateManagement の要素である nonCollapsing 能力である。

Parameter identifier value:

1

Parameter status:

オプショナルParameter type:logicalSupersedes:－

Parameter name:t38FaxMaxBuffer

Parameter description:

これは nonCollapsing 能力である。
これは最大バッファサイズを指定する。

Parameter identifier value:

3

Parameter status:

オプショナルParameter type:unsigned32Max

Supersedes:－- 103 -

ＪＴ－Ｔ３８Parameter name:t38FaxMaxDatagram

Parameter description:

これは nonCollapsing 能力である。
これは最大データグラムサイズを指定する。

Parameter identifier value:

4

Parameter status:

オプショナルParameter type:unsigned32Max

Supersedes:－- 104 -

ＪＴ－Ｔ３８

付属資料

Ｈ（ＪＴ－Ｔ３８に対する）通知や提供されるＪＴ－Ｔ３８プロトコルパラメータ（この付属資料は、本標準の必須部分を形成する）

H.1

はじめに

ＪＴ－Ｔ３８エンドポイントの呼の個別構成では、一部のＪＴ－Ｔ３８パラメータのネゴシエーションが必要である。 本付属資料の目的は、ＪＴ－Ｔ３８エンドポイントとＶ．１５２～ＪＴ－Ｔ３８（Ｖ．１５３）の相互接続機能の構成と、 デフォルトパラメータ値の定義を明確にすることである。
付表Ｈ．１／ＪＴ－Ｔ３８は、ＪＴ－Ｔ３８シグナリングプロトコルタイプに依存せず、Ｔ３８トランスポー
トモードとは独立した、すべてのＪＴ－Ｔ３８パラメータの要約である。 デフォルト値は太字。

付表Ｈ．１／ＪＴ－Ｔ３８

構成（ＪＴ－Ｔ３８パラメータ／設定値；一般的なフォーマット、

すなわち、シグナリングプロトコルに依存しない 無条件なＪＴ－Ｔ３８トランスポート）（ＩＴＵ－Ｔ
No.

Ｔ．３８）

パラメータ

値

0

T38 Transport ModeUDPTL/UDP | RTP/UDP | TPKT/TCP

1

T38FaxVersion

0 | 1 | 2 | 3 | 42

T38MaxBitRate

9600 | 14400 | 33600

3

T38FaxFillBitRemoval

FALSE | TRUE

4

T38FaxTranscodingMMR

FALSE | TRUE

5

T38FaxTranscodingJBIG

FALSE | TRUE

6

T38FaxRateManagement

localTCF | transferredTCF

7

T38FaxMaxBuffer… | 1800 | …

8

T38FaxMaxDatagram… | 150 | …

9

T38FaxMaxIFP… | 40 | …

10

T38FaxUdpEC

t38UDPFEC | t38UDPRedundancy | t38UDPNoEC

11

T38FaxUdpECDepth

minred:… | 1 | …
maxred:… | none | …

H.2

12

T38FaxUdpFECMaxSpan… | 3 | …

13

T38VendorInfo$ … $ | parameter omitted

14

T38ModemType

t38G3FaxOnly | t38G3AndV34G3

トランスポート条件付きＪＴ－Ｔ３８パラメータ

H.2.1 ＪＴ－Ｔ３８ ＩＦＰパケットのトランスポートモード
一部のＪＴ－Ｔ３８パラメータは、適用されるトランスポートモード（ＵＤＰＴＬ／ＵＤＰ｜ＲＴＰ／ＵＤ
Ｐ｜ＴＰＫＴ／ＴＣＰ）に依存する。 したがって、 ＪＴ－Ｔ３８の必須パラメータとオプションパラメー
タは、相互に同意されたＪＴ－Ｔ３８トランスポートの条件下で考慮されることがある。
ＪＴ－Ｔ３８トランスポートは、ＳＤＰで "c ="行（IP バージョン）と "m ="行（'proto' フィールド）を介してネゴシエーションされる。

- 105 -

ＪＴ－Ｔ３８

H.2.2 トランスポート依存 のＪＴ－Ｔ３８パラメータの概要
H.2.2.1“ＵＤＰＴＬ／ＵＤＰ”トランスポートモード

付表Ｈ．２／ＪＴ－Ｔ３８は、定義されているＪＴ－Ｔ３８のすべてのパラメータの要約を示す。 すべてのパラメータは主に任意であり、コントロールプレーンシグナリングプロトコルにおいては省略してもよい。
シグナリングメッセージにパラメータが無い場合は、ローカルのＪＴ－Ｔ３８エンドポイントはデフォルトのパラメータ値を適用する。デフォルトのパラメータ値は、ＪＴ－Ｔ３８自体により暗黙的に与えられていない場合、「ＪＴ－Ｔ３８プロファイル」定義（例えば、ＳＩＰまたはＨ．２４８インタフェースプロファ
イルのサブセットであってもよい）において更新されるかもしれない。

- 106 -

ＪＴ－Ｔ３８

付表Ｈ．２／ＪＴ－Ｔ３８

ＳＤＰパラメータ（ＳＤＰ

ＲＦＣ３２６４能力ネゴシエーションプロトコルによるセマンティック）（１）ネゴシエーションされたＩＰトランスポート＝ＵＤＰＴＬ／ＵＤＰ（ＩＴＵ－Ｔ
番号

１

名前

バージョン

構文（ＳＤＰ）

T38FaxVersion

Ｔ．３８）

セマンティック（ＳＩＰ／ＳＤＰ）

必須／

Ｄ．２．３．５節参照

オプション

型,単位

デフォルト
値

本パラメータはネゴシエーションされる。 オファーに応答するエン推奨（注８）INTEGER

ティティは、同じかまたは低いバージョン番号を返す

省略時はデフォ(0..255), [-]

0

ルト値
２

３

４

５

６

最大ビットレート

フィルビット削除

ＭＭＲ変換

ＪＢＩＧ変換

データレート本パラメータは宣言型で、アンサーはオファーに影響されない。パラ

T38MaxBitRate

T38FaxFillBitRemoval

T38FaxTranscodingMMR

T38FaxTranscodingJBIG

T38FaxRateManagement

管理方法

推奨（注９）INTEGER

14400

メータは単にエンドポイントによってサポートされる最大送信ビット

省略時はデフォ(0..216–1), [bit/s]（注１）

レートを表すルト値（注６）

本パラメータはネゴシエーションされる。アンサーのエンティティがオプション

BOOLEAN, [-]FALSE

この機能をサポートしない場合、またはこの機能がオファーに無い場

省略時はデフォ合は、このパラメータはアンサーに含まれてはならない。

ルト値

本パラメータはネゴシエーションされる。アンサーのエンティティがオプション

BOOLEAN, [-]FALSE

この機能をサポートしない場合、またはこの機能がオファーに無い場

省略時はデフォ合は、このパラメータはアンサーに含まれてはならない。

ルト値

本パラメータはネゴシエーションされる。アンサーのエンティティがオプション

BOOLEAN, [-]FALSE

この機能をサポートしない場合、またはこの機能がオファーに無い場

省略時はデフォ合は、このパラメータはアンサーに含まれてはならない。

ルト値

本パラメータは宣言型で、アンサーには同じ値が含まれている必要が

必須

ENUMERATION'transferredる。

省略時はデフォ

, [-]

TCF'

ルト値

- 107 -

ＪＴ－Ｔ３８

（注４）

番号

７

名前

最大バッファ

構文（ＳＤＰ）

セマンティック（ＳＩＰ／ＳＤＰ）

必須／

Ｄ．２．３．５節参照

オプション

本パラメータは宣言型で、アンサーはオファーに影響されない。 この

T38FaxMaxBuffer

サイズ

型,単位

デフォルト
値

オプション

INTEGER

パラメータは、オファーのエンドポイントとアンサーのエンドポイン

省略時はデフォ

216–1), [bytes]（注２）

トで使用可能なバッファの空きを通知する。アンサーのエンドポイン

ルト値

(0..

1800

トは、オファーのエンドポイントよりも多少のバッファスペースを持
つことがある。 各エンドポイントは、反対側のエンドポイントで使用可能なバッファスペースを考慮する必要がある
８

最大データグラム

T38FaxMaxDatagram

サイズ

本パラメータは宣言型で、アンサーはオファーに影響されない。 このオプション

INTEGER

150

パラメータは、オファーのエンドポイントおよびアンサーのエンドポ

省略時はデフォ(0..216–1), [bytes]（注３）

イント（すなわち、ｘｙｚペイロードの最大サイズ）についての最大

ルト値

許容データグラムを通知する。 アンサーのエンドポイントは、オファーのエンドポイントよりも大きいまたは小さいデータグラムを受け入れるかもしれない。 各エンドポイントは、反対側のエンドポイン
トの最大データグラムサイズを考慮する必要がある
９

最大ＩＦＰサイズ

T38FaxMaxIFP

本パラメータは宣言型で、アンサーはオファーに影響されない。 パラオプション

INTEGER40 （注３）メータは単純にオファーのエンドポイントが許容できる最大ＩＦＰフ

省略時はデフォ(0..216–1), [bytes]（注７）

レームサイズを表す

ルト値
T38FaxMaxIFP がオファーに含まれるなら、T38FaxMaxDatagr
am もオファーでは必須となる- 108 -

ＪＴ－Ｔ３８

番号

１０

名前

エラー訂正

構文（ＳＤＰ）

T38FaxUdpEC

セマンティック（ＳＩＰ／ＳＤＰ）

必須／

Ｄ．２．３．５節参照

オプション

型,単位

デフォルト
値

本パラメータは、トランスポートとしてＵＤＰＴＬを使用する場合にオプション

ENUMERATION't38UDPRe

のみネゴシエーションされる。 応答するエンドポイントが提示された

省略時はデフォ, [-]dund ancy'

エラー訂正モードをサポートしている場合、アンサーでは同じ値を返

ルト値

（注５）

す。 そうでなければ T38FaxUdpEC パラメータはアンサーに含まれてはならない。
１１

エラー訂正スパン

T38FaxUdpECDepth

本パラメータは宣言型で、アンサーはオファーに影響されず、ＵＤＰ

オプション

INTEGER

1

ＴＬをトランスポートとして使用する場合にのみ関係する。 このパラ

省略時はデフォ(0..216–1),

は’minred’

メータが指定されている場合、 'minred'値は、提示するエンドポイント

ルト値[frames]

2

がＵＤＰＴＬデータグラムあたり多くの冗長フレームを少なくとも受は’maxred’

信したいことを示している（アンサーのエンドポイントがエラー訂正（注３）

モードとして t38UDPRedundancy を使用することを選択した場合）。
または提示するエンドポイントがＵＤＰＴＬデータグラムあたり多くのＦＥＣフレームを少なくとも受信したいことを示している（応答するエンドポイントがエラー訂正モードとして t38UDPFEC を使用する
ことを選択した場合）。 さらに、 'maxred'が指定されている場合は、提示するエンドポイントがＵＤＰＴＬデータグラムあたり多くの冗長フレームまたはＦＥＣフレームを受信したいことを示している。
１２

エラー訂正間隔

T38FaxUdpFECMaxSpan

本パラメータは宣言型で、アンサーはオファーに影響されない。ＵＤオプション

INTEGERＰＴＬをトランスポートとして使用する場合にのみ関係する。 このパ

省略時はデフォ(0..216–1),

ラメータを指定すると、提示するエンドポイントが指定された数以上

ルト値[frames]のＩＦＰフレームにまたがるＦＥＣフレームを適切に処理できないことがある。

- 109 -

ＪＴ－Ｔ３８

3）

番号

１３

名前

ベンダー情報構文（ＳＤＰ）

セマンティック（ＳＩＰ／ＳＤＰ）

必須／

Ｄ．２．３．５節参照

オプション

本パラメータは宣言型で、アンサーはオファーに影響されない。本パ

T38VendorInfo

オプション

ラメータはエンドポイントの製造元を表す。

型,単位

デフォルト
値

スペースで区切デフォルトられた３つの値は設定さINTEGERれていないリスト（注１０）
１４

サポートモデム

T38ModemType

本パラメータは宣言型で、ゲートウェイがサポートするモデム機能を

オプション

表す。

省略時はデフォ

列挙

T38G3Fax
Only

ルト値(0)（注１） Ｖ．１７モデムのビットレートは、Ｖ．１７モデム速度をサポートしている大半の展開済みＧ３ＦＥデバイスのために、デフォルト値として使用される。
（注２） 提案されているデフォルトの最大バッファサイズは、１秒間の Ｖ．１７モデムデータの控えめな推定値（14400bit/s×1 秒 = 1800Byte）に関連している。
（注３） 最大データグラムサイズ（ＵＤＰＴＬ ＰＤＵの最大サイズ）は、パケット化時間、最大ビットレート（モデム速度）および冗長度（ＦＥＣ）の結果である。１５０バイトのデフォルト値案は、最も速いモデム速度、最大冗長レベル“３”、おびパケット化時間２０ｍｓの条件下での控えめな推定値を表している。 T38FaxMaxDatagram、T38FaxMaxIFP および
T38FaxUdpECDepth の関係は、次のように定義できる。
T38FaxMaxDatagram≧UDPTL ヘッダー+ T38FaxMaxIFP + T38FaxUdpECDepth *（ＦＥＣあたりのバイト数または冗長フレームあたりのバイト数）+ ＡＳＮ．１構造体によるエラー回復のための追加バイト（注４）データレート管理方法２はＵＤＰに対して必須であるため（８．２節参照）。
（注５）パケット冗長方式は、前方エラー訂正方法としてより簡単で広範に展開されるため（注６）T38MaxBitRate パラメータの単位値の解釈は、特定のプロトコルに固有のものである（注７）デフォルト値は T38FaxMaxDatagram（上記注３）と同様に計算されている（注８）主なＪＴ－Ｔ３８能力設定は、特定の ＪＴ－Ｔ３８バージョンに関連する。したがって、このパラメータを通知することを推奨する。
（注９）このパラメータは、潜在的な相互運用性の問題を回避するために通知されることが推奨される（ ＪＴ－Ｈ３２３によって制御される ＪＴ－Ｔ３８エンドポイントに対してこのパラメータに従うＢ．３．７節を参照）。
（注１０）Ｄ．２．３．１節及びＤ．２．３．２節を参照- 110 -

ＪＴ－Ｔ３８

H.2.2.2 ＴＰＫＴ／ＴＣＰ 転送モード
要検討
H.2.2.3 ＲＴＰ／ＵＤＰ 転送モード
要検討

H.3 ＪＴ－Ｔ３８プロトコルパラメータを通知するためのガイドライン
デフォルトの ＪＴ－Ｔ３８構成は、特定のＪＴ－Ｔ３８ドメインのすべてのＪＴ－Ｔ３８エンティティに提供することができ、それはＪＴ－Ｔ３８オンランプとオフランプゲートウェイまたはＩＡＦ間のすべての構
成詳細の表示、シグナリング、そしてネゴシエーションを省略できる。
ただし、完全なプロビジョニングのアプローチは推奨されない。主な理由は次のとおり。
-

ＪＴ－Ｔ３８パラメータのデフォルト値は、ＪＴ－Ｔ３８の第１版～第３．１版では完全に指定されていないため、潜在的なあいまいさがある。

-

異なるＪＴ－Ｔ３８の版番号で異なるデフォルト値設定を使用できることを除外することはできない。

-

単一のＪＴ－Ｔ３８ドメインの空間的な境界は、複数のＩＰネットワークドメインにまたがる場合もある。（例えば、異なるプロバイダドメイン内に位置するＪＴ－Ｔ３８エンドポイントや、各プロバイダ
は、それ自体好ましいＪＴ－Ｔ３８デフォルト構成 設定を有する。）

したがって、完全なＪＴ－Ｔ３８構成設定を通知することを推奨する。 例えば：-必須のＪＴ－Ｔ３８パラメータを通知するだけでは、ＪＴ－Ｔ３８の版番号に依存した機能設定のためには不十分とみなされる。

-

または、特定のＪＴ－Ｔ３８機能設定を参照するためにＪＴ－Ｔ３８のバージョン番号を（パラメータ
T38FaxVersion を介して）通知することは、前のＪＴ－Ｔ３８の版番号におけるこのパラメータの任意の特性のために不十分であると考えらる 。

H.4 ＳＤＰパラメータのレガシーな解釈
H.4.1 T38MaxBitRate
本標準の第６版以前は、T38MaxBitRate パラメータの単位が定義されていなかった。したがって、多くの実装でこの単位に異なる値が使用されている。この見落としは修正されたが、実装間に潜在的な相互運用性の問題が存在する。ＳＤＰの変更はＡＳＮ．１の構文バージョン番号によって管理されていないので、この節の目的は、これらの違いを管理する方法に関するガイダンスを提供することである。
このパラメータで使用される値は、実装によってサポートされる様々な最大グループ３ビットレートを表し、結果として、{33600,31200,28800,26400,24000,21600,19200,14400,12000,9600,7200,4800,2400}をサポートしている。実装者は、１００ｂｉｔ／ｓまたは１ｂｉｔ／ｓの単位を使用して、T38MaxBitRate でこれらの値を表している。
パラメータを受け取ると、上記設定に記載されている値がある場合、単位は１ｂｉｔ／ｓと見なすことができる。しかし、値が{336,312,288,264,240,216,192,144,120,96,72,48,24}の組にある場合、仮定される単位は１００ｂｉｔ／ｓである。
ほとんどの実装者によれば、この分野では１００ｂｉｔ／ｓと１ｂｉｔ／ｓの単位しか使用されていないことに注意。

- 111 -

ＪＴ－Ｔ３８

付録

Ⅰ（ＪＴ－Ｔ３８に対する）
セッションの例（この付録は、本標準の必須部分を形成しない）
I.1 セッションの例
本付録は、送信と受信のＧ３ＦＥがゲートウェイとどのように通信するか、ゲートウェイがどんなパケッ
トを交換するかを示すための、いくつかの例を含んでいる。全ての例は、方法１の速度整合を使用するＴＣ
Ｐの実装を示している。
下方向に時間が経過する。情報は、矢印の方向の実線上に流れる。各々の線の上に置かれた箱は、どんな情報が送信されているかを、示している。Ｇ３ＦＥとゲートウェイの間の全情報は、ＪＴ－Ｔ３０／ＪＴ－Ｔ
４／Ｔ．６に適合している情報である。ゲートウェイの間で送信される情報は、本標準に記述されたパケッ
トの形式による。パケット送信時のラベルがついた箱の内容は、パケットタイプを表しており、パケットのペイロードにより運ばれる追加情報がそれに続く。
点線は、情報の一部が送信を始める時点を、明確化するために使われている。（例えば、フラグが認識された時に、Ｔ３０＿ＩＮＤＩＣＡＴＯＲ：フラグパケットが送られるのであって、フラグの送信を開始した時や終了したときである必要はない。点線は、情報のフローのどのタイプも示さない。
パケットラベルは、フィールドタイプのパケットのために、フィールド情報と同じようにパケットのタイプを表している。例えば、“Ｖ．２１：ＨＤＬＣ：ＴＳＩ／ＦＣＳ”の様なラベルは、ＴＳＩ情報とＦＣＳを表すフィールドを持つＶ．２１ ＨＤＬＣ（ＪＴ－Ｔ３０制御）パケットを表している。スペースの制約から、
ＦＣＳという表記は、ＦＣＳ とＦＣＳ－Ｓｉｇ－Ｅｎｄを含むように一般化されている。

I.1.1 ＥＣＭで通信する２台の従来のファクシミリ装置
付図Ⅰ．１は、ファクシミリゲートウェイを使って通信するためにＰＳＴＮを使用している２台の従来のグループ３ファクシミリ装置を示している。ＥＣＭは画像伝送のために使用されている。例では、トランスポートのコネクション／セッションが確立され、受信Ｇ３ＦＥが受信デートウェイからの呼に応答した後、まさにＣＥＤを生成しようとしているところから始まっている。

I.1.2 従来のファクシミリ装置とインターネット対応ファクシミリ装置
付図Ⅰ．２は、ＥＣＭを使用せずインターネット対応ファクシミリ装置に送信している、従来のグループ
３ファクシミリ装置を示している。例では、トランスポートのコネクション／セッションが確立された後、受信側がまさにＣＥＤを生成しようとしているところから始まっている。

I.1.3 複数フレームを使用する２台の従来のファクシミリ装置
付図Ⅰ．３は、ファクシミリゲートウェイを使って通信するためにＰＳＴＮを使用している２台の従来のグループ３ファクシミリ装置を示している。画像伝送がＥＣＭを使用していないことと、受信ゲートウェイ
がフレームを送信し始める前に完全なＨＤＬＣ ＢＣＳシーケンスを待っていないこと、以外はＩ．１．１に記述されている筋書に似ている。

- 112 -

ＪＴ－Ｔ３８

送信ゲートウェイ

送信Ｇ３ＦＥ

受信ゲートウェイ

T30 IND:CED

受信Ｇ３ＦＥ

CED tone

CED tone
T30 IND:Flags

CSI

Flags
CSI

Flags

V.21:HDLC:CSI/FCS

DIS

V.21:HDLC:DIS/FCS

DIS

Flags

T30 IND : Flags

TSI
DCS

Flags
V.21:HDLC:TSI/FCS

V.21:HDLC:DCS/FCS
TCF

TSI
DCS
TCF

T30 IND : Flags

Flags
CFR

Flags

V.21:HDLC:CFR/FCS

CFR
Training

Image

T30 IND : Speed

V.17:HDLC:
Image Data

Training

data
V.17:HDLC:
Image Data:
FCS-Sig-End
Flags

Image
data

T30 IND : Flags

PPSNULL

Flags
T.21:HDLC:PPS/NULL/FCS

T30 IND : Flags

PPSNULL
Flags
PPR

Flags
V.21:HDLC:PPR/FCS
PPR

付図Ⅰ．１／ＪＴ－Ｔ３８ ゲートウェイを介した２台のＧ３ファクシミリ装置間通信（１／２）（ＩＴＵ－Ｔ Ｔ．３８）- 113 -

ＪＴ－Ｔ３８

送信Ｇ３ＦE

送信ゲートウェイ

受信ゲートウェイ

受信Ｇ３ＦE

Training
T30 IND : Speed

Image
data

Training
V.17:HDLC:
Image
Data
V.17:HDLC:
Image Data:
FCS-Sig-End

Flags

Image
data

T30 IND : Flags

PPSNULL

Flags
V.21:HDLC:PPS-NULL/FCS

PPSNULL
Flags

T30 IND : Flags
Flags

MCF

V.21:HDLC:MCF/FCS

MCF
Training
T30 IND : Speed

Image
data

V.17:HDLC:
Image Data:FCS

Training

Image

Flags
PPS-EOP

V.17:HDLC:
Image Data:
FCS-Sig-End

data

T30 IND : Flags
V.21:HDLC:PPS-EOP/FCS

T30 IND : Flags

Flags
PPS-EOP

Flags
MCF

Flags
V.21:HDLC:MCF/FCS
MCF
Flags

T30 IND : Flags

DCN

Flags
V.21:HDLC:DCN/FCS
DISCONNECT

付図Ｉ．１／ＪＴ－Ｔ３８

DCN

ゲートウェイを介した２台のＧ３ファクシミリ装置間通信（２／２）（ＩＴＵ－Ｔ

Ｔ．３８）- 114 -

ＪＴ－Ｔ３８

受信ゲートウェイ
送信Ｇ３ＦE

送信ゲートウェイ/

ＩＡＦ装置-

T30 IND:CED
CED tone

T30 IND : Flags

Flags

V.21:HDLC:CSI/FCS,
DIS/FCS- Sig-End

CSI
DIS

Flags

T30 IND : Flags

TSI
V.21:HDLC:TSI/FCS

DCS

V.21:HDLC:DCS/FCS
TCF

T30 IND : Flags
Flags
V.21:HDLC:CFR/FCS
CFR

Training

T30 IND : Speed

Image
data

V.17: non-ECM:
Image Data
V.17: non-ECM:
Image Data:
non-ECM-Sig-End

Flags
EOP

T30 IND : Flags
V.21:HDLC:EOP/FCS
T30 IND : Flags

Flags

V.21:HDLC:MCF/FCS

MCF
Flags

T30 IND : Flags

DCN

V.21:HDLC:DCN/FCS
DISCONNECT

付図Ⅰ．２／ＪＴ－Ｔ３８

従来のファクシミリとＩＡＦ間の通信（ＩＴＵ－Ｔ

Ｔ．３８）- 115 -

ＪＴ－Ｔ３８

送信Ｇ３ＦE

送信ゲートウェイ

受信ゲートウェイ

受信Ｇ３ＦE

T30 IND:CED

CED tone

T30 IND : Flags

Flags

CED tone

Flags
CSI
V.21:HDLC:CSI
CSI

V.21:HDLC:CSI/FCS
V.21:HDLC:DIS

DIS

V.21:HDLC:DIS/FCS

Flags

T30 IND : Flags

TSI

DIS

Flags
V.21:HDLC:TSI/FCS

DCS

TSI
V.21:HDLC:DCS/FCS

TCF

DCS
TCF

T30 IND : Flags

Flags

Flags
V.21:HDLC:CFR
CFR

CFR

V.21:HDLC:CFR/FCS

Training

T30 IND : Speed

T30 Data

Image
data

Flags
EOP

V.17: non-ECM:
Image Data

Training

V.17: non-ECM:
Image Data:Sig-End
T30.IND : Flags
.

Image
data

V.21:HDLC:EOP/FCS

Flags
EOP

T30 IND : Flags
Flags

V.21:HDLC:MCF

MCF

V.21:HDLC:MCF/FCS

付図Ｉ．３／ＪＴ－Ｔ３８

Flags
MCF

ＢＣＳシーケンス毎の複数フレームの使用（ＩＴＵ－Ｔ

Ｔ．３８）- 116 -

ＪＴ－Ｔ３８

I.2 インターネット対応ファクシミリ装置（ＩＡＦ）
この節は、ＩＡＦの通信で考えられるシーケンスを説明する。

I.2.1 送信側がＩＡＦ、受信側がＧ３ファクシミリ
ＩＡＦでのＣＦＲ信号の受信タイミング

ＩＡＦは、ゲートウェイがＧ３ファクシミリにＴＣＦを送信する間の期間を考慮してＣＦＲ信号を受信するために待つことを推奨される。このことにより、付図Ｉ．４／ＪＴ－Ｔ３８のように、ＩＡＦのＤＣＳ信号がＧ３ファクシミリのＣＦＲ信号とゲートウェイで衝突することを防いでいる。

ゲートウェイ

IAF

G3FAX

DIS
DIS
DCS
DCS

TCF

CFR
CFR

付図Ｉ．４／ＪＴ－Ｔ３８

ＤＣＳからＣＦＲまでのＩＡＦ送信タイミング（ＩＴＵ－Ｔ

Ｔ．３８）- 117 -

ＪＴ－Ｔ３８

I.2.2

受信側がＩＡＦ、送信側がＧ３ファクシミリ

ＩＡＦでのＣＦＲ信号の送信タイミング

ゲートウェイがＧ３ファクシミリ装置からＴＣＦを受信する間の期間を考慮した後、ＩＡＦはＣＦＲ信号を送ることを推奨される。このことにより、付図Ｉ．５／ＪＴ－Ｔ３８のように、ＴＣＦがＣＦＲ信号と衝突することから防いでいる。

ゲートウェイ

G3FAX

IAF

DIS
DIS
DCS
DCS
TCF

CFR
CFR

付図Ｉ．５／ＪＴ－Ｔ３８

ＤＣＳからＣＦＲまでのＩＡＦ受信タイミング（ＩＴＵ－Ｔ

Ｔ．３８）- 118 -

ＪＴ－Ｔ３８

付録

Ⅱ（ＪＴ－Ｔ３８に対する）
ＪＴ－Ｔ３８付属資料Ｂに記載する呼確立手順の例（この付録は、本標準の必須部分を形成しない）
Ⅱ.1 呼確立手順シーケンス例

Ⅱ.1.1 ＪＴ－Ｔ３８付属資料Ｂゲートウェイ間シーケンス
付属資料Ｂ/ＪＴ－Ｔ３８
送信 G3FE

付属資料Ｂ/ＪＴ－Ｔ３８

送信ゲートウェイ
Off hook
Dial tone
Dialling number

受信 G3FE

受信ゲートウェイ

Q:SETUP[H:OLC](注１)
Q:CALL PROC
Q:ALERT
Q:CONNECT[H:OLC](注２)Ringing
Off hook

Open FAX channel(注３)Open FAX channel(注３)JT-T38 Session
On hook
Q:REL COMP
Busy tone
On hook必須

Ｑ： ＪＴ－Ｈ２２５．０にあるＪＴ－Ｑ９３１メッセージ

オプション l

Ｈ： ＪＴ－Ｈ２４５メッセージ

条件付き

（注１）

SETUP は、ＪＴ－Ｈ２４５の OpenLogicalChannel(OLC)に関連付けられた fastStart 要素を持つ
Setup-UUIE を含む。

（注２） CONNECT は、ＪＴ－Ｈ２４５の OpenLogicalChannel(OLC)に関連付けられた fastStart 要素を持つ
CONNECT-UUIE を含む。
（注３） ファクシミリチャネルは、ＴＣＰまたはＵＤＰを用いて開かれる。このフェーズは、ＪＴ－Ｔ３
８付属資料Ｂの装置間のＴＣＰ接続動作を明示している。ＵＤＰが適用される場合、ＵＤＰはコ
ネクションレストランスポートなので、このフェーズは現れない。
（注４） 基本的に、ゲートウェイ間シーケンスと同じものが、Ｇ３ＦＥへのゲートウェイ機能のないイン
ターネット対応ファクシミリ装置にも適用される。

付図Ⅱ．１／ＪＴ－Ｔ３８

付属資料Ｂ／ＪＴ－Ｔ３８ゲートウェイ間シーケンス（ＩＴＵ－Ｔ

Ｔ．３８）- 119 -

ＪＴ－Ｔ３８

Ⅱ.1.2 ＪＴ－Ｔ３８付属資料ＢとＪＴ－Ｈ３２３付属資料Ｄゲートウェイ間シーケンス
Ⅱ.1.2.1 正常接続と正常切断シーケンス（ファクシミリのみサポートするＪＴ－Ｔ３８付属資料Ｂ）

付属資料Ｄ／ＪＴ－Ｈ３２３
送信 G3FE

付属資料Ｂ／ＪＴ－Ｔ３８

送信ゲートウェイ

受信 G3FE

受信ゲートウェイ

Off hook
Dial tone
Q:SETUP[H:OLC]（注１）

Dialling number

Q:CALL PROC
Q:ALERT
Q:CONNECT[H:OLC]（注２）
Q:FACILITY（注３）
Q:FACILITY（注３）

Ringing
Off hook

Open FAX channel
Open FAX channel
JT-T38 Session
On hook
Q:REL COMP
Busy tone
On hook（注１）ＪＴ－Ｈ３２３付属資料Ｄの実装では、音声とファクシミリ能力を含むＯＬＣを送信するために
fastStart 要素を用いる。
（注２）ＪＴ－Ｔ３８付属資料Ｂの実装では、ＪＴ－Ｈ３２３付属資料Ｄ実装からの SETUP に対する応答にファクシミリ能力のみを含むＯＬＣを返す。ＪＴ－Ｔ３８付属資料Ｂ実装はＪＴ－Ｈ２４５ポー
トの値を返さないことに注意。
（注３）ＪＴ－Ｈ３２３付属資料Ｄ実装は、送信されなかった能力を交換するためにＪＴ－Ｈ２４５チャネ
ルを開く必要がある。従い、相手にＪＴ－Ｈ２４５チャネルを開くことを促すために startH245 のFacilityReason を持つファシリティ(Facility)メッセージを送る。その応答として、ＪＴ－Ｔ３８付属
資料Ｂ実装は、ＪＴ－Ｈ２４５動作をサポートしないことを示すために noH245 の FacilityReason を持つファシリティ(Facility)メッセージを返す。このシーケンスは、ＪＴ－Ｈ３２３付属資料Ｄ実装
が音声チャネルを必要としないときには、ＪＴ－Ｈ２４５チャネルを開かずに、ファクシミリ通信ができることを示す。

付図Ⅱ．２／ＪＴ－Ｔ３８

付属資料Ｂ／ＪＴ－Ｔ３８ゲートウェイと付属資料Ｄ／ＪＴ－Ｈ３２３間シーケンス（ＩＴＵ－Ｔ

Ｔ．３８）- 120 -

ＪＴ－Ｔ３８

Ⅱ.1.2.2

正常接続と正常切断シーケンス（ファクシミリと音声をサポートするＴＴＣ標準ＪＴ－Ｔ３８

付属資料Ｂ）
付属資料Ｄ／ＪＴ－Ｈ３２３
送信 G3FE

付属資料Ｂ／ＪＴ－Ｔ３８
受信ゲートウェイ

送信ゲートウェイ

受信 G3FE

Off hook
Dial tone
Q:SETUP[H:OLC]（注１）

Dialling number

Q:CALL PROC
Q:ALERT
Q:CONNECT[H:OLC]（注２）Ringing
Off hook

Voice Session
Open FAX channel（注３）Open FAX channel（注３）T.38 Session
On hook
Q:REL COMP
Busy tone
On hook（注１） ＪＴ－Ｈ３２３付属資料Ｄ実装は、ＯＬＣを送信するために fastStart を用いる。それは、最低限として音声能力を含んでいる。
（注２） ＪＴ－Ｔ３８付属資料Ｂ実装は、ＪＴ－Ｈ３２３付属資料Ｄ実装からの SETUP の応答として音声及びファクシミリ能力を含むＯＬＣを返す。音声とファクシミリをサポートするＪＴ－Ｔ３８
付属資料Ｂ実装は、ＪＴ－Ｈ２４５手順の能力を持つことに注意。
（注３） これは、両方向からＪＴ－Ｈ２４５手順でＯＬＣを交換することにより交渉されたファクシミリ
チャネルを開く。音声会話、ＣＮＧ、ＣＥＤとＶ．２１信号（図には表れない）など様々なものがそのシーケンスのトリガーとなることに注意。ＪＴ－Ｈ３２３付属資料ＤとＪＴ－Ｔ３８付属資料Ｂ実
装は、相手端末から送られるＪＴ－Ｔ３０信号（ＣＮＧ，ＣＥＤ、Ｖ．２１など）を認識する必要がある。これらは、ファクシミリチャネルが開かれるまでＪＴ－Ｔ３８を経由して転送されない。
（注４） ファクシミリとオプションとしての音声をサポートするＪＴ－Ｔ３８付属資料Ｂは、Ｂ．３．１．
１節で記載のとおり、ＪＴ－Ｈ３２３付属資料Ｄにある方法を用いなければならない。従って、上の図は、ＪＴ－Ｈ３２３付属資料Ｄに準拠するシーケンスを示している。
（注５） 切替えメカニズムは、ＪＴ－Ｈ３２３付属資料Ｄにある「Ｄ．５ 既に存在するオーディオスト
リームのＪＴ－Ｔ３８ファクシミリストリームでの置き換え」節を参照すべきである。

付図Ⅱ．３／ＪＴ－Ｔ３８

付属資料Ｂ／ＪＴ－Ｔ３８ゲートウェイと付属資料Ｄ／ＪＴ－Ｈ３２３間正常接続と正常切断シーケンス（ＩＴＵ－Ｔ

Ｔ．３８）- 121 -

ＪＴ－Ｔ３８

Ⅱ.1.2.3 接続拒否シーケンス１（発呼側（ＪＴ－Ｈ３２３付属資料Ｄ）が、ファーストコネクト手順をサポートしないケース）
付属資料Ｂ／ＪＴ－Ｔ３８
受信 G3FE
受信ゲートウェイ

付属資料Ｄ／ＪＴ－Ｈ３２３
送信 G3FE
送信ゲートウェイ
Off hook
Dial tone
Dialling number

Q:SETUP[H:OLC]
Q:REL COMP（注 1）（注１）ＪＴ－Ｔ３８付属資料Ｂ実装は fastStart 要素の無い SETUP メッセージを受信すると、ＪＴ－Ｑ９３
１：RELEASE COMPLETE を送ることで接続を拒否する。

付図Ⅱ．４／ＪＴ－Ｔ３８

付属資料Ｂ／ＪＴ－Ｔ３８と付属資料Ｄ／ＪＴ－Ｈ３２３ゲートウェイ間接続拒否シーケンス１（ＩＴＵ－Ｔ

Ⅱ.1.2.4

接続拒否シーケンス２

Ｔ．３８）（着呼側（ＪＴ－Ｈ３２３付属資料Ｄ）が、ファーストコネクト手順をサポートしないケース））付属資料Ｄ／ＪＴ－Ｈ３２３
送信ゲートウェイ
受信 G3FE

付属資料Ｂ／ＪＴ－Ｔ３８
送信 G3FE
送信ゲートウェイ
Off hook
Dial tone
Dialling number

Q:SETUP[H:OLC]
Q:CONNECT[H:OLC]
Q:REL COMP（注 1）（注１）

ＪＴ－Ｔ３８付属資料Ｂ実装は、fastStart 要素を持った SETUP メッセージに対する応答として
fastStart 要 素 の 無 い CONNECT メ ッ セ ー ジ を 受 信 し た 場 合 、 Ｊ Ｔ － Ｑ ９ ３ １ ： RELEASECOMPLETE を送ることで接続を拒否する。

付図Ⅱ．５／ＪＴ－Ｔ３８

付属資料Ｂ／ＪＴ－Ｔ３８と付属資料Ｄ／ＪＴ－Ｈ３２３ゲートウェイ間接続拒否シーケンス２（ＩＴＵ－Ｔ

Ｔ．３８）- 122 -

ＪＴ－Ｔ３８

Ⅱ.1.3

ファクシミリをサポートするＪＴ－Ｔ３８付属資料Ｂと同じゲートキーパーに登録されたＪＴ－Ｈ
３２３付属資料Ｄ間シーケンス

Ⅱ.1.3.1 正常接続シーケンス（ゲートキーパーがダイレクトコールシグナリングを選択した場合）

付属資料Ｄ／ＪＴ－Ｈ３２３
送信 G3FE

付属資料Ｂ／ＪＴ－Ｔ３８

送信ゲートウェイ

ゲートキーパー受信ゲートウェイ

受信 G3FE

Off hook
Dial tone
Dialling number
R:ARQ
R:ACF
Q:SETUP[H:OLC]

Ringing

Q:CALL PROC
R:ARQ
R:ACF
Q:ALERT
Q:CONNECT[H:OLC]

Off hook

Open FAX channel
Open FAX channel

JT-T38 Session

R

RAS (Registration, Admission and Status) メッセージ（注）ＪＴ－Ｈ３２３ ８．１節に様々な呼のモデルが記載されている。

付図Ⅱ．５／ＪＴ－Ｔ３８

付属資料Ｂ／ＪＴ－Ｔ３８と付属資料Ｄ／ＪＴ－Ｈ３２３ゲートウェイ間接続拒否シーケンス２（ＩＴＵ－Ｔ

Ｔ．３８）- 123 -

ＪＴ－Ｔ３８

Ⅱ.2 呼確立手順で用いられるプロトコルデータ

Ⅱ.2.1 概要
ＪＴ－Ｈ２２５．０（ＪＴ－Ｑ９３１のサブセット）とＪＴ－Ｈ２４５が、ＪＴ－Ｔ３８付属資料Ｂの呼確立手順に用いられるプロトコルデータを定義する一方、ＪＴ－Ｈ３２３がシステム全体の一般的なプロトコ
ルデザインを与える。例えば、SETUP メッセージは表１３／ＪＴ－Ｈ２２５．０で定義され、ユーザ・ユー
ザ情報要素（UUIE）は、ＪＴ－Ｈ２２５．０の H323-UU-PDU 中の Setup-UUIE として定義される。従って、Setup-UUIE のＡＳＮ．１定義によって SEQUENCE OF OCTET STRING として定義された fastStart 要素は、
ＪＴ－Ｈ２４５の MultimediaSystemControlMessage 中に定義された OpenLogicalChannel をカプセル化する。
さらに、RAS メッセージは、ＪＴ－Ｔ３８付属資料Ｂの完全な実装として理解される必要がある。RAS は、
また、ＡＳＮ．１を用い、RasMessage としてＪＴ－Ｈ２２５．０に定義される。表１８／ＪＴ－Ｈ２２５．
０は、そのサポート要件を与える。

Ⅱ.2.2 プロトコルデータ例

Ⅱ.2.2.1 サポートされるＪＴ－Ｈ２２５．０（ＪＴ－Ｑ９３１）メッセージ種別
付表Ⅱ．１から付表Ⅱ．３は、３つのフェーズでサポートされるＪＴ－Ｈ２２５．０（ＪＴ－Ｑ９３１）メッセージ種別を示す。

付表Ⅱ．１／ＪＴ－Ｔ３８ 呼設定フェーズメッセージ（ＩＴＵ－Ｔ

Ｔ．３８）

メッセージ種別

送信

受信

ALERT

ＣＭ(注)

Ｍ

CALL PROC

ＣＭ(注)

Ｍ

CONNECT

Ｍ

Ｍ

CONNECT ACKＦＦPROGRESS

Ｏ

Ｏ

SETUP

Ｍ

Ｍ

SETUP ACK

Ｏ

Ｏ

Ｍ

必須

Ｏ

オプション

Ｆ

使用不可

ＣＭ

条件付必須

(注)

ＩＡＦ（インターネット対応ファクシミリ装置）は、ALERT や CALL PROC

メッセージを送らないかもしれないが、ゲートウェイはそれらを送信しなければならないことに注意。ＪＴ－Ｈ３２３付属資料Ｄゲートウェイは、ＩＡＦに対し、
ALERT や CALL PROC を送るかもしれないことに注意- 124 -

ＪＴ－Ｔ３８

付表Ⅱ．２／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

呼解放フェーズメッセージ
Ｔ．３８）

メッセージ種別

送信受信

DISCONNECTＦ

Ｆ

RELEASEＦ

Ｆ

RELEASE COMP

Ｍ

Ｍ

付表Ⅱ．３／ＪＴ－Ｔ３８

その他のフェーズメッセージ（ＩＴＵ－Ｔ

メッセージ種別
FACILITY
（注）

Ｔ．３８）

送信

受信

ＣＭ（注）

Ｍ（注）

ＪＴ－Ｔ３８付属資料Ｂ実装は、ＪＴ－Ｈ３２３付属資料Ｄ実装に接続する
とき、FACILITY を送受信しなければならないことに注意- 125 -

ＪＴ－Ｔ３８

Ⅱ.2.2.2

SETUP 情報要素

付表Ⅱ．４から付表Ⅱ．６は、SETUP メッセージの情報要素を示す。

付表Ⅱ．４／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

情報要素

SETUP 情報要素

Ｔ．３８）

パラメータ

状態

説明

プロトコル識別子

ＪＴ－Ｈ２２５．０参照

Ｍ

呼番号

ＪＴ－Ｈ２２５．０参照

Ｍ

メッセージ種別

ＪＴ－Ｈ２２５．０参照

Ｍ

伝達能力

ＪＴ－Ｈ２２５．０参照

Ｍ

発番号

ＪＴ－Ｈ２２５．０参照

Ｏ

発サブアドレス

ＪＴ－Ｈ２２５．０参照

ＣＭ

着番号

ＪＴ－Ｈ２２５．０参照

Ｏ

着サブアドレス

ＪＴ－Ｈ２２５．０参照

ＣＭ

ユーザ・ユーザ

ProtocolIdentifierＭ

ＪＴ－Ｈ２２５．０バージョン番号

SourceInfo

Ｍ

EndPointType

DestinationAddressＭ

ゲートキーパーにより使用

DestCallSignalAddress

Ｍ

TransportAddress（ＩＰアドレス＋ポート番号）

ActiveMC

Ｍ

FALSE

ConferenceID

Ｍ

NULL

ConferenceGoal

Ｍ

NULL

CallType

Ｍ

PointToPoint

CallIdentifier

Ｍ

GloballyUniqueIDMediaWaitForConnect

Ｍ

TRUE

CanOverlapSend

Ｍ

TRUE なら、分割送信のサポート

FastStart

Ｍ

付表Ⅱ．５／ＪＴ－Ｔ３８参照- 126 -

ＪＴ－Ｔ３８

付表Ⅱ．５／ＪＴ－Ｔ３８

fastStart(OpenLogicalChannel)パラメータ（ＩＴＵ－Ｔ

Ｔ．３８）

パラメータ

説明

ForwardLogicalChannelNumber
ForwardLogicalChannelParameters
PortNumber
DataType

付表Ⅱ．６／ＪＴ－Ｔ３８参照
DataType は、ＪＴ－Ｔ３８付属資料Ｂの DataApplicationCapabilityに関連付けられている
ＪＴ－Ｔ３８付属資料Ｂの DataApplicationCapability は、ＪＴ－Ｈ２
４５のアプリケーションの CHOICE 中から抽出されただけである
ことに注意

MultiplexParameters

H2250LogicalChannelParameters の中の sessionID、mediaChannel 及びmediaControlChannel

ReverseLogicalChannelParameters
DataType

付表Ⅱ．６／ＪＴ－Ｔ３８参照
DataType は、ＪＴ－Ｔ３８付属資料Ｂの DataApplicationCapabilityに関連付けられている
ＪＴ－Ｔ３８付属資料Ｂの DataApplicationCapability は、ＪＴ－Ｈ２
４５のアプリケーションの CHOICE 中から抽出されただけである
ことに注意

MultiplexParameters

H2250LogicalChannelParameters の中の sessionID、mediaChannel 及びmediaControlChannel- 127 -

ＪＴ－Ｔ３８

付表Ⅱ．６／ＪＴ－Ｔ３８

dataType(DataApplicationCapability)パラメータ（ＩＴＵ－Ｔ

パラメータ
Application

Ｔ．３８）

状態

説明

－

t38fax の使用を指示するために CHOICE インデックス
が、符号化されなければならない

t38faxＭ

t38FaxProtocolＭ

tcp または udp の使用を指示するために
DataProtocolCapability の CHOICE インデックスが、符号化されなければならない

t38FaxProfile

Ｍ

FilBitRemoval

Ｍ

TranscodingJBIG

Ｍ

TranscodingMMR

Ｍ

VersionＭ

t38FaxRateManagement

Ｍ

localTCF または transferredTCF の使用を指示するために、CHOICE インデックスが、符号化されなければならない

t38FaxUdpOptions

Ｏ

t38FaxMaxBufferＯ

t38FaxMaxDatagramＯ

t38FaxUdpEC

Ｏ

t38UDPFEC または t38UDPRedundancy の使用を指示する
ために CHOICE インデックスが、符号化されなければな
らない

Ｍ

MaxBitRate

Ⅱ.2.2.3

単位

１００ｂｉｔ／ｓ

ALERT 情報要素

付表Ⅱ．７は、ALERT メッセージの情報要素を示す。

付表Ⅱ．７／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

情報要素

ALERT 情報要素

Ｔ．３８）

パラメータ

状態

プロトコル識別子

ＪＴ－Ｈ２２５．０参照

Ｍ

呼番号

ＪＴ－Ｈ２２５．０参照

Ｍ

メッセージ種別

ＪＴ－Ｈ２２５．０参照

Ｍ

ユーザ・ユーザ

ＪＴ－Ｈ２２５．０参照

Ｍ- 128 -

説明

ＪＴ－Ｔ３８

Ⅱ.2.2.4

CALL PROC 情報要素

付表Ⅱ．８は、CALL PROC メッセージの情報要素を示す。

付表Ⅱ．８／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

情報要素

CALL PROC 情報要素
Ｔ．３８）

パラメータ

状態

プロトコル識別子

ＪＴ－Ｈ２２５．０参照

Ｍ

呼番号

ＪＴ－Ｈ２２５．０参照

Ｍ

メッセージ種別

ＪＴ－Ｈ２２５．０参照

Ｍ

ユーザ・ユーザ

ＪＴ－Ｈ２２５．０参照

Ｍ

Ⅱ.2.2.5

説明

CONNECT 情報要素

付表Ⅱ．９は、CONNECT メッセージの情報要素を示す。

付表Ⅱ．９／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

情報要素

CONNECT 情報要素

Ｔ．３８）

パラメータ

状態

プロトコル識別子

ＪＴ－Ｈ２２５．０参照

Ｍ

呼番号

ＪＴ－Ｈ２２５．０参照

Ｍ

メッセージ種別

ＪＴ－Ｈ２２５．０参照

Ｍ

ユーザ・ユーザ

protocolIdentifierＭ

説明ＪＴ－Ｈ２２５．０

バージョン番号
destinationInfo

Ｍ

EndPointTypeconferenceID

Ｍ

NULL

callIdentifier

Ｍ

GloballyUniqueID

FastStart

Ｍ

付表Ⅱ．５／ＪＴ－Ｔ３８参照- 129 -

ＪＴ－Ｔ３８

Ⅱ.2.2.6

RELEASE COMPLETE 情報要素

付表Ⅱ．１０は、RELEASE COMPLETE メッセージの情報要素を示す。

付表Ⅱ．１０／ＪＴ－Ｔ３８

RELEASE COMPLETE 情報要素

（ＩＴＵ－Ｔ

情報要素

Ｔ．３８）

パラメータ

状態

プロトコル識別子

ＪＴ－Ｈ２２５．０参照

Ｍ

呼番号

ＪＴ－Ｈ２２５．０参照

Ｍ

メッセージ種別

ＪＴ－Ｈ２２５．０参照

Ｍ

理由表示

ＪＴ－Ｈ２２５．０参照

ＣＭ

説明

この理由表示情報要素か、または、
ユーザ・ユーザ情報要素中にReleaseCompleteReason のどちらかが存在しなければならない

ユーザ・ユーザ

ＪＴ－Ｈ２２５．０参照

Ｍ

Ⅱ.2.2.7 FACILITY 情報要素
付表Ⅱ．１１は、FACILITY メッセージの情報要素を示す。

付表Ⅱ．１１／ＪＴ－Ｔ３８（ＩＴＵ－Ｔ

情報要素

FACILITY 情報要素

Ｔ．３８）

パラメータ

状態

プロトコル識別子

ＪＴ－Ｈ２２５．０参照

Ｍ

呼番号

ＪＴ－Ｈ２２５．０参照

Ｍ

メッセージ種別

ＪＴ－Ｈ２２５．０参照

Ｍ

ユーザ・ユーザ

protocolIdentifierＭ

説明ＪＴ－Ｈ２２５．０

バージョン番号
ReasonＭ

FacilityReason

CallIdentifier

Ｍ

GloballyUniqueID- 130 -

ＪＴ－Ｔ３８

付録

Ⅲ（ＪＴ－Ｔ３８に対する）
ファクシミリ機能を有するメディアゲートウェイのＨ．２４８呼の確立手順例（この付録は、本標準の必須部分を形成しない）
Ⅲ.1 はじめに本付録は付属資料ＥとＪＴ－Ｈ２４８．１によって定義されている手順を使用した他のＪＴ－Ｔ３８を実装した端末との呼を確立するために本標準に適合したインターネット対応ファクシミリ実装端末及びイン
ターネット対応ファクシミリゲートウェイのための手順例を記述する。さらに、本付録ではＨ．２４８とＪ
Ｔ－Ｈ３２３エンドポイント間における呼確立のためのＭＧ／ＭＧＣの相互作用の例を記述する。手順例は
主に２つのカテゴリに分かれる。
（１）ＭＧがＭＧＣ制御方式を用いて音声／オーディオ状態からＪＴ－Ｔ３８状態へ遷移する呼設定手順（２）ＭＧが音声／オーディオ状態からＪＴ－Ｔ３８状態へ自動的に遷移する呼設定手順

Ⅲ.2 呼設定の例
Ⅲ.2.1 ＪＴ－Ｔ３８遷移方式を使用したＨ．２４８エンドポイントでの音声からファクシミリへの呼設定

本発呼フロー例はＳＣＮ内に発生、終結する音声の呼とパケット網を通して転送される音声の呼を記述する。
本例ではパケット網のシグナリングについては明記されてないが、ＪＴ－Ｈ３２３またはＳＩＰのようなシグナリングプロトコルは使用できる。この例の目的はファクシミリ検出と音声からファクシミリへの切換えを含み、ＭＧとＭＧＣがＭＧＣ手順をサポートする際に必要となるＭＧ／ＭＧＣの相互作用を記述することである。

- 131 -

ＪＴ－Ｔ３８

MG1

G3FE1

MG2

MGC

G3FE2

1-AUDIT
1-REPLY

1-AUDIT
1-REPLY

2-OFF HOOK
2-DIAL TONE
2-DIALLING

SGW
2-SETUP(SCTP)

MG1
3-CREATE CONTEXT
4-ACK

5-CREATE CONTEXT
6-ACK
Voice mode

7-RINGING
7-ACK

8-CNG

8-CNG DETECTED
8-ACK

8-PLAY CNG
8-ACK
9-CED DETECTED
9-ACK

10-PLAY CED

8-CNG
9-CED
11-V.21
Preamble+flags

11-V.21 DETECTED
10-ACK
10-CED

11-ACK
11-PLAY V.21

11-MODIFY

11-ACK
11-V.21 preamble

switch11-ACK{

12-MODIFY
12-ACK
13-MODIFY
14-ACK

switchport IDs{｝fax
packageto｝switchT.38

15-MODIFY
16-ACK
17-MODIFY
17-ACK｝switchport IDs

Fax mode
V.21 Preamble+flags
JT-T38 V.21

PACKET

付図Ⅲ．１／ＪＴ－Ｔ３８ Ｈ．２４８エンドポイントを使用した音声端末からファクシミリへの呼設定（ＩＴＵ－Ｔ Ｔ．３８）- 132 -

ＪＴ－Ｔ３８

イベントのシーケンスは次のとおりである。
１）呼の前のある時点でメディアゲートウェイコントローラは能力検査コマンドをメディアゲートウェイにその制御下で発行し、各ゲートウェイのための音声とファクシミリの機能が何であるかを知ることになる。以下のシナリオでは、両方のメディアゲートウェイがＪＴ－Ｔ３８をサポートしていれば、これはＩＰファクシミリ動作においては好ましいモードである。一方もしくは両方のメディアゲートウェイ
がＪＴ－Ｔ３８をサポートしていなければ、ファクシミリの呼はＩＰ音声チャネルを通して行ってもよい。しかしながらＪＴ－Ｔ３０ファクシミリは圧縮された音声コーデックを介した場合は正常動作しな
いかもしれないので、メディアゲートウェイ間の通信にはＪＴ－Ｇ７１１コーデックを使用することが望ましい。‘Ｗ－’はＭＧ上の各ターミネーション能力検査ではなく、ＭＧの全てのターミネーション
上での統一情報を含んだワイルドカード化された回答が要求されることを示すために用いられる。しかしながら、ＭＧ１がＪＴ－Ｔ３８をサポートすることを示す場合は、付属資料ＥのＥ．２．２節で記述されているＪＴ－Ｔ３８自動遷移方式またはＪＴ－Ｔ３８ＭＧＣ遷移方式をサポートしているかどうかを推測するために、能力検査を用いてはいけない。Add Ephemeral（下記（３）参照）の間の発呼の状況によって推測されなければならない。

ＭＧＣはＭＧ１を検査する。
ＭＧＣからＭＧ１へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 9 {Context = - {W-AuditValue = * {Audit{Packages}}}}
ＭＧ１の応答。ＭＧ１からＭＧＣへ
MEGACO/1 [125.125.125.111]:55555
Reply = 9 {Context = - {AuditValue = * {Packages {al, rtp, ipfax, fax, ctyp, cg}; al = analog line pkg, rtp = rtp pkg, ipfax = T.38 fax pkg, fax = fax pkg; ftmd = fax/textphone/modem tones detection pkg; ctyp = Call Type Discrimination package); cg =call progress tones generator pkg}}}
MEGACO/1 [123.123.123.4]:55555
Transaction = 10 {Context = - {W-AuditCapabilities = * {Audit{Media}}}}
ＭＧ１の応答。ＭＧ１からＭＧＣへ
MEGACO/1 [123.123.123.111]:55555
Reply = 10 {Context = - {AuditValue = * {Media {
Stream = 1 {Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 0 18
v=0c=IN IP4 $m=image $ udptl t38} ; G.711 に関する RTP プロファイルは 0、G.729 は 18、T.38 は t38 である。
}
},
}
}
}
- 133 -

ＪＴ－Ｔ３８

ＭＧＣとＭＧ２との間で同様の交換が発生する。
２）エンドユーザがＧ３ＦＥ１装置からファクシミリを送ると決め、電話番号を入力する。ファクシミリ装
置はダイヤルトーンを受信し、その電話番号をダイヤルする。その結果、ローカルＳＣＮループ内の交換局はＮｏ．７信号方式メッセージを信号ゲートウェイ（ＳＧ）へ送る。ＳＣＮ交換機からの、発着電話番号を伝えるこのＩＡＭを受信した後、ＳＧは Setup メッセージをＭＧＣへ送る。ＳＣＴＰ（例）はＮｏ．７信号方式シグナリングをＳＧからＭＧＣへ搬送する。

３）ＩＡＭにより、ＭＧＣはＭＧが関係している回線やどこで呼を終了すべきかを推測してもよい。ＭＧＣ
がどのようにしてこれを実行するのかについては本付録の範囲外である。エンドポイントはメディア
ゲートウェイコントローラ（ＭＧＣ）によって見つけられる。ＭＧＣは２つのメディアゲートウェイ間のオーディオチャネルを設定し、最終目的地の電話に接続するように受信交換局（ＣＯ）のＮｏ．７信号方式設備に指示することによって、リンギングが生成される。従い、コントローラがＭＧ１からＭＧ２への接続が必要かどうかを決定し、開始する。ＭＧＣは、その呼のためのコンテキストを生成する。
両方のＴＤＭターミネーションＤＳ０／１／１とＲＴＰターミネーションが、ＭＧ１の新たなコンテキ
ストに加えられる。リモート記述子の値が特定されてないので、モードは ReceiveOnly である。望ましいコーデックはＭＧＣの優先順位の選択にある。ＭＧＣはＭＧがそれ自身を設定するであろうローカル
記述子の中のＳＤＰ内フィールドをＣＨＯＯＳＥ（すなわち＄）に設定する。さらに、ＭＧＣが、両方のゲートウェイがＪＴ－Ｔ３８自動遷移方式またはＪＴ－Ｔ３８ＭＧＣ遷移方式をサポートしているかを推測できるようにするために、ＭＧＣはＭＧ１に対して audio RTP/AVP 能力と image/t38 能力の値を応答することを指示する。これは、ＭＧにオーディオと画像記述のための資源確保を依頼するための”ReserveGroup=True”を LocalControl 記述子の中に含ませることによって達成されることに注意すること。さらに、メディア記述子の中で提示されている全ての可能なコーデックのための資源を確保するよ
うに依頼する”ReserveValue=True”（もしくは、ＭＧＣは最良の符号化を要求するためにReserveValue=false を含むかもしれない。
しかしながら、省略した場合、ＭＧはこの値を初期値として falseを設定しなければならない。）

ＭＧＣからＭＧ１へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 11 {Context = $ {Add = DS0/1/1 {Events = 1 {al/on, ctyp/dtone}}, ; SCN 終了は、トーンを聞くための準備。
Add = $ {Media {
Stream = 1 {LocalControl { Mode = ReceiveOnly, ReserveGroup = True, ReserveValue= True},Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 18 0v=0
c=IN IP4 $m=image $ udptl t38}; オーディオに関する IP 終了。
}
}
}
}
}

- 134 -

ＪＴ－Ｔ３８

４）ＭＧ１は新しいターミネーションを認識し、ローカルＩＰアドレスとＵＤＰポートを書き込む。本例では、ＭＧ１は両方の提示されたコーデックをサポートしておりＭＧＣにより与えられた同じ優先順位で両方のコーデックを返す（最終選択をＭＧ２へ委ねる）。ＭＧ１は、ＲＴＰポートを２２２２にセットする。
さらにＭＧ１はＶｏＩＰとＦｏＩＰ間のＪＴ－Ｔ３８自動遷移方式をサポートしてないので、ＭＧ１はイメージメディア記述子ラインを全て省略する（もしくは、ＪＴ－Ｔ３８ポートを０に設定する）。
MEGACO/1 [124.124.124.222]:55555
Reply = 11 {Context = 2000 {Add = DS0/1/1, ; SCN 終了が加えられた。
Add = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0 ;MG1 は両方の提示されたコーデックをサポート。
a=ptime:20} ; IP 終了が加えられた。
}
}
}
}
}

５）ＭＧＣはまた、リモートＭＧ２も制御すると仮定する。ＭＧ１の返答にもとづき、ＶｏＩＰとＦｏＩＰ間を遷移するために、ＭＧＣはＪＴ－Ｔ３８ＭＧＣ遷移方式を使用すべきであると推測する。そして、
ＭＧＣはＭＧ２上の新しいコンテキストでＤＳ０／２／２を関連づけ、発呼ユーザ、ユーザ１までずっと SendReceive 接続のＲＴＰストリーム（すなわちＲＴＰ／２が割り当てられる）を確立する。ＭＧＣ
は、ＭＧ２へコーデックを選択することを指示するために、短期間のターミネーションの LocalControl
記述子の中に ReserveValue=False 属性を含む。

ＭＧＣからＭＧ２へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 30 {Context = $ {Add = DS0/2/2 {Media {
Stream = 1 {LocalControl {Mode = SendReceive } } },Events = 10 {al/of, ctyp/dtone},
Signals = {al/ri}},
Add = $ {Media {
Stream = 1 {LocalControl {Mode = SendReceive, ReserveValue=False },Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 18 0},
Remote {v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0a=ptime:20} ; G.729 に関する RTP プロファイルは 18。
}- 135 -

ＪＴ－Ｔ３８

}}}}６）ＭＧ２は、提供されるリモートＳＤＰにもとづき、ＶｏＩＰ状態からＦｏＩＰ状態へ遷移するためにＪ
Ｔ－Ｔ３８ＭＧＣ遷移方式を使用することは認められている。ストリームポート番号は１１１１である（ＳＤＰ内）。ＭＧ２は、所望のコーデックとしてリストされている優先コーデックの中の最初のコーデック、
すなわちＪＴ－Ｇ７２９を選択する（ＲＴＰペイロードタイプ＝１８）。

ＭＧ２からＭＧＣへMEGACO/1 [125.125.125.111]:55555
Reply = 30 {Context = 5000 {Add = DS0/2/2,
Add = RTP/2 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 125.125.125.111m=audio 1111 RTP/AVP 18
}
}
}
}
}
}

７）上記ＩＰＡｄｄｒ、ＵＤＰｐｏｒｔ、選択されたコーデックはＭＧ１へ提供される必要がある。ＭＧＣ
は、ＪＴ－Ｔ３８ＭＧＣ遷移方式を使用しなければならないことをわかっているので、ＭＧＣはＭＧ１に対してファクシミリトーンを検出し、ＤＳ０／１／１ターミネーションにリングバックトーン
ringback を適用するのと同様にその検出を正しく通知するように指示する。さらに、それを SendReceiveに置き換えるように指示する。

ＭＧＣからＭＧ１へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 12 {Context = 2000 {Modify = DS0/1/1 {Events = 10 { ctyp/dtone},;ファクシミリトーンの検出。
Signals {cg/rt} }, ;リンギングトーンの適用。
Modify = RTP/1 {Media {
Stream = 1 {LocalControl {Mode = SendReceive }Remote {v=0
c=IN IP4 125.125.125.111m=audio 1111 RTP/AVP 18
}
}
}
}
}
}
ＭＧ１からＭＧＣへMEGACO/1 [124.124.124.222]:55555
Reply = 12 {- 136 -

ＪＴ－Ｔ３８

Context = 2000 {Modify = DS0/1/1, Modify = RTP/1}}

８）発呼ファクシミリ装置は、通常ＣＮＧコーリングトーンを生成することから始まる。ＣＮＧトーンが最初のメディアゲートウェイ（ＭＧ１）によって検出されると、このイベントはメディアゲートウェイコ
ントローラへ報告されなければならない。メディアゲートウェイコントローラは二つ目のメディアゲー
トウェイ（ＭＧ２）へＣＮＧトーンを生成するようにコマンドを発行しなければならない。この時点では、全２重チャネルはまだ音声モードであり、ＪＴ－Ｇ７２３．１やＪＴ－Ｇ７２９Ａのような指示されたオーディオコーデックを使用している。

ＭＧ１からＭＧＣへMEGACO/1 [124.124.124.222]:55555
Transaction = 50 {Context = 2000 {Notify = DS0/1/1 {ObservedEvents = 1 {19991212T22110001: ctyp/dtone{dtt=cng} }}}}ＭＧＣからＭＧ１へ
MEGACO/1 [123.123.123.4]:55555
Reply = 50 {Context = 2000 {Notify = DS0/1/1}}
ＭＧＣからＭＧ２へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 31 {Context = 5000 {Modify = DS0/2/2 {Signals {ctyp/callsig{callSigname=cng}}; リモートエンドで CNG を発行。
}}}
ＭＧ２からＭＧＣへMEGACO/1 [125.125.125.111]:55555
Reply = 31 {Context = 5000 {Modify = DS0/2/2}}

９）前のステップでは、ＭＧ２はＭＧＣが Signals 記述子内で要求したＣＮＧトーンを生成した。通常は、もし最後の送信先電話番号がファクシミリ可能であれば、ＣＥＤトーンは受信ファクシミリ装置によって生成されるであろう。本ステップはここに例示されている。しかしながら、もしファクシミリ受信機
がこのライン上に無い場合は、通常の応答は音声になるであろう。
ＭＧ２からＭＧＣへMEGACO/1 [123.123.123.4]:55555
Transaction = 70 {Context = 5000 {Notify = DS0/2/2 {ObservedEvents = 10 {19991212T22110031: ctyp/dtone{dtt=ANS}}; CED と ANS は等価である。名称 ANSとして報告される。
}}}
ＭＧＣからＭＧ２へ
MEGACO/1 [125.125.125.111]:55555- 137 -

ＪＴ－Ｔ３８

Reply = 70 {Context = 5000 {Notify = DS0/2/2}}１０）ＣＥＤが受信ファクシミリ装置により発生されたと仮定すると、ＭＧ２がＣＥＤを受信し、それが本当にＣＥＤかどうかを検出するために、トーン検出アルゴリズムを使用する。（注意：Ｖ．２５とＶ．
８で定義されるモデムアンサートーンを検出するために幾つかの研究がなされた。位相反転がないモデ
ムアンサートーンＶ．２５のＡＮＳとして知られ、位相反転があるモデムアンサートーンはＡＮＳ（位相反転を表すバーを上部につける）。モデムやＤＳＰには、ＣＥＤ、ＡＮＳ、ＡＮＳ（バー）を識別することが困難な時期があるかもしれない。しかし、もしＣＮＧに応答して生成されたトーンの様なＣＥ
Ｄがあれば、ＡＮＳトーンのひとつではなく本当にＣＥＤであるという可能性が非常に高い。高機能なモデムは、ＡＮＳａｍ、他のモデム、ファクシミリトーンを識別できる。
ＣＮＧは発呼側によって報告され、また、ＣＥＤは被呼側によって報告されるので、メディアゲート
ウェイコントローラはＣＥＤ再生命令をＭＧ１に発行する。両方のメディアゲートウェイは、ファクシ
ミリモードに移行する（もしＪＴ－Ｔ３８あるいはＪＴ－Ｇ７１１をサポートしていれば）。この時点
から、Ｖ．２１ファクシミリデータはメディアのゲートウェイ間で伝送されることになる。もし、この時点で他の応答トーン、たとえばＡＮＳａｍ（（１８）参照）のような応答トーンが検出されないと仮定できるならば、ＭＧＣが十分な確信を持ってファクシミリに切り替えることを決定できるかもしれないことに注意すること。この例の目的として、十分な確証を示すものではない。
ＭＧＣからＭＧ１へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 13 {Context = 2000 {Modify = DS0/1/1 {Signals {ctyp/ans{anstype=ans}}}}}
ＭＧ１からＭＧＣへMEGACO/1 [124.125.125.222]:55555
Reply = 13 {Context = 2000 {Modify = DS0/1/1}}

１１）ＭＧ２は、フラグが続くＶ．２１キャリアを検出すると、このイベントを報告するメッセージをＭＧＣに送る。この時点でＭＧＣは、呼がファクシミリであることを確定し、最初にＤＳ０ターミネーショ
ン上で切換えを開始する。Ｖ．２１フラグはＭＧ１には通知されないことに注意すること。そのイベントによりＭＧＣは、ＭＧ１に V21flags をＳＣＮターミネーションに再生することを依頼する。
ＭＧ２はＭＧＣにＶ．２１キャリアイベントを知らせる。
ＭＧ２からＭＧＣへMEGACO/1 [123.123.123.4]:55555
Transaction = 71 {Context = 5000 {Notify = DS0/2/2 {ObservedEvents = 10 {19991212T22110031:ctyp/dtone{dtt=v21flag}}}}}
ＭＧＣの応答
ＭＧＣからＭＧ２へ
MEGACO/1 [125.125.125.111]:55555
Reply = 71 {Context = 5000 {Notify = DS0/2/2}- 138 -

ＪＴ－Ｔ３８}

ＭＧＣはそのＳＣＮターミネーション上でＶ．２１フラグを送るようにＭＧ１にコマンドを送り、ファクシ
ミリのパッケージに対するセッションを継続する。
ＭＧＣからＭＧ１へ
MEGACO/1 [123.123.123.4]:55555
Transaction = 5{Context = 2000 {Modify = DS0/1/1 {Signals {ctyp/ans{anstype=v21flags, SignalType=TimeOut}}
Events = 2 { fax/faxconnchange}
Media{
TerminationState{fax/faxstate = TrainT;
}
}
}
}
}
}
ＭＧ１からＭＧＣへMEGACO/1 [124.125.125.222]:55555
Reply = 5 {Context = 2000 {Modify = DS0/1/1}}

ＭＧはＪＴ－Ｔ３８メディアストリーム（（１７）参照）の中で V21flags 表示が届くまで V21flags シグナルを生成しなければならない。そして、ＪＴ－Ｔ３８メディアストリームの中で V21flags ターミネーションが表示されるまで継続しなければならない。

１２）この時点では、ＭＧ２とＭＧ１のＳＣＮターミネーションは、ファクシミリモードに入らなければならない（ネゴシエーション段階である）。ＭＧ２の例だけを示す。ＭＧ２の場合には、ctyp パッケージは Events 記述子には、記述されていないので、ＭＧは発呼タイプの識別イベント通知を要求されない。
また、ＣＮＧはシグナル記述子でも記述されてないので、この信号は消滅している。
ＭＧＣからＭＧ２ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 33{
Context = 5000 {Modify = DS0/2/2 {Events = 12 { fax/faxconnchange}
Signals{},
Media{
TerminationState{fax/faxstate = Negotiating;
}
}
}
}
}
ＭＧ２の応答ＭＧ２からＭＧＣヘ
MEGACO/1 [125.125.125.111]:55555
Reply = 33 {Context = 5000 {Modify = DS0/2/2}}- 139 -

ＪＴ－Ｔ３８１３）発呼の時点では、ファクシミリへの切換えは、ＪＴ－Ｔ３８モードに切換えるためにそれぞれのＭＧに要求を続ける。それぞれのＭＧが以前の検査結果としてＪＴ－Ｔ３８をサポートしていることをＭＧ
Ｃは認識していることに注意すること。ＪＴ－Ｔ３８が利用可能でないなら、オーディオモードをＪＴ－Ｇ７１１に変更してもよい（詳細は本標準の適用外である）。ＡＮＳａｍのような他のアンサートー
ンが検出されなければ、音声、ファクシミリ、データモード間の選択が達成されることになる。ＡＮＳ
ａｍが検出される場合、２つのＭＧは、呼（例えばＶ．３４ファクシミリ、Ｖ．９０データ、テキスト
電話など）のタイプを決定するためにＶ．８セッションを行うモードに移行すべきである。この環境でのＶ．３４ファクシミリ呼の取り扱いは、継続検討とする。

ＭＧＣからＭＧ１ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 15 {Context = 2000 {Modify = RTP/1 {Media {
TerminationState {ipfax/faxstate = Negotiating;}Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=image 2222 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC} ; IP 接続中で T.38 へ変更。
}
}
}
}
}

１４）次の記載はＭＧ１からの応答である。ＭＧ１は a= フィールドのひとつを変更する。ＪＴ－Ｔ３８パ
ラメータの transferredTCF はＭＧ１によって localTCF に変えられる。ＭＧ１は、またもし既存の音声チャ
ネルポートをファクシミリポートへ切換えたくないならば、ＭＧ１はポート番号を変更してもよい。この例では 2222 から 3333 にポートを変更している。

ＭＧ１からＭＧＣヘ
MEGACO/1 [124.124.124.222]:55555
Reply = 15 {Context = 2000 {Modify = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=image 3333 udptl t38
a=T38FaxRateManagement:localTCF
a=T38FaxUdpEC:t38UDPFEC}; IP 接続はファクシミリモードへ。
}
}
} }
}

- 140 -

ＪＴ－Ｔ３８

１５）新しいメディア情報は、ＭＧ２へ与えられなければならない。

ＭＧＣからＭＧ２ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 32 {Context = 5000 {Modify = RTP/2 {Media {
TerminationState {ipfax/faxstate = Negotiating;}Stream = 1 {Local {
v=0
c=IN IP4 125.125.125.111
m=image 1111 udptl t38
a=T38FaxRateManagement:localTCF
a=T38FaxUdpEC:t38UDPFEC},
Remote {v=0
c=IN IP4 124.124.124.222
m=image 3333 udptl t38
a=T38FaxRateManagement:localTCF
a=T38FaxUdpEC:t38UDPFEC
}
}
}
}
}
}

１６）ＭＧ２はポート番号を変更しないことを選択し（1111 のままである）、どのＪＴ－Ｔ３８パラメータも変更しないということは認められている。

ＭＧ２からＭＧＣヘ
MEGACO/1 [125.125.125.111]:55555
Reply = 32 {Context = 5000 {Modify = RTP/2 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 125.125.125.111
m=image 1111 udptl t38
a=T38FaxRateManagement:localTCF
a=T38FaxUdpEC:t38UDPFEC
}
}
}
}
}
}

１７）今度は、ＭＧ１はＭＧ２から新しいメディア情報を与えられる必要がある。

ＭＧＣからＭＧ１ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 15 {Context = 2000 {- 141 -

ＪＴ－Ｔ３８

Modify = RTP/1 {Media {
Stream = 1 {Remote {v=0
c=IN IP4 125.125.125.111
m=image 1111 udptl t38
a=T38FaxRateManagement:localTCF
a=T38FaxUdpEC:t38UDPFEC
}
}
}
}
}
}
ＭＧ１からＭＧＣヘ
MEGACO/1 [124.124.124.222]:55555
Reply = 15 {Context = 2000 { Modify = RTP/1}}

ファクシミリ呼は、直ちに、ＭＧ間でＪＴ－Ｔ３８モードに進む。ＭＧ２からの最初のメッセージは、Ｖ．
２１フラグを含むＪＴ－Ｔ３０インジケータパケットとなる。ＭＧは以前のイベントを記憶しないので、Ｄ
Ｓ０上のこの信号の継続的な出現によって生成される。

event/faxconnchange は、両方のＭＧのイベントリストに残され、それからそれぞれステート変更はＭＧＣへ通知されることに注意すること。しかし、faxstate は状態変化としてそれぞれのＭＧによって暗黙に設定されるべきなので、ＭＧＣは応答として明確に fax/faxstate を設定する必要がない。ＭＧＣは、ほとんどのス
テート変更に対して何もしなくて良い。しかし、回線切断のような状態変化に関しては適切なアクション
をとるであろう。

１８）別の例：ＭＧ２によってＣＥＤまたは同等のトーンの検出イベントが起これば、ＭＧ２は常にＭＧＣにこれを通知する。ＭＧＣは以前にＭＧ１によってＣＮＧの検出の通知を受信しなかった場合は、ファ
クシミリまたはデータモードが適用できるかどうかは明確ではない。しかし、圧縮された音声コーデッ
クはいずれの場合も適切ではないので、ＭＧＣはデータ有効モード（すなわちＪＴ－Ｇ７１１である）に両方のＭＧを設定しなければならないか、さらに呼を識別するために付加されたトーンを待たなければならない。

１９）もしＭＧ２が、フラグが続くＶ．２１キャリアを検出する能力を持っているなら、ＭＧ２はこのイベントを報告するメッセージをＭＧＣに送るであろう。（ＭＧは一般に以前に発生したイベントのためのメモリを持たないと想定されている。それで、たとえＭＧＣがすでにファクシミリモードに２つのＭＧを移行させたとしても、Ｖ．２１の通知とフラグは送られるであろう。）もし、ＭＧＣがファクシミリ
モードの中に前に２つのＭＧを置いてなかったなら、ここで移行させるだろう。もし、ＭＧがすでにＪ
Ｔ－Ｇ７１１モードなら、ＭＧＣはモード変更を求めないか、あるいは、２つのメディアゲートウェイ
をＪＴ－Ｔ３８モードに切り替えるかを選択しなければならない。

ＭＧ２はＭＧＣにＶ．２１キャリアイベントを知らせる。
ＭＧ２からＭＧＣヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 4 {Context = 5000 {- 142 -

ＪＴ－Ｔ３８

Notify = DS0/2/2 {ObservedEvents = 10 {19991212T22110031:ctyp/dtone{dtt=v21flag}}}}}２０）別の例：発呼の時点で、少なくともＡＮＳａｍのようないくつかの応答トーンを検出しない限り、音声、ファクシミリ、データモードのいずれかが選択される。ＡＮＳａｍが検出されたイベントで、２つのＭＧはそれらがさらに発呼（Ｖ．３４ファクシミリ、Ｖ．９０データ、テキスト電話など）のタイプを決定するためにＶ．８セッションを実行できるモードに変更されるべきである。この環境でのＶ．３
４ファクシミリ呼の取り扱いは継続検討とする。

ＭＧはＭＧ２にＡＮＳａｍイベントを知らせる。
ＭＧ２からＭＧＣヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 4 {Context = 5000 {Notify = DS0/2/2 {ObservedEvents = 10 {19991212T22110031: ctyp/dtone{dtt=ansam}}}}}

Ⅲ.2.2 Ｈ．２４８とＪＴ－Ｈ３２３の間でのファクシミリのみの呼設定

このファクシミリのみの本発呼フロー例（付図Ⅲ．２）は、ＳＣＮ内で生成され、パケットネットワークで終端するファクシミリ呼を記述する。この例のパケットネットワークシグナリングは、ＪＴ－Ｈ３２３であるが、ＳＩＰのような他のシグナリング手順を使用することができる。この例の目的はＭＧ／ＭＧＣ相互作用を記述することである。シグナリングゲートウェイ（ＳＧＷ）とＭＧＣ間のシグナリングは、ＪＴ－Ｑ９
３１に基づいていると仮定される。これは、他のシグナリングがこのインタフェースで使用できないことを示すものではない。ここで記述される能力は、一般的なラインパッケージ記述である。（但し、これはＳＤ
ＰまたはＪＴ－Ｈ２４５メッセージの可能性がある）
メディアゲートウェイは音声とファクシミリに設定される。しかし、ＪＴ－Ｈ３２３エンドポイントはファ
クシミリのみである。その呼はファクシミリのみのモード（すなわちＪＴ－Ｔ３８付属資料Ｂのようなエンドポイント）になる。

- 143 -

ＪＴ－Ｔ３８

JT-T38

JT-T38
JT-T38

付図Ⅲ．２／ＪＴ－Ｔ３８ Ｈ．２４８とＪＴ－Ｈ３２３エンドポイント間でのファクシミリのみの呼設定（ＩＴＵ－Ｔ Ｔ．３８）- 144 -

ＪＴ－Ｔ３８

１）ＳＧＷはＳＣＮ交換機からＩＡＭを受信した後にＭＧＣに Setup メッセージを送る。Setup メッセージから、ＭＧＣはＭＧが関係している回線やどこで呼を終端すべきかを推測してもよい。ＭＧＣがどのようにしてこれを実行するのかについては本標準の範囲外である。
２）ＭＧＣは呼のためのコンテキストを作成する。コンテキストは２つのターミネーションを含む。１つはＳＣＮ側のためのターミネーションで、もう１つはパケット側のためのそれである。更に、両方のゲー
トウェイがＪＴ－Ｔ３８自動遷移方式またはＪＴ－Ｔ３８ＭＧＣ遷移方式をサポートしているかを推測できるようにするために、ＭＧＣはＭＧ１に対して audio RTP/AVP 能力と image/t38 能力の値を応答することを指示する。LocalControl 記述子の中で、オーディオとイメージメディア記述子を取得するよ
うにＭＧに依頼する”ReserveGroup=True”に注意すること。（さらに、ＭＧＣは最良のコーデックを要求するために ReserveValue=false を含めてもよい。しかしながら、省略した場合、MG はＨ．２４８に従ってこの値を初期値として False を設定しなければならない）

ＭＧＣからＭＧヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 11 {Context = $ {Add = DS0/1/1 {Events = 1 { ctyp/dtone, fax/faxconnchange, al/of}}, ; トーンを示す呼のタイプを聞いている SCN 側のターミネーション
Add = $ {Media {
Stream = 1 {LocalControl { Mode = ReceiveOnly, ReserveGroup = True },Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 18 0v=0
c=IN IP4 $m=image $ udptl t38} ; IP 側の用語。PT 0(G.711 PCMU)及び 18(G.729)を備えた RTP オーディオの

能力を表示
}
}
}
}
}

３）ＭＧはコンテキストの作成を受諾し、未知のパラメータ（＄）の中を埋める。ＭＧ１はＪＴ－Ｔ３８自動遷移方式をサポートしない。従い、応答の中のイメージメディアラインを省く。
MEGACO/1 [124.124.124.222]:55555
Reply = 11 {Context = 2000 {Add = DS0/1/1,; SCN ターミネーションが受理される。
Add = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18} ; IP RTP ターミネーションはオーディオ・ペイロード・タイプ 18 で受理される。
}
}
}
}
}
- 145 -

ＪＴ－Ｔ３８

ＭＧがどのパラメータを埋めたかをＭＧＣへ報告する方法を示す。

４）ＭＧＣは、ここでＪＴ－Ｈ３２３エンドポイント（端末、ゲートウェイなど）であると考えられる宛先
エンドポイントに Setup メッセージを送る。それは、ＵＤＰかＴＣＰのいずれかを使用する能力がＪＴ－Ｔ３８ファクシミリストリームのために使用されてもよいことを fastStart 要素で示す。
５）ＪＴ－Ｈ３２３エンドポイントは Alerting メッセージが続く CallProceeding メッセージをＭＧＣへ返して、使用すべきモード（ここでは双方向のＵＤＰと仮定）と転送アドレスをＭＧＣに通知し、引き続く
Alerting メッセージでＧ３ＦＥにリンギングしていることを示す。
６）ＭＧＣは、パケット側でモード及びリモートターミネーションの記述を設定するために、ＭＧに Modify
コマンドを送る。

ＭＧＣからＭＧヘ
MEGACO/1 [123.123.123.4]:55555

Transaction = 1450 {Context = 2000 {Modify = RTP/1 {Events= 3 {fax/faxconnchange},
Media {
TerminationState {fax/faxstate=Prepare;
ipfax/ipftrpt=T38UDPTL;}
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=image 2222 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC} ; イメージメディア(T38 のための udpt1 転送)を使用するために
メディアストリーム 1 を修正。
}
}
}
}
}

- 146 -

ＪＴ－Ｔ３８

７）ＭＧは、Modify コマンドを受諾する。およそこの時点で、ＭＧは回線上のＣＮＧを検出し、ＭＧＣに通知し、認識する。ＪＴ－Ｈ３２３エンドポイントにおいてＣＮＧの再生を開始する手段はないので、Ｍ
ＧＣは回線が開放されるまで待つ。ＭＧＣはＪＴ－Ｈ３２３Connect の前にＣＮＧを受信しないかもしれないことに注意すること。

ＭＧからＭＧＣヘ
MEGACO/1 [124.124.124.222]:55555
Reply = 1450 {Context = 2000 {Modify = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=image 3333 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC}; ファクシミリ udpt1/t38 転送チャネルは IP セッションで受理される。
}}}}
MEGACO/1 [124.124.124.222]:55555
Transaction = 50 {Context = 2000 {Notify = DS0/1/1 {ObservedEvents = 1 {19991212T22110001:ctyp/dtone{dtt=cng} }}}}ＭＧＣからＭＧヘ
MEGACO/1 [123.123.123.4]:55555
Reply = 50 {Context = 2000 {Notify = DS0/1/1}}

８）ＭＧＣは、ＳＧＷに Alerting メッセージを送る。
９）ある瞬間、被呼エンドポイントはＧ３ＦＥが一旦オフフック状態になると、ＭＧＣに Connect メッセージを送る。このメッセージはファクシミリの能力だけを含み、ＪＴ－Ｈ２４５ポートを含まないことに注意すること。

- 147 -

ＪＴ－Ｔ３８

１０）Modify はＭＧに、ＳＣＮ側ターミネーションのモードを SendRecive とファクシミリモードに変更す
るように命令する。また、ＪＴ－Ｔ３８上で設定されるべきファクシミリ能力の指示もこのコマンドに含まれる。（この情報はＪＴ－Ｔ３２３エンドポイントが発行する Connect にも含まれていた）ＭＧＣからＭＧヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 30 {Context = $ {Modify = DS0/1/1 {Media {
TerminationState { fax/faxstate = Prepare},Stream = 1 {LocalControl { Mode=SendReceive } } },Events = 10 {al/of, ctyp/dtone, fax/faxconnchange },Signals = {al/ri }} ; 私たちが接続されると考えるために SCN ターミネーションを修正する。
Modify = RTP/1 {Media {
TerminationState { ipfax/faxstate = Prepare,
ipfax/ipftrpt=T38UDPTL },Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=image 2222 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC} ; イメージメディア(T38 のための udpt1 転送)を使用するために
メディアストリーム 1 を修正。
LocalControl { Mode = SendReceive}}},
Events = 2 { ipfax/faxconnchng }}}}１１）ＭＧＣは、ＳＷＧに呼の接続を示すために Connect メッセージを送る。
１２）ＭＧは、先に送られた Modify コマンドを受諾する。（（１０）参照）

ＭＧからＭＧＣヘ
MEGACO/1 [124.124.124.222]:55555
Reply = 14 {Context = 2000 {Modify = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=image 3333 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC}; ファクシミリ udpt1/t38 転送チャネルは IP セッションで受理される。
}}},
Modify = DS0/1/1}; 修正は DS0 セッションで受理される。
}- 148 -

ＪＴ－Ｔ３８この時点で呼は、ゲートウェイ間をＪＴ－Ｔ３８モードで進んでいる。おそらく発呼Ｇ３ＦＥは、宛先Ｇ３
ＦＥからのＣＥＤが続く、最初に送信されるであろうＣＮＧをまだ送信している。

１３）ＭＧは、Ｖ．２１フラグパケットを受信した後に、ファクシミリ接続状態がいつ変更するのかを示すことを依頼されるので、ＭＧはＭＧＣにイベントを通知することに注意すること。

ＭＧからＭＧＣヘ
MEGACO/1 [124.124.124.222]:55555
Transaction = 60 {Context = 2000 {Notify = RTP/1 {ObservedEvents = 1 {19991212T22110001:ipfax/faxconnchange{faxconnchng=Negotiating }}}}}ＭＧＣからＭＧヘ
MEGACO/1 [123.123.123.4]:55555
Reply = 60 {Context = 2000 {Notify = RTP/1}}

Ⅲ.2.3 ＪＴ－Ｔ３８自動遷移方式をサポートするＨ．２４８を用いた音声からファクシミリへの呼設定

本発呼フロー例（付図Ⅲ．３）はＳＣＮ内で生成され、終端する音声の呼とパケット網を通して転送される音声の呼を記述する。本例ではパケットネットワークのシグナリングについては明記されてないが、ＪＴ－
Ｈ３２３またはＳＩＰのようなシグナリングプロトコルは使用できる。この例の目的は、ＪＴ－Ｔ３８自動遷移モードのサポートの指示、ファクシミリの検出、音声からファクシミリへの切換えを含むＪＴ－Ｔ３８
自動遷移モードで動作している場合のＭＧ／ＭＧＣの相互作用を記述することである。ＭＧＣの制御の下でのファクシミリモードへの切換え（すなわちＪＴ－Ｔ３８ＭＧＣ遷移方式）とは対照的に、ＪＴ－Ｈ２４８．
１で定義されているファクシミリパッケージはＭＧによってサポートされる必要はない。

- 149 -

ＪＴ－Ｔ３８

G3FE1

MG1

MGC

MG2

G3FE2

1 - AUDIT
1 – REPLY

1 - AUDIT
1 - REPLY

2 - OFF HOOK
2 - DIAL TONE
2 - DIALLING
SGW
2 – SETUP(SCTP)
MG1
3 - CREATE CONTEXT
4 – ACK

5 – CREATE CONTEXT
6 - ACK

Voice mode
7 - Modify
8 - ACK Response
9 - CNG
9 – JT-T38 CNG indicator packet
9 - CNG

JT-T38 mode

10a- DCN
10a- JT-T38 package with DCN
10a- DCN
10d- Modify (optional)
10d- Modify (optional)
10d- ACK
10d- ACK

Voice mode

付図Ⅲ．３／ＪＴ－Ｔ３８ ＶｏＩＰとＦｏＩＰ間の自動遷移をサポートするＨ．２４８を使用した音声からファクシミリへの呼設定（ＩＴＵ－Ｔ Ｔ．３８）- 150 -

ＪＴ－Ｔ３８

イベントのシーケンスは次のとおりである。
１）呼の前のある時点でメディアゲートウェイコントローラは能力検査コマンドをメディアゲートウェイに
その制御下で発行し、各ゲートウェイのための音声とファクシミリの機能が何であるかを知ることになる。以下のシナリオでは、両方のメディアゲートウェイがＪＴ－Ｔ３８をサポートしていれば、これはＩＰファクシミリ動作においては好ましいモードである。一方もしくは両方のメディアゲートウェイがＪＴ－Ｔ３８をサポートしていなければ、ファクシミリの呼はＩP 音声チャネルを通して行ってもよい。
しかしながらＪＴ－Ｔ３０ファクシミリは圧縮された音声コーデックを介した場合は正常動作しないかもしれないので、メディアゲートウェイ間の通信にはＪＴ－Ｇ７１１コーデックを使用することが望ましい。‘Ｗ－’はＭＧ上の各ターミネーション能力検査ではなく、ＭＧの全てのターミネーション上
での統一情報を含んだワイルドカード化された回答が要求されることを示すために用いられる。ＭＧ１
がＪＴ－Ｔ３８をサポートすることをＭＧＣに指示することに注意すること。しかしながら、ＪＴ－Ｔ
３８自動遷移方式またはＪＴ－Ｔ３８ＭＧＣ遷移方式（付属資料ＥのＥ．２．２節で記述されている）のサポートを指示するために、能力検査を用いてはいけない。Add Ephemeral（下記（３）参照）の間の発呼の状況によって推測しなければならない。
ＭＧＣはＭＧ１を検査する。
ＭＧＣからＭＧ１ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 9 {Context = - {W-AuditValue = * {Audit{Packages}}}}
ＭＧ１の応答。ＭＧ１からＭＧＣヘ
MEGACO/1 [125.125.125.111]:55555
Reply = 9 {Context = - {AuditValue = * {Packages {al, rtp, ipfax, fax, ctyp, cg}; al = analog line pkg, rtp = rtp pkg, ipfax = T.38 fax pkg, fax = fax pkg; ftmd = fax/textphone/modem tones detection pkg; ctyp = Call Type Discrimination package); cg =call progress tones generator pkg}}}
ＭＧＣからＭＧ１ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 10 {Context = - {W-AuditCapability = * {Audit{Media }}}}ＭＧ１の応答。ＭＧ１からＭＧＣヘ
MEGACO/1 [125.125.125.111]:55555
Reply = 10 {Context = - {AuditCapability = * {Media {
Stream = 1 {Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 0 18
v=0c=IN IP4 $m=image $ udptl t38} ; G.711 のための RTP プロファイルは０、G.729 は 18、t38 は T.38 である。
}
},
}
}
}

- 151 -

ＪＴ－Ｔ３８

ＭＧＣとＭＧ２との間で同様の交換が発生する。
２）エンドユーザがＧ３ＦＥ１装置からファクシミリを送ると決め、電話番号を入力する。ファクシミリ装
置はダイヤルトーンを受信し、その電話番号をダイヤルする。その結果、ローカルＳＣＮループ内の交換局はＮｏ．７信号方式メッセージを信号ゲートウェイ（ＳＧ）へ送る。ＳＣＮ交換機からの、発着電話番号を伝えるこのＩＡＭを受信した後、ＳＧは Setup メッセージをＭＧＣへ送る。Sigtran のＳＣＴＰ
はＮｏ．７信号方式シグナリングをＳＧからＭＧＣへ搬送する。
３）ＩＡＭにより、ＭＧＣはＭＧが関係している回線やどこで呼を終了すべきかを推測してもよい。ＭＧＣ
がどのようにしてこれを実行するのかについては本標準の範囲外である。エンドポイントはメディア
ゲートウェイコントローラ（ＭＧＣ）によって見つけられる。ＭＧＣは２つのメディアゲートウェイ間のオーディオチャネルを設定し、最終目的地の電話に接続するように受信交換局（ＣＯ）のＮｏ．７信号方式設備に指示することによって、リンギングが生成される。従い、コントローラがＭＧ１からＭＧ２への接続が必要かどうかを決定し、開始する。ＭＧＣは、その呼のためのコンテキストを生成する。
ＴＤＭターミネーションＤＳ０／１／１、audio/RTP ターミネーションと image/t38 ターミネーションが、ＭＧ１の新たなコンテキストに加えられる。リモート記述子の値が特定されてないので、モードはReceiveOnly である。望ましいコーデックはＭＧＣの優先順位の選択にある。ＭＧＣはＭＧがそれ自身を設定するであろうローカル記述子の中のＳＤＰ内フィールドをＣＨＯＯＳＥ（すなわち＄）に設定する。さらに、ＭＧＣが、両方のゲートウェイがＪＴ－Ｔ３８自動遷移方式またはＪＴ－Ｔ３８ＭＧＣ遷移方式をサポートしているかを推測できるようにするために、ＭＧＣはＭＧ１に対して audio RTP/AVP
能力と image/t38 能力の値を応答することを指示する。これは、ＭＧにオーディオとイメージメディア
記述子のための資源確保を依頼するための”ReserveGroup=True”を LocalControl 記述子の中に含ませることによって達成されることに注意すること。さらに、メディア記述子の中で提示されている全ての可能なコーデックのための資源を確保するようにＭＧに依頼する”ReserveValue=True”（もしくは、ＭＧＣは最良の符号化を要求するために ReserveValue=false を含むかもしれない。しかしながら、省略した場合、MG はこの値を初期値として false を設定しなければならない。）

ＭＧＣからＭＧ１ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 11 {Context = $ {Add = DS0/1/1 {Media {
Stream = 1 {}}}Add = $ {Media {
Stream = 1 {LocalControl { Mode = ReceiveOnly, ReserveGroup=True,
ReserveValue=True },Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 18 0
V=0
c=IN IP4 $m=image $ udptl t38}; オーディオのための IP ターミネーション。
}
}
}
}
}
- 152 -

ＪＴ－Ｔ３８

４）ＭＧ１は新しいターミネーションを認識し、ローカルＩＰアドレスとＵＤＰポートを書き込む。またＭ
Ｇ１は、ローカルのＳＤＰブロックのメディア記述子内のリストに提示された全てのコーデックのための資源を確保可能で、サポートする。こうして、リモートゲートウェイのためのコーデックの最終選択を委ねる。ＭＧ１は、ＲＴＰポートを２２２２に設定する。ＭＧは、ＶｏＩＰとＦｏＩＰ間の遷移のためのＪＴ－Ｔ３８自動遷移方式をサポートするので、ＭＧはＪＴ－Ｔ３８ポートを４４４４に設定し、サポートされるＪＴ－Ｔ３８能力を含む。ＭＧがＶｏＩＰとＦｏＩＰ間の自動遷移をサポートしなかった場合は、ＭＧはＪＴ－Ｔ３８ポートを０に設定するだろう。もしくは、イメージメディア記述子ラインをいっしょに省き、Ⅲ.2.1 節で示したように進むであろう。

MEGACO/1 [124.124.124.222]:55555
Reply = 11 {Context = 2000 {Add = DS0/1/1, ; SCN ターミネーションが加えられた。
Add = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0 ; MG1 は両方のコーデックのために資源を確保可能。
v=0
c=IN IP4 124.124.124.222
m=image 4444 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC} ; IP ターミネーションが加えられた。
}
}
}
}
}

- 153 -

ＪＴ－Ｔ３８

５）ＭＧＣは、ＤＳ０／２／２をＭＧ２上の新しいコンテキストと関連づけ、ＲＴＰストリーム（すなわち、ＲＴＰ／２が割り付けられる）と発呼ユーザまでのＪＴ－Ｔ３８ストリーム SendReceive 接続を確立する。ＭＧ１は、ＪＴ－Ｔ３８自動遷移方式をサポートしているので、ＭＧＣはＭＧ２がＪＴ－Ｔ３８自動遷移方式をサポートしているかどうかを確認する必要がある。ＭＧＣは、リモートＭＧがＪＴ－Ｔ３
８自動遷移方式をサポートしていることを示すだけではなく、オーディオメディア記述子とイメージメ
ディア記述子をクリエートコンテキストメッセージの Add ephemeral 内の＄に設定されたポートに含ませたり、LocalControl 記述子内でオーディオメディア記述子とイメージメディア記述子の取得をＭＧに依頼するためのプロパティ”ReserveGroup=True”を含ませることにより、ＭＧ２にその確認を依頼する。
さらにＭＧＣはもっとも望ましいコーデックを求めるための ReserveValue=false を含むことに注意すること。

ＭＧＣからＭＧ２ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 30 {Context = $ {Add = DS0/2/2 {Media {
Stream = 1 {LocalControl {Mode = SendReceive}, ReserveGroup=True,
ReserveValue=false },}},Add = $ {Media {
Stream = 1 {LocalControl {Mode = SendReceive },Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 18 0v=0
c=IN IP4 $m=image $ udptl t38},
Remote {v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0v=0
c=IN IP4 124.124.124.222
m=image 4444 udptl t38
a=T38FaxRateManagement :transferredTCF
a=T38FaxUdpEC :t38UDPFEC} ; G.711 に関する RTP プロファイルは 0。
}
}
}
}
}

- 154 -

ＪＴ－Ｔ３８

６）これは認められている。ＭＧ２は、ＶｏＩＰとＦｏＩＰ間の遷移のためのＪＴ－Ｔ３８自動遷移方式をサポートしているので、ＳＤＰ応答内でオーディオとイメージメディア記述子の両方を有効なポート番号に含む。ＲＴＰストリームポート番号は、Megaco/H.248 コントロールポート番号とは異なる。この場
合、その値は１１１１である（ＳＤＰ内）。ＪＴ－Ｔ３８ストリームポート番号は、Megaco/H.248 コン
トロールポート番号とは異なる。この場合、その値は５５５５である（ＳＤＰ内）。リモートＳＤＰから、ＭＧ２はＪＴ－Ｔ３８自動遷移方式を使用してＶｏＩＰとＦｏＩＰ間を遷移しなければならないことがわかる。もし、リモートＳＤＰがオーディオとイメージメディア記述子の両方を備えていなかった
場合は、audio/RTP 接続から image/t38 接続へ遷移するためのＪＴ－Ｔ３８ＭＧＣ 遷移方式とⅢ.2.1 節（７）の手順を使用しないであろう。ＭＧ２はＪＴ－Ｇ７２９（ペイロードタイプ＝１８）を使用すべ
き音声コーデックとして選択する。

ＭＧ２からＭＧＣヘ
MEGACO/1 [125.125.125.111]:55555
Reply = 30 {Context = 5000 {Add = DS0/2/2,
Add = RTP/2 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 125.125.125.111m=audio 1111 RTP/AVP 18
v=0
c=IN IP4 125.125.125.111
m=image 5555 udptl t38
a=T38FaxRateManagement :transferredTCF
a=T38FaxUdpEC :t38UDPFEC
}
}
}
}
}
}

- 155 -

ＪＴ－Ｔ３８

７）上記ＩＰＡｄｄｒ、ＵＤＰｐｏｒｔ、音声コーデックは、ＭＧ１に提供される必要がある。ＶｏＩＰとＦｏＩＰ間を遷移するためにＭＧ２がＪＴ－Ｔ３８自動遷移方式をサポートすることを示すだけではなく、ＤＳ０／１／１ターミネーションへのリングバックに呼出し音を適用し、それを SendReceive に変更する。

ＭＧＣからＭＧ１ヘ
MEGACO/1 [123.123.123.4]:55555
Transaction = 12 {Context = 2000 {Modify = DS0/1/1 {Signals {cg/rt} },;呼出し音を適用
Modify = RTP/1 {Media {
Stream = 1 {LocalControl {Mode = SendReceive, ReserveGroup=True },Remote {v=0
c=IN IP4 125.125.125.111m=audio 1111 RTP/AVP 18
v=0
c=IN IP4 125.125.125.111
m=image 5555 udptl t38
a=T38FaxRateManagement :transferredTCF
a=T38FaxUdpEC :t38UDPFEC
}
}
}
}
}
}
ＭＧ１からＭＧＣヘ
MEGACO/1 [124.124.124.222]:55555
Reply = 12 {Context = 2000 {Modify = DS0/1/1, Modify = RTP/1}}

８）ＭＧ１は認識し、audio/RTP 接続から image/t38 接続に遷移するためにＪＴ－Ｔ３８自動遷移方式を使用しなければならない。
９）発信ファクシミリ装置は、通常ＣＮＧコーリングトーンの生成を始める。第１のメディアゲートウェイ（ＭＧ１）はＣＮＧトーンイベントを検出し、ファクシミリ呼が始まっていることを決定することが予想される。ＭＧ１は image/t38 モードに切り替わり、そのオーディオ／ＲＴＰ接続をミュートし、ＭＧ
２にＪＴ－Ｔ３８ＣＮＧインジケータパケットを送信する（その image/t38 接続経由）。ＪＴ－Ｔ３８
ＣＮＧインジケータを受信すると、ＭＧ２は image/t38 モードに遷移する。これは、ＭＧ１のそれに相当するソースＩＰアドレスの有効なＩＰ／ＵＤＰのＪＴ－Ｔ３８ＵＤＰポートにおいてこのような受信がＪＴ－Ｔ３８へ遷移させるＪＴ－Ｔ３８パケットと想定できるように実行されるかもしれない。
従って、image/t38 モードへの遷移においてこのパケットはデコードされ、タイプＣＮＧとなるように解析され、その結果、適切なＣＮＧトーンを再生する。ＪＴ－Ｔ３８ＵＤＰポートに届くいかなる不必要なＵＤＰパケットを無効にするために、このポートはＪＴ－Ｔ３８自動遷移方式（及びＪＴ－Ｔ３８能力）が呼の前にうまくネゴシエーションされた場合のみに起動されるべきである。ここから両方のＭＧは、この勧告に従い動作する。ＣＮＧトーンが存在しなかった場合は、ＭＧ１は十分な長さのＪＴ－Ｔ
３０プリアンブルフラグを検出して、ＪＴ－Ｔ３８へ遷移し、相当するＪＴ－Ｔ３８Ｖ．２１プリアン- 156 -

ＪＴ－Ｔ３８

ブルインジケータパケットを送出する。もしくは、ＲＦＣ４７３３電話イベントが、両方のＭＧ（すなわち、E.2.2.2.2.1 節に記述されている方法２と３）にてサポートされていて、かつＳＤＰ交換経由または本勧告の範囲外である他のメカニズム経由で示されている場合は、ＭＧ１は E.2.2.2.2.1 節で記述されているパケットネットワークを通して相当するＣＮＧ、ＣＥＤ及びＶ．２１プリアンブルを送出し、十分な長さのＶ．２１プリアンブルフラグを検出した場合のみＪＴ－Ｔ３８への遷移を選択してもよい。

１０）ＭＧは、次のいずれかを検出した場合は、オーディオ／ＲＴＰ接続（ＶｏＩＰ）へ戻らなければならない。
ａ）ＪＴ－Ｔ３０

ＤＣＮメッセージの検出ｂ）双方向無音の検出。ＪＴ－Ｔ３０ Ｔ２タイマ（Ｇ３ＦＥ内）がタイムアウトになるように、７秒
以上の双方向無音を検出したら音声モードへの遷移を検出することが推奨される。
ｃ）音声の検出ｄ）オーディオメディア記述子が存在する場合の Modify コマンドの受信- 157 -

ＪＴ－Ｔ３８

Ⅲ.2.4Ｈ．２４８とＪＴ－Ｈ３２３エンドポイント間における音声端末からファクシミリへの呼設定のためのＪＴ－Ｔ３８自動遷移方式

ファクシミリのみの呼設定手順例（付図Ⅲ．４参照）においては、ＳＣＮから始まりパケット網で終結す
るファクシミリ呼を表わしている。この例のパケット信号は、ＪＴ－Ｈ３２３付属資料ＤのＤ．３節に表わされているが、ＳＩＰのような他のプロトコルを利用することもできる。この例の目的はＭＧとＭＧＣ間の通信を表わすことである。

シグナリングゲートウェイ（ＳＧＷ）とＭＧＣ間の通信は、ＪＴ－Ｑ９３１に基づいて想定している。このインタフェースでは、使うことが出来ない信号は表示していない。ここで記述された能力は、一般的な手順をまとめて記述している。（ただしＳＤＰやＨ．２４５メッセージも利用している）

メディアゲートウェイとＪＴ－Ｈ３２３エンドポイントは音声端末とファクシミリのために配置している。
この例の目的は、ＪＴ－Ｔ３８自動モードを利用することを表示しつつＪＴ－Ｔ３８自動モードで通信した
ときに、ＭＧ／ＭＧＣとＪＴ－Ｈ３２３エンドポイント／ＭＧＣ間の通信を表わし、ファクシミリであることを検出したら音声からファクシミリ通信へ切替えることである。

- 158 -

ＪＴ－Ｔ３８

G3FE

SCN

SGW

MGC

H.323
GW

G3FE

1-OFF HOOK
1-DIAL TONE
1-DIALLING
1-IAM
1-Q:SETUP

MG
3-CREATE CONTEXT
4-ACK
5-SETUP [fastStartG.711 PCMU, JT-T38]
6-Q:CALL PROC
7-Q:ALERTING [fastStartG.711 PCMU, JT-T38]

RINGING

SGW
8-Q:ALERTRINGING
9-Q:CONNECT[H:OLC]

OFF HOOK

MG
10-MODIFY

SGW
11-Q:CONNECT

MG
12-ACK

Voice mode
CNG

Fax mode
JT-T38 CNG packet
CNG
JT-T38 CED packet

CED

JT-T38 V.21 packet

V.21

CED

V.21

付図Ⅲ．４／ＪＴ－Ｔ３８ Ｈ．２４８とＪＴ－Ｈ３２３エンドポイントのＶｏＩＰとＦｏＩＰ間の音声端末からファクシミリへの呼設定のためのＪＴ－Ｔ３８自動遷移方式（ＩＴＵ－Ｔ Ｔ．３８）- 159 -

ＪＴ－Ｔ３８

１）ＳＣＮの交換機からＩＡＭを受信したあと SＧＷはセットアップメッセージをＭＧＣへ送る。
２）ＩＡＭを用いて、ＭＧＣはＭＧが関係する回線やどこが呼の終了かを推定しても良い。どのようにＭＧ
Ｃがこれを実行するかは本標準の範囲外である。
３）ＭＧＣは、その呼のためのコンテキストを生成する。このコンテキストにはＳＣＮ側とパケット側の２つの終端が存在する。ＭＧＣはＭＧがそれ自身をセットするであろう Local 記述子のＳＤＰ内のフィールドをＣＨＯＯＳＥ（すなわち$）にセットする。ＭＧＣは、ＭＧ１がＪＴ－Ｔ３８自動遷移方式をサポートしているのかＪＴ－Ｔ３８ＭＧＣ遷移方式をサポートしているのかを推定するために、audio
RTP/AVP 能力と、image/t38 能力の両方の値を応答するようにＭＧ１に指示する。これは、オーディオと画像メディア記述子のための資源を確保するようＭＧに求めるために、 LocalControl 記述子に“ReserveGroup=True”を含めることで達成できる点に注意。さらに、ＭＧＣは最も良い符号化のために“ReserveValue=False”とする場合もある。しかし、省略した場合、ＭＧは初期値 False をセットすべきである。

ＭＧＣからＭＧへ
MEGACO/1 [123.123.123.4]:55555
Transaction = 11 {Context = $ {Add = DS0/1/1 {Events = 1 { ctyp/dtone, fax/faxconnchange, al/of}}, ; トーンを示す呼のタイプに注意しているＳＣＮ側の終了
Add = $ {Media {
Stream = 1 {LocalControl { Mode = ReceiveOnly, ReserveGroup=True },Local {
v=0
c=IN IP4 $m=audio $ RTP/AVP 18 0v=0
c=IN IP4 $m=image $ udptl t38} ; ＰＴ ０と１８を持つＲＴＰ audio 能力を示す IP 側の終了
}
}
}
}
}

- 160 -

ＪＴ－Ｔ３８

４）ＭＧはコンテキストの生成を受け入れて、不明を表わす（$）パラメータをセットする。ＭＧがＪＴ－
Ｔ３８自動遷移方式を備えている。このため、応答のなかに適切なポート番号が書かれたイメージメ
ディア行を含み、好ましい符号化のためにＪＴ－Ｇ７２９符号化を選択する。
MEGACO/1 [124.124.124.222]:55555
Reply = 11 {Context = 2000 {Add = DS0/1/1,; SCN の終了が受け入れられた
Add = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18
v=0
c=IN IP4 124.124.124.222
m=image 5555 udptl t38} ; IP RTP の終了がオーディオペイロードタイプ０で受け入れられた。また、MG は、
VoIP と FoIP 間の遷移のために JT-T38 自動遷移方式をサポートすることを示す。
}
}
}
}
}

どのようにしてＭＧがＭＧＣに何のパラメータをつめているか以下に表わす。
５）ＭＧＣは Setup メッセージを宛先のエンドポイントに送信する。ここでは仮にＪＴ－H３２３エンドポ
イントとする（端末、ゲートウェイ等）。さらに、ＪＴ－Ｔ３８自動遷移方式をＭＧがサポートすることが分かるため、fastStart 要素において、少なくとも１つのオーディオコーデックと、ＪＴ－Ｔ３８ Ｆ
ｏＩＰ送受信を同時にサポートする能力によってこれを表示する。
６）
ＪＴ－Ｈ３２３エンドポイントは fastStart とともに Alerting メッセージに続いて、CallProceeding メッセー
ジをＭＧＣに返信する。少なくとも１つのオーディオコーデックと、ＪＴ－Ｔ３８ ＦｏＩＰ送受信を同時にサポートする能力を表示することで、ＪＴ－Ｔ３８自動遷移方式をサポートすることを伝えるものである。
７）ＭＧＣは、Alerting メッセージをＳＧＷへ送信する。
８）ＭＧＣは、モードとパケット側のリモートの終了記述を設定するために、Modify コマンドをＭＧへ送信する。
９）いったんＧ３ＦＥがオフフックすると、いくつかの例での被呼エンドポイントはＭＧＣに Connect メッ
セージを送信する。このメッセージにはオーディオとファクシミリ能力の両方が含まれるが、Ｈ．２４
５ポートは含まれていないことに注意。

- 161 -

ＪＴ－Ｔ３８

１０）Modify コマンドが、ＳＣＮ側の SendRecv 終了というモード変更のためにＭＧに送信される。リモー
ト側エンドポイントのオーディオとファクシミリ能力も、このコマンドに含まれる（この情報は、ＪＴ－Ｈ３２３エンドポイントからの Connect に含まれる）。さらにリモート側エンドポイントがＪＴ－Ｔ
３８自動遷移方式をサポートし、まず初めに音声の呼接続を行わなければならないことを表示する。

ＭＧＣからＭＧへ
MEGACO/1 [123.123.123.4]:55555
Transaction = 30 {Context = $ {Modify = DS0/1/1 {Media {
TerminationState { fax/faxstate = Prepare},Stream = 1 {LocalControl { ReserveGroup=True } } },Events = 10 {al/of, fax/faxconnchange },;ＭＧＣはＭＧに、ＪＴ－Ｔ３８に遷移する場合にイベントを送ることを要求する。
Signals = {al/ri }} ; 我々が接続されているということを反映するためにＳＣＮ終了を修正する
Modify = RTP/1 {Media {
TerminationState {ipfax/faxstate=Prepare,
ipfax/ipftrpt=T38UDPTL },Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=audio 1111 RTP/AVP 18
v=0
c=IN IP4 124.124.124.222
m=image 2222 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC} ; ＪＴ－Ｔ３８のための udptl 伝送というイメージメディアを使用するために

メディアストリーム１を修正する
LocalControl { Mode = SendReceive}}},
Events = 2 { ipfax/faxconnchng }}}}- 162 -

ＪＴ－Ｔ３８

１１）ＭＧＣは、呼が接続されたことを通知するため、Connect メッセージをＳＧＷに送信する。
１２）ＭＧは Modify コマンドを受信する。

ＭＧからＭＧＣへ
MEGACO/1 [124.124.124.222]:55555
Reply = 14 {Context = 2000 {Modify = RTP/1 {Media {
Stream = 1 {Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18
v=0
c=IN IP4 124.124.124.222
m=image 3333 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPFEC}; fax udptl/t38 伝送チャネルはＩＰセッションで受け入れられる。そして、ＪＴ－Ｔ

３８自動遷移方式はＶｏＩＰとＦｏＩＰ間の遷移のために使用されなければならない。
}}},
Modify = DS0/1/1}; modify は DS0 セッションで受け入れられる。
}

これより呼はゲートウェイ間における音声モードに進む。ＭＧＣは両方のゲートウェイからの応答によって、ＪＴ－Ｔ３８自動遷移方式が、ＶｏＩＰとＦｏＩＰ間の遷移のために両方のゲートウェイによって使用されなければならないことを知る。おそらく、発呼Ｇ３ＦＥはＣＮＧを送信する。これにより、発呼ゲート
ウェイがオーディオ／ＲＴＰポートを消音し、ＦｏＩＰモードに遷移し、ＩＰ上で対応するＪＴ－Ｔ３８
T30_indicator(CNG)を送信する。もしＣＮＧ信号の送信や検出が出来ない場合は、ＭＧがＶ．２１プリアン
ブルを遷移する判断基準に使うことになる。なぜなら宛先のゲートウェイは、ＪＴ－Ｔ３８のために割当てられているＵＤＰポートでＵＤＰパケットを受信するためであり、ＪＴ－Ｔ３８のパケットであれば、ＪＴ－Ｔ３８モードに遷移しなくてはならない。ここから両方のゲートウェイは、本標準に従って動作する。

代わりに、ＲＦＣ４７３３テレフォンイベントが両方のＭＧにサポートされていて（例えば、E.2.2.2.2.1 節に記載の方法２と３）、ＳＤＰ経由の交換か本標準の範囲を超えた他の仕組みが指示された場合は、ＭＧ１
は E.2.2.2.2.1 節に記載されているようなパケット網で、対応するＣＮＧ、ＣＥＤおよびＶ．２１プリアンブ
ルの送信を選択しても良い。十分な数のＶ．２１プリアンブルフラグの検出によってのみＪＴ－Ｔ３８に遷移する。

これらゲートウェイは、次にあげるようないくつかの検出を元にして、オーディオ／ＲＴＰ接続（ＶｏＩＰ）
へ復帰しなければならない。
－ ＪＴ－Ｔ３０のＤＣＮ信号検出－ 双方向の無音検出。ＪＴ－Ｔ３０のＴ２タイマがタイムアウトするまでは許されており（Ｇ３ＦＥにおいて）、７秒以上の双方向の無音を検出したら、音声モードへの復帰を検出することが推奨される。

- 163 -

ＪＴ－Ｔ３８

付録

Ⅳ（ＪＴ－Ｔ３８に対する）
Ｖ．３４を用いた セッション例（この付録は、本標準の必須部分を形成しない）

Ⅳ.１ Ｖ．３４を用いた セッション例
この節はＶ．３４の半二重ファクシミリセッションにおける信号フローに関するいくつかの例を含む。 図
表中で、送信Ｇ３ＦＥをＦ１、送信ゲートウェイをＧ１、受信ゲートウェイをＧ２、受信Ｇ３ＦＥをＦ２とそれぞれ略する。

F1

G1

G2

F2

t30-indicator(v8-ansam)

CM
ANSam
CM

ANSam

t30-data(v8:cm-message:FAP)

CM

CM

CM

CM
CM

CM

JM
CM

CM
t30-data(v8:jm-message:A0)

CM
JM
CM

JM

CM

JM

CJ

JM

INFO0cINFO0a

JM
CM
JM
CJ

JM

INFO0cINFO0aT.38_FIV.1(APPIV)

付図 Ⅳ.１／ＪＴ－Ｔ３８ Ｖ．８信号 （プロファイルと肯定応答を用いる）（ＩＴＵ－Ｔ Ｔ．３８）- 164 -

ＪＴ－Ｔ３８

F1

G2

G1

F2

TRN
TRN
PPh
PPh
PPh
PPh
ALT

MPh

MPh

MPh

MPh

MPh

E

E

MPh

MPh

E

E

PPh

ALT

ALT

MPh

Flags

ALT

t30-data(v34-pri-rate:v34-rate:336)

DIS

t30-data(v34-CC-1200:HDLC (DIS octets))

Flags
AC
PPh

ALT
ALT

MPh

MPh

MPh

MPh

E

E

Flags

DIS

DCS

t30-data(v34-CC-1200:HDLCFCS-OK-Sig-End)
もし G1 と G2 の通信能力が等しい場合はデータレートを変更する必要はない。もし G1が G2ifより通信能力が低い場合には、
G1 = G2 then okay. No rate G2 からF2 へのデータレートよりも G1 から F1 へのchange needed.
データレートが低いので問題はない。もし G1
G1 < G2 then that too is okay からが G2Ifより通信能力が高い場合は、G2
since source data arrivesG1
slower
F2 へのデータレートよりもから F1 への Flags
than sink can send it.G1 のデータレート
データレートが高いので
If G1 を落とす必要がある。
> G2 then G1 rate needs tobe reduced since the source data
is faster than sink data.
Flags

t30-data[v34-CC-1200:HDLC (DIS octets)]
Flags

t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)

DCS

t30-data[v34-CC-1200:HDLC (CFR)]

Flags

CFR

"1s"

CFR

t30-data(v34-CC-1200:HDLCFCS-OK-Sig-End)

Flags

t30-indicator(v34-pri-channel)

Flags

Flags
"1s"

T.38_FIV.2(APPIV)

付図 Ⅳ.２／ＪＴ－Ｔ３８ データレートネゴシエーションと制御チャネルスタートアップ（ＩＴＵ－Ｔ Ｔ．３８）- 165 -

ＪＴ－Ｔ３８

F1

G1

G2

F2

t30-data(v34-pri-ch:HDLC:image octets)
DATA

DATA
t30-data(v34-pri-ch:HDLC-FCS-OK-Sig-End)Flag

t30-indicator(v34-cntl-channel-1200)

Sh

Sh
Sh*
ALT
E
Flags

Sh

Sh*

Sh*

ALT

ALT

E

E

t30-data(v34-CC-1200:HDLC:PPS-NULL)
t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

Flag
MCF
FLAG

Sh
Sh*
ALT
E

Flags

FLAG

PPSNULL

1s

Flag

Flag
PPSNULL

t30-data(v34-CC-1200:HDLC:MCF)
t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

MCF
FLAG

t30-indicator(v34-pri-channel)

FLAG

1s
S
S*
PP
B1

S
S*
PP
B1

Flags

Flags
t30-data(v34-pri-ch:HDLC:image octets)

DATA

DATA
t30-data(v34-pri-ch:HDLC:image octets)

T.38_FIV.3(APPIV)

付図 Ⅳ.３／ＪＴ－Ｔ３８ 部分ページ間（ＩＴＵ－Ｔ Ｔ．３８）- 166 -

ＪＴ－Ｔ３８

G2

G1

F1

F2

t30-data(v34-pri-ch:HDLC:octets)
DATA

DATA
t30-data(v34-pri-ch:HDLC-FCS-OK-Sig-End)Flag

t30-indicator(v34-cntl-channel-1200)

Sh

Sh
Sh*

Flag

Sh

Sh*

Sh*
ALT

E

Sh*

ALT

ALT

ALT

E

E

Flag
PPSEOP

Flag
Flag

Flag

PPSEOP

t30-data(v34-CC-1200:HDLC:MCF)

DCN

E

t30-data(v34-CC-1200:HDLC:PPS-EOP)
t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

Flag

Sh

MCF

FLAG

t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

MCF

Flag

t30-data(v34-CC-1200:HDLC:DCN)
Flag

t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

DCN

Flag
1s

t30-data(v34-CC-1200:HDLC-Sig-End)

Flag
ls
T.38_FIV.4(APPIV)

付図 Ⅳ.４／ＪＴ－Ｔ３８ 最終ページ（ＩＴＵ－Ｔ Ｔ．３８）- 167 -

ＪＴ－Ｔ３８requests data rate change
F2 F2
がデータレートの変更を要求する場合

F1

G1

G2

Primary
Channel
Data

F2

Primary
ChannelDatat30-indicator(v34-cntl-channel-1200)

Flags

Flags
Sh

Sh

/Sh
Sh

/Sh
PPh

ALT

E
Flags

/Sh

t30-indicator(v34-CC-retrain)

ALT
PPh
ALT

ALT
E

ALT
MPh

MPh

MPh
E

MPh

Flags

PPh

AC

ALT

PPh
ALT

MPh

MPh

MPh

MPh

E
PPSMPSE

Flags

t30-data(v34-pri-rate:v34rate:288)
もし、プライマリチャネルレートに
If F1/G1 Primary Channel data
よって示されているように、F1/G1間のプライマリチャネルデータ信号
signalling rate as indicated by
レートが間のプライマリチャ
PCrate isG2/F2> G2/F2
Primary
ネルデータ信号レートより高いな
Channel data signalling rate, then
ら、PPS-MPS の送信が遅延されていG1 changes its Rate Sequences
る間に、G1 はレートシーケンスを変and initiates a Control Channel
更し、コントロールチャネルのリト
retrain,while delaying
レーニングを開始する。
transmission of MPS-PPS.

E

Flags
Flags

t30-data(v34-CC-1200:HDLC:PPSMPS)
t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)PPSMPS

t30-data(v34-CC-1200:HDLC:MCF)
MCF

Flags
MCF

t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)

Flags
Flags

"1s"

Flags

t30-indicator(v34-pri-channel)

"1s"

S
S
/S
/S
PP
PP

T.38_FIV.5(APPIV)

付図 Ⅳ.５／ＪＴ－Ｔ３８ 受信Ｇ３ＦＥからのリトレーニングによるデータレート変更シーケンス（ＩＴＵ－Ｔ Ｔ．３８）- 168 -

ＪＴ－Ｔ３８

F1 がデータレートの変更を要求する場合
F1 requests data rate change

F1

G1

G2

Primary
ChannelData

Primary
ChannelDatat30-indicator(v34-cntl-channel-1200)

Flags
PPh
PPh
ALT

ALT

MPh

MPh

MPh

MPh

E

F2

E

PPSMPS
Flags

F1 がデータレート変更を要求する
For the situation where F1
状況において、要求されたデータ
requires a rate change, this can
レートが指定された要求を満たす限り、beデータレート変更は認められる。
permitted as long as the rate
G2/F2
間はデータレートの変更を要
requestedmeets the
求されない。
requirements
as specified. The
G2/F2 pair are not required tochange rates.

Flags
Sh
/Sh
Sh
ALT

t30-data(v34-CC-1200:HDLC:PPSMPS)
t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)t30-data(v34-CC-1200:HDLC:MCF)

ALT
E
Flags

E

PPSMPS

Flags

MCF

Flags
MCF
"1s"

/Sh

Flags

t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)
Flags

Flags

t30-indicator(v34-pri-channel)
"1s"

S
S

/S

/S

PP

PP

T.38_FIV.6(APPIV)

付図 Ⅳ.６／ＪＴ－Ｔ３８ 発信 G3FE からのリトレーニングによるデータレート変更シーケンス（ＩＴＵ－Ｔ Ｔ．３８）- 169 -

ＪＴ－Ｔ３８

G2 がデータレートの変更を要求する場合
G2 requests data rate change

F1

G1

G2

Primary
ChannelDatat30-indicator(v34-cntl-channel-1200)

Flags

F2

Primary
Channel
Data
Flags

Sh
PPh
/Sh
Sh
ALT

E
Flags
PPh

ALT

ALT

/Sh
ALT
E
Flags
AC
PPh
ALT

MPh

MPh

MPh

MPh

E

E

PPSMPS
Flags

PPht30-indicator(v34-CC-retrain)t30-data(v34-pri-rate:v34rate:264)
もし、プライマリチャネルレートによって示されているように、F1/G1
If F1/G1 Primary Channel data
間のプライマリチャネルデータ信号
signalling rate as indicated by
レートがG2/F2間のプライマリチャ
PCrate is > G2/F2 Primary
ネルデータ信号レートより高いな
Channel data signalling rate, then
ら、
PPS-MPSの送信が遅延されていG1changes its Rate Sequences
る間に、
G1はレートシーケンスを変and initiatesa Control Channel
更し、コントロールチャネルのリト
retrain, while delaying
transmission of MPS-PPS.
レーニングを開始する
。

ALT

MPh

MPh

MPh

MPh

E

E

Flags
Flags

t30-data(v34-CC-1200:HDLC:PPSMPS)
t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)t30-data(v34-CC-1200:HDLC:MCF)

PPSMPS

Flags
t30-data(v34-CC-1200:HDLC:FCSOK-Sig-End)
MCF
"1s"

Flags

MCF
Flags
Flags

t30-indicator(v34-pri-channel)
"1s"

S
S
/S
/S
PP
PP

T.38_FIV.7(APPIV)

付図 Ⅳ.７／ＪＴ－Ｔ３８ 受信ゲートウェイからのリトレーニングによるデータレート変更シーケンス（ＩＴＵ－Ｔ Ｔ．３８）- 170 -

ＪＴ－Ｔ３８

G１がデータレートの変更を要求する場合
G1 requests data rate change

F1

G1

Primary
ChannelDataG2t30-indicator(v34-cntl-channel-1200)

F2

Primary
Channel
Data

Flags
Flags
Sh
/Sh
PPh

requested meets therequirements as specified. The
G2/F2 pair are not required tochange rates.

ALT

PPh

G1 がデータレート変更を要求する状況において、要求されたデータレートが指定された要For the situation where G1
求を満たす限り、
データレートrequires a rate change,
this can
変更は認められる。G2/F2 間はbepermitted
aslong
as the rate
レート変更を要求されない。

Sh
/Sh
Sh
ALT

/Sh
ALT

ALT
E

E

ALT
MPh

MPh

MPh

MPh
E

E
PPSMPS

Flags
Flags

t30-data(v34-CC-1200:HDLC:PPSMPS)
t30-data(v34-CC-1200:HDLC-FCSOK-Sig-End)Flags

PPSMPS

t30-data(v34-CC-1200:HDLC:MCF)
Flags

MCF
t30-data(v34-CC-1200:HDLCFCS-OK-Sig-End)

Flags

MCF
"1s"

Flags

Flags

t30-indicator(v34-pri-channel)
"1s"

S
S
/S
/S
PP
PP

T.38_FIV.8(APPIV)

付図 Ⅳ.８／ＪＴ－Ｔ３８ 送信ゲートウェイからのリトレーニングによるデータレート変更シーケンス（ＩＴＵ－Ｔ Ｔ．３８）- 171 -

ＪＴ－Ｔ３８

F1

G1

G2

F2

t30-data(v34-pri-ch:HDLC:image octets)
DATA

DATA
t30-data(v34-pri-ch:HDLC-FCS-OK-Sig-End)
Flags

t30-indicator(v34-cntl-channel-1200)

Sh

Sh
Sh*

Flags

Sh

Sh*

Sh*
ALT
E

Sh
Sh*

ALT

ALT
E

E

ALT
E

t30-data(v34-CC-1200:HDLC:PPS-EOM)PPSEOM

Flags
Flags

t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

PPSEOMt30-data(v34-CC-1200:HDLC:MCF)

Flags

MCF

t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)

Flags
MCF

t30-data(v34-CC-1200:HDLC:DIS)
Flags
DIS

Flags
t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)t30-data(v34-CC-1200:HDLC:DTC)

DTC
Flags
Flags

DIS

Flags

t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)
DTC
t30-indicator(v8)

Flags

1s

1s

CM
CM
CM
CM
CM
CM
CM
CM
CJ

JM
JM
JM

INFO0cINFO0at30-data(v8:cm-message:FAP Prof 4)

t30-data(v8:jm-message:A0)

CM
CM
CM
CM
CJ

JM
JM
JM

INFO0cINFO0aT.38_FIV.9(APPIV)

付図 Ⅳ.９／ＪＴ－Ｔ３８ ターンアラウンドポーリング（ＩＴＵ－Ｔ Ｔ．３８）- 172 -

ＪＴ－Ｔ３８

F1

G1

F2

G2

t30-indicator(v8-ansam)

ANSam

ANSam

t30-indicator(v21-preamble)
DIS

START
CNG
CNG

t30-data(v21:HDLC:DIS octets)DIS

t30-data(v21:HDLC-FCS-OK-Sig-End)t30-indicator(v21-preamble)
DIS

CNG

t30-data(v21:HDLC:DIS octets)
t30-data(v21:HDLC-FCS-OK-Sig-End)

CNG

DIS

CNG
CI

t30-data(v8:ci-message: Octet)

CNG

CI
CI

CI

CI
CI

t30-indicator(v8-ansam)

CI

CI

CM
ANSam

CM
t30-data(v8:cm-message:FAP)

CM
CM

ANSam

CM

CM

CM

CM

CM

CM

CM
t30-data(v8:jm-message:A0)

CM
CM

JM

CM
CJ

JM
JM
JM

CM
JM
CM

JM
INFO0cCJ

INFO0cINFO0aINFO0aT.38_FIV.10(APPIV)

付図 Ⅳ.１０／ＪＴ－Ｔ３８ 手動送信(DIS に V.8 能力を示すビット６が１にセットされている)（ＩＴＵ－Ｔ Ｔ．３８）- 173 -

ＪＴ－Ｔ３８

F1

G2

G1

F2

CNG
START

CNG
CNG

No Answer Tone
(optional)

CNG
CNG
t30-indicator(v21-preamble)

CNG

t30-data(v21:HDLC:DIS octets)

CNG
CNG

DIS

CNG

t30-indicator(v21-preamble)

CNG

t30-data(v21:HDLC:DIS octets)
DIS

CNG

DIS

t30-data(v21:HDLC-FCS-OK-Sig-End)t30-data(v21:HDLC-FCS-OK-Sig-End)

DIS
CNG
CNG

CI
t30-data (v8:ci-message:octet)

CI

CNG
CI

CI
t30-indicator(v8-ansam)

CI

CI
CI

CI

CM
CM

ANSam

t30-data (v8:cm-message:FAP)

CM
CM

ANSam

CM

CM

CM

CM

CM

CM

CM

JM
JM

CM

t30-data(v8:jm-message:A0)

CM
JM

CM
CJ

JM

INFO0cINFO0a

CM
JM
CM
JM
CJ

INFO0cINFO0aT.38_FIV.11(APPIV)

付図 Ⅳ.１１／ＪＴ－Ｔ３８ 手動受信(DIS に V.8 能力を示すビット６が１にセットされている)（ＩＴＵ－Ｔ Ｔ．３８）- 174 -

ＪＴ－Ｔ３８

付録

Ⅴ（ＪＴ－Ｔ３８に対する）
ＪＴ－Ｔ３８実装ガイドライン（この付録は、本標準の必須部分を形成しない）

ＪＴ－Ｔ３８を実際に実装した経験に基づいて、ＪＴ－Ｔ３８装置の相互運用性を向上するために記述する。

V.1

一般的な問題V.1.1 伝送ビット順序
伝送ビット順序は７．１．１節および７．１．２節に記述されるとおりである。例えばＤＩＳフレームの最初は「7E FF C8 01…」で始まる。

7E

FF

C8

01

0111111011111111

11001000

00000001

B

B

B

B

E

E

E

E

それぞれのオクテットで「B」は最初、「E」は終端をあらわす。「B」ビットは、最初にＩＰパケットのオクテットに格納され、最初に伝送される。

V.1.2 パケットの間隔
複数のパケットに対処するための十分なバッファがないので、プリアンブルパケットとＪＴ－Ｔ３０信号
パケットの間隔とトレーニングパケットとイメージパケットとの間隔をゲートウェイにおいて設けてもよい。それと同じ理由で、ＣＳＩとＤＩＳのような複数のＪＴ－Ｔ３０信号を送るとき、それぞれの信号の間隔をゲートウェイにおいて設けてもよい。
さらに、パケットをゲートウェイに送るとき、ＤＩＳ／ＤＣＳ交換でネゴシエーションされたモデム速度によって送られるべきである。モデムがパケットを生成する速度を制限できるファクシミリ装置がないので、ＩＡＦの実装では特にこの問題に注意しなければならない。

V.1.3 ＪＴ－Ｔ３０信号の間のプリアンブルパケット
ＪＴ－Ｔ３０信号パケットの間にプリアンブルパケットをいくつかの実装が間違って送る。このタイプのシーケンスを受信するＪＴ－Ｔ３８の実装は正しく処理しなければならない。例えば、 field-type 中の「sig-end」の前に受信したプリアンブルパケットはフラグ(0x7e)と見なされるべきである。

V.1.4 パケット中の信号の分割
１つのＪＴ－Ｔ３０信号フレームを、いくつかの実装が１つのパケットで送り、他の実装はそれを複数のパケットで送る。したがって、ＪＴ－Ｔ３８の実装はどちらの場合においても処理し、必要に応じて複数のパケットを組み立てなければならない。同様にこの考え方はイメージパケットにも適用される。いくつかの実装はすべてのＨＤＬＣフレーム（フラグの間で）を１つのパケットに入れる。その他はパケットにデータを挿入するときフレームの境界を無視してもよい。

- 175 -

ＪＴ－Ｔ３８

V.1.5 パケットサイズの制限
いくつかの実装がＴＣＰモードであっても受信するためにパケットサイズを制限することがある。制限はＥＣＭパケット 1 つ分のサイズに関係している。 この状況について対処することは送信側の責任である。ひ
とつの可能性は送信プロトコルがＴＣＰまたはＵＤＰであるかにかかわらず、そして相手側がＩＡＦかゲー
トウェイにかかわらず同じパケットサイズを使うことである。
ＵＤＰモードにおいて、call-setup でネゴシエーションされた t38FaxMaxDatagram 値を、パケットのサイズを決定することに使用されるべきである。

V.1.6 送信されたＴＣＦのパケット
ＤＩＳ／ＤＣＳ交換でネゴシエーションされたモデム速度に基づいて、１．５秒間の連続する０が、送信されたＴＣＦの１つかそれ以上のパケットの中で送られなければならない。ＪＴ－Ｔ３８装置の受信側がＩ
ＡＦでないならば、ＩＡＦの送信側は、ＴＣＦを生成しなければならない。

V.1.7 ネットワーク技術ガイドライン
V.1.7.1 ＪＴ－Ｔ３８ゲートウェイに関するネットワーク技術
V.1.7.1.1 単一のＪＴ－Ｔ３８ＦｏＩＰネットワークドメイン
図 V.0a に、ＪＴ－Ｔ３８策定時の基準であった、基本的なネットワーク構成を再掲する。
JT-T38 FoIP
標準
ファクシミリ端末(=G3FE)

PSTN-IP
ゲートウェイ

PSTN

JT-T4
端末

IP ネットワー
ク

JT-T38
ゲートウェイPSTN-IP
ゲートウェイ

PSTN

標準
ファクシミリ端末(=G3FE)

JT-T38
ゲートウェイ

JT-T4
端末

図 V.0a 単一の IP ネットワークを介したファクシミリ通信（ＩＴＵ－Ｔ Ｔ．３８）

このように、ファクシミリ通信路上には単一のＩＰネットワークが存在することが想定されている。図１や、付属資料Ｄ・Ｅ・Ｆ、付録Ⅱ・Ⅲ・IV にあるネットワークに関係する図が示すように、このようなネッ
トワーク構成がＪＴ－Ｔ３８の主要なスコープである。（次節で述べているように）ＪＴ－Ｔ３８のＦｏＩ
Ｐサービスは、複数のＩＰネットワークを介した通信をカバーするようには策定されていない。

V.1.7.1.2 複数のＪＴ－Ｔ３８ＦｏＩＰネットワークドメイン
図 V.0b は、複数のＩＰネットワークを介したファクシミリ通信ネットワークを示している
JT-T38 FoIP

JT-T38 FoIP
標準
ファク
シミリ
端末
(=G3FE)
JT-T4
端末

PSTN

PSTN-IP
ゲート
ウェイ

IP ネッ
トワー
ク

PSTN-IP
ゲート
ウェイ

PSTN

PSTN

PSTN-IP
ゲート
ウェイ

IP ネッ
トワー
ク

PSTN-IP
ゲート
ウェイ

JT-T38
JT-T38
ゲート
ゲート
ウェイ
ウェイ
IP ネットワークドメ
イン N (JT-T38 サー
ビス)

JT-T38
JT-T38
ゲート
ゲート
ウェイ
ウェイ
IP ネットワークドメ
イン 1 (JT-T38 サー
ビス)

PSTN

標準
ファク
シミリ
端末
(=G3FE)
JT-T4
端末

図 V.0b 複数のＩＰネットワークを介したファクシミリ通信（ＩＴＵ－Ｔ Ｔ．３８）- 176 -

ＪＴ－Ｔ３８

複数のＪＴ－Ｔ３８ドメインが存在するネットワーク構成は、例えば次のような場合に生じうる。

－ ＪＴ－Ｔ３８がアクセスネットワークレベルで利用され、ＴＤＭがコアネットワークレベルで利用される場合－ 複数のネットワーク管理者が、コア間のネットワーク相互接続にＴＤＭを利用する場合

ＪＴ－Ｔ３８は、複数のＩＰネットワークを介したファクシミリ通信のために策定されていないことに注意しなければならず、それゆえに信頼できるサービスためのいかなる保証も提供されない可能性がある。
従って、そのような種類のＪＴ－Ｔ３８ネットワークは推奨されない。

背景：
ＪＴ－Ｔ３８ゲートウェイは、ＰＳＴＮ回線を介して遠隔のファクシミリ装置と直接接続されていることを想定されている。このようなネットワークとゲートウェイのモデルでは、モデムレベルでのタイミン
グ条件、ＪＴ－Ｔ３０エンドポイントにおけるプロトコルタイマ、ＪＴ－Ｔ３０／ＪＴ－Ｔ３８変換に固有の遅れが存在し、それに合わせてデータレート管理のようなＪＴ－Ｔ３８の能力が調整されている。通信路上には、ＪＴ－Ｔ３８のオンランプとオフランプがそれぞれ１つあることが想定されている。
ＪＴ－Ｔ３８ゲートウェイの対が、ＰＳＴＮネットワークを介して接続されているような構成（図 V.0bの構成）は、ＪＴ－Ｔ３８策定時のスコープ外である。

ファクシミリトランスポートのための代替ＩＰエミュレーションサービス：
複数の仮のＩＰネットワークドメインを介したエンドツーエンドファクシミリ送信では、ＶＢＤｏＩＰ（Ｖ．１５２）を代替のトランスポートとして利用できる。すべてのＩＰドメインにおいて、Ｖ．１５２
を一貫してエンドツーエンドで利用することが推奨されている。

V.1.7.2.

Ｖ．１５３ゲートウェイに関するネットワーク技術

Ｖ．１５３ゲートウェイは、２つのＩＰネットワークドメインを接続し、ＪＴ－Ｔ３８（ＦｏＩＰ）とＶ．
１５２（ＶＢＤｏＩＰ）の相互接続サービスを提供する（Ｖ．１５３参照）。ＪＴ－Ｔ３８に起因する類似のネットワーク技術制約がある。

V.1.7.2.1 単一のＪＴ－Ｔ３８ＦｏＩＰネットワークドメイン
図 V.0c に、ＪＴ－Ｔ３８とＶ．１５２の相互接続のための基本的なネットワーク構成を再掲する（Ｖ．
１５３の図２も参照）
JT-T38 FoIP
標準
ファクシ
ミリ
端末
(=G3FE)
JT-T4
端末

PSTN

PSTN-IP
ゲート
ウェイ

IP ネッ
トワー
ク

JT-T38ゲート
ウェイ

V.152 VBDoIP

IP-IP
ゲート
ウェイ
V.153
ゲート
ウェイ

IP ネットワークドメ
イン 1 (JT-T38 サー
ビス)

IP ネッ
トワー
ク

PSTN-IP
ゲート
ウェイ

V.152
ゲート
ウェイ
IP ネットワークドメ
イン 2 (V.152 サービ
ス)

PSTN

標準
ファクシ
ミリ
端末
(=G3FE)
JT-T4
端末

図 V.0c Ｖ．１５３ゲートウェイを利用し、ＪＴ－Ｔ３８とＶ．１５２のＩＰネットワークドメインの対を介したファクシミリ通信（ＩＴＵ－Ｔ Ｔ．３８）- 177 -

ＪＴ－Ｔ３８このようなネットワークソリューションが実現可能であり、これは２つのＩＰネットワークドメインの接続点としてＶ．１５３ゲートウェイを利用できることを示す。

V.1.7.2.2 ２つの相互接続されたＪＴ－Ｔ３８ＦｏＩＰネットワークドメイン
複数のＪＴ－Ｔ３８ＦｏＩＰネットワークドメインは、ＩＴＵ－Ｔ ＩＰネットワーク間ボイスゲートウェ
イ（Ｇ．７９９．３）や３ＧＰＰトランジションゲートウェイ（ＥＴＳＩ ＴＳ １２９ ２３８）のようなＩＰネットワーク間ゲートウェイを介し相互接続されている可能性がある。図 V.0d はネットワーク構成を示している。
JT-T38 FoIP
標準
ファクシ
ミリ
端末
(=G3FE)
JT-T4
端末

PSTN

PSTN-IP
ゲート
ウェイ

IP-IP
ゲート
ウェイ

IP ネッ
トワー
ク

PSTN-IP
ゲート
ウェイ

IP ネッ
トワー
ク

PSTN

JT-T38ゲート
ウェイ
IP ネットワークドメV.153
IP ネットワークドメ
ゲートウェイ イン 2 (JT-T38 サー
イン 1 (JT-T38 サー
ビス)
ビス)
JT-T38 非依存型
ゲートウェイ

JT-T38
ゲート
ウェイ

標準
ファクシ
ミリ
端末
(=G3FE)
JT-T4
端末

図 V.0d ２つの相互接続されたＪＴ－Ｔ３８ＦｏＩＰネットワークドメインを介したファクシミリ通信（ＩＴＵ－Ｔ Ｔ．３８）

このようなネットワークソリューションは、ＩＰネットワーク間ゲートウェイがいかなる種類のＪＴ－Ｔ
３８処理に対し有効になっていない状況においても利用可能である。ＩＰネットワーク間ゲートウェイには、
むしろ純粋なパケット転送モード(例えば、Ｔ３８トランスポートモードが“ＵＤＰＴＬ－ＵＤＰ”の場合のＵＤＰ透過転送)を提供することが要求され、結果として２つのＩＰネットワークが単一の仮想ＪＴ－Ｔ
３８ＦｏＩＰドメインとなる。
すべての相互接続されたＩＰネットワークセグメントにおいて、共通のＪＴ－Ｔ３８設定を指示・ネゴシ
エーションするかどうかについては、コントロールプレーン次第である。

V.1.7.2.3 Ｖ．１５２ＶＢＤｏＩＰネットワークセクションにより断絶された、複数のＪＴ－Ｔ３８ＦｏＩ
Ｐネットワークドメイン
図 V.0e は、ＪＴ－Ｔ３８ＦｏＩＰネットワークドメインが、Ｖ．１５２ＶＢＤｏＩＰドメインにより相互接続されている構成の例を示している。
JT-T38 FoIP
標準
ファクシ
ミリ
端末
(=G3FE)
JT-T4
端末

PSTN

PSTN-IP
ゲート
ウェイ

IP ネッ
トワー
ク

V.152 VBDoIP

IP-IP
ゲート
ウェイ

IP ネッ
トワー
ク

JT-T38 FoIP

IP-IP
ゲート
ウェイ

IP ネッ
トワー
ク

PSTN-IP
ゲート
ウェイ

PSTN

V.153
JT-T38
V.153
JT-T38
ゲートウェイゲート
ゲートウェイゲート
ウェイ
ウェイ
IP ネットワークドメ
IP ネットワークドメ IP ネットワークドメ
イン 1 (JT-T38 サー イン 2 (V.152 サービ イン 3 (JT-T38 サー
ビス)
ビス)
ス)

標準
ファクシ
ミリ
端末
(=G3FE)
JT-T4
端末

図 V.0e Ｖ．１５２ＶＢＤｏＩＰネットワークセクションにより断絶された、複数のＪＴ－Ｔ３８ＦｏＩＰネットワークドメイン（ＩＴＵ－Ｔ Ｔ．３８）

このような種類のネットワークは、ＪＴ－Ｔ３８、Ｖ．１５２、Ｖ．１５３策定時のスコープ外であったため、問題を引き起こしうる。Ⅴ.1.7.1.2 節で説明したのと同様の理由により、信頼できるサービスのための- 178 -

ＪＴ－Ｔ３８保証はなく、それゆえこのような種類のＪＴ－Ｔ３８ネットワークは推奨されない。

V.2

ＩＡＦの問題V.2.1 ＪＴ－Ｔ３０タイマ値
両方の実装がＩＡＦであるとき、ＪＴ－Ｔ３０タイマ値は２、３倍に拡張してもよい。タイマの拡張は２つの端末を特定の困難な環境において、ファクシミリ通信を成功させる。これらの環境は狭帯域の伝送路や、高頻度のネットワークの遅延やパケットの損失を含む。ＤＩＳ／ＤＣＳのビット１２３は、ＩＡＦを示すネ
ゴシエーションビットである。

V.2.2 ＩＡＦ間のデータレート
ＴＣＰが選択されているときにはＤＩＳ／ＤＴＣ（８．１節参照）で示されるモデム速度により制限されずＩＡＦ間のデータ速度は双方がサポートできる速度となる。ＴＣＰは、MaxBitRate 属性を無視して、プロトコルに依存し、双方が２つのＩＡＦ間でデータ通信を抑えることを許容する。

V.2.3 ＩＡＦとゲートウェイ間のデータレート
ゲートウェイがＴＣＰをサポートしないならば、受信ゲートウェイにおいてバッファオーバーフローが起
こらないようにＩＡＦはデータを送らなければならない。メッセージとデータがＨＤＬＣフレーミング（フラグと０の挿入）なしで送られるので、そして、ＩＡＦはメッセージとデータを生成することができる速度でのファクシミリモデムにより制限されないという理由で、潜在的な問題は起こる。イメージデータのための問題の起こりそうな影響は１つあるいはそれ以上のＥＣＭフレームのエラーである。
送信ＩＡＦは、受信ゲートウェイにより加えられたＨＤＬＣフレーミングによるオーバーヘッドを何らかの手段で考慮してパケットを送るべきである。そうすればゲートウェイのバッファはオーバーフローしない。

V.3
V.3.1

呼設定の問題
Setup メッセージの CalledPartyNumber （付属資料Ｂ）

相手先のファクシミリ番号は Setup メッセージの CalledPartyNumber に設定するべきである。いくつかの受信ゲートウェイがいくつかのファクシミリポートを持っており、その中から１つを選ぶためにその情報を使う。

V.3.2 音声能力の宣言
ＪＴ－Ｈ３２３ゲートウェイの実装は、デフォルトで最初の発呼タイプとして、一般に音声通信をサポートする。ＪＴ－Ｔ３８付属資料Ｂの実装がＪＴ－Ｈ３２３付属資料Ｄの実装を呼ぶとき、ＪＴ－Ｔ３８の実
装はたとえそれがファクシミリ通信だけのためであっても、音声能力を呼設定に含めてよい。

V.3.3 ＪＴ－Ｔ３８付属資料Ｄの属性におけるコロン「：」の不正確な使用について
一 部 の 装 置 業 者 は パ ラ メ ー タ T38FaxFillBitRemoval 、 T38FaxTranscodingMMR 、 お よ び
T38FaxTranscodingJBIG のための付属資料Ｄにおいて定義されたＡＢＮＦを不正確に実装した。一部の実装
者は、これらの属性がコロン（例えば、「a=T38FaxTranscodingJBIG:0」）に続く値（ＳＤＰの att-value）を有すると誤って推測したが、実際にはそうではない。実装者は、どのような属性値が存在している場合であっても、属性がある場合には“true”、属性がない場合には“false”として扱わなければならない。さらに、実装
者 は 、 コ ロ ン と 属 性 値 を 含 む Boolean 属 性 の Ｓ Ｄ Ｐ 属 性 行 を 構 成 し て は な ら な い 。 例 え ば
T38FaxTranscodingJBIG の適切な属性行は、”a=T38FaxTranscodingJBIG”となる。

- 179 -

ＪＴ－Ｔ３８これらのパラメータの正しくは、ＪＴ－Ｔ３８付属資料ＤのＤ．２．３．１節とＤ．２．３．２節に定義されている。

V.3.4 ＳＩＰとＪＴ－Ｈ２４８．１におけるＵＤＰＴＬと T38MaxBitRate との相違について
ＳＩＰとＪＴ－Ｈ２４８．１のためのｕｄｐｔｌ（ＵＤＰＴＬ）と T38MaxBitRate（T38maxBitRate）のＪ
Ｔ－Ｔ３８とＩＡＮＡの定義に違いがある。好ましい実装は、ＪＴ－Ｔ３８の定義、すなわち、ｕｄｐｔｌと T38MaxBitRate である。

V.4

その他

V.4.1 ＭＧＣへのＤＣＮ通知の遅延について
ゲートウェイは送信ファクシミリ装置からのＤＣＮ信号を受信した後にＡＵＤＩＯに遷移することができる。もし、このモードの切り替えがあまりにも速いなら、メディアゲートウェイコントローラからの送信要求を受け取ろうとして、リモートゲートウェイからの ＤＣＮ信号が欠落する可能性がある。
ＤＣＮ遷移モードに移行するとき、ゲートウェイが受信ファクシミリ装置に確実にＤＣＮを送信できることを保障するために、ＭＧ(ＤＳＰ)がＤＣＮを検出してからＭＧＣにこの状態が伝えられるまでに遅延（例えば６００ｍｓ）が必要とされる。

G3FE1

MG1

MGC

MG2

G3FE2

JT-T38 mode

DCN

JT-T38 package with

DCN

DCN
600ms

event:fax-end

ModifyModifyACKACKVoice mode
付図 Ⅴ.１／ＪＴ－Ｔ３８

モード遷移要求開始前のＭＧ１によるタイマ使用（ＩＴＵ－Ｔ

Ｔ．３８）- 180 -

ＪＴ－Ｔ３８

付録

Ⅵ（ＪＴ－Ｔ３８に対する）
セキュリティに関する経緯（この付録は、本標準の必須部分を形成しない）

Ⅵ.1 ＪＴ-Ｔ３８の起源と使用
ＪＴ-Ｔ３８自体はセキュリティサポートの明確な手段を定義していない。
その背景にある理論的根拠は、ファクシミリデータのリアルタイム送信するパケット交換ネットワークの使用法および進化の中で見出すことができる。
図Ⅵ.1は、過去２０年間を４つの重要なフェーズに分けて、その進化を簡略化した図となる。ＪＴ-Ｔ３８の先行技術はＸ．３８参照）となる。ＪＴ-Ｔ３８は、Ｘ．３８から多くの能力を継承している。Ｘ．３８
自体（フェーズ１）は、セキュリティサポートは提供していなかった。その主な理由は：-Ｘ．３８は２つのゲートウェイ間だけに使われていた（発信側と受信側のゲートウェイ）-

ＰＳＴＮ経由のみのネットワークアクセスであり、ＰＳＴＮ自体は信頼できるドメイン（回線交換網）

である-

パケットデータネットワーク（ＰＤＮ）は、回線／フレーム交換網の上位に位置づけられ、しかも潜在的なセキュリティ攻撃に対して非常に強固なネットワーク技術である

ＪＴ-Ｔ３８は、当初（そして現在も）ＰＳＴＮエミュレーションシステム（ＰＥＳ：フェーズ２）に導入されていた。ＩＰ送信は、ネットワークコアレベル上で制限されている、それは、一般的に管理されている（信頼性できる）ＩＰネットワークである。
ＪＴ-Ｔ３８（１９９８年～２０１０年）は、主にサービス提供（フェーズ２）のような形で提供しているため、ＪＴ-Ｔ３８の対応のための明白なセキュリティ要求はなかった。
この仮定は、ＪＴ-Ｔ３８のステージ１／２仕様にて確認することができる： インターネットファクシミリ
Ｆ．１８５のサービス定義ではセキュリティ要求について定義していない。
注記 - Sivannarayana Nagireddiの著書「VoIP Voice and Fax Signal Processing」(ISBN:978-0-470-22736-7)によると、セキュリティ対応へのＪＴ-Ｔ３８

ＦＥＣ 能力の使用について以下のように記されている："前方エラー訂正は多くのディジタル通信システムにおいて用いられている。 また、ＪＴ-Ｔ３８基準のファクシミリにも有用であり、ＦＥＣ技術が安全なＶoＩＰによる音声やファクシミリの送信のための転送ビット列の暗号化処理にも役立っている。 いくつかのＦＥＣに基づく技術が安全なＶoＩＰ通信の一部としてＶoＩＰの特許として報告されている"

ほぼすべての新しい有線および無線アクセス技術がＩＰを対応している、つまり、ＪＴ-Ｔ３８

ＰＳＴ

Ｎ－ＩＰゲートウェイ（フェーズ３）はもはや必要でないかもしれない。ＪＴ-Ｔ３８のエンドポイントはＩＰベースのエンドユーザ端末自体にあり、いわゆるＩＡＦと呼ばれる。ＩＰベースの通信網はセキュリ
ティ議論の焦点となる（例；ネットワークセグメント信用の可否）。
最終的な進化のステップは、すべてＩＰネットワーク（フェーズ４）となるだろう。ＪＴ-Ｔ３８は、より適したＩＰ送信技術に取って代わられるかもしれないが、一般的には依然として電子書類の法的要件に依存している。

- 181 -

ＪＴ－Ｔ３８

フェーズ１ (ＪＴ－Ｔ３８先行技術)

標準
ファクシミリ端末(=G3FE)

PSTN

JT-T4
端末

X.38 FoPDN

PSTN-IP
ゲートウェイ
ITU-T X.38
ゲートウェイ

フェーズ２ (ＰＳＴＮエミュレーションシステム)標準
ファクシミリ端末(=G3FE)

パケット
データネットワーク (PDN)

PSTN

PSTN-IP
ゲートウェイ

JT-T4
端末

PSTN-IP
ゲートウェイPSTN

ITU-T X.38
ゲートウェイ標準
ファクシミリ端末(=G3FE)
JT-T4
端末

JT-T38 FoIP

IP ネットワー
ク

JT-T38
ゲートウェイPSTN-IP
ゲートウェイPSTN

JT-T38
ゲートウェイ標準
ファクシミリ端末(=G3FE)
JT-T4
端末

フェーズ３ (ＰＳＴＮとＩＰベースのネットワークアクセスの混在)
JT-T38 FoIP
インターネット対応ファクシミリ装置(IAF)

PSTN-IP
ゲートウェイIP ネットワーク

JT-T38端末

JT-T38
ゲートウェイ

PSTN

標準
ファクシミリ端末(=G3FE)
JT-T4
端末

フェーズ４ (全てＩＰネットワーク)
JT-T38 FoIP
インターネット対応ファク
シミリ装置(IAF)

IP ネットワーク

JT-T38端末

インターネット対応ファク
シミリ装置(IAF)
JT-T38
端末

図Ⅵ.1 パケットネットワーク上のリアルタイムファクシミリ
- 過去２０年における簡略化されたネットワークの進化 （ＩＴＵ－Ｔ Ｔ．３８）- 182 -

ＪＴ－Ｔ３８

Ⅵ.2 アプリケーション対ネットワーク／トランスポートレベル セキュリティ
ＩＰベースのネットワークアクセス（フェーズ３）での展開におけるＪＴ-Ｔ３８の使用は、セキュリティ観点で最も重要なシナリオといえる。セキュリティは原則としてマルチプロトコルレイヤにてサポートする
ことができる；図Ⅵ.2参照

通信:ｱﾌﾟﾘｹｰｼｮﾝﾚﾍﾞﾙｾｷｭﾘﾃｨ(例, JT-T30 画像暗号化)

a)

IP ドメイン:ﾄﾗﾝｽﾎﾟｰﾄﾚﾍﾞﾙｾｷｭﾘﾃｨ(例 DTLS,TLS,SRTP)b)

IP ドメイン:ﾈｯﾄﾜｰｸﾚﾍﾞﾙｾｷｭﾘﾃｨ(例, IPsec)c)

インターネット対応ファクシミリ装置(IAF)

PSTN-IP
ゲートウェイIP ネットワーク

標準ファク
シミリ
端末
(=G3FE)

PSTN

JT-T38
ゲートウェイ

JT-T38
端末

JT-T4 端末

JT-T38 FoIP
T.38(10)-Amd.1(14)_FVI.2

図 Ⅵ.2 –

アプリケーション 対 ネットワーク／トランスポートレベル セキュリティ（ＩＴＵ－Ｔ Ｔ．３８）

ネットワークとトランスポートレベルのセキュリティの範囲は、ＩＰネットワークに限定されている。トランスポートレベルのセキュリティには、Ｔ３８トランスポートモード（３．６節参照）に依存する複数のオプションがある。
アプリケーションレベルのセキュリティは、ファクシミリ文書（いわば画像）自体の符号化に関連する。Ｊ
Ｔ-Ｔ３０は、文書の機密性と文書の完全性を確保するために、２つのオプションのセキュリティサポート
機能（ＪＴ-Ｔ３０の付属資料Ｆを参照）を定義する。

- 183 -

ＪＴ－Ｔ３８