Re: [hylafax-users] COMREC invalid response received to PPS.

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.05.16 05:30 Simon Perry wrote:
> Hi All,
>
> I am having problems sending a fax with two parts, one pdf and one 
> tiff using hylafax 4.2.0 CVS built 02 May.

Have you modified the source code at all?  It appears to be doing 
something other than normal (see below), and I cannot reproduce it here 
with a PDF and a TIFF.

> It would appear that hylafax tries to send twice, after receiving an 
> "COMREC invalid response received to PPS" error on the second page of 
> the first try. On the second attempt only the second page is 
> transmitted and that is the only page received.

On the second call only the last page is sent because the first page 
was already confirmed as received by the receiver.

> If I send the pages separately no error occurs, two or more page pdf 
> or ps files also cause no error.

So the error only occurs with a pdf and a tiff?  Does it always occur 
with a pdf and a tiff?  How is the fax job submitted (what client)?

> What I am wondering here is if the issue lies with Hylafax or the 
> receiver,

In this case, HylaFAX is doing something screwy.

> if I follow hylafax's logic correctly then it is only resending page 
> 2 as the receiver acknowledged that it got page one on the first try. 
> However when the receiver encountered an error it scrapped the whole 
> transmission.

If the receiver discards a page after it has confirmed the receipt of 
that page with the MCF, then it is the receiver's fault for discarding 
it, not the sender's fault for not retransmitting it.

> May 16 12:57:21.73: [21355]: <-- [9:AT+FTH=3\r]
> May 16 12:57:21.77: [21355]: --> [7:CONNECT]
> May 16 12:57:21.77: [21355]: <-- data [7]
> May 16 12:57:21.77: [21355]: <-- data [2]
> May 16 12:57:23.09: [21355]: --> [2:OK]
> May 16 12:57:23.09: [21355]: SEND send PPS (partial page signal)
> May 16 12:57:23.09: [21355]: SEND send EOM (more documents)

This is the part that's messed-up.  HylaFAX faxq doesn't currently 
schedule jobs with EOM page-separators, so something has gone wrong 
here to make this happen.  The protocol following EOM is much different 
than the protocol following MPS (which is what should have been sent), 
and because the protocol followed here is for MPS and not EOM, that's 
why it gets messed up.

> May 16 12:57:54.20: [21355]: <-- [9:AT+FTH=3\r]
> May 16 12:57:54.24: [21355]: --> [7:CONNECT]
> May 16 12:57:54.24: [21355]: <-- data [7]
> May 16 12:57:54.24: [21355]: <-- data [2]
> May 16 12:57:55.56: [21355]: --> [2:OK]
> May 16 12:57:55.56: [21355]: SEND send PPS (partial page signal)
> May 16 12:57:55.56: [21355]: SEND send EOP (no more pages or 
> documents)
> May 16 12:57:55.56: [21355]: <-- [9:AT+FRH=3\r]
> May 16 12:57:55.60: [21355]: --> [7:CONNECT]
> May 16 12:57:56.10: [21355]: --> [2:OK]
> May 16 12:57:56.10: [21355]: SEND recv MCF (message confirmation)

This is funny, though.  It seems that the mis-behavior on HylaFAX's 
part has evoked a bug in the receiver.  We didn't renegotiate (redo 
Phase B) after EOM and just sent the data.  We sent PPS-EOP, an 
ECM-mode signal, but the receiver sends MCF, a non-ECM-mode signal.  
Without knowing any better, it would almost appear as if the receiver 
is actually confirming the second page, and that's screwy because the 
ECM data isn't even end-to-end TIFF - it has to be assembled by the 
receiver.

Anyway, ignore the last part.

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*