Fax Servers: Pooled Lines and the Inbound Routing Problem

Two problems that share a wire

It is easy to describe a fax server as a single thing: a box with telephone lines on one side and a local network on the other. Structurally it was two systems that happened to share hardware. The outbound system took jobs from many users, held them, ordered them, and dealt them out to whichever line was free. The inbound system took calls arriving on those same lines and tried to decide who each one belonged to. The first is a scheduling problem with a well-understood shape. The second is an addressing problem that the underlying protocol simply does not provide the information to solve.

That asymmetry explains most of what looks arbitrary about fax-server design — the licence-and-line arithmetic, the odd insistence on one telephone number per employee, the persistence of a person whose job was to look at incoming faxes and walk them to a desk. None of it was inefficiency. It was the cost of routing a document format that was never designed to be routed.

The half that worked: pooling lines for outbound

The outbound model is stated plainly in the primary sources. The HylaFAX project describes itself as an enterprise-class system for sending and receiving facsimiles in which the fax modems may reside on a single networked machine while clients submit jobs from any other machine, with support for multiple modems and heavy traffic. Microsoft's Fax Service documentation describes the same shape from the other side of the industry: a TAPI-compliant service that provides fax functionality for clients on a local area network, letting users send and receive using either a local fax device or a shared network fax device, and archiving sent faxes.

Once a job is a queue entry rather than a person standing at a machine, the ordinary machinery of scheduling becomes available: retries on busy or no-answer, priority, off-peak deferral, per-user and per-department accounting, and a record of what was sent and whether it was confirmed. The economics that justified the purchase followed from this — fewer telephone lines carrying more traffic, no walk to the machine room, and an audit trail that a physical fax machine could not produce. It is worth resisting the temptation to fold this into a paperless-office narrative. Fax servers were bought to reduce line cost, save time at the desk, and produce records; they still ended with a document that was very often printed.

What the pool was made of varied, and the distinction matters here only for what a pool could be. At one end is the single-line fax modem, which presents an AT-style command interface and splits the T.30 work between host and modem according to a service class. At the other is the multi-channel fax board, a different animal: the Computer History Museum's GammaLink publicity photographs show both a single-line PC fax board and the multi-line MLCP-4, and boards of that family carried their own signal processors and multiple line interfaces rather than exposing a modem command set at all. The same number of pooled lines might therefore be an array of single-line modems or a small number of boards, with quite different host software behind them. The service classes themselves — Class 1 against Class 2 and 2.0, and why pre-standard Class 2 modems interoperated badly — are covered on their own page and not rehearsed here. Channel densities were board- and generation-specific and are not worth stating as general facts.

The half that did not: nothing on the page says who it is for

A Group 3 call is governed by ITU-T T.30, which negotiates capabilities, transfers pages, and confirms them. What it does not do is carry a structured recipient. The cover sheet may say "For: Margaret in Accounts", but that is ink on an image, indistinguishable to the server from any other marks. Everything the server knows about the intended recipient has to come from outside the document.

The clearest single inventory of what a server had instead is a data structure. Microsoft's FAX_ROUTE, the structure handed to a routing extension when a fax arrives, contains Csid — documented as the called station identifier of the local device that received the fax — and Tsid, the transmitting station identifier of the remote device that sent it; CallerId, which identifies the calling device; RoutingInfo, documented in the form "Canonical-Phone-Number[|Additional-Routing-Info]", where the additional part is the subaddress; ReceiverName, documented as the name of the person who received the fax; ReceiverNumber, the telephone number of the device that received it; the device name and identifier; and an opaque routing-data blob. One of those fields does name a person. But the documentation does not say where its value comes from, and the T.30 exchange offers nothing for it to be filled from — every field the structure can populate out of the incoming call is a station, a line or a number. The recipient's name is not something the fax brings with it. It is something the server has to work out.

Why direct inward dialling won

Of the available signals, one is unambiguous, arrives before the document does, and requires nothing of the sending machine: the number that was dialled. Give each person their own fax number, point the block at the server, and the switch tells the server who the fax is for. It is expensive in numbers and it pushes the burden onto the sender's address book, but it is deterministic, and determinism is what an inbound router needs.

The standards body did produce a more elegant answer. ITU-T T.33, in force since 1996, defines facsimile routing using a subaddress — a way of naming a recipient behind a single published number rather than buying a number per person. It is the correct design. It also depended on the machine at the far end supporting and populating the subaddress, which the great majority did not, and a routing scheme that fails whenever a sender's equipment is ordinary is not a routing scheme an organisation can rely on. T.33 belongs in this story as the answer the industry had and could not use, not as the answer it used.

Identifier-based routing occupied an awkward middle. TSID matching and caller-ID matching work by knowing who is calling rather than who is being called, which means they route correctly only for correspondents already in a table and only when the far end declares itself honestly. CSID does not even do that much: it is the called station's own identifier, so it describes the line that answered rather than anyone at the other end of the call. Cover-sheet recognition was the most heavily advertised approach and the least dependable; vendor claims about its accuracy should be read as advertising rather than as evidence, and in practice a queue of unroutable faxes and a person to sort them remained part of the design.

What happened after the decision

Once a recipient was decided, delivery was comparatively unglamorous and well documented. Microsoft's Windows Server 2008 incoming-routing documentation describes any combination of routing methods being applied to a received fax: forward it to an e-mail address, store it in a folder, or print it. Vendors could extend the set of global routing methods through the Fax Routing Extension API, whose documented anatomy covers initialising an extension, routing a fax, managing the file list associated with it, and registering both routing extensions and fax service providers. The same documentation carries the operational residue of all this — a run of Fax Service event identifiers, 32002 through 32110, recording the success and failure of print, store and e-mail routing.

A pattern without a clean origin

There is no defensible "first fax server", and the claim is worth refusing rather than adjudicating. Candidates include PC fax boards fitted with local-network front ends from the mid-1980s onward, dedicated LAN fax gateway products of the early 1990s, and FlexFAX, which later became HylaFAX — a project commonly attributed to Sam Leffler and dated to 1991, though the project's current site carries no history section to confirm either that or the rename, which is itself commonly dated to April 1995 for trademark reasons. Vendor corporate histories in this space are also unreliable narrators, having been rewritten through repeated acquisition: both GammaLink and Brooktrout Technology ended up inside Dialogic, and nothing cited here fixes the dates of those transfers. Founding dates and priority claims taken from a current vendor's About page should be treated as marketing — including, consistently, when the date is one this page would have liked to use.

The problem outlived the hardware

When fax addressing was carried into internet mail, the same shortage of recipient information reappeared, and the same subaddress was pressed into service. RFC 3192, published in October 2001, defines a minimal fax address format for internet mail of the form FAX=+phone-number, optionally followed by /T33S= and a subaddress, at a gateway domain. The telephone number identifies the destination station, and the optional subaddress is the T.33 mechanism carried across unchanged — the same answer to the same shortage, in a new envelope.

Two claims are worth declining at this point. The first is that Microsoft removed fax from Windows: the TAPI-based Fax Service is documented for the Windows 2000 and XP generation, a Fax Server role shipped in Windows Server 2008, and Windows Fax and Scan shipped on client Windows. Those API documents are archived, which is a statement about documentation rather than about the feature, and any claim of removal needs to name a specific version. The second is the quiet backdating of hosted fax services into this history. An on-premises fax server owned its lines and its boards; a hosted service owns lines on a customer's behalf. Their inbound routing, failure modes and cost structures differ, and the arrangement described here should not be read as an early version of the other.

What survives is the shape of the problem. Pooling a scarce outbound resource behind a queue is a solved pattern that recurs wherever many people share few channels. Delivering an inbound document to a named person, when the document format carries no name, is not solved by better software — it is solved by buying addressing from the network, one number at a time, or by accepting that a human will read the cover sheet.