Re: [hylafax-users] LOG EXPLAIN

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Jonny Berthiaume wrote:

> For once, Mr Howard is a bit mistaken.


If it gives you a greater sense of joy in life, I am a bit mistaken more 
than just a bit.

> You see, HylaFAX treat RTN signal the way it should be as T.30 
> specifications.
>
> But if you read the man pages for the RTNHandlingMethod, you will 
> notice this:
>
>   "There is a non-written rule among fax developers,
>    that RTN means ``over and out''  --  hang  up
>    immediately and never try to send the same page
>    to the same destination again"


This part of the man page was written by Dmitry Bely, and he was 
referencing information coming from Harald Pollack.  I have the greatest 
respect for both of them, and I do miss my e-mail chats with Harald 
regarding T.30 specifics.  However, I must say that I disagree with this 
statement in the man page.  So if this is what you disagree with, then 
we're actually in agreement.

The RTN signal is defined by T.30 this way:  "To indicate that the 
previous message has not been satisfactorily received.  However, further 
receptions may be possible, provided training is retransmitted."  And, 
in the flowcharts the sending of RTN is entirely based upon *copy quality*.

Yes, "non-written" rules are nasty creatures to disprove.  As far as I 
can understand, this definition by T.30 contradicts what the man page 
says.  The man page says to never retransmit the same page.  Yet the 
spec says that further receptions are possible after retraining 
(including, I expect, the one that was just rejected - as it's not 
specifically stated otherwise).  Indeed, I've not even seen behavior by 
fax machines or fax softwares to indicate the "over and out" behavior 
mentioned by the man page.

I've been tempted on more than one occasion to simply rewrite the man 
page there.  Maybe I still will - especially now that it seems to bother 
someone else.  I haven't done it yet out of respect for what Dmitry and 
Harald were trying to say.

What they were trying to say is this... in perhaps a situation where a 
fax receiver has a broken T.4 decoder or where the fax sender has a 
broken T.4 encoder - or maybe just a situation where the two are 
slightly incompatible... no matter how many times the page data is 
retransmitted the receiver will not be alble to produce a page with 
sufficitient copy quality.  Remember that TCF passed fine already - so 
it could be justly assumed that the communication channel is clear 
enough for the modulation.  So by that it could be said that any copy 
quality problems could be a result of a T.4 incompatibility between the 
endpoints.

Maybe that was true at one time years and years ago.  However, I don't 
see that being the case any more.  I don't know of any modern T.4 (or 
T.6) incompatibilities out there.  Indeed, some of that may actually be 
due to Sam Leffler's efforts with libtiff - as it can be used in just 
about any application - giving a common base for T.4 reference.

> The sender in this case just sent the "DCN" (disconnect) signal,
> probably because it doesn't respect T.30 specifications and not 
> because it is incapable of retransmitting pages. I don't agree with 
> that methode


I don't agree with that method either, but from the session log it is 
quite clear that the sender did not want to retransmit, and we have no 
control over that decision.  However, if you disagree with my 
interpretation here, consider a sheet-fed fax machine where it does not 
have sufficient memory to store the entire page image and where the 
mechanics of the machine do not allow it to "roll back" the page.  (I've 
never seen a machine roll back a page.)  This machine will not be able 
to retransmit a page after RTN.

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*