Re: [hylafax-users] LOG EXPLAIN (RTN meaning)

[Jonny Berthiaume <jberthiaume@xxxxxxxxxx>]

Hi,

First, I just assure you it didn't give me a greater sense of joy in 
life... I just wanted to point out that it wasn't entirely true. I have 
a great respect for your work, it's been helpfull through all the forums 
I have consulted.

I understand why the fax machine cannot resend the page, I didn't 
thought about it that way. But, you must admit that a sheet-fed fax 
machine where it does not have sufficient memory to store the entire 
page image is nowadays somewhat a rare bird in the jungle.

I was refering to an impressive number of Ricoh multi-function products 
which treat the RTN as "Over and out -- hang  up ...". I don't know if 
all their product use that code that way, but there is a large selection 
of models who does. I didn't come across any other fax machine that 
respond that way, but I believe that if a world wide company like Ricoh 
is doing it, I guess others do it as well. And with this fact in hand, I 
might not be so prompt to delete the specified statement in the man pages.

I am confident you will make the right decision concerning the 
modification of the man page if needed. You are way more experienced 
than me in this domain and I you will be better suited to know how to do it.

Have a nice day.

Jonny
--
Jonny Berthiaume
Programmeur-analyste
Tél...: 418-864-7721
Fax...: 418-263-3147
Email.: JBerthiaume@xxxxxxxxxx


Lee Howard wrote:
> 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*