Implementing Fax over IP
By David Hanes
Introduction
Voice over IP (VoIP) has revolutionized the world of telecommunications and it is now a mainstream solution in most enterprise networks. The wide-ranging benefits of VoIP solutions include cost savings over traditional telephony networks, increased flexibility, and better scalability. However, during the rapid migration to VoIP, other types of traditional telephony communication were often overlooked or ignored, even though these alternative traffic types could also benefit with a move to an IP infrastructure. The most important of these overlooked telephony communications is fax.
One reason that fax over IP (FoIP) has somewhat lagged behind the large shift to VoIP is that fax communications are rarely the dominant form of telephony communication for a business. Migrating an organization’s main form of telephony communication over to IP was the first priority and this is almost always voice traffic. Being the minority form of communication relegated fax migration to IP to the backseat behind voice. Now, as VoIP has matured, organizations continue to push towards a comprehensive Unified Communications solution where IP is the backbone for all communications, including fax.
In some cases, fax and voice were initially migrated over to IP together until it quickly became apparent that fax communications were different than voice. Treating fax traffic like voice traffic in an IP network is not a reliable solution and faxes were often moved back to their traditional telephony connections. However, numerous solutions are now available designed specifically to reliably handle the transport of fax communications.
Fax Overview
Before diving into specific FoIP solutions, it is imperative that you understand some basic fax concepts. Mainstream fax technology has always been classified into groups as shown in Table 1.
Table 1: Fax Group Classifications
| Group Designation |
Relevant ITU-T
Specifications |
Transmission Time
(8.5" X 11" page) |
| G1 (Group 1) |
T.2 |
6 minutes |
| G2 (Group 2) |
T.3 |
3 minutes |
| G3 (Group 3) |
T.30, T.4, and T.6 |
1 minute or less |
| Super Group 3 (SG3) |
T.30 and T.6 |
Less than a minute |
| G4 (Group 4) |
T.6, T.503, T.521, T.563, T.72, T.62, T.62 bis, T.70, and F.161 |
Less than a minute |
The two main classifications of fax communications encountered today are Group 3 (G3) and Super Group 3 (SG3). The older G1 and G2 fax groupings were replaced by G3 and are no longer used. The G4 standard has never been widely implemented. Therefore, the G3 and SG3 classifications are the only ones that are relevant when dealing with FoIP.
The G3 fax standard encompasses three ITU-T specifications, T.30, T.4, and T.6. The T.30 protocol handles the call setup and other negotiations for the sending of the fax page information. Parameters such as paper size, image resolution, fax page encoding algorithm, and page transmission speed are exchanged in T.30 messages between the fax endpoints. Because these T.30 messages are sent at a slow speed of only 300 bps, much higher speeds are negotiated for the sending of the actual fax pages.
The T.4 and T.6 specifications define the encoding or compression algorithm that is to be utilized for the fax page transmission. The algorithms of Modified Huffman (MH) and Modified READ (MR) are detailed in the T.4 specification while Modifed Modified READ (MMR) is documented in the T.6 specification. When transmitting plain text, the MMR compression algorithm is the most efficient, followed by MR. The MH algorithm is less complicated and less efficient when handling text. Most fax devices support all of these compression algorithms and at a minimum they must support MH. Figure 1 illustrates the roles played by the T.30, T.4, and T.6 protocols during a G3 fax transaction.
While G3 fax devices have a maximum page transmission speed of 14400 bps, SG3 fax machines use the V.34 modulation to transmit at speeds up to 33600 bps. While all fax machines today support the G3 standard, SG3 support is optional and usually found on pricier fax machines. Fax machines with SG3 support will always try SG3 first and then gracefully fall back to a G3 fax transaction if the other fax device lacks support for SG3.
To achieve the faster page transmission speeds, the V.34 modulation used by SG3 is very different than the modulations used in G3 fax transactions. This modulation difference causes problems when it comes to transporting SG3 over IP. As discussed in the next section you will see that there are currently less transport options for SG3 fax communications than for G3 fax calls.
FoIP Transport Methods
Transporting fax over IP infrastructures occurs using one of three methods: passthrough, relay, or T.37 Store-and-Forward fax. Both passthrough and relay transport methods are real-time, meaning that the fax communication between the fax endpoints happens instantly and, from the fax machine’s perspective, they are communicating with one another as if they were directly connected over the Public Switched Telephone Network (PSTN). The T.37 Store-and-Forward fax transport method breaks the real-time nature of a fax transaction. Fax machines communicate only with the voice gateways themselves as fax information is converted to and from emails and transported across the IP network.
Passthrough is the simplest transport method for fax communications, especially if you already have a grasp of how VoIP works. In a VoIP network, human speech is sampled and digitized using one of the various coder/decoders (codecs) available on a Cisco voice product. These codecs are almost always designed and optimized for human speech, especially those that implement high compression algorithms. These high compression voice codecs retain good voice quality while also providing significant bandwidth savings. Once the voice has been digitized using the selected codec, the information is packaged inside the Real Time Protocol (RTP) and sent across the IP network.
If you now substitute fax tones in place of human speech and apply the same digitization by means of a codec along with an RTP transport mechanism over IP, then you have fax passthrough. However, most voice codecs are not optimized for fax tones and in fact distort the fax tones, especially the high compression voice codecs. As a result, you must use a voice codec with minimal compression for fax passthrough and this means the G.711 voice codec. A simple illustration of how passthrough works is shown in Figure 2.
The other real-time fax transport method is relay. Fax relay is a bit more complicated than passthrough. Instead of digitizing the analog fax tones using the G.711 codec, the voice gateways strip the analog carrier from the incoming fax tones and extract the binary information. In fact, fax messages are simple data frames using the High-Level Data Link Control (HDLC) format. With the analog carrier removed, the fax HDLC frames are then encapsulated in a fax relay protocol and transported across the IP network as shown in Figure 3.
Cisco currently supports two different types of relay on its voice products, T.38 fax relay and Cisco fax relay. Cisco fax relay was a pre-standard fax relay implementation and is still the default on most Cisco voice gateways. T.38 fax relay is the de facto standard for FoIP transport today and allows for interoperability with third party products.
T.37 Store-and-Forward fax provides for the transport of fax pages using email over an IP network. Two processes are necessary to implement T.37: onramp (for faxes coming "on" to the voice gateway to be converted into email) and offramp (for faxes going "off" the voice gateway after being converted from an email into a standard fax call). The T.37 Store-and Forward onramp process is graphically demonstrated in Figure 4.
In Figure 4, the T.37 onramp process is initiated when the originating fax machine communicates using standard analog G3 fax tones with a voice gateway. This onramp gateway acts exactly like a terminating fax machine "talking" the T.30 and T.4/T.6 fax protocols. From the perspective of the originating fax machine, the fax communication has been sent and accepted by another fax device (which happens to be the onramp gateway). The onramp gateway takes the analog fax tones containing the fax pages and creates an email that is sent to a mail server to be routed through the IP network. If the recipient of this fax has an email account that this mail server can reach then the fax can be delivered to the recipient as an email with the fax pages showing up as attachments. If the recipient of the original fax is not reachable by email then the fax mail can be forwarded to the appropriate offramp gateway to be transmitted over the PSTN.
The T.37 Store-and-Forward offramp process is the opposite of the onramp process. Emails containing fax page attachments are sent from a mail server to the offramp gateway. The offramp gateway extracts the attached pages from the email as well as the phone number to dial. A normal G3 fax call is then placed by the offramp gateway to the destination phone number specified in the email. Figure 5 highlights the T.37 Store-and-Forward fax offramp process.
Design Best Practices
When designing a FoIP solution, the first decision that you have to make is what transport option is the best for your network and your faxing needs. The easiest way to make this decision is to first decide if you need a real-time fax transport option or if a solution such as T.37 Store-and-Forward fax is acceptable.
The main-advantage of real-time fax solutions such as passthrough and relay is that the real-time nature of the original fax transaction is not broken. Instant confirmation or notification of fax success or failure is provided with real-time fax transports and this is important for critical fax documents.
While T.37 Store-and Forward fax is not real-time, the allure of sending and receiving faxes through email is enticing for many organizations. Because T.37 is not real time, it is dependent on email Message Disposition Notification (MDN) and Delivery Status Notification (DSN) messages for status and notifications of the fax email. Although MDN and DSN messages are potentially useful, they are not always supported or enabled on mail servers and email clients. Unlike the instant confirmation reports available with real-time fax transport methods, it is difficult with T.37 to confirm whether a fax was ever received at its final destination.
Cisco’s implementation of T.37 also lacks support for the optional Error Correction Mode (ECM) feature found on most G3 fax machines. ECM ensures that fax communications are received error free by retransmitting corrupted scan lines that make up the image on the fax page. In networks with impairments, the lack of ECM support does not allow fax page information to be corrected. In some cases this can lead to fax pages that have image quality issues, incomplete attachments in the fax email, or even failure of the fax call.
With few exceptions, the recommendation for real-time FoIP transport from a design best practices perspective is T.38 fax relay. With robust features such as redundancy, fallback, and third party interoperability, T.38 fax relay is the de facto standard for FoIP today. Table 2 highlights some of the major advantages of T.38 and allows for a quick comparison with the other real-time fax methods of Cisco fax relay and passthrough.
As shown in Table 2, T.38 fax relay excels in a number of categories compared to Cisco fax relay and passthrough. It is the only real-time fax transport option that is standards-based so third party product integration is easier to accomplish. Bandwidth consumption for T.38 is lower than it is for Cisco fax relay and passthrough. This can be a critical attribute for networks with low-bandwidth WAN links. T.38 fax relay has a robust redundancy mechanism that still keeps the bandwidth consumption reasonable at 41 Kbps/call. Enabling redundancy for passthrough consumes a much larger amount of bandwidth at 170 Kbps/call. T.38 also is the only transport method that, on Cisco voice gateways, has an option to fallback to Cisco fax relay or passthrough if the T.38 negotiation should happen to fail. Last of all, even though passthrough can already support SG3 fax calls, this feature will soon be available for Cisco’s implementation of T.38 as well.
One disadvantage of T.38 is that it lacks support for Secure RTP (SRTP) because Cisco’s implementation uses a User Datagram Protocol Transport Layer (UDPTL) header instead of RTP. This prevents organizations that need secure faxing using SRTP from using T.38 fax relay. However, overall it is easy to see why T.38 fax relay is the predominant choice for handling FoIP today.
When implementing FoIP, a few critical design best practices exist. Following these best practices in the beginning can save you time and trouble later on. Design best practices for FoIP include the following:
- T.38 fax relay is the recommended choice for FoIP.
- Fax relay protocols, such as T.38 fax relay and Cisco fax relay, consume less bandwidth than passthrough. If bandwidth consumption is a concern then choose a relay protocol.
- Packet loss is more harmful to FoIP than VoIP. Ensure that packet loss does not occur for your fax calls by implementing appropriate Quality of Service (QoS) policies in your network. If packet loss or other impairments are unavoidable, then use T.38 fax relay with its redundancy features enabled.
- One of the biggest causes of FoIP issues are PSTN impairments, especially slips or other errors on digital T1/E1 interfaces on a voice gateway. These errors do not typically impact voice calls, but they can be devastating to fax calls. Make sure that all digital PSTN interfaces that are in the fax path are error-free or you will most likely have problems with FoIP.
- Currently, the only transport method that handles SG3 fax calls at their native speeds is passthrough. If you must transport SG3 fax communications using either T.38 or Cisco fax relay, then make sure IOS version 12.4(4)T or later is used on your voice gateways. An SG3 spoofing feature introduced in this IOS version automatically forces SG3 fax calls to fall back to normal G3 fax calls that are compatible with both Cisco and T.38 fax relay. Also, please note that SG3 support for T.38 is on the roadmap for next year (2009).
- If you need to interoperate with third party fax devices, such as fax servers or voice gateways, then T.38 fax relay is the best choice.
Fax Servers
A growing trend in FoIP is the installation of IP-based fax servers. Similar to a Cisco Unified Communications Manger for fax calls, fax servers offer a centralized device for handling an organizations fax needs. The fax server uses the T.38 transport method to send and receive faxes from Cisco voice gateways. Additionally, the fax server can be accessed from a number of other sources as well, including Multi Function Peripherals (MFPs) that combine printing, scanning, copying, and faxing in one device, web interfaces, special fax clients, and even email. In fact, using a fax server provides all of the benefits of T.37 with the real-time fax capabilities of T.38. Figure 6 highlights how a fax server integrates into an IP environment.
As show in Figure 6, a fax server can integrate into an existing VoIP network that uses Unified CM while also sending and receiving faxes from other devices such as email clients, fax clients, and MFPs. Additionally, fax servers have Application Programming Interfaces (APIs) that allow other systems to access them for the faxing of documents, such as orders and invoices. Sent and received faxes can also be easily archived by the fax server if necessary. If fax is a critical form of communication for your organization, then a fax server offers many key benefits and is a solution worth exploring.
Summary
Fax and voice communications are different and this is especially true in the IP world. Implementing fax communications in an IP environment requires the use of specific transport mechanisms that are not required for voice. Additionally, FoIP has its own unique design considerations that must be considered to ensure reliable faxing across IP infrastructures.
While FoIP network design and implementation can become much more involved, this article provides you with the basic information necessary to start making FoIP implementation decisions. Please consult other FoIP resource such as Cisco’s own webpage or the book Fax, Modem, and Text for IP Telephony for additional information on implementing FoIP.
