Hi Guys

The GUI 4.0 has been updated to support fax2email via attrafax, let us know how you go!!!

Thanks
Jason

Hi Guys,

Goertzel in Attrafax was rewriten in fixed point and probably this is the last thing which worths optimization for now. 

The fixed point Attrafax patch with this addition and some clean up is in SVN now.
To test Goertzel fax2 should send fax to fax1.

     fax1 <-> dahdi <-> IP02/IP08 <-> sip <-> T38 ATA <-> fax2

Please share your test results in case you have two fax machines IP02/IP08 and one of the supported ATA:

Mediatrix 1102
Cisco Linksys Sipura SPA2100 with firmware 3.3.6
Cisco Linksys Sipura SPA2102 with firmware 3.3.6
Cisco Linksys Sipura SPA3102 with firmware 3.3.6
Cisco Linksys Sipura SPA3102 with firmware 5.1.7
Cisco Linksys Sipura SPA9000 with firmware 3.3.6
Audio Codes MP-112 FXS
Allied Telesyn AT-RG613-TX
Cisco 827
Cisco 5350
AddPac 200
Grandstream HT386

Cheers
Dimitar

Hi Guys,

Jason and I did series of tests of Switchfin.
Attrafax/Switchfin now passes all of the FAX tests as defined above.

If you observe Overflow condition or some issue using this FAX solution please
let us know.

Cheers
Dimitar

Hi Nikos,

Do you use unchanged Switchfin or you are taking only Attrafax patch?
It looks like your asterisk is not properly patched.

Your remote fax is connected directly to the PSTN, right?

We have never tested with FX02. Did you try if the FXO port can pass thru
the fax signal? This you can test with unchanged Asterisk and without Attrafax.   
Or probably you can give it a try using IP02.

I don't expect issues with G23 and Switchfin as G23 is confirmed to be working in few scenarios. Still some issues are possible so your further testing is very welcome!

Best Regards
Dimitar

Dear Dimitar,

I am glad we have confirmed that the attrafax included by default in the Switchvoice uImage-ip02-ip08-v383.img is fixed point and hence suitable for the BF532 processor based hardware.

I managed to have the FAX Rx/Tx chain working and I have tried to summarise all the procedure sofar, so that maybe someone else can save some time setting it up.

;----- GET DOCUMENT FROM FAX MACHINE (PRODUCES infax_2D_page_0001.g3)------
[DEBUG_7777]
exten = 7777,1,NoOp($$$$$$$ SCAN DOCUMENT FROM FAX MACHINE $$$$$$$$$$$$)
exten = 7777,n,Answer()
exten = 7777,n,Set(FAX_FORCE_V29=1)
exten = 7777,n(t30),Rxfax_t30(/infax, 7777)
exten = h,1,Goto(debug_file,s,1)

