Re: [hylafax-users] RSPREC error/got DCN (code 51) since hylafax upgrade

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Jeff Brickwell wrote:

> Jan 16 16:13:08.75: [13556]: --> [21:+FDIS:1,5,2,2,3,1,0,3]
> Jan 16 16:13:08.75: [13556]: --> [2:OK]
> Jan 16 16:13:08.75: [13556]: REMOTE best rate 14400 bit/s
> Jan 16 16:13:08.75: [13556]: REMOTE max A3 page width (303 mm)
> Jan 16 16:13:08.75: [13556]: REMOTE max unlimited page length
> Jan 16 16:13:08.75: [13556]: REMOTE best vres 7.7 line/mm
> Jan 16 16:13:08.75: [13556]: REMOTE best format 2-D MMR
> Jan 16 16:13:08.75: [13556]: REMOTE supports T.30 Annex A, 64-byte ECM
> Jan 16 16:13:08.75: [13556]: REMOTE best 10 ms/scanline
> Jan 16 16:13:08.75: [13556]: USE 14400 bit/s
> Jan 16 16:13:08.75: [13556]: USE 10 ms/scanline
> Jan 16 16:13:08.75: [13556]: SEND file "docq/doc1149720.ps;01"
> Jan 16 16:13:08.75: [13556]: USE A4 page width (215 mm)
> Jan 16 16:13:08.75: [13556]: USE unlimited page length
> Jan 16 16:13:08.75: [13556]: USE 7.7 line/mm
> Jan 16 16:13:08.75: [13556]: USE 1-D MH


The basic, fundamental difference that occurs between the successful and 
the failed sessions is that in the former ECM is not used with MH 
compression and in the latter ECM is used - along with MMR image data 
compression.

So the solution, at least for the problematic destinations, is to 
disable ECM from being used to them.  You should be able to do that in 
JobControl with DesiredEC, but I seem to recall some bug in that feature 
that is only fixed in HylaFAX+.  You could just disable the modems from 
supporting ECM, too.

Your modems are curious, by the way, and maybe that's part of the 
problem.  Note that the modems operate in Class 2 (not Class 2.0/2.1).  
And yet they appear to be following the Class 2.0 spec in some ways.  In 
particular, the +FDIS:1,5,2,2,3,1,0,3 response appears to indicate ECM 
support (the 6th parameter) in Class 2.0 mannerisms.  In Class 2, 0 = no 
ECM, 1 = 64-byte ECM, and 2 = 256-byte ECM.  It's extremely unlikely 
that a receiver either does not support 256-byte ECM or even just 
indicates a preference for 64-byte ECM.  So it leads me to believe that 
there is some discrepancy in how closely the modem follows spec.

This is not that uncommon for "modern" Class 2 devices.  They seem to 
want to keep old Class 2 commands and responses and yet interpret them 
according to T.32 instead of SP-2388-A... and they also try to throw in 
modern technology under the old spec where it doesn't always fit very well.

So I'm not trying to excuse HylaFAX at all, but rather trying to explain 
that because the modem doesn't seem to be following spec we can't really 
be sure... without some testing or without involving the manufacturer as 
to what's really happening and what the appropriate action is to take in 
the modem config file.  However, I would suspect that you should add 
this to your modem config file:

 Class2ECMType:   2.0

That may resolve things... it may not.

The reason why things changed for you between 4.2.1 and 4.3.0 is because 
somewhere in there I taught the Class 2 driver that it was okay to try 
to use 64-byte ECM.

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*