Overview

You may notice that faxes to certain numbers fail every time. The same numbers successfully respond to calls from a normal phone and receive faxes from a physical fax machine.

This has been reported when using Brooktrout SR140 with a Sangoma Vega 100G Gateway.

Solution

If you're using Brooktrout SR140 to send faxes, please follow the article Faxes Failing When Using A Brooktrout Device to change the ced_timeout value in Brooktrout's configuration.

In the Wireshark capture, check if failed faxes are associated with BYE where a T38 invite would have been expected, e.g., for the following failure:

"2/22/2022","1:56:10 PM","username@example.com","Name LastName","","","NAME LASTNAME","","555-432-1234","00:50","0","FAILURE","Failed to send fax : Unknown error","Line1",""

FaxMaker (192.168.100.45) is not sending the T38 invite, but instead sends a BYE:

Then we see Q.850 ;cause=16, which is a normal call clearing:

On successful faxes, FaxMaker would send the T38 invite:

To try and improve this, update Brooktrout configurations:

• Set these in btcall.cfg:

line_compression 0
v34_ci_enable 0
v34_2400_baud_ctrl 0
v34_enable 0

• Set these in callctrl.cfg:

sip_Contact=192.168.170.105
media_renegotiate_delay_outbound=5000
t38_fax_version=0

• Run the Brooktrout Configuration Tool as an Administrator:
  • Click the Advanced mode button and click Yes.
  • Navigate to IP Call Control Modules/SIP.
  • Click the T.38 Parameters tab.
  • Click the dropdown for "Fax Transporting Protocol", and set this to T38 with fallback to G711.

After performing these changes, check if the situation improves.

If the issue persists, look for FCS-BAD-sig-end and retrain negative events in a Wireshark capture, for example:

You can check this 3rd-party article for a general description of FCS errors.

Check for Q.850 codes in the Wireshark captures:

• cause=16: Normal call clearing - This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situations, the source of this cause is not the network.
• cause=17: User busy - This cause is used to indicate that the called party is unable to accept another call because the user's busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user-determined user busy, it is noted that the user equipment is compatible with the call.
• cause=19: No answer from user (user alerted) - This value is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time.
• cause=41: This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time, e.g., the user may wish to try another call attempt almost immediately.
• cause=44: Requested circuit/channel not available - This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.

If you notice many causes 41 and especially 44, it's an indication of network issues.

The next step would be to open a ticket with Sangoma, providing them the information above as well as the Wireshark captures.