David Hanes, Cisco

Various transport methods have been developed for transporting fax communications over an organization’s IP network. However, in the last few years one protocol among these various transport methods has emerged as the clear de facto standard. T.38 is now the predominant protocol choice for contemporary FoIP communications.

T.38 was first introduced as a fax relay standard by the ITU-T in 1998. Although many had high hopes that T.38 would soon become the future of FoIP, other transport methods were already firmly entrenched and proved quite difficult to dislodge. These other transport methods included fax passthrough or voice band data (VBD), which is simply carrying fax communications over high quality voice codecs like G.711, and proprietary fax transport solutions. At least one major industry player developed a pre-standard, proprietary implementation of T.38 that until recently was still supported as the default FoIP transport method on its latest products. Additionally, the ITU-T released the T.37 Store-and-Forward fax standard in 1998, as well. T.37 provided the ability to transport faxes over IP networks using email, which at least conceptually has some real advantages. So, why has T.38 eventually won out over these alternative FoIP transport options?

In retrospect, the answer is fairly straightforward and can be best summarized by the following attributes of T.38: real-time transmission, redundancy, and third party interoperability. These T.38 attributes to one extent or another are almost always critical to customers looking to deploy FoIP in their IP networks. Consequently, a FoIP transport mechanism that fails in supporting one or more of these attributes is usually dismissed. Table 1 compares the alternative FoIP transport methods with the three important attributes of T.38.

Table 1: Comparison of Important T.38 Attributes and Alternative FoIP Transport Options

T.38 Attributes

Fax Passthrough/VBD

Proprietary Fax  Relay Protocols

T.37 Store-and-Forward Fax

Real-time transmission

Yes

Yes

No

Redundancy

Varies

Usually no

Yes

Third Party Interoperability

Varies

No.

Yes


Fax passthrough is the simplest choice for transmitting fax communications over an IP infrastructure. The fax call is treated like a VoIP call from the IP network’s perspective. Using a voice codec like G.711, incoming fax tones are digitized, transported over IP, and then played out to the destination fax endpoint. While this is a real-time process like T.38, the issues of redundancy and third party interoperability can be problematic, as indicated in Table 1.


Fax transmissions contain digital data and are sensitive to any sort of packet loss or excessive jitter in an IP network. Unfortunately, fax passthrough implementations are vendor specific and many vendors do not offer packet redundancy, which involves the transmission of extra copies of the fax data to compensate for packet loss and, thereby, ensure that the entire fax arrives successfully at the destination device. T.38 includes a multi-level redundancy mechanism, while most passthrough offerings fail to offer even a single level of redundancy. For those vendors that do implement passthrough redundancy lab tests show that packet loss even below 1% can still result in unreliable fax transmissions. T.38 with full redundancy enabled has been reported to tolerate packet loss levels in excess of 10%.


Passthrough has also suffered interoperability problems due to the lack of a unified standard. Most contemporary fax passthrough implementations simply use the call control protocol to activate the G.711 codec when a fax passthrough call is needed, but interoperability problems with this method are still seen. The ITU-T attempted to standardize the transmission of fax and modems over a voice codec with the V.152 standard. However, this standard has not gained broad support so interoperability results vary between different vendors when implementing fax passthrough.

As reflected in Table 1, proprietary fax transport protocols suffer even more than fax passthrough when it comes to interoperability. Because these protocols are proprietary, they lock an organization into one vendor’s product line and, in most cases, are inferior to T.38 in terms of performance. On the other hand, T.38 has broad support from multiple vendors, which lends itself naturally to multi-vendor deployments. Also, because T.38 is a unified standard a framework is readily available should interoperability issues be encountered.

Fax transmissions occur in real-time, which is the biggest downfall with a technology like T.37 where the fax is captured and stored. The originating fax machine receives a confirmation and disconnects before the fax is actually delivered to its final destination.  Notifying this originating fax machine that the destination is busy, does not answer, or even truly receives the fax transmission is problematic.

To work around some of these status and confirmation issues, the T.37 standard depends on SMTP (Simple Mail Transport Protocol) and its DSN (Delivery Status Notification) and MDN (Message Disposition Notification) messages. While these DSN and MDN messages are promising, unfortunately they do not fully address the real-time issue; furthermore, they lack wide-ranging support from mail servers and clients.

An additional nail in the coffin of T.37 has been the emergence of IP fax servers. Fax servers typically use T.38 and capitalize on its advantages while also offering all of the fax and email conversion benefits of T.37.

Deploying FoIP can be a daunting task and the selection of a fax transport method is probably the most important decision that you will need to make. Various fax transport options are available but only T.38 provides a real-time transmission support with multi-vendor interoperability and a robust redundancy mechanism. These attributes are some of the main reasons why T.38 has risen to be the de facto standard for FoIP communications and why T.38 should be your first choice when selecting a fax transport solution for your network.

A Closer Look at FoIP Redundancy

T.38’s mutli-level redundancy mechanism is an important reason why it is such a compelling choice as a FoIP transport protocol. This redundancy mechanism is inherently necessary because T.38 is almost always deployed using the UDP (User Datagram Protocol) option of the standard. UDP is a connectionless transport layer protocol and does not guarantee delivery of the T.38 information.

The way that T.38 redundancy works is that fax information is divided into IFP (Internet Facsimile Protocol) packets. These IFP packets are then stuffed into T.38 packets for transmission over the IP network. When redundancy is enabled for T.38, secondary copies of IFP packets are made and transmitted separately from the primary IFP packet. This allows a T.38 packet containing the primary IFP packet to be lost because a subsequent T.38 packet containing the secondary IFP, which is a copy of that primary, will still make it through.

The T.38 standard has a provision to use TCP (Transmission Control Protocol) instead of UDP. TCP differs from UDP in that it is connection-oriented and retransmission mechanisms within TCP ensure that information is not lost. Therefore, redundancy is not required for TCP. Interestingly, T.37 Store-and-Forward fax’s SMTP protocol uses TCP, as well, and also benefits from TCP’s ability to ensure that lost packets are retransmitted. In reality, however, vendors rarely, if ever, support T.38 over TCP. UDP encapsulations are ubiquitously used for real-time communications such as T.38 fax because they are less overhead-intensive than TCP. And while TCP’s method of retransmitting lost packets is sufficient for a non-real time FoIP transport like T.37, these retransmissions add latency that is impractical for most real-time traffic.

David Hanes is a technical expert for Cisco Systems in the area of Unified Communications with a concentration in the design, deployment, and troubleshooting of voice and fax over IP technologies. He is the coauthor of Fax, Modem, and Text for IP Telephony and holds CCIE certification #3491.

253 queries. 1.817 seconds.