Itu-T: Procedures For Real-Time Group 3 Facsimile Communication Over IP Networks

I n t e r n a t i o n a l
T e l e c o m m u n i c a t i o n
ITU-T
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
U n i o n
T.38
(09/2005)
SERIES T: TERMINALS FOR TELEMATIC SERVICES
Procedures for real-time Group 3 facsimile

communication over IP networks
ITU-T Recommendation T.38

Procedures for real-time Group 3 facsimile communication over IP networks
Summary
This Recommendation defines the procedures to be applied to allow Group 3 facsimile transmission
between terminals where in addition to the PSTN or ISDN a portion of the transmission path used
between terminals includes an IP network, e.g., the Internet.
This revision of T.38 specifies in Annex B the use of the h245Tunnelling flag during H.323 call
establishment for T.38 devices that do not support H.245, and, in Appendix III, corrects errors in the
procedure examples for H.248 call establishment.
Source
ITU-T Recommendation T.38 was approved on 13 September 2005 by ITU-T Study Group 16
(2005-2008) under the ITU-T Recommendation A.8 procedure.
ITU-T Rec. T.38 (09/2005)
FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of
ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing
Recommendations on them with a view to standardizing telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may
involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
outside of the Recommendation development process.
As of the date of approval of this Recommendation, ITU had received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementors
are cautioned that this may not represent the latest information and are therefore strongly urged to consult the
TSB patent database.
ITU 2006
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
ii
ITU-T Rec. T.38 (09/2005)
CONTENTS
Page
1
Scope ............................................................................................................................
Normative references....................................................................................................
Definitions ....................................................................................................................
Abbreviations................................................................................................................
Introduction ..................................................................................................................
Communication between gateways ..............................................................................

6.1
Internet protocol TCP or UDP.....................................................................
6.2
Gateway facsimile data transfer functions .....................................................
5
5
5
IFT protocol definition and procedures ........................................................................

7.1
General ...........................................................................................................
7.2
IFP packet format ...........................................................................................
7.3
TYPE definitions ............................................................................................
7.4
The IFP DATA element .................................................................................
6
6
8
9
11
IFP message flow for facsimile modulations up to V.17..............................................

8.1
Data rate management method 1 ....................................................................
8.2
Data rate management method 2 ....................................................................
13
13
14
IFT over UDP transport ................................................................................................

9.1
IFT over UDP transport using UDPTL protocol: IFT/UDPTL/UDP.............
9.2
IFT over UDP transport using RTP protocol: IFT/RTP/UDP........................
15
15
17
10
Message flow for V.8 signals and Annex F/V.34 facsimile .........................................
10.1
V.8 negotiation ...............................................................................................
10.2
V.34 data rate management ............................................................................
10.3
Facsimile mode...............................................................................................
10.4
Compatibility with equipment conforming to prior versions of this
Recommendation............................................................................................
18
18
19
21
Annex A ASN.1 notation ......................................................................................................

A.1
T.38 (2002) ASN.1 notation...........................................................................
A.2
T.38 (1998) ASN.1 notation...........................................................................
23
23
25
Annex B H.323 call establishment procedures .....................................................................

B.1
Introduction ....................................................................................................
B.2
Communication between facsimile terminal and gateway.............................
B.3
Communication between gateways ................................................................
26
26
26
26
Annex C The optional forward error correction scheme for UDPTL...................................

C.1
Overview of the optional forward error correction mechanism .....................
C.2
Parity encode/decode scheme operation and characteristics ..........................
33
33
33
Annex D SIP/SDP call establishment procedures ................................................................

D.1
Introduction ....................................................................................................
37
37
ITU-T Rec. T.38 (09/2005)
iii
22
Page
37
Annex E H.248.1 call establishment procedures ..................................................................

E.1
Introduction ....................................................................................................
E.2
45
45
46
Annex F Interworking procedures: T.38 and V.150.1 in the same gateway.........................

F.1
Introduction ....................................................................................................
F.2
SSE reason identifier codes for T.38 transition..............................................
F.3
External signalling..........................................................................................
55
55
56
56
Annex G H.245 Capability Definition for T.38 over RTP....................................................
57
Appendix I Session examples ...............................................................................................

I.1
Session examples............................................................................................
I.2
IAF device ......................................................................................................
59
59
64
Appendix II Examples of call establishment procedures described in Annex B/T.38 ..........

II.1
Sequence examples of call establishment procedures ....................................
II.2
Protocol data used in call establishment procedures ......................................
66
66
70
Appendix III H.248 call establishment procedure examples for facsimile-capable media
gateways .......................................................................................................................
III.1
Introduction ....................................................................................................
III.2
Examples of call setup....................................................................................
75
75
75
Appendix IV V.34 session examples ....................................................................................

IV.1
V.34 session examples....................................................................................
103
103
Appendix V T.38 Implementation Guidelines ......................................................................

V.1
General issue ..................................................................................................
V.2
IAF issues .......................................................................................................
V.3
Call-setup issues .............................................................................................
114
114
115
115
D.2
iv
ITU-T Rec. T.38 (09/2005)

Procedures for real-time Group 3 facsimile communication over IP networks
1
Scope
This Recommendation defines the procedures to be applied to allow Group 3 facsimile transmission
between terminals where in addition to the PSTN or ISDN a portion of the transmission path used
between terminals includes an IP network, e.g., the Internet.
2
Normative references
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
ITU-T Recommendation F.185 (1998), Internet facsimile: Guidelines for the support of the
communication of facsimile documents.
ITU-T Recommendation H.225.0 (2003), Call signalling protocols and media stream
packetization for packet-based multimedia communication systems.
ITU-T Recommendation H.248.1 (2005), Gateway control protocol, Version 3.
ITU-T Recommendation H.248.2 (2005), Gateway control protocol: Facsimile, text

conversation and call discrimination packages.
ITU-T Recommendation H.323 (2003), Packet-based multimedia communications systems.
ITU-T Recommendation Q.850 (1998), Usage of cause and location in the Digital
Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part.
ITU-T Recommendation T.4 (2003), Standardization of Group 3 facsimile terminals for

document transmission.
ITU-T Recommendation T.6 (1988), Facsimile coding schemes and coding control
functions for Group 4 facsimile apparatus.
ITU-T Recommendation T.30 (2005), Procedures for document facsimile transmission in

the general switched telephone network.
ITU-T Recommendation V.8 (2000), Procedures for starting sessions of data transmission
over the public switched telephone network.
ITU-T Recommendation V.34 (1998), A modem operating at data signalling rates of up to

33 600 bit/s for use on the general switched telephone network and on leased point-to-point
2-wire telephone-type circuits.
ITU-T Recommendation V.150.1 (2003), Modem-over-IP networks: Procedures for the

end-to-end connection of V-series DCEs.
ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology

Abstract Syntax Notation One (ASN.1): Specification of basic notation.
ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002, Information technology

ASN.1 encoding rules: Specification of Packed Encoding Rules (PER).
ITU-T Rec. T.38 (09/2005)
IETF RFC 768 (1980), User Datagram Protocol.
IETF RFC 791 (1981), Internet Protocol DARPA Internet Program Protocol
Specification.
IETF RFC 793 (1981), Transmission Control Protocol DARPA Internet Program
Protocol Specification.
IETF RFC 1006 (1987), ISO transport services on top of the TCP: Version 3.
IEFT RFC 2198 (1997), RTP Payload for Redundant Audio Data.
IETF RFC 2327 (1998), SDP: Session Description Protocol.
IETF RFC 2543 (1999), SIP: Session Initiation Protocol.
IETF RFC 2733 (1999), An RTP Payload Format for Generic Forward Error Correction.
IETF RFC 2833 (2000), RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals.
IETF RFC 3550 (2003), RTP: A Transport Protocol for Real-Time Applications.
Definitions
Unless otherwise noted, the definitions in ITU-T Rec. F.185 shall apply. This Recommendation
defines the following terms:
3.1
emitting gateway: The IFP peer which initiates IFT service for a calling G3FE. It initiates
a TCP or UDP connection to a receiving gateway to begin an IFT session.
3.2
receiving gateway: The IFP peer which accepts a TCP or UDP connection from an
emitting gateway, providing IFT service to a called G3FE.
3.3
G3 facsimile equipment (G3FE): In this Recommendation, G3FE refers to any entity
which presents a communications interface conforming to ITU-T Recs T.30, T.4, and, optionally,
T.6. A G3FE may be a traditional G3 facsimile machine, an application with a T.30 protocol
engine, or any of the other possibilities mentioned in the network model for IP Facsimile.
4
Abbreviations
This Recommendation uses the following abbreviations:

ANSam
amplitude-modulated ANSwer tone
CI
Call Indicator (signal)
CM
Call Menu (signal)
CJ
Call Menu terminator (signal)
ECM
Error Correction Mode
FEC
Forward Error Correction
IAF
Internet-Aware Fax device
IFP
Internet Facsimile Protocol
IFT
Internet Facsimile Transfer
INFOh
Half duplex INFO sequence
IP
Internet Protocol
JM
Joint Menu (signal)
ITU-T Rec. T.38 (09/2005)
LSB
Least Significant Bit
MPh
V.34 half-duplex Modulation Parameter sequence
MSB
Most Significant Bit
OLC
Open Logical Channel
RTP
Real Time Protocol
RTCP
Real Time Control Protocol
SUB
Sub-address
TCF
Training check
TCP
Transmission Control Protocol
TPKT
Transport Protocol Data Unit Packet
UDP
User Datagram Protocol
UDPTL
Facsimile UDP Transport Layer (protocol)
Introduction
The availability of IP networks such as the Internet for international communication provides the
potential for utilizing this transmission medium in the transfer of Group 3 facsimile messages
between terminals. Since the characteristics of IP networks differ from those provided by the PSTN
or ISDN, some additional provisions need to be standardized to maintain successful facsimile
operation.
The protocol defined in this Recommendation specifies the messages and data exchanged between
facsimile gateways and/or IAFs connected via an IP network. The reference model for this
Recommendation is shown in Figure 1.
This model shows a traditional Group 3 facsimile terminal connected to a gateway emitting a
facsimile through an IP network to a receiving gateway which makes a PSTN call to the called
Group 3 facsimile equipment. Once the PSTN calls are established on both ends, the two Group 3
terminals are virtually linked. All standard T.30 session establishment and capabilities negotiation is
carried out between the terminals. For non-V.34 G3FEs, TCF is either generated locally or
transferred between the terminals, depending on the mode of operation to synchronize modulation
rates between the gateways and G3FEs.
An alternate scenario would be a connection to a facsimile-enabled device (for example, a PC)
which is directly connected to an IP network. In this case, there is a virtual receiving gateway as
part of the device's facsimile-enabling software and/or hardware. In other environments, the roles
could be reversed, or there might be two facsimile-enabled network devices. The protocol defined
by this Recommendation operates directly between the emitting and receiving gateways.
Communication between the gateways and facsimile terminals and/or other devices is outside the
scope of this Recommendation.
The protocol defined in this Recommendation was chosen on the basis of efficiency and economy.
For optimum performance, the IP transmission paths should have reasonably low delays to meet the
F.185 requirements. Good image quality is provided by error control in the network in addition to
the means provided by the T.30 protocol.
Reliable data transport is provided in two ways: by using TCP over IP networks, or by using UDP
over IP networks with optional means for error control.
Three call control protocols are supported: H.323, SIP, and H.248. H.323 systems may utilize either
method as described in Annex D/H.323. These environments are being used to support voice
ITU-T Rec. T.38 (09/2005)
transmission over IP as an alternative to the PSTN. Since facsimile generally uses the same
facilities as voice communications, it may be desirable to utilize these environments when
implementing facsimile over IP.
Receiving
gateway
Emitting
gateway
Called G3
Facsimile terminal
equipment
Calling G3
Facsimile terminal
equipment
Heisfksdfjslkjdfiowksdfjkowthiuosd fjksdfsdksdf
sdfksldkfjlsdixcovslkdjfweoijsdvkxcvlkjxk
xcvkosfdjgwoidfvlxcvxocivjosdijfg,dklkdjokjvoisdfkldfg
PSTN
PSTN
IP
network
xcvkosfdjgwoidfvlxcvxocivjosdijfg,dklkdjokjvoisdfkldfg
Internetaware fax
device
xcvkosfdjgwoidfvlxcvxocivjosdijfg,dklkdjo kjvoisdfkldfg
T.38_F1
Figure 1/T.38 Model for facsimile transmission over IP Networks

Under some circumstances it may be necessary to make some adjustments to the procedures
between the gateway and the Group 3 terminal. Any such adjustments should not go beyond those
available in the T.30 protocol. These adjustments are implementation-dependent.
The protocol defined in this Recommendation focuses on the interval where a network connection
has been established between two peers (gateway or IAF) implementing the Real-Time Facsimile
document transfer over Internet Protocol.
Management issues, such as directory services (converting PSTN numbers to IP addresses when
required), network hunting, user authentication and CDR (Call Detail Record) collection and
network management (SNMP or others) are important but are not addressed in this
Recommendation. Standardization of these issues will allow the implementation of a network based
on third party management devices, including sharing such devices with other Internet gateways
such as Internet telephony and video, remote access and e-mail.
In addition, user interface aspects, such as the way that the facsimile operator selects the PSTN
number of the destination or identifies himself to the system (for security purposes) are also not in
the scope of this Recommendation. However, it is reasonable to assume that the facsimile operator
uses the Group 3 terminal equipment keypad (using DTMF signals) or the IAF keyboard to provide
the gateway with the required information.
Some of these issues mentioned here are being addressed in other ITU-T and
IETF Recommendations. Specifically, ITU-T Recs H.323/H.225.0, H.248, and SIP and the
Gatekeeper/Call Agent Recommendations address some of the above-mentioned dependencies.
It is intended that all procedures in this Recommendation conform to the requirements of ITU-T
Rec. F.185.
ITU-T Rec. T.38 (09/2005)
The main body of this Recommendation describes the protocol and communication procedures
between the emitting gateway and the receiving gateway. Communication between the gateways
and the calling and called G3FEs as well as call control procedures are described in Annexes B, D,
E, and F.
T.38 ASN.1 version numbers
ASN.1
version
Version-dependent content summary
Original documentation
1998 ASN.1 syntax
Initial publication (1998), Amendment 1 (1999),

Amendment 2 (02/00)
1998 ASN.1 syntax, TPKT, IAF support
Amendment 3 (11/00)
NOTE Some early implementations supporting
TPKT indicate version 0.
2002 ASN.1 syntax
V.34, V.33 support, 2002 Syntax

extended
Updated Recommendation (2002)
The T.38 version number is a mandatory attribute (see Table B.1) that shall be exchanged between
the emitting and receiving gateways. An endpoint shall signal the version that it supports in the
T38Version attribute in its offer. The recipient of the offer shall accept that version or modify the
version attribute to be an equal or lower version when transmitting an answer to the initial offer.
The recipient of an offer shall not respond with an answer containing a higher version than that
which was offered.
Early implementations of T.38 equipment may not provide a T.38 version number. In receipt of
SDP without the version attribute, the endpoint shall assume that the version is 0. Version 0 devices
are recommended to explicitly advertise their version.
6
Communication between gateways
6.1
Internet protocol TCP or UDP
The public Internet service provides two principal modes of data transmission:
TCP (Transmission Control Protocol) A session-based, confirmed delivery service;
UDP (User Datagram Protocol) Datagram service, non-confirmed delivery.

This Recommendation allows the use of either TCP or UDP depending on the service environment.
It defines a layered protocol such that the T.38 messages exchanged for TCP and UDP
implementations are identical.
6.2
Gateway facsimile data transfer functions
The emitting gateway shall demodulate the T.30 transmission received from the calling terminal.
The T.30 facsimile control and image data shall be transferred in an octet stream structure using the
IFP packets, over a transport protocol (TCP or UDP). The following signals are not transferred
between gateways but are generated or handled locally between the gateway and the G3FE: CNG,
CED, and in one mode, TCF. The gateways may indicate the detection of the tonal signals CNG and
CED so that the other gateway can generate them.
The receiving gateway shall decode the transferred information and establish communication with
the called facsimile terminal using normal T.30 procedures. The receiving gateway shall forward all
relevant responses from the called terminal to the emitting gateway.
ITU-T Rec. T.38 (09/2005)
The facsimile data transfer structure is described in 7.1.3. The flow between gateways is described
in clause 8.
6.2.1
Treatment of non-standard facilities requests
The emitting gateway may optionally ignore NSF, NCS and NSS, take appropriate action or pass
the information to the receiving gateway. The receiving gateway may optionally ignore NSF, NCS
and NSS or take appropriate action including passing the information to the receiving G3FE.
Information in other frames related directly to these frames may be altered by the gateway.
7
IFT protocol definition and procedures
7.1
General
This clause contains the textual description of the IFT protocol. The IFT protocol is specified by the
ASN.1 description in Annex A. In the case of a conflict between the ASN.1 and the text, the ASN.1
governs. The ASN.1 encoding in Annex A should employ the BASIC-ALIGNED version of Packed
Encoding Rules (PER) according to ITU-T Rec. X.691 | ISO/IEC 8825-2:2002.
7.1.1
Bit and octet transmission order
Transmission order is as defined in RFC 791 "Internet Protocol", quoted herein as reference:
The order of transmission of the header and data described in this document is resolved to
the octet level. Whenever a diagram shows a group of octets, the order of transmission of
those octets is the normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are numbered.
0
0
1
0
2
0
10
11
12
3
0
T.38_F2
Figure 2/T.38 Transmission order of octets (based on RFC 791, Figure 10)
Whenever an octet represents a numeric quantity the left most bit in the diagram is the high
order or most significant bit. This is, the bit labelled 0 is the most significant bit. For
example, the following diagram represents the value 170 (decimal).
0
T.38_F3
Figure 3/T.38 Significance of bit (based on RFC 791, Figure 11)
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the
whole field is the most significant bit. When a multi-octet quantity is transmitted the most
significant octet is transmitted first.
ITU-T Rec. T.38 (09/2005)
7.1.2
Mapping of the T.30 bit stream
The T.30 bit stream is mapped so that bit order is maintained between the PSTN and IP networks.
This means that the first bit transmitted is stored in the MSB of the first octet, where the MSB is
defined as in 7.1.1.
7.1.3
IFP packet layers for TCP/IP and UDP/IP
The IFP packets described in 7.2 are combined with the appropriate headers for TCP/IP and UDP/IP
as shown in Figures 4, 5 and 6. In Figure 4, the UDPTL header represents the additional header
information required for error control over UDP. The TPKT header defined in RFC 1006 shall
precede the IFP Packet in TCP implementations as shown in Figure 4. Implementations using
TPKT shall set the version to 1 or higher. Version 0 implementations shall not use TPKT.
TPKT header
TCP payload
TCP header
IP header
IFP Packet
IP payload
a) Layered model of IFP/TCP/IP packet
TCP header
IP header
IFP packet
TPKT header
T.38_F4
b) Flat model of IFP/TCP/IP protocol
Figure 4/T.38 High-level TCP/TPKT/IP packet structure

For the UDP transport, IFP data may be encapsulated in UDPTL, as shown in Figure 5, or
alternatively encapsulated in RTP, as shown in Figure 6.
In Figure 5, the UDPTL header represents the additional header information required for error
control over UDP. When UDPTL encapsulation is used, the payload structure is as defined in
Annex A for UDPTLPacket.
UDPTL header
UDPTL payload = IFP packet + Redundancy/FEC
UDP payload
UDP header
IP payload
IP header
a) Layered model of IFP/UDPTL/UDP/IP packet
IP header
UDP header
UDPTL header
IFP packet + Redundancy/FEC
b) Flat model of IFP/UDPTL/UDP/IP protocol
T.38_F5
Figure 5/T.38 High-level UDPTL/UDP/IP packet structure
ITU-T Rec. T.38 (09/2005)
RTP encapsulation of T.38 facsimile signals may only be used if both gateways negotiate this
capability during call setup. This negotiation is described in Annexes B, D, E, or Annex D/H.323.
With RTP encapsulation, the optional redundancy and FEC mechanisms described in RFC 2198 and
RFC 2733 may be used.
Figure 6 represents the packet structure when optional RTP encapsulation is used. Within an RTP
packet, an IFP packet may be optionally combined with a redundant IFP packet (RFC 2198) or with
a FEC packet (RFC 2733 and RFC 2198). Another valid RFC 2733 option, not shown in Figure 6,
allows FEC packets to be sent as a separate RTP stream rather than being combined with IFP
packets into RTP packets. The RTP payload corresponds to a single IFP packet when RFC 2198 is
not used to combine it with a redundant IFP packet or with a FEC packet.
RTP header
RTP payload = IFP packet + Redundancy*/FEC**
UDP payload
UDP header
IP header
IP Payload
a) Layered model of IFP/RTP/UDP/IP packet
IP header
UDP header
RTP Header
* Redundancy per RFC 2198

** FEC per RFC 2733
IFP packet + Redundancy*/FEC**
b) Flat model of IFP/RTP/UDP/IP protocol
T.38_F6
Figure 6/T.38 High-level RTP/UDP/IP packet structure

7.2
IFP packet format
In the following discussion, a message is the protocol or data information transferred in one
direction from a G3FE to or from a gateway during a single period. It may include, for example,
one or more HDLC frames, or a "page" of Phase C data. Messages may be sent across the
IP network in multiple packets. The packets may, for example, contain partial or full, singular or
multiple HDLC frames. Support for multiple packets is provided in this protocol. The DATA
element uses Fields to support partial and full HDLC frames.
IFP operates (listens) over TCP/IP or UDP/IP using a port determined during call setup. All
communication between IFP Peers is done using packets, identified as IFPPackets.
Table 1 summarizes the IFP Packets (for full explanation, refer to the following subclauses).
Table 1/T.38 IFP packet elements
7.2.1
Field
Description
TYPE
Type of message
DATA
Dependent on TYPE
T.38 packet
The T.38 packet element provides an alert for the start of a message. It is used by the IFP peer to
verify message alignment. It is identified by an ASN.1 Application tag. When data is read by the
peer from its TCP/IP or UDP/IP stack, and the expected tag is not present, the session should be
immediately aborted by the receiver.
8
ITU-T Rec. T.38 (09/2005)
7.2.2
TYPE
The TYPE element describes the function of, and optionally the data of, the packet. The legitimate
TYPEs are given in Table 2. Each TYPE is separately explained in the following subclauses. The
table also indicates whether the TYPEs are Mandatory or Optional for implementations using TCP
and UDP.
If the TYPE element is not recognized, it and the related data element shall be ignored.
Table 2/T.38 IFP packet TYPE field
TYPE
DATA Type
Mandatory
T30_INDICATOR
Regular
Yes
Carries indication about the presence of a

facsimile signal (CED/CNG), preamble flags or
modulation indications
Field
Yes
T.30 HDLC Control and Phase C data

(e.g., T.4/T.6 image segment)
T30_DATA
Description
NOTE If both G3FE devices are identified via DIS/DCS exchange as Internet-aware fax (IAF) devices,
the use of T30_INDICATOR is optional.
7.2.3
DATA-Field
The DATA-Field element contains the T.30 HDLC control data and the Phase C image (or BFT)
data. The structure of the DATA-Field is defined in 7.4. The structure carries the modulation data as
well as indicators for the end of an HDLC frame, the status of the Frame Check Sequence (FCS) for
an HDLC frame, and whether the data represents the end of a message.
7.3
TYPE definitions
The following subclauses describe the message TYPEs.

7.3.1
T30_INDICATOR
The T30_INDICATOR TYPE is used by the gateways to indicate the detection of signals such as
CED, HDLC preamble flags, and modem modulation training. It is sent by the receiving gateway to
the emitting gateway, and by the emitting gateway to the receiving gateway. The use of this
message is mandatory, except in the case where both G3FE devices are identified via
DIS/DCS exchange as Internet-aware fax devices. A peer may send this message in order to notify
its peer about upcoming messages. The T30_INDICATOR TYPE has one of the following values
(see Table 3):
ITU-T Rec. T.38 (09/2005)
Table 3/T.38 Listing of T30_INDICATOR values

Signal/Indication
No signal
CNG (1100 Hz)
CED (2100 Hz)
V.21 preamble
V.27 2400 modulation training
V.17 7200 modulation short training
V.17 7200 modulation long training
V.17 9600 modulation short training
V.17 9600 modulation long training
V.17 12 000 modulation short training
V.17 12 000 modulation long training
V.17 14 400 modulation short training
V.17 14 400 modulation long training
V.8 ANSam signal
V.8 signal
V.34-cntl-channel-1200
V.34-pri-channel
V.34-CC-retrain
V.33 12 000 modulation training
V.33 14 400 modulation training
"No signal" indicator may be sent whenever there is no signal in TDM input. For example, it may
be used when modem is changed, from V.21 modem to V.17 one or from V.17 modem to V.21 one.
NOTE It is the responsibility of the gateway receiving the indicator to properly generate the appropriate
analogue signal, including, for example, the ON-OFF cadence, and to terminate it appropriately.
7.3.2
T30_DATA TYPE
The T30_DATA TYPE is used to indicate that the packet contains data in the DATA element and
what modulation was used to carry the data. The T30_DATA TYPE is used to indicate
HDLC control data, Phase C data (T.4/T.6 or other) and, whenever V.34 modulation is used, the
V.8 control signal data and V.34 control and primary channel data.
10
ITU-T Rec. T.38 (09/2005)
It has the following values (see Table 4):

