Re: [hylafax-users] Is this evidence of line noise ?

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

George H wrote:
> Again training at 14400 (V.17) Short train time
>
> Jan 15 12:26:03.68: [ 7539]: <-- [11:AT+FRM=146\r]
> Jan 15 12:26:05.22: [ 7539]: --> [7:CONNECT]
>
> Tries to train at 14400 (V.17) Short train time, but modem returns
> +FCERROR twice meaning that it detected a different signal than the
> one it was expecting. Later succeeds with AT+FRH=3 to make it recieve
> HDLC framed data.
>
> Jan 15 12:28:30.14: [ 7539]: RECV send PPR (partial page request)
> Jan 15 12:28:30.14: [ 7539]: <-- [11:AT+FRM=146\r]
> Jan 15 12:28:31.75: [ 7539]: --> [8:+FCERROR]
> Jan 15 12:28:31.75: [ 7539]: <-- [11:AT+FRM=146\r]
> Jan 15 12:28:32.13: [ 7539]: --> [8:+FCERROR]
> Jan 15 12:28:32.13: [ 7539]: <-- [9:AT+FRH=3\r]
> Jan 15 12:28:35.77: [ 7539]: --> [7:CONNECT]
>   

ECM protocol (ITU T.30 A) says that the sender must retransmit the same 
block up to three times if the receiver keeps requesting retransmissions 
via PPR.  After the third retransmission (the fourth transmission of 
frames from the same block) the sender then is expected to indicate CTC 
(continue to correct) or EOR (end of retransmissions).  However, some 
senders regularly violate the counting requirement there - whether 
intentional or not - and will send CTC or EOR prematurely.  And, all 
well-developed ECM receivers will tolerate it (which only encourages the 
senders to further violate the spec).

So this kind of +FCERROR thing you'll see on occasion, especially 
depending on the sender type.  As long as HylaFAX is able to recover... 
as long as a signal is received afterwards (and it should be CTC or EOR, 
and your explanation of the log seems to indicate this) then as a 
receiver you should consider everything to be working properly.

However, this process of repeated PPR and repeated CTC/CTR exchanges is 
*extremely* indicative of either 1) corrupt audio conditions, 2) badly 
trained modems, or 3) slightly incompatible modems.  I think that you 
can rule out bad training because it happens so regularly.  And you can 
probably rule out modem incompatibilities because you see the session 
traverse through V.17 and V.29 (and possibly even V.27ter) - which are 
all different modems - with the same issues.  So it's almost conclusive 
that the audio is corrupt somehow.  Given that you're dealing with some 
Cisco IP infrastructure... well, that's where I would look first.  
BUT... if this is only happening with a select few senders, then you 
could rightly conclude that the audio corruption is coming from the 
sender's side of the call (and possibly well out of your control).

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*