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] problem receiving some faxes



Sean Proctor wrote:

Jun 17 07:22:19.18: [18337]: <-- [10:AT+FRM=96\r]
Jun 17 07:22:19.48: [18337]: --> [8:+FCERROR]
Jun 17 07:22:19.48: [18337]: <-- [10:AT+FRM=96\r]
Jun 17 07:22:19.78: [18337]: --> [8:+FCERROR]


There's a new feature in 4.2.2 that is called "Class1RMPersistence" it is used in conjuction with "Class1AdaptRecvCmd" (if available).

The Comtrol RocketModems use Rockwell/Conexant chipsets, and HylaFAX can be optimized with those chipsets by setting "Class1RMPersistence: 1" (the default is 2). However, you said that you're using a RocketModem II, and every RocketModem II that I have ever used also supports "adaptive receive" (not to be confused with "adaptive answer"). Which means that you probably want to leave Class1RMPersistence as it is, but set "Class1AdaptRecvCmd: AT+FAR=1". Using adaptive receive is a better thing than relying on +FCERROR.

If you re-run faxaddmodem and then choose Class 1.0 this will happen for you.

Jun 17 07:22:19.78: [18337]: <-- [9:AT+FRH=3\r]
Jun 17 07:22:45.08: [18337]: --> [7:CONNECT]
Jun 17 07:22:46.02: [18337]: --> [2:OK]
Jun 17 07:22:46.02: [18337]: RECV recv EOP (no more pages or documents)
Jun 17 07:22:46.02: [18337]: <-- [9:AT+FRS=7\r]
Jun 17 07:22:46.14: [18337]: --> [2:OK]
Jun 17 07:22:46.14: [18337]: <-- [9:AT+FTH=3\r]
Jun 17 07:22:46.19: [18337]: --> [7:CONNECT]
Jun 17 07:22:46.19: [18337]: <-- data [3]
Jun 17 07:22:46.19: [18337]: <-- data [2]
Jun 17 07:22:47.50: [18337]: --> [2:OK]
Jun 17 07:22:47.50: [18337]: RECV send RTN (retrain negative)
Jun 17 07:22:47.50: [18337]: <-- [9:AT+FRH=3\r]
Jun 17 07:22:47.89: [18337]: --> [7:CONNECT]
Jun 17 07:22:48.24: [18337]: --> [2:OK]
Jun 17 07:22:48.24: [18337]: RECV FAX: COMREC invalid response received


Your logging isn't set high enough to know what the "invalid response" actually was. Set "SessionTracing: 0xFFF" if you want me to be able to help you with that. However, the situation is this:

1) The sender transmits training
2) we respond with a "training successful" response
3) we begin to listen for the high-speed image data carrier
4) The sender transmits low-speed EOP signal
5) the modem responds +FCERROR and we are able to get that signal
6) the best thing we can do is send RTN, so we do
7) the sender responds with something other than TSI/DCS (probably DCN), so we hang up


The real question isn't so much what the signal in #7 was, but rather, why the sender didn't appear to transmit any high-speed data in #3. If this is particularly disturbing to you please contact the sender and ask them what happened. My guess would be that an error occurred on their end (i.e. they didn't feed the paper in correctly or something like that).

When this kind of problem does occur in non-error conditions, then full recovery in non-ECM sessions is rather difficult, because senders do not often interpret the RTN signal as they should (many sender's *can't* retransmit a page because they don't store the image in memory - they scan and transmit lines-at-a-time).

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