Re: [hylafax-users] LOG EXPLAIN

["Grygoriy Dobrovolskyy" <megahohol@xxxxxxxxx>]

lol owned;) sorry for spam but it was too tempting to say that.

2006/11/20, 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*