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

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.10.15 17:50 An Intrepid HylaFax User wrote:

> > 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.

Don't get me wrong in what I'm saying here... I think V.34 is a 
wonderful thing... but I have a personal belief that V.34 should only 
be attempted when the last fax we sent to that destination went through 
without error and without EOR at V.34 speeds... and if not, V.34 should 
not be attempted.  This currently cannot be configured with HylaFAX.  
Why do I think this way?  Because CTC is specifically omitted from 
V.34-faxing's protocol and each block can therefore only be attempted 
four times before giving up and moving on.  If we're talking about MMR 
image data, then EOR will mean image truncation.  Some receivers 
thoughtfully will disconnect upon receiving EOR with MMR image data (in 
hopes that the error triggers a second attempt by the sender), but some 
receivers won't do this.  A thoughtful sender would likewise initiate a 
disconnect if EOR were required with MMR image data.  Because Class 2 
hides the protocol from us, we don't know if EOR was communicated or 
not, so building this intelligence fully into HylaFAX is impossible 
with Class 2.

Whether or not this "thoughtfulness" is programmed into any particular 
modem... it's hard to say.

> >  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?

Not likely.

> 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).

I don't understand the underpinnings of how V.8 handshaking/Class 
1.0/Class 2.1 work well enough to know whether or not V.8 still works 
at 14400 or not, but I suspect that it means not, and so if we see the 
remote supporting 14400 it would mean that the remote does not support 
V.8 handshaking.

> > 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.

All I can say is to attempt faxing with Class 1 and see if you get the 
same problem.  If you do, then yes, it must be a protocol weakness or a 
broken receiver.  If not, then something must be wrong with the 
firmware (yes, not the thing you'll want to hear).

> > 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?

Things work vastly different with V.8 handshaking, by the way, and 
except for the lack of CTC support, it's quite a superior protocol as 
far as these things go.  That won't help you for this receiver, though.

> > 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?

Honestly, I don't know how the modem firmware interprets AT+FIS 
commands or if we did without the AT+FIS command if the modem would 
even reduce speed during TCF before responding with the +FCS: report.  
I suspect that different modems would behave differently.  That's the 
big downside to Class 2: a lack of real control by the DTE.  HylaFAX 
could probably cope with an +FCS: report that varied from the AT+FIS 
command... but I don't suspect a modem is going to defy the AT+FIS 
command like that.

> > But, unfortunately, the receiver seems to have disconnected
> immediately
> > after sending RTN.
>
> Some fax machines just bail out when they get bad fax data?

Yes, as I noted above with EOR-reception.  It may happen with other 
cases, also.  But realize that on a connection with a lot of 
interference the remote may disconnect because of the line conditions 
and not particularly because it got bad fax data.  That was nothing we 
could control.

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