Re: [hylafax-users] R: Received faxes resent unnecessarily

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Mauro Crisanti wrote:

> > Nov 07 12:51:54.01: [ 5733]: RECV send MCF (message confirmation)
> > Nov 07 12:51:54.01: [ 5733]: RECV FAX (000062459): from 0117712525, page 2 in 0:32, INF, 3.85 line/mm, 2-D MMR, 9600 bit/s
> > Nov 07 12:51:54.01: [ 5733]: RECV FAX (000062459): recvq/fax000066812.tif from 0117712525, route to <unspecified>, 2 pages in 1:24
> > Nov 07 12:51:54.01: [ 5733]: <-- [9:AT+FRH=3\r]
> > Nov 07 12:51:55.14: [ 5733]: --> [10:NO CARRIER]
> >    

I'm not sure what NO CARRIER means after AT+FRH=3 on an analog modem.  
On some digital modems it means that the line was disconnected.  In any 
case, it certainly represents a carrier detection error, and my guess is 
that the error came from within the modem itself.  See below...

> > Nov 07 12:56:12.62: [ 5733]: RECV send MCF (message confirmation)
> > Nov 07 12:56:12.63: [ 5733]: RECV FAX (000062470): from 0117712525, page 2 in 0:17, INF, 3.85 line/mm, 2-D MMR, 9600 bit/s
> > Nov 07 12:56:12.63: [ 5733]: RECV FAX (000062470): recvq/fax000066823.tif from 0117712525, route to <unspecified>, 2 pages in 1:08
> > Nov 07 12:56:12.63: [ 5733]: <-- [9:AT+FRH=3\r]
> > Nov 07 12:56:13.08: [ 5733]: --> [7:CONNECT]
> > Nov 07 12:56:14.02: [ 5733]: --> [2:OK]
> >    

Your logging isn't sufficient enough to say, exactly, what the HDLC 
frame received here represented.  If it was PPS-EOP again or CRP then 
4.2.1 didn't handle it correctly, and that would cause the matter you're 
seeing.  My guess, though, is that it's still related to the same 
problem as everything else...

> > Nov 07 13:58:27.85: [ 5733]: <-- [9:AT+FTH=3\r]
> > Nov 07 13:58:35.40: [ 5733]: --> [0:]
> > Nov 07 13:58:35.40: [ 5733]: RECV send MCF (message confirmation)
> > Nov 07 13:58:35.40: [ 5733]: RECV FAX (000062536): from 0774 307360, page 2 in 0:49, INF, 3.85 line/mm, 2-D MMR, 14400 bit/s
> > Nov 07 13:58:35.40: [ 5733]: RECV FAX (000062536): recvq/fax000066889.tif from 0774 307360, route to <unspecified>, 2 pages in 1:23
> > Nov 07 13:58:35.40: [ 5733]: <-- [9:AT+FRH=3\r]
> > Nov 07 13:58:35.54: [ 5733]: --> [8:AT+FRH=3]
> >    

This is an obvious case of the big fault with USR modems in Class 1.  In 
some cases (and I'm not certain what the catalyst is) the USR modem will 
reset itself around the point in time where MCF is transmitted.  This 
causes the MCF signal to not be sent properly.  This causes the modem to 
go into a state that confuses HylaFAX.  This probably causes the modem 
to go on-hook.

It will sometimes show up like this.  Sometimes you'll see some garbage 
in the terminal.  Sometimes it won't show up until it's too late to get 
recognized easily.

The downside, though, is that USR's are even worse in Class 2.0 than 
they are in Class 1.

That said...

We didn't see too much of these kinds of problems with USR modems until 
after we changed the software delays in receiving to AT+FRS=7.  So I've 
had a suspicion that these modem crashes are due to some flaw in the 
modem firmware in performing AT+FRS=7.  So you could try this change in 
your modem config file, and see if it helps:

 Class1SwitchingCmd:  "<delay:7>"

Even if it works, though, it's not an ideal situation as there was a 
reason we changed to use AT+FRS=7.  USR modems are simply not very 
reliable for faxing.

It's also possible to store the faxgetty initialized state to be the 
soft-reset state of the modem.  This would allow the modem to re-enter a 
familiar state (to avoid confusing HylaFAX) if it resets mid-session and 
does not cause the modem to go on-hook (which isn't likely, but it's a 
possibility).

Hope this helps,

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*