Retry delays are specified using the $retry_delays command in the configuration file, user profile or FS file. The specification consists of a sequence of numbers representing the delay period before each retry. For example a sequence of three numbers indicates that up to three retries are to be made (four attempts in all). The delays are normally specified in minutes but a suffix of S or H may be used to specify seconds or hours. You may also specify an absolute time for the retry in hh:mm format, with an optional suffix of N or W to specify a non-working day or working day respectively.

For e-mail, the corresponding command is $email_retry_delays.  If you have no $email_retry_delays commands at all, $retry_delays will be used. When $retry_delays is used in this way for e-mail, the system will also use $retry_max, even if you have $email_retry_max defined.

If no delays are given for an outcome, the values from the $callback configuration command are used to generate a delay sequence as a default value. The retries parameter from the configuration command is ignored and all outcomes use the same values from the attempts and delay parameters.

Examples of $retry_delays commands are given in the reference documentation for this command.

CopiaFacts normally traverses the sequence of retries independently for each outcome class. Thus if an outcome of "no dial tone" (class D) is encountered after a number of "no answer" outcomes (class A), the next retry delay for class D will be used, and when a subsequent "no answer" outcome is encountered the sequence for class A will be resumed.

When the sequence of delays for an outcome class has been traversed once and there are no more delay specifications for the class, the call fails. You can also limit the total number of retries of all types using the $retry_max command. CopiaFacts uses a record of the "attempt history" recorded in the FS file (as $attempt_record) to determine the number of attempts in each class. Manually editing these command lines is not recommended. If you resubmit a fax by moving it from FAIL or SENT to TOSEND, the sequence of retries will be completely restarted and no account is taken of earlier attempts.

The $retry_delays command allows great flexibility in specifying retry strategies. For example you can specify two retries at three-minute intervals and then, twice, a wait of an hour before two further attempts. This would be done with the sequence "5 5 1H 5 1H 5". You can also specify a retry at or after a specific clock time rather than as an interval: if you specify more than one clock-time delay, the clock-time delay will only be done once in a sequence attempts, and replaced by a 3-minute delay thereafter.

Delays cause the FS file to be rescheduled with a new start time. This may result in a longer delay than the specified time if your system is loaded. You can use the $retry_tosend command to place retry FS files in a higher (or lower) priority TOSEND directory. Lower TOSEND directory numbers have higher priority.

Deferred retries may also be scheduled for a specific line group, using the $retry_linegroup command. This allows a specific board type to be used for retries, when the system contains more than one type of board.  If possible, you should schedule this type of retry by using $retry_tosend, not $retry_linegroup.  This requires your nodes to be configured so that nodes with differerent boards service different TOSEND queues.

Individual retry delay values may have a prefix letter of A, E, G, I, Q, R, T, X or Y as described in detail for $retry_delays.  These prefixes provide powerful means of changing transmission parameters such as baud rates on successive attempts.