Asterisk res_fax: session options, mode and result evidence

Separate the generic resource layer from a fax technology

Asterisk documents ReceiveFAX() and SendFAX() as applications provided by res_fax, a technology-agnostic resource module that uses a fax technology resource to complete a transmission. Record the installed Asterisk version, loaded res_fax module, loaded technology resource and their build or package provenance before interpreting a dialplan result.

Application availability does not prove that a compatible technology resource loaded, accepted the session or supports the selected mode. Keep module loading, configuration parsing, channel capability and a completed fax as different evidence.

Bind each FAXOPT value to one channel and session

FAXOPT() can override session settings otherwise supplied by res_fax.conf and can read information after a fax session finishes. Record the exact channel and when each value was written. A value set on a caller, Local-channel half or earlier leg is not automatically evidence for the channel that later runs ReceiveFAX() or SendFAX().

Treat error-correction mode, minimum and maximum rate, modem family, header, local station ID, T.38 timeout, gateway and fax-detection controls as independent inputs. Do not copy one endpoint or carrier workaround into every session without proving the failing boundary.

Keep detection, gatewaying and termination distinct

FAXOPT(faxdetect) can request detection for T.38 or calling tone with an optional timeout, while FAXOPT(gateway) controls T.38 gateway behavior. Detection is a signal observation; gatewaying translates between call legs; ReceiveFAX() or SendFAX() terminates or originates a fax session in Asterisk.

Name the intended role before enabling a control. A detected tone does not prove a route change, negotiated T.38, a gateway conversion, an accepted image or a successful downstream delivery.

Treat audio and T.38 as explicit session outcomes

The applications expose a final fax mode of AUDIO or T38. ReceiveFAX() documents an option that allows audio fallback on T.38-capable channels and another that forces audio mode. Preserve the SIP or other channel exchange, any T.38 negotiation and the media path that actually carried the session.

A T.38-capable channel is not proof that T.38 was offered, accepted or used. An audio fallback is not proof that loss, jitter, transcoding or echo cancellation were suitable for a reliable image transfer.

Keep the TIFF/F artifact and transmission result separate

ReceiveFAX() saves a received image as a TIFF/F file, while SendFAX() sends a specified TIFF/F file. Before a call, validate the selected path, file type, ownership, permissions, free space and retention boundary without exposing customer content. Afterward, keep file existence and readability separate from transmission success.

A written file does not prove an email, UCP copy, archive or workflow received it. Likewise, an accepted source file does not prove that the far endpoint received every page.

Record status, error, pages, rate, resolution and mode together

The fax applications publish status, error, detailed status string, local and remote station IDs, page count, negotiated bitrate, resolution and mode. FAXOPT() exposes corresponding session information, including a session ID. Preserve the complete result from the same channel and session rather than reducing it to a generic success or failure label.

Correct the earliest demonstrated mismatch and repeat the same authorized document and destination. Remove temporary debugging, protect fax content and identifiers, and retain only approved evidence. This guide is documentation-derived; no host, module, channel, file, packet or fax session was tested.

Continue fax application evidence into the carrier leg

After proving the Asterisk fax session and mode, use the T38Fax negotiation workflow to locate the re-INVITE owner, negotiated UDPTL path and received-document boundary.