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