[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hylafax
Subject:    Re: [hylafax-users] Getting No Carrier right after FRH=3
From:       Lee Howard <faxguy () howardsilvan ! com>
Date:       2008-05-22 1:37:00
Message-ID: 4834CE3C.4030704 () howardsilvan ! com
[Download RAW message or body]

George H wrote:
> I upgraded to HylaFAX+ 5.2.4 yesterday. I wonder what it means when I
> get NO CARRIER before and after a FRH=3. I looked at the tif file as
> well.. it was blank with specs of black dots.
> May 20 12:32:11.11: [23481]: RECV received frame number 110
> May 20 12:32:11.39: [23481]: RECV received frame number 111
> May 20 12:32:11.67: [23481]: RECV received frame number 112
> May 20 12:32:11.95: [23481]: RECV received frame number 113
> May 20 12:32:12.30: [23481]: HDLC frame not byte-oriented.  Trailing byte: 0xc0
> May 20 12:32:12.30: [23481]: RECV assumed RCP frame with block end
> May 20 12:32:12.30: [23481]: MODEM set XON/XOFF/DRAIN: input ignored, output disabled
> May 20 12:32:12.30: [23481]: MODEM input buffering disabled
> May 20 12:32:12.30: [23481]: --> [10:NO CARRIER]
> May 20 12:32:12.30: [23481]: <-- [9:AT+FRH=3\r]
> May 20 12:33:12.64: [23481]: --> [10:NO CARRIER]
> May 20 12:33:12.64: [23481]: MODEM No carrier

There was premature carrier loss in Phase C.  HylaFAX then told the 
modem to listen for V.21 HDLC (AT+FRH=3).  The modem responded shortly 
thereafter with NO CARRIER.

Historically I had felt that this NO CARRIER response immediately 
following AT+FRH=3 was out-of-spec.  It certainly seems meaningless 
without a CONNECT preceding it.  However, ITU T.31 uses it in some 
sample sessions to illustrate that it can be used to detect arbitrary 
carrier loss (even if the carrier is not V.21 HDLC)... in other words 
AT+FRH=3 -> NO CARRIER can mean that there was some audio (we don't know 
what kind) that stopped.  It's a feature that gets in the way more than 
it helps, but nonetheless...

So historically I had assumed that it meant that the modem was on-hook 
because that's what I was seeing happen most frequently on digital 
modems that knew when the remote end hung up.  However, that was not an 
accurate assumption.

In January I made some changes to improve HylaFAX's response to this 
condition.  Those changes were part of 5.2.2.  However, the changes were 
incomplete, unfortunately.  Attached is the rest of the necessary 
changes needed.  This patch will be part of 5.2.5.

Thanks,

Lee.

["hylafax-frh3nocarrier.patch" (text/x-patch)]

--- hylafax.orig/faxd/Class1.c++	2008-05-22 00:48:33.001547776 -0700
+++ hylafax/faxd/Class1.c++	2008-05-22 01:05:25.298655224 -0700
@@ -1422,6 +1422,19 @@
 	 * with a pause to prevent unwanted massive amounts of tracing.  The pause 
 	 * needs to be short enough, though, that the modem will still pick up
 	 * any V.21 signalling if it misses that much of the startup.
+	 *
+	 * T.31 8.3.6 states that the NO CARRIER result to AT+FRH=3 indicates 
+	 * carrier loss.  Getting this result without first getting a CONNECT 
+	 * response (indicating carrier detection) seems a bit undefined.  However,
+	 * sample sessions T.31 I.1 and I.2 seem to give its use as a means to
+	 * deliberately detect carrier loss since the OK result to AT+FRH=3 does
+	 * not necessarily indicate carrier loss (even on final frames - although
+	 * smart modem developers would make it thus).  Thus could serve a purpose
+	 * similar to AT+FRS=1 as we haved used in Class1TCFRecvHackCmd (which is
+	 * generally a bad idea).  In any case, if we're trying to detect a V.21
+	 * HDLC frame and we get a NO CARRIER result immediately following AT+FRH=3
+	 * it probably means that the previous carrier was still up, that we just
+	 * saw its loss, and so we just need to re-issue AT+FRH=3.  See more below...
 	 */
 	do {
 	    readPending = atCmd(rhCmd, AT_NOTHING, 0) && waitFor(AT_CONNECT, 0);
@@ -1438,7 +1451,7 @@
 		}
 	    }
 	} while (((u_int) Sys::now()-start < conf.t1Timer) && !wasTimeout() &&
-	    (lastResponse == AT_FCERROR || (lastResponse == AT_ERROR && onhooks <= \
conf.class1HookSensitivity))); +	    (lastResponse == AT_FCERROR || lastResponse == \
AT_NOCARRIER || (lastResponse == AT_ERROR && onhooks <= \
conf.class1HookSensitivity)));  }
     if (readPending) {
         stopTimeout("waiting for HDLC flags");


____________________ 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@hylafax.org < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@ifax.com.*


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic