Fax Working Group                                       Herman R. Silbiger
Internet-Draft                                          Rapporteur, ITU-T Q.4/8
Expiration <5/98>                                       November 21, 1997


<draft-ietf-fax-ipfax-00.txt>

PROCEDURES  FOR REAL TIME GROUP 3 FACSIMILE COMMUNICATION BETWEEN
TERMINALS USING IP NETWORKS



STATUS OF THIS MEMO

This  document  is  an  Internet-Draft.   Internet-Drafts  are working
documents  of  the Internet  Engineering  Task  Force (IETF),  its
areas, and its working groups.  Note  that  other groups  may  also
distribute working documents  as  Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and  may be updated, replaced, or obsoleted  by  other documents  at any
time.  It is inappropriate to use  Internet- Drafts  as  reference
material or to cite them other  than  as "work in progress."

To  learn  the  current  status of any Internet-Draft,  please check
the  ``1id-abstracts.txt''  listing  contained  in  the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe),   munnari.oz.au   (Pacific    Rim), ds.internic.net  (US  East
Coast),  or  ftp.isi.edu  (US  West Coast).

NOTE:   The distribution of this document to the  IETF Fax WG  was
authorized by  Study  Group  8. The information herein is made available
for  use  by  the Fax  WG.  Some of the tables and figures have been
modified or removed to allow for publication in the Internet-Draft
format. The material is copyright (c) ITU-T and  is  not for further
publication.

This   document  is  based  on  a revision of draft T.Ifax2 which was
determined at the October, 1997  meeting  of ITU-T  Study  Group  8
as a candidate for approval in June 1998.  This version implements some
but not all of the amendments authorized by the Study Group and is subject
to further minor amendments.


1. Scope

This Internet Draft defines the procedures  to be applied to allow Group
3 facsimile transmission between terminals where in addition to the GSTN
or ISDN a portion of the transmission path used between terminals
includes an IP network, e.g. the Internet.

3. Terminology

ACK - Acknowledgment

ECM - Error Correction Mode

Emitting gateway (Onramp) - The IFP peer which initiates IFT service for
a calling G3FE. It initiates a TCP or UDP connection to an Receiving
gateway to begin an IFT session.

G3FE - G3 Facsimile Equipment.  In this document, G3FE refers to any
entity which presents a communications interface conforming to
Recommendation 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

IFP - Internet Facsimile Protocol.

IFT - Internet Facsimile Transfer

IP - Internet Protocol

LSB - Least Significant Bit

MSB - Most Significant Bit

Receiving gateway (Offramp)- The IFP peer which accepts a TCP or UDP
connection from an Emitting gateway, providing IFT service to a called
G3FE.

RTP - Real Time Protocol

TCP - Transmission Control Protocol

UDP - User Datagram Protocol

SUB - Subaddress

4. 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 Internet Draft specifies the messages and
data exchanged between facsimile gateways connected via an IP network.
The reference model for this Internet Draft is 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
receiving Group 3 facsimile equipment.  Once the PSTN calls are
established on both ends, the two Group 3 terminals are virtually
linked.  All T.30 session establishment and capabilities negotiation is
carried out between the terminals. The gateway local to each terminal
generates TCF for training and the gateways use data rate management 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
Internet Draft 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 Internet Draft.
The protocol defined in this Internet Draft 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.ifax requirements.
Good image quality is provided by error control in the network in
addition to the means provided by the Rec. T.30 protocol.

Reliable data transport is provided for two cases: TCP for general
purpose IP networks such as the Internet, and a protocol defined in this
document for reliable operation in applications using RTP, for example
in the H.323 environment. The H.323 environment is being used to support
voice transmission over IP as an alternate to the PSTN.   Since
facsimile generally uses the same facilities as voice communications it
is therefore reasonable to utilize the H.323 environment when
implementing facsimile over IP.

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 Internet Draft 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 GSTN numbers
to IP addresses when require), 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 Email.

In addition, user interface aspects, such as the way that the facsimile
operator selects the GSTN 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 ITU-T
Recommendations. Specifically, H.323/H.225 and the Gatekeeper
Recommendations address some of the above mentioned dependencies.

It is intended that all procedures in this Internet Draft conform to the
requirements of the draft Rec. F.ifax.

The main body of this document 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 Annex A.

5. Communication between gateways

5.1 Internet Protocol - TCP vs. UDP
The public Internet 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.

In addition, a UDP implementation may additionally use the RTP (Real
Time Protocol) protocols
This Internet Draft allows the use of either TCP or UDP depending on the
service environment.
5.2 Gateway 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, UDP or RTP/UDP in an H.323 environment).
The following signals are not transferred between gateways but are
generated or handled locally between the gateway and the G3FE:  CNG,
CED, PIN, PIP, and TCF.  Information in other frames related directly to
these frames may be altered by the gateway.

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.

