<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
David Backeberg wrote:
<blockquote
 id="mid_3de056a30903140733l2a0d26d3l1e5d2daa387826f3_mail_gmail_com"
 cite="mid:3de056a30903140733l2a0d26d3l1e5d2daa387826f3@mail.gmail.com"
 type="cite">
  <pre wrap="">On Sat, Mar 14, 2009 at 12:00 AM, Steve Underwood <a class="moz-txt-link-rfc2396E" href="mailto:steveu@coppice.org">&lt;steveu@coppice.org&gt;</a> wrote:
  </pre>
  <blockquote id="StationeryCiteGenerated_1" type="cite">
    <pre wrap="">Fully open-to-the-public FAX servers tend to get just get a lot of bad
calls, many of them wrong numbers, or voice users. FAX servers for
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I've definitely seen that, and have been able to either identify the
validity of a caller by CID or by calling the number and confirming a
blast of fax tones.

  </pre>
  <blockquote id="StationeryCiteGenerated_2" type="cite">
    <pre wrap="">clue what kind of failure rate might be expected. You can find a bit
more about these issues and our results at
<a class="moz-txt-link-freetext" href="http://www.soft-switch.org/spandsp-soft-fax-performance.html">http://www.soft-switch.org/spandsp-soft-fax-performance.html</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
After reading that, it occurred to me that I'm running SpanDSP 0.0.5
and 0.0.6 seems to have enhancements that may solve the problems I've
been seeing. I'm convinced that it's worth upgrading and seeing if I
can reduce my failure rate.

  </pre>
  <blockquote id="StationeryCiteGenerated_3" type="cite">
    <pre wrap="">Your differing failure rates between using ReceiveFAX and using iaxmodem
seem to indicate your results relate to issues in your own system,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think I wasn't very good at setting it up, as I had no experience
with IAX. Likely my fault rather than anything inherently wrong with
the software. There were more moving parts than I was able to get a
handle on, and when I switched to 1.6 and app_fax things 'just
worked'. This is why I keep recommending the 1.6 approach over the 1.4
+ IAX + IAXModem + Hylafax.

  </pre>
  <blockquote id="StationeryCiteGenerated_4" type="cite">
    <pre wrap="">LANs don't loose packets), will have a true failure rate (i.e. a rate of
calls failing which had the potential to succeed) well below 1%. The
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That's consistent with my testing before I set it live.

You mentioned recording faxes. I know how to do that with IAXModem,
but are you familiar with a method for 1.6 and app_fax? I read through
app_fax.c and didn't see any way to send a flag. Is the recording
built into SpanDSP, or is is something IAXModem added on themselves?

  </pre>
</blockquote>
For what it's worth, the company I work for switched from WinFax to
HylaFax last spring.&nbsp; We only have 4 analog phone lines coming in to a
4-port modem card, but the Hylafax system runs on the same server as
our main Asterisk PBX.&nbsp; So far Hylafax is performing much better than
WinFax ever did.&nbsp; When we have errors either sending or receiving, it
is always either line problems or the wrong number being dialed
resulting in a voice call to the fax line.<br>
<br>
I would estimate that our overall success rate is around 95% if you
disregard faxes to wrong numbers or incoming voice calls to the fax
lines.&nbsp; Load testing a large-scale fax system under real-world
conditions is difficult if not impossible without having access to a
variety of hardware and software fax devices scattered all over your
prospective send or receive area.&nbsp; If you load test from your own
location by attaching a bunch of fax machines or a fax sending server
to your outgoing lines and have them dial back in, then you're only
looping through your local telco's switching center.&nbsp; You might get
very different results from sending faxes from out of state, or even
across town.&nbsp; It's been my experience that telephone line quality
varies greatly from place to place and even from time to time.<br>
<br>
A perfect example is from back in my days as a systems admin for a
dial-up ISP.&nbsp; We were operating in a small town where PRI or
channelized T1's weren't available so we had a bank of about 100 US
Robotics external modems connected with serial cables to 2 Livingston
PortMaster terminal servers.&nbsp; Everything would run fine (or as fine as
it ever got with dial-up) until it decided to rain.&nbsp; Everytime we'd get
more than a tenth of an inch of rain a large group of the modems would
go haywire and start dropping calls.&nbsp; A couple of the modems would burn
out completely.&nbsp; We had the telco out repeatedly and they always gave
us some answer that didn't make any sense.&nbsp; After about the 6th time
this happened they sent out a technician with a brand new line analyzer
that happened to include a TDR.&nbsp; The vast majority of the lines we were
having trouble with showed to have a partial short about 100 feet from
our building which just happened to be right under the middle of the
road in front of our building.&nbsp; They dug the section of line up and
found that the cable had been partially cut at some point in the past
and the wires were spliced with electrical tape and the whole bundle
had then been wrapped with tape.&nbsp; Every time it rained, the water would
seep into the shoddy splice and short all the lines together.&nbsp; When the
water dried out, the shorts would go away and the lines would go back
to normal.<br>
<br>
I've seen situation like that enough to know that until everybody has a
purely digital phone line, there will always be line quality problems
that will be out of the end user's control.&nbsp; Even though the company I
work for now is a small company is a very rural area where technology
is somewhat limited, we're beginning to realize just how antiquated Fax
is becoming.&nbsp; E-mail and web services are rapidly replacing fax to the
point that 90% of our incoming faxes are spam.<br>
<br>
One really nice thing about Hylafax is the logging that happens during
the entire fax process, so it's much easier to see where the problem is
occurring.<br>
</body>
</html>