Re: [hylafax-users] HDLC frame not byte-oriented

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

nicola nicola wrote:


> Dec 19 11:31:49.70: [ 4174]: SESSION BEGIN 000000120 390376720320
>
> Dec 19 11:31:57.53: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 11:31:57.93: [ 4174]: --> [10:NO CARRIER]
>
> Dec 19 11:32:01.35: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 11:32:04.06: [ 4174]: --> [7:CONNECT]
> Dec 19 11:32:04.22: [ 4174]: --> [5:ERROR]
>
> Dec 19 11:32:05.92: [ 4174]: RECV recv CRP (command repeat)
>
> Dec 19 11:32:09.26: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 11:32:11.86: [ 4174]: --> [7:CONNECT]
> Dec 19 11:32:12.98: [ 4174]: --> [5:ERROR]

This kind of thing going on in the log indicates that the audio quality 
for this call is poor.  And it makes it very understandable that this 
would happen:

> Dec 19 11:32:18.61: [ 4174]: <-- [10:AT+FRM=96\r]
> Dec 19 11:32:19.62: [ 4174]: --> [7:CONNECT]
> Dec 19 11:32:19.83: [ 4174]: Bad HDLC terminating flag received.
> Dec 19 11:32:19.83: [ 4174]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xe0
> Dec 19 11:32:19.83: [ 4174]: Bad HDLC terminating flag received.
> ....
> Dec 19 11:32:21.59: [ 4174]: Bad HDLC terminating flag received.
> Dec 19 11:32:21.59: [ 4174]: Bad HDLC terminating flag received.
> Dec 19 11:32:21.59: [ 4174]: RECV assumed RCP frame with block end
> Dec 19 11:32:21.59: [ 4174]: --> [10:NO CARRIER]
> Dec 19 11:32:21.59: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 11:32:30.17: [ 4174]: --> [7:CONNECT]
> Dec 19 11:32:32.39: [ 4174]: --> [5:ERROR]
>
> Dec 19 11:32:33.83: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 11:32:42.33: [ 4174]: --> [10:NO CARRIER]
> Dec 19 11:32:42.33: [ 4174]: MODEM No carrier
> Dec 19 11:32:42.33: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 11:32:42.35: [ 4174]: --> [10:NO CARRIER]

And then it looks like the connection was lost.  So at least for this 
call I would guess that audio quality was the issue.  Now maybe the 
modem was lying, but it probably wasn't.  The problem could be transient 
or fixed... it could be on your end or on the caller's end or somewhere 
in-between.  Multiple tests will say.

> Dec 19 11:34:16.13: [ 4174]: SESSION BEGIN 000000121 390376720320

Same thing with this one as with 000000120.

> Dec 19 11:49:30.11: [ 4174]: SESSION BEGIN 000000122 390376720320

There's nothing wrong with this one.

> Dec 19 14:17:30.75: [ 4174]: SESSION BEGIN 000000128 390376720320
>
> Dec 19 14:17:53.87: [ 4174]: RECV received frame number 46
> Dec 19 14:17:53.87: [ 4174]: RECV frame FCS check failed
> Dec 19 14:17:53.87: [ 4174]: HDLC frame not byte-oriented.  Trailing 
> byte: 0x80
> Dec 19 14:17:53.87: [ 4174]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xfc
> Dec 19 14:17:53.87: [ 4174]: RECV assumed RCP frame with block end
> Dec 19 14:17:53.87: [ 4174]: --> [10:NO CARRIER]
> Dec 19 14:17:53.87: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 14:18:03.55: [ 4174]: --> [7:CONNECT]
> Dec 19 14:18:03.89: [ 4174]: --> [5:ERROR]

Something happened on the audio with this call that caused the modem to 
lose the V.17 carrier.  Then 10 seconds later the V.21 HDLC carrier was 
detected, but the data received on that carrier was corrupt.

> Dec 19 14:18:11.39: [ 4174]: RECV received frame number 55
> Dec 19 14:18:11.53: [ 4174]: RECV received frame number 56
> Dec 19 14:18:11.69: [ 4174]: Bad HDLC terminating flag received.
> Dec 19 14:18:11.69: [ 4174]: RECV assumed RCP frame with block end
> Dec 19 14:18:11.69: [ 4174]: --> [10:NO CARRIER]

Another premature carrier loss on the retransmission.  Again, it's 
looking like audio quality is bad.  You're not using VoIP "lines" are you?

> Dec 19 14:18:11.69: [ 4174]: <-- [9:AT+FRH=3\r]
> Dec 19 14:18:21.15: [ 4174]: --> [10:NO CARRIER]

This here probably shouldn't have caused HylaFAX to give up trying, but 
it did.  Behavior would be different if you were using HylaFAX+ 5.2.0.  
On some modems NO CARRIER after AT+FRH=3 may indicate a disconnection, 
but more accurately (and probably the case here) it means that some 
carrier/noise was heard but that it wasn't V.21 HDLC and that it ended 
at 14:18:21.15.  HylaFAX+ here will re-issue AT+FRH=3.  If that had been 
done here recovery may have been possible... but the audio appears to be 
bad, and so it's possible that recovery here still wouldn't resolve the 
problem.

> Dec 19 14:21:51.52: [ 4174]: SESSION BEGIN 000000129 390376720320

Nearly the same exact thing here as with 000000128.

> Dec 19 14:25:57.51: [ 4174]: SESSION BEGIN 000000130 390376720320
>
> Dec 19 14:26:07.89: [ 4174]: RECV training at v.17 14400 bit/s
> Dec 19 14:26:07.89: [ 4174]: <-- [11:AT+FRM=145\r]
> Dec 19 14:26:09.62: [ 4174]: --> [7:CONNECT]
> Dec 19 14:26:10.38: [ 4174]: RECV: TCF 1372 bytes, 84% non-zero, 206 
> zero-run
> Dec 19 14:26:10.38: [ 4174]: RECV: reject TCF (too many non-zero, max 10%)
> Dec 19 14:26:10.38: [ 4174]: RECV: reject TCF (zero run too short, min 
> 1800)
> Dec 19 14:26:10.38: [ 4174]: --> [10:NO CARRIER]

This session exhibits nearly identical problems to the other sessions 
before it, with the addition of a TCF failure that you see here.  Again, 
it seems like something is wrong with the audio.  If you're not using 
VoIP then the problems seem very VoIP-like.

> Dec 19 14:52:40.65: [ 4091]: SESSION BEGIN 000000135 390376720320

Same as other problems that I've already talked about.

> Dec 19 14:48:37.59: [ 4091]: SESSION BEGIN 000000134 390376720320

Again, same as other problems already discussed.

> Dec 19 14:44:11.67: [ 4091]: SESSION BEGIN 000000133 390376720320

And once again, more of the same.

So, in conclusion... there are a number of changes/improvements in 
HylaFAX+ 5.2.0 that would make these sessions be a bit more resilient to 
what's going on, but the bottom line is that the audio quality is poor.  
So if you're not using VoIP then I would have the telco check your 
lines.  If you're using VoIP then please read:

http://hylafax.sourceforge.net/docs/fax-over-voip.pdf

Thanks,

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*