Re: flexfax: Q: Retrain Negative -- Giving up after 3 tries?

[David Weiss <dweiss@vic.design.telstra.com.au>]

> Message-ID: <009e01bdc489$5df6c920$30027297@asparks.nss.harris.com>
> From: "Alan Sparks" <asparks@nss.harris.com>
> To: <flexfax@sgi.com>
> Subject: flexfax: Q: Retrain Negative -- Giving up after 3 tries?
> Date: Mon, 10 Aug 1998 11:04:49 -0700
> 
[...]
> Aug 10 10:48:35.67: [29651]: --> [7:+FPTS:2]
> Aug 10 10:48:35.67: [29651]: --> [2:OK]
> Aug 10 10:48:35.67: [29651]: SEND recv RTN (retrain negative)
> Aug 10 10:48:35.67: [29651]: <-- [6:AT+FK\r]
> Aug 10 10:48:37.17: [29651]: --> [8:+FHNG:02]
> Aug 10 10:48:37.17: [29651]: REMOTE HANGUP: Call aborted,  from +FK or <CAN>
> (code 2)
> Aug 10 10:48:37.17: [29651]: --> [2:OK]
> Aug 10 10:48:37.18: [29651]: SEND: Unable to transmit page (giving up after
> 3 attempts); Giving up after 3 attempts to send same page
> "docq/doc766.cover;40", dirnum 0
> Aug 10 10:48:37.18: [29651]: <-- [5:ATH0\r]
> 
> Never can get it to send.  Does anyone have any experiences with this, and
> can give me a clue how to debug these problems?  (Unfortunately, no, don't
> know what machine type I'm trying to hit.)

Alan,

I too, am experiencing the "retrain negative" problem, and in the few
weeks since I first subscribed to the mailing list, there have been
several postings concerning this issue (although very little in the
archives). It seems therefore, that this is a common HylaFAX problem.

Here is what I know about it:

1. HylaFAX incorrectly encodes fax pages for transmission at 9600. In
particular, scan line 19 does not conform to the protocol specification:
it has a zero length run of white picture elements, followed by 187
fill bits and an end-of-line (measured by a protocol analyser). Scan
line 19 is the place where the tag line (ie., the string of text at
the top of every fax page) is spliced to the main page body, so
perhaps the spice routine is failing (I blame Geri Haliwell for that!).

2. Since scan line 19 is blank, many receiving devices accept this
protocol error without complaint. The more pedantic implementations
however, do not. Instead, a "retrain negative" is returned. From the
ITU T.30 (Blue book 1988) page 112:

		Post-message responses

		Retrain negative (RTN) - To indicate that the previous message 
		has not been satisfactorily received. However, further
		receptions may be possible, provided training and/or phasing
		are retransmitted.

You may be interested in comparing this with the definition of the
"retrain positive" primitive, also page 112:

		Retrain positive (RTP) - To indicate that a complete message
		has been received and that additional messages may follow
		after retransmission of training and/or phasing and CFR.

3. There has been some discussion concerning the "correct" response to 
an RTN, and whether HylaFAX is doing it or not. I'm not sure about
that. I do know however, that HylaFAX actually responds to the RTN by
retransmitting the badly encoded page. The receiving device replies with 
another RTN, and so on, until some error limit is reached. In my case
that limit is reached after 9 transmissions of the first page, all of
which I might add, are actually printed by the receiving device and
appear as successful transmissions.

4. Regarding the HylaFAX report; "REMOTE HANGUP". I have noticed that
in a slightly different context HylaFAX claimed that the remote
device had hung up, when in fact it was the transmitting device that
had disconnected the call (as detected by a protocol analyser).
Therefore, the veracity of this report is suspect.
Furthermore, even when HylaFAX transmits to a less-critical receiving
device and no RTN is returned, the transmission if eventually
concluded by the transmitting device disconnecting the call, in the
middle of the sign-off sequence. This usually results in the receiving 
device displaying some sort of error message on its console, but since 
the page(s) got through, the error is frequently not noticed or simply
ignored. 

5. If HylaFAX can be persuaded to transmit at 2400 b/s, rather than
9600, the encoding error sometimes disappears, and so too, do the RTNs.
The difficulty here is in persuading HylaFAX to use 2400 for certain
targets. This is a non-trivial exercise. None of the techniques
described in the documentation (sendfax -B, destctrls) actually
functioned (for me) as advertised. Of course, this could be due to my
ignorance, lack of experience etc, and so I welcome correction.
However I tried everything I could think of for several days with
limited success. The _only_ approach that worked, required hacking of
FaxMachineInfo.c++ to ignore the "info" files, so that the -B option
to sendfax, actually had an effect. 

This last paragraph is not really relevant to your question, but I've
included it in case you are interested in how I resolved my problem.
In turn, I would be interested in your experience, in particular any
light you could shed on configuring HylaFAX (using destctrls etc) 
would be most useful.

thanks
David