Re: [hylafax-users] Iaxmodem to hylafax to asterisk to asterisk to hylafax to iaxmodem having errors

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Duncan Turnbull wrote:

> I use iaxmodem 0.1.9 and hylafax 4.3.0.3 which generally works very well.
>
> This is on Debian etch
>
> I have an asterisk server with two analogue lines which send fine most of the time but when sending between each line for tests I
> often get partial or full failures.
>  

Because the receiver and sender are on the same machine (thus the 
timestamps are perfectly in-sync) it is quite useful to set the two 
side-by side and see exactly what happened at certain instances.  So 
I'll be rearranging the following a little bit...

Receiver:

> Jul 07 17:07:40.33: [ 4489]: RECV training at v.29 9600 bit/s
> Jul 07 17:07:40.33: [ 4489]: MODEM set XON/XOFF/DRAIN: input ignored, output generated
> Jul 07 17:07:40.33: [ 4489]: <-- [10:AT+FRM=96\r]
> Jul 07 17:07:42.31: [ 4489]: --> [6:+FRH:3]
> Jul 07 17:07:42.31: [ 4489]: MODEM set XON/XOFF/DRAIN: input ignored, output disabled
> Jul 07 17:07:42.31: [ 4489]: --> [7:CONNECT]
> Jul 07 17:07:42.33: [ 4489]: --> [10:NO CARRIER]
> Jul 07 17:07:42.33: [ 4489]: MODEM No carrier

Sender:

> Jul 07 17:07:37.83: [ 1506]: <-- [9:AT+FTH=3\r]
> Jul 07 17:07:37.85: [ 1506]: --> [7:CONNECT]
> Jul 07 17:07:37.85: [ 1506]: <-- HDLC<23:FF C0 C2 8C 6C 6C AC 1C 1C CC 2C 2C 6C D4 04 04 04 04 04 04 04 04 04>
> Jul 07 17:07:39.87: [ 1506]: --> [7:CONNECT]
> Jul 07 17:07:39.87: [ 1506]: <-- HDLC<7:FF C8 C1 00 60 1F 22>
> Jul 07 17:07:40.27: [ 1506]: --> [2:OK]
> Jul 07 17:07:40.27: [ 1506]: <-- [9:AT+FTS=7\r]
> Jul 07 17:07:40.35: [ 1506]: --> [2:OK]
> Jul 07 17:07:40.35: [ 1506]: MODEM set XON/XOFF/FLUSH: input interpreted, output disabled
> Jul 07 17:07:40.35: [ 1506]: <-- [10:AT+FTM=96\r]
> Jul 07 17:07:40.36: [ 1506]: --> [7:CONNECT]
> Jul 07 17:07:40.36: [ 1506]: DELAY 400 ms
> Jul 07 17:07:42.29: [ 1506]: --> [2:OK]

The receiver starts listening for V.29 9600 bps at 40.33 and doesn't 
recognize anything until 42.31 when it misinterprets the carrier-drop 
noises as a V.21 signal (this misinterpretation isn't unusual).  The 
problem, though, is that for some reason it didn't recognize the V.29 
signalling at all.  In order to figure this part out I'll need to see 
recordings.  In your iaxmodem configuration files (/etc/iaxmodem/...) 
put "record" there and then reproduce this exact same thing.  Then mail 
me the *.raw audio files in /tmp/.

My guess is that there was some disturbance in the audio that caused the 
audio to be distorted enough to not be recognizable by the DSP.

Receiver:

> Jul 07 17:08:32.37: [ 4489]: RECV received frame number 36
> Jul 07 17:08:32.61: [ 4489]: RECV assumed RCP frame with block end
> Jul 07 17:08:32.61: [ 4489]: MODEM set XON/XOFF/DRAIN: input ignored, output disabled
> Jul 07 17:08:32.61: [ 4489]: MODEM input buffering disabled
> Jul 07 17:08:32.61: [ 4489]: --> [10:NO CARRIER]
> Jul 07 17:08:32.61: [ 4489]: <-- [9:AT+FRH=3\r]
> Jul 07 17:08:35.01: [ 4489]: --> [7:CONNECT]
> Jul 07 17:08:35.91: [ 4489]: --> [20:EE 56 4D EF 12 13 C3 A2 88 E6 AD 74 DC B1 6C F5 62 2A BD A7]
> Jul 07 17:08:35.91: [ 4489]: --> [15:7B D3 7A AB 8C 4E AE 08 B1 C5 0D 58 4F 10 03]
> Jul 07 17:08:35.91: [ 4489]: --> [5:ERROR]
> Jul 07 17:08:35.91: [ 4489]: MODEM Command error

Sender:

> Jul 07 17:08:30.85: [ 1506]: <-- data [1033]
> Jul 07 17:08:30.85: [ 1506]: <-- data [1036]
> Jul 07 17:08:30.85: [ 1506]: <-- data [1034]
> Jul 07 17:08:30.85: [ 1506]: <-- data [1033]
> Jul 07 17:08:37.73: [ 1506]: <-- data [1032]
> Jul 07 17:08:37.73: [ 1506]: <-- data [1036]
> Jul 07 17:08:37.73: [ 1506]: <-- data [1035]
> Jul 07 17:08:37.73: [ 1506]: <-- data [1039]

What happens here is that the receiver detected carrier loss at 32.61, 
however the sender was actually sending audio during that entire time.

So this further adds credence to the theory that there is some audio 
disturbance going on somewhere.  Again, a recording will be necessary to 
see more clearly.

HOWEVER, you may be able to cut to the root of the problem by running 
zttest and if you have anything ever less than 99.98% through a minute 
or two of testing, then you have some underlying hardware problems 
(possibly zaptel bugs in itself) that are making things tough for faxing 
to work properly.

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*