Re: [hylafax-users] FRH=3 -> timeout waiting for v.21 carrier

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.12.10 01:48 Giulio Orsero wrote:
> 4.1.7, rh6x, courier v.34 in class1.
>
> Sending to some destinations always result in training failed.
> Before trying changing line/modem I'm sending log here.
>
> I tried using -B 4800, Class1ResponseWaitCmd="AT+FRS=1" (2, 3, ),
> using
> hardware flow in place of soft to no avail.


> Dec 10 09:54:03.92: [17213]: MODEM set XON/XOFF/FLUSH: input ignored,
> output disabled
> Dec 10 09:54:03.95: [17213]: DIAL 9,,000000000
> Dec 10 09:54:03.95: [17213]: <-- [18:ATDT9,,000000000\r]
> Dec 10 09:54:30.14: [17213]: --> [7:CONNECT]
> Dec 10 09:54:30.14: [17213]: MODEM input buffering disabled
> Dec 10 09:54:30.14: [17213]: --> HDLC<16:FF C0 04 00 00 6A AA AA 00 31
> 09 01 9D 60 5E 25>
> Dec 10 09:54:30.14: [17213]: --> [2:OK]
> Dec 10 09:54:30.14: [17213]: REMOTE NSF "00 00 56 55 55 00 8C 90 80 B9
> 06 7A"
> Dec 10 09:54:30.14: [17213]: NSF remote fax equipment: Brother
> Dec 10 09:54:30.14: [17213]: <-- [9:AT+FRH=3\r]
> Dec 10 09:54:30.19: [17213]: --> [7:CONNECT]
> Dec 10 09:54:30.74: [17213]: --> HDLC<25:FF C0 02 AC 0C AC CC 6C CC EC
> AC 2C 0C 04 04 04 04 04 04 04 04 04 04 15 0C>
> Dec 10 09:54:30.74: [17213]: --> [2:OK]
> Dec 10 09:54:30.74: [17213]: REMOTE CSI "000000000"
> Dec 10 09:54:30.74: [17213]: <-- [9:AT+FRH=3\r]
> Dec 10 09:54:30.79: [17213]: --> [7:CONNECT]
> Dec 10 09:54:31.07: [17213]: --> HDLC<11:FF C8 01 00 77 15 23 01 88 E7
> CD>
> Dec 10 09:54:31.07: [17213]: --> [2:OK]

After this point we don't hear from the remote again...

> Dec 10 09:54:31.07: [17213]: REMOTE best rate 14400 bit/s
> Dec 10 09:54:31.07: [17213]: REMOTE max page width 1728 pixels in 215
> mm
> Dec 10 09:54:31.07: [17213]: REMOTE max unlimited page length
> Dec 10 09:54:31.07: [17213]: REMOTE best vres 7.7 line/mm
> Dec 10 09:54:31.07: [17213]: REMOTE best format 2-D MMR
> Dec 10 09:54:31.07: [17213]: REMOTE supports T.30 Annex A, ECM
> Dec 10 09:54:31.07: [17213]: REMOTE best 10 ms/scanline
> Dec 10 09:54:31.07: [17213]: USE 4800 bit/s
> Dec 10 09:54:31.07: [17213]: USE 10 ms/scanline
> Dec 10 09:54:31.07: [17213]: SEND file "docq/doc11343.ps;41"
> Dec 10 09:54:31.10: [17213]: USE page width 1728 pixels in 215 mm
> Dec 10 09:54:31.10: [17213]: USE unlimited page length
> Dec 10 09:54:31.10: [17213]: USE 7.7 line/mm
> Dec 10 09:54:31.10: [17213]: USE 2-D MR
> Dec 10 09:54:31.10: [17213]: SEND training at v.27ter 4800 bit/s
> Dec 10 09:54:31.10: [17213]: <-- [9:AT+FTH=3\r]
> Dec 10 09:54:31.20: [17213]: --> [7:CONNECT]
> Dec 10 09:54:31.20: [17213]: <-- HDLC<23:FF C0 C2 0C 1C EC CC 9C 2C CC
> 04 8C 8C 0C 04 9C CC D4 04 04 04 04 04>
> Dec 10 09:54:31.20: [17213]: <-- data [23]
> Dec 10 09:54:31.20: [17213]: <-- data [2]
> Dec 10 09:54:32.94: [17213]: --> [7:CONNECT]
> Dec 10 09:54:32.94: [17213]: <-- HDLC<6:FF C8 C1 00 53 14>
> Dec 10 09:54:32.94: [17213]: <-- data [6]
> Dec 10 09:54:32.94: [17213]: <-- data [2]
> Dec 10 09:54:33.64: [17213]: --> [2:OK]
> Dec 10 09:54:33.64: [17213]: <-- [9:AT+FTS=7\r]
> Dec 10 09:54:33.77: [17213]: --> [2:OK]
> Dec 10 09:54:33.77: [17213]: MODEM set XON/XOFF/FLUSH: input
> interpreted, output disabled
> Dec 10 09:54:33.77: [17213]: <-- [10:AT+FTM=48\r]
> Dec 10 09:54:34.74: [17213]: --> [7:CONNECT]
> Dec 10 09:54:34.74: [17213]: <-- data [900]
> Dec 10 09:54:34.74: [17213]: <-- data [2]
> Dec 10 09:54:36.31: [17213]: --> [2:OK]
> Dec 10 09:54:36.31: [17213]: MODEM set XON/XOFF/DRAIN: input ignored,
> output disabled
> Dec 10 09:54:36.31: [17213]: <-- [9:AT+FRH=3\r]
> Dec 10 09:54:39.41: [17213]: --> [0:]
> Dec 10 09:54:39.41: [17213]: MODEM <Empty line>
> Dec 10 09:54:39.41: [17213]: MODEM TIMEOUT: waiting for v.21 carrier

T.31 pretty much instructs the DCE to wait for the carrier forever in 
the +FRH=n command.  In theory if the carrier is lost, then the "NO 
CARRIER" result would be given, but often a DCE will only do this if it 
is lost after the command is sent.  Thus if the loss occurred before 
the command, we may never get a "NO CARRIER" signal no matter how long 
we wait.

Given your log I think we could assume that the carrier is gone at this 
point.  Thus, something between the point of CSI and now could have 
caused the remote to hang up without clearly disconnecting (sending 
DCN).

The DCS signal looks proper.  So at that point all you can do is vary 
the parameters (speed, compression, etc.) until you get one that works, 
and then figure out what the real difference is.

Do all of the receivers that have problems like this have the same 
NSF?  Does this happen with all modems on your end?

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@xxxxxxxxxxxx*