Overview

Fax routing enables FaxMaker to determine the correct recipient of an incoming fax, so that it is routed to the intended user. FaxMaker provides several methods for this, each with its advantages and disadvantages.

Information

The Purpose and Setup of Fax Routing

Being able to route the fax to the correct end-user is very important for compliance reasons as well. Fax with personal information cannot be left out on a printer for all to see nor can it be sent to the wrong email address.

Occasionally FaxMaker will have a fax it cannot route due to the fax not meeting the criteria for any of the routing rules or one of the routing rules is not complete. In this situation, it is sent to specific users (usually a fax admin) so no faxes are lost.

For this reason, in the routing properties, we have a few settings as well as the routing rules:

Routing Properties

Default Routers This user receives all faxes that are not routed to a user. This could be due to no routing rule or rule unable to be followed depending on the circumstances involved
Receive All Faxes  Any user listed here will receive every fax that comes into FaxMaker. See Setting Up FaxMaker User to Receive All Faxes
Network Share Here a network share can be set up for the routing types used when the option "Send transmission report with link to Fax" is selected. This will set up a folder structure with permissions applied for only the user that receives the fax

Back to top

Routing Rules 

There are 5 types of routing rules that can be used depending on the customer environment. These rules can be seen with the routing node expanded. 

Note: DTMF/DID and MSN require routing to be enabled and the correct number of digits selected in lines and devices in the Advanced tab in the line properties. It will not allow you to create routing rules of this type without routing enabled on these lines.  We also see from the screenshot below that in lines and devices the number of digits to capture is set to 4 and the routing properties are for a 4 digit DID route.

Back to top 

Routing Types

Each of the routing types uses the same information to route the faxes: 

• Users
  
  
  
  The Users tab provides the following options: 
  
  

  Option	Description
  Do not send...	Does not send transmission report at all
  Send transmission report with the fax attached	Sends transmission report with the fax attached in the format selected in Sending/Receiving Options > Sending Options tab
  Save fax and send transmission report with a link to fax	This selection will send a transmission report with a link to the saved fax. The fax will be saved in the network share listed in the Routing Properties > Network Share tab. FaxMaker creates a sub-folder in the share as follows and for security reasons, only fax recipients can access stored faxes. For example, faxes routed to John Doe are only accessible by John Doe: <network share path configured>\yyyy_mm\dd\ where: <network share path configured> - the shared folder where received faxes are stored yyyy - year mm - month dd - day
  Transmission Report Recipients	Here you can add licensed users to receive the fax report that meets this routing rule's requirements.

• Options 

  
  
  

  Option	Description
  CSID/DTMF/DID/MSN/OCR/Line	Here you can change the rule name/number
  Exclude this line from all archiving options	-

• Printers
  
  

  Option	Description
  Enable fax auto-printing	Enables auto-printing of faxes when the fax meets this routing rule's requirements
  Select printer	A printer can be selected to auto-print incoming faxes to

• Backup2Folder 
  
  

  Option	Description
  Automatically backup faxes to a folder	Insert the path to the folder where you would like the faxes backed up.
  Backup faxes in this format	Select the format in which you would like the faxes backed up.

Email2FaxGateway > SMTP Connector

• The Email2FaxGateway is where the outbound (from FaxMaker) email settings are configured.
• The Mail server name/IP and port will be the name or IP of the mail server and the port will coincide with whether or not a secure connection is used.
• Ports: 25, 465, and 587
• All mail sent from FaxMaker to any users will be sent to this single mail server so all FaxMaker users/admins should have a mailbox on this server. 
• Emails are sent from address fax@faxmaker.com
  
  

Back to top

Troubleshooting Fax Routing

Troubleshooting fax routing will require logging from the product. You need to gather the troubleshooting logs before you can proceed to the next steps. 

Once logs are received a few things can be verified in the configuration database (fmdb_rul.mdb).  

• In the support\data\databases folder, open the fmdb_rul.mdb (Access Database).
• Check the Line/MSN/DID etc table (e.g. tb_line, tb_msn, tb_did) for the routing rules that are actually in place. In the screenshot below, many 4-digit DID routes are visible.  
  
  

• In the next screenshot, we can see in the same database for the table tb_lines showing the number of digits selected for routing; the field is Lines_LineConfig_dtmflength. We can see this is set for 4 which matches the created DID/DTMF routes in the tb_did table.  
  
  

