Hi Florent,
as you might know HylaFAX is a fax server suite for Unix. It is over 20 years old but still actively developed, and it is *very* stable and widely used. Hylafax consists of a few daemons and tools that interact. It provides a FTP-based network protocol to submit faxes from desktop clients or other systems, a scheduler that schedules sending of queued faxes and dealing with failed transmissions and backends to interact with fax modems.
The most important components are:
faxq - qeuue manager daemon for outgoing faxes
hfaxd - network protocol server daemon (receives jobs and hands them to faxq)
faxgetty - modem daemon (one faxgetty waits for incoming faxes on one particular modem)
faxsend - open a modem device and send outgoing faxes through that modem
As 20 years ago fax always meant using fax modems, HylaFax is natively made to (only) work with fax modems through it's faxgetty and faxsend processes. To use those, you *have* to have one or more fax modems that are connected/exposed through a serial interface (/dev/tty* on Linux).
FreeSWITCH with its spandsp module can already provide a number of virtual modems that HylaFAX can use, see
http://wiki.freeswitch.org/wiki/HylaFax. Connecting HylaFax and FreeSWITCH using tty devices has some drawbacks as i mentioned.
The interface of faxgetty and faxsend is pretty easy to implement, faxsend is called by faxq, it will take a .tiff fax file and send it using a fax modem. faxgetty will receive a fax and place a .tiff file in HylaFax' spool directory. After receiving, it will call a shell script that can dispatch the fax (send it by mail, print it etc.).
What I did here was reimplement those two commands:
gofaxd - replacement for one or more faxgetty processes
gofaxsend - replacement for faxsend
The two replacement commands will talk to FreeSWITCH through the event socket and send/receive faxes using mod_spandsp's rxfax/txfax applications. This has a few advantages over using tty devices to connect to FreeSWITCH:
- No Fax modem emulation and tty device necessary (thus the stack becomes simpler)
- Native T.38 without t38_gateway (more robust and less CPU usage)
- We can use and log all sorts of events and verbose debugging (SIP headers, bad rows etc.) to HylaFax.
- Number of parallel incoming faxes not limited by number of virtual modems.
The concept was used before in the open source capi4hylafax suite that implemented c2faxsend and c2faxrcvd as replacement for faxsend and faxgetty. capi4hylafax could talk to ISDN CAPI 2.0 devices instead of tty fax modems.
Compared to t38modem or iaxmodem, which (as far as i know) are not maintained anymore, the beauty in this system is that - apart from some decent FreeSWITCH and HylaFax knowledge needed to implement it - all the hard stuff (signal processing) is done in FreeSWITCH and mod_spandsp with both are actively maintained and improved. GOfax.IP is only shifting metadata like logs and queue files around and helping HylaFax and FreeSWITCH talk to each other. That's not much more than basic text processing, so it's easy to maintain and easy to improve without deeper knowledge of Fax protocols, spandsp etc.
The remaining question is if it is a good idea to use HylaFax for new projects at all. If I have to implement a new receive only fax system, I'd probably just use rxfax in the dialplan and a Lua script to process the fax and be done with it. I've done that before and it's easy to implement and works really well.
The reason why we've built GOfax.IP is that we have a larger amount of existing HylaFax setups that have been running for years (or even decades) with existing incoming/outgoing document handling based on HylaFax. Customers trust HylaFax and hesitate to completely redesign their fax processing when wanting to move from legacy analog modems or ISDN to Fax over IP. So it's more agreeable to all parties involved to switch the PSTN connectivity in HylaFax than deploy a completely different solution.
Best regards,
Markus