CopiaFacts reports fax error outcomes using the (different) codes defined by each board or port supplier, and showing the explanation provided by the supplier for each code. These explanations can be somewhat terse for people unfamiliar with faxing, so this topic shows some of the more common errors with a longer explanation.
Almost all of the possible errors may result from poor quality lines or poor quality segments of the transmission path. Fax transmission depends on precise timing in both directions, and can be disrupted when faxes are sent over a transmission path which contains both analog and digital segments, which is increasingly the case. Special transmission protocols such as T.38 fax are intended to optimize the delivery of fax, but can only be used when supported at both ends of of the route and all segments of the path.
For all these reasons it is essential that a retry strategy is used for all reported error outcomes which can be related to the transmission path. It is entirely possible that a retried call may take a completely different route to the destination. Retrying calls also shows the pattern of repeated failures, if they occur, and this may help you determine the cause and how to fix it.
 | If you have not thought about a retry strategy, and not configured this in CopiaFacts, these are the first actions you should take to resolve fax failures. Faxing is never 100% successful and it is normal for some failures to occur. The linked topics and the provided USR files contain sample retry configurations. |
| For FoIP errors, please refer to the BladeWare and XCAPI topics where specific advice for these interfaces can be found. |
Please use the feedback feature in this manual to suggest other outcome messages for which you would like more information.
Common Error Outcomes
| Busy | This simply means the phone line is busy and the call should be retried later. |
| No Answer | The usual cause of this outcome when sending to a simple fax machine is that it is out of paper. Most fax machines can store incoming faxes when this happens, but the store may fill up. You can also receive a 'no answer' outcome when sending to a busy fax server which has no free channels. |
| No Fax | The call was answered but no fax tones were heard. You may simply have called a telephone number. Or the line quality may be so bad that the fax tone could not be identified. For SIP calls, the remote fax may not support the protocol (G.711 or T.38) which is configured at the sending or receiving end. |
| Failed to Negotiate | The sending and receiving fax devices are incompatible. For example you may be attempting to send a B4 size page to a physical machine which can only handle A4 or Letter sized pages, or when using an unsupported image resolution which cannot be automatically converted as it is transmitted. This error can also be caused by a communication failure or poor line quality which was first detected during the phase in which the two end-points are negotiating the common transmission parameters. |
| Failed to Train | After negotiation of the transmission parameters, transmission is attempted at the highest common supported baud rate (transmission speed). If this cannot be supported on the line, the speed is gradually reduced (14,400, 9,600, 7.200 etc.). If the training at the lowest speed (2400) is not successful then a failure to train is reported. |
| Partial Fax | The fax transmission failed after some pages had already been reported as successfully received. This issue can arise at the same time as other errors, for example when transmission needs to be re-negotiated as a result of page size or resolution changing in the middle of a multi-page document. |
| T.30 Error... | An error occurred during the transitions between different phases of fax transmission. |
| Page Result Error... | The transmission or reception of a page was not acknowledged correctly after the retries specified in the T.30 protocol. |
| RTP/RTN Error | The procedure to retry sending part or all of a page was not completed successfully. |
Faxing Tips
The following methods can be used to reduce the number of fax failures.
| Diva Fax Receive | When using Diva boards, a list is maintained of incoming fax numbers for which negotiation at higher speeds fails. This speeds up reception by not attempting these baud rates the next time. The cache is cleared on reboot but if you rarely reboot you should clear this list from time to time in case the original failure was a temporary glitch only. |
| Adjust Send Rate | CopiaFacts also allows you to collect information about low baud rates on outbound faxes (for any board or port) and use this to automatically retry at a reduced speed which has previously been successful. The DNSUPD program can extract this information from the log files and create an action list file specifying a reduced baud rate selection for each affected destination number. |
| Fax page counts | If your site frequently sends faxes with many pages, it is very important to use the $retry_partial command to allow the transmission to be restarted from the first failing page when a transmission error occurs. Without this, the fax will always be retransmitted from the first page on a retry. |
| Fax file size | It is important to select an optimal conversion method for submitted documents such as PDF and DOCX, especially if the original is in color or grayscale which needs to be converted to monochrome for faxing. If the file size is huge (and some conversions have this result) then you are more likely to encounter failures when line quality is poor. |
| Fax uniformity | We recommend trying to ensure that multiple-page documents have the same size, resolution, and orientation on all pages. This will reduce the need to re-negotiate the faxing parameters during the transmission, and will therefore eliminate some opportunities for failure on poor-quality lines. |
