flexfax: Endless RTN -- seems to be fixed now!

[Dmitry Bely <dbely@mail.ru>]

I am glad to inform you that after a couple of days of hard work I have
found a bug which caused infamous "endless RTN" problem. There is nothing
special - Hylafax just violated T.4/T.class2 protocol specs :-)

To be more specific, T.4/T.class2 (Class 2.0 standard) defines the
following format for the Phase C data (core of G3 fax protocol):

<EOL>
<1-st encoded raw>
<EOL>
<2-nd encoded raw>
<EOL>
...
<last encoded raw>
<RTC>
<DLE><EOP>

But Hylafax generates:

<EOL>             \
<1-st encoded raw> \
<EOL>               \
<2-nd encoded raw>   \ from Hylafax-generated g3 TIFF contains it
<EOL>                /
...                 /
<last encoded raw> /
<RTC>             /     
<RTC>             -- sendRTC()
<DLE><EOP>

(not always -- just when no chopping happened. See the attached patches for
details).

As you can see, RTC is transmitted twice, and it may cause missing of the
RTC/EOP and generating RTN/other transmission errors by the remote fax
machine. Endless RTN (and possibly other unidentified errors) is here.

Well, the attached patches seems to fix that. They are still experimental
and possibly incomplete, but they work for me (tested with Zyxel 1496E in
Class 2.0 mode).  A Panasonic BX780 fax machine, connected to the server
via PBX, i.e. directly, now successfully generates MCF (always responded
with RTN before). Could you, folks, check if they work for you also.

Any comments are always welcome,

Hope to hear from you soon,
Dmitry

P.S. I am also going to publish tsi processing bug fixes (after some
testing). Stay tuned :-)

Class2Send.diff

Class20.diff

G3Encoder.diff