Table 4/T.38 Listing of T30_DATA values
Modulation
V.21 Channel 2
V.27 ter 2400
V.27 ter 4800
V.29 7200
V.29 9600
V.17 7200
V.17 9600
V.17 12 000
V.17 14 400
V.8
V.34-pri-rate
V.34-CC-1200
V.34-Pri-Ch
V.33 12 000
V.33 14 400
NOTE If both G3FE devices are identified via DIS/DCS exchange as IAF devices, T30_DATA values
shall be ignored.
7.4
The IFP DATA element
The DATA Element of the IFP packets contains the data from the PSTN connections and some
indication of the data format. The DATA element is a structure containing one or more Fields. Each
Field has two parts: the first part indicates the Field-Type; the second part contains the Field-Data.
The meanings for the Field-Type are shown in Table 5.
Table 5/T.38 Field-Type and Field-Data description
Field-Type
HDLC data
Field-Type description
Data transmitted over the PSTN connection as HDLC. This includes the
T.30 control messages as well as Phase C data sent using ECM.
The Field-Data that follows contains some, or all, of a single HDLC data
frame starting with the address frame of the HDLC frame, up to but not
including FCS. Bit stuffing is removed from all data. The end of a frame is
indicated by the FCS field. The gateway is responsible for bit stuffing,
FCS generation, and separating frames with one or more flag (0x7E) when
sending the HDLC data to a G3FE.
HDLC-Sig-End
Indicates that the HDLC power level has dropped below the turnoff
threshold. There is no Field-Data with this Field-Type. This field type can
be used during V.34 operation for terminating control channel at the end of
a session.
HDLC-FCS-OK
Indicates the end of an HDLC frame and that the proper FCS was received.
It also indicates that this frame is not the final frame. There is no
Field-Data with this Field-Type.
ITU-T Rec. T.38 (09/2005)
11
Table 5/T.38 Field-Type and Field-Data description

Field-Type
Field-Type description
HDLC-FCS-Bad
Indicates the end of an HDLC frame and that the proper FCS was not
received. It also indicates that this frame is not the final frame. There is no
Field-Data with this Field-Type.
HDLC-FCS-OK-Sig-End
Indicates the end of an HDLC frame and that the proper FCS was received.
In non-V.34 mode, it also indicates that V.21 modulation should terminate.
In V.34 mode, flags shall be sent following the frame. There is no FieldData with this Field-Type.
HDLC-FCS-BAD-Sig-End
Indicates the end of an HDLC frame and that the proper FCS was not
received and transmission should terminate. It also indicates that this frame
is the final frame. There is no Field-Data with this Field-Type.
T.4-Non-ECM
T.4 Phase C data that is not sent using ECM or TCF data in the case of
Method 2 of Rate Adaptation. It also indicates that this is not the end of the
Phase C data.
The Field-Data that follow are the demodulated Phase C data, including fill
bits and RTC.
T.4-Non-ECM-Sig-End
T.4 phase C data that is not sent using ECM or TCF data in the case of
Method 2 of Rate Adaptation. It also indicates that this is the end of the
Phase C data.
The Field-Data that follow are the demodulated Phase C data, including fill
bits and RTC.
cm-message
The data of the CM signal is translated into the Facsimile Application

Profile (see Table 8).
The Field-Data is a single IA5 character of the Profile Number in Table 8.
For example, a "1" indicates Profile 1.
jm-message
Response to the cm-message as defined in 10.1.

The Field-Data is an IA5 character string of length two octets. The first
character is "A" if it is an ACK, or "N" if it is a nACK. The second
character is "0" if the first character is "A" and the appropriate nACK value
as shown in Table 9. For example, nACK(1) is represented as "N1".
ci-message
Data transmitted in the V.8 CI signal is mapped to an IA5 character.

The Field-Data that follows contains the IA5 character octet of either "4"
or "5" based on the decode of bits 6-8 of the CI Call Function bits. Note
that b8 is the MSB and b6 the LSB.
V.34-rate
Indicates the negotiated Primary Channel data signalling rate between

receiving gateway and receiving G3FE.
The Field-Data is an IA5 character string of length three octets the two
least significant digits are always 0 and not represented. The first octet
after the V.34-pri-rate field type is the most significant digit of the data rate
(e.g., "024" represents 2400 bit/s). (Note that the rate of 2400 bit/s between
receiving gateway and receiving G3FE is disallowed due to possible
symbol-rate mismatch.)
Multiple fields can appear in a single IFP DATA Element. The example below shows two
HDLC frames arranged in a single DATA Element.
12
ITU-T Rec. T.38 (09/2005)
Field-Type
Field part
description
HDLC-Data
FCS-OK
HDLC-Data
Indicates end of
First HDLC frame.
The HDLC octets with HDLC frame and
zero stuffing and FCS more data to follow
removed in the FieldData.
Second HDLC
frame
FCS-OK-Sig-End
Indicates end of
HDLC frame and
end of HDLC data
NOTE When the Field-Type DATA element is received, the receiver should analyse it by examining each
field separately. If the receiver does not recognize a certain Field-Type of the field it is examining, the entire
field shall be skipped, and the receiver shall continue with the next field.
The IFP peer may elect to send the message data in several packets. Although relatively large
packets may be sent, smaller data packets are recommended. It is entirely up to the emitting
gateway to decide on the size of packets being sent. The xx-Sig-End Field-Types indicate the end of
the message data. Note that for each packet sent, the whole header is repeated.
A message with zero length data field may be sent to indicate, as early as possible, that T30_DATA
messages are coming. Alternately, the appropriate T30_INDICATOR signal for High Speed could
be sent. Implementations shall support both methods.
Partial HDLC frames are also supported. The next example shows how two HDLC frames would be
transmitted using three consecutive IFP packets. (Data transport headers are not shown.)
TYPE
element
DATA element
V.21 Data
FieldType:
HDLC
Data
HDLC
Address
(0xff)
HDLC
Control
HDLC
Octet 1
HDLC
Octet 2
V.21 Data
FieldType:
HDLC
Data
HDLC
Octet 7
HDLC
Octet 8
HDLC
Octet 9
FieldType
FCSOK
V.21 Data
FieldType:
HDLC
Data
HDLC
Address
(0xff)
HDLC
Control
HDLC
Octet 1
FieldType
FCSOKSigEnd
HDLC
Octet 3
HDLC
Octet 4
HDLC
Octet 5
HDLC
Octet 6
IFP message flow for facsimile modulations up to V.17
The gateways follow the T.30 message flow and use the packet format in clause 7 to transmit these
messages. This means, for example, that error correction in ECM mode is done between the sending
G3FE and the receiving G3FE. The PPS, PPR, etc., signals are sent between the end G3FE devices.
In another example, negotiation of security keys, etc., as proscribed in Annex H/T.30 is done
between the end G3FE devices. Examples of typical message flows are shown in Appendix I.
There are two methods of handling the TCF signal for determining the high-speed data rate. Either
of these methods ensures that both PSTN facsimile sessions be conducted at the same speed.
8.1
Data rate management method 1
Method 1 of data rate management requires that the TCF training signal be generated locally by the
receiving gateway. Data rate management is performed by the emitting gateway based on training
results from both PSTN connections.
ITU-T Rec. T.38 (09/2005)
13
Method 1 is used for TCP implementations and is optional for UDP implementations.
When a confirmation to receive (CFR) or a failure to train (FTT) is received from a G3FE at the
receiving gateway, a T.30 HDLC packet (indicating CFR or FTT respectively) should be forwarded
to the emitting gateway.
Based on the results of a TCF received from a G3FE and the T.30 HDLC packet (CFR or FTT)
forwarded from a receiving gateway, an emitting gateway shall transmit FTT or CFR according to
Table 6.
Table 6/T.38 Decision table of signalling rate of an emitting gateway
T.30 signal
message forwarded
from receiving gateway
TCF signal
received from a G3FE
at emitting gateway
Signal to be
transmitted
to G3FE (emitter)
CFR
Success
CFR
FTT
Success
FTT
CFR
Failure
FTT
FTT
Failure
FTT
In the case where the Emitting Device is an Internet-aware fax (IAF) device and there is no emitting
gateway, the IAF device shall respond to FTTs from the receiving gateway with appropriate DCS
responses, including possibly modulation changes.
In the case where the Receiving Device is an IAF device and there is no receiving gateway, the IAF
device shall respond to DCS from the emitting gateway with CFR, but shall be prepared for a DCS
in case the emitting gateway generates an FTT.
In the case where the emitting device and the receiving device are IAF devices, the emitting device
shall send DCS with the modulation bits set to 0, and the receiving device shall respond with CFR.
The data rate over the IP network is established during call setup.
8.2
Data rate management method 2
Data rate management method 2 requires that the TCF be transferred from the sending G3FE to the
receiving G3FE rather than having the receiving gateway generate it locally. Speed selection is
done by the G3FEs in the same way as they would on a regular PSTN connection.
In the case where the emitting device is an Internet-aware fax (IAF) device and there is no emitting
gateway, the IAF device shall respond to FTTs from the receiving gateway with appropriate
DCS + TCF responses, including possibly modulation changes.
In the case where the receiving device is an IAF device and there is no receiving gateway, the
IAF device shall respond to DCS from the emitting gateway with either CFR or FTT, depending
upon the received TCF signal.
In the case where the emitting device and the receiving device are IAF devices, the emitting device
shall send DCS with the modulation bits set to 0, and the receiving device shall respond with CFR.
The data rate over the IP network is established during call setup. Data Rate Management Method 2
is mandatory for use with UDP. Method 2 is not recommended either for use with TCP, or for the
case where both G3FE devices are identified via DIS/DCS exchange as IAF devices.
14
ITU-T Rec. T.38 (09/2005)
IFT over UDP transport
9.1
IFT over UDP transport using UDPTL protocol: IFT/UDPTL/UDP
9.1.1
Overview of UDPTL protocol
In the following discussion, a packet is regarded as a block of information which has the overall
structure of that presented in 7.1.3.
The layered model in Figure 5-a may be visualised more simply (Figure 5-b) in a flat space which
allows packets to be regarded as a composite of headers plus the IFP payload. It is the IFP payload
which is used to convey facsimile related information between gateways; all other information
should be regarded as overhead necessary for the safe transportation and interpretation of
IFP messages as described in clause 7. This clause describes the UDPTL payload. Descriptions of
the IP and UDP headers and payloads are found in RFCs 791 and 768 respectively.
UDPTL packets comprise a sequence number and a variable length, octet aligned, payload.
UDPTL packets are based upon the principle of framing. Each packet may contain one or more
IFP packets in its payload section. The first packet in any payload is always formatted in
accordance with the specifications of clause 7 and must correspond to the sequence number
supplied in the header (for instance, the first field in a payload with sequence number 15 must have
been generated 5 payloads later than the first field in the payload with sequence number 10). The
IFP packet in a UDPTL payload is referred to as the "primary". Additional fields may be included
in a payload after the primary. These fields are referred to as "secondaries" and may or may not be
formatted as per clause 7 specifications depending on their form.
9.1.2
UDPTL header section format
The UDPTL sequence number is used to identify the sequencing in a payload.

9.1.2.1
UDPTL sequence number element
Each packet, and therefore primary field, has its own corresponding unique sequence number which
specifies an ordering at the receiving gateway should packets arrive out of sequence. To enable
gateways to be synchronized upon receipt of any packet, the first primary field transmitted shall
have sequence number zero. Successive primaries shall have linearly increasing (integer adjacent)
sequence numbers.
9.1.3
UDPTL payload section format
During H.323 capabilities exchange, a gateway shall indicate its support of the available error
protection schemes, parity FEC, or redundancy. Based on these capabilities, a choice may be made
on which scheme is used for error protection. If a capability is indicated to receive both parity error
correction frames and redundant frames, then either scheme may be used. If, however, a gateway
indicates a capability to receive only redundant error protection frames, then the transmitting
gateway may not send parity FEC frames. The support of parity FEC is optional; a gateway
providing parity FEC receive services should, however, also be capable of receiving redundant
messages.
The IFP payload section comprises one or more fields. The basic format of an UDPTL payload is as
shown in Figure 7.
Figure 7 specifies the order in which different messages are to be assembled into the
UDPTL payload. It is invalid to transmit both redundant and FEC fields within the same packet.
ITU-T Rec. T.38 (09/2005)
15
SEQUENCE
NUMBER
OPTIONAL REDUNDANT
MESSAGE
OPTIONAL REDUNDANT
MESSAGE
OR
OR
MANDATORY MESSAGE
(PRIMARY)
n packets
OPTIONAL FEC
MESSAGE
OPTIONAL FEC MESSAGE

T.38_F7
Figure 7/T.38 Basic format of UDPTL payload section (UDP header not shown)
9.1.3.1
UDPTL FEC message format
An FEC contains a parity-encoded representation of a number of primaries. The number of primary

IPF packets represented by an FEC field is given by the fec-n-packets element of the
UDPTLPacket.
9.1.4
IFP/UDP facsimile data transfer functions
9.1.4.1
Use of redundancy messages
Each primary contains an IFP packet. As packets, and therefore primaries, are assigned unique and
linearly increasing sequence numbers, receiving gateways can detect packet loss and re-sequencing
requirements. By imposing a simple structure it is possible to provide error recovery by means of
transmitting redundant information in the form of prior primary packets within each payload. The
strategy used is to assemble an additional n prior packets after the primary with monotonically
decreasing sequence numbers. Thus, should each payload contain a primary and two or more
secondary fields, a loss of two consecutive UDPTL packets will be protected against. In order to
provide a redundancy service in the UDPTL, it is necessary to maintain a buffer of "old" primaries
for assembly into new packets. An illustration of such a buffer is provided in Figure 8 to
demonstrate the principles of redundancy transfer by example.
SEQUENCE NUMBER
( 45 )
Sequence
PRIMARY
MESSAGE
REDUNDANCY
MESSAGE 1
REDUNDANCY
MESSAGE n
IFP Message Store
45
IFP MESSAGE
44
IFP MESSAGE
43
IFP MESSAGE
42
IFP MESSAGE
41
IFP MESSAGE
T.38_F8
Figure 8/T.38 Including prior (secondary) IFP packets (fields) into an UDPTL packet
Note that the UDPTL scheme is only capable of transmitting a block of redundant IFP packets
whose sequence numbers are contiguous. Thus, if the current IFP packet has sequence number C
and it is desired to redundantly transmit the IFP packet from UDPTL packet sequence number C-2,
then the UDPTL packet must contain all the IFP packets from C, C-1, C-2 in the order given.
Gateways need not be capable of transmitting redundant packets. Receiving gateways may ignore
them.
16
ITU-T Rec. T.38 (09/2005)
9.2
IFT over UDP transport using RTP protocol: IFT/RTP/UDP
For UDP transport, the RTP protocol (RFC 1889) may be used as an alternative to UDPTL. The
RTP protocol is used when both gateways negotiate this capability during call setup. This
negotiation is described in Annexes B and D.
Additional capabilities available to RTP streams may optionally be used as long as these are
negotiated by both gateways. These include redundancy (RFC 2198) and FEC (RFC 2733).
There are a few differences which must be considered when using RTP instead of UDPTL. These
differences result from differences in the payload format and operational procedures for RTP and
UDPTL. Along with the similarities between these formats, these differences are highlighted in
Table 7.
Table 7/T.38 Similarities and differences between RTP and UDPTL
Feature
Payload format
UDPTL mechanism
UDPTLPacket specified in
Annex A
RTP mechanism
Without redundancy and FEC, RTP
payload is a single IFP packet.
When FEC packets constitute a
separate stream (RFC 2733), the RTP
payload is a single IFP packet.
With RFC 2198-based redundancy,
the RTP payload structure is as
specified in RFC 2198.
With FEC that uses RFC 2198
encapsulation, the RTP payload
structure is as specified in RFC 2733
and RFC 2198.
Negotiation necessary to use

RTP or UDPTL protocol
In order to be used, the

UDPTL-based T.38 capability
must be proposed by one gateway
and selected/accepted by the other
gateway. The capability
declaration and negotiation
procedures are per Annexes B, D,
and E, or Annex D/H.323.
In order to be used, the RTP-based

T.38 capability must be proposed by
one gateway and selected/accepted by
the other gateway. The capability
declaration and negotiation
procedures are per Annexes B, D,
and E, or Annex D/H.323.
Payload sequencing
UDPTL sequence number
RTP sequence number
Redundancy
Uses mechanism defined in

clause 9
RFC 2198
FEC
Uses mechanism defined in

Annex C
RFC 2733, with or without RFC 2198

encapsulation
Each RTP packet starts with a fixed RTP header. The following describes the payload specific
fields of the RTP fixed header when the RTP packet encapsulates fax:
Payload Type (PT): The payload type for fax is a dynamic payload type identified by the
name "t38". If redundancy is used per RFC 2198, the payload type must indicate the
payload format RED (as per RFC 2198).
Marker (M) bit: The marker bit is not used for fax and MUST be set to zero. The Marker bit
should be ignored by the receiver of the packet.
ITU-T Rec. T.38 (09/2005)
17
10
Message flow for V.8 signals and Annex F/V.34 facsimile
10.1
V.8 negotiation
V.8 is used as a means to negotiate capabilities of facsimile and modem devices. This includes the
modulations and the applications supported by the devices. During the negotiation procedure the
ANSam, CI, CM, JM and CJ signals are interchanged between the calling and called G3FEs. The
CM and JM signals are compelled end-to-end in order to fully verify a matching application or
capability set. In the T.38 reference configuration, the CM information received by the emitting
gateway from the calling G3FE is transferred to the receiving gateway that then uses it
appropriately (possibly modifying it) and transmits it to the receiving G3FE. The receiving G3FE in
response, transmits its JM signal to the receiving gateway. The receiving gateway then passes the
information (again modifying it if necessary) to the emitting gateway, that in turn, transmits it to the
calling G3FE. Once the emitting gateway has the JM information, it has full knowledge of the
connection capabilities.
At the initiation of a call, the ANSam signal begins the V.8 exchange for both V.34 facsimile and
V.8-based modems. Call initiation in a multimode gateway, including V.8-based modems and V.34
G3FEs, is described in Annex F.
This clause describes the handling of ANSam and the V.8 exchange for call initiation in
facsimile-only gateways as well as for supporting V.34 turn-around polling (see 10.3.5) and
re-starting V.34 in manual mode (see 10.3.6).
ANSam shall be detected by the receiving gateway and generated by the emitting gateway. When
ANSam is detected by the receiving gateway, it shall be reported using the v8-ansam indicator if
the emitting gateway is V.34 capable. If the emitting gateway is not V.34 capable, the receiving
gateway shall report ANSam using the ced t30-indicator.
In the event that there is a timeout in response to an ANSam generated by the emitting gateway,
resulting in a V.21 response, either gateway may elect to prevent a possible return to
V.8 negotiations by resetting the V.8 bit of the DIS message (bit 6, first octet).
An emitting gateway shall report the Facsimile Application Profile (FAP) to the receiving gateway
when it has detected two identical/consecutive CM signals, and has verified that the Call Function
Category octet contains a facsimile function. If the Call Function is not a valid facsimile value, then
the call can be terminated as being a non-supported call type. The profile is transmitted to the
receiving gateway using the cm-message data Field-Type, where it is regenerated for transmission
to the receiving G3FE.
The Facsimile Application Profile contains a base profile number. The base profile represents the
contents of the Call Function and Modulation Modes of the V.8 CM signal. Table 8 shows the six
possible valid facsimile profiles.
Table 8/T.38 List of valid facsimile profiles
Description
V.8 identifying code-points
G3 Facsimile Terminal: (Sending

Facsimile)
Call Function = 4
G3 Facsimile Terminal:
(Receiving Facsimile)
Call Function = 5
V.34 HDX and G3 Facsimile

Terminal: (Sending Facsimile)
Call Function = 4
18
Modulation = V.17, V.29, V.27 ter, V.21

Modulation = V.17, V.29, V.27 ter, V.21
Modulation = V.34 HDX, V.17, V.29, V.27 ter, V.21
ITU-T Rec. T.38 (09/2005)
Profile No.
1
2
3
Table 8/T.38 List of valid facsimile profiles

Description
V.8 identifying code-points
V.34 HDX and G3 Facsimile

Terminal: (Receiving Facsimile)
Call Function = 5
V.34 HDX-only Facsimile

Terminal: (Sending Facsimile)
Call Function = 4
V.34 HDX-only Facsimile

Terminal: (Receiving Facsimile)
Call Function = 5
Profile No.
Modulation = V.34 HDX, V.17, V.29, V.27 ter, V.21
4
5
Modulation = V.34 HDX-only
Modulation = V.34 HDX-only
The receiving gateway shall transmit an acknowledgement (ACK) when it has received two
identical/consecutive JM signals, and has determined that the profile being requested by the
emitting gateway is acceptable to the remote terminal. The receiving gateway shall transmit a
Negative Acknowledgement (NAK) to the emitting gateway if the profile is not acceptable. The
value of the NAK depends upon the JM response. See Table 9.
Table 9/T.38 Negative Acknowledgement (NAK) message to invalid profiles
NAK(0)
No compatible mode available
NAK(1)
No V.34 fax, use G3 fax Response for profiles 1 and 2
NAK(2)
V.34 fax only. Response for profiles 5 and 6
Upon completion of the V.8 signalling, the emitting and receiving gateways shall proceed with the
appropriate modulation specified indicated by the jm-message response.
10.2
V.34 data rate management
The two gateways shall independently proceed with phase 2 and phase 3 of V.34 half-duplex
handshake as described in clause 12/V.34.
To prevent the overflow of data from the calling terminal (calling G3FE) being transmitted to the
answering terminal (receiving G3FE), the primary channel data signalling rate of the calling
G3FE/emitting gateway terminal-gateway pair shall be less than or equal to the primary channel
data signalling rate of the receiving gateway/receiving G3FE terminal gateway pair. Preference is to
ensure that the rates are equal and the fastest compatible rate is selected. In the case where the
calling G3FE/emitting gateway rate is less than that of the receiving gateway/receiving G3FE rate
and the data is arriving at rate slower than being transmitted to the receiving G3FE terminal, gaps
may be filled with HDLC flags between frames. Note that the only possibility of a data signalling
rate incompatibility can be avoided by the receiving gateway disallowing a data rate of 2400 bit/s.
Once a T.30 session has begun, data rate changes shall be managed to preserve these requirements.
10.2.1 Control channel start-up
Control channel start-up can occur after training of the primary channel or after sending data in the
primary channel (T.30 Phase C) if there is no request to change the primary channel data rate via a
control channel retrain.
The control channel rate shall be 1200 bit/s. Support for control channel rate of 2400 bit/s is for
further study.
The data rate shall be negotiated in the control channel start-up or control channel retrain of the
V.34 half-duplex handshake. The emitting gateway shall be responsible for the correct selection of
the data rates for the primary channel of the G3FEs. It is not necessary to constrain the equipment at
ITU-T Rec. T.38 (09/2005)
19
both ends to the same symbol rate. The emitting gateway, once trained up, shall exchange
HDLC flags in the control channel until it receives the primary channel signalling rate of the
receiving gateway/receiving G3FE pair via the v34-pri-rate message. Once the emitting gateway
has information of both its own negotiated data rate and the data rate selected by the receiving
gateway/receiving G3FE pair, the emitting gateway shall determine if it must change the primary
channel rate between itself and the calling G3FE, using a control channel retrain with a modified
MPh. The local rate parameter shall be set to a value that is less than or (preferably) equal to the
receiving G3FE value. Once the rate selection criteria has been met, the receiving gateway and the
emitting gateway can pass on the T.30 DIS, DCS signals, etc., as normal. If the T.30 messages such
as DIS are received from the receiving gateway while a control channel retrain is in progress
between the emitting gateway and the calling G3FE, the emitting gateway shall buffer the incoming
message and delay transmission of the T.30 messages until the rate selection and negotiation
procedure is completed. Once completed, DIS, etc., can be transmitted from the emitting gateway to
the calling G3FE.
10.2.2 Control channel retrain
Once a T.30 session is established (i.e., after T.30 Phase B has started with the exchange of DIS),
the primary channel data rate can be changed between pages or between partial pages via control
channel retrain. Either the sending G3FE or the receiving G3FE can initiate a data rate change by
sending AC. A control channel retrain from the G3FEs can be signalled using the v34-CC-retrain
indicator. A gateway may initiate a retrain sequence at an appropriate time in response to this
indicator. The retrain sequence can cause an MPh exchange between a gateway and a G3FE,
resulting in a new data signalling rate for the primary channel.
When a control channel retrain occurs in an attempt to change the primary channel data rate, the
requirement to prevent data overflow, as defined in 10.2, shall be preserved. Either the calling
G3FE or the receiving G3FE may initiate a data rate change request, leading to two main cases to
consider. For each case, the rate may increase or decrease. The behaviour for each case is defined
below:
Retrain initiated by the calling G3FE

In this case, no signals are sent from the emitting gateway to the receiving gateway.
a) The calling G3FE requests a rate increase.
If the rate request would result in the calling G3FE rate to be greater than the rate
between the receiving gateway and the receiving G3FE, the emitting gateway shall not
allow the rate increase, else it may allow it.
b) The calling G3FE requests a rate decrease.
The emitting gateway may change the rate as requested.
Retrain initiated by the receiving G3FE

In this case, the receiving gateway shall send the v34-CC-retrain indicator, followed by
the v34-pri-rate message with the new data rate that is selected.
a) The receiving G3FE requests a rate increase.
The receiving gateway may change the rate as requested. The emitting gateway may, at
an appropriate time, initiate a control-channel retrain with the sending G3FE, and
increase the data rate of the calling G3FE if it is less than or equal to the new rate of the
receiving G3FE.
b) The receiving G3FE requests a rate decrease.
The receiving gateway may change the rate as requested. If the new rate indicated by
the v34-pri-rate message is less than the calling G3FE rate, the emitting gateway shall,
at the appropriate time, initiate a control-channel retrain with the sending G3FE and
20
ITU-T Rec. T.38 (09/2005)
decrease the primary channel data rate of the calling G3FE so that it is less than or
equal to the new rate of the receiving G3FE.
Note that a control channel retrain may be initiated at any time when the control
channel is active. One appropriate time for the emitting gateway to initiate the required
retrain is after the post-page message exchange but before the start-up of the primary
channel.
10.3
Facsimile mode
10.3.1 Control channel