The facsimile data transfer structure is described in section 6.2.  The
flow between gateways is described in section 7.

5.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.

6. IFT Protocol Definition and Procedures

6. 1 General
This section  contains the IFT protocol specification and provides
general information for the IFT protocol.

6.1.1 Bit and Octet Transmission Order

Transmission order is as defined in Internet RFC 791 "INTERNET PROTOCOL

6.1.2 Mapping of 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 most significant bit (MSB) of the first octet., where the
MSB is defined as in Section 6.1.1.

6.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, multiple
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 port [TBD]. All
communication between IFP Peers is done using packets.

The following table summarizes the IFP packet elements (for full
explanation refer to the following sections):

IFP packet elements

Field           Description                              Length
--------------------------------------------------------------------
SOM             Unique prefix to define start of message 1 octet
--------------------------------------------------------------------
SEQ-NUM         Sequence Number                          2 octets
--------------------------------------------------------------------
TYPE            Type of message                          1 octet
---------------------------------------------------------------------
C               Chaining bit                             2 octets
---------------------------------------------------------------------
LEN             Length of DATA element
---------------------------------------------------------------------
DATA            Dependend on TYPE                        Value of LEN


6.2.1 SOM (Start Of Message)

The SOM element provides an alert for the start of a message. It is used
by the IFP peer to verify message alignment. It is one octet long, and
always set to 0x24 (T.51 '$'). When data is read by the peer from its
TCP/IP or UDP/IP stack, and the expected SOM element does not contain
the SOM value, the session should be immediately aborted by the
receiver.

6.2.2 LENGTH

The LENGTH element of the packet is 2 octets wide and specifies the
number of octets which are included in the DATA element of the packet.
The most significant bit of the LENGTH element is called the CHAIN bit,
and is used to indicate if this packet contains partial information, or
it ends the IFP message.
If the most significant bit is set to B'0', then this packet is the last
packet of this message and the packet ends.
If the most significant bit is set to B'1', then the message is not
complete and continues into the next packet.

6.2.3 SEQ-NUM

The SEQ-NUM element of the packet is 2 octets wide and specifies the
sequence number of the packet being sent. Each peer counts its own
packets, starting with 0x0001.

6.2.4 TYPE

The TYPE element of the packet is 1 octet wide. The legitimate values
for TYPE are given in the table below. Each TYPE is separately explained
in the following sections.
If the TYPE element is not recognized, it and the related data element
shall be ignored.

6.2.5 DATA

The DATA element of the packet occupies the number of octets given in
the LENGTH field.  Content depends on the value of the TYPE element.

There are two types of DATA elements.
* Regular Data Element - The DATA element has no internal structure
* Field based Data Elements - Where the DATA element contains internal
fields.

When a field type DATA element is received, the receiver should analyze
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 should be skipped, and the receiver should continue with the next
field.

The IFP peer may elect to send the message data in several packets. The
CHAIN bit of the LENGTH element shall be used for this purpose. Note
that for each packet sent, the whole header is repeated - except for the
sequence number which is incremented - and the LENGTH element indicates
the length of the DATA element in that packet.

6.3 Packet Command Types - IFP Controls and T.30 Data

The following sections describe the structure of each packet type. Some
of the packets use the field based DATA element.

6.3.1 T30_ INDICATOR

The T30_ INDICATOR TYPE has the value of 0x63. It is sent by the
Receiving gateway to the Emitting gateway, and by the Emitting gateway
to the Receiving gateway with a special signals or indication of
preamble flags or modulation type.

The use of this message is optional. A peer may be sending this message
in order to pre-notify its peer about upcoming messages.

The DATA element includes one octet specifying the signal or indication.

6.3.2 T30_HDLC_CONTROL

The T30_HDLC_CONTROL TYPE has the value of 0x66. It is sent by the
Receiving gateway to the Emitting gateway, and by the Emitting gateway
to the Receiving gateway with a T.30 command

This packet uses  a field type DATA element and may contain  one or more
fields.

The ability to send partial IFP messages is very useful because of  the
relatively long time it takes for a low speed (e.g. V.21)  HDLC frame to
be received by the gateway. With the chaining option, the original HDLC
message can be divided into several IFP packets, instead of being sent
in  a single IFP packet.

6.3.3 T30_ DATA

The T30_ DATA command has the TYPE value of 0x68. It is sent by the
Emitting gateway to the Receiving gateway with any Phase C data (T.4/T.6
or other). 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.  A message with zero length
data field may be sent to indicate, as early as possible, that T30_DATA
messages are coming.  Alternately, a T30_Indicator signal for High Speed
could be sent.  Implementations shall support both methods.
This packet uses a field type DATA element.

