Internet Fax Standards: T.37 Store-and-Forward and T.38 Real-Time

The thing that had to be preserved or abandoned

Group 3 facsimile splits its work across two layers that behave very differently. Image coding and terminal characteristics belong to T.4; the call itself — the part that makes fax a session rather than a transfer — belongs to T.30. A T.30 call opens with low-speed V.21 signalling in which the called terminal announces what it can do and the caller selects from that set. Page data then moves at higher speed over the V-series modem carriers, and after each page the receiver returns a message confirming what it did or did not get. The sender is not free to proceed until that answer arrives.

That last property is the whole difficulty. The confirmation is not an application-level receipt bolted on afterwards; it is part of the call, and the call has response windows. The in-force edition of T.30 is dated 09/05, and its Amendment 1 (01/07) concerns the extension of a silence period during fallback from V.34 — a detail worth noticing, because it shows that timing tolerances in T.30 are themselves normative text, still being adjusted a decade after the internet-fax Recommendations appeared. A design that introduces arbitrary delay between the two terminals is not slowing a fax down. It is breaking the protocol's own contract about when an answer is expected.

Two answers, one approval season

The popular telling gives T.37 first and T.38 as its successor, usually with a gap of several years implied between them. The ITU-T's own edition listings do not support that. T.37, covering the transfer of facsimile data by store-and-forward on the internet, carries a 06/98 base text; T.38, covering real-time Group 3 facsimile over IP networks, carries a 06/98 base text as well. What genuinely differs is what happened afterwards.

Read as maintenance history rather than as succession, the picture is straightforward. The edition lists record the divergence without explaining it. What they do show is that T.37's substance lives largely in IETF documents that continued on their own schedule, while T.38 needed repeated Implementors' Guides — a pattern consistent with relay being the harder thing for two independent vendors to implement identically. Neither pattern makes one Recommendation obsolete. Both remain in force.

What the store-and-forward side actually specifies

T.37's answer is to stop pretending there is a session at all. The page becomes an attachment to an ordinary Internet mail message, submitted and relayed by SMTP like any other mail, and delivered either to a mailbox or to a gateway that dials out. The IETF's simple mode was published as RFC 2305 in March 1998 and superseded by RFC 3965 in December 2004; it describes precisely the topologies the architecture implies — an onramp gateway that answers a telephone call from a Group 3 machine and emits mail, and an offramp gateway that receives mail and places the telephone call at the far end.

The payload is where vendor literature most reliably goes wrong. Simple mode requires the minimum TIFF profile — profile S — defined in RFC 2301 (March 1998) and revised as RFC 3949 (February 2005), which specifies the profile set S, F, J, C, L and M with profile S mandatory. That family is TIFF-FX. It is not TIFF-F, which is a different thing: RFC 2306, also published in March 1998, states in its own words that TIFF-F had been folklore with no standard reference definition before that document, and credits an informal specification by a group led by Joe Campbell. Writing that T.37 uses TIFF-F conflates a retrospectively documented convention with the profile the specification actually names. T.37's Amendment 3 (11/02) later added support for the image/tiff and image/tiff-fx MIME content types outright.

The remaining piece is addressing. A telephone number is not an email address, so RFC 3192 (October 2001) defined a minimal form for expressing a public-network fax destination inside one — the FAX=+number construction, optionally carrying a T.33 subaddress — which is what lets an offramp gateway be told where to dial. Manufacturer documentation for configuring onramp and offramp fax on router platforms describes the same two halves in implementation terms.

Rebuilding what the session used to provide free

Once the session is gone, two things go with it, and the sequence of RFCs after 1998 is essentially the work of putting them back. The first is confirmation. In a T.30 call, the receiver's per-page message tells the sender that a specific page arrived, inside the call, while the caller is still on the line. Mail has no equivalent: successful submission says nothing about delivery, and delivery says nothing about rendering. RFC 2532 (March 1999) responded by making delivery and disposition notifications a required part of extended-mode internet fax rather than an optional courtesy.

The second is negotiation. T.30 asks the far end what it can receive before anything is sent, so a sender never transmits a resolution or coding the receiver cannot handle. A store-and-forward sender has no one to ask. RFC 4142 (November 2005), the full-mode fax profile for internet mail, states its purpose in those terms: adding reliability and capability negotiation to email so that it matches what classical T.30 already did. Seven years separate the simple-mode publication from that statement, which is a fair measure of how much of a fax call is not the image.

The other half of the choice: keeping the session alive

T.38 takes the opposite branch. The T.30 conversation is preserved end to end, and a gateway at each edge makes the packet network carry it — demodulating the V.21 signalling and the page carrier, forwarding the recovered T.30 messages and image data as packets, and remodulating them for the terminal on the far side. What crosses between the two gateways is therefore decoded protocol rather than sound. This is the correction the popular sources most need: T.38 is not the fax call sent as audio over the internet. Carrying the modem tones themselves in a voice stream is fax pass-through, a different arrangement, and one that a lossy voice codec handles badly for reasons that belong to the modem, not to fax.

The transport detail also gets reported backwards. The mainstream negotiation is image/t38 over UDPTL, registered in RFC 3362; the RTP-carried alternative registered as audio/t38 in RFC 4612 (August 2006) is classified Historic. The relay mechanism itself — packet structure, redundancy, error correction, and the gateway's job of holding a local state machine inside its timers while packets are in flight — is the subject of this archive's separate reference entry on T.38 in its tools section, and is deliberately not repeated here. What matters for the comparison is only that the session survives, and that surviving it is the entire cost.

Complements, not generations

Set side by side, the two Recommendations answer different questions, which is why the ITU-T never treated them as alternatives.

Where the 1998 choice still lives

Both branches converge on the same object at the edge: a gateway that holds a genuine T.30 conversation with a Group 3 machine over the telephone network while, on its other side, speaking something entirely different. The onramp and offramp gateways of the store-and-forward design and the relay gateways of the real-time design are variations on that one component. It is the piece that never became obsolete, because the machines it dials never all went away.

That is also the honest description of what a fax app on a phone is. Nothing about the device speaks T.30; the document is submitted over a data network to a service, and the service runs the offramp — placing the telephone call, negotiating capabilities with whatever answers, and returning a result. The interface is new and the architecture is the one settled in 1998. Understanding which half of that settlement a given service implements is the difference between expecting a delivery notification and expecting a handshake, and those are not the same promise.