Control channel data exchange begins after the MPh exchanges are complete and the parameters for
the control channel rate and the primary channel rate have been agreed.
The control channel is a full duplex channel that, unlike the non-V.34 fax modes, sends flags in the
absence of data (compared to silence for the non-V.34 modes). It is the responsibility of the
gateway or IAF to generate flags as needed during control channel operations.
Control channel packets are sent using v34-CC-1200 t30-data "modulation" value with Field-Types
of hdlc-xxx.
The hdlc-xxx-sig-end Field-Types indicate the end of an HDLC message. Flags shall be sent after
this instead of "silence" as in non-V.34 operation.
10.3.2 Switch from control channel to primary channel
The source terminal indicates its intention to shut down the control channel and switch to the
primary channel by sending continuous ONEs of at least 40 in number and until it detects that the
recipient terminal has stopped sending flags.
An emitting gateway shall signal a receiving gateway or IAF that it is ready to transition to the
primary channel by sending the v34-primary-channel indicator.
10.3.3 Primary channel
Annex F/T.30 requires that all image data be sent using ECM. This means that primary channel data
shall be sent in packets using v34-primary-channel Data Value and Field-Types of hdlc-xxx.
In the case where the calling G3FE/emitting gateway primary rate is less than that of the receiving
gateway/receiving G3FE rate, causing the data to arrive at a rate slower than is being transmitted to
the receiving G3FE, HDLC flags shall be used to fill between frames.
10.3.4 Switch from primary channel to control channel
The emitting gateway shall send the v34-control-channel-1200 indicator after the primary channel
turn-off sequence is complete. After receiving the v34-control-channel-1200 indicator, the
receiving gateway shall initiate the turn-off of the primary channel between it and the called G3FE.
If a change in the primary channel bit rate is not desired, the control channel starts up per 10.3.1. If
a change in primary channel bit rate is desired, the v34-CC-retrain t30-indicator is sent per 10.2.2
instead of the v34-control channel t30-indicator.
10.3.5 Turn-around polling mode
Turn-around polling is accomplished by shutting down the control channel after a DTC command
and initiating a V.8 exchange with CM (ANSam is not used). The source terminal (calling G3FE)
indicates its intention to do turn-around polling by sending DTC and sends flags until continuous
ONEs are detected. After the ONEs are detected, the source terminal is quiet for 70 ms and then
initiates CM. The receiving terminal indicates its intention to shut down the control channel and
ITU-T Rec. T.38 (09/2005)
21
switch to V.8 exchange by sending continuous ONEs of at least 40 in number and until it detects
that the source terminal has stopped sending flags.
Turn-around polling shall be supported between the calling G3FE and the receiving G3FE as
follows.
The receiving gateway shall detect the T.30 DTC signal. After receiving DTC, the receiving
gateway shall prepare to detect continuous ONEs from the receiving G3FE. Upon detection of
continuous ONEs, it shall send the v8 indicator to the emitting gateway.
The emitting gateway, after receiving the v8 indicator from the receiving gateway, shall send
continuous ONEs to the emitting G3FE until the G3FE stops sending flags. The emitting gateway
will then shut down the control channel, and prepare to receive the CM message from the emitting
G3FE device. Upon receipt of the CM message, it shall forward the Facsimile Application Profile
(FAP) to the receiving gateway using the cm-message.
The receiving gateway, upon detecting turn-off of the control channel, from the receiving G3FE,
shall go quiet until it receives the Facsimile Application Profile. Upon receiving the profile it shall
send the appropriate CM to the receiving G3FE.
The emitting gateway shall transmit an (ACK or nACK) to the receiving gateway after it has
received two identical JM signals from the emitting G3FE, as described in 10.1. The operation is
identical to normal V.8 negotiation except the emitting and receiving gateways switch behaviour.
10.3.6 Manual entry into Annex F/V.34 operation
Manual entry into V.34 is accomplished by the calling G3FE responding with CI to a DIS from the
receiving G3FE with bit 6 set to 1. The receiving G3FE responds to CI with ANSam, thus initiating
the normal V.8 sequence described in 10.1.
To support manual entry, the emitting gateway shall be capable of detecting CI after sending DIS in
non-V.34 mode. If CI is received in response to DIS, the emitting gateway shall send a ci-message
to the receiving gateway, and prepare to receive the V.8ANSam signal in response.
When the receiving gateway, operating in non-V.34 mode, receives the ci-message, it shall
regenerate the CI signal to the receiving G3FE, and prepare to receive ANSam from it.
10.3.7 Disconnect
At the end of a call, a gateway shall indicate the end of the control channel with the
hdlc-xxx-sig-end or the no-sig indicator to the remote gateway.
10.4
Compatibility with equipment conforming to prior versions of this Recommendation
A T.38 device conforming to earlier versions of ITU-T Rec. T.38 (ASN.1 versions 0, 1, 2) will not
be able to interpret some messages added to enable V.34 capability. This generally should not
present a problem because the gateways should discover during the call setup exchange what their
respective capabilities are, including what version of ITU-T Rec. T.38 is supported. (See for
example Annexes B, D and E). The following table shows the possible combinations and the
resulting compatibility.
Emitting gateway
V.34 HDX capable
Receiving gateway
V.34 HDX capable
No
No
Standard T.38
No
Yes
Fallback to Standard T.38
Yes
No
Fallback to Standard T.38
Yes
Yes
V.34 HDX T.38 procedures used
22
ITU-T Rec. T.38 (09/2005)
Comment
A non-V.34 (V.8) facsimile device will not recognize the amplitude modulation or phase reversals
on an ANSam signal and will treat the signal as CED. A T.38 device conforming to earlier versions
of this Recommendation will not be able to understand the T30_INDICATOR V.8 ANSam signal.
A T.38 device conforming to this version of ITU-T Rec. T.38 shall only send signals defined in
previous versions of T.38 to another device conforming to previous versions of T.38. A T.38 device
detecting a T30_INDICATOR V.8 ANSam signal shall map this signal into a T30_INDICATOR
CED signal before sending it to a T.38 device indicating version 0, 1, or 2 capability. A T.38
gateway conforming to version 3 of ITU-T Rec. T.38 may not advertise V.8 capability or respond to
V.8 handshake with an external facsimile device when interoperating with a version 0, 1, or 2 T.38
device.
Annex A
ASN.1 notation
A.1
T.38 (2002) ASN.1 notation
T38 DEFINITIONS AUTOMATIC TAGS ::=

BEGIN
IFPPacket ::= SEQUENCE
{
type-of-msg
Type-of-msg,
data-field
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,
,
v8-ansam,
v8-signal,
v34-cntl-channel-1200,
v34-pri-channel,
v34-CC-retrain,
v33-12000-training,
v33-14400-training
},
ITU-T Rec. T.38 (09/2005)
23
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
}
}
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
24
ITU-T Rec. T.38 (09/2005)
A.2
T.38 (1998) ASN.1 notation
T38 DEFINITIONS AUTOMATIC TAGS ::=

BEGIN
IFPPacket ::= SEQUENCE
{
type-of-msg
Type-of-msg,
data-field
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,
},
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
ITU-T Rec. T.38 (09/2005)
25
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
Annex B
H.323 call establishment procedures
B.1
Introduction
This annex describes system level requirements and procedures for Internet-aware facsimile
implementations and Internet-aware facsimile gateways conforming to this Recommendation to
establish calls with other T.38 implementations including those using the procedures defined in this
annex as well as Annex D/H.323.
B.2
Communication between facsimile terminal and gateway
Communication between a sending Group 3 facsimile terminal and the incoming gateway is
generally effected using dial-up procedures over the PSTN. Basic and optional T.30 procedures are
supported. The support for V.34 is for further study.
The gateway may receive the facsimile transmission from the calling terminal as a modem signal on
the PSTN if the gateway supports a direct dial-in procedure. Where the gateway is located within
the network, it may receive the transmission in the form of a PCM-encoded digital channel.
Internet-aware facsimile (IAF) implementations are connected directly to the IP network and act as
a gateway for call establishment.
B.2.1
Transfer of addressing information
The conveyance of the E.164 address of the called terminal from the calling terminal to the emitting
gateway may be by manual procedures using prompts, by means of double dialling, or by any other
suitable means. In addition, there are some applications which may benefit from placing the
destination E.164 address in the IRA (Internet Routing Address)/ISP (Internet Selective Polling)
signals, as described in ITU-T Rec. T.30.
B.3
B.3.1
Overview
B.3.1.1
Call setup
Call setup for T.38 Annex B compliant implementations is based on the Fast Connect Procedure
defined in ITU-T Rec. H.323. T.38 implementations may operate in two distinct H.323 compatible
environments.
26
ITU-T Rec. T.38 (09/2005)
1)
2)
A facsimile-only over IP environment. In this environment, no voice support is provided.

The procedures and requirements of this annex shall apply to implementations operating in
this environment unless they are superseded by an H.323 Annex D implementation.
A facsimile and voice over IP environment. Implementations in this environment shall use
the methods described in Annex D/H.323.
T.38 Annex B implementations use only the Fast Connect Procedure for call setup and do not
support H.245 negotiation. H.323 Annex D implementations, on the other hand, support both the
Fast Connect Procedure and the normal H.323 procedure for call setup. Most
H.323 implementations also support H.245 negotiation.
B.3.1.2
Media channels
Annex D/H.323 requires that T.38 facsimile packets are sent on a separate TCP/UDP port from
H.225.0 call signalling. All required ports are established during the initial fastStart exchange. A
minimal T.38 Annex B implementation requires a TCP port for call signalling and either a UDP
port for UDPTL, or two UDP ports for RTP (one for RTP and one for RTCP), or a TCP port for
T.38 facsimile information.
B.3.1.3
Usage of ITU-T Rec. H.245
Endpoints conforming to this annex are not required to support ITU-T Rec. H.245, except as
required in this annex to support fastStart signalling. As described in B.3.9 below, an H.323
endpoint can use the Facility message to determine that the T.38 Annex B endpoint does not
support ITU-T Rec. H.245.
B.3.2
Basic call setup
H.323 implementations have a multi-phase call setup procedure, which includes:
RAS (Registration, Admissions and Status) signalling using UDP between the endpoint and
the gatekeeper.
H.225.0 call signalling either directly between endpoints, or between endpoints and
gatekeeper depending on the call model in use, using TCP/IP.
H.245 capability negotiation and logical channel management using TCP/IP.

Although support for RAS is mandatory, an H.323 endpoint is not required to use RAS unless a
gatekeeper is present in the network and willing to provide service to the endpoint. Thus, an
Annex B implementation could be used with or without a gatekeeper. It could obtain its IP
addresses in any fashion desired, such as LDAP or a personal directory. However, if placed in a
gatekeeper environment, it would register and operate as per ITU-T Rec. H.323.
Implementations conforming to this annex shall conform to H.323 RAS signalling. RAS signalling
allows a T.38 implementation to initiate a call, using the H.323 well-known TCP port, and provides
dynamic assignment of the port to use for the T.38 messages.
Implementations conforming to this annex utilize H.323 call setup messages as described
in 8.1.1/H.323: "Basic call setup neither endpoint registered" assuming this to be the case. The
initial text of 8.1/H.323: "Phase A Call Setup" is also relevant to T.38 implementations. The rest
of 8.1/H.323 applies if one or both endpoints are registered with a gatekeeper.
Implementations conforming to this annex shall initially start calls by opening a TCP/IP session and
sending an H.225.0 SETUP message with the fast connect fields filled in as described in
8.1.7/H.323.
The receiving terminal replies with an H.225.0 ALERTING, CALL PROCEEDING, PROGRESS,
or CONNECT message as per the procedures of ITU-T Rec. H.323 "fast connect". The Annex B
ITU-T Rec. T.38 (09/2005)
27
implementation shall not include any video, voice, or data OLC elements in the "fastStart"
structure. Instead it includes OLC elements pertinent to facsimile as described in the next clause.
B.3.3
Capabilities negotiation
There are several options that need to be negotiated to determine which options the gateways
support and use. See Table B.1.
Table B.1/T.38 Gateway option capability support indications
Option
Description
Data rate management

method
Method 1: Local generation of TCF is required for use with TCP.
Data transport protocol
The emitting gateway may indicate a preference for either UDP/UDPTL, or

UDP/RTP, or TCP for transport of T.38 IFP Packets. The receiving device
selects the transport protocol.
Fill bit removal
Indicates the capability to remove and insert fill bits in Phase C, non-ECM
data to reduce bandwidth in the packet network. Optional. See Note.
MMR transcoding
Indicates the ability to convert to/from MMR from/to the line format for
increasing the compression of the data and reducing the bandwidth in the
packet network. Optional. See Note.
JBIG transcoding
Indicates the ability to convert to/from JBIG to reduce bandwidth. Optional.

See Note.
Maximum buffer size
For UDP (UDPTL or RTP) modes, this option indicates the maximum
number of octets that can be stored on the remote device before an overflow
condition occurs. It is the responsibility of the transmitting application to
limit the transfer rate to prevent an overflow. The negotiated data rate
should be used to determine the rate at which data is being removed from
the buffer.
Maximum datagram size
This option indicates the maximum size of a UDPTL packet or the

maximum size of the payload within an RTP packet that can be accepted by
the remote device.
Version
This is the version number of ITU-T Rec. T.38. New versions shall be
compatible with previous versions.
Method 2: Transfer of TCF is required for use with UDP (UDPTL or RTP).
Method 2 is not recommended for use with TCP.
NOTE Bandwidth reduction shall only be done on suitable Phase C data, i.e., MH, MR and in the case
of transcoding to JBIG MMR. MMR and JBIG require reliable data transport such as that provided by
TCP. When transcoding is selected, it shall be applied to every suitable page in a call.
These capabilities are negotiated using the OLC elements as defined in the T38faxProfile of
H.245 V7 (or higher).
Two unidirectional, reliable or unreliable, logical channels (sender to receiver channel and receiver
to sender channel) as shown in Figure B.1 or, optionally, one bidirectional reliable channel as
shown in Figure B.2 shall be opened for the transfer of T.38 packets. T.38 packets can be
transferred using either TCP or UDP (UDPTL or RTP). In general, the usage of TCP is more
effective when the bandwidth for facsimile communication is limited, or for IAF to IAF transfers
since TCP provides flow control. On the other hand, the usage of UDP (UDPTL or RTP) may be
more effective when the bandwidth for facsimile communication is sufficient.
28
ITU-T Rec. T.38 (09/2005)
Source
Sending logical channel
Destination
Receiving logical channel

T.38_FB.1
Figure B.1/T.38 A pair of unidirectional channels

Source
Sending stream
Destination
Receiving stream
T.38_FB.2
Figure B.2/T.38 A single bidirectional channel

The sender terminal specifies a TCP/UDP port in the OpenLogicalChannel in the fastStart
element of Setup when transmitting T.38 via TCP or UDPTL. The receiver terminal shall provide its
TCP (or UDP) port in the OpenLogicalChannel of the fastStart element as specified by the
procedures in 8.1.7/H.323: "Fast connect".
The receiver should open the TCP/UDP port based on the preference of the sender. If the sender
terminal has a preference for UDP (UDPTL or RTP) or TCP, then it shall provide its preference in
the OpenLogicalChannel with the appropriate port in the fastStart sequence. The receiving
terminal can select the transport, TCP or UDP (UDPTL or RTP), by specifying one of the two in
OpenLogicalChannel structures in the fastStart element of Connect.
When transmitting T.38 over RTP, the OpenLogicalChannel contains the generic audio capability
defined in Annex G and shall be included in the fastStart element in the Setup message as specified
in 8.1.7/H.323: "Fast Connect". The parameter names in the generic audio capability are named the
same as those used in the H.245 ASN.1.
All T.38 Annex B implementations shall include a T38fax OLC with t38FaxUdpOptions and
transferredTCF set in the fastStart structure. Note that all H.323 Annex D devices supporting
T.38 also are required to include these structures. In addition, T.38 Annex B devices shall include
an OLC with t38FaxTcpOptions and localTCF set and with tcp selected as the t38FaxProtocol
choice. Optionally, T.38 Annex B devices may include an OLC with the T38RTP generic audio
capability specified with the transferredTCF included in the fastStart structure. As described
in 8.1.7/H.323, the order in which OLCs are included in the fastStart element indicates preference
on the part of the sender. The receiver only includes the OLCs that it wishes to use in the fastStart
element of the Connect.
NOTE In the first version of this annex, it was not possible to use a single bidirectional reliable channel. In
order to retain backward compatibility, the endpoint may specify support for bidirectional reliable channels
by including the t38FaxTcpOptions SEQUENCE and setting the t38TCPBidirectionalMode field to
TRUE. If the other endpoint does not include the t38FaxTcpOptions SEQUENCE, the endpoint shall
assume that a single bidirectional reliable channel for T.38 is not supported and shall use either two
unidirectional reliable or unreliable channels.
ITU-T Rec. T.38 (09/2005)
29
B.3.4
Examples of call setup OLCs
The examples in this clause illustrate the OLC elements that are sent in various cases. The rules of
8.1.7/H.323 are followed using OLC definitions in ITU-T Rec. H.245. Refer to ITU-T Rec. H.245
for the relevant ASN.1.
B.3.4.1
TCP, UDP (UDPTL), or RTP support
The default case requires support for both TCP and UDP (UDPTL). In this case, the sender shall
send OLCs for T38/TCP&localTCF and T38/UDPTL&transferredTCF. Optionally, the sender
may send OLCs for T38RTP&transferredTCF. If the receiver wishes to use UDP, an OLC for
T38/UDPTL&transferredTCF is returned. If the receiver wishes to use RTP, an OLC for
T38RTP&transferredTCF is returned. Otherwise, the OLC for T38/TCP&localTCF is returned.
B.3.4.2
UDP (UDPTL) with data rate management method 1 support
For the case where the sender wishes to use data rate management method 1 and UDP (UDPTL) for
data transport, it shall send OLCs for T38/UDPTL&transferredTCF, T38/UDPTL&localTCF,
T38/TCP&localTCF. If the receiver agrees to use UDPTL&localTCF, an OLC for
T38/UDPTL&localTCF is returned.
B.3.4.3
RTP with data rate management method 1 support
For the case where the sender wishes to use data rate management method 1 and RTP for data
transport, it shall send OLCs for T38RTP&transferredTCF and T38RTP&localTCF. If the
receiver agrees to use RTP&localTCF, an OLC for T38RTP&localTCF is returned.
B.3.5
Mandatory call setup messages
The Annex B implementation shall support the following clauses of H.225.0 for call setup:
Mandatory elements in Table 4/H.225.0, i.e., ALERTING, CONNECT, CALL

PROCEEDING, SETUP, RELEASE COMPLETE, etc. shall be supported by T.38
endpoints conforming to Annex B. Note that there is no requirement to send ALERTING if
CONNECT, CALL PROCEEDING, or RELEASE COMPLETE is sent within 4 seconds of
the receipt of SETUP, as described in ITU-T Rec. H.323. Note also that gateways shall
send CALL PROCEEDING.
The Information elements of FACILITY as described in 7.4.1/H.225.0.
The Information elements of ALERTING as described in 7.3.1/H.225.0.
The Information elements of CALL PROCEEDING as described in 7.3.2/H.225.0.
The Information elements of CONNECT as described in 7.3.3/H.225.0
The information elements of PROGRESS as described in 7.3.7/H.225.0.
The Information elements of RELEASE COMPLETE as described in 7.3.9/H.225.0.
The Information elements of SETUP as described in 7.3.10/H.225.0.
The ASN.1 of H.225.0 as described in ITU-T Rec. H.225.0.

NOTE H.225.0 ASN.1 supports a large number of optional features. T.38 Annex B implementations may
implement the full range of optional H.225.0 features, including authentication features that are potentially
available. They may also implement H.450.x supplementary services. H.225.0 options are outside (i.e., prior)
to the OLC negotiations. If a real time fax endpoint (H.323 Annex D or T.38 Annex B) makes use of H.450.x
supplementary services, it must take into account that the remote endpoint may or may not support them. In
the worst case, the supplementary service is ignored by the receiver. Thus the requesting endpoint must
handle this condition, with, for example, a timeout mechanism.
30
ITU-T Rec. T.38 (09/2005)
B.3.6
Mapping of call progress signals
For call setup and call progress, the return signals can be simplified to the set shown in Table B.2.
These are all returned prior to or instead of a connect message.
The CONNECT message is returned when the gateway, by some means, determines that a
connection to the terminal G3FE has been established. If CED or FSK flags are detected, the
appropriate T.38 messages can be sent. This level of call setup and progress works in both H.323 as
well as non-H.323 environments.
Table B.2/T.38 Call Progress Mapping
Meaning
Mapping/Comments
Busy1. Subscriber busy tone as defined in ITU-T Rec. E.180/Q.35. Q.850 cause value 17.
Busy2. Sometimes referred to as "Distinctive Busy" on some
PABX models.
Q.850 cause value 17.
Congestion busy as defined in ITU-T Rec. E.180/Q.35.
Ring1. Ringing tone as defined in ITU-T Rec. E.180/Q.35. This is

an intermediate call progress indicator. It can be used to generate a
ringback signal to the originating G3FE as if it were an end-to-end
PSTN connection.
ALERTING
Ring2. Ringing tone similar to Ring1 where two short rings are
generated instead of one long ring. This is an intermediate call
progress result.
ALERTING
SIT Intercept. Special Information Tones are defined in ITU-T

Rec. E.180/Q.35. Intercept Tone is one combination of tones
frequency and duration.
SIT Vacant. Special Information Tones are defined in ITU-T

Rec. E.180/Q.35. Circuit Vacant Tone is one combination of tones
SIT Reorder. Special Information Tones are defined in ITU-T

Rec. E.180/Q.35. Reorder Tone is one combination of tones
SIT No Circuit. Special Information Tones are defined in ITU-T

Rec. E.180/Q.35. No Circuit Tone is one combination of tones
NOTE SIT tones are not

distinguished because they generally
indicate a problem with the number
to dial.
ITU-T Rec. T.38 (09/2005)
31
B.3.7
Usage of the maxBitRate in messages
T.38 is a data application per ITU-T Rec. H.245. An H.245 OLC requires that the maxBitRate field
be set. For gateway implementations, this field should indicate the maximum modem rate for the
TDM network that is supported by the gateway. The rate for IAF devices is TBD but shall not be set
to zero. Note that the units for maxBitRate is 100 bit/s.
B.3.8
DTMF transmission
For further study. Note that UserInputIndication as described in Annex D/H.323 is an H.245 signal.
H.245 is not required for T.38 Annex B devices.
B.3.9
Interoperability
Both H.323 direct call model and T.38 Annex B require a well-known port to initiate call signalling.
As described in Appendix IV/H.225.0, the H.323 well-known port for call signalling via TCP is
1720. T.38 Annex B endpoints shall use the H.323 well-known port. In order for a single
implementation (such as a gateway) to support multiple endpoints, dynamic ports must be used. A
facsimile gateway conforming to this annex shall support H.323 RAS. Also, note that when the
gatekeeper-routed call model is used, a well-known port is not needed.
An H.323 Annex D implementation becomes aware that it is communicating with a T.38 Annex B
implementation due to the following sequence of events:
The T.38 Annex B implementation does not supply an H.245 port in the connect or setup.
The H.323 Annex D transmits a FACILITY message with a FacilityReason of startH245

and provides its H.245 address in the h245Address element, as described in 8.2.3/H.323.
The T.38 Annex B implementation receiving a FACILITY message with a FacilityReason
of startH245 shall respond with a FACILITY message having a FacilityReason of
noH245. At this point, the H.323 Annex D implementation should cease all attempts to
open the H.245 channel.
If the Annex B implementation connects with an H.323 non-facsimile capable implementation, it
shall disconnect after noting the lack of facsimile OLCs in the fastStart elements in the responding
messaging such as ALERTING, CALL PROCEEDING, PROGRESS, or CONNECT. If it notes the
facsimile start procedure initiation in the responding message, it proceeds according to the fast
connect procedures, with the exception that as an Annex B implementation, it need not support any
H.323 video, voice, or data feature or H.245 messaging. Thus, the T.38 Annex B implementation
will disconnect from any H.323 (1996) implementation as it will not find the fast connect OLCs in
the messages from those implementations. The T.38 implementation may also disconnect on seeing
the H.323 version number 1.
T.38 Annex B implementations that do not support H.245 shall set h245Tunnelling to FALSE in
all H.225.0 messages.
32
ITU-T Rec. T.38 (09/2005)
Annex C
The optional forward error correction scheme for UDPTL
C.1
Overview of the optional forward error correction mechanism
The parity FEC scheme is symmetrical in that it is identical in both encode and decode modes, and
may be computed for an arbitrary number of arbitrarily sized IFP messages. A transmitting gateway
generates FEC messages by passing in a number of primary IFP packets; these FEC messages may
then be assembled into a packet in accordance with Figure 5.
Receiving gateways which detect the loss of a primary IFP packet that is covered by an FEC
message may be able to reconstruct it by passing in the remaining (received) primary IFP packets
and the FEC message itself to the parity encode/decode algorithm. Certain conditions apply in order
for a lost primary IFP packet to be recovered using the parity encoder/decoder; these shall be
discussed in the following clauses.
C.2
Parity encode/decode scheme operation and characteristics
The parity scheme accepts a number of arbitrarily sized IFP messages. It aligns them vertically and
zero pads the shorter length messages to produce a 2D matrix as shown in Figure C.1 a). A one-bit
piece-wise sum is then performed on a column by column basis (equivalent to exclusive OR logic
function) across the width of the matrix, each summation resulting in a binary digit. This process is
illustrated in Figure C.1 b). The output from the parity scheme is the row of resulting binary data.
The basic error recovery scheme works by assuming that 1 loss in n packets may occur. If the
(n + 1)th packet contains an FEC message generated from the primary IFP packets of the n
preceding packets, then provided no more than one of the first n packets is lost, any missing
IFP message can be reconstructed. The generation and reconstruction of primary IFP packets using
the parity scheme outlined above is described in the following subclauses.
ITU-T Rec. T.38 (09/2005)
33
b) Parity function application
a) Length normalization example

