Re: [hylafax-users] Large number of failures receiving faxes ~38% failure rate

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

It's certainly a possibility that the problem is with the serial card, 
but it's not probable, no.

You could try taking the HylaFAX system to a different location where 
there are different and known-good-for-fax lines and test there.  If it 
works, then you know the original two lines are the culprit.  If it 
doesn't work, then you know you have something wrong with the modems or 
the system elsewhere.

Thanks,

Lee.


Andy H wrote:
> Thank you for the detailed explanation.  Sadly, the two lines are 
> POTS.  At least as they enter the building.  Is there a possibility 
> that the multi-port serial card could be the culprit?  Well, I know 
> there's always a possibility, but is it probable?  Or should I have 
> the telco run another/more tests on the two phone lines?
>
> On Thu, Aug 19, 2010 at 2:33 AM, Lee Howard <faxguy@xxxxxxxxxxxxxxxx 
> <mailto:faxguy@xxxxxxxxxxxxxxxx>> wrote:
>
>     Andy H wrote:
>
>
>         I am trying to attach the respective logs to this as well.  I
>         thought that line quality was the issue and
>         had the remote office cordinate with the local telco to check
>         the lines.  Telco said the lines were good.
>          I am including two examples each of:
>         RSPREC error - got DCN
>         Failed to properly detect high speed data carrier
>         COMREC received DCN
>         T30 T2 timeout, expected signal not received
>         No sender protocol - T30 T1 timeout
>
>
>     Aug 10 10:24:32.14: [ 3075]: RECV recv EOP (no more pages or
>     documents)
>     Aug 10 10:24:32.14: [ 3075]: <-- [9:AT+FRS=7\r]
>     Aug 10 10:24:32.40: [ 3075]: --> [2:OK]
>     Aug 10 10:24:32.40: [ 3075]: <-- [9:AT+FTH=3\r]
>     Aug 10 10:24:32.57: [ 3075]: --> [7:CONNECT]
>     Aug 10 10:24:32.57: [ 3075]: RECV send RTN (retrain negative)
>     Aug 10 10:24:32.57: [ 3075]: RECV FAX (000016346): from
>     <UNSPECIFIED>, page 1 in 0:55, INF, 3.85 line/mm, 1-D MH, 7200 bit/s
>     Aug 10 10:24:32.57: [ 3075]: <-- data [3]
>     Aug 10 10:24:32.57: [ 3075]: <-- data [2]
>     Aug 10 10:24:33.87: [ 3075]: --> [2:OK]
>     Aug 10 10:24:33.87: [ 3075]: <-- [9:AT+FRH=3\r]
>     Aug 10 10:24:34.76: [ 3075]: --> [7:CONNECT]
>     Aug 10 10:24:35.38: [ 3075]: --> [2:OK]
>     Aug 10 10:24:35.38: [ 3075]: RECV recv DCN (disconnect)
>
>     Here, after receiving the page image data, the sender signals the
>     End Of Procedure signal (indicating it's the last page to be
>     sent), but it was not of adequate quality, and so HylaFAX signals
>     RTN back (which means that the previous page was not received with
>     acceptable quality and that a retrain must occur before accepting
>     any more pages).  At this point it's really inexact what the
>     sender is supposed to do (it could retransmit, but it could also
>     just end the fax there since it already transmitted the last
>     page).  The outcome was not unusual, but the real problem was that
>     the audio quality on the call was so poor that RTN needed to be
>     signaled in the first place.
>
>     Aug 13 15:31:43.53: [ 3075]: RECV send PPR (partial page request)
>     Aug 13 15:31:43.53: [ 3075]: <-- [10:AT+FRM=24\r]
>     Aug 13 15:31:45.01: [ 3075]: --> [7:CONNECT]
>     Aug 13 15:31:46.69: [ 3075]: RECV received frame number 133
>     Aug 13 15:31:47.57: [ 3075]: RECV received frame number 134
>     Aug 13 15:31:47.57: [ 3075]: RECV received RCP frame
>     Aug 13 15:31:47.57: [ 3075]: --> [10:NO CARRIER]
>     Aug 13 15:31:47.57: [ 3075]: <-- [9:AT+FRH=3\r]
>     Aug 13 15:31:47.96: [ 3075]: --> [7:CONNECT]
>     Aug 13 15:31:48.60: [ 3075]: --> [5:ERROR]
>     Aug 13 15:31:48.60: [ 3075]: MODEM Command error
>     Aug 13 15:31:48.60: [ 3075]: FCS error
>
>     Whenever you see PPR being signaled on a fax it means that some
>     audio distortion or modulator/demodulator incompatibility caused
>     one or more portions of the fax image to not come through
>     correctly, and a retransmission is being requested.  The face that
>     you see this happening so frequently is a strong indicator that
>     you're looking at line audio quality problems.  Furthermore, the
>     ERROR after AT+FRH=3, CONNECT means that the audio was so bad that
>     not even V.21 HDLC got through, and that really does take very bad
>     audio quality to do that.
>
>     Aug 16 14:45:26.11: [ 3074]: <-- [9:AT+FRH=3\r]
>     Aug 16 14:45:33.11: [ 3074]: --> [0:]
>     Aug 16 14:45:33.11: [ 3074]: MODEM <Empty line>
>     Aug 16 14:45:33.11: [ 3074]: MODEM TIMEOUT: waiting for v.21 carrier
>     Aug 16 14:45:33.11: [ 3074]: <-- data [1]
>     Aug 16 14:45:33.11: [ 3074]: --> [2:  ]
>     Aug 16 14:45:33.11: [ 3074]: --> [2:OK]
>     Aug 16 14:45:33.11: [ 3074]: RECV FAX: No sender protocol (T.30 T1
>     timeout)
>
>     This means that after answering a call the modem did not detect
>     fax signaling on the call.  This is either because it was not a
>     fax call or because the audio was so corrupted that the modem
>     could not distinguish it as fax.
>
>     So to answer your question, yeah, you're almost certainly looking
>     at bad line audio quality.  And it's so bad that it begs the
>     question... is this a VoIP line?
>
>     Thanks,
>
>     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*