Overview

This article will discuss handshaking failures.  It will list the causes of handshaking failures, as well as types of failures handshaking encompasses. This will include being unable to send a fax to a specific number, aborted faxes and modem timeouts.  Also, things to look for when handshake failures occur and what to do if you cannot resolve them yourself are included in this article.

Environment

This will apply to any FaxMaker installation that is not using a fax service(FaxMaker Online or EtherFax).  

Solution

Handshaking refers to phase B of the fax when the endpoints are identifying themselves to each other and setting the parameters by which the fax will be transmitted. Technically, a handshaking failure would occur during this time only.  Other failures during later phases in the fax would be actual errors, such as the expected page not received or a timeout when a page was sent and confirmation was not received. 

FaxMaker will call any fax that fails from phase B through phase E a handshaking failure, depending on the fax device.  An ISDN device will receive a "call failed 46" error, rather than a handshaking failure.  The other exception to this is the "operation aborted by user" error.  This is basically the same as a handshaking failure except the sender initiates the disconnect rather than the receiver.  

Causes of Handshaking Failures

Handshaking failures can be caused by many things. A shortlist is provided below, but whatever stops the transmission of the fax from completing successfully can be a cause.  

• Bad fax numbers (numbers you dial and fax tone is not heard)
• Older or degraded lines
• Electronic interference with fax lines
• Sharing fax lines for phone use 
• One line for multiple fax devices
• Incompatible fax equipment (normally deals with older devices)
• Transmission speeds higher than fax lines allow
• Network congestions if using fax over IP
• Attempting to use digital phone lines with analog fax devices
• Changes to systems used in conjunction with FaxMaker

The list of causes could go on and on.  One thing to note is the cause may not always be within the control of the user.  It could be on either side of the DMARC (demarcation point - the point at which the provider's responsibility stops and the end-users starts).  

What to Look For When Handshaking Failures Occur

Test the fax numbers that failed.  Call them on a phone or cell phone and ensure that fax tone is heard.   In many cases, especially if faxing from a software program like an EHR (electronic health records), where fax numbers may not be updated as frequently as they change.  

Verify your FaxMaker and fax device configurations have not changed.  This will vary by system and equipment for the fax device.  For FaxMaker checking the FaxMaker Configuration > Lines and Devices area for the following items on the Line Options tab of each line.  These items can also be verified with the screenshot below:

• Verify the Max resolution is set to Fine (200x200dpi).
• Verify the Max speed is not set to Maximum available.  Start with 14400 or 9600 before increasing to higher baud rates.  This only affects the outbound transmission rate.  The inbound rate will adjustment vary by device 
• Verify that a dial prefix is not needed for your environment.
• Ensure ECM is enabled (deselected).  This can also be disabled, but as a general rule, this setting is known to prevent these issues.  

Verify that nothing in your local configuration has changed.  This would include any other resources being used in conjunction with FaxMaker.  There have been many instances where a change was made in the phone system at the same time the handshaking errors started.  This will, of course, vary by system and equipment.

Verify there have been no changes on the provider's side as well.  These changes are not usually made without notification, but verifying there were no emails or notifications from the providers could also be helpful.  

What to Provide to GFI Support When Opening a Ticket 

When fax failures are happening, uploading logging when the ticket is opened gives support the information required to immediately review what is transpiring during the transmissions.  

In all of the following cases, please enable debug, reproduce the issue and run the troubleshooter to upload the logging - this will assist in diagnosis.

• If using any analog devices
• If using any ISDN devices (other than Brooktrout or XCAPI devices)
• If using a Brooktrout ISDN device, please also collect Dialogic ECC logging
• If using a Brooktrout SR140 FoIP device, please also collect both Dialogic ECC logging, and a Wireshark capture
• If using an XCAPI FoIP device, please also collect an XCAPI trace