Input frame 1
Input frame 2
Input frame 3
NORMALIZE
Input frame 1
Input frame 2
Input frame 3
Input frame 1
Input frame 2
Input frame 3
Column-based
binary Sum
(carry discarded)
Resulting output
T.38_FC.1
Figure C.1/T.38 Illustration of Length normalization and Parity function operation
34
ITU-T Rec. T.38 (09/2005)
C.2.1
Generating and transmitting FEC messages
By utilizing a buffer similar to that shown in Figure C.2, it is possible to pass multiple prior primary
IFP packets into the parity FEC algorithm for processing. The FEC scheme returns with a frame of
encoded data that may then be assembled into a packet after the current primary IFP packet. The
transmitting gateway must decide in advance the number of prior IFP messages it shall use to
generate the FEC information. The n prior primary IFP packets are sent to the parity encoding
scheme which results in a single message of FEC data of length l octets where l is the largest
message length value encountered in the list of primary IFP packets plus 2 octets. Finally, the newly
generated FEC message is assembled as in Figure C.2 and inserted into the packet after the primary
IFP packet.
SEQUENCE NUMBER
( 45 )
Sequence
PRIMARY MESSAGE
FEC MESSAGE
IFP Message Store
45
IFP MESSAGE
44
IFP MESSAGE
Parity FEC
scheme
43
IFP MESSAGE
42
IFP MESSAGE
41
IFP MESSAGE
T.38_FC.2
Figure C.2/T.38 Generation and packetization of a single parity FEC frame

Multiple FEC messages may be sent in a single packet, each generated from fec_npackets (i.e., the
number of) prior primary IFP packets. Unlike the instance where only one FEC message is present,
when multiple FEC messages are transmitted in a single packet, the contributing primary IFP
packets for each FEC message are not consecutive, but are interleaved. This is illustrated in
Figure C.3 which shows an example providing protection against a burst of three consecutive lost
packets.
ITU-T Rec. T.38 (09/2005)
35
SEQUENCE NUMBER
( 45 )
Sequence
PRIMARY MESSAGE
FEC MESSAGE 1
FEC MESSAGE 2
Frame data
45
IFP MESSAGE
44
IFP MESSAGE
Parity FEC
scheme
43
IFP MESSAGE
42
IFP MESSAGE
41
IFP MESSAGE
40
IFP MESSAGE
39
IFP MESSAGE
38
IFP MESSAGE
37
IFP MESSAGE
36
IFP MESSAGE
Parity FEC
scheme
+
Parity FEC
scheme
+
T.38_FC.3
Figure C.3/T.38 Generating multiple FEC messages to protect against burst errors
36
ITU-T Rec. T.38 (09/2005)
FEC MESSAGE n
C.2.2
Receiving FEC messages and primary IFP packet reconstruction
A gateway in receipt of FEC messages in a packet must determine from the UDPTL packet:
the number of FEC messages present in the packet;
the sequence numbers of the primary IFP packets contained in each FEC message;
the sequence numbers of any packets which have been "lost" over the network.
In order to determine the sequence numbers of the primary IFP packets encoded in a given
FEC message, the receiving gateway must extract the number of primary IFP packets covered by
that frame. For a packet containing a single FEC message, the sequence numbers covered by that
message are simply those from [Seq 1] to [Seq (n + 1)] where n is the value in the fec_npackets
element and Seq is the value in the seq-number element. For a UDPTL packet containing m FEC
messages with sequence number Seq and a message control field setting of n, the sequence number
ranges for FEC message I (for 1 I m) are trivially extracted from the following equations:
StartSeq = Seq I
EndSeq = Seq I (n 1)m
Intermediate sequence numbers between these ranges are linearly spaced with gap m. Once the
sequence numbers of the primary IFP packets encoded in an FEC message have been determined,
the receiving gateway may check to determine whether any of the primary IFP packets listed has
failed to arrive. If one, and only one, of these primary IFP packets has failed to arrive, then the
FEC message and the remaining (delivered) primary IFP packets may be sent to the parity
algorithm to recover the missing sequence.
The number of FEC messages, m, is the number of octet strings contained in the fec-data element
(as encoded in the SEQUENCE OF construct).
Annex D
SIP/SDP call establishment procedures
D.1
Introduction
implementations and Internet-aware facsimile gateways conforming to ITU-T Rec. T.38 to establish
calls with other ITU-T T.38 implementations using the procedures defined in RFC 2543 (SIP) and
RFC 2327 (SDP).
D.2
D.2.1
Overview
D.2.1.1
Call setup
Call setup for Annex D/T.38 compliant implementations is based on SIP (Session Initiation
Protocol) defined in RFC 2543. As in Annex B, implementations may operate in two distinct
compatible environments:
1)
A facsimile-only over IP environment In this environment, no voice support is provided.

The procedures and requirements of D.2.2.3 shall apply to implementations operating in
this environment.
2)
A facsimile and voice over IP environment The procedures and requirements of this
annex shall apply to implementations operating in this environment.
ITU-T Rec. T.38 (09/2005)
37
D.2.1.2
Media channels
ITU-T T.38 facsimile packets are sent on a separate TCP/UDP port from SIP call signalling. A
minimal Annex D/T.38 implementation requires a TCP/UDP port (default is 5060) for call
signalling and either a UDP port or a TCP port for ITU-T T.38 facsimile information.
D.2.1.3
Usage of SDP
Endpoints conforming to this annex are required to support SDP, including the extensions described
below.
D.2.2
Basic call setup
D.2.2.1
Choosing call setup mechanism
Annex B indicates that H.323 FastCall Setup is the basic mechanism for establishing a T.38 call.
The method described in this annex is intended for use in conjunction with this mechanism in a
decomposed gateway model. In addition, this annex may also be used if the emitting gateway is
aware that the destination gateway supports the call establishment mechanism of this annex.
D.2.2.2
SIP call setup
According to RFC 2543 section 1, SIP supports a five-phase process for establishing and
terminating a call:
User location
determination of the end system to be used for communication
User capabilities
determination of the media and media parameters to be used
User availability
determination of the willingness of the called party to engage in communications
Call setup
"ringing", establishment of call parameters at both called and calling party
Call handling
including transfer and termination of calls
SIP can also be used in conjunction with other call setup and signalling protocols, for example in an
H.248 to H.323 interworking function.
SIP can invite users to sessions with and without resource reservation. SIP does not reserve
resources, but can convey to the invited system the information necessary to do this.
D.2.2.3
Facsimile-only connection
The emitting gateway sends a SIP INVITE request (with the appropriate options set) for a T.38
facsimile connection with the receiving SIP server. The receiving server will likely be the receiving
gateway; however, it may also proxy or redirect the SIP connection to the actual gateway through
SIP or other means. In any case, a response will be sent to the emitting gateway indicating
acceptance, redirection or failure of the request.
If accepted (or a redirected INVITE is accepted), the T.38 facsimile call proceeds.
Once the call is completed, the call may be disconnected with a SIP BYE command.
D.2.2.4
Voice and facsimile connection
A SIP INVITE is made to the called party requesting a voice connection per the requirements of
RFC 2543. A voice connection is then established.
Upon detection of facsimile by the receiving gateway, a SIP INVITE request is sent to the emitting
gateway (with the same Call-ID as the existing voice connection) for a T.38 facsimile connection.
Upon completion of the facsimile call establishment (noted in D.2.2.3), the T.38 facsimile call
proceeds with a T.38 V.21 flags indicator packet.
38
ITU-T Rec. T.38 (09/2005)
Note that during this switchover and the facsimile call, it may be useful to mute the voice channel.
The voice channel may be used again once the end of facsimile transmission is detected.
Alternately, some implementations may choose to replace the voice channel with a facsimile
channel.
Once the call is completed, the call may be disconnected with a SIP BYE command.
D.2.3
There are several capabilities that need to be negotiated to determine which options the gateways
support and use. These are described in Table B.1.
RFC 2327 Session Description Protocol (SDP) provides mechanisms for describing sessions for
SIP. There are several T.38 specific parameters that may be negotiated when establishing a T.38
media stream. For historic reasons, this is done differently for the UDPTL/TCP transport and the
RTP transport.
D.2.3.1
UDPTL and TCP negotiation
New attributes (section 6 of SDP) are required to support this Recommendation when using the
UDPTL and TCP transports. Note that the attributes defined below are specific to the use of T.38
with either the UDPTL or TCP transport and do not apply to the use of T.38 with RTP
(see D.2.3.2). Specifically, the following options are registered with IANA as valid att-field and
att-value values per the procedure noted in Appendix B of SDP (RFC 2327). Note that options
without values are boolean their presence indicates that they are valid for the session. These
capabilities are negotiated using the following ABNF elements defined for use with this
Recommendation:
Version
Att-field=T38FaxVersion
Att-value = 1*(DIGIT)
;Version 0, the default, refers to T.38 (1998)
Maximum Bit Rate
Att-field=T38MaxBitRate
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
;optional
Maximum Datagram Size
Att-field=T38FaxMaxDatagram
;optional
Error Correction
Att-field=T38FaxUdpEC
Att-value = t38UDPFEC | t38UDPRedundancy
T38VendorInfo
Att-field=T38VendorInfo
Att-value = t35country-code SP t35extention SP manufacturer-code
t35country-code = 1*(DIGIT)
t35extension = 1*(DIGIT)
manufacturer-code = 1*(DIGIT)
ITU-T Rec. T.38 (09/2005)
39
;optional
;0 to 255 for t35country-code and t35extension
;t35country-code is defined in T.35 Annex A.
;t35extension is defined in T.35 Annex B
;The value of "manufacturer-code" is assigned nationally
;and identifies an equipment manufacturer.
;Example a=T38VendorInfo:0 0 37
D.2.3.2
RTP negotiation
The MIME type registration for "audio/T38" defines several optional parameters that may be used
with T.38 over RTP. Those parameters are supplied in a semi-colon separated list of "parameter" or
"parameter=value" pairs using the "a=fmtp" parameter defined in SDP; the "parameter" form is
used for boolean values, where presence equals "true" and absence "false". The parameter
definitions are repeated here:
Version
Name=T38FaxVersion
Value= 1*(DIGIT)
;Version 0, the default, refers to T.38 (1998)
Maximum Bit Rate
Name=T38MaxBitRate
Value= 1*(DIGIT)
Fill Bit Removal
Name=T38FaxFillBitRemoval
;Boolean
MMR Transcoding
Name=T38FaxTranscodingMMR
;Boolean
JBIG Transcoding
Name=T38FaxTranscodingJBIG
;Boolean
Data Rate Management Method
Name=T38FaxRateManagement
Value = "localTCF" | "transferredTCF"
Maximum Buffer Size
Name=T38FaxMaxBuffer
Value = 1*(DIGIT)
;optional
Maximum Datagram Size
Name=T38FaxMaxDatagram
Value = 1*(DIGIT)
;optional
T38VendorInfo
Att-field=T38VendorInfo
Att-value = t35country-code SP t35extention SP manufacturer-code
t35country-code = 1*(DIGIT)
t35extension = 1*(DIGIT)
manufacturer-code = 1*(DIGIT)
;optional
;0 to 255 for t35country-code and t35extension
;t35country-code is defined in T.35 Annex A.
;t35extension is defined in T.35 Annex B
;The value of "manufacturer-code" is assigned nationally
;and identifies an equipment manufacturer.
;Example a=T38VendorInfo:0 0 37
NOTE There is no Error Correction defined for this Recommendation over RTP Redundancy and FEC can
be declared for RTP payloads according to the SDP usage defined in RFCs 2198 and 2733.
40
ITU-T Rec. T.38 (09/2005)
D.2.3.3
Declaration of T.38 in SDP
The image/t38 MIME content type in SDP indicates this Recommendation.

This choice is consistent with image/tiff used in ITU-T Rec. T.37 and image/g3fax used for ITU-T
Rec. X.420.
D.2.3.4
Use of either TCP or UDP
Two logical channels (sender to receiver channel and receiver to sender channel) shall be opened
for the transfer of T.38 packets. T.38 packets can be transferred using either TCP or UDP. In
general, the usage of TCP is more effective when the bandwidth for facsimile communication is
limited, or for IAF to IAF transfers since TCP provides flow control. On the other hand, the usage
of UDP may be more effective when the bandwidth for facsimile communication is sufficient.
Note that during the SIP call setup, the calling party suggests the transport (TCP or UDP) by listing
its preferred first in the SDP of a SIP INVITE. The receiver should open the TCP/UDP port based
on the preference of the sender, but the receiver decides.
In support of T.38 choice of UDP or TCP transport, SDP extensions:
indicate UDPTL (facsimile user datagram protocol transport layer) as a valid transport
value (third field);
indicate TCP (transmission control protocol) as a valid transport value (third field);
indicate RTP/AVP (Real Time Protocol/Audio-Video Profile) as a valid transport value

(third field);
indicate RTP/SAVP (Real Time Protocol/Secure Audio-Video Profile) as a valid transport

value (third field);
indicate other RTP profiles (e.g., AVPF and SAVPF) as a valid transport value (third field);
include t38 as a valid format type value (fourth field). This value is used when the transport
value is UDPTL or TCP;
include an RTP payload type as a valid format type value (fourth field). This value is used
when the transport value is RTP/AVP or RTP/SAVP. This payload type is mapped via an
'rtpmap' attribute to the MIME type "audio/t38".
When the transport layer is RTP, standard RTP mechanisms for packet redundancy (RFC 2198) and
FEC protection (RFC 2733) may be used. The declaration of these mechanisms in SDP is described
in RFC 2198 and RFC 2733.
NOTE As t38 is not an RTP-defined value, it has to be a MIME sub-type of the media type. As a result,
this is awaiting the publication of an IETF RFC to define the registration of audio/t38 with IANA as a valid
MIME content-type per the procedure noted in Appendix B of SDP (RFC 2327).
D.2.4
D.2.4.1
Examples of call setup

Facsimile-only invite
The default case requires support for both TCP and UDP. A UDPTL or RTP encapsulation method
may be used in conjunction with UDP transport. In this case, two 'm=' lines are listed with the
preferred one first in the INVITE. The rejected media connection will be indicated with a port
number set to zero in the response.
For a two-party facsimile-only call between T.38 gateways, when UDPTL encapsulation is used in
conjunction with the UDP transport protocol:
C->S: INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:[email protected]>
To: T. Watson <sip:[email protected]>
ITU-T Rec. T.38 (09/2005)
41
Call-ID: [email protected]
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
[email protected]
t=2873397496 0
c=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
S->C: SIP/2.0 200 OK
Cseq: 1 INVITE
Contact: sip:[email protected]
Content-Length:
v=0
o=faxwatson 4858949 4858949 IN IP4 192.1.2.3
c=IN IP4 boston.bell-tel.com
m=image 0 tcp t38
For a two-party facsimile-only call between T.38 gateways, when RTP encapsulation is used in
Cseq: 1 INVITE
Content-Length:
v=0
o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
[email protected]
t=2873397496 0
c=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
S->C: SIP/2.0 200 OK
Cseq: 1 INVITE
42
ITU-T Rec. T.38 (09/2005)
Content-Length:
v=0
o=faxwatson 4858949 4858949 IN IP4 192.1.2.3
a=rtpmap:100 t38/8000
a=rtpmap:101 parityfec/8000
a=fmtp:101 5004 IN IP4 192.1.2.3
m=image 0 tcp t38
This example shows forward error correction (FEC) as defined for RTP media streams in
RFC 2733. In this case, a separate UDP port is allocated to the FEC stream. For the case when
RFC 2198 encapsulation is used in conjunction with FEC, the SDP descriptors in this example will
need to be modified per RFC 2733.
For secure RTP, the third field (transport protocol) on the 'm=' lines would have been RTP/SAVP
rather than RTP/AVP.
For a two-party voice and fax call between gateways, when RTP encapsulation is used in
Cseq: 1 INVITE
Content-Length:
v=0
o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
[email protected]
t=2873397496 0
c=IN IP4 128.59.19.68
m=audio 49170 RTP/AVP 121 0 100
a=rtpmap:100 t38/8000
a=rtpmap:121 red/8000
a=fmtp:121 100/100
S->C: SIP/2.0 200 OK
Cseq: 1 INVITE
Content-Length:
v=0
o=faxwatson 4858949 4858949 IN IP4 192.1.2.3
m=audio 5002 RTP/AVP 121 0 100
a=rtpmap:100 t38/8000
ITU-T Rec. T.38 (09/2005)
43
a=rtpmap:121 red/8000
a=fmtp:121 100/100
m=image 0 tcp t38
This example shows redundant encoding for RTP fax as defined in RFC 2198. For G.711 encoding
of voice, redundancy is not used.
D.2.5
Minimum call setup messages
The implementation of this annex shall support the minimum requirements for a SIP client and
server as defined in RFC 2543 sections A.1 and A.2:
All clients MUST be able to generate the INVITE and ACK requests. Clients MUST generate and
parse the Call-ID, Content-Length, Content-Type, CSeq, From and To headers. Clients MUST also
parse the Require header. A minimal implementation MUST understand SDP (RFC 2327). It
MUST be able to recognize the status code classes 1 through 6 and act accordingly.
A minimally compliant server implementation MUST understand the INVITE, ACK, OPTIONS
and BYE requests. A proxy server MUST also understand CANCEL. It MUST parse and generate,
as appropriate, the Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-Forwards,
Require, To and Via headers. It MUST echo the CSeq and Timestamp headers in the response. It
SHOULD include the Server header in its responses.
D.2.6
For call setup and call progress, the return signals can be simplified to the following set. These are
all returned prior to or instead of a 200 OK response to the INVITE request.
Table D.1/T.38 Call progress mapping
Meaning
SIP response mapping
Busy1. Subscriber busy tone as defined in ITU-T Rec. E.180/Q.35.
486 Busy here
Busy2. Sometimes referred to as Distinctive Busy on some PABX models.
486 Busy here
Congestion busy as defined in ITU-T Rec. E.180/Q.35.
600 Busy everywhere
Ring1. Ringing tone as defined in ITU-T Rec. E.180/Q.35. This is an

intermediate call progress indicator. It can be used to generate a ringback signal
to the originating G3FE as if it there were an end-to-end PSTN connection.
180 Ringing
Ring2. Ringing tone similar to Ring1 where two short rings are generated
instead of one long ring. This is an intermediate call progress result.
180 Ringing
SIT Intercept. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. 503 Service Unavailable
Intercept Tone is one combination of tones frequency and duration.
SIT vacant. Special Information Tones are defined in ITU-T Rec. E.180/Q.35.
Circuit Vacant Tone is one combination of tones frequency and duration.
503 Service Unavailable
SIT Reorder. Special Information Tones are defined in ITU-T Rec. E.180/Q.35.
Reorder Tone is one combination of tones frequency and duration.
SIT No Circuit. Special Information Tones are defined in ITU-T Rec.

E.180/Q.35. No Circuit Tone is one combination of tones frequency and
duration.
NOTE SIT tones are not distinguished because it generally indicates a problem with the number dialled.
The 200 OK message in response to an INVITE request is returned when the gateway, by some
means, determines that a connection to the terminal G3FE has been established. If CED or FSK
flags are detected, the appropriate T.38 messages can be sent.
44
ITU-T Rec. T.38 (09/2005)
D.2.7
Usage of the T38maxBitRate in messages
T38maxBitRate refers to the maximum fax data rate that is supported by an endpoint. When TCP
is used for T.38 facsimile transmission, T38maxBitRate does not apply. When UDP is used for
T.38 facsimile transmission, T38maxBitRate should be specified to aid in bandwidth allocation.
D.2.8
DTMF transmission
SIP can transfer collected DTMF dialling digits as a SIP URL as defined in RFC 2543 section 2:
sip:[email protected];user=phone
DTMF transmission during an established voice and facsimile connection may be completed using
the RTP tone payload described in RFC 2833.
D.2.9
Interoperability
Both SIP and Annex B require a well-known port to initiate call signalling. As described in SIP, its
well-known port is 5060. Endpoints in this annex shall use the SIP well-known port by default.
Annex E
H.248.1 call establishment procedures
E.1
Introduction
implementations and Internet-aware facsimile gateways conforming to ITU-T Rec. T.38 to establish
calls with other T.38 implementations using ITU-T Rec. H.248.1 and either one of the following
procedures:
a)
A media gateway controlled paradigm via the procedures defined by ITU-T Rec. H.248.1.
This paradigm shall be referred to as the T.38 MGC Transitioning method. Using this
method a call is setup using the normal procedures as described in ITU-T Rec. H.248
(see [E1]), but if T.38 has to be supported, the packages as described in ITU-T
Rec. H.248.2 [E2] are taken into account, so the detection and generation of fax tones are
enabled. Upon detection of fax signals, the MGC is notified by the emitting MG about the
event, and gives the command to the receiving part via its controlling MGC to generate the
signals. Answering signals are handled in the same way. When all signals needed are
communicated between both fax terminals via the MGs and MGCs, the MGCs will modify
the contexts to put them into fax-mode. This scenario can take up to 20 Megaco commands.
b)
A paradigm that allows for transitioning between a VoIP call and a FoIP call (using T.38)
by media gateways (MG) that support T.38 without the real-time intervention of a media
gateway controller (MGC). Note that throughout this annex the term "media gateway
controller" is used as to indicate a MGC as defined in ITU-T Rec. H.248 as well as a
gatekeeper as defined in ITU-T Rec. H.323. The only involvement of the MGC will be
during initial connection capabilities negotiation between the media gateways using SDP
descriptors. At this stage, both the MGs and the MGCs are unaware of the type of
connection (i.e., voice, fax, modem, etc.). The mechanism in this alternative is an optional
procedure that complements the existing mechanisms in Annex B (H.323 procedures),
Annex D (SIP-SDP procedures), Annex E (H.248.1 procedures), and Annex D/H.323. This
paradigm shall be referred to as the T.38 Autonomous Transitioning method.
ITU-T Rec. T.38 (09/2005)
45
E.2
E.2.1
Overview
E.2.1.1
Gateway architecture
The method described in this annex is intended for use in conjunction with other methods in a
decomposed gateway model as shown in Figure E.1. In this model, the media gateway controller
(MGC) has knowledge of all the endpoints within a domain and has control over connections being
created and terminated at its media gateways (MG).
SS7
SG
SG
MGC
MGC
MG
PSTN
IP
network
MG
SS7
PSTN
T.38_FE.1
Figure E.1/T.38 Typical decomposed model

The mechanism in this annex complements the mechanism of Annex D/H.323 (which describes a
simple case without a decomposed gateway). In the situation where more than one MGC is involved
in a call, the mechanism in this annex (other methods are for further study) is used to signal
between them.
E.2.1.2
Call setup
Call setup for implementations compliant to this annex is based on ITU-T Rec. H.248.1. As in the
basic Annex B, implementations may operate in two distinct compatible environments:
1)
A facsimile-only over IP environment In this environment, no voice support is provided.

The procedures and requirements of D.2.2.1 shall apply to implementations operating in
this environment.
2)
A facsimile and voice over IP environment The procedures and requirements of E.2.2.2
shall apply to implementations operating in this environment.
E.2.1.3
Media channels
T.38 facsimile packets are sent on a separate TCP/UDP port from H.248 message transport. A
minimal implementation of this annex requires a TCP port for call signalling and either a UDP port
or a TCP port for T.38 facsimile information.
E.2.2
Basic call setup
According to 8.2.1/H.248.1:
the connection model for the protocol describes the logical entities, or objects, within the
media gateway that can be controlled by the media gateway controller. The main
abstractions used in the connection model are Terminations and Contexts;
46
ITU-T Rec. T.38 (09/2005)
a termination is an object that sources and/or sinks media streams;

a context represents a collection of terminations in a single conference.
Terminations recognize events that invoke a response by the MGC to create another event
(e.g., recognizing off-hook invokes play dial tone). This interaction proceeds throughout a typical
call setup process initiated at the MG (e.g., H.323 Fast Connect Setup).
It shall be possible to establish a facsimile over IP call using either of the following two
mechanisms:
1)
T.38 MGC Transitioning method: A mechanism in which the MGC decides when and
whether it is possible to transition from VoIP to T.38 FoIP based in tone events sent to it
(via H.248 and the packages described in Annex F/H.248) by the MGs. For H.248 it is
described in E.2.2.1. In an H.323 environment, the replacement of a voice channel with a
T.38 channel is done according to the procedures of D.5/H.323.
2)
T.38 Autonomous Transitioning method: A mechanism for transitioning between a
VoIP call and a FoIP call (using T.38) by MGs without the intervention of a media gateway
controller (MGC), as described in E.2.2.2, or without the need to request modification of a
call as described in Annex D (SIP/SDP). Note that the packages described in H.248.2 are
not needed when supporting this method. In an H.323 environment, the procedures of
D.3/H.323 (fastStart) or D.4/H.323 (non-fastStart) are used to setup two parallel channels.
A MG shall indicate support of the T.38 Autonomous Transitioning method by including in the
initial capabilities exchange or setup message support for both audio and image/t38 media streams,
using mechanisms described below.
Media gateways that use SDP (see [E3]) to exchange capabilities (such as, but not limited to, SIP or
H.248 MGs), shall indicate support for the T.38 Autonomous Transitioning method by including in
the first SDP to be exchanged at least two media descriptors (i.e., "m=" lines), one of type audio
and one media descriptor of type image/t38, in which the port number is not set to zero (this is for
compatibility with SIP terminals, for which setting the port to zero means non-support of that media
type). This is illustrated in the following examples, which show only the SDP portion and in which
only the media line is important. Also, note that when using H.248, the media descriptors must be
separated by a version descriptor (aka v-line), as shown in Appendix III:
SDP examples illustrating support of the T.38 Autonomous Transitioning method:

Example 1:
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0
( additional attributes may be included)
a=T38FaxVersion:1
a=T38FaxRateManagement:transferredTCFlocalTCF
a=T38FaxMaxBufferSize:2000
a=T38MaxDatagram:512
a=T38FaxMaxRate:14400
Example 2:
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0 8 13
a=ptime:20
ITU-T Rec. T.38 (09/2005)
47

