By Steve F, March 31, 2026

To this day, fax remains an essential method for transmitting legal and official documents in the United States. It is still widely used for medical prescriptions, legal notices, and government communications. Therefore, the ability to reliably support customers’ existing fax services is a critical factor in the successful deployment of any POTS replacement solution.

1   A Brief Review of Fax over IP Technologies

1.1  T.30 Fax

Similar to alarm panels, the T.30 fax protocol was originally developed for PSTN networks and has strict requirements for synchronization and latency. When migrated to VoIP networks, traditional fax machines connected via standard ATAs often encounter issues such as failed session establishment or incomplete transmissions. This is especially problematic for long documents (e.g., dozens of pages), which frequently fail to send successfully.

1.2   T.38 Fax

To address these challenges, the ITU defined the T.38 protocol for transmitting fax over Next Generation Networks (NGN), which are based on protocols such as H.323, H.248, and SIP.

T.38 is an excellent protocol and can handle most fax transmission scenarios over IP networks. However, its adoption is limited by two main drawbacks:

• Both endpoints must support T.38, and in some cases, FEC (Forward Error Correction) is also required for optimal performance.

• Due to inherent IP network issues such as latency, jitter, and packet loss, T.38 cannot guarantee reliability in all conditions—especially during sudden congestion or network interruptions lasting several seconds.

1.3   T.37 Fax (eFax)

To ensure fax reliability even in unstable IP network conditions, the ITU introduced the T.37 protocol, which uses a store-and-forward approach.

The principle of T.37 is straightforward:

• The ATA emulates a fax machine.

• When sending, the ATA receives the fax from the connected fax machine via its FXS port and stores it as a TIFF file.

• When receiving, the ATA converts the TIFF file back into T.30 format and sends it to the fax machine.

As for how the TIFF file is delivered to the destination, T.37 recommends using email protocols such as SMTP/POP3, though this is not mandatory. This is why T.37 is often referred to as the Fax-to-Email standard.

Most eFax solutions on the market are variations of T.37. However, since email-based transmission may not meet privacy and security requirements, many implementations use dedicated fax servers with secure protocols such as SSL for file transfer.

2   How Flyingvoice Helps MSPs Deliver Fax Services

Flyingvoice’s POTS replacement solution provides strong support for all three methods: T.30, T.38, and T.37.

• For T.30 and T.38, Flyingvoice solutions can integrate seamlessly with existing UC platforms without any code modification.

• For T.37, Flyingvoice offers comprehensive FlyingvoiceCloud API documentation and demo code, enabling MSPs to develop their own store-and-forward fax servers within just 1–2 weeks.

2.1   For MSPs Already Using T.38 Gateways

All Flyingvoice POTS replacement CPE devices are fully T.38-compatible.

If an MSP has already deployed a T.38 gateway, they can simply enable T.38 on the Flyingvoice POTS CPE devices—no additional integration work is required.

2.2   For MSPs Using Existing UC Platforms

For MSPs that only have voice-oriented UC platforms, is it possible to provide reliable fax services without investing in new infrastructure?

The answer is yes—by using the Flyingvoice POTS Media SBC.

The Flyingvoice POTS Media SBC acts as a transparent device to the UC platform:

• The UC platform is unaware of its existence and requires no configuration changes.

• The SBC handles packet retransmission and error correction between the Flyingvoice POTS CPE (e.g., PR12) and converts the traffic into standard G.711 audio streams for the UC platform.

This enables both T.38 and T.30 + SBC provide real-time fax services, delivering real-time fax services equivalent to PSTN. A successful transmission confirms that the receiving fax machine has received the document.

Both T.38 and T.30 + SBC performance depends on network quality. According to Flyingvoice Lab testing:

• End-to-end latency (including jitter) should be < 300 ms

• Packet loss should be < 3%

2.3   For MSPs Deploying or Planning eFax Servers

For MSPs that already have or plan to deploy their own eFax servers, Flyingvoice POTS CPE provides built-in T.37 support, Combined with FlyingvoiceCloud APIs, development and deployment can be completed quickly. For detailed technical documentation, please contact our sales representative.

Over all, T.37 is a non-real-time (store-and-forward) solution. The advantage is that it has very low performance requirements for the IP network, and fax sending and receiving can be achieved even under intermittent network conditions.

The disadvantage is that the fact that the sending fax machine displays a successful transmission status only means that the fax server has correctly received the fax file; it does not mean that the receiving fax machine has correctly received the fax file. Confirmation of successful fax transmission often has a delay, requiring a wait of several minutes to over ten minutes.

3   Summary: Which Solution Is Best?

For UC service providers, the T.38 approach (if supported by the UC Platform) or the T.30 + SBC solution (no UC Platform requirements) is generally the most convenient. Integration with Flyingvoice solutions can be completed within days, providing reliable POTS Replacement services without modifying existing systems.

The T.38 or T.30 + SBC approach is suitable for installation locations with relatively good network conditions. According to Flyingvoice Labs' assessment, the network generally requires an end-to-end overall latency (fixed latency + jitter) of less than 300ms and a packet loss rate of less than 3%.

For installation locations with poor network conditions, such as frequent jitter greater than 500ms, packet loss rates greater than 5%, or frequent network outages, the store-and-forward T.37 approach is a better choice.