[Freeswitch-users] Successful faxing with spandsp / T38 and stats

[Steve Underwood]

On 06/27/2012 09:01 AM, Mitch Capper wrote:
> Hello everyone,
> I have been working on faxing for awhile now and figure I would post
> back with some results and method.  Much of my method I have
> documented on the wiki about faxing but some more details on my method
> are also below.  Faxing overall is a horrific thing and when I first
> looked into VOIP faxing I did not think I would be able to achieve
> nearly the success rate I have been able to with FreeSWITCH.
>
> These stats were collected over 1000 individual faxes and over 4000
> pages sent to over 500 unique fax numbers.   I would guess a lot of
> these numbers are geographically clustered around the northwest of the
> US but I doubt that should matter a whole lot.
> Up until last week I had but 1 fax that didn't complete (it was an 80+
> page fax that failed twice mid-fax before we just emailed it so it
> probably would have completed with some extra time).
>
> In the last week I have had two I have yet to get through (not sure
> why or if I have finally found fax machines I just can't send to or
> what have you).   I was blown away with the current success rate.  I
> did not collect as detailed stats the entire time I was logging data
> (probably only 3/4's+ of the total faxes have full detailed stats).
> With all that said the below numbers should be decently reflective of
> real world use.
>
> First on the method:
>
> I try a progressive retry system,  I try one method if it fails I wait
> 60 seconds then try the next.  I use two providers, flowroute and
> t38faxing.com.   Flowroute I highly recommend they are a great
> provider and have worked very well for faxing.  T38Faxing.com / EZCALL
> are quite bad and I highly recommend avoiding (see bottom of email for
> why).
>
> My 8 methods are: T38,ECM / ECM / T38_DISABLED,ECM / T38,SLOW /
> T38_DISABLED,SLOW / BACKUP,ECM / BACKUP,SLOW /
> BACKUP,SLOW,T38_DISABLED
>
> Slashes delimit the method and commas delimit the flags for that
> method.   Slow=fax_disable_v17,  T38=fax_enable_t38_request,
> T38_DISABLED=fax_enable_t38=false  BACKUP=T38Faxing.com (T38faxing.com
> fails if t38_request is enabled so thats why T38 is not used with
> them).
>
> If the line is busy I don't move to the next method nor if there is a
> channel error.
>
> The methods are tried in order they are not tried randomly.  Randomly
> would make the below stats better but I care about fax through a fast
> as possible so I try in order of what I thought had the best chance of
> success.
>
> average secs per page: 28.055
> average tries until success: 1.33 (not including busy).
>
> Method Usage Rates:
>          75% T38,ECM success rate: 82% avg secs/page: 27.4
>          13% ECM success rate: 46% avg secs/page: 29.5
>           7% ECM,T38_DISABLED success rate: 60% avg secs/page: 28.3
>           2% T38,SLOW success rate: 56% avg secs/page: 45.7
>           1% SLOW,T38_DISABLED success rate: 57% avg secs/page: 40.6
>           1% ECM,BACKUP success rate: 57% avg secs/page: 35.8
How should I interpret those percentages? Does it mean 75% of call 
attempts were with T.38 and ECM, and 82% of those attempts were 
successful? If so, that's somewhat encouraging, as a lot of T.38 boxes 
have broken ECM support, and quite a lot of operators suppress ECM mode.

Overall, its rather sad. On the PSTN we would get 99.5% success first 
time as a bare minimum, and then look to improve the results. :-)

>
> Failure Reasons:
>          40% The call dropped prematurely
>          25% No response after sending a page
>          11% Invalid response after sending a page
>           6% Invalid ECM response received from receiver
>           5% Received no response to DCS or TCF
>           2% Unexpected message received
>           2% Timed out waiting for initial communication
>           2% The HDLC carrier did not stop in a timely manner
>           1% Received bad response to DCS or training
>           1% Disconnected after permitted retries
>           0% Timed out waiting for the first message
I don't think you can get much from those figures. Its a real mixed bag 
of results. If there were a dominant pattern it might represent a bug or 
design weakness I might be able to address. This just suggests poor 
channels.

Steve