a=ptime10
a=rtpmap:129 telephone-event/8000
a=fmtp:129 0-15
SDP examples illustrating non-support of the T.38 Autonomous Transitioning method:

Example 3:
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0 8 13 140
a=ptime:20
a=fmtp:140 0-15
m=image 0 udptl t38
a=T38MaxDatagram:512
Example 4:
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0 8 13 140
a=ptime:20
a=fmtp:140 0-15
Example 5:
v=0
c=IN IP4 124.124.124.222
a=T38FaxVersion:0
Note that examples 3 and 4 shall be construed as indicating that, at the instance of time the SDP
was exchanged, the T.38 Autonomous Transitioning method shall not be used, as well as indicating
that the media gateway that sent the SDP does not support (at that instance of time) ITU-T
Rec. T.38. In such a case the call will proceed as mandated by the call establishment control
protocol being used (which may be, but not limited to, H.323, SIP, or H.248); if it is H.248, then the
procedures in E.2.2.1 shall be used. Also, note that, although in examples 3 and 4 the SDP does not
indicate support of T.38, this does not mean that either the MG or the MGC cannot request, at a
later stage of the call, to transition to T.38 by sending a new SDP (for example within an H.248
Modify command or a SIP INVITE command) containing a media attribute of type image/t38
(as described either in Annex D or in E.2.2.1).
Example 5 will cause both MG to immediately transition to FoIP (using T.38); however any future
transitioning to any other mode of operation (e.g., voice, voiceband data, etc.) shall be controlled by
the MGC.
48
ITU-T Rec. T.38 (09/2005)
An H.323-capable media gateway shall indicate support of the T.38 Autonomous Transitioning
method during the H.245 capabilities exchange by opening two parallel channels in each direction,
one for voice, the other for T.38, as described in D.3/H.323 for fastStart or in D.4/H.323 for
non-fastStart. Two MGs that mutually support the T.38 Autonomous Transitioning method shall
autonomously, on detection of the appropriate facsimile signals or on reception of a T.38 UDP
(or TCP) packet at its T.38 UDP (or TCP) port, mute the audio channel and transition to the
T.38 channel.
The media gateway controller shall decide at the start of the call which method to use (i.e., whether
to control the transitioning from audio to facsimile or to let the MGs autonomously transition),
based on data derived from capability messages exchanged as described above between the media
gateways.
Hence, the MGC shall not control the transition between VoIP and FoIP only if both MGs that are
establishing the connection have mutually indicated that they support the T.38 Autonomous
Transitioning method (by the means described above). Note that in H.323 fastStart, there is no
explicit negotiation of which method to use, autonomous or MGC-based: the fastStart element will
indicate that the call is either a pure voice call (which may turn out eventually to be switched to a
T.38 call using D.5/H.323), or it may consist of a separate channel for voice and a separate channel
for T.38 as per D.3/H.323. The latter shall be used by an MGC (i.e., Gatekeeper) as indication that
the MGs shall use the T.38 Autonomous Transitioning method. When non-fastStart procedures are
used, the terminal capability negotiation will indicate if T.38 and voice can be used simultaneously
or not (the terminal capability negotiation procedures may also be used after a fastStart call setup,
and will be instrumental in indicating that the autonomous or MGC switchover procedures are
supported).
Absence of an MG indicating support of the T.38 Autonomous Transitioning method must be
construed, by both the MGs and the MGCs, as an indication to use the existing call establishment
procedures which depend on the call control protocol being used (SIP, H.323 or H.248), which can
be one of the following:
T.38 MGC Transitioning method (for H.248) described in E.2.2.1;
the method described in Annex B (H.323 procedures);
the procedure described in Annex D (SIP/SDP procedures).

The fact that a MGC knows that the T.38 Autonomous Transitioning method shall be used for a
particular call does not preclude the possibility of the MGC to request to receive notifications from
the MGs indicating detection of facsimile tones or transition to FoIP (using T.38). The possible
usage of such notifications is out of the scope of this Recommendation.
E.2.2.1
T.38 media gateway controller (MGC) method
Note that two cases exist for the use of this mechanism:
1)
If the call agent (MGC & Gatekeeper) controls both MGs, then H.248 and the packages
described in Annex F/H.248 are used to modify the existing connection between the two
MGs.
2)
If different call agents are involved (e.g., when two different service providers are involved
in completing a call), then MGC-MGC communication is required (i.e., using the
mechanism of Annex D). On confirmation of a connection, the on-ramp call agent instructs
its media gateway (via H.248) to initiate a T.38 session with the off-ramp MG.
This method of transitioning from VoIP to FoIP shall be the default method unless the MGs have
indicated mutual support of the T.38 Autonomous Transitioning method using the mechanisms
described in this clause.
ITU-T Rec. T.38 (09/2005)
49
E.2.2.1.1 Facsimile-only connection

Digits are collected by the media gateway (MG) and sent to the calling agent to invite the called
party on a facsimile call.
Once connected, the call proceeds as in Annex B.
E.2.2.1.2 Voice and facsimile connection
party to a voice connection as defined in ITU-T Rec. H.248.1. A voice connection is set up.
Upon detection of CNG by the emitting media gateway (MG), the calling agent is informed (via
H.248.1) of this event and instructs the destination MG to play CNG. If the destination MG then
notifies the MGC of a CED (or V.21 flags) event and is capable of T.38, the MGC requests that
each MG open a T.38 connection. Details for discrimination of the call as facsimile is described in
clause 8/H.248.2. The MGC may also request that a new MG handle the facsimile connection. The
T.38 protocol proceeds with a T.38 V.21 flags indicator packet.
Note that if T.38 is not supported by one of the MGs, the MGC may decide to attempt the facsimile
call over G.711 (using G.711 in this case is beyond the scope of this annex). Full flexibility of
switching between MGs (e.g., voice+facsimile, voice-only or facsimile-only) and deciding on
options will not be possible if the MGC is not notified of the facsimile events (and the MG alone
detects facsimile and switches blindly to T.38). Upon completion of the facsimile call
(T.38 completion) by the off-ramp media gateway (MG), the calling agent is informed (via H.248.1)
of this event and may request that the connection be reverted to voice.
E.2.2.2
T.38 Autonomous Transitioning method
To use this method the MGs must mutually agree to do so at the start of the call. Refer to E.2.2
(Basic call setup) for the mechanisms to be used by an MG to indicate to the MGC and the remote
MG that it supports the T.38 Autonomous Transitioning method.
The MG will negotiate at the start of the call all possible media descriptors; thus, an audio
descriptor and an image/t38 descriptor would both be included. Therefore, T.38 options of a
subsequent fax phase to the call are negotiated at the same time as the audio parameters.
Note that for the case of using H.248 call setup procedures, the fact that both MGs may have
indicated in the audit that they support T.38 as well as audio (and responded with two media
descriptor lines) shall not be used as an indication of support of the T.38 Autonomous Transitioning
method.
It shall be in the creation of a context where support of the T.38 Autonomous Transitioning method
is indicated. Hence, the H.248 MGC will need to include both an audio and an image descriptor in
the Local descriptor portion of the Add Ephemeral command (refer to III.2.2 3) for an example,
with the port numbers set to $, and with the ReserveGroup property, of the LocalControl descriptor,
set to True, thus effectively asking the MGs to reserve resources for both the image and audio
descriptors. However, if for some reason, (e.g., lack of resources) both audio and image resources
cannot be reserved at the time of the start of the call, the image media descriptor, within the
response SDP, shall either have its port set to zero (recommended for compatibility with
SIP capable terminals) or be omitted altogether, thus indicating non-support of the T.38
Autonomous Transitioning method as well as initializing the call as voice, and hence by default
both gateways and the media gateway controller shall use the MGC method.
E.2.2.2.1 Facsimile-only connection
party on a facsimile call.
Once connected, the call proceeds as in Annex B.
50
ITU-T Rec. T.38 (09/2005)
E.2.2.2.2 Voice and facsimile connection

party to a voice connection as defined in ITU-T Rec. H.248. Because the MGC and the MGs have
no indication that a call is going to be voice or facsimile, the MGs shall set up a voice connection
and no T.38 packets are sent. The MGs remain in this mode until they detect such criteria (refer to
E.2.2.2.2.1) that cause them to determine that a fax call is starting. At this point the MGs shall start
the image/t38 connection and mute the audio connection. The MGs will remain in fax mode until
they detect such criteria that cause them to determine that the fax transmission is complete, at which
point they will mute the image/t38 connection and re-enable the audio/RTP connection. This
process may continue indefinitely until the call is terminated.
E.2.2.2.2.1
MG-to-MG signalling of facsimile tones/signals
When using voice high-compression encoding techniques such as, but not limited to, G.729, some
fax tonal signals may not get correctly transported across the packet network. Hence, it is
recommended that a gateway detect these signals and transport them across the packet network via
other mechanisms. The following methods exist to pass information about the detected signals and
tones to the peer fax terminal over the packet network:
Method 1
Tone pass through: The tone is sent in-band using a lower compression algorithm such as the one
used for Voiceband Data (VBD), e.g., encoded using G.711 or G.726-32k over RTP/UDP/IP.
Upon detection of a tone, the MG switches autonomously to VBD, in which mode an appropriate
codec is used (e.g., G.711), and passes the tone in the voice RTP payload. The receiving gateway
has to detect the tone from the packet network, and has to switch to VBD, to pass the signal to the
fax terminal.
This method should only be used if both media gateways have indicated support of a common lower
compression codec or support of the VBD state. The mechanisms used for indicating such support
may be via SDP exchange or other mechanisms, which are outside the scope of this
Recommendation.
Method 2
Tone relay (RFC 2833 RTP Payload Format for Telephony Tones); see [E4].
All information needed to regenerate the tone is passed in the RTP payload. The BIWF in the peer
MG has to generate the tones towards the fax terminal.
Before using this method, it is recommended that media gateways should mutually indicate support
of this method via SDP (see [E3]) exchange or other call capability exchange mechanisms, which
are beyond the scope of this Recommendation.
A gateway that does not support this RTP payload type must be capable of discarding these packets
without affecting its operation.
Method 3
Tone detection indication (RFC 2833 RTP Payload Format for Named Telephone Events):
Event messages (NTE) are used to pass events as described in RFC 2833 [E4], chapter 3.11 (Data
modems and Fax Events). The peer MG may use this message to switch to VBD or T.38, dependent
of the current state, and shall generate the tones with the characteristics as described in ITU-T
Rec. T.30 [E5].
ITU-T Rec. T.38 (09/2005)
51
When using this method, the following events are to be sent, as defined in Table 3 of RFC 2833
[E4]:
Event
Encoding (decimal)
ANS (=CED)
32
CNG
36
V.21 channel 2,"0" bit
39 (see Note)
V.21 channel 2,"1" bit:
40 (see Note)
NOTE In the existing RFC 2833, for V.21 preamble flags there exists no RFC 2833 event. Only V.21
channel 2, bit "0" and bit "1" events exist, which are passed to the transmitting MG. To be able to
discriminate between a fax and a data call, the receiving MG must be able to decode the preamble flag, out
of the RFC 2833 NTE messages. However, there is currently an IETF draft, RFC 2833bis [E6] (in the
IETF AVT working group), in which there exists an event for the V.21 preamble flag that has the (decimal)
encoding number 52. It is recommended that when RFC 2833bis is approved, an implementation should use
this V.21 preamble flags event instead of the V.21 channel 2 bit "0" and bit "1" events.
The number of flags to be detected before switch-over is a parameter which must be chosen in such
a way that the receiving MG sends enough RFC 2833 messages towards the transmitting MG,
before it switches to T.38.
After the switch-over to T.38, the V.21 flags are passed over UDPTL.
Before using this method, it is recommended that media gateways should mutually indicate support
of the RTP payload types indicated above via SDP (see [E3]) exchange or other call capability
exchange mechanisms, which are beyond the scope of this Recommendation.
A gateway that does not support these RTP payload types must be capable of discarding these
packets without affecting its operation.
Method 4
After switch-over to T.38, if the tonal signals still exist, then the media gateway shall send
T.38 packets of Type t30-indicator, to signal the presence of facsimile signals.
E.2.2.2.2.2
VoIP to FoIP transition criteria
Upon detection of CNG by the emitting media gateway (MG), it is possible to determine with
sufficient confidence that it is a facsimile call because CNG is only sent by a G3FE. Hence, if a
T.38 capability has been mutually successfully negotiated between the MGs, the MG will switch to
T.38 and, in accordance with the T.38 protocol, transmit to the remote MG the T.38 CNG indicator
packet. The remote MG will switch to T.38, on receipt at its T.38 UDP (or TCP) port, of the T.38
CNG indicator packet.
When in audio/RTP mode, receipt of any T.38 packet at a designated T.38 UDP (or TCP) port,
should be a criterion for switching to image/t38 mode (see E.2.2.2.2.1). The implementation of how
this is done is out of the scope of this Recommendation. However, one recommended method is that
of which, receipt at its local T.38 UDP (or TCP) port of a valid UDP (or TCP) packet can be
assumed to be a T.38 packet and hence cause autonomous transition to T.38, if the source
IP address of that packet corresponds with that of the remote MG, with which the T.38 Autonomous
Transitioning method (as well as the T.38 capabilities) was mutually successfully negotiated,
because only T.38 UDPTL packets must be sent to negotiated image/t38 UDP port number. The
same applies for T.38 TCP packets. The T.38 UDP (or TCP) port should only be activated if the
T.38 Autonomous Transitioning method (and a mutual set of T.38 capabilities) is supported by the
MGs establishing the call. (This would avoid falsely transitioning autonomously to T.38 on receipt
of any valid UDP packet if T.38 Autonomous Transitioning method is not mutually supported
between the MGs.)
52
ITU-T Rec. T.38 (09/2005)
MGs that are operating with the autonomous method must not rely solely on detection of the
CNG tone, as this tone is only mandatory for automatic G3FEs and manual G3FEs conforming to
the post-1993 version of ITU-T Rec. T.30.
If CNG is not present, then the MGs shall transition to T.38 on detection of the V.21 preamble,
which is sent by all G3FEs except V.34 G3FEs. V.34 facsimiles use V.8 signals that will have to be
detected by the MG in order to support the procedures in clause 10. The T.38 protocol proceeds
with a T.38 V.21 flags indicator packet. The emitting MG, on receipt of the T.38 V.21 flags
indicator packet, shall transition to T.38 if not already in T.38 mode.
Optionally, if mutually supported by the media gateways involved in the call (via SDP exchange or
other means), a media gateway may choose to transmit the V.21 preamble to the peer gateway over
the packet network using RFC 2833 events (i.e., the method 3 stated in E.2.2.2.2.1). RFC 2833 has
defined four dedicated events (37-40) for relaying FSK-encoded binary information per channel.
When using this method, RFC 2833 RTP packets shall be generated by grouping events as well as
by using the redundancy mechanisms as defined in RFC 2833/RFC 2198.
Detection of the call function set to facsimile within the V.8 signals CI/CM/JM shall also indicate
transition to image/t38 mode and the procedures in clause 10. See also Annex F.
Media gateways that support the T.38 Autonomous Transitioning method should not determine to
switch to facsimile based on detection of a CED tone. The CED tone is the same tone as the
ANS tone (defined in ITU-T Rec. V.25). The latter tone is sent by some non-fax modems.
Note that if T.38 is not supported by one of the MGs, the MGs may decide to attempt the facsimile
call over G.711 only if G.711 was received in audio media descriptor (using G.711 in this case is
beyond the scope of this annex).
E.2.2.2.2.3
FoIP to VoIP transition criteria
The MGs shall autonomously transition from fax (image/t38 connection) to a voice
(audio/RTP connection) when the MG detect one of the following:
a)
Detection of the T.30 DCN message: Following detection of the T.30 DCN message, the
MG will transmit the corresponding T.38 packet and subsequently transition to voice.
Following receipt of T.38/T.30 CDN packet, the MG will play out the T.30 DCN and
subsequently transition to voice.
b)
Detection of bidirectional silence: It is recommended that an MG transition back to voice
mode after detecting more than 7 s of bidirectional silence (this value was chosen in order
to allow for the T.30 T2 timer).
c)
Receipt from the MGC of an appropriate command modifying the call to audio. A H.248
Modify, a SIP INVITE command in which only the audio descriptor is present or the
appropriate messages as per D.5/H.323 can do this.
E.2.3
Event and signal indication
There are several events and signals that need to be transferred from the MG to the MGC and vice
versa during the setup of a fax call. These events are defined in H.248 packages. The base packages
are in Annex E/H.248.1. Additional signals for fax are defined in ITU-T Rec. H.248.2.
E.2.4
There are several options that need to be negotiated to determine which options the gateways
support and use. These are described in Table B.1 and are defined as SDP extensions in D.2.3. They
are also defined as binary types in the IP Fax package of ITU-T Rec. H.248.2.
ITU-T Rec. T.38 (09/2005)
53
A T.38 Annex E implementation may use the SDP extensions to describe the fax media
terminations in text mode of the protocol. An H.248.1 implementation shall use the IP fax package
as the preferred method to describe the fax media termination. These media descriptors indicate the
capabilities of, or requested of a media gateway (e.g., TCP, UDPTL or RTP transport).
In addition, as well as being able to identify that a call is using T.38 transport for facsimile, ITU-T
Rec. H.248.1 may also indicate other transports.
E.2.5
Examples of the T.38 MGC procedure are described in III.2.1 and III.2.2.
Examples of the T.38 Autonomous Transitioning method are described in III.2.3 and III.2.4.
E.2.6
Minimum call setup messages
The implementation of this annex shall support the minimum requirements for ITU-T Rec. H.248.1
as noted in 8.2/H.248.1.
E.2.7
For call setup and call progress, the return signals are identical to those in Annex B (for H.323 Fast
Connect setup) and Annex D (for SIP).
E.2.8
DTMF transmission
ITU-T Rec. H.248 supports collection of DTMF digits to make a call.

DTMF tones transmission during an established voice and facsimile call is handled within the
DTMF packages of E.5 and E.6/H.248.1.
E.2.9
Interoperability
Both ITU-T Rec. H.248.1 and Annex B require a well-known port to initiate call signalling.
T.38 Annex E endpoints shall use the H.248.1 well-known port of 2944 for the text protocol and
2945 for the binary protocol.
References
[E1]
ITU-T Recommendation H.248 (2005), Gateway control protocol.
[E2]
ITU-T Recommendation H.248.2 (2005), Gateway control protocol: Facsimile, text

conversation and call discrimination packages.
[E3]
HANDLEY (M.), JACOBSON (V.): SDP: Session Description Protocol, RFC 2327,
April 1998.
[E4]
SCHULZRINNE (H.), PETRACK (S.): RTP Payload for DTMF Digits, Telephony Tones
and Telephony Signals, RFC 2833, May 2000.
[E5]
ITU-T Recommendation T.30 (2005), Procedures for document facsimile transmission in

