Technical Information

By providing this technical information page, you can know more about our programs. Also, you can develop your own application programs base on the provided information. However, we cannot guarantee that the information matches the most updated program because we keep enhancing our programs. If you are interested in developing customized applications, feel free to contact us and we are glad to give you all the information we have.

Internet Fax Transmission Protocol used in our program:

Use TCP port 108 in this version

Font used:

Bold -- The command Server or Client send
Bold + Italic
-- May change in different implementations
Bold + Underline
-- should fill in correct content
Blue commands indicate that the command is the last command. Server or client will close the connection after it sends/receives this command.
CRLF is ASCII 13 10
Content in different lines implies a CRLF between each line.

The client or server may close the connection to abort the transmission.  However, if you client close the connection after server receives enough information, then the transmission will not be aborted.

Client Server Comment
  Action Server 1.00  
UFOFax 1.0
  Client send "FAX"+CRLF+"UFOFax 1.0"

"UFOFax 1.0" is the program version (or a hello message), it may change in the future.

In the future, we may have a newer version of protocol, the first string "FAX" will be changed.

Server may disconnect to refuse this connection.

  UFOFax 1.0
Version OK


UFOFax 1.0
Fail reason

"UFOFax 1.0" is the program version (or a hello message), it would change in the future. If the server decides not to accept this connection, it can reply an error reason (for example, bad from IP or Version Fail) to the client.

The client will continue the protocol only if it receives a reply "Version OK"

Version OK


Fail Reason

  The client program can decide whether to continue or not.

The server will continue the protocol only if it receives a reply "Version OK".

Telephone number
  Password is a string. In this version, we use the format "username:password" to identify the sender. Use "guest:guest" for testing purpose, our program will have a default account unless the manager delete this account.

"reserved" is a string for supplemental information. In this version, it is the filename.

Telephone number is the destination number. Since the fax file format contains the destination fax number, you may set this number to an empty string if you don't want an immediately fax out.



Fail reason

Server reply OK or a fail reason.
(Client sends the fax file)
[4 bytes length] [file content in binary format]
  4 bytes length in little endie form

The file content is in the "*.ref" format, please click here for the detail.

Server may close the connection if the file is too long or timeout. Server can also disconnect after it receives the header of the REF stream.

  Fax Out Start


Accept OK (then close the connection, client doesn't need to reply anything.)


In Busy(capture the file but
modem is busy)



Hide Status

  Client replies "Status" if it wants to receive a periodical status code.

Otherwise, the client should reply "Hide Status"

  (Under Fax Out Start mode, the server will send status report to the client periodically)

Status ID (a number in ASCII format)

Status ID :0-100 is the percentage.
1000 - 9999 is status code, please click here to see the map. You can also create a mapping INI file to localize these messages.



  Client replies "Status" for acknowledgement.

Or, it can send "Stop" to stop the fax transmission.

  Fax Out End (and close the connection


Fax Out Fail

The client will reply only if the Fax is not successful!
OK (and close the connection)



  Accept OK (and close the connection) When the client replies "Save", the server will save this fax to its output folder, and will try to send it out later. Server will reply "Accept OK" in this case.

Status code definition

4801=Initializing modem
4803=Busy, Fax Transmit is waiting
4804=Sending document page data
4805=Send EOP
4806=Error sending page
4807=Page accepted by remote
4808=Send call handoff connecting
4840=Getting connection params
4841=got called-station ID
4842=User abort
4843=Finished with this fax

REF file format:

REF (Rising Edge Fax or REFerence) file is an enhanced fax file which includes the fax images and related job information about that fax. If you want to view an REF file, your have to use InterFax at this time.

Normally, REF files are internally used by our programs. However, you'll need to know its format if you are going to write a program which can communicate with our programs.

REF file is a wrapper (or container) of any possible E-Fax file. So, it contains two parts -- header and content. Most likely, the content is just the content of an APF file. However, you can put a WORD file (*.doc) or ZIP file into an REF file. REF does not assume anything about the enclosed content -- it just provide more related fax job information, and the receiver should decide whether to accept or reject this file.

An REF file consists of two parts -- header and content, and the header consists of three parts -- fixed length header, variable length header, and extra properties.

Fixed Length header (also named "Base Header", size=8 bytes)
All integers are in Intel byte order (low byte first)


field name field type/size comment
0 Signature string[4]; (4 bytes) REFT
4 Version word (2 bytes) 100
6 HeaderSize word (2 bytes) The total length of the header -- fixed length header, variable length header, and extra properties. It does not include the content's size.

Variable length header (minimum size is 26)

StringZ means a string with a terminating zero. So, an empty string occupies one byte. StringZ has no length limit, however, the total header size has a length limit of 65535.
StringL means a string with a "one-byte length" before the actual data. An empty string also occupies one byte. However, StringL has a length limit of 255. StringL is used for strings which may contain Null (ASCII 0).

No all fields in variable length header are used in all the cases. However, it won't hurt if we put some useless information in  "variable length header" -- the size of the header is still very small.



from IP



Friendly name of fax job



Name of sender



Name of receiver



Password (might be encoded)



Area code is a mask id for interfax to get a valid id



Fax number


StringZ Extra properties in "propName=Value" format (text format)
You may put many properties, separated by CRLF, into this string.
This property is defined by application, for example:
The application should interpret the meanings of different properties.



Receiver email address



File extension of the content (APF/JPG/BMP/JPEG/PNG/...)
CoverFile StringZ The path of cover file (APF content only)
This is used for sending a fax with cover file.
FaxHeader StringZ Fax header text (APF content only)
Memo StringZ Text describes this fax.


TDateTime; (Double, 8 bytes)

Reserved for scheduled fax out time
PasswordCipher byte Password cipher algorithm, Reserved (should be zero)
ContentCipher byte File content cipher algorithm, Reserved (should be zero)
Compress Algorithm byte Content compression algorithm, Reserved (should be zero)
DeliveryMethod byte preferred delivery method (RemoteFax, LocalFax, or e-mail)
FailCount byte A flag for fax sender to indicate failure count

Extra Properties:

"Extra Propertie" is used when the above information is not enough to an application program. Normally, people use a reserved area of header for future use. However, since one REF file may be processed by different applications, it's difficult to know what size/type of area we should reserve in advance. So, we define a mechanism to satisfy the"future need" of different applications.

Extra properties consists of a list of "properties", each property constist of three parts:

Property ID (WORD) Property Size (WORD, does not include header) Property Data (Variable length, specified by Property Size)

Property ID=0 indicates "end of property". You don't need to check this because all the custom properties must fit in "HeaderSize" chunk, which has a 64K size limit.

Rising Edge plans to use property ID 1 to 3 to handle digital signature, multiple file attachment, and the "fax ID + routing log". Although Property ID is not well defined at this time, we are confident that REF format may provide a good flexibility to satisfy future requirement.

If you want to have larger custom properties, you can put the data into the content part. One REF file will contain one "logical" content, but we don't define the format of the content part. You may also use a compressed file (for example, a ZIP file) to store multiple files.

We set a 64K HeaderSize limit to ease the header parsing programming & prevent bad file format attack. The REF handling program can allocate memory for the whole header and load the header into memory at one time. 64K is not a big deal for modern computers, and a corrupted header will never makes the server program to receive a large junk.  (Most programs need to get the header before they can reject or accept the file)