Re: [hylafax-users] problem receiving some faxes

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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*