[asterisk-users] res_fax

[Steve Underwood]

On 01/21/2011 06:46 AM, Bryant Zimmerman wrote:
> On 01/20/2011 11:47 AM, Steve Underwood
> On 01/20/2011 11:11 PM, Kevin P. Fleming wrote:
> > On 01/19/2011 02:30 PM, Bryant Zimmerman wrote:
> >> On 01/19/2011 02:05 PM, Bryant Zimmerman wrote:
> >>> I am working on some fax tools for some of my users. I am reading the
> >>> https://wiki.asterisk.org docs for faxing.
> >>> Is see Application_SendFax and Application_SendeFax has one been
> >> discondinued?
> >>> Any feed back on using the res_fax module would be apperciated. Any
> >> examples or
> >>> other.
> >>
> >> *From*: "Jason Parker" <jparker at digium.com>
> >> *Sent*: Wednesday, January 19, 2011 3:19 PM
> >> There was a typo in the res_fax documentation. Application_SendeFax
> >> should be
> >> the correct documentation. I don't know where Application_SendFax is
> >> coming
> >> from - it's probably old. When the next import happens,
> >> Application_SendFax
> >> should be replaced by the correct version (then I'll try to remember to
> >> remove
> >> the bogus SendeFax copy).
> >>
> >> Jason thanks for the clarification on this.
> >>
> >> If I start my development with the res_fax_spandsp.so module. Should all
> >> of my code be compatible with the res_fax_digium.so module? I want to be
> >> able to get things running and tested and move to the digium supported
> >> option in the future.
> >
> > The choice of technology module is mostly irrelevant; that was the
> > whole point of splitting res_fax out from them. If you use the
> > applications and other features of res_fax, it won't matter which
> > underlying technology module is loaded.
> >
> Well, people do get problems with the Digum FAX software, which go away
> when they switch to spandsp. Its best to test with the code you intend
> to deploy.
>
> Steve
>
> Steve is there any real compelling reason to res_fax_digium.so over 
> the res_fax_spandsp.so?
> I was thinking Digium module was likely to be better is this wrong 
> based on what people are seeing?
Feature wise they are similar, using an Asterisk release. By adding 
patches from the bug tracker, spandsp can work as a T.38 gateway, which 
the current Digium code cannot. I assumed by now Digium would have 
launched a V.34 version of their FAX module, which is something a free 
version can't do for a few more years, but there seems no sign of that 
happening. People tell me spandsp is more flexible in its TIFF file 
handling, but I've never found any documentation on what the Digium file 
handling is supposed to be capable of. Speed wise I have no comparisons. 
There are people running hundreds of concurrent FAXes all day using 
spandsp on quad core servers with good disk setups. I have no idea how 
fast the Digium software can be.

Performance wise I've helped people get off the Digium FAX software, and 
start using spandsp, to get around problems. A couple of people were 
frequently finding only the first 1/4 or so of each page in the output 
file, when the received T.38 stream was perfect (i.e. I could play a 
PCAP of the session into spandsp, and get a perfect TIFF file). Those 
people complained that the only support offered by Digium was an offer 
of a refund. I've help a couple of people who regularly see weird T.38, 
which the Digium FAX was handling in a very ungraceful way. Spandsp 
handled it badly too at that time, but the latest spandsp snapshots do a 
good job.

To be fair, I only get contacted when the Digium FAX software screws up, 
Digium are no help, and the person is looking for a solution. I get 
little visibility when spandsp might do something bad, and the Digium 
software does a better job in the same situation.

A comparison wouldn't be complete without mentioning Hylafax. Hylafax 
has a great infrastructure - tools for integrating with Windows clients, 
and so on. Neither spandsp or the Digium FAX code can match that for FAX 
termination. I think its biggest drawback is you either use it with 
iaxmodem for audio FAXing, or t38modem for T.38 FAXing. It can't 
smoothly integrate the two right now.

Steve