Several software FAX solutions exist today, built around the SpanDSP library. These notes try to review the available options, and their performance limits.
SpanDSP is a library of DSP functions for telephony. It includes a complete software FAX machine for both audio and T.38 FAXing. It contains a PSTN to T.38 gateway. It can also function as a class 1 FAX modem, to the ITU T.31 specification, for use with FAX applications like HylaFAX+, HylaFAX, efax, or the Windows XP FAX facility. Currently, this class 1 FAX modem function is limited to audio FAXing - it does not support T.38 at this time (2008-12-02).
SpanDSP contains V.21, V.27ter, V.29 and V.17 modems. This means it supports FAXing at rates from 2400bps to 14,400bps. The faster V.34 modem standard is heavily encumbered by patents in most countries, so a free implementation is not possible. When used as a complete FAX machine SpanDSP supports all the standard sizes and resolutions of FAX pages. It supports error correcting mode (ECM). It supports T.4 1D, T.4 2D, and T.6 image compression. T.82 JBIG compression appears to be encumbered by one or more patents, so is not implemented. Colour FAXing is not currently supported.
Before looking at the level of success that can be achieved with specific FAX solutions, it is worth looking at the general limits of what is achievable. Many FAX calls fail for various valid reasons - wrong number calls, buggy far end equipment, etc. So what are things like in the real world?
FAX servers show widely differing rates of failed calls. Those used by a fairly closed group of people might see failure rates below 1%, because most calls are to and from well proven far end equipment. Those providing completely open FAX service more typically see failure rates of 15% to 20%, because of erroneous voice calls, clumsy FAX machine users, bad equipment, and numerous other problems. If the server is unlucky enough that its number gets onto some spamming list, the bad call rate may go through the roof. It is generally more interesting to look at call failures in systems with a fairly high call failure rate, as these typically communicate with many different terminals, and are a good way to assess compatibility with a broadest range of FAX equipment.
Clearly, it is important to screen out all the calls which could never possibly succeed when looking for the true call failure rate. The only sure way to reliably differentiate the different reasons for call failure is to instrument a FAX server, so the audio from all calls is recorded, and the failed call audio is kept for detailed human analysis. Such human analysis is time consuming, and not always reliable. Did that call fail because of a system problem, or did the user at the other end just fail to drop the page into the machine in good time? If our equipment was sending a FAX, and the far end disconnected, did we create a problem, or did someone at the far end do something. There will always be grey areas in call failure assessment, so it will always be a little imprecise.
At the end of the day, when failed calls are analysed in detail, the best FAX server solutions successfully complete about 99.5% of all real world calls which have the potential to be completed. This is a realistic goal that a good FAX server solution should target.
For about 2 years, a robust solution has been available in the form of SpanDSP + IAXmodem + HylaFAX+. HylaFAX, efax and other FAX packages also work well. Some people have even successfully used SpanDSP + IAXmodem on a Linux or BSD machine, and the Windows FAX system on a Windows machine, with the two interfaced by virtual terminal server software.
A "PRI + Asterisk + SpanDSP + IAXmodem + HylaFAX+ + some instrumenting of IAXmodem" setup was run as a high volume FAX server, for detailed call failure analysis. This quickly identified some issues which were fixed, and the unexplainable call failure rate dropped to about 1%, at about the time of IAXmodem-0.1.10. Further analysis of failed calls revealed certain line quirks, such as strange DC level steps, and far end FAX machine bugs which the original SpanDSP modems were not very tolerant of. Refinements added by the time of IAXmodem-1.0.0 had reduced unexplainable failures to well below 1%. A few adjustments to the DSP in IAXmodem-1.1.0 has made the SpanDSP modems more tolerant of FAX machines who's timing is out of spec. Failure rates have been comparable with other good quality FAX servers for quite a while.
The robustness of a SpanDSP + IAXmodem + HylaFAX+ setup is only good when it is used in a well constructed system. FAX has strict real time requirements. If the audio data hiccups, or a CPU overloads, FAXing will be slowed down by numerous retries or fail completely. Configured properly, an E1 or T1 setup is usually rock solid. mISDN, for BRI users, is hopeless, producing a very unstable audio stream. A number of users complain of problems with some analogue line (FXO/FXS) cards, but it is usually the associated driver software which corrupts the audio stream. A change of driver revision may change the behaviour of the system. Some motherboards use strange default settings for their PCI bus timing, and this can cause data loss for real time cards, like telephony ones. So, the bottom line is some care is needed, but reliable results are not too hard to achieve.
Using SpanDSP + IAXmodem inevitably involves a VoIP protocol, which is generally a bad thing for signal reliability. Only expect to use this between two processes on the same box, or two boxes on the same LAN. Don't assume your LAN will give you zero packet loss. It might when you do your testing, but few LANs are totally free of packet loss with their normal workload. Using a separate LAN for IAXmodem traffic may be a good idea. If you intend to route FAX calls across wider area IP networks, expect trouble.
SpanDSP + IAXmodem has been tested with hundreds of concurrent calls on a fast machine. Some systems saturate multiple T1/E1 lines all day using this software. Your mileage may vary, depending on the hardware you use, and what other work the servers are doing.
There is a channel driver for Callweaver, chan_fax, which performs a similar job to IAXmodem, but works inside Callweaver, avoiding the use of VoIP protocols. Its functionality is similar to using SpanDSP + IAXmodem, and its potential capacity is similar.
The modems in SpanDSP are the same as those used by IAXmodem, so the basic signal processing when using SpanDSP as a complete FAX solution is as reliable as when using it in a SpanDSP + IAXmodem + HylaFAX+ setup. Until recently, there were some limitations in the robustness of its FAX back-end's error handling, which made its overall reliability a little lower than HylaFAX. For a clean FAX call it was generally as good, but its problem/error recovery had some weaknesses. SpanDSP-0.0.6 has addressed this. By testing against the TSB85 FAX test specification a number of issues have been identified and fixed. The robustness of a standalone SpanDSP setup should now be comparable to SpanDSP + IAXmodem + HylaFAX. HylaFAX still leads in a few areas of functionality, such as colour FAXing, and has a nice queuing system for which several clients are available. SpanDSP alone takes less CPU power, and is quite easy to integrate with third party software for e-mail to fax, fax to e-mail, print to FAX, and other functions.
Callweaver uses SpanDSP to provide support for audio and T.38 FAXing, and as a T.38 gateway operation.
External support for using SpanDSP inside Asterisk has been available for a long time. Only recently, when SpanDSP changed licence from GPL 2 to LGPL 2.1, did support for FAXing with SpanDSP start to be integrated with the main Asterisk distribution. Currently, audio FAXing is supported. T.38 termination works with some limtations. T.38 gateway operation seems to be in development (2008-12-02).
FreeSwitch has a module called mod_spandsp, which provides access to a number of functions from SpanDSP. This includes support for audio and T.38 FAXing, and as a T.38 gateway operation.
2011-05-12