Re: flexfax: Re: Hylafax question

[Dmitry Bely <dbely@mail.ru>]

Giulio Orsero <giulioo@pobox.com> writes:

> >- added the RTNHandlingMethod option, allowing you to select more robust
> >method of handling RTN ("giveup" or "ignore" besides default "retransmit")
> 
> Please, where is the patch for this new feature?
> When I tried your last public patch for RTN I still had problems with
> class1.

Possibly there are some more bugs (if you really describe the bug) that
have not been fixed yet :-( I could try to fix these bugs if I can
reproduce them (and have enough time).

> Is this in a new patch?

Yes. But it's against current CVS and so was only published in
hylafax-devel mailing list. Wait for 4.1 beta3 :-)

> If someone uses "ignore", does this mean that Hylafax would terminate
> the connection (after sending the page just once) logging a success
> (this is what I'd like)?

Here is the description:

RTNHandlingMethod

Specifies how to react to RTN signal, received from the remote;
one of ``Retransmit'', ``Giveup'' and ``Ignore''. ``Retransmit''
assumes that the page is not sent succesfully if RTN signal has been received.
Hylafax will made up to 2 additional attempts to send the page,
decreasing signalling rate and retraining. If RTN is still there,
it will place up to 2 additional calls. So if the remote always respond with
RTN, the page will be send 9 times. Although this algorithm complies with
T.30 specs and was originally implemented by Sam Leffler as the only
possible choice, real fax machines behave completely different. 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. That is because RTN usually indicates problems with flow control,
incorrectly encoded T.4 data, incompatibility between local and remote
equipment etc., but very rarely is caused by the real noise on the line.
This ``over and out'' behaviour can be activated by ``Giveup'' value.
There is also third option, not so radical as ``Giveup''. Yes, we will never
retransmit the page, but we can try to send the next page, and let the
remote to decide what to do (accept our decision or hang up). Thus one page will
(or will not) be missed but we have a chance to successfully send all other pages.
This behaviour can be activated by ``Ignore'' value.

> Would this affect "no response to MPS" too?

No. It seems that for Class 2/2.0 "no response to EOP/MPS" is firmware
related (if it's really abnormal -- EOP was present, but DCE failed to
recognize it). The situation can be improved for Class 1, but that is not
easy task, mostly because it's hard to reproduce the bug (and of course
requires strong T.30/Class1 knowledge). The other problem is that currently
I have not enough spare time to investigate/fix this issue...

Hope to hear from you soon,
Dmitry