I've encountered an issue with faxing (T.38) certain G3 encoded tiff files wherein the sending system reports that the fax was successfully sent while the receiving system aborts quite early on in the process with "Received a DCN while waiting for a DIS". My setup is such that I have two identical Linux systems running callweaver-1.2.0.1 and spandsp-0.0.5pre4 that are connected to the same T.38 proxy and I am sending faxes between them using TxFAX and RxFAX. I have done a lot of testing and can confirm the following:

  1. With the right tiff files, I can successfully fax in both directions.
  2. Both TxFAX and RxFAX are set up for ecm.
  3. When I generate a problem tiff file, the problem is the same
     regardless of direction (the sender always reports the fax
     successfully sent; the receiver reports failure).
  4. Both the good and bad tiff files are generated using:

   convert inputfile.jpg /options /pdf:intermediate.pdf
   gs -q -sDEVICE=tiffg3 -sPAPERSIZE=letter -r204x196 -dNOPAUSE
   -sOutputFile=outputfile.tif -- intermediate.pdf

4. convert is an ImageMagick (6.4.4) image manipulation application. 5. I can consistently generate good or bad files based on how I set
     up the /options/ above.  As long as the phrase -page letter
     appears in the right place, the file can be faxed.
  6. convert can also be used to generate a tiff file directly but I
     have been unable to get any of these files to fax using many
     different methods including:
        1. Generating convert's default tiff file output (uncompressed
           color) and used tiff2bw, tiffdither, and tiffcp -c g3:fill
           to create a g3 tiff file.
        2. Using convert's -compress fax option (with many different
           modifiers) to create a g3 tiff file.
        3. Taking the output of the above and using tiffcp to combine a
           good fax file with a bad one to create a new one.  In this
           case, the file gets sent but, using windows fax viewer, the
           good portion displays fine but the bad portion is rendered
           as garbage.
  7. Looking at the udptl traffic, the receiver aborts very early on in
     the conversation between 30 and 100 packets.
  8. The sip traffic looks the same regardless of whether the fax is
     successfully sent or not.  The only difference is the timing.

Now, while I have figured out how to get something to work, I'm left feeling not very confident that this will stand up to the variety of different types of input formats that I expect to convert. I am especially concerned about the fact that if I do generate a bad file, I do not get any kind of feedback that the file is bad (except much later when someone calls to say that they didn't receive the fax I thought I'd sent). Ideally, I'd like the bad fax to be sent as a good fax but, if I can't get that, my second choice is to get a failure response.

I've attached an example of a good and a bad tiff file in bzip2 files. Both were generated from the same input file using the following:

good:

convert "shed in field.jpg" -page letter pdf:sh7.pdf
gs -q -sDEVICE=tiffg3 -sPAPERSIZE=letter -r204x196 -dNOPAUSE -sOutputFile="good.tif" -- "sh7.pdf"

bad:

convert "shed in field.jpg" pdf:sh7.pdf
gs -q -sDEVICE=tiffg3 -sPAPERSIZE=letter -r204x196 -dNOPAUSE -sOutputFile="bad.tif" -- "sh7.pdf"



I haven't included debug traces because I think this behavior can be easily repeated on other systems. If necessary, I will provide them.

Attachment: good.tif.bz2
Description: Binary data

Attachment: bad.tif.bz2
Description: Binary data

_______________________________________________
Callweaver-users mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-users

Reply via email to