The State of IP Fax in 2010

After years of incubation within the confines of the enterprise IP network, IP-based fax has recently entered a period of rapid and increasingly broad adoption. Business users are now pushing beyond the enterprise network, which uses on-premises gateways—let’s call that IP Fax Phase I–and are now directly connecting with the IP service provider via SIP trunking or direct SIP peering—IP Fax Phase II–obviating the need for the enterprise gateway. However, not all local-access providers are ready with effective IP-fax support, and the backbone IP providers have only recently begun the move to provide for the transport of quality IP-based fax. International IP fax, peered between national carriers, has yet to get underway.

As with any introduction of a new technology, this transition period of IP-fax adoption is not without challenges. It requires effective internetworking between the enterprise and the access provider, and between the access provider and long-haul IP networks, often resulting in several tandem connections. And ironing out the kinks isn’t always simple, as it requires an unusual degree of inter-vendor cooperation. Moreover, if a fax session transits the open Internet, the use of T.38 fax relay is usually required for reliable fax transmission, and T.38 support is still uneven. So, much of the challenge for users and service providers is to find partners and vendors that support T.38 in their equipment and networks and are willing and able to solve session-setup problems. Then, we must overcome firewall, network address translation, registration, authentication, routing, and T.38 handoff challenges

But prior to reviewing this transition period one step at a time, let’s settle on a definition of fax, since that’s what this paper is about and there seems to be some confusion as to what is a “fax/facsimile”? We can actually turn to the courts for an answer. It turns out there is some amount of intellectual-property legal jousting going on out there, and one case actually resulted in a definition of “facsimile” or faxing. One ruling from the Federal District Court of Central California (paraphrasing) defines the word “fax,” or “facsimile,” as image data transmitted between two endpoints (fax terminals) that use the T.30 protocol to govern the transaction. This means, for example, that sending or receiving an e-mail with an attached image file is not “faxing” or sending a fax. T.30 is the international standard that specifies the procedures for computer-to-computer (yes, all G3 fax terminals are computers) image exchange. If T.30 isn’t being executed on each end of the exchange, it isn’t a fax, and this paper is about fax.

But T.30 and its related recommendations, such as T.4, T.6, and the fax-modems, were developed prior to the Internet’s use as a telephony transport, and the timing restrictions of T.30 usually can’t be maintained when using an error-correcting protocol, such as TCP, so PCM streams are transported using UDP, a best-effort protocol, combined with an additional protocol, T.38. T.38’s job is to make an interposing IP network transparent to two communicating T.30 endpoints, as shown in the figure below.

T.30 Protocol

The network diagram shows two fax terminals communicating using the T.30 protocol and two IP-PSTN gateways communicating using T.38. If the gateways and their T.38 do their job, the two fax machines are “unaware” that there is an IP network involved. T.38 makes an interposing IP network transparent to the two T.30 terminals.

But not all gateways, especially those more than five years old, support T.38. And even if the gateways support T.38, the IP-network operator may not offer a T.38 service. Without T.38, these less-capable gateways and networks will try to complete the fax transaction with what is known as “G.711 pass through.” G.711 is simply the encoding scheme used to represent analog signals, such as voice and modem, on digital telephone networks. There are usually a few differences between how voice and modem data are handled, but basically, these gateways try to transport the fax session’s modem signals as though they were voice. However, modems are much less tolerant of packet loss than our ears, so G.711 pass-through can result in image errors and dropped calls when packet loss occurs, while a voice call might sound just fine. This does not mean that G.711 pass through should not be used for fax. There are some applications, such as a high-speed enterprise LAN or metro-network, where it works just fine. (But beware of long pages sent using super-fine resolution even in these controlled environments.)

Note that performance and interoperability of T.38 implementations vary widely. Performance metrics include the ability to handle missing, late, and out-of-order packets of a T.38 implementation, and can be very poor, even when the interoperability may be excellent. Interoperability results from effective implementation of the T.38 recommendation; performance results from years of fax-technology experience and effective design of the developer. Less-capable T.38 implementations can only handle packet delays of a few 100-milliseconds or so, while the best implementations handle nearly five seconds of delay, supporting the delays inherent in geosynchronous-satellite links.

Fax Server Finally, let’s settle on one more term: “terminating T.38”. Take a look at the figure on the previous page. Now, remove the PSTN network on one side and you remove the need for analog modems in the gateway function. Then, combine the function of the two remaining network elements on that side, the fax terminal and the gateway, and you have “terminating T.38”, the integration of T.30 and T.38 in one system, as shown in the figure to the right. Terminating T.38, invented and shipped by Commetrex in 2001, is the function that allows fax servers to send and receive faxes within an IP network. T.38 is used for fax transport in lieu of the analog modems used for TDM networks. Think of the T.38 protocol engine in an IP network as being functionally equivalent to the analog modems in a TDM network (or G.711 pass through in an IP network without T.38 support). Of course, all of these entities use T.30 as the end-to-end protocol.)