6.3.4 DISCONNECT

The DISCONNECT command has the TYPE value of 0x69. It may be sent by
either the Emitting gateway or the Receiving gateway peers, at any stage
to indicate a failure in the PSTN connection that requires the
termination of the IFT session.

The packet uses a Regular type  DATA element.
The DATA element consists of one octet specifying the disconnection
reason. The following values are defined:

Value   Meaning
-----------------------------------------------
0x00            Normal and proper end of connection
-----------------------------------------------
0x01            Connection aborted
-----------------------------------------------
0x02            T.30 timer expiration
-----------------------------------------------
0x03            T.30 negotiation failure
-----------------------------------------------
0x04            T.30 training failure
-----------------------------------------------
0x05            Incompatible capabilities
-----------------------------------------------
0x06            Communication failure
-----------------------------------------------
0x07            Device is unresponsive
-----------------------------------------------
0x08            T.30 protocol violation
-----------------------------------------------
0x09 - 0xff Reserved
-----------------------------------------------

6.4 IFP Fields

6.4.1 HDLC Data (field Type 0x21)

This mandatory field carries  T.30 HDLC data.

The length of the field is variable.

The data part of the field contains HDLC data. The HDLC data that is
sent in this field is T.30 HDLC data starting with the address field of
the HDLC frame up to and not including FCS.  Bit stuffing is removed
from all data. The end of a frame is indicated by the FCS Indicator
field.  The gateway is responsible for bit stuffing, FCS generation, and
separating frames with one or more flags (0x7E) when sending the HDLC
data to a G3FE. IFP Packets which carry HDLC Data may carry a single
HDLC field with a partial sequence, a complete sequence, or multiple
HDLC Data fields. The chain bit indicates the end of the last frame.

6.4.2 FCS Indicator (field Type 0x22)

This field indicates 1) the end of an HDLC frame, and 2) whether the
gateway detected an FCS error in that frame.

The length of the field is 1.

The data octet of the field contains a 0 if the FCS was good, and a 1 if
the FCS was bad.

7. IFP Message flow

The gateways follow the T.30 message flow and uses the packet format in
section 6 to transmit these messages.

Due to the fact that TCF is generated locally, data rate management is
required in order for both facsimile sessions to be conducted at the
same speed.

7.1 Data rate management

When a CFR (Confirmation to receive) or an FTT (failure to train) is
received from a G3 facsimile equipment at a receiving gateway, a T.30
HDLC packet (indicating CFR or FTT respectively) should be forwarded to
an emitting gateway.

According to the result of a TCF received from a G3 facsimile equipment
and the T.30 HDLC packet (CFR or FTT) forwarded from a receiving
gateway, an emitting gateway transmits FTT or CFR according to a
decision table.

8. Usage of Transport Protocols

8.1 Transport using TCP or UDP in a standalone environment

The IFT protocol may use either UDP or TCP transport protocols without
any adjustment.

8.2 Transport using RTP/UDP in H.323 environment

When using RTP/UDP frames are to be transported over the IP network
using the RTP protocol described in ITU-T Recommendation H.225.0 Annex
A. RTP is based upon the principles of application level framing.
"Framing" is essentially the imposition of some format on the payload
section of the RTP protocol. In order to provide support for handling
network errors, framing has been made a two-stage process when using
RTP/UDP. A high level protocol describes how the RTP payload section is
a "super-frame" composed of a series of facsimile protocol frames.

8.2.1 RTP payload format for facsimile transfer

The RTP payload is used to convey the demodulated facsimile data over
the IP network. It is composed of one or more facsimile protocol frames
The first octet in the RTP payload is used to identify the total number
of frames that are carried within the current packet. Note that this
number, n, will always be one or greater. Thereafter, a series of n
octet-aligned frames are observed. These protocol units comprise two
parts: a two octet frame payload length specifier (in units of octets),
and a frame payload section. Note that the length of the frame payload
will be the value specified in the frame length field. Figure 4
illustrates the formatting of the RTP payload into frames.

Frames are used to associate a set of demodulated facsimile signals with
an arbitrary time period. For instance, a facsimile-demodulator may
provide output every 30 ms to the application responsible for IP network
transmissions. This output would therefore represent 30 ms of facsimile
data from a G3FE. The capacity for transmitting multiple frames has been
included to allow data from previous time slots to be resent, thereby
providing a degree of redundancy and robustness in the presence of
packet loss over the IP network. If redundant information is to be
transmitted in this way, the first frame must always represent the
current time-slot with successive frames containing successively "older"
data sets. Because frames contain no indication of the actual time slot
from which they originated, if it is desired to transmit a frame
containing data from two time slots prior to the current slot, all
frames after this must also be transmitted in the packet.

