One document matched: draft-ietf-fax-ipfax-00.txt

                               
                               
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.