Definition of FAX_FAILURE_PARTIAL

I have been treating FAX_FAILURE_PARTIAL as a failure and resending any faxes that have completed with FAX_FAILURE_PARTIAL. On reviewing the examples I have I see that they appear to happen after a disconnecting event, so I am guessing that the faxes have completed sending/receiving and there has been an issue with final disconnect.

The Fax For Asterisk manual does not document this error. Is there any resource that will confirm whether my guess is correct?

The particular error occurs when some or even all of the images have been transferred, but some protocol error occurred.

It isn’t guaranteed that it only will occur on a disconnecting event, but I would guess that if all of the images have been transferred, then it did occur at that point.

Thanks.

All the occurrences I have seen occurred after a fax status event with “DCN Count: 1”. I assume that means that the fax is effectively complete, but as far as I can see there is no way to access that information from the dial plan and use that as a basis to treat the fax as successful?

You can use FAXSTATUS and/or FAXSTATUSSTRING to detect if you succeeded or failed. In the case of a failure, you may be able to use the FAXPAGES channel variable to determine if the entire fax was sent anyway.

I’m not sure I can rely on FAXPAGES as it seems to be set to zero for most errors, e.g. I have a message logged where the last fax status event reports 4 pages transmitted but the FAXPAGES variable is set to zero after “remote channel hungup”.

Even if I can rely on FAXPAGES, I could use it for an outgoing fax, but for an incoming fax I don’t know how many pages I should have received, so the FAXPAGES variable can’t tell me whether I got a complete FAX or not.

According to Fax, Modem, and Text for IP Telephony “The disconnect, or DCN message, is the last message seen in a fax transaction and indicates the initiation of Phase E, call disconnect. A response or acknowledgment is not needed for this message. This message signifies a graceful disconnect to the fax call, and both sides prepare for a new fax transaction by returning to an on-hook state.”

My interpretation is that once a DCN is sent or received the call is over and any errors after that point should be ignored. I have a fax logged with a fax status event showing state FAX_FINISHED, DCN count: 1, after which variable FAXERROR is set to 3RD_FRM_CHECK_ERROR and FAXSTATUSSTRING is set to FAX_FAILURE_PARTIAL. I’m guessing that a hangup has caused the lower level protocol handling to report an error after the disconnect. Asterisk fax is reporting it as an error, but I think it should be ignored at that point as a hangup is expected?

Asterisk has no visibility into why the error was reported, merely that the stack below it has told it that an error occurred, which it then dutifully reports back to you via the channel variables.

If something is hanging up without properly disconnecting the session - which may or may not be what is happening - then that would be an error, at least from the fax stack’s perspective.

Because this is fax, which:

  1. May represent the nadir of man’s protocol achievement
  2. Has sucked the life out of more developers than I care to think about
  3. Is also FFA and is no longer being updated for new versions of Asterisk - effectively EOL’d

No code modification is going to occur to provide any functionality other than what is occurring today. Your best bet is to use the channel variables and/or AMI events to monitor why a failure occurred, and then use higher level logic in the dialplan and/or an external system to make decisions about whether or not the fax truly failed or succeeded.

1 Like

To me the why isn’t really important, it’s the when. The error appears to occur after the disconnect at which point it’s allowed to stop communicating, however a failure to communicate appears to be treated as an error.

As the trace shows it has received a DCN, I can’t see how any any disconnect would not be proper, but I am not a fax expert and I may be missing something.

My takeout from that is that we need to find another fax solution. Is there something official I can quote on FFA being effectively EOL?

http://blogs.digium.com/2015/06/26/fax-asterisk-res_fax_digium-no-longer-supported-asterisk-13-later/

That’s much better. My first retry of a test which consistently gave me FAX_FAILURE_PARTIAL with Asterisk 11 and FFA, seemed to work almost perfectly with Asterisk 13 and spandsp.

I observed 2 minor issues, which were:
Log message "res_fax_spandsp.c: WARNING T.30 ECM carrier not found"
The value of $FAXRESOLUTION was 8031x3850

Googling the log message didn’t provide any useful information, but it works, so I’m not really bothered. I don’t use $FAXRESOLUTION, other than logging the value, so I can live with that as well.

I’ve just found that I can’t monitor progress of long faxes because Asterisk 13/spandsp doesn’t seem to send FAXStatus events to AMI. I relied on these to monitor faxes in Asterisk 11 and there doesn’t seem to be a way to monitor long running faxes in AMI in Asterisk 13.