9. Call establishment procedures

9.1. Communication between  facsimile terminal and gateway

Communication between a sending Group 3 facsimile terminal and the
incoming gateway is generally effected using dialup procedures over the
GSTN. 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 GSTN 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.

9.2. Transfer of addressing information

9.2.1 From calling terminal to gateway

The conveyance of the Rec. 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 dialing; or by any other suitable
means.

9.2.2 Between gateways

The destination terminal's E.164 address shall be passed from the
emitting gateway to the receiving gateway via a method consistent with
the underlying transport protocol.  When using RTP/UDP, Rec. H.323
defines signaling for this purpose and it should be used.  When using
TCP the required information is transmitted between gateways by packets
defined for this purpose.

9.2.3 Call information packets

Call information packets are passed between the gateways by means of the
IFP when an external call control channel is not provided.  The
information is otherwise to be conveyed by the H.323 control channel.

9.2.3.1 CALL_REQ

The CALL_REQ command has the TYPE value of 0x64. It is sent from the
Emitting gateway to the Receiving gateway to indicate the setup of a new
call, with the details such as telephone number which the originating
facsimile user wishes to contact.

CALL_REQ is a field based DATA element.

Any of the following fields, in any order may be included in the DATA
field:
Protocol Version                                        - Mandatory
Phone Number (called E.164 GSTN Number)         - Optional
Caller Information                              - Optional
Vendor and Product Information          - Optional

Note:  The information contained in these fields is provided by the
gateway or IAF.

9.3.2 CALL-PROGRESS

The CALL_PROGRESS command has the TYPE value of 0x70. The Receiving
gateway may relay the status of the call made by the Receiving gateway
to the destination G3FE.

The DATA element is a regular type which consists of one or two octets
specifying the call progress value.   The ISDN results are reported in
two octets, the first being the value identifying it as a BRI result,
and the second being the ISDN cause code.   All other results consist of
a single octet.

9.4 Call information field definitions

9.4.1 Destination terminal address (field Type 0x01)

This optional field specifies the E.164 address of the destination G3FE.

The length of the field is variable.

The data part of the field contains the E.164 number to be dialed
represented as a T.51 string.

9.4.2 Private use information (field Type 0x11)

This optional field identifies the IFP peer.

The length of the field is variable.

The data part of the field contains an T.51 string with any information
about the vendor, product, version of the IFP peer.

9.4.3 Protocol version (field Type 0x12)

This mandatory field identifies the IFP peer.

The length of the field is 4 octets.

The data part of the field contains an T.51 character string with the
protocol version in the format VVRR (VV - Version, RR- Release). This
protocol version is '0101' (version 1, release 1)

9.4.4 Caller Information (field Type 0x02)

This field identifies the calling facsimile terminal.

The length of the field is variable.

The data part of the field contains any T.51 character string with an ID
of the caller. This information may be used to identify the user of the
service, collect CDR information about the call or any other
implementation dependent use.


10. 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 referenced
Standards are subject to revision; all users of this Recommendation are
therefore encouraged to investigate the possibility of applying the most
recent editions of the Recommendations and other references listed
below.  A list of currently valid ITU-T Recommendations is regularly
published.

IETF RFC768 - User Datagram Protocol

IETF RFC791 - Internet Protocol

IETF RFC793 - Transmission Control Protocol

IETF RFC1889 - Real Time Protocol

ITU-T Recommendation E.164 (1991) - Numbering Plan for the ISDN Era

ITU-T Vol. II, Supplement No. 2, - Various Tones Used in National
Networks

ITU-T Recommendation E.182 (Blue Book) - Application of Tones and
Recorded Announcements in Telephone Services

ITU-T Recommendation Q.35 (Blue Book) - Technical Characteristics of
Tones for the Telephone Service

ITU-T Draft Recommendation F.Ifax - Internet facsimile: operations and
definition of service

ITU Rec. H.323 (1996) - Visual telephone systems and equipment for local
area networks which provide a non-guaranteed quality of service

ITU Rec. T.4 (1997): Standardization of Group 3 Facsimile apparatus for
document transmission

ITU Recommendation T.6 (1996) - Facsimile Coding Schemes and Coding
Control Functions For Group 4 Facsimile Apparatus

ITU Rec. T.30 (1996): Procedures for document facsimile transmission in
the General Switched Telephone Network

ITU Recommendation T.51 (Blue Book) - Coded Character Sets For Telematic
Services.