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