This article will help you troubleshoot some of the most common issues encountered with faxes.
Faxes can be sent over audio stream (G711 for example) or using t38, which is generally recommended. When involved in a fax transmission, VoipNow can be the receiver, the sender or just a proxy between two fax machines sending/receiving the fax. No matter what role VoipNow plays, the messages exchanged by the parties involved in the setup and transmission of the fax are similar.
The scenario below describes what happens when a fax message is sent to a VoipNow extension by an external party. In our example, VoipNow is the receiver and has the fax center enabled.
Let's see what you should do if the fax is not received.
If you've got all that covered, take a tcpdump capture of the fax. For fax transmission over t38, VoipNow uses udp ports 4000-5999 as defined in /etc/asterisk/udptl.conf:
The other party may use different ports. So, the best way to capture a fax is to use a tcpdump command with a udp filter.
tcpdump -nni any -s 0 udp -w /usr/local/voipnow/admin/htdocs/fax.pcap
The correct sequence is: 1) start the capture; 2) send the fax; 3) wait for it to work or fail; 4) stop the capture.
Once the capture is done, you can download it with from the VoipNow server where it has been taken.
Open the capture using Wireshark. Go to Telephony >> Voip Calls and you will see a list of all the calls in the capture. You can identify the fax by the phone numbers used for sending / receiving the fax message. In our case, it was a fax from 2007 to 3004.
Select the fax and click Flow. In our example, we have a fax answered by VoipNow, so we only have one leg of this call: between the caller and the VoipNow server. If 3004 had been assigned to a fax machine, we would have had a second leg: from 2007 to the extension assigned to 3004. In such cases, select both legs of the call and then click Flow.
You will see a graph showing the SIP and t38 negotiation between the two parties, the sender (10.150.20.13) and the receiver (10.150.20.14).
Here are some screenshots of the entire flow. For a better view, we split the capture of the call.
If the t38 re-INVITE is rejected with an "Unsupported media" message, then the sender may not support t38. Make sure t38 is enabled on their side.
If our example would have been about an outgoing fax, then the first INVITE would have been sent by VoipNow. If you don't see it in the capture, you might be having configuration issues like bad outgoing routing rules, channel costs, and so on. An Asterisk log will help you identify the exact issue.
|It's not necessary for the t38 negociation to happen between the same IPs as the SIP signalling. The two parties can establish this negotiation between different IPs. These IP addresses are mentioned in the "Connection Information" header in the SDP from the t38 INVITE/200OK.|
The fax flow is the following:
This flow should not vary too much. The CED and CNG messages are optional, and the MPS will appear only for multi-page faxes. If one of the parties does not send a message, the other will retry sending the previous one until it times out.
For example, if we send the DIS and do not receive a DCS, we'll try until timeout. This indicates an issue on the sender side. If the issue is on the sender side, you need to tell the sender to check its settings. If the problem is on the VoipNow side, you can continue troubleshooting with an Asterisk log.
To create an Asterisk log:
Reload the logger with asterisk -rx "logger reload":
console => notice,warning,error,fax
Then log the fax with:
This log should offer clues as to why a certain message isn't sent by Asterisk.
If the previous fax was successfully sent, the call returns to a regular audio call and is hung up.
Make sure the call ends properly with a BYE, followed by a 200 OK message. Otherwise, you might get stuck calls in Kamailio.
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.