Re: [hylafax-users] RSPREC error/got EOT

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Jonathan Smithe wrote:

> We're using Hylafax+ 4.3.0.3, with t38modem.


> Jun 26 08:24:48.52: [23815]: RECV training at v.29 9600 bit/s
> Jun 26 08:24:48.52: [23815]: <-- [10:AT+FRM=96\r]
> Jun 26 08:24:50.55: [23815]: --> [10:NO CARRIER]


I'm a bit intrigued by the timing of this NO CARRIER response.  T.31 
provides for a NO CARRIER response only in the case where there is 
actual carrier loss (in which case we *should* see a CONNECT before 
it).  In fact, the timing of the NO CARRIER response (2 seconds after 
+FRM) would almost seem to indicate that t38modem erred and did not 
report the CONNECT response as it should have.

It is expected that a NO CARRIER or ERROR result also occur on a 
possible timeout situation.  But I would think that we're not talking 
about a timeout situation at a mere 2 seconds.

> Jun 26 08:24:54.53: [23815]: RECV training at v.29 7200 bit/s
> Jun 26 08:24:54.53: [23815]: <-- [10:AT+FRM=72\r]
> Jun 26 08:24:59.04: [23815]: --> [0:]
> Jun 26 08:24:59.04: [23815]: MODEM <Empty line>
> Jun 26 08:24:59.04: [23815]: MODEM TIMEOUT: receiving TCF
> Jun 26 08:24:59.04: [23815]: <-- data [1]
> Jun 26 08:24:59.04: [23815]: --> [2:OK]


In this instance I find the results a bit incredible.  It's extremely 
unlikely that the sender delivered TSI and DCS only to then omit TCF.  
Most likely the modem was not capable of detecting (or failed to detect) 
the V.29 7200 bps carrier as transmitted by the sender.

> Jun 26 08:25:01.18: [23815]: <-- [9:AT+FRH=3\r]
> Jun 26 08:25:01.73: [23815]: --> [8:+FCERROR]


> Jun 26 08:25:06.90: [23815]: <-- [9:AT+FRH=3\r]
> Jun 26 08:25:09.91: [23815]: --> [8:+FCERROR] 


And these +FCERROR responses are something that, I believe, that 
t38modem is doing incorrectly in response to +FRH=3.

T.31 does make provision for +FCERROR after +FRH=3.  However, the modem 
should only respond such when the expected modulation is V.27ter, V.29, 
or V.17, like +FRH=146, and not V.21.  (Yes, this may be contrary to a 
strict adherance to the spec.)  This is how other (hardware) modems 
behave, and I believe that it is with sound reason, too.  In more simple 
terms, +FCERROR should only ever indicate that V.21 signalling was heard 
when expecting some other modulation.  It should never be used to 
indicate that a high-speed modulation carrier was detected.

The reasons for this are multiple:

1) If used to indicate carrier presense other than V.21 it is quite 
impossible for the DTE to know to what carrier the +FCERROR result is 
referring.  The +FCERROR result is ambiguous when used to indicate 
carrier presense other than V.21.

2) Intermittent V.21 "handshakes" serve as a kind of synchronization 
mechanism for fax.  If ever the endpoints become disjointed or 
out-of-sync they need only stop and wait for the next set of V.21 HDLC 
signals and act accordingly in order to resync.  By allowing the +FRH=3 
command to sit and wait, without a response or result (even for a period 
up to 30 or 45 or 60 seconds) ignoring any high-speed modulations 
present until V.21 is detected allows the +FRH=3 command to serve in 
this capacity as a "synchronization command".

3) If the DTE gets +FCERROR in response to +FRH=3 its options are very 
limited.  Fax carriers other than V.21 cannot be entered mid-stream 
without first receiving the training phase of the carrier cycle.  The 
DTE must, essentially, continue repeating +FRH=3 until the +FCERROR 
result stops.  (It may use +FRS in order to limit the iterations of 
+FRH=3/+FCERROR.)  Thus the end-result of the +FCERROR result for 
detected carriers other than V.21 is only an increased difficulty for 
the DTE.

I can write some code to HylaFAX that will try to cope with +FCERROR 
results to +FRH=3 as best as possible.  (I may do this anyway.)  But I 
think that the best course of action here is for you to forward this 
message to Vyacheslav (if he's not reading this list anyway still) and 
let's see if we can all get together to resolve these issues.  From my 
perspective your trouble with this sender is due to problems in t38modem 
itself.

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*