Facsimile —commonly known as fax— came to the fore in the 1970’s when consumer electronics were boosted dramatically by the creation of inexpensive integrated circuits. The opportunity to sell inexpensive fax terminals brought the manufacturers of proprietary fax devices together to find a common protocol so that the terminals of each brand could communicate with all the others. This resulted in the release of the ITU T.30 protocol recommendation in the middle of the decade.
T.30 was written to deal with the communication negotiations necessary for a fax call to transfer pages between terminals. It also contained a number of provisions for dealing with problems in the public analog switched circuit telephone system (PSTN) which was expected to carry fax calls. As with most efforts to satisfy everyone, T.30 satisfied no one. Many fax terminals were built and sold in volume with T.30 implementations that were anywhere from marginally compatible with each other to completely unable to communicate. And they all complied with the loosely defined T.30 document.
How Fax over IP (FoIP) Came to Be
The manufacturers eventually learned to create robust T.30 stacks that could deal with most of these vagaries. Then Voice over IP (VoIP) came on the scene and began to rapidly displace the somewhat antiquated PSTN voice network… the same network T.30 was created and continuously modified to use. Now the carrier companies were faced with making T.30 fax work over switched packet IP networks, by creating a service commonly known as Fax over IP or FoIP.
The good news is that the IP network had none of the issues caused by the PSTN. The bad news is that it introduced a whole new set of problems unique to its switched packet operation. A major part of this is that the installed base of some 100 million fax terminals expect to communicate over PSTN interfaces and require adapters called gateways to use IP network connections instead.
This adaptation to a new IP connection network forces PSTN fax calls to be exchanged between the originating fax terminal and the emitting gateway and between the receiving gateway and the answering fax terminal. This is done while these two gateways are exchanging fax call packets with each other over the Internet. These three simultaneous call models introduces new challenges, three of which are described below.
1. Call Collision or Glare
Fax calls share the IP network with voice calls. This means that the IP network has to be able to handle both fax and voice calls. Digitizing analog voice data into IP packets begs for compression to conserve bandwidth. This has led a movement away from the G.711 protocol for direct digital encoding of analog voice to G.729 which uses many techniques that discard some of the input data. This works fine for voice and you never notice the difference in the sound caused by the ‘lossey’ compression method.
However, loosing input data to reduce packet counts stops fax calls cold. The loss of any data means that critical control messages and page data messages are corrupted and the call itself quickly fails. To get around this, the FoIP gateway model includes the ability to recognize fax calls as opposed to voice calls and route them using different protocols.
Problems Between the Negotiation from Voice to Fax
The gateways look for the connection tones from fax terminals (CNG 1100Hz and CED/ANSam 2100Hz) to identify fax calls and will use either G.711 (called pass through mode) or T.38 to convert the call into packets. G.711 performs digitization of the entire signal as described above and T.38 provides a translation of each T.30 message into one or more T.38 packets.
The transition between voice protocols and fax protocols requires that the Session Initiation Protocol (SIP) re-negotiate the call from voice to fax. This means that one gateway must establish a new call path with the other. When the gateways try to do this at the same time or try to use different FoIP protocols, a problem condition called glare arises. The typical result is that the call is dropped and fax terminals cannot communicate over this path.
There are two ways around this issue. A complex negotiation process has been developed for SIP to recognize fax calls by the tones described above and deal with the renegotiation they require. A better solution is dubbed Internet Engineering Task Force (IETF) RFC 6913. Implementation of this RFC in gateway SIP code introduces a ‘sip.fax’ media feature tag that will directly identify fax calls at the beginning of a SIP negotiation and remove the ambiguity of who is doing what to support the call.
2. T.30 Timing and the Curse of Analog
Another major issue arises out of the analog roots of fax itself. Being designed for an analog switched circuit telephone system, T.30 incorporated a few pauses between adjacent messages to compensate for noise and phase/amplitude corruption of their audio carrier signals. These timing adjustments have been the source of endless grief over the analog PSTN and they also cause problems for FoIP in the, still analog, calls between the terminals and the gateways.
Since there are two analog calls in a FoIP call that still must be supported, the pause count between the signals doubles. In addition, transmission over an IP network adds the possibility of packet delays and out of order packet arrival which consume still more time. The creators of T.30 recognized that problems would occur in the exchange of control and page content messages and made timers that would re-transmit a message that was overdue. These timers will also terminate the call if one of the terminals judged it to have failed in the exchange process.
Add the multiple pauses, packet queuing and T.30 time outs together, and you have problems with calls being dropped because one terminal or the other didn’t get its messages in the specified ‘timely’ manner. Many gateways are engineered to deal with this using a range of techniques called ‘spoofing’. These generally involve sending parts of or even complete signals to a terminal to keep it on the call and waiting for the actual messages it needs to continue.
Artificial Intelligence hasn’t quite penetrated the gateway design arena yet so the implementation of these spoofing tricks is not a clear cut proposition. They often cause as many problems as they cure and require troubleshooting tools that can record and examine both the T.30 and the IP fax messages to catch issues and suggest equipment configuration changes.
3. Just a Hop, Skip and a Jump: The Problem with Multi-hop Paths
The fax terminal to gateway, to gateway, to fax terminal call path is tricky enough to navigate as is. What happens when a call is routed via several connected carriers and has to go through transitions between several FoIP protocols over a variety of gateways? The short answer is nothing good.
This connection model is becoming more common with the proliferation of carriers who lease network time from each other. The only real cure for this is the widespread adoption of RFC 6913 to keep the connections as quick, clean and compatible as possible.
Fax Over IP Can Be a Challenge
If fax over the PSTN was fraught with issues, fax over IP is an outright challenge. But 100 million fax machines still have to be serviced and telecom specialists are well advised to acquire the tools and skills that troubleshooting fax communications require.