Re: [hylafax-users] Re[2]: "COMREC invalid response.." persisting in HylaFAX+ 5.2.0

["Andrew Rinaldi" <andrew.rinaldi@xxxxxxxxxxxx>]

Hi Walter,
 
Do you know the make and model of the receiver ?
 
Regards
 
Andrew Rinaldi
Mainpine Developer Support
USA +1 503 822 9944 | UK +44 8458 909438
andrew.rinaldi@xxxxxxxxxxxx | www.mainpine.com <http://www.mainpine.com/> 
  _____  

From: hylafax-users-bounce@xxxxxxxxxxx
[mailto:hylafax-users-bounce@xxxxxxxxxxx] On Behalf Of Walter Hop
Sent: 05 January 2008 00:54
To: Lee Howard
Cc: hylafax-users@xxxxxxxxxxx
Subject: [hylafax-users] Re[2]: "COMREC invalid response.." persisting in
HylaFAX+ 5.2.0



[in reply to faxguy@xxxxxxxxxxxxxxxx, 12-12-2007]




Hi Lee,




it's been a while, good 2008!




Meanwhile the festivities are over and I have created a test setup at
another location (to rule out local line problems) with the same software
and hardware configuration. To recap, I receive "COMREC invalid response
received to PPS" consistently for a small number of remote destinations.




I've followed your test plan (which was very detailed, thank you), and it
turns out that ECM seems to be the culprit. When I disable ECM mode with the
-E parameter, faxes to the problem destination succeed (for the first time
in ca. 100 attempts, so this is probably no coincidence.)




> Okay, so I think that these are the possibilities...

> 1) The receiver may not like the V.17 short-train that this modem 

> produces.  In other words, a slight incompatibility between the modem 

> and the receiver.

> 2) There may be a particular audio distortion between the modem and the

> receiver that amount to the same as #1.

> 3) The receiver may not like the MMR image data that we're sending... or

> there is some kind of incompatibility between HylaFAX's encoder and the

> receiver's MMR decoder.

> 4) There may be some unlikely quirk in our ECM protocol that the 

> receiver does not like.

> 5) The receiver always sends DCN in response to EOP (and thus is broken).




Test results:




>   echo "This is just a test." | textfmt > /tmp/test.ps

>   sendfax -n -3 -t 1 -F "test" -h cuad0@ -d 003232xxxxxx /tmp/test.ps

> This control test should result in the same thing: "COMREC invalid 

> response received to PPS."  




This is correct.




>   ModemSoftRTFCC: no

> Please run the following tests in this order.  To test #5 please run:

>   sendfax -n -3 -t 1 -F "test" -h cuad0@ -d 003232xxxxxx /tmp/test.ps 

> /tmp/test.ps

> This *should* fail after the first page, after PPS-MPS instead of 

> PPS-EOP.  




This is correct.




> To test #3 please run:

>   sendfax -n -1 -t 1 -F "test" -h cuad0@ -d 003232xxxxxx /tmp/test.ps




This is correct (still fails).




> To test #4 please run:

>   sendfax -n -1 -E -t 1 -F "test" -h cuad0@ -d 003232xxxxxx /tmp/test.ps

> If this fails then we know that the problem is not with any particulars

> of the ECM protocol as employed by the receiver or HylaFAX.  If it 

> succeeds, then stop; #4 is likely the issue; again, let me know if the

> receiver is printing out all of the pages.




The fax was successful with this parameter.




Unfortunately I can't get involved much with the recipient of the fax
(business relation of our customer)... They have called however to say that
they were getting annoyed by many duplicate faxes, and I have not heard of
missing faxes, so I'm pretty sure that faxes are actually printed out on the
remote side.




Are there any further debugging possibilities to pursue?




Meanwhile I'll keep using the -E parameter for those destinations, to see if
the results remain consistently good.




Kind regards,

Walter Hop







-- 

 Walter Hop <walter@xxxxxxxxxxxx> | Lifeforms | www.lifeforms.nl

 The Estimator's Rule:

 It always takes longer than estimated, even after accounting for the
Estimator's Rule.

<<attachment: winmail.dat>>