Currently, terminating T.38 is sweeping the enterprise-fax industry, as businesses have dramatically reduced investments in TDM-based systems (or at least in TDM systems that can’t be easily upgraded to IP-based systems). Enterprise-fax vendors are scrambling to make sure they have a solid, cost-effective terminating-T.38 solution.

So, let’s look at where FoIP is today, how we got here, and where it’s headed.

Phase I

Phase I of enterprise IP-fax adoption was its use in intra-enterprise applications. T.38 was released by the ITU in October 1998, and some quick-to-market vendors (such as Commetrex) began shipping T.38-capable terminal adapters and gateways in 1999, enabling enterprises to use their corporate IP networks to move intra-enterprise faxes between offices and within the corporate LAN. Premises-located gateways were required to move the fax beyond the enterprise edge.

The industry’s first T.38-based enterprise fax server shipped in early 2002, permitting those enterprises to avoid the cost and system complexity of multi-line fax boards in their fax servers. But we still had not been able to move the IP-based fax beyond the enterprise network. That has required the industry to mature somewhat–to move to Phase II.

Phase II

In 2005, the large-footprint IP carriers began to deploy their second-generation infrastructure, which included T.38-capable equipment, enabling some of them to make T.38 service commitments. And the momentum continues to build as more IP-network vendors offer T.38 for both inbound and outbound. Moreover, in 2006, some access-service providers began tentative support for T.38. But their long-haul peering arrangements were problematic because only some of their partners would carry a T.38 session. Special routing was required.

With IP carriers finally moving to provide effective support for fax, the push for direct SIP trunking began to take hold. SIP trunking allows enterprise equipment, such as IP PBXs and IP fax servers, and their IP service providers to directly connect without the need for intervening PSTN-IP gateways. The move received a good push in 2007 when the SIPforum came up with its SIPconnect recommendation. SIPconnect is not a new “standard”, but a recommendation of practices intended to promote interoperability of SIP peering between the enterprise and the IP service provider.

But even with the benefit of SIPconnect, achieving interoperability can often be a challenge. Premises-equipment vendors and access-service providers must work together effectively to achieve SIP-trunking interoperability. And access providers and IP-backbone providers must do the same. This means clear published interop requirements and access to qualified technical people for enterprise-equipment vendors, access providers, and backbone providers. But, all too often, the service provider’s attitude is that interop requirements are for them to know and the enterprise-equipment vendor’s responsibility to somehow figure it out and make it work. Nothing can do more to accelerate the adoption of T.38 for robust fax transport than for the access providers and backbone providers to publish on their Websites their interop requirements and an explanation of how they handle T.38.

Some access providers, such as Packet8, which offers T.38, are working to do something about the problem of effective IP transport of fax sessions. Others simply tell their enterprise customers to keep their legacy fax lines (at over $40 per month) if they are interested in error-free faxes (and who isn’t?). Others have resorted to store-and-forward techniques by terminating a fax call on premises and sending the file. But, as we have seen, that’s not a fax.

Known Phase II Problems

Through rigorous testing, Commetrex has found that significant practical problems with SIP negotiations for FoIP calls exist in carrier-based networks. We have discovered that in some carrier networks, many transaction failures aren’t caused by T.38, but by the session negotiations that occur at the beginning of a SIP-based FoIP call. After much analysis of the problems, we have developed Smart FoIP, a technology that improves the reliability of fax-session establishment for media servers, ATAs, and gateways.

It turns out that if an on-ramp gateway (the calling end) blindly accepts a T.38 re-invite from its off-ramp peer (in a non-V.34 session) the on-ramp gateway can actually cause a session, which would have otherwise succeeded, to immediately fail. To solve this problem, we developed Smart FoIP, Commetrex’ licensed software that includes patent-applied-for technology that puts intelligence into whether to accept a T.38 re-invite, eliminating this as a cause of failed sessions, boosting transaction success rates often by 10%.

An ATA (analog telephone adapter) or gateway with Commetrex’ proprietary relay technology attaches a V.21 modem (along with other analysis algorithms) to the media streams at the beginning of the call. The on-ramp gateway analyzes the decoded V.21 data to track the T.30 states of the calling and called terminals. The called terminal will repeatedly send its initial message (DIS) until the calling terminal sends its response. Once the calling fax terminal receives a complete DIS, it sends its response (DCS) within 75 milliseconds. Therefore, once this calling-terminal response (DCS) is received by the called terminal, uninterruptable modem operations have begun, and the gateways can no longer switch the session to T.38 without possible corruption of the T.30 states being maintained in the endpoint terminals.

With Smart FoIP, once the on-ramp gateway detects the preamble to the calling fax terminal’s response, it will no longer accept the T.38 re-invite, continuing the transaction in G.711 mode and avoiding the session failures caused by the transition occurring during a modem session.

In the case of an IP-based fax server there are no modems since the server is connected directly to the IP network, and the T.30 state machine and the T.38 protocol engine are both on the same system. Therefore, there is no need for a V.21 modem since the server maintains its own T.30 calling-terminal state. The server will accept T.38 re-invites up to the point where it has received the called terminal’s DIS, refusing all subsequent re-invites.

