When upgrading from standard analog fax to Fax over IP. Transport over a network or networks can be challenging to say the least. Two of the primary modes of transport are T.38 and HTTPS.
When implementing the transport method besides the fax settings such as fax transmission speed, one must consider other variables that may or may not affect Fax over IP (FoIP) and have impact on performance.
T.38
T.38 fax relay allows for fax data to be transmitted over IP networks without conversion to an audio stream
Although T.38 relay is a very efficient means of transport over a closed network, it is not without when it comes to ECM (Error Correction Mode) which is not universal thus the gateway support for fax has difficulty dealing with it, and in most cases it is required to be disabled.
One of the largest drawbacks in the current mixed network environment of packet-based and circuit-switched PSTN and open internet connections, T.38 often has a transcoding overhead. That can add latency and cost to fax services and lead to packet loss as outlined below.
When congestion is high a network is unable to relay all packets received, these congestion time frames may be short periods when a large file is transported over the network, or when real-time voice is given priority access over data. Also included could be hardware issues like a poor signal. All of which T.30 is susceptible too.
HTTPS
HTTP(S) uses a request-response paradigm that works well with the distributed nature of the Internet, as a request or response might pass through many intermediate routers and proxy servers. Also a request includes not only the requested content but also relevant status information about the request. This self-contained design allows intermediary servers to perform value-added functions such as load balancing, caching, encryption, and compression.
This means that HTTPS ensures secure and reliable last mile connectivity for fax machines and servers when faxes are being transferred over the Internet. As such HTTPS suffers from none of the issues t.38 has with the open Internet. Latency, packet loss and congestion simply do not interfere with HTTPS packets as they do with T.38.
T.38
Another challenge for T.38 is burst packet loss, a series of consecutive packets from an IP stream unable to reach its termination point. Burst length is the factor that determines the depth of the negative impact on the transmission.
T.38 is susceptible to single packet loss is to the occasional loss of single packets (that is, non-consecutive packets) from a data stream. This type of loss is not as significant as burst losses, but can cause serious issues if it occurs frequently.
HTTPS
HTTP(S) uses Chunked transfer encoding which allows a server (our in our case and ATA to our cloud) to maintain an HTTP persistent connection for dynamically generated content. Chunked encoding has the benefit that it is not necessary to generate the full content before writing the header, as it allows streaming of content as chunks and explicitly signaling the end of the content, making the connection available for the next HTTP request/response. This means that packet loss does not affect HTTPS transfer.
T.38
T.38 is susceptible to jitter, jitter is a combination or packet loss and latency the term Jitter makes reference to variables of latency adds to transmitted packets. Because we are dealing in real-time the stream must be continuous for the data termination to be successful, which is particularly the case with T.38 as it is being carried over an audio stream.
When a packet is not received when required, then the end result is the same as that of burst packet loss, even in the event of late arrival the packet will be discarded.
HTTPS
Due to its nature HTTP(S) data transfer is not susceptible to these issues so will not be affected by them. This allows our faxing solution to be robust regardless of the Internet connection it is using; be it WiFi or satellite etc.
