Re: [hylafax-users] Multi-Tech ZMA v.92 (1.28C firmware) sending is still not right.

[An Intrepid HylaFax User <hylafax@xxxxxxxxx>]

Lee,

Thank you for such a detailed explanation which obviously took a great deal
of time on your part.  It's sincerely appreciated.

> As I mention in a paper-in-progress I've 
> published at http://www.howardsilvan.com/HylaFAX/faxfacts.pdf, usually 
> the benefit in "slowing down" is due to the change in protocol, not 
> particularly the speed.  

I will read this.

> For example, I've found V.27 ter to be an 
> extremely robust protocol, albeit slow.  So if there's some sort of 
> line disturbance (i.e. a PBX or digital interference), then a protocol 
> change is more likely the solution than is a change in transmission 
> speed.

OK, you've recently covered this concept with another poster, though I
recall the "pre-selection" of protocol is a bit dicey since so many things
are bound up together (speed and protocol).

> (I'm including myself in the "anyone who knows" category... but I 
> really only belong to the "anyone who may know" category.  I certainly 
> don't put myself in the same "knowing" category as Steve.)

You know better than most, which is all that matters! :)
 
> In overseas communications we generally assume a fair amount of line 
> noise (this is not necessarily true, though).  In such situations, ECM 
> is *highly* advantageous and EOR should be enabled (AT+FRY=4 in Class 
> 2.0).

I've used that, though in Class 2.1.

>  Because you should enable EOR you probably shouldn't use Class 
> 2.1 (V.34 faxing/SuperG3) because you can't do EOR with V.34.  

If I configured the sender to use Class 2.1 + ECM, but the remotes never use
anything faster than 14.4, does this warning still apply?  Or am I still
"using V.34" even though the REMOTE end might not be using it (or a
modulation that indicates V.34 functionality).

> The HylaFAX documentation indicates that users may want to disable ECM 
> on international calls.  I think that the reason this opinion is there 
> is to help users avoid expensive tolls on ECM faxes which tend to take 
> longer than non-ECM faxing.  But if cost isn't more important than is 
> getting a perfect image through, then the documentation is off-base.

Getting a good image through is more important in this application, though
getting SOME image through is more important that just getting
disconnections. :(

> We don't hang up.  If the receiver responds to the post-page message 
> with RTN then we are instructed to retrain and resend the same page 
> because the receiver got an image of too-poor quality.

Hrm, is this a "vulnerable" time in the protocol to losing the connection? 
I see "REMOTE HANGUP"s around these exchanges.

> If you anticipate that HylaFAX will deliver corrupt TIFF to the modem 
> and that the modem can correct it.

Oh, OK.  So it doesn't actually serve to advertise to the remote side that
copy-quality checking should be engaged.

> Honestly, that's the way that T.30 was written.

*SIGH*

> Again, carrier drops are a core part of T.30 specification.  They are 
> required to indicate specific points in the protocol.

Sheesh...  and what was their thinking behind using HDLC ?  Did faxing
originally happen over bizarre X.25-style sync connections or something?

> CVS in Class 1 would give you a better picture of problems on ECM 
> calls.  There are no significant protocol improvements otherwise.

OK.

> The repeated +FNF and +FHR reports indicate that there are a few TCF 
> retrainings going on here, indication of a poor connection. 

ARGH.

> Unfortunately, the modem firmware doesn't seem to "slow down" the 
> communication rate during the retraining... possibly because HylaFAX 
> sent AT+FIS and is trying to control the negotiations that way rather 
> than relinquishing the control to the modem (HylaFAX Class 2 design).

Hrm...  would it be possible to allow for a reduction in speed during such
conditions, or is it a bit difficult because it's somewhat committed to a
certain protocol or what have you?

> But, unfortunately, the receiver seems to have disconnected immediately 
> after sending RTN.

Some fax machines just bail out when they get bad fax data?

> This timeout message is a HylaFAX bug, but didn't influence the 
> problems earlier.  It occurs because HylaFAX doesn't know that the "OK" 
> indicates that "CONNECT" will not be coming, so it keeps waiting for 
> "CONNECT" until the timeout occurs.  The attached patch (untested) 
> should fix this.

Thanks for the patch, and such a detailed response.  You're a Diogenes, Lee.

=R=




____________________ 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@xxxxxxxxxxxx*