Of course, refusing a T.38 re-invite means continuing the session in what is called “G.711 pass-through mode”, making support for G.711 pass-through in server applications a Smart FoIP prerequisite. Commetrex’ BladeWare HMP, MMTF, and T.38 Fax Relay products all support both T.38 and G.711 pass through. (Commetrex’ TerminatingT38 does not). Smart FoIP is included in BladeWare beginning with Release 2.2. Of course, gateways and ATAs always support both, and they are plagued by this problem unless they have Commetrex technology with Smart FoIP inside.

So, what about G.711 pass-through fax? Carriers have done a great job of virtually eliminating dropped packets, but PCM clock-synchronization problems remain. The problem results from jitter buffer under-run and over-run caused by the PCM clocks at opposite ends of the link (the endpoint terminals) not being equal, which is always the case. The question, of course, is how unequal are they and how long is the fax? The more unequal they are, the quicker the session fails. Long-enough G.711 pass-through faxes and even long T.38 sessions can fail if the jitter buffers are not effectively handled. Commetrex’ Smart FoIP relay technology and BladeWare media servers include buffer-management technology that eliminates PCM-clock-synchronization problems in G.711 pass-through and T.38 fax sessions.

In BladeWare, our HMP fax-server platform, terminating G.711 IP faxes use the incoming G.711 packet stream for timing purposes. For every 20ms of G.711 data it receives, for example, the system generates an equal amount of data for transmit. So BladeWare’s G.711 data are exactly in sync with the remote relay’s sample clock, and we never overflow or underflow our G.711 buffers, nor does the remote gateway since we are slaved to its clock.

However, in relay-to-relay T.38 operations, there are two analog PCM sample clocks: one at the remote transmitting fax and the other at the local re-modulating modem. These two clocks always have a different rate. Bits generated at the transmitting endpoint fax terminal must be retransmitted by the off-ramp gateway’s local modem. If the remote fax is generating bits faster than the off-ramp gateway’s local modem can send them out to the fax terminal, off-ramp overflow eventually occurs. In the reverse case (off-ramp faster than transmitting fax terminal), the on-ramp modem will run dry since the off-ramp gateway is sending the bits out faster than it receives them, and T.38 relay will have to spoof some bits to keep the transmitter running (provided you have a well designed relay, of course). Underflow is not as much of a problem, since the relay can insert additional flags in V.21 data or padding bits at the end of a line of image data (Does your relay do that?). But overflow is a problem as valid data must be tossed (and modems just hate that).

Commetrex’ T.38 relay, which we license to telecom OEMs, includes patent-applied-for fax-aware jitter-buffer management that is specific to G.711 pass-through fax and eliminates PCM-clock sync problems in gateways.

V.34 Support

IT took the IP carriers over 10 years from the time T.38 was determined by the ITU to get Phase II underway, and they are using gateways that support V.17 fax, with a maximum data rate of 14,400bps. What about V.34 fax at 33,600bps? This very likely won’t happen soon as the carriers have only within the last five years installed gateways with V.17 support. But now that Commetrex, the primary fax-technology supplier to the telecom-equipment industry, is shipping T.38 with version 3 support (needed for V.34), we will see the technology begin to work its way through the equipment vendors and into the carrier networks. Moreover, the ITU has recently (3Q2010) accepted the SIP Forum’s FoIP Task Group recommendation for improvements to the T.38 recommendation that are necessary for T.38 V3 to actually interop and work in today’s SIP networks. With the technology and effective standards in place, adoption rates should begin to increase.

Whither Phase III?

In 4Q2010, we have entered a phase of rapid adoption of IP-based fax in the enterprise. If you are an enterprise user, you seriously consider SIP trunking to simplify your network. Lacking that, you can also prepare for the future by making sure that your new system is either all IP or capable of a smooth transition to all IP. If you are a vendor of enterprise fax systems, you are making sure your partners are ready to support both TDM and IP solutions. And consider SIP trunking as a requirement for your fax server.

The industry will soon leave the rough edges of the Phase I-to-Phase II transition behind as the backbone carriers move to their second-generation networks, usually based on Sonus GSX gateways, which support T.38 fax with Commetrex’ technology. Among them are Global Crossing, XO Communications, Qwest, AT&T, and Level(3). And with long-haul peering arrangements available with T.38 support, you’ll see a continued move to T.38 by the access provider in 2011 and beyond.

But just as SIP trunking hastened the move to Phase II, the adoption of T.38 by individual carriers and, finally, the national incumbent carriers, will usher in Phase III, the effective use of FoIP in international tandem-network calls. To solve the anticipated call setup problems of these calls, the SIP Forum FoIP Task Group (primarily equipment vendors) and the i3 Forum FoIP working group (primarily international carriers) have formed a testing cooperative that will characterize international FoIP performance in Q4-Q1, analyze the data in Q2, and make recommendations to the industry in 3Q2011.

Commetrex will continue to update this report to keep the State of the Fax current.