the general switched telephone network.
[E6]
SCHULZRINNE (H.), PETRACK (S.): RTP Payload for DTMF Digits, Telephony Tones
and Telephony Signals, draft-ietf-avt-rfc2833bis-2.txt, November 2005.
54
ITU-T Rec. T.38 (09/2005)
Annex F
Interworking procedures: T.38 and V.150.1 in the same gateway
F.1
Introduction
This annex describes the procedures that shall be used by gateways that have both T.38 and
V.150.1 capabilities in the same gateway. Such a gateway shall indicate these capabilities by use of
the appropriate external signalling mechanism (H.323, H.248 or SIP/SDP) as defined in the relevant
Recommendations. The terms "FoIP" and "MoIP" as used in this annex are synonymous to ITU-T
Recs T.38 and V.150.1 respectively.
This type of gateway shall only transition to FoIP from MoIP. These procedures do not include any
transitions directly from audio to FoIP nor do they replace the audio and T.38 configuration
procedures as defined in Annexes B, D and E.
A gateway with these joint capabilities shall initially behave as a V.150.1 gateway. That is all the
call discrimination procedures up to the point at which T.38 procedures are invoked are defined in
clause 20/V.150.1. The transition from MoIP to FoIP occurs when a gateway (in MoIP mode)
detects and verifies the presence of a T.30 facsimile signal such as V.21 Channel 2 HDLC encoded
flags or a V.8 CM signal on the telephony link to the gateway.
This switching mechanism shall use State Signalling Event (SSE) protocol as defined in
Annex C/V.150.1. Figures F.1 and F.2 illustrate this transition for two facsimile triggering events.
Figure F.1 shows a transition to Standard G3 facsimile and Figure F.2 shows a similar transition
to V.34 facsimile.
F1
G1
Audio
G2
Audio
V.21(H) flags
1Flags)
SSE:f(V2
SSE:f(p')
Facsimile/
T.38
Link 1
F2
Facsimile/
T.38
T.38
Link 2
T.38_F1(AF)
Figure F.1/T.38 T.38 FoIP (MoIP transition to T.30 fax)

F1
G1
V.8-CM=V.34 fax
Facsimile/
T.38
Link 1
G2
Audio
SSE:f(V3
4fax)
SSE:f(p')
T.38
F2
Audio
Facsimile/
T.38
Link 2
T.38_F2(AF)
Figure F.2/T.38 T.38 FoIP (MoIP transition to V.34 fax)
ITU-T Rec. T.38 (09/2005)
55
Upon the detection of a facsimile event, the gateway shall transmit a SSE:f(RIC) to the peer
gateway, where SSE:f is the FAX RELAY SSE transition indication. RICs are reason identifier
codes and are defined in F.2. The use of SSE shall comply with Annex C/V.150.1.
ITU-T Rec. V.150.1 defines the SSE:f event code in C.5.2/V.150.1 and it has a decimal value of 4.
F.2
SSE reason identifier codes for T.38 transition
The following RICs are defined for the SSE:f event:

V21Flags: This RIC indicates that the gateway has detected and verified that it has received
HDLC flags modulated on V.21 channel 2 as defined in ITU-T Rec. T.30.
V8Profile: This RIC indicates that the gateway has received a V.8 CM sequence that is a valid
facsimile connection request. This RIC has as additional information the Profile and T.66 codes
(if present) that is used in the "t30-data(cm-message)" of this Recommendation.
P' State Transition: This is the same signal as used in MoIP. It performs the same behaviour as an
ACK. The value is chosen to be consistent with ITU-T Rec. V.150.1.
The table below summarizes the RICs for T.38 SSEs.
Name
Code
(decimal)
Additional informational content
Null
None
V21Flags
None
V8Profile
"cm-message"
p' State Transition
19
None
In both examples, the use of SSE:f may be used as an equivalent signal from T.38. For example
SSE:f(V21Flags) may be used as t30-indicator:FLAGS and SSE:f(V8profile(cm-message)) may be
used as t30-data:cm-message.
A gateway is not required to wait for the SSE:f(p') message in response to its SSE:f request. The
gateway shall transmit the equivalent T.38 IFP message immediately after issuing the
SSE:fr request. The gateway shall then follow the procedures as defined in this Recommendation.
F.3
External signalling
The use of SSEs is negotiated during the call setup phase. Annexes E and F/V.150.1 describe the
SDP and H.323 syntax accordingly to be incorporated by a MoIP/FoIP gateway.
NOTE The definition of the H.248 syntax for ITU-T Rec. V.150.1 is to be defined.
56
ITU-T Rec. T.38 (09/2005)
Annex G
H.245 Capability Definition for T.38 over RTP
This annex defines a generic H.245 capability that allows for the transport of T.38 over RTP. It is
intended that this capability would be signalled as an audioCapability within H.245-based systems.
Note that ITU-T Rec. H.245 already defines a T.38 capability for transport of IFP packets over
UDP and TCP, which is a dataApplicationCapability. The capability definition in this annex is
not intended to replace that definition, but rather to provide a means of transporting T.38
IFP packets over RTP only.
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:
This parameter is optional.
collapsing:
This field shall not be included and shall be ignored if received.
nonCollapsing:
This field shall be present and consist of the parameters defined below.
nonCollapsingRaw:
This field shall not be included and shall be ignored if received.
transport:
This field shall not be included.
Parameters for this capability are defined in the following tables:

Parameter name:
BooleanOptions
Parameter description:
This is a nonCollapsing capability.

Contains various Boolean options that must be conveyed.
Parameter identifier value:
Parameter status:
Mandatory
Parameter type:
BooleanArray
LSB is bit 0. Bit value 1 = TRUE.
Bit 0 fillBitRemoval
Bit 1 transcodingJBIG
Bit 2 transcodingMMR
All other bits are reserved and shall be ignored.
Supersedes:
Parameter name:
Version

This identifies the version of the T.38 protocol.
Parameter status:
Optional. If absent, version 0 is assumed.
Parameter type:
unsignedMin
Supersedes:
ITU-T Rec. T.38 (09/2005)
57
Parameter name:
T38FaxRateManagement

This specifies the fax rate management modes.
Parameter status:
Required. Only one sub-parameter of T38FaxRateManagement may be

included in this parameter.
Parameter type:
genericParameter
Supersedes:
Parameter name:
T38FaxRateManagement-localTCF
This is a nonCollapsing capability that is an element of

T38FaxRateManagement.
Parameter status:
Optional
Parameter type:
Logical
Supersedes:
Parameter name:
T38FaxRateManagement-transferredTCF
This is a nonCollapsing capability that is an element of

T38FaxRateManagement.
Parameter status:
Optional
Parameter type:
Logical
Supersedes:
Parameter name:
t38FaxMaxBuffer

This specifies the maximum buffer size.
Parameter status:
Optional
Parameter type:
unsigned32Max
Supersedes:
Parameter name:
t38FaxMaxDatagram

This specifies the maximum datagram size.
Parameter status:
Optional
Parameter type:
unsigned32Max
Supersedes:
58
ITU-T Rec. T.38 (09/2005)
Appendix I
Session examples
I.1
Session examples
This appendix contains a number of examples to show how the sending and receiving G3FEs
communicate with the gateways and what packets the gateways exchange. All examples show a
TCP implementation using Method 1 Rate Adaptation.
Time proceeds downward. Information flows on the solid lines in the direction of the arrows. The
box superimposed on each line indicates what information is being transmitted. All information
between the G3FE and a gateway is T.30/T.4/T.6-conforming information. Information transmitted
between the gateways is in the form of packets as described in this Recommendation. The contents
of the labelling box on a packet transmission indicates the packet type, followed by any additional
information which is carried in the packet's payload.
Dashed lines are used to clarify the point in time at which a piece of information begins
transmission (for example, T30_INDICATOR: Flags packets are sent when flags are noticed, not
necessarily when the flags begin or end transmission). Dashed lines do not indicate any type of
information flow.
Packet labels indicate the type of packet as well as any field information, for field-type packets. For
example, a label such as "V.21:HDLC:TSI/FCS" indicates a V.21 HDLC (T.30 Control) packet
with a field containing TSI information and a field indicating FCS. Due to space constraints, the
FCS is generalized to include FCS and FCS-Sig-End.
I.1.1
Two traditional facsimile devices communicating using ECM
Figure I.1 shows two traditional Group 3 facsimile devices that use the PSTN for communicating
with facsimile gateways. ECM is used for image transfer. The example begins after the transport
connection/session has been established and the receiving G3FE has answered a call from the
receiving gateway and is about to generate CED.
I.1.2
Traditional facsimile device and Internet-aware facsimile device
Figure I.2 shows a traditional Group 3 facsimile device sending to an Internet-aware facsimile
device without using ECM. The example begins after the transport connection/session has been
established and the Receiving is about to generate CED.
I.1.3
Two traditional facsimile devices using frequent frames
Figure I.3 shows two traditional Group 3 facsimile devices that use the PSTN for communicating
with facsimile gateways. It is similar to the scenario described in I.1.1 except that the image transfer
does not use ECM and the receiving gateway does not wait for complete HDLC BCS sequences
before beginning to send frames.
ITU-T Rec. T.38 (09/2005)
59
Sending G3FE
Emitting gateway
CED tone
Receiving gateway
T30 IND:CED
T30 IND:Flags
Flags
CSI
Receiving G3FE
CED tone
Flags
CSI
V.21:HDLC:CSI/FCS
V.21:HDLC:DIS/FCS
DIS
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
Flags
CFR
V.21:HDLC:CFR/FCS
CFR
Training
Image
data
Flags
T30 IND : Speed

V.17:HDLC:
Image Data
Training
V.17:HDLC:
Image Data:
FCS-Sig-End
Image
data
T30 IND : Flags
PPSNULL
Flags
T.21:HDLC:
PPS/NULL/FCS
T30 IND : Flags

Flags
PPSNULL
Flags
PPR
V.21:HDLC:PPR/FCS
PPR
T.38_FI.1a(APPI)
Figure I.1/T.38 Two Group 3 facsimile devices communicating

through gateways (sheet 1 of 2)
60
ITU-T Rec. T.38 (09/2005)
Sending G3FE
Emitting gateway
Training
Image
data
Receiving gateway
T30 IND : Speed

V.17:HDLC:
Image Data
V.17:HDLC:
Image Data:
FCS-Sig-End
Flags
Training
Image
data
T30 IND : Flags
PPSNULL
V.21:HDLC:
PPS-NULL/FCS
T30 IND : Flags

Flags
Receiving G3FE
Flags
PPSNULL
Flags
MCF
V.21:HDLC:MCF/FCS
MCF
Training
T30 IND : Speed
Image
data
V.17:HDLC:
Image Data:FCS
Training
Image
data
Flags
V.17:HDLC:
Image Data:
FCS-Sig-End
PPS-EOP
T30 IND : Flags

V.21:HDLC:
PPS-EOP/FCS
T30 IND : Flags

Flags
Flags
PPS-EOP
Flags
MCF
V.21:HDLC:MCF/FCS
MCF
Flags
T30 IND : Flags
DCN
V.21:HDLC:DCN/FCS
DISCONNECT
Flags
DCN
T.38_FI.1b(APPI)
Figure I.1/T.38 Two Group 3 facsimile devices communicating through

gateways (sheet 2 of 2)
ITU-T Rec. T.38 (09/2005)
61
Emitting gateway
Sending G3FE
Receiving
gateway/Internetaware Device
T30 IND:CED
CED tone
Flags
CSI
T30 IND : Flags

V.21:HDLC:
CSI/FCS,
DIS/FCS-Sig-End
DIS
Flags
T30 IND : Flags
TSI
DCS
V.21:HDLC:TSI/FCS
V.21:HDLC:DCS/FCS
TCF
T30 IND : Flags

Flags
V.21:HDLC:CFR/FCS
CFR
Training
Image
data
Flags
EOP
T30 IND : Speed

V.17: non-ECM:
Image Data
V.17: non-ECM:
Image Data:
non-ECM-Sig-End
T30 IND : Flags
V.21:HDLC:EOP/FCS
Flags
MCF
Flags
DCN
T30 IND : Flags

V.21:HDLC:MCF/FCS
T30 IND : Flags

V.21:HDLC:DCN/FCS
DISCONNECT
T.38_FI.2(APPI)
Figure I.2/T.38 Traditional facsimile device and Internet-aware device
62
ITU-T Rec. T.38 (09/2005)
Sending G3FE
Emitting gateway
Receiving gateway
T30 IND:CED
Receiving G3FE
CED tone
CED tone
T30 IND : Flags
Flags
CSI
V.21:HDLC:CSI
V.21:HDLC:CSI/FCS
V.21:HDLC:DIS
DIS
Flags
CSI
DIS
V.21:HDLC:DIS/FCS
T30 IND : Flags
Flags
TSI
DCS
Flags
V.21:HDLC:TSI/FCS
V.21:HDLC:DCS/FCS
TCF
TSI
DCS
TCF
T30 IND : Flags

Flags
V.21:HDLC:CFR
CFR
Training
Image
data
Flags
EOP
Flags
CFR
V.21:HDLC:CFR/FCS
T30 IND : Speed
V.17: non-ECM:
Image Data
Training
V.17: non-ECM:
Image Data:Sig-End
Image
data
T30 IND : Flags

V.21:HDLC:EOP/FCS
Flags
EOP
Flags
T30 IND : Flags

V.21:HDLC:MCF
MCF
V.21:HDLC:MCF/FCS
Flags
MCF
T.38_FI.3(APPI)
Figure I.3/T.38 Use of multiple frames per BCS sequence
ITU-T Rec. T.38 (09/2005)
63
I.2
IAF device
This clause addresses the sequences that are considered in IAF device communication.
I.2.1
Sender is an IAF device, receiver is G3fax
CFR signal receive timing at the IAF device

It is recommended that IAF devices wait to receive the CFR signal, taking into account the period
during which the Gateway sends TCF to G3fax. As Figure I.4 shows, this prevents the DCS signal
of the IAF device from colliding at the Gateway with the CFR signal of the G3fax.
IAF
Gateway
G3fax
DIS
DIS
DCS
DCS
TCF
CFR
CFR
T.38_FI.4(APPI)
Figure I.4/T.38 IAF transmit timing from DCS to CFR
64
ITU-T Rec. T.38 (09/2005)
I.2.2
Receiver is an IAF device, sender is G3fax
CFR signal send timing at the IAF device

It is recommended that IAF devices send the CFR signal, after taking into account the period during
which the Gateway receives TCF from the G3fax device. As Figure I.5 shows, this prevents the
TCF from colliding with the CFR signal from the IAF device.
G3fax
Gateway
IAF
DIS
DIS
DCS
DCS
TCF
CFR
CFR
T.38_FI.5(APPI)
Figure I.5/T.38 IAF receive timing from DCS to CFR
ITU-T Rec. T.38 (09/2005)
65
Appendix II
Examples of call establishment procedures described in Annex B/T.38
II.1
Sequence examples of call establishment procedures
II.1.1
Between Annex B/T.38 gateways
66
ITU-T Rec. T.38 (09/2005)
II.1.2
II.1.2.1
Between Annex B/T.38 and Annex D/H.323 gateways

Normal connection and disconnection sequence (Annex B/T.38 supporting only
FAX)
ITU-T Rec. T.38 (09/2005)
67
II.1.2.2
68
Normal connection and disconnection sequence (Annex B/T.38 supporting FAX

and voice)
ITU-T Rec. T.38 (09/2005)
II.1.2.3
Connection rejected sequence 1 (when the calling side, Annex D/H.323, does not
support Fast Connect Procedures)
II.1.2.4
Connection rejected sequence 2 (when the called side, Annex D/H.323, does not
support Fast Connect Procedures)
ITU-T Rec. T.38 (09/2005)
69
II.1.3
II.1.3.1
Between Annex B/T.38 supporting FAX and Annex D/H.323 gateways that are both
registered to the same Gatekeeper
Normal connection sequence (when Gatekeeper has chosen Direct Call Signalling)
II.2
Protocol data used in call establishment procedures
II.2.1
General
Two Recommendations ITU-T Rec. H.225.0 (as a subset of ITU-T Rec. Q.931) and ITU-T
Rec. H.245 define the protocol data used in Call establishment procedures of Annex B, while
ITU-T Rec. H.323 gives the general protocol design of the whole system. For example
SETUP message is defined in Table 13/H.225.0 and its User-user Information Element (UUIE) is
defined as Setup-UUIE under H323-UU-PDU in ITU-T Rec. H.225.0. Then fastStart element which
is defined as SEQUENCE OF OCTET STRING by ASN.1 definition of Setup-UUIE encapsulates
OpenLogicalChannel which is defined under MultimediaSystemControlMessage in ITU-T
Rec. H.245.
70
ITU-T Rec. T.38 (09/2005)
Additionally, RAS messages need to be understood to fully implement Annex B. RAS is also
defined in ITU-T Rec. H.225.0 as RasMessage using ASN.1 and Table 18/H.225.0 gives its support
requirements.
II.2.2
Examples of the protocol data
II.2.2.1
Supported H.225.0 (Q.931) message types
Tables II.1 to II.3 show the supported H.225.0 (Q.931) message types in three phases.
Table II.1/T.38 Messages of call setup phase
Message type
transmit
receive
CMa)
a)
ALERT
CALL PROC
CM
CONNECT
CONNECT ACK
PROGRESS
SETUP
SETUP ACK
Mandatory
Optional
Forbidden
CM
Conditional Mandatory
a)
Note that gateways shall send ALERT and CALL PROC messages while IAF (Internet-aware fax) may
not send them. Note that an Annex D/H.323 GW may send ALERTING or CALL PROC to an IAF.
Table II.2/T.38 Messages of call release phase

Message type
transmit
receive
DISCONNECT
RELEASE
RELEASE COMP
Table II.3/T.38 Messages of other phase

Message type
FACILITY
a)
transmit
receive
CMa)
Ma)
Note that Annex B/T.38 implementation shall receive and send FACILITY when connecting to
Annex D/H.323 implementation.
II.2.2.2
Information elements of SETUP
Tables II.4 to II.6 show information elements of SETUP message.
ITU-T Rec. T.38 (09/2005)
71
Table II.4/T.38 Information elements of SETUP

Information element
Protocol discriminator
Call reference
Message type
Bearer capability
Calling party number
Calling party subaddress
Called party number
Called party subaddress
User-user
Parameter
Status
Reference H.225.0
Reference H.225.0
Reference H.225.0
Reference H.225.0
Reference H.225.0
Reference H.225.0
Reference H.225.0
Reference H.225.0
protocolIdentifier
SourceInfo
destinationAddress
destCallSignalAddress
M
M
M
M
O
CM
O
CM
M
M
M
M
activeMC
conferenceID
conferenceGoal
callType
callIdentifier
mediaWaitForConnect
canOverlapSend
M
M
M
M
M
M
M
fastStart
Description
H.225.0 version number

EndpointType
Used by Gatekeeper
TransportAddress
(IP address + Port number)
FALSE
NULL
NULL
PointToPoint
GloballyUniqueID
TRUE
if TRUE, support overlap
sending
Reference Table II.5
Table II.5/T.38 Parameters of fastStart(OpenLogicalChannel)

Parameters
ForwardLogicalChannelNumber
ForwardLogicalChannelParameters
PortNumber
DataType
MultiplexParameters
ReverseLogicalChannelParameters
DataType
MultiplexParameters
72
ITU-T Rec. T.38 (09/2005)
Description

dateType is linked with DataApplicationCapability in
Annex B.
Note that DataApplicationCapability in Annex B is only
extraction among CHOICEs of application of H.245.
sessionID, mediaChannel and mediaControlChannel in
H2250LogicalChannelParameters
dateType is linked with DataApplicationCapability in
Annex B.
Note that DataApplicationCapability in Annex B is only
extraction among CHOICEs of application of H.245.
sessionID, mediaChannel and mediaControlChannel in
H2250LogicalChannelParameters
Table II.6/T.38 Parameters of dataType(DataApplicationCapability)

Parameter
Status
Description
Application
t38fax
t38FaxProtocol
t38FaxProfile
FilBitRemoval
TranscodingJBIG
TranscodingMMR
Version
t38FaxRateManagement
t38FaxUdpOptions
t38FaxMaxBuffer
t38FaxMaxDatagram
t38FaxUdpEC
CHOICE index shall be encoded to indicate the

use of t38UDPFEC or t38UDPRedundancy.
Units 100 bit/s
MaxBitRate
II.2.2.3

use of t38fax.
CHOICE index of DataProtocolCapability shall
be encoded to indicate the use of TCP or UDP.

use of localTCF or transferredTCF.
Information elements of ALERT
Table II.7 shows information elements of ALERT message.

Table II.7/T.38 Information elements of ALERT
Information element
Parameter
Status
Reference H.225.0
Call reference
Reference H.225.0
Message type
Reference H.225.0
User-user
Reference H.225.0
II.2.2.4
Description
Information elements of CALL PROC
Table II.8 shows information elements of CALL PROC message.

Table II.8/T.38 Information elements of CALL PROC
Information element
Parameter
Status
Reference H.225.0
Call reference
Reference H.225.0
Message type
Reference H.225.0
User-user
Reference H.225.0
Description
ITU-T Rec. T.38 (09/2005)
73
II.2.2.5
Information elements of CONNECT
Table II.9 shows information elements of CONNECT message.

Table II.9/T.38 Information elements of CONNECT
Information element
Parameter
Status
Description
Reference H.225.0
Call reference
Reference H.225.0
Message type
Reference H.225.0
User-user
protocolIdentifier
destinationInfo
EndpointType
conferenceID
NULL
callIdentifier
GloballyUniqueID
FastStart
II.2.2.6
Information elements of RELEASE COMPLETE
Table II.10 shows information elements of RELEASE COMPLETE message.

Table II.10/T.38 Information elements of RELEASE COMPLETE
Information element
Parameter
Status
Reference H.225.0
Call reference
Reference H.225.0
Message type
Reference H.225.0
Cause
Reference H.225.0
CM
User-user
Reference H.225.0
II.2.2.7
Description
Either the Cause IE or

ReleaseCompleteReason in
User-user shall be present.
Information elements of FACILITY
Table II.11 shows information elements of FACILITY message.

Table II.11/T.38 Information elements of FACILITY
Information element
Parameter
Status
Description
Reference H.225.0
Call reference
Reference H.225.0
Message type
Reference H.225.0
User-user
protocolIdentifier
reason
FacilityReason
callIdentifier
GloballyUniqueID
74
ITU-T Rec. T.38 (09/2005)
Appendix III
H.248 call establishment procedure examples for
facsimile-capable media gateways
III.1
Introduction
This appendix describes examples of the procedures for Internet-aware facsimile implementations
and Internet-aware facsimile gateways conforming to this Recommendation to establish calls with
other T.38 implementations using the procedures defined by Annex E and ITU-T Rec. H.248. In
addition, this appendix describes examples of MG/MGC interactions for establishing a call between
H.248 endpoints and H.323 endpoints. The examples are divided into two main categories:
Call setup procedures that allow MGs to transition from voice/audio state to T.38 state
using the MGC controlled method;
Call setup procedures that allow MGs to autonomously transition from voice/audio state to
T.38 state.
III.2
III.2.1 Voice to fax call setup with H.248 endpoints using the T.38 Transitioning Method
This call flow example describes a voice call that originates and terminates in the SCN and is
transported through the packet network. The packet network signalling in this example is not
specified but any signalling protocol such as H.323 or SIP can be used the purpose of the example
is to describe MG/MGC interactions, involved when the MGs and the MGC support the
MGC procedure, including the detection of fax and switching from voice to fax.
ITU-T Rec. T.38 (09/2005)
75
Figure III.1/T.38 Voice to fax call setup with H.248 endpoints
76
ITU-T Rec. T.38 (09/2005)
The sequence of events is as follows:

1)
At some point before a call, the media gateway controller will have issued an audit
capabilities command to the media gateways under its control and will know what the voice
and fax capabilities are for each gateway. In the scenarios below, if both Media Gateways
support T.38, then this is the preferred mode for IP fax operations. In the event that one or
both media gateways do not support T.38, then the fax call may proceed over the IP voice
channel. However, since T.30 facsimile may fail over a compressed voice codec, it would
be preferable to use a G.711 codec for communication between the media gateways. 'W-' is
used to indicate that a wild-card answer with a union of information on all terminations on
the MG is requested, not an audit of each termination on the MG. In the example MG1
indicates support of T.38, however the audit shall not be used to infer support of either
the T.38 Autonomous Transitioning method or the T.38 MGC Transitioning method
as described in E.2.2. This shall be done on a call-by-call basis during the Add Ephemeral
(see point 3 below).
The MGC audits MG1.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 9 {
Context = - {W-AuditValue = * {Audit{Packages}}}
}
MG1 replies. MG1 to MGC:

MEGACO/1.0 [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.0 [123.123.123.4]:55555
Transaction = 10 {
Context = - {W-AuditCapabilities = * {Audit{Media }}}
}

MEGACO/1.0 [125.125.125.111]:55555
Reply = 10 {
Context = - {
AuditValue = * {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0 18
v=0
c=IN IP4 $
m=image $ udptl t38
} ; RTP profile for G.711 is 0, G.729 is 18, t38 is T.38
}
},
}
}
}
ITU-T Rec. T.38 (09/2005)
77
A similar exchange happens between the MGC and MG2.

2)
The End User decides to send a fax from device F1 and enters the phone number. The fax
device gets dial tone and then dials the phone number. As a result, the central office within
the local SCN loop sends an SS7 message to the signalling gateway (SG). The SG sends a
Setup message to the MGC after receiving this IAM from a SCN switch that conveys the
called and calling phone numbers. SCTP (for example) carries the SS7 signalling from the
SG to the MGC.
3)
From the IAM message, the MGC may infer which circuit on which MG is involved and
where to terminate the call. How the MGC does this is outside the scope of this appendix.
The endpoints are found by the media gateway controller (MGC) and it sets up the audio
channel between the two media gateways and instructs the SS7 facility of the receiving CO
to connect to the end phone destination, which results in the generation of ringing. So, to
start, the controller determines that a connection needs to be made from MG1 to MG2. The
MGC creates a Context for the call. Both the TDM termination DS0/1/1, and an RTP
termination are added to a new context in MG1. Mode is ReceiveOnly since Remote
descriptor values are not yet specified. Preferred codecs are in the MGC's preferred order of
choice. The MGC sets to CHOOSE (i.e., $) the fields in the SDP in the Local descriptor
that the MG will set itself. Also, in order for the MGC to infer whether both gateways
support the T.38 Autonomous Transitioning method or T.38 MGC Transitioning
method, the MGC instructs MG1 to respond with the values of both its audio
RTP/AVP capabilities and its image/t38 capabilities. Note that this is achieved by
including in the LocalControl descriptor "ReserveGroup=True" to ask the MG to
reserve resources for both audio and image media descriptors. In addition
"ReserveValue = True" to ask the MG to reserve resources for all the possible codecs
offered in the media descriptor (alternatively, an MGC may include ReserveValue=false to
ask for the most preferred codec; however, if omitted, a MG by default must set this value
to false).
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 11 {
Context = $ {
Add = DS0/1/1 {
Events = 1 {al/on, ctyp/dtone }
}, ; SCN termination prepared to listen for tones
Add = $ {
Media {
Stream = 1 {
LocalControl { Mode = ReceiveOnly, ReserveGroup = True, ReserveValue =
True},
Local {
v=0
c=IN IP4 $
v=0
c=IN IP4 $
m=image $ udptl t38
}; IP termination for audio
}
}
}
}
}
4)
78
MG1 acknowledges the new Termination and fills in the Local IP address and UDP port. In
this example, MG1 supports both offered codecs, hence returns both codecs in the same
preference order provided by the MGC (thus leaving the final choice to MG2). MG1 sets
the RTP port to 2222. Also, because MG1 does not support the T.38 Autonomous
ITU-T Rec. T.38 (09/2005)
Transitioning method for transitioning between VoIP and FoIP, it omits the image media
descriptor line all together (alternatively, it could have set the T.38 port to 0).
MEGACO/1.0 [124.124.124.222]:55555
Reply = 11 {
Context = 2000 {
Add = DS0/1/1, ; SCN termination added
Add = RTP/1 {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0 ;MG1 supports both offered codecs
a=ptime:20
} ; IP termination added
}
}
}
}
}
5)
Assume that the MGC has control over the remote MG2 also. The MGC, based on the reply
of MG1, has inferred that the T.38 MGC Transitioning method shall be used to transition
between VoIP and FoIP, and will now associate DS0/2/2 with a new Context on MG2, and
establish an RTP Stream (i.e., RTP/2 will be assigned), SendReceive connection through to
the originating user, User 1. MGC includes in the LocalControl descriptor of the ephemeral
termination the property "ReserveValue=False" to indicate to MG2 to select a codec.
MGC to MG2:
MEGACO/1.0 [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 $
},
Remote {
v=0
c=IN IP4 124.124.124.222
a=ptime:20
} ; RTP profile for G.729 is 18
}
}
}
}
}
6)
This is acknowledged. Also, based on the remote SDP provided, MG2 can infer that the
T.38 MGC Transitioning method shall be used for transitioning from a VoIP state to a FoIP
state. The stream port number is 1111 (in the SDP). Also, MG2 selects the first codec in the
offered priority codec list as the preferred codec, i.e., G.729 (RTP payload type = 18).
ITU-T Rec. T.38 (09/2005)
79
MG2 to MGC:
MEGACO/1.0 [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.111
}
}
}
}
}
}
7)
The above IPAddr, UDPport, and selected codec need to be given to MG1 now. Also,
because the MGC knows that the T.38 MGC Transitioning method shall be used, it needs to
indicate to MG1 that it has to detect facsimile tones and inform it appropriately as well as
apply ringing tone ringback to the DS0/1/1 termination and change it to a SendReceive.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 12 {
Context = 2000 {
Modify = DS0/1/1 {
Events = 10 { ctyp/dtone},
; detect facsimile tones
Signals {cg/rt} }, ;apply ringing tone
Modify = RTP/1 {
Media {
Stream = 1 {
LocalControl {Mode = SendReceive }
Remote {
v=0
c=IN IP4 125.125.125.111
}
}
}
}
}
}
from MG1 to MGC:

MEGACO/1.0 [124.124.124.222]:55555
Reply = 12 {
Context = 2000 {Modify = DS0/1/1, Modify = RTP/1}
}
8)
80
The calling fax machine typically will start to generate CNG calling tones. When the CNG
tone event is detected by the first media gateway (MG1), this event shall be reported to the
media gateway controller. The media gateway controller then shall issue a command to the
second media gateway (MG2) to generate a CNG tone. At this point, the full duplex
channel is still in a voice mode and using the indicated audio codec such as G.723.1 and
G.729A.
ITU-T Rec. T.38 (09/2005)
from MG1 to MGC:

MEGACO/1.0 [124.124.124.222]:55555
Transaction = 50 {
Context = 2000 {
Notify = DS0/1/1 {
ObservedEvents = 1 {
19991212T22110001: ctyp/dtone{dtt=cng} }
}
}
}
from MGC to MG1:

MEGACO/1.0 [123.123.123.4]:55555
Reply = 50 {
Context = 2000 {Notify = DS0/1/1}
}
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 31 {
Context = 5000 {
Modify = DS0/2/2 {
Signals {ctyp/callsig{callSigname=cng}}; issue CNG at remote end
}
}
}
MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555
Reply = 31 {
Context = 5000 {Modify = DS0/2/2}
}
9)
In the previous step, the MG2 generated a CNG tone requested by the MGC in the Signals
descriptor. In the typical case, if the final destination phone number is fax capable, a CED
tone will be generated by the recipient fax machine. This step is illustrated here. However,
if there is not a fax receiver on the line, the typical response will be via voice.
from MG2 to MGC:

MEGACO/1.0 [123.123.123.4]:55555
Transaction = 70 {
Context = 5000 {
Notify = DS0/2/2 {
19991212T22110031: ctyp/dtone{dtt=ANS}}; CED and ANS are equivalent. Reported
under the name ANS.
}
}
}
from MGC to MG2:

