Re: [hylafax-users] "Successful" Faxes never receied after delay in 4.1.8

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.07.27 15:28 Bill Binko wrote:
> Hello everyone,
>
> We have been seeing faxes sent to several destinations that were
> declared
> "successful" by hylafax never actually print on the far end.  I've
> looked
> at the comm logs, and have noticed that all of them have a delay
> between
> when hylafax sends EOP (no more pages) and when the remote responds
> with
> +FHS:0 and hylafax says "Normal and proper end of connection".
>
> The delay seems to be between 20 and 60 seconds.  Here is a sample:
>
> Jul 27 16:43:10.91: [16402]: <-- data [1027]
> Jul 27 16:43:11.10: [16402]: <-- data [364]
> Jul 27 16:43:11.10: [16402]: SENT 22890 bytes of data
> Jul 27 16:43:11.10: [16402]: SEND 2D RTC
> Jul 27 16:43:11.10: [16402]: <-- data [10]
> Jul 27 16:43:11.28: [16402]: SEND end page
> Jul 27 16:43:11.28: [16402]: SEND send EOP (no more pages or
> documents)
> Jul 27 16:43:11.28: [16402]: <-- data [2]
> Jul 27 16:43:55.50: [16402]: --> [6:+FHS:0]
> Jul 27 16:43:55.50: [16402]: REMOTE HANGUP: Normal and proper end of
> connection (code 0)
> Jul 27 16:43:55.50: [16402]: SEND recv MCF (message confirmation)
> ... email omitted
> Jul 27 16:43:55.50: [16402]: <-- [5:ATH0\r]
> Jul 27 16:43:55.50: [16402]: --> [2:OK]
> Jul 27 16:43:55.50: [16402]: SESSION END
>
> Notice the delay btween 16:43:11 and 16:43:55.

Nothing really can be concluded from that delay.  If using ECM the 
modem in Class 2.1 will spend a lot of time sometimes, trying to push a 
single page through (especially if the connection speed must be slowed 
down a few times).  Obviously there is a misunderstanding, however, 
between the sender and the receiver with regards to the post-page 
status, however.  This is something that only MultiTech is going to be 
able to fix for you.  You'd probably be much better served with 4.2.0 
in Class 1.0.

> We are running Hylafax 4.1.8 on Mandrake 10.0
> (hylafax-server-4.1.8-2mdk)
> using three internal Multitech ZPX modems.
>
> The modem IDs as : MODEM MULTI-TECH SYSTEMS MT5634ZPX-PCI-V92/1.25p

I'm not certain of this, but I think that your firmware can be 
updated.  I think that 1.32 is the new version number.

> We are running in class 2.1 with certain features disabled due to
> firmware
> issues.

These may be fixed in the new firmware, and they aren't relevant in 
Class 1/1.0.

> I have been trying (unsuccessfully) to convince my client to go to
> 4.2.0rc2 and class 1.0.  I realize that that would probably solve most
> of
> my problems including this one.  I can't get him to go to class 1 with
> 4.1.8 due to the amount of v.34 (38.4) faxing he does.

Which is why he should go to 4.2.0 Class 1.0.

> Is this a known issue, and is it fixed in 4.2.0?

The issue, if there is one, is a MultiTech matter.  It is nothing that 
can be fixed in any HylaFAX release.  In this case the modem is telling 
HylaFAX that the fax went just fine.  How can HylaFAX argue about 
that?  The only thing to do at that point is to fix the modem or to 
take the responsibility for handling the fax protocol from the modem 
(by switching to Class 1/1.0).  The "issue" is irrelevant to Class 
1/1.0 function.

> If so, it would be a
> great motivator for me to use to get my client to move.  Their big
> issue
> is the "rc" status.

"Status" isn't really the right terminology for it.  It's just a label 
that means "okay, we're going to make this a release unless someone 
discovers a major issue with it before long".  The only real thing that 
it indicates is that it hasn't had as much exposure as the previous 
full release.  Perhaps in other packages the CVS/beta/rc releases are a 
mess full of experimental things, but not with HylaFAX.  A full release 
doesn't really mean that there are no known bugs in it; it certainly 
doesn't guarantee flawless performance.  As with any software, you try 
it, and it should work for you as expected.  If it doesn't, then you 
revert back to the way it was or you fix the way that it is.

I think that if you could survey this you would find that many, many 
production servers have been running what has become 4.2.0 for a long, 
long time.  Realize that the 4.2 code branch split from 4.1 back just 
after 4.1.6 - a little over a year ago.  So anyone who has wanted the 
features (extended resolutions, ECM, MMR, V.34, integrated line IDs, 
returned fax documents via e-mail attachment, etc.) or any of the 
myriad of bugfixes therein has needed to run "CVS" or "beta" or "rc" 
code for a while now.

> I've explained that it shouldn't be an issue
> (open
> source, it being more stable than 4.1.8, etc).  So far, they want to
> wait.

I am intimately aware of all of the flaws and shortcomings that have 
been fixed in 4.1.8 to produce 4.2.0, and there is no way I would ever 
choose to use it in lieu of 4.2.0 on my clients' systems.  If they were 
afraid of the new features... well, then the one with largest impact 
can be disabled with this:

Class1ECMSupport: no

Note, however, that in doing so you deprive yourself of what has to be 
the greatest extension to T.30 since sliced bread.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*