HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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*




Project hosted by iFAX Solutions