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

[Andy H <a.hassle.spam@xxxxxxxxx>]

Unfortunately, I've no way of trying this system on other known good lines.  One avenue that I'm going to approach is dialing into the other modem via minicom and see if I'm able to capture the line quality stats in the registers that way...  

One last question... Would the country have any impact on the system?  USA vs England vs China? NA vs Europe vs Asia?

On Thu, Aug 19, 2010 at 10:18 AM, Lee Howard <faxguy@xxxxxxxxxxxxxxxx> wrote:

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.