HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] receive failure



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*




Project hosted by iFAX Solutions