MEGACO/1.0 [125.125.125.111]:55555
Reply = 70 {
}
10)
Assuming that a CED has been generated by the recipient fax device, the MG2 will then
receive the CED and uses its tone detection algorithms to detect that it actually is a CED.
(NOTE Some research was done to check out modem answer tones, which are defined in ITU-T
Recs V.25 and V.8. The modem answer tone without phase reversals is known as ANS in ITU-T
Rec. V.25 and with answer tones is ANS (with a bar on top denoting Phase reversals). Some
modems and DSPs may have a difficult time distinguishing among the CED, ANS and ANS(bar).
However, the group felt that if a CED-like tone was generated in response to a CNG, there is a very
high likelihood that the tone is indeed a CED and not one of the ANS tones. Higher end modems
are able to discriminate between ANSam and the other modem and fax tones.).
ITU-T Rec. T.38 (09/2005)
81
Since a CNG was reported by the calling side and a CED by the called side, the Media
Gateway Controller will issue a command instructing MG1 to play the CED. Both media
gateways to shift into a fax mode (either T.38 if supported, or G.711). From this point, the
V.21 fax data will be conveyed between the media gateways. Note that at this point, the
MGC could decide that there is sufficient confidence to switch to fax, unless, for example,
some other answer tone has been detected, such as ANSam (see step 18). For the purpose of
this example, it does not believe it has sufficient confidence.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 13 {
Context = 2000 {
Modify = DS0/1/1 {
Signals {ctyp/ans{anstype=ans}}
}
}
}
MG1 to MGC:
MEGACO/1.0 [124.125.125.222]:55555
Reply = 13 {
}
11)
When MG2 detects a V.21 carrier followed by flags, it will send a message to the MGC
reporting this event. At this point, the MGC is certain that the call is a fax and will initiate a
switch, first on the DS0 terminations. Note that V.21 flags are not signalled to MG1. The
event causes the MGC to ask MG1 to play v21flags to its SCN termination.
MG2 notifying MGC of V.21 carrier event:

from MG2 to MGC:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 71 {
Context = 5000 {
Notify = DS0/2/2 {
19991212T22110031:ctyp/dtone{dtt=v21flag}}
}
}
}
MGC responds.
from MGC to MG2:
MEGACO/1.0 [125.125.125.111]:55555
Reply = 71 {
}
MGC sends a command to MG1 to send the V.21 flags on its SCN termination and hand over the
continuation of the session to the fax package.
MGC to MG1:
MEGACO/1.0 [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;
}
}
}
}
}
82
ITU-T Rec. T.38 (09/2005)
MG1 to MGC:
MEGACO/1.0 [124.125.125.222]:55555
Reply = 5 {
The MG must generate the V21flags signal until the V21 flags indication arrives in the T.38 media
stream (see step 17) and then continue until the V21 flags termination is indicated in the T.38 media
stream.
12)
At this point the SCN termination on MG2 and MG1 shall be put into fax mode (this stage
is Negotiating). Only the example of MG2 is shown. Note that in the case of MG2, since
the ctyp package is not mentioned in the Events Descriptor, the MG is no longer required to
perform call type discrimination event notification. Also, since CNG is not mentioned in
the signal descriptor, this signal is terminated.
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 33{
Context = 5000 {
Modify = DS0/2/2 {
Events = 12 { fax/faxconnchange}
Signals{},
Media{
TerminationState
{fax/faxstate = Negotiating;
}
}
}
}
}
And MG2 responds.

MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555
Reply = 33 {
13)
At this point in the call, the switch to fax continues with a request for each MG to switch to
T.38 mode. Note that the MGC is aware that the MGs support T.38 as a result of a previous
audit. If T.38 was not available, then the audio mode may be changed to G.711 (the details
of this are out of scope). Selection among the voice, fax and data modes will have been
achieved, unless some other answer tone has been detected, such as ANSam. In the event
that ANSam is detected, the two MGs should be switched into a mode where they can
conduct a V.8 session to further determine the type of call (e.g., V.34 fax, V.90 data, text
telephone, etc.). The handling of V.34 fax calls in this environment is for further study.
MGC to MG1:
MEGACO/1.0 [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
} ; change to T.38 in the IP connection
}
}
ITU-T Rec. T.38 (09/2005)
83
}
}
}
14)
Following is the response from MG1. MG1 changes one of the a= fields: The T.38
parameter transferredTCF is changed by MG1 to localTCF. MG1 may also change the port
number if it does not want to switch the use of the existing voice channel to faxport. In this
example, it changes the port from 2222 to 3333.
from MG1 to MGC:

MEGACO/1.0 [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
}; the IP connection brought into fax mode
}
}
} }
}
15)
The new media information must be passed on to MG2.
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 32 {
Context = 5000 {
Modify = RTP/2 {
Media {
TerminationState
}
Stream = 1 {
Local {
v=0
c=IN IP4 125.125.125.111
},
Remote {
v=0
c=IN IP4 124.124.124.222
}
}
}
}
}
}
16)
This is acknowledged MG2 elects NOT to change the port (it remains as 1111), and does
not change any T.38 parameters.
MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555
Reply = 32 {
Context = 5000 {
Modify = RTP/2 {
Media {
Stream = 1 {
Local {
84
{ipfax/faxstate = Negotiating;
ITU-T Rec. T.38 (09/2005)
v=0
c=IN IP4 125.125.125.111
}
}
}
}
}
}
17)
Now, MG1 needs to be given the new media information from MG2.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 15 {
Context = 2000 {
Modify = RTP/1 {
Media {
Stream = 1 {
Remote {
v=0
c=IN IP4 125.125.125.111
}
}
}
}
}
}
from MG1 to MGC:

MEGACO/1.0 [124.124.124.222]:55555
Reply = 15 {
Context = 2000 { Modify = RTP/1}
}
The fax call will now proceed in T.38 mode between the MGs. The first from MG2 message will be
a T.30 Indicator packet containing V.21 flags. This will be generated by the continued appearance
of this signal on the DS0 since the MG has no memory of previous events.
Note that the event/faxconnchange is left on the event list of both MGs and so each state change
will result in a Notify to MCG; however, MCG need not explicitly set the fax/faxstate in response
since faxstate should be set implicitly by each MG as it changes state. MCG may take no action for
most state changes but will likely take appropriate action for states such as Disconnect.
18)
Variant: In the event that a CED or similar tone is detected by the MG2, it will always
report this to the MGC. For the case where the MGC had not previously received
notification of CNG detection by MG1, the group felt that it is still not clear whether a fax
or data mode is applicable. However, the compressed voice codecs are not adequate in
either case, so the MGC should place both MGs into a data-capable mode (i.e., G.711) or
wait for additional tones to further discriminate the call.
19)
If the MG2 has the facility to detect a V.21 carrier followed by flags, it will send a message
to the MGC reporting this event. (It is assumed that MGs will generally not have memory
of prior events, so that the notification of V.21 and flags will be sent even if the MGC has
already placed the two MGs into a fax mode.) If the MGC had not previously placed the
two MGs into a fax mode, it will do so now. If the MGs are already in a G.711 mode, the
MGC shall have the choice of not requesting a mode change or of requesting that the two
media gateways switch to a T.38 mode.
ITU-T Rec. T.38 (09/2005)
85
MG2 notifying MGC of V.21 carrier event:

from MG2 to MGC:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 4 {
Context = 5000 {
Notify = DS0/2/2 {
19991212T22110031:ctyp/dtone{dtt=v21flag}}
}
}
}
20)
Variant: At this point in the call, the selection among the voice, fax and data modes will
have been achieved, unless some other answer tone has been detected, such as ANSam. In
the event that ANSam is detected, the two MGs should be switched into a mode where they
can conduct a V.8 session to further determine the type of call (e.g., V.34 fax, V.90 data,
text, telephone, etc.) The handling of V.34 fax calls in this environment is for further study.
MG notifying MG2 of an ANSam event:

from MG2 to MGC:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 4 {
Context = 5000 {
Notify = DS0/2/2 {
19991212T22110031:ctyp/dtone{dtt=ansam}}
}
}
}
III.2.2 Fax-only call setup between H.248 and an H.323 endpoint

This facsimile-only call flow example (see Figure III.2), describes a facsimile call that originates in
the SCN and is terminated in the packet network. The packet network signalling in this example is
H.323 but other signalling protocols such as SIP can be used. The purpose of the example is to
describe MG/MGC interactions.
The assumption is made that the signalling between the signalling gateway (SGW) and MGC is
based on ITU-T Rec. Q.931. This does not indicate that no other signalling can be used on this
interface. Capabilities described here are generic line package descriptions (but could also be SDP
or H.245 messages).
The media gateway is configured for voice and fax; however, the H.323 endpoint is fax only, taking
the calls into fax-only mode. (i.e., it is likely a T.38 Annex B endpoint).
86
ITU-T Rec. T.38 (09/2005)
Figure III.2/T.38 Fax-only call setup between H.248 and an H.323 endpoint
1)
The SGW sends a Setup message to the MGC after receiving an IAM from a SCN switch.
From the Setup message, the MGC may infer which circuit on which MG is involved and
ITU-T Rec. T.38 (09/2005)
87
2)
where to terminate the call. How the MGC does this is outside the scope of this
Recommendation.
The MGC creates a Context for the call. The Context contains two terminations: one for the
SCN side and one for the packet side. Also, in order for the MGC to infer whether both
gateways support the T.38 Autonomous Transitioning method or the T.38 MGC
Transitioning method, the MGC instructs MG1 to respond with the values of both its audio
RTP/AVP capabilities and its image/t38 capabilities. Note that in the LocalControl
descriptor, ReserveGroup = True to ask the MG to take both audio and image media
descriptors (in addition, an MGC may include ReserveValue = false to ask for the most
preferred codec. However, if omitted, an MG by default must set this value to false in
accordance with ITU-T Rec. H.248):
MGC to MG:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 11 {
Context = $ {
Add = DS0/1/1 {
Events = 1 { ctyp/dtone, fax/faxconnchange, al/of}
}, ; the SCN side termination listening for call type indicating tones
Add = $ {
Media {
Stream = 1 {
LocalControl { Mode = ReceiveOnly, ReserveGroup = True },
Local {
v=0
c=IN IP4 $
v=0
c=IN IP4 $
m=image $ udptl t38
} ; the IP side term. showing capability of RTP audio with PT 0 (G.711
PCMU) and 18 (G.729).
}
}
}
}
}
3)
The MG accepts the Context creation and fills in the unknown ($) parameters. MG1 does
not support the T.38 Autonomous Transitioning method; hence, it omits the image media
line in the response:
MEGACO/1.0 [124.124.124.222]:55555
Reply = 11 {
Context = 2000 {
Add = DS0/1/1,; the SCN termination is accepted
Add = RTP/1 {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
} ; the IP RTP termination is accepted with audio payload type 18.
}
}
}
}
}
This shows how the MG reports to the MGC what parameters it filled in.
4)
The MGC sends a Setup message to the destination endpoint, here assumed to be an H.323
endpoint (terminal, GW, etc.). It indicates in the fastStart element that either the capability
to use UDP or TCP may be used for the T.38 facsimile stream.
88
ITU-T Rec. T.38 (09/2005)
5)
6)
The H.323 endpoint sends a CallProceeding message followed by an Alerting message

back to the MGC, informing it of the mode to be used (assume UDP for both directions)
and the transport address; followed by an Alerting message, indicating that it is ringing the
G3FE.
The MGC sends a Modify command to the MG to set the mode and remote termination
description on the packet side:
MGC to MG:
MEGACO/1.0 [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
} ; modify media stream 1 to use image media , udptl transport for T38
}
}
}
}
}
7)
The MG accepts the Modify commands. At about this time, the MG may detect a CNG on
the line; thus notifies the MGC, which acknowledges. Since there is no way to initiate a
playing of CNG on the H.323 endpoint, the MGC will wait until the connection is open.
Note that the MGC may not receive a CNG before the H.323 Connect:
from MG to MGC:
MEGACO/1.0 [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
}; The fax udptl/t38 transport channel is accepted on the IP session
}
}
}
}
MEGACO/1.0 [124.124.124.222]:55555
Transaction = 50 {
Context = 2000 {
Notify = DS0/1/1 {
19991212T22110001:ctyp/dtone{dtt=cng} }
}
}
}
ITU-T Rec. T.38 (09/2005)
89
from MGC to MG:

MEGACO/1.0 [123.123.123.4]:55555
Reply = 50 {
}
8)
9)
10)
The MGC sends an Alerting message to the SGW.

The called endpoint, at some instance, sends a Connect message to the MGC once the
G3FE goes off-hook. Note that this message only contains facsimile capabilities and does
not include an H.245 port
A Modify command to the MG to change the mode of the SCN side termination to
SendRecv and to fax mode. Also, the indication of fax capabilities to be setup on the T.38
is also included in this command (this information was included in the Connect from the
H.323 endpoint):
MGC to MG:
MEGACO/1.0 [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 }
} ; modify SCN termination to reflect that we are connected through
Modify = RTP/1 {
Media {
TerminationState { ipfax/faxstate = Prepare,
ipfax/ipftrpt=T38UDPTL },
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
} ; modify media stream 1 to use image media , udptl transport for T38
LocalControl { Mode = SendReceive
}
}
},
Events = 2 { ipfax/faxconnchng }
}
}
}
11)
12)
The MGC sends a Connect message to the SGW to indicate the call is connected.
The MG accepts the Modify command that was sent to it earlier (see point 10).
from MG to MGC:
MEGACO/1.0 [124.124.124.222]:55555
Reply = 14 {
Context = 2000 {
Modify = RTP/1 {
Media {
Stream = 1 {
Local {
90
ITU-T Rec. T.38 (09/2005)
v=0
c=IN IP4 124.124.124.222
}; The fax udptl/t38 transport channel is accepted on the IP session
}
}
},
Modify = DS0/1/1
}; The modify is accepted on the DS0 session
}
13)
At this point the call proceeds in T.38 mode between the gateways. Likely the originating
G3FE is still sending CNG so this will be sent first, followed by CED from the destination
G3FE.
Note that since the MG has been asked to indicate when the fax connection state changes,
after the V.21 flags packet is received, the MG notifies the MGC of this event.
from MG to MGC:
MEGACO/1.0 [124.124.124.222]:55555
Transaction = 60 {
Context = 2000 {
Notify = RTP/1 {
19991212T22110001:ipfax/faxconnchange{faxconnchng=Negotiating }
}
}
}
from MGC to MG:

MEGACO/1.0 [123.123.123.4]:55555
Reply = 60 {
Context = 2000 {Notify = RTP/1}
}
III.2.3 Voice to fax call setup with H.248 endpoints that support the T.38 Autonomous
Transitioning method
This call flow example (see Figure III.3) describes a voice call that originates and terminates in the
SCN and is transported through the packet network. The packet network signalling in this example
is not specified but any signalling protocols such as H.323 or SIP can be used. The purpose of the
example is to describe MG/MGC interactions when operating in the T.38 Autonomous
Transitioning mode including indication of support of the T.38 Autonomous Transitioning mode,
the detection of fax and switching from voice to fax. Note that, in contrast to the switch-over to
T.38 fax mode under control of the MGC (i.e., the T.38 MGC Transitioning method), the fax
package defined in Annex F/H.248 does not need to be supported by the MGs.
ITU-T Rec. T.38 (09/2005)
91
G3FE1
MG1
MGC
1- AUDIT
MG2
1- REPLY
G3FE2
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- T.38 CNG indicator packet

9- CNG
T.38 mode
10a- T.38 package with DCN
10a- DCN
10a- DCN
10d- Modify (optional)
10d- Modify (optional)
10d- ACK
10d- ACK
Voice mode
T.38_FIII.3(APPIII)
Figure III.3/T.38 Voice to fax call setup with H.248 endpoints that support Autonomous
Transition between VoIP and FoIP
92
ITU-T Rec. T.38 (09/2005)
The sequence of events is as follows:

1)
At some point before a call, the media gateway controller will have issued an audit
capabilities command to the media gateways under its control and will know what the voice
and fax capabilities are for each gateway. In the scenarios below, if both media gateways
support T.38, then this is the preferred mode for IP fax operations. In the event that one or
both media gateways do not support T.38, then the fax call may proceed over the IP voice
channel. However, since T.30 facsimile may fail over a compressed voice codec, it would
be preferable to use a G.711 codec for communication between the media gateways. 'W-' is
used to indicate that a wild-carded answer with a union of information on all terminations
on the MG is requested, not an audit of each termination on the MG. Note that MG1
indicates to the MGC that it supports T.38; however, the audit shall not be used to
indicate support of the T.38 Autonomous Transitioning method or the T.38 MGC
Transitioning method (as described in E.2.2). This shall be done on a call-by-call basis
during the Add ephemeral (see point 3 below).
The MGC audits MG1.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 9 {
Context = - {W-AuditValue = * {Audit{Packages}}}
}

MEGACO/1.0 [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
}
}
}
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 10 {
Context = - {W-AuditCapability = * {Audit{Media }}}
}

MEGACO/1.0 [125.125.125.111]:55555
Reply = 10 {
Context = - {
AuditCapability = * {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 $
v=0
c=IN IP4 $
m=image $ udptl t38
} ; RTP profile for G.711 is 0, G.729 is 18, t38 is T.38
}
},
}
}
}
A similar exchange happens between the MGC and MG2.

ITU-T Rec. T.38 (09/2005)
93
2)
The End User decides to send a fax from device F1 and enters the phone number. The fax
device gets dial tone and then dials the phone number. As a result, the central office within
the local SCN loop sends an SS7 message to the signalling gateway (SG). The SG sends a
Setup message to the MGC after receiving this IAM from a SCN switch that conveys the
called and calling phone numbers. Sigtran's SCTP carries the SS7 signalling from the SG to
the MGC.
Recommendation. The endpoints are found by the media gateway controller (MGC) and it
sets up the audio channel between the two media gateways and instructs the SS7 facility of
the receiving CO to connect to the end phone destination, which results in the generation of
ringing. So, to start, the controller determines that a connection needs to be made from
MG1 to MG2. The MGC creates a Context for the call. A TDM termination DS0/1/1, an
audio/RTP termination and an image/t38 termination are added to a new context in MG1.
Mode is ReceiveOnly since Remote descriptor values are not yet specified. Preferred
codecs are in the MGC's preferred order of choice. The MGC sets to CHOOSE (i.e., $) the
fields in the SDP in the Local descriptor that the MG will set itself. Also, in order for the
MGC to infer whether both gateways support the T.38 Autonomous Transitioning
method or the T.38 MGC Transitioning method, the MGC instructs MG1 to respond
with the values of both its audio RTP/AVP capabilities and its image/t38 capabilities.
Note that this is achieved by including in the LocalControl descriptor
"ReserveGroup=True" to ask the MG to reserve resources for both audio and image
media descriptors. In addition "ReserveValue=True" to ask the MG to reserve resources
for all the possible codecs offered in the media descriptor (alternatively an MGC may
include ReserveValue=false to ask for the most preferred codec; however, if omitted a MG
by default must set this value to false).
3)
MGC to MG1:
MEGACO/1.0 [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 $
v=0
c=IN IP4 $
m=image $ udptl t38
}; IP termination for audio
}
}
}
}
}
4)
94
MG1 acknowledges the new Termination and fills in the Local IP address and UDP port. It
also supports and can reserve resources for all the codecs offered in the list within the
media descriptor of the SDP block in Local, thus leaving the final choice of codec for the
remote gateway. MG1 sets the RTP port to 2222. Because the MG supports the T.38
ITU-T Rec. T.38 (09/2005)
Autonomous Transitioning method for transitioning between VoIP and FoIP; it also sets the
T.38 port to 4444 and includes the supported T.38 capabilities. If the MG did not support
autonomous transitioning between VoIP and FoIP; it would set the T.38 port to 0 or omit
the image media descriptor line altogether, and would proceed as indicated in III.2.1.
MEGACO/1.0 [124.124.124.222]:55555
Reply = 11 {
Context = 2000 {
Add = DS0/1/1, ; SCN termination added
Add = RTP/1 {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0 ; MG1 can reserve resources for both codecs
v=0
c=IN IP4 124.124.124.222
} ; IP termination added
}
}
}
}
}
5)
The MGC will now associate DS0/2/2 with a new Context on MG2, and establish an RTP
Stream (i.e., RTP/2 will be assigned) and T.38 stream SendReceive connections through to
the originating user, User 1. Also, because MG1 supports the T.38 Autonomous
Transitioning method, the MGC needs to find out whether the MG2 supports the T.38
Autonomous Transitioning method, for which the MGC will ask MG2 by including an
audio media descriptor and an image media descriptor with the ports set to $ in the Add
ephemeral of the create context message and including, in the LocalControl descriptor, the
property "ReserveGroup=True" to ask the MG to take both audio and image media
descriptors, as well as indicating that the remote MG supports the T.38 Autonomous
Transitioning method. Note that in addition the MGC includes ReserveValue=false to ask
for the most preferred Code.
MGC to MG2:
MEGACO/1.0 [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 $
v=0
c=IN IP4 $
m=image $ udptl t38
},
Remote {
ITU-T Rec. T.38 (09/2005)
95
v=0
c=IN IP4 124.124.124.222
v=0
c=IN IP4 124.124.124.222
} ; RTP profile for G.711 is 0
}
}
}
}
}
6)
This is acknowledged. Also, because MG2 supports the T.38 Autonomous Transitioning
method for transitioning between VoIP and FoIP, it includes in the SDP response both an
audio and an image media descriptor with valid port numbers. The RTP stream port number
is different from the Megaco/H.248 control port number. In this case it is 1111 (in the
SDP). The T.38 stream port number is different from the Megaco/H.248 control port
number. In this case it is 5555 (in the SDP). Also, from the remote SDP, MG2 knows that it
shall transition between VoIP and FoIP using the T.38 Autonomous Transitioning method.
If the remote SDP did not have both the audio and an image media descriptor, MG2 would
have defaulted to using the T.38 MGC Transitioning method for transitioning from an
audio/RTP connection to an image/t38 connection and the procedures in point 7 of III.2.1
follow. Also, MG2 chooses G.729 (payload type = 18) as the voice codec to use.
MG2 to MGC:
MEGACO/1.0 [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.111
v=0
c=IN IP4 125.125.125.111
}
}
}
}
}
}
7)
The above IPAddr and UDPport and voice codec need to be given to MG1 now. As well as
indicating that MG2 supports the T.38 Autonomous Transitioning method for transitioning
between VoIP & FoIP. Also apply ringing tone ringback to the DS0/1/1 termination and
change it to a SendReceive.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 12 {
Context = 2000 {
Modify = DS0/1/1 {
Signals {cg/rt} }, ;apply ringing tone
Modify = RTP/1 {
96
ITU-T Rec. T.38 (09/2005)
Media {
Stream = 1 {
LocalControl {Mode = SendReceive, ReserveGroup=True },
Remote {
v=0
c=IN IP4 125.125.125.111
v=0
c=IN IP4 125.125.125.111
}
}
}
}
}
}
from MG1 to MGC:

MEGACO/1.0 [124.124.124.222]:55555
Reply = 12 {
Context = 2000 {Modify = DS0/1/1, Modify = RTP/1}
}
8)
9)
10)
MG1 acknowledges, and shall use the T.38 Autonomous Transitioning method for
transitioning from audio/RTP connection to an image/t38 connection.
The calling fax machine typically will start to generate CNG calling tones. It is envisioned
that the first media gateway (MG1) will detect the CNG tone event and will determine that
a facsimile call is commencing. Hence, MG1 will switch to image/t38 mode, mute its
audio/RTP connection and transmit (via its image/t38 connection) to MG2 the T.38 CNG
indicator packet. MG2, on receipt of the T.38 CNG indicator packet, will transition to
image/t38 mode. This may be implemented such that receipt at its T.38 UDP port of a valid
IP/UDP packet whose source IP address corresponds to that of MG1 can be assumed to be a
T.38 packet causing a transition to T.38. Hence, on transition to image/t38 mode, this
packet will be decoded and analysed to be of type CNG, thus playing out the appropriate
CNG tone. In order to avoid any unwanted UDP packet arriving at the T.38 UDP port, this
port should be activated only if the T.38 Autonomous Transitioning method (and T.38
capabilities) was successfully negotiated before the call. From here on both MGs will
operate in accordance with this Recommendation. If there were no CNG tone, then MG1
would transition the T.38 on detection of a sufficient number of T.30 preamble flags (aka
the V.21 preamble flags) and send the corresponding T.38 V.21 preamble indicator packet.
Alternatively: If RFC 2833 telephone events is supported by both MGs (i.e., methods 2
and 3 described in E.2.2.2.2.1), and indicated either via SDP exchange or other mechanisms
beyond the scope of this Recommendation, then a MG1 may choose to send the
corresponding CNG, CED and V.21 preamble across the packet network as described
in E.2.2.2.2.1 and transition to T.38 only on detection of a sufficient number of V.21
preamble flags.
The MGs shall revert back to the audio/RTP connection (VoIP) based on detection of any
of the following:
a) Detection of a T.30 DCN message;
b) Detection of bidirectional silence. It is recommended to detect transition back to voice
mode on detection of more than 7 s of bidirectional silence to allow for the T.30 T2
timers (within the G3FEs) to time out;
c) Detection of voice;
d) Reception of a Modify command in which only an audio media descriptor is present.
ITU-T Rec. T.38 (09/2005)
97
III.2.4 Voice to fax call setup between H.248 and H.323 endpoints that support the
T.38 Autonomous Transitioning method
This facsimile-only call flow example (see Figure III.4) describes a facsimile call that originates in
the SCN and is terminated in the packet network. The packet network signalling in this example is
D.3/H.323 but other signalling protocols such as SIP can be used. The purpose of the example is to
describe MG/MGC interactions.
The assumption is made that the signalling between the signalling gateway (SGW) and MGC is
based on ITU-T Rec. Q.931. This does not indicate that no other signalling can be used on this
interface. Capabilities described here are generic line package descriptions (but could also be SDP
or H.245 messages).
The media gateway and the H.323 endpoint are configured for voice and fax. The purpose of the
example is to describe MG/MGC and H.323-endpoint/MGC interactions when operating in the
T.38 Autonomous mode including indication to use the T.38 Autonomous mode, the detection of
fax and switching from voice to fax.
98
ITU-T Rec. T.38 (09/2005)
G3FE
SCN
SGW
MGC
G3FE
H.323
GW
1- OFF HOOK
1- DIAL TONE
1- DIALLING
1- IAM
1- Q:SETUP
MG
3- CREATE CONTEXT
4- ACK
5- SETUP[fastStartG.711 PCMU, T.38]

