[Home]

Summary:ASTERISK-14707: SendFax without reliable transmission.
Reporter:chrisde (chrisde)Labels:
Date Opened:2009-08-24 14:14:16Date Closed:2011-06-07 14:08:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_fax
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) debug1.txt
( 1) debug2.txt
( 2) debug3.txt
( 3) debug4-success.txt
( 4) udptl.conf
Description:Using sendfax application there are random transmission errors.

Transmission has been tested extensively with different carriers, different documents and also different asterisk versions but same results.

In some cases (approximately 50% of the cases) fax transmission is SUCCESSFUL
In other cases (approx. 10%) fax transmission ends with

WARNING[14167]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=21: No response after sending a page.

in approx. 40% I get

WARNING[16247]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=20: Received no response to DCS or TCF.

Because only 50% of the faxes pass with OK the functionality is not reliable and the severity of this problem is major.

****** ADDITIONAL INFORMATION ******

Attached (debug1.txt) there is the debug output for the transmission of a 1 page document (windows printer test file) with an error:
[Aug 24 18:20:38] WARNING[14167]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=21: No response after sending a page.

Also there is debug output attached for transmission of the same document with same faxnumber and faxservice with success (debug2.txt)

debug3.txt shows the debug output (other svn version for testing) with error
WARNING[16247]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=20: Received no response to DCS or TCF.

spandsp is spandsp-0.0.6pre12.tgz
tifflib is 3.8.2
Comments:By: Kevin P. Fleming (kpfleming) 2009-08-24 14:22:48

This cannot be a 'major' issue, as it does not affect the proper operation of Asterisk itself or any channel driver.

Please keep in mind that app_fax is just a wrapper around the FAX functionality of the spandsp library; there isn't any code in Asterisk that actually implements any FAX protocol. If the failures you are experiencing are FAX protocol errors, you'll have to work with the author of spandsp to troubleshoot them.

Your debug1 and debug2 logs don't include enough information to actually see if there was any negotiation problems; if you are going to upload a log, please use 'core set verbose 10', 'core set debug 10' and 'sip set debug on', and ensure that your console logger channel has all the logger levels enabled (debug, verbose, and all the rest).

Your debug3 log is from an older revision of Asterisk 1.6.0 and exhibits an SDP formatting problem that does not exist in current revisions.
By: chrisde (chrisde) 2009-08-24 16:15:04

I didn't enable sip debugging because as I can see this is not a sip issue as the udptl packets are transmitted after the t.38 connection is established. You can see this in the newly attached debug4-success.txt. Also these error codes are retrieved, as I understand, from spandsp.

So if you say not to support the functionality behind the SendFax application (that is spandsp) with this bug tracker you will have to close this bug. And have probably a working wrapper for a non working FAX functionality.
By: Kevin P. Fleming (kpfleming) 2009-08-24 16:22:30

It was possible that it was a SIP issue, if the T.38 negotiations in your failure cases did not happen correctly. Just because there are UDPTL packets present does not mean they are formatted in the way that the receiver expects :-)

Yes, you are correct, the error codes are from the spandsp library itself. SendFAX/ReceiveFAX just provide an easy to use interface to the library. They do work in the vast majority of cases, we have many, many users who use app_fax/spandsp for thousands of FAXes every month/week/day. In this case, the fact that the problem appears to be in spandsp makes it nearly impossible for us to resolve, the same as would be true if the spandsp maintainers analyzed the UDPTL packet stream and determined that the failure was in the remote T.38 endpoint... there is just a limit to what we can do when we don't maintain the entire chain of communication.

I encourage you to contact the spandsp author; he is very willing to deal with issues like this and improve his code. As an alternative, you can try Digium's Fax For Asterisk product, which uses a completely different FAX stack and may not suffer from this issue.