|
Hylafax Mailing List Archives
|
[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*