6- Q:CALL PROC
7- Q:ALERTING [fastStartG.711 PCMU, T.38]
RINGING
9- Q:CONNECT[H:OLC]
OFF HOOK
SGW
8- Q:ALERT
RINGING
MG
10- MODIFY
SGW
11- Q:CONNECT
MG
12- ACK
Voice mode
CNG
Fax mode
T.38 CNG packet
T.38 CED packet
CED
T.38 V.21 packet
CNG
CED
V.21
V.21
T.38_FIII.4(APPIII)
Figure III.4/T.38 Voice to fax call setup with H.248 and H.323 endpoints that support
T.38 Autonomous Transition between VoIP and FoIP
ITU-T Rec. T.38 (09/2005)
99
1)
2)
3)
The SGW sends a Setup message to the MGC after receiving an IAM from a SCN switch.
Recommendation.
The MGC creates a Context for the call. The Context contains two terminations: one for the
SCN side and one for the packet side. The MGC sets to CHOOSE (i.e., $) the fields in the
SDP in the Local descriptor that the MG will set itself. Also, in order for the MGC to
infer whether MG1 supports the T.38 Autonomous Transitioning method or the T.38
MGC Transitioning method, the MGC instructs MG1 to respond with the values of
both its audio RTP/AVP capabilities and its image/t38 capabilities. Note that this is
achieved by including in the LocalControl descriptor "ReserveGroup=True" to ask
the MG to reserve resources for both audio and image media descriptors. In addition
the MGC may include ReserveValue=false to ask for the most preferred codec; however, if
omitted, an MG by default should set this value to false:
MGC to MG:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 11 {
Context = $ {
Add = DS0/1/1 {
Events = 1 { ctyp/dtone, fax/faxconnchange, al/of}
}, ; the SCN side termination listening for call type indicating tones
Add = $ {
Media {
Stream = 1 {
LocalControl { Mode = ReceiveOnly, ReserveGroup=True },
Local {
v=0
c=IN IP4 $
v=0
c=IN IP4 $
m=image $ udptl t38
} ; the IP side termination showing capability of RTP audio with PT 0
and 18.
}
}
}
}
}
4)
The MG accepts the Context creation and fills in the unknown ($) parameters. The MG
supports the T.38 Autonomous Transitioning method; hence, it includes the image media
line with an appropriate port number in the response and select G.729 as the preferred
codec:
MEGACO/1.0 [124.124.124.222]:55555
Reply = 11 {
Context = 2000 {
Add = DS0/1/1,; the SCN termination is accepted
Add = RTP/1 {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
v=0
c=IN IP4 124.124.124.222
100
ITU-T Rec. T.38 (09/2005)

} ; the IP RTP termination is accepted with audio payload type 0. Also,
the MG indicates that it supports the T.38 Autonomous Transitioning method for
transitioning between VoIP and FoIP.
}
}
}
}
}
This shows how the MG reports to the MGC what parameters it filled in.
5)
The MGC sends a Setup message to the destination endpoint, here assumed to be an
H.323 endpoint (terminal, GW, etc.). Also, because it knows that the MG supports the T.38
Autonomous Transitioning method, it indicates this in the fastStart element by the
capability of simultaneous support of at least one audio codec and of receiving and
transmitting T.38 FoIP.
6)
The H.323 endpoint sends a CallProceeding message followed by an Alerting message with
fastStart back to the MGC, informing it that it supports the T.38 Autonomous Transitioning
method by indicating its capability of simultaneous support of at least one audio codec and
of receiving and transmitting T.38 FoIP.
7)
The MGC sends an Alerting message to the SGW.
8)
The MGC sends a Modify command to the MG to set the mode and remote termination
description on the packet side.
9)
The called endpoint at some instance sends a Connect message to the MGC once the G3FE
goes off-hook. Note that this message contains both the audio and facsimile capabilities and
does not include an H.245 port.
10)
A Modify command is sent to the MG to change the mode of the SCN side termination to
SendRecv. The remote endpoints audio and fax capabilities are also included in this
command (this information was included in the Connect from the H.323 endpoint). This
also indicates that the remote endpoint supports the T.38 Autonomous Transitioning
method and that the call shall initially be set up as a voice call.
MGC to MG:
MEGACO/1.0 [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 },; the MGC requests the MG to send it
an event when it transitions to T.38.
Signals = {al/ri }
} ; modify SCN termination to reflect that we are connected through
Modify = RTP/1 {
Media {
TerminationState {ipfax/faxstate=Prepare,
ipfax/ipftrpt=T38UDPTL },
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
v=0
c=IN IP4 124.124.124.222
} ; modify media stream 1 to use image media, udptl transport for T38
ITU-T Rec. T.38 (09/2005)
101
LocalControl { Mode = SendReceive

}
}
},
Events = 2 { ipfax/faxconnchng }
}
}
}
11)
12)
The MGC sends a Connect message to the SGW to indicate the call is connected.
The MG accepts the Modify commands:
from MG to MGC:
MEGACO/1.0 [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
v=0
c=IN IP4 124.124.124.222
}; The fax udptl/t38 transport channel is accepted on the IP session and the
T.38 Autonomous Transitioning method shall be used for transitioning between VoIP
and FoIP
}
}
},
Modify = DS0/1/1
}; The modify is accepted on the DS0 session
}
At this point the call proceeds in voice mode between the gateways. The MGC knows from the
responses from both gateways that the T.38 Autonomous Transitioning method shall be used by
both gateways for transitioning between VoIP and FoIP. Likely, the originating G3FE would send a
CNG at which point the originating gateway will mute its audio/RTP port and transition to
FoIP mode and send over the IP network the corresponding T.38 T.30_Indicator (CNG) packet. If
no CNG tone was sent or detected, then the MGs would use the V.21 preamble as the transitioning
criteria. Because the destination gateway received the UDP packet at its UDP port that has been
assigned for T.38, it assumes that it is a T.38 packet and that it must transition to T.38 mode. From
here on both gateways will operate in accordance with this Recommendation.
Alternatively: If RFC 2833 telephone events is supported by both MGs (i.e., methods 2 and 3
described in E.2.2.2.2.1), and indicated either via SDP exchange or other mechanisms beyond the
scope of this Recommendation, then a MG1 may choose to send the corresponding CNG, CED and
V.21 preamble across the packet network as described in E.2.2.2.2.1 and transition to T.38 only on
detection of a sufficient number of V.21 preamble flags.
The gateways shall revert back to the audio/RTP connection (VoIP) based on detection of any of the
following:
Detection of a T.30 DCN message;
Detection of bidirectional silence. It is recommended to detect transition back to voice

mode on detection of more than 7 s of bidirectional silence to allow for the T.30 T2 timers
(within the G3FEs) to timeout.
102
ITU-T Rec. T.38 (09/2005)
Appendix IV
V.34 session examples
IV.1
V.34 session examples
This clause contains several examples of signal flow in a V.34 half-duplex fax session. In the
diagrams, the labels F1, G1, G2 and F2 are used as shorthand for emitting G3FE, emitting gateway,
receiving gateway and receiving G3FE, respectively.
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
CM
CM
JM
CM
JM
CJ
JM
INFO0c
INFO0a
JM
JM
CJ
JM
INFO0c
INFO0a
JM
T.38_FIV.1(APPIV)
Figure IV.1/T.38 V.8 signalling (using profiles and acks)
ITU-T Rec. T.38 (09/2005)
103
F1
G2
G1
F2
TRN
TRN
PPh
PPh
PPh
ALT
PPh
MPh
MPh
MPh
PPh
ALT
Flags
t30-data(v34-pri-rate:v34-rate:336)
MPh
MPh
MPh
MPh
E
DIS
t30-data(v34-CC-1200:HDLC (DIS octets))
t30-data(v34-CC-1200:HDLCFCS-OK-Sig-End)
AC
PPh
if G1 = G2 then okay. No rate

change needed.
If G1 < G2 then that too is okay
since source data arrives slower
than sink can send it.
If G1 > G2 then G1 rate needs to
be reduced since the source data
is faster than sink data.
ALT
MPh
MPh
MPh
MPh
Flags
DIS
DCS
Flags
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
"1s"
ALT
ALT
MPh
Flags
ALT
CFR
Flags
t30-indicator(v34-pri-channel)
CFR
Flags
Flags
"1s"
T.38_FIV.2(APPIV)
Figure IV.2/T.38 Data rate negotiation and control channel start-up
104
ITU-T Rec. T.38 (09/2005)
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
Flag
t30-indicator(v34-cntl-channel-1200)
Sh
Sh
Sh*
ALT
E
Flags
Sh
Sh*
ALT
ALT
E
FLAG
Flags
t30-data(v34-CC-1200:HDLC:PPS-NULL)
PPSNULL
t30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)
Flag
MCF
1s
Sh*
FLAG
PPSNULL
t30-data(v34-CC-1200:HDLC:MCF)
Sh
Sh*
ALT
E
Flag
MCF
FLAG
FLAG
1s
S
S*
PP
B1
S
S*
PP
B1
Flags
Flags
DATA
DATA
T.38_FIV.3(APPIV)
Figure IV.3/T.38 Between partial pages
ITU-T Rec. T.38 (09/2005)
105
G2
G1
F1
F2
t30-data(v34-pri-ch:HDLC:octets)
DATA
DATA
Flag
Sh
Sh
Sh*
ALT
Sh
Sh*
Sh*
ALT
ALT
Flag
PPSEOP
Flag
t30-data(v34-CC-1200:HDLC:PPS-EOP)
Flag
DCN
MCF
PPSEOP
ALT
E
Flag
MCF
Flag
t30-data(v34-CC-1200:HDLC:DCN)
FLAG
Sh*
Flag
Flag
Sh
Flag
DCN
Flag
1s
t30-data(v34-CC-1200:HDLC-Sig-End)
Flag
ls
T.38_FIV.4(APPIV)
Figure IV.4/T.38 Last page
106
ITU-T Rec. T.38 (09/2005)
F2 requests data rate change
F1
G1
G2
Primary
Channel
Data
Flags
ALT
E
Flags
Primary
Channel
Data
Flags
Sh
/Sh
F2
Sh
Sh
/Sh
/Sh
t30-indicator(v34-CC-retrain)
ALT
Flags
t30-data(v34-pri-rate:v34rate:288)
AC
ALT
PPh
ALT
MPh
MPh
MPh
MPh
E
PPSMPS
Flags
PPh
PPh
ALT
E
PPh
ALT
If F1/G1 Primary Channel data

signalling rate as indicated by
PCrate is > G2/F2 Primary
Channel data signalling rate, then
G1 changes its Rate Sequences
and initiates a Control Channel
retrain, while delaying
transmission of MPS-PPS.
ALT
MPh
MPh
MPh
E
MPh
E
Flags
Flags
t30-data(v34-CC-1200:HDLC:PPSMPS)
PPSMPS
MCF
Flags
MCF
Flags
Flags
"1s"
S
/S
PP
Flags
"1s"
S
/S
PP
T.38_FIV.5(APPIV)
Figure IV.5/T.38 Data rate change sequence when receiving G3FE initiates retraining
ITU-T Rec. T.38 (09/2005)
107
F1 requests data rate change
F1
G1
G2
Primary
Channel
Data
Flags
PPh
ALT
MPh
MPh
MPh
MPh
PPSMPS
Flags
For the situation where F1

requires a rate change, this can
be permitted as long as the rate
requested meets the
requirements as specified. The
G2/F2 pair are not required to
change rates.
Flags
MCF
"1s"
Primary
Channel
Data
Flags
PPh
ALT
F2
Flags
Sh
/Sh
ALT
Sh
/Sh
ALT
E
Flags
PPSMPS
Flags
MCF
Flags
Flags
"1s"
S
S
/S
/S
PP
PP
T.38_FIV.6(APPIV)
Figure IV.6/T.38 Data rate change sequence when calling G3FE initiates retraining
108
ITU-T Rec. T.38 (09/2005)
G2 requests data rate change
F1
G1
G2
Primary
Channel
Data
Flags
F2
Primary
Channel
Data
Flags
Sh
PPh
/Sh
ALT
Sh
E
Flags
PPh
ALT
ALT
/Sh
ALT
E
PPh
t30-indicator(v34-CC-retrain)
t30-data(v34-pri-rate:v34rate:264)
MPh
MPh
MPh
MPh
Flags
AC
PPh
ALT
MPh
MPh
MPh
MPh
PPSMPS
Flags
If F1/G1 Primary Channel data

signalling rate as indicated by
PCrate is > G2/F2 Primary
Channel data signalling rate, then
G1 changes its Rate Sequences
and initiates a Control Channel
retrain, while delaying
transmission of MPS-PPS.
Flags
Flags
PPSMPS
Flags
MCF
"1s"
ALT
Flags
t30-data(v34-CC-1200:HDLC:FCSOK-Sig-End)
MCF
Flags
Flags
"1s"
S
/S
PP
S
/S
PP
T.38_FIV.7(APPIV)
Figure IV.7/T.38 Data rate change sequence when receiving gateway initiates retraining
ITU-T Rec. T.38 (09/2005)
109
G1 requests data rate change
F1
G1
Primary
Channel
Data
G2
Flags
Primary
Channel
Data
Flags
Sh
/Sh
PPh
ALT
PPh
F2
For the situation where G1

requires a rate change, this can
be permitted as long as the rate
requested meets the
requirements as specified. The
G2/F2 pair are not required to
change rates.
ALT
Sh
/Sh
ALT
Sh
/Sh
ALT
ALT
MPh
MPh
MPh
MPh
E
E
PPSMPS
Flags
Flags
PPSMPS
Flags
MCF
"1s"
Flags
Flags
MCF
Flags
Flags
"1s"
/S
/S
PP
PP
T.38_FIV.8(APPIV)
Figure IV.8/T.38 Data rate change sequence when emitting gateway initiates retraining
110
ITU-T Rec. T.38 (09/2005)
F1
G1
G2
F2
DATA
DATA
Flags
Flags
Sh
Sh
Sh*
ALT
E
Sh
Sh*
Sh*
Sh
Sh*
ALT
ALT
E
ALT
E
t30-data(v34-CC-1200:HDLC:PPS-EOM)
PPSEOM
Flags
Flags
PPSEOM
Flags
MCF
Flags
MCF
Flags
DIS
t30-data(v34-CC-1200:HDLC:DIS)
Flags
t30-data(v34-CC-1200:HDLC:DTC)
DTC
Flags
Flags
DIS
Flags
t30-indicator(v8)
DTC
Flags
1s
1s
CM
CM
CM
CM
CM
CM
CM
CM
CJ
INFO0c
t30-data(v8:cm-message:FAP Prof 4)
JM
JM
JM
CM
CM
CM
CM
CJ
JM
JM
JM
INFO0c
INFO0a
INFO0a
T.38_FIV.9(APPIV)
Figure IV.9/T.38 Turn-around polling
ITU-T Rec. T.38 (09/2005)
111
F1
G1
F2
G2
ANSam
ANSam
t30-indicator(v21-preamble)
DIS
START
t30-data(v21:HDLC:DIS octets)
CNG
CNG
DIS
CNG
DIS
t30-data(v21:HDLC-FCS-OK-Sig-End)
CNG
DIS
CNG
CI
t30-data(v8:ci-message: Octet)
CI
CNG
CI
CI
CI
CI
CI
CI
CM
ANSam
CM
t30-data(v8:cm-message:FAP)
CM
CM
ANSam
CM
CM
CM
CM
CM
CM
CM
CM
CM
CM
CM
JM
JM
JM
JM
JM
CJ
INFO0c
CM
CJ
JM
INFO0c
INFO0a
INFO0a
T.38_FIV.10(APPIV)
Figure IV.10/T.38 Manual Transmit (DIS has bit 6 set to 1 to indicate V.8 capability)
112
ITU-T Rec. T.38 (09/2005)
F1
G2
G1
F2
CNG
START
CNG
CNG
No Answer Tone
(optional)
CNG
CNG
CNG
CNG
CNG
DIS
CNG
CNG
CNG
DIS
DIS
CNG
DIS
CNG
CI
t30-data (v8:ci-message:octet)
CI
CNG
CI
CI
CI
CI
CI
CI
CM
CM
ANSam
t30-data (v8:cm-message:FAP)
CM
CM
ANSam
CM
CM
CM
CM
CM
CM
CM
CM
CM
CM
CM
CJ
INFO0c
JM
JM
JM
CM
CJ
JM
INFO0c
INFO0a
JM
JM
INFO0a
T.38_FIV.11(APPIV)
Figure IV.11/T.38 Manual Receive (DIS has bit 6 set to 1 to indicate V.8 capability)
ITU-T Rec. T.38 (09/2005)
113
Appendix V
T.38 Implementation Guidelines
This appendix provides guidance for implementers to improve interoperability amongst T.38
devices, based on experience gained with actual implementations of the T.38 specification.
V.1
General issue
V.1.1
Transmission bit order
The transmission bit order complies with 7.1.1 and 7.1.2. As an example, DIS frame starts with
"7E FF C8 01 ":
7E
FF
C8
01
01111110 11111111 11001000 00000001

B
E B
E B
E B
'B' means "beginning" and 'E' means "end" in each octet. 'B' bit is first stored in an octet of
IP packet and is first transmitted.
V.1.2
Interval between packets
An interval between a preamble packet and a T.30 signal packet, and an interval between a training
packet and an image packet, may be necessary for some gateway implementations, because they do
not have enough buffers for dealing with multiple packets. When multiple T.30 signals like CSI and
DIS are sent, an interval between the signals may be necessary for some gateway implementations
for the same reason.
In addition, when packets are sent to gateway, they should be sent at the negotiated modem speed in
DIS/DCS exchange. IAF implementations may be particularly prone to this problem because there
is no fax terminal connected to GSTN where the modem limits the rate at which packets can be
created.
V.1.3
Preamble packet between T.30 signals
Some implementations incorrectly send a preamble packet between T.30 signal packets. A T.38
implementation that receives a sequence of this type, should handle it properly. For example, the
received preamble packet before "sig-end" in field-type should be regarded as flag (0x7e).
V.1.4
Disassembly of one signal in packet
Some implementations send one T.30 signal frame in one packet and other implementations send it
in multiple packets. Therefore, a T.38 implementation should handle both situations and assemble
the multiple packets when necessary. This principle applies to image packets as well. Some
implementations place an entire HDLC frame (between flags) into a single packet, others may
ignore the frame boundaries when inserting the data into packets.
V.1.5
Limitation of packet size
Some implementations limit the packet size to receive even in tcp mode. The limitation often
relates to the size of one ECM packet. It is the responsibility of the sender to address this situation.
One possibility is to use the same packet size regardless of whether the transport protocol is tcp or
udp and regardless of whether the remote side is an IAF or a gateway.
114
ITU-T Rec. T.38 (09/2005)
In udp mode, the t38FaxMaxDatagram value negotiated in call-setup, should be used to determine
the size of the packets.
V.1.6
Packet of Transferred TCF
A series of ZEROs for 1.5 s must be sent in one or more packets in transferred TCF, based on the
negotiated modem speed in DIS/DCS exchange. An IAF sender must generate the TCF if the
receiving T.38 devices is not an IAF.
V.2
IAF issues
V.2.1
T.30 Timer value
When both implementations are IAFs, T.30 timer values may be extended by two or three times.
Extension of the timers allows two terminals to have successful facsimile transactions in certain
difficult environments. These environments include narrow-band transports or when there is a high
degree of network delay and/or loss of packets. Bit 123 in DIS/DCS is the negotiation bit that
indicates an IAF device.
V.2.2
The data rate between IAFs
When TCP is selected, the data rate between IAFs is not limited by modem speeds indicated in
DIS/DTC (see 8.1) and can be as fast a rate as both sides can support. TCP allows both sides to
ignore the MaxBitRate attribute and rely on the protocol itself to throttle the data transfer between
the two IAFs.
V.2.3
Data rate between IAFs and gateways
If a gateway does not support TCP, an IAF shall send data so as to not cause a buffer overflow in
the receiving gateway. A potential problem arises because the messages and data are sent without
HDLC framing (insertion of FLAGs and ZEROs) and an IAF is not limited by a fax modem in the
speed that it can generate messages and data. The likely effect of this problem for image data is one
or more ECM frames in error.
The sending IAF should send packets that, by some means, account for the overhead due to the
HDLC framing that is added by the receiving gateway, so as to not overflow the gateway's buffer.
V.3
Call-setup issues
V.3.1
CalledPartyNumber in Setup (Annex B)
The destination fax number should be set in CalledPartyNumber of Setup. Some receiving gateways
have several fax ports and use the information to select one.
V.3.2
Announcement of voice capability
H.323 gateway implementations generally support voice communication as the default and initial
call type. When a T.38 Annex B implementation calls an H.323 Annex D implementation, the T.38
implementation may need to indicate voice capability in call setup, even if it wants only fax
communication.
V.3.3
Incorrect use of the colon (":") in several T.38 attributes in Annex D
Some equipment vendors have incorrectly implemented the ABNF as defined in Annex D for
several
parameters:
T38FaxFillBit
Removal,
T38FaxTranscodingMMR,
and
T38FaxTranscodingJBIG. These implementers have made incorrect use of the colon (":").
Implementers should avoid this mistake, and make their implementations robust by interpreting ":1"
as support for the attribute, and ":0" as not supporting the attribute.
The correct behaviour of these parameters is defined in D.2.3.1 and D.2.3.2.
ITU-T Rec. T.38 (09/2005)
115
V.3.4
Case sensitivity of udptl and T38MaxBitRate in SIP and H.248.1
There are case differences between the T.38 and IANA definitions of updtl (UDPTL) and
T38MaxBitRate (T38maxBitRate) for SIP and H.248.1. The preferred implementation is the
T.38 definitions, namely udptl and T38MaxBitRate.
116
ITU-T Rec. T.38 (09/2005)
SERIES OF ITU-T RECOMMENDATIONS

Series A
Organization of the work of ITU-T
Series D
General tariff principles
Series E
Overall network operation, telephone service, service operation and human factors
Series F
Non-telephone telecommunication services
Series G
Transmission systems and media, digital systems and networks
Series H
Audiovisual and multimedia systems
Series I
Integrated services digital network
Series J
Cable networks and transmission of television, sound programme and other multimedia signals
Series K
Protection against interference
Series L
Construction, installation and protection of cables and other elements of outside plant
Series M
Telecommunication management, including TMN and network maintenance
Series N
Maintenance: international sound programme and television transmission circuits
Series O
Specifications of measuring equipment
Series P
Telephone transmission quality, telephone installations, local line networks
Series Q
Switching and signalling
Series R
Telegraph transmission
Series S
Telegraph services terminal equipment
Series T
Terminals for telematic services
Series U
Telegraph switching
Series V
Data communication over the telephone network
Series X
Data networks, open system communications and security
Series Y
Global information infrastructure, Internet protocol aspects and next-generation networks
Series Z
Languages and general software aspects for telecommunication systems
Printed in Switzerland
Geneva, 2006

Itu-T: Procedures For Real-Time Group 3 Facsimile Communication Over IP Networks

Uploaded by

Copyright:

Available Formats

Itu-T: Procedures For Real-Time Group 3 Facsimile Communication Over IP Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Itu-T: Procedures For Real-Time Group 3 Facsimile Communication Over IP Networks

Uploaded by

Copyright:

Available Formats

I n t e r n a t i o n a l

SERIES T: TERMINALS FOR TELEMATIC SERVICES

Procedures for real-time Group 3 facsimile

ITU-T Recommendation T.38

ITU-T Recommendation T.38

ITU-T Rec. T.38 (09/2005)

INTELLECTUAL PROPERTY RIGHTS

ITU-T Rec. T.38 (09/2005)

Communication between gateways ..............................................................................

IFT protocol definition and procedures ........................................................................

IFP message flow for facsimile modulations up to V.17..............................................

IFT over UDP transport ................................................................................................

Annex A ASN.1 notation ......................................................................................................

Annex B H.323 call establishment procedures .....................................................................

Annex C The optional forward error correction scheme for UDPTL...................................

Annex D SIP/SDP call establishment procedures ................................................................

ITU-T Rec. T.38 (09/2005)

Communication between gateways ................................................................

Annex E H.248.1 call establishment procedures ..................................................................

Annex F Interworking procedures: T.38 and V.150.1 in the same gateway.........................

Annex G H.245 Capability Definition for T.38 over RTP....................................................

Appendix I Session examples ...............................................................................................

Appendix II Examples of call establishment procedures described in Annex B/T.38 ..........

Appendix IV V.34 session examples ....................................................................................

Appendix V T.38 Implementation Guidelines ......................................................................

ITU-T Rec. T.38 (09/2005)

ITU-T Recommendation T.38

ITU-T Recommendation H.248.1 (2005), Gateway control protocol, Version 3.

ITU-T Recommendation H.248.2 (2005), Gateway control protocol: Facsimile, text

ITU-T Recommendation H.323 (2003), Packet-based multimedia communications systems.

ITU-T Recommendation T.4 (2003), Standardization of Group 3 facsimile terminals for

ITU-T Recommendation T.30 (2005), Procedures for document facsimile transmission in

ITU-T Recommendation V.34 (1998), A modem operating at data signalling rates of up to

ITU-T Recommendation V.150.1 (2003), Modem-over-IP networks: Procedures for the

ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology

ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002, Information technology

IETF RFC 768 (1980), User Datagram Protocol.

IETF RFC 2327 (1998), SDP: Session Description Protocol.

IETF RFC 2543 (1999), SIP: Session Initiation Protocol.

This Recommendation uses the following abbreviations:

amplitude-modulated ANSwer tone

Call Indicator (signal)

Call Menu (signal)

Call Menu terminator (signal)

Error Correction Mode

Forward Error Correction

Internet-Aware Fax device

Internet Facsimile Protocol

Internet Facsimile Transfer

Half duplex INFO sequence

Joint Menu (signal)

ITU-T Rec. T.38 (09/2005)

Least Significant Bit

V.34 half-duplex Modulation Parameter sequence

Most Significant Bit

Open Logical Channel

Real Time Protocol

Real Time Control Protocol

Transmission Control Protocol