FAX send failing due to failed file conversion (?)

We had a similar problem with PDF 1.2 and 1.3. I would suggest opening a ticket with Digium as it is a problem in their fax software. Older versions would actually crash Asterisk entirely, rather than just generate an error. We just had our customer update their PDF generating software to get around the problem in the meantime.

My understanding is that the Digium FAX module does not really do any conversions - it just works with the TIFF files.

For inbound fax to email, the TIFF file gets converted to a PDF with the fax2pdf.sh script where tiff2pdf is run against the TIFF file created by the FAX module.

For outbound faxes, I believe TL converts the uploaded PDF to a TIFF using, my guess is, Ghostscript and then tells Asterisk to fax the resulting TIFF file. The FAX send is failing because the converted file (the TIFF file) in /tmp does not exist due to, presumably, a failed conversion.

Chris
AxisInternet, Inc.

The fax module does not do any conversion. You said you manually converted the PDF to a TIF and the fax module still failed. This would indicate a problem with the fax module, not the conversion process.

[Sep 30 10:59:10] ERROR[5037] res_fax_digium.c: FAX handle 0: failed to queue document '/tmp/axint-302-2010-09-30-10-59-07' │
[S│[Sep 30 10:59:10] ERROR[5037] res_fax.c: channel 'Local/8883590926@from-inside-axint-eaeb;1' FAX session '34' failure, reason: 'failed to start FAX session' (INIT_ERROR) │

This is from the attempt with the manually converted TIF file - manually converted from PDF 1.5 to a TIFF with Ghostscript. I uploaded the TIF file via the TL User Portal's Send Fax option. Note that the first error message refers to the file /tmp/axint-302-2010-09-30-10-59-07, which is missing the .tif extension. And, there are no /tmp/axint-302-2010-09-30-10-59-07* files there - so not sure what happened after uploading, but it does not look like TL put it in /tmp and even if it did as /tmp/axint-302-2010-09-30-10-59-07.tif, it is apparently telling Asterisk to send /tmp/axint-302-2010-09-30-10-59-07 instead of /tmp/axint-302-2010-09-30-10-59-07.tif.

Chris
AxisInternet, Inc.

open up a console and run

watch -n 1 ls -l /tmp/

Try to resend the fax and see if the file shows up. The system deletes the file automatically.

try using the extension .tiff instead of .tif just to see if its a more basic problem on the front-end side of things.

When uploading a *.tif or *.tiff file, I do see the file created in /tmp - without any file extension in the name in both cases - and both faxes failed with the INIT error.

When uploading a PDF 1.5 format file, TL also does create the TIF file in /tmp (with the file extension), but the fax fails with the INIT error.

When uploading a PDF 1.4 format file, the file is also created and the fax is sent successfully.....

So, heading over to Digium to open a ticket with them - will see what they have to offer....

Chris
AxisInternet, Inc.

it might be a ghostscript problem failing to properly convert to tiff.

OK appears to not be an issue, per se, with PDF 1.5 vs PDF 1.4. My printing though of the PDF 1.5 file to a PDF 1.4 file did work around the real issue. It is not really a Digium problem but rather something that can be taken care of within TL. Did an RTFM and found in the Digium FAX for Asterisk manual:

============================================================================

When PDF files are created by document scanners, they are sometimes created with a larger-than-standard paper size, e.g. 8.6" x 12". In these cases, ghostscript does not adjust the size to a Standard (Letter or A4), even if PAPERSIZE is specified. This will cause SendFAX to fail with the following error:

ERROR[31106]: res_fax_digium.c:2114 dgm_fax_start: FAX handle 0: failed to queue document 'document name'

To prevent this, the size of the TIFF file needs to be specified in pixels. The following command will create TIFF files with a correct width and length:

For Letter-size paper (8.5" x 11"):
# gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sPAPERSIZE=letter -g1728x2150 -sOutputFile=

============================================================================

So, I took the PDF 1.5 format file my customer sent me (which he created using his HP document scanner) and ran the above command to manually create the TIFF file with the correct size in pixels. Uploaded that TIFF to fax via the User Portal and it was successfully sent.

So, appears that we need a way in TL to specify the command line that gets run in the conversion, or we need to have the '-g1728x2150' added to that command in the encrypted TL source....Alex????

Chris
AxisInternet, Inc.

I like your first suggestion better. If there were a file with some defined attributes like the pdf to tiff conversion command then people could make their own changes.

gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sPAPERSIZE=letter -g1728x2150 -sOutputFile=<dest> <src>

might work here in the USA, but in Europe I believe they use the A4 standard. Having a file that lets them change it to

gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sPAPERSIZE=a4 -g???x??? -sOutputFile=<dest> <src>

for whatever their needs are, would give more flexibility.

FWIW I used the Fax For Asterisk manual when I created this feature back in October of 2009. At the time it gave the command as

gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sPAPERSIZE=letter -sOutputFile=<dest> <src>

those geometry settings are a recent change to that manual. Another good reason to define the command in a configuration file, should the command construct get refined again in the future.

That would definitely be the most flexible and allow people to use virtually any application, switches, etc that they want to for the convertion......

Alex - got an update ready for this yet? ;-D

Chris
AxisInternet, Inc.

Interesting topic - makes me feel good about Thirdlane's community and the usual suspects - hi Erik :).

If we follow the general principles of Thirdlane - to be the most customizable management interface for Asterisk, we should implement this right away. That said, I am a little afraid of people shooting themselves in a foot having access to an open command. The difficulty would be how to pick the defaults (and at what level - installation, tenant, extension, etc) and not upset any provider or their customer in the world. Living in the US we don't usually think about this enough. I guess locale and internationalization could be is a separate topic. Your thoughts?

similar settings already exist..

in voicemail.conf there is a mailcmd option where you can change the command line argument of which mail client to use and what flags to set.

Typically Perl scripts will have pieces that look like

# Change settings here

variable1=

variable2=

variable3=

## Don not edit below this line unless you really know what your doing

variable4=

How about making the Perl script look for variables based on extension type

pdf=gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sPAPERSIZE=letter -g1728x2150 -sOutputFile=<dest> <src>

make sure it looks for pdf even if the extension is .PDF or .pdf. then if they want to add a handler for ms word (ie .doc .DOC .docx etc) they could add their own line like

msdoc=doc2pdf <src> | gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg4 -sPAPERSIZE=letter -g1728x2150 -sOutputFile=

Alex - if you put management of this command in the TL interface, you would then have some ability to validate the command and at least make sure it can run with some check on the output and not generate an error such as you'd likely see if the command did not exist or options were specified incorrectly. They could still change it in the file directly, but you can throw up your hands on that one and put the blame all back on them for not using the procedures you've provided....

Chris
AxisInternet, Inc.

Has this been resolved?

Don't know - Alex - has this been resolved? What version was the fix in? Then I can check and make sure we have that version installed and try testing it again to confirm....

Chris
AxisInternet, Inc.

this has not been adressed yet

Anyone interested in pushing this one through? We have a number of customers with issues in this area right now.

Also, while we're at it, providing form validation on the number or scrubbing extra characters (dashes, spaces, parenthesis, etc...) from the fax number would be a really handy addition.

Just my $.02...

My customers are having the same issues.
1. Failed conversions
2. Need to scrub phone number input
3. Need to allow faxreport.sh to send email without FAXFILE argument.

If the conversion fails, FAXFILE is missing, and then faxreport.sh doesn't send out email on failure.
I commented out all the FAXFILE tests at the top, and added this at the bottom:

if [ -e "$FAXFILE" ]; then
rm ${FAXFILE}
fi

4. Also, I had to do the following to /etc/asterisk/special_features.include:

exten => s,n,SendFAX(${FILENAME},${OPTIONS}f) ; add trailing 'f' for fallback to ulaw

exten => failed,1,System(REMOTENUMBER=${REMOTENUMBER} REASON=${REASON} FAILED=2 EMAILADDR=${EMAILADDR} FAXFILE=${FILENAME} /usr/local/sbin/faxreport.sh) ; Add FAXFILE argument so faxreport.sh won't fail due to missing argument.

The 2nd one is kinda moot now as I due to my changes to faxreport.sh

your 'f' command is passed in OPTIONS if you alter /etc/asterisk/provisioning/sendfax_template.txt and add a set command for OPTIONS
.. the 'f' option is version specific and does not appear in 1.8 syntax at all. Therefore the OPTIONS section of dialplan was best method to deal with a moving target. Supposedly in 1.8 and some versions of res_fax_digium in 1.6 they did the failback automatically.

the only time they hit the 'failed' extension is if all the fax attempts failed when calling but I can add bug report that adds the variable FAXFILE to the list. If you got to this part of the dialplan you've been failed 12 times once every 5 minutes.

I happened to be debugging a fax problem and the call file was still in the outgoing directory. I looked at the filename of the fax to be sent, and the file listed in the call file was not in the /tmp directory.

I did not have access to the source document so I couldn't test again but what I assumed was that the conversion failed for some reason and the file was never created.

Regardless of why the file was missing, the system went through 12 tries and then failed. And my end-users were not receiving notification because faxreport.sh would fail due to the missing variable, and therefore no email was generated.

which will be an easy bug fix to get the failure message sent out. I am more concerned with why their files aren't being converted. I've been using faxing for over a year now from the portal and never have any of my PDF's failed to convert. Could they be trying to upload tiffs instead? Those I have seen fail if the tiff isn't exactly perfect.

Hey Erik,

They're only uploading PDFs. They might have been uploading a PDF with a comma in the filename because they were doing that before and the fax interface was failing silently.

I'm trying to gather more information but so far no luck.