• Once the basic config is verified we can review the logs.
  • Review faxserver.gfi_log.txt first to see what information that would trigger a routing rule is being received.
    
    
    
    

    Line No.	Info	Description
    1	"faxsrvFaxReceived() >> "	Start of fax being received in this log. Technically the fax has already been received by the fax device and the fax server service is now processing the incoming fax.
    8	"faxsrvFaxReceived() : Fax from [Fax received from 15024545353]"	Shows the number the fax was received from
    12	"AddRecipientsByType() >> Rule Type : [csid =]"	Attempting to verify the information for rule type CSID.  The CSID, in this case, is blank and line 13 shows: No Rules triggered which match RuleType Criteria
    14	"AddRecipientsByType() >> Rule Type : [did =3218]"	From this we can see that the DID information received from the PBX/Gateway was 3218 and from the screenshot of tb_did we see 3218 is there as a valid routing rule
    15 -17	Gives us the end result of Routing: adding user [ayoung@thisorthat.com] Line 15 shows the GUID string that is queried against the user database and the email address returned  This user is now added for this routing rule
    18 and 20	Verification of Line and MSN routing.  Both return No Rules triggered which match RuleType Criteria
    22	"AddRecipientsByType() >> Rule Type : [cpyrouters ]"	cpyrouters or copy routers is for users who receive all faxes, which in this case there are none.
    26	"faxsrvFaxReceived() <<"	Completion of the fax processing

     

    Takeaways from the above:

    • If we were having issues with faxes going to DID 3218, we could search this log for [did=3218] to find the instances of this.
    • If the issue were with all incoming faxes, we could search for faxsrvFaxReceived() >> and skip through each received fax.
    • Note the timestamps as these are/can be used to navigate between FaxMaker logs.

  • Now we can review the notifications.gfi_log.txt file and see the notification email was created and sent to the correct end-user. 

    • The screenshots below are found from this log creating a successful fax inbound notification.
    • The notification is created by the FaxServer service and once created placed in the FaxMaker\in folder for the message transfer agent service to deliver.  
      
       

      Line No.	Description
      2	This line tells us it is using the fax_recv_success.fbt file for the template for this notification
      6 - 31	Listing of the tags that are being replaced in this notification
      7	This line gives the date and time the fax was received
      33	Shows that there was an attachment added to the notification in pdf format
      36	Shows SenderNumber "15024545353", the same number as the FaxServer log
      42	Shows Setting To & SMTP RCPT TO ayoung@thisorthat.com, which is the user we see added in the FaxServer log line 17

       

    • From the log above we see the notification was created from the fax in the previous log addressed to the correct user.

  • Using the smtpin.fmlogger.txt to verify the email was received by the mail server specified in the Email2FaxGateway > SMTP connector tab (see GFIFM-203 "Email2FAXGateway" section for more information on this configuration). 
    
    

    • At first glance from this log, we see SMTP errors giving an invalid address.
    • The timestamp from the notifications log was 2019-06-25,09:59:20. Usually, there is a 10 to 15-second delay in the notification being created, the mail being sent by the FaxMaker email client, and the receiving mail server sending a response.
    • Line 7: 2019-06-25,09-59-34, , , ,Success - Message uploaded.  We see this is 14 seconds after the previous logs' timestamp and shows that the message was successfully uploaded.
    • The message transfer agent will then move the file to the FaxMaker\in\emailqueue folder and attempt to deliver the email to the server listed in the Email2FaxGateway > SMTP connector tab. If successfully delivered, the file is removed and the message is logged in the smtpin log. If the delivery is unsuccessful, it will be deposited in the FaxMaker\in\undeliverable folder. From here it will be retried every 5 minutes until delivered or manually removed from this location.
    • The rest of the errors shown here are from 2 emails in the FaxMaker\In\Undeliverable folder. We can see they are retried every 5 minutes, as items in the undeliverable folder are. They had bad email addresses - from a user who was removed from the company’s Active Directory but not removed from FaxMaker. These items were removed and these errors stopped after that.

• Check for issues with the dropping files in a folder (e.g. Backup2Folder or Network Share).

  • When Backup2Folder or Network Share are used the log entry will appear like the highlighted FaxServer log entry below.
  • Routing: adding backup2folder[C:\root] -  If there was an issue writing to this location this entry would not be here and there would be a write error, depending on the Windows error given. 
    
      

• Check Auto-Printing. 
  
   

  • First, notice the auto-printing  in the FaxServer logging above:
    
    "Routing:adding autoprinter[{6DBB75ED-F0B5-4D21-B3B4-49F5B296BA44}]"
    "Added autoprint successfully."
    
    This tells us the auto-printing from the routing was detected and started.

• Next, in the AutoPrintTaskTrigger.gfi_log.txt file, we will see logging showing the task initiated:
  
   

• We can then review the task scheduler from the Administrative Tools in Control Panel and review the task used to auto-print inbound faxes.

• Highlighted in the screenshot below is something you may see in version 19.  Run whether user is logged on or not needs to be selected rather than Run only when user is logged on. 
  
  

• You may also select the history tab to see the history of the task being triggered and the results of the task being run. 

• Finally, in the repprint.gfi_log.txt file, we should see the printing taking place.