Re: [hylafax-users] receive failure

[Matthias Reich <rei@xxxxxxxx>]

Am Montag, 10. April 2006 23:09 schrieb Lee Howard:
> Lee Howard wrote:
> > Matthias Reich wrote:
> >> Apr 04 10:41:24.00: [12667]: <-- [9:AT+FRH=3\r]
> >> Apr 04 10:41:24.14: [12667]: --> [7:CONNECT]
> >> Apr 04 10:41:25.28: [12667]: --> HDLC<7:FF C8 C8 00 04 4D E9>
> >> Apr 04 10:41:25.28: [12667]: --> [2:OK]
> >> Apr 04 10:41:25.28: [12667]: RECV recv CTC (continue to correct)
> >> Apr 04 10:41:25.28: [12667]: DELAY 70 ms
> >> Apr 04 10:41:25.35: [12667]: <-- [9:AT+FTH=3\r]
> >> Apr 04 10:41:26.30: [12667]: --> [7:CONNECT]
> >> Apr 04 10:41:26.30: [12667]: <-- HDLC<3:FF C8 23>
> >> Apr 04 10:41:26.80: [12667]: --> [2:OK]
> >> Apr 04 10:41:26.80: [12667]: RECV send CTR (confirm continue to correct)
> >> Apr 04 10:41:26.80: [12667]: MODEM input buffering enabled
> >> Apr 04 10:41:26.80: [12667]: <-- [11:AT+FRM=145\r]
> >
> > This is HylaFAX's fault.  It misinterpreted or mishandled the CTC
> > signal.  I suspect that this has been fixed since 4.2.1.
>
> Actually, I double-checked this matter.  The signal you got was
> "00000000 00000100", which, according to T.30 Table 2 indicates V.17
> 14400 bps (meaning that the sender wanted to continue using the same
> carrier that it was using before).  So HylaFAX correctly interpreted it
> as V.17 14400 bps.  (I have to admit, though, that this situation is
> apparently *very* rare.  In many thousands of fax logs I've surveyed
> I've not seen the sender re-use V.17 14400 bps through CTC/CTR like this.)
>
> The sender, however, probably sent short-train data and the modem was
> told to expect long-train data.
>
> This point in question is perhaps debatable on how it should be properly
> handled.  T.30 Section 5 Note 5 states:
>
> "Terminals using the modulation system defined in ITU-T Rec. V.17 (as
> specified by bits 11, 12, 13 and 14 of Table 2/V.17) shall use the short
> resynchronization sequence defined in Table 3/V.17 for all trellis mode
> training except during a TCF message and the first high-speed message
> after a CTC/CTR ECM message sequence.  The long synchronization sequence
> shall be used in the TCF and the first high-speed message after the
> CTC/CTR sequence."
>
> Meaning that according to spec the sender *should* have used the
> long-training rather than the short-train and that HylaFAX did things
> correctly according to the spec.
>
> I've run some tests, and if the sender does long-train the receiver
> needs to also do long-train, and if the sender does short-train then the
> receiver also needs to do short-train.  So the fact that the sender got
> T.30 wrong is not HylaFAX's fault after all, it another fault in the
> sender.
>
> Lee.

Hi Lee,

thanks a lot for your birlliant analysis on that matter.
I updated to 4.2.5 meanwhile and the error is gone.
Receiving is fine now, no errors anymore.
Having a closer look on theses errors I found out, that it is software on the 
other end, one is called Faxware and the other Tobit David. 
This software seems to behave strange sometimes.
I found out another error communicating with this software. Sending a fax that 
destination, isn't sending a fax. Sending from location A to that destination 
never works. Using the same modem, same firmware, same parameters, same 
hylafax-version in location B works fine. The only difference is the line 
between our locations and the destination. As I have no idea how to fix it,
we use our network to route faxes to that dest to a hylafaxserver that is 
known to work and send it from there.

Matthias
-- 
HAGOS eG                 phone: +49 711 7880592
Matthias Reich             fax: +49 711 7880535
Industriestr. 62           web: http://www.hagos.de
D-70565 Stuttgart         mail: rei@xxxxxxxx
Germany

Attachment: pgp00004.pgp
Description: PGP signature