HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

PIP revisited



The following code in HylaFAX v4.0pl2, file faxd/Class2Send.c++, has me
wondering about the way PIP requests are treated:
----snip-----
                case PPR_PIP:           // page good, interrupt =
requested
                case PPR_RTP:           // page good, retrain requested
                    countPage();        // bump page count
                    notifyPageSent(tif);// update server
                    if (pph[2] =3D=3D 'Z')
                        pph.remove(0,2+5+1);    // discard
page-chop+handling
                    else
                        pph.remove(0,3);        // discard =
page-handling
info
                    ntrys =3D 0;
                    if (ppr =3D=3D PPR_PIP) {
                        emsg =3D "Procedure interrupt (operator
intervention)";
                        goto failed;
                    }
----snip----

According to a response I got on this list some time ago, a PIP signals =
that
someone has "lifted the receiver" on the fax line, and the fax =
transmission
has to be interrupted. This is OK, only from the above code it seems =
that
PIP means that yes, the transmission should be interrupted, but at =
least the
latest page was sent OK. However, the following code tells the program =
to
jump to label "failed" if a PIP is received, and as far as I understand =
(and
have been able to tell from real transmission logs) this means that the
latest page will *not* be logged as having been sent. Is my =
understanding of
the situation correct? If so, is this a bug or a feature? Also, when =
will we
see v4.1 of HylaFAX? I saw some mails about this some time ago, but =
then
there was silence. As I understand it, the designated maintainer
("Mathias"?) is no longer active but has not arranged for a successor =
to
take over. I also understand that there is a 4.1 waiting in the wings, =
but
for some reason it is not being released. If it is, please release it. =
I
think it is long overdue, and this excellent software deserves better =
than
to die from malnutrition.

Erik =D6sthols
TDB Project Coordinator
OECD/NEA Data Bank
12, bd. des =EEles
F-92130 Issy-les-Moulineaux
France
Tel: +33-(0)1-45 24 10 83
Fax: +33-(0)1-45 24 11 26
E-mail: erik.osthols@oecd.org or erik.osthols@nea.fr




Project hosted by iFAX Solutions