flexfax: How to handle PIP

[Erik.OSTHOLS@oecd.org]

I have  HylaFAX v4.0pl2 installed on a FreeBSD 2.2.8 box, using a MultiTech
MT2834ZDXI modem (don't know how old it is, it was around at my workplace)
on /dev/cuaa0 (callout line). The system worked well for most faxen out of
the box (though supplying a default cover page without the SGI logo might
save people without the inclination to do LaTeX and/or PostScript hacking
some grief), but could not communicate with a particular fax. The problem
always occurred after the first page was sent, when trying to obtain
confirmation of the first page having been sent. Then the following would
happen:

>Mar 18 12:32:59.92: [ 3435]: <-- data [2]
>Mar 18 12:32:59.92: [ 3435]: SEND end page
>Mar 18 12:33:15.32: [ 3435]: --> [16:]
>Mar 18 12:33:15.32: [ 3435]: --> [2:OK]
>Mar 18 12:33:15.32: [ 3435]: SEND send MPS (more pages, same >document)
>Mar 18 12:33:15.32: [ 3435]: <-- [9:AT+FET=0\r]
>Mar 18 12:33:31.69: [ 3435]: --> [7:+FPTS:5]
>Mar 18 12:33:31.69: [ 3435]: --> [2:OK]
>Mar 18 12:33:31.69: [ 3435]: SEND recv PIP (procedural interrupt positive)
>Mar 18 12:33:31.69: [ 3435]: SEND FAX (00000036): FROM >daemon@osthols TO
200420685227371 (page 1 of 4 sent in 0:49)
>Mar 18 12:33:31.69: [ 3435]: <-- [6:AT+FK\r]
>Mar 18 12:33:33.29: [ 3435]: --> [7:+FHNG:2]
>Mar 18 12:33:33.29: [ 3435]: REMOTE HANGUP: Call aborted,  from +FK or
><CAN> (code 2)

As my modem runs as a Class 2 fax only, I checked in the code of
Class2Send.c++, and found that if it receives a PIP from the remote fax when
trying to get confirmation for the page just sent, it concludes that there
has been an "operator intervention" and quits, which is what happened in the
session above. However, in the code it is also stated, that PIP means that
there has been a request for interrupt, but that the page just sent has been
sent OK. Since I knew there had been no "operator intervention" for the
receiving fax, and that the first page had indeed been received OK, I
decided to simply hack the sending code to make it wait a while (I used 10
secs, but that may be overkill), and then just go on if it gets a PIP. I put
in a safeguard so if it gets three consecutive PIPs it aborts as before.
This seems to work fine, confirming my suspicion that the PIP, at least when
coming from this fax, doesn't necessarily mean that things are broken, just
that it needs some time to think things over before receiving the next page.
All pages now get sent 
as they should, with no errors in the logs (it also works with the more
"normal" fax I tested on, that didn't have the PIP problem). It is also a
fact, that sending from a standard "hardware fax" (an old Hitachi model) to
the fax concerned, there are usually no problems, despite the PIPs. Would it
be desirable to change the HylaFAX code that takes care of PIPs (I noticed
there is something similar for the Class 1 code), or have I violated the fax
protocols in a horrible way? Perhaps the elegant solution would be to poll
the sending fax for a while to see if it recovers within a "reasonable" time
frame, and if it does, then go on, if not, then abort? On the off chance
that you wish to respond, please do so to my normal e-mail address, since I
am not (yet) a subscriber to this mailing list.

Greetings,




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