;----- CONVERT infax_2D_page_0001.g3 to infax.tiff ------------
[debug_file]
exten = s,1,System(/bin/fax2tiff -3 -2 -o /infax.tiff /infax*.g3)
exten = s,n,System(rm /*.g3)
exten = s,n,Set(TX_ARGS="Data: infax.tiff|")
exten = s,n,Set(FAX_NUMBER=1234567890)
;----- SEND infax.tiff to NUMBER 1234567890 --------------------------------
exten = s,n,System(echo Channel: DAHDI/g1/1234567890 >> ./printofax.call)
exten = s,n,System(echo MaxRetries: 2 >> ./printofax.call)
exten = s,n,System(echo RetryTime: 20 >> ./printofax.call)
exten = s,n,System(echo WaitTime: 10 >> ./printofax.call)
exten = s,n,System(echo Application: Txfax_t30 >> ./printofax.call)
exten = s,n,System(echo "${TX_ARGS}${FAX_NUMBER}" >> ./foo.call)
exten = s,n,System(echo " " >> ./foo.call)
exten = s,n,System(cat ./printofax.call ./foo.call > faxsend.call)
exten = s,n,System(mv faxsend.call /var/spool/asterisk/outgoing/)
exten = s,n,Goto(default,s,1)


However this configuration is not perfect.
Although infax_2D_0001.g3 and the corresponding infax.tiff are very fine 1728x2326 1-bit/pixel documents (Rxfax_t30 works fine), when I use Txfax_t30 to send to a remote fax (e.g. DAHDI/g1/1234567890) or print locally (e.g. local/6710@local) the printed document is a corrupted version of the original. I tried to set rxgain/txgain in chan_dahdi.conf using a 1004Hz sinewave (one machine called another and stored the resulting samples using SNDREC), but still the documents printed are strangely corrupted
(possibly synchronisation is lost every 100 pixels ???? Is one of the applications trying to smooth or interpolate the image????)

To print to a local fax I used:

Channel: local/6010@local
MaxRetries: 2
RetryTime: 30
WaitTime: 60
Application: Txfax_t30
Data: /infax.tiff|local/6010@local

is this correct, or Txfax_t30 when running corrupts the file to be transmitted and I need a patch. See the attached to understand the corruption taking place (makes small print text, impossible to read)
Here is a sample of the pr[img width=100px height=100px][/img]oblem. On the left there is the original (the handwritten word "FAX"). On the right there is the received image.
http://picasaweb.google.gr/102172595061 … 1467050146

(This is the original image converted to jpeg, because picassa would not let me uploaf the original tiff. Here the picture depth is 8 bits, but the effect is clearly visible)

I am a bit stuck for ideas, so again Any help would be appreciated!

Nikos

I haven't updtaed the status yet, becaus I was waiting to stabilise my system. Anyway, I have now replaced Attrafax with appfax and the faxes seem to be going through nicely now via any POTS channel.
I have also set the SET_FORCE_V29 flag in the extensions.conf file
The (working) configuration is now:

Channel: DAHDI/g1/1234567890
MaxRetries: 100
RetryTime: 20
WaitTime: 60
Application: txfax
Data: /file.tiff|DAHDI/g1/1234567890

inside extensions.conf
exten = s,n,Set(FAX_FORCE_V29=1)

The problem I am faced with now is the following:
I generate inside the IP02 fax messages as tif files and send them.
These "home made" tif files seem to be going through nicely when the call is local, but have an increased probability of failure when the call is international. So far I have not seen the same problem with the tiff files aquired by the IP02 or when the call is local. The only difference that I can find is that my tiffs have fewer tags set. In the past, setting some of these tags caused problems. I am now investigating if any of them are really necessary.
As usual, any ideas will be welcome!

Nikos

Yes, this is the one

Well, I was planning anyway to go back and try to compile Attrafax (I haven't managed this yet - I am using pre-compiled distributions). However I am currently engaged in another panic: my IP02 does not seem to recognise its network interface. When this happens, I connet to it via the serial port and when I run the ifconfig command, I just see the local loopback and the eth0 interface has dissapeared!
So far I have managed to revive it a few times. Steps:
1) I connect via serial port
2) Flash erase
3) Set up a firmware update (the recovery procedure)
4) Rebooting the IP02 several times until it recognises its NI
However this procedure seems random. How can I find out what is really happening?

Best regards,
Nikos

No the ethernet interface is still non-functional from u-boot.
It seems to recover after a random number of flash erases and reboots.
Please see separate post in the IP0x forum:
Home --> Forum --> Developers --> IP0x --> IP02 lost ethernet port

Hi bradley

I have noticed allot of instability with Attrafax and Asterisk 1.4.40, The rebooting cycle of the IP04 is most likely ProcWatch detecting asterisk has crashed and rebooting to fix the issue.

You can disable procwatch by running "/etc/init.d/asteriskwatch stop" you will have to be fast as procwatch checks every 27sec.

You can also try reverting to the older asterisk build or building the image without Attrafax.

Thanks
Jason