Measures for improving the success rate of fax transmission with SwyxFax via SIP provider

Depending on the operating environment, using SwyxFax via SIP provider may imply a relatively high error rate.

This article describes four measures for improving the success rate:

1. Using QoS
2. Configuring a bandwidth reservation on the router
3. Checking the capacity of the switches in the customer network and the rest of the network infrastructure between SwyxServer and internet access
4. Using an asynchronous tracing for SwyxFax Server

Depending on the operating environment, using SwyxFax via SIP provider may imply a relatively high fax transmission error rate.

Main cause for the errors is packet loss at the LAN/WAN interface (i.e. on the customer router), in the provider network or at network transitions between different provider networks. Local performance bottlenecks on SwyxServer can cause considerable problems, too.

Unfortunately, fax transmission is very sensitive to dropouts and jitter. This is a result of its origins in purely analog transmission environments, such problems are not supposed to happen and thus can lead to aborts quickly. In such cases fax transmission is aborted by the recipient on the opposite side through going on hook.

This article describes four measures for improving the transmission quality which are all together supposed to result in a considerable increase of the success rate. These include:

1. Using QoS
   Providers can handle pakets marked as VoIP traffic with higher priority so that the probability of packet loss and/or jitter decreases significantly. If this is actually going to happen depends on the senders’ as well as the recipients’ VoIP provider since the media data must be transmitted via both networks.
   
   Please find detailed information on how to configure policy-based QoS on your SwyxWare machine in the attached PDF file "Policy_QoS_EN.pdf".
    
2. Configuring prioritization and bandwidth reservation on the router
   With most routers the above mentioned step 1 is required since DSCP tagging is used by the router to trigger the corresponding rules. On the router you have to configure that VoIP traffic is always being prioritized over other services. To assure that this works properly you have to configure a bandwidth reservation, too. This means: The router then reserves a defined bandwidth for this VoIP data traffic transmission so that no other transmissions (downloads, uploads, emails etc.) can interfere and cause delays or even packet loss by fully utilizing the internet connection.
   
   The respective configuration settings depend on router manufacturer and type. For detailed information, please contact your router manufacturer. Unfortunately, Swyx cannot provide this information since there are too many different types of routers on the market.
   
   If the customer uses a Lancom router the following link to the manufacturer’s knowledgebase provides further information. This document describes the complete configuration for Lancom devices: https://www2.lancom.de/kb.nsf/1276/09194F665FD7FB14C1256FFD003903FE?OpenDocument
    
3. Checking the capacity of the switches in the customer network and the rest of the infrastructure between SwyxServer and internet access
   Packet loss not only occurs at the LAN/WAN transition but also within the customer network itself. If an error occurs we recommend you to check the utilization of the corresponding switches and check also for possible bit errors at the corresponding switchports. Converters in the network can result in packet loss or delays, too, e.g. due to the connection of different customer buildings via a micro wave radio relay bridging solution or something similar or VPNs between separate customer networks.
    
4. Using an asynchronous tracing for SwyxFax Server
   Like all other SwyxWare services, the fax server service writes a logfile on the local hard disk. At the same time it reads the data to be transferred from the hard disk while transmitting a fax. Reading the data from the hard disk, transmitting it and writing the trace logs is all happening simultaneously. As a result, latencies in the hard disk subsystem can cause delays and  higher jitter. If the jitter is so high that the receiving fax device identifies a gap, transmission may be aborted.
   
   This problem especially occurs with machines which "share" their physical hard disks with other VMs. However, it can also occur with physical machines with a high hard disk utilization. A high utilization can be caused e.g. by other services which are running on the same machine simultaneously with SwyxWare. When the number of simultaneous calls is very high, SwyxWare itself can cause a high base load, especially in combination with call center applications or similar additional software. The mentioned asynchronous tracing moves the writing of trace output to a seperate thread, thus chronologically decoupling the writing operations and the fax data handling.
   
   To configure asynchronous tracing, under "HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Swyx\IpPbxFaxSrv\CurrentVersion\Tracing", create a new DWORD value with the name "UseTraceThread" and set it to "1". The additional thread for the trace logs is activated immediately without restarting the service. You can check the success in the trace file, the trace line should look like this:
   
   12 14:29:15.778 0026dc Alws SwyxLib    00000000 00000000 STrace::StartTraceThread : Trace Thread started
   
   Please note:If you start the configuration assistent or reset the trace settings via the SwyxWare tracetool, this registry entry is being deleted since all trace settings are being reset to the default values defined in the "TraceLevelDefault.xml" file.
   
   To avoid this problem in a simple way, you can copy the "TraceLevelDefault.xml" file, which is attached to this article, to your SwyxWare program directory. This file contains the new trace entry, so that the registry entry will not be deleted anymore. However, if you perform a repair installation of SwyxWare at a later time, you have to repeat these processes since the default file will be overwritten, too.
   
   Starting with version 2015 R40.3.0, this new registry value is included by default. In this case, step 4 is no longer necessary.

The above measures are all together supposed to help you avoid the described performance bottlenecks through all included components. This should result in a measurable increase of the success rate of SwyxFax transmissions via SIP provider.  Thus we recommend you to perform all four measures to achieve an optimal result.