Re: [hylafax-users] receive failure

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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.


____________________ 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*