HylaFAX The world's most advanced open source fax server

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

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



I tried "Class2ECMType:   2.0" and It seemed to work but then I got a
failure on a new number (session log below).

I then disabled that parameter and added "desiresec:0" to jobcontrols
for all numbers.  It failed again.  the log is identical, bar missing
this line : Reading MMR-compressed image file.

Is there another jobcontrols parameter I should add for something to
do with dataformat?

Thanks for your time so far, Lee.

Jeff

---------------------Session log for new failure--------

Feb 14 11:51:24.46: [25817]: SESSION BEGIN 000000009 XXXXXXXXXXX
Feb 14 11:51:24.46: [25817]: HylaFAX (tm) Version 4.3.1
Feb 14 11:51:24.46: [25817]: SEND FAX: JOB 11 DEST XXXXXXXXXX COMMID
000000009 DEVICE '/dev/tmodem29' FROM 'jeffb <jeffb@xxxxxxxxxx>' USER
jeffb
Feb 14 11:51:24.46: [25817]: <-- [10:AT+FTBC=0\r]
Feb 14 11:51:24.82: [25817]: --> [2:OK]
Feb 14 11:51:24.82: [25817]: <-- [10:AT+FBOR=0\r]
Feb 14 11:51:25.12: [25817]: --> [2:OK]
Feb 14 11:51:25.12: [25817]: <-- [13:AT+FPHCTO=30\r]
Feb 14 11:51:25.40: [25817]: --> [2:OK]
Feb 14 11:51:25.40: [25817]: <-- [24:AT+FDCC=1,5,2,2,3,1,0,0\r]
Feb 14 11:51:25.67: [25817]: --> [2:OK]
Feb 14 11:51:25.67: [25817]: DIAL XXXXXXXXXX
Feb 14 11:51:25.67: [25817]: <-- [15:ATDTXXXXXXXXXX\r]
Feb 14 11:51:37.19: [25817]: --> [5:+FCON]
Feb 14 11:51:39.12: [25817]: --> [110:+FNSF:00 00 31 00 CE B8 80 80 11
85 0D DD 00 00 DD DD 00 00 DD DD 00 00 00 00 00 00 00 00 ED 22 B0 00
00 90 00]
Feb 14 11:51:39.12: [25817]: REMOTE NSF "00 00 31 00 CE B8 80 80 11 85
0D DD 00 00 DD DD 00 00 DD DD 00 00 00 00 00 00 00 00 ED 22 B0 00 00
90 00"
Feb 14 11:51:39.12: [25817]: NSF remote fax equipment: Sharp/Olivetti
Sharp UX-460
Feb 14 11:51:39.81: [25817]: --> [28:+FCSI:"      XX XXXXXXXX   "]
Feb 14 11:51:39.81: [25817]: REMOTE CSI "XX XXXXXXXX"
Feb 14 11:51:40.17: [25817]: --> [21:+FDIS:1,3,0,2,1,0,0,4]
Feb 14 11:51:40.18: [25817]: --> [2:OK]
Feb 14 11:51:40.18: [25817]: REMOTE best rate 9600 bit/s
Feb 14 11:51:40.18: [25817]: REMOTE max A4 page width (215 mm)
Feb 14 11:51:40.18: [25817]: REMOTE max unlimited page length
Feb 14 11:51:40.18: [25817]: REMOTE best vres 7.7 line/mm
Feb 14 11:51:40.18: [25817]: REMOTE format support: MH, MR
Feb 14 11:51:40.18: [25817]: REMOTE best 20 ms, 10 ms/scanline
Feb 14 11:51:40.18: [25817]: USE 9600 bit/s
Feb 14 11:51:40.18: [25817]: SEND file "docq/doc11.ps;c1"
Feb 14 11:51:40.18: [25817]: USE A4 page width (215 mm)
Feb 14 11:51:40.18: [25817]: USE unlimited page length
Feb 14 11:51:40.18: [25817]: USE 7.7 line/mm
Feb 14 11:51:40.18: [25817]: USE 2-D MR
Feb 14 11:51:40.18: [25817]: USE 10 ms/scanline
Feb 14 11:51:40.18: [25817]: <-- [24:AT+FDIS=1,3,0,2,1,0,0,3\r]
Feb 14 11:51:40.44: [25817]: --> [2:OK]
Feb 14 11:51:40.44: [25817]: <-- [7:AT+FDT\r]
Feb 14 11:51:46.43: [25817]: --> [21:+FDCS:1,3,0,2,1,0,0,4]
Feb 14 11:51:46.89: [25817]: --> [7:CONNECT]
Feb 14 11:51:46.89: [25817]: SEND wait for XON
Feb 14 11:51:46.89: [25817]: --> [1:]
Feb 14 11:51:46.89: [25817]: SEND begin page
Feb 14 11:51:46.93: [25817]: Reading MMR-compressed image file
Feb 14 11:51:46.95: [25817]: <-- data [1030]

(snipped data lines)

Feb 14 11:52:25.80: [25817]: <-- data [1024]
Feb 14 11:52:25.80: [25817]: <-- data [312]
Feb 14 11:52:41.36: [25817]: SENT 33076 bytes of data
Feb 14 11:52:41.36: [25817]: <-- data [2]
Feb 14 11:52:41.42: [25817]: SEND end page
Feb 14 11:52:44.01: [25817]: --> [2:OK]
Feb 14 11:52:44.01: [25817]: SEND send EOP (no more pages or documents)
Feb 14 11:52:44.01: [25817]: <-- [9:AT+FET=2\r]
Feb 14 11:52:58.76: [25817]: --> [8:+FHNG:51]
Feb 14 11:52:58.76: [25817]: REMOTE HANGUP: RSPREC error/got DCN (code 51)
Feb 14 11:52:58.76: [25817]: <-- [5:ATH0\r]
Feb 14 11:52:58.84: [25817]: --> [2:OK]
Feb 14 11:52:58.84: [25817]: SESSION END



On 14/02/07, Lee Howard <faxguy@xxxxxxxxxxxxxxxx> wrote:
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*




Project hosted by iFAX Solutions