Commetrex Corporation
Copyright© 2009
All Rights Reserved
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 LAN, which uses on-premises gateways—let’s call that IP Fax Phase I--and are connecting with the IP service provider via SIP trunking—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.
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. 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. 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. So, what is a “fax/facsimile”? When it comes to IP fax there seems to be some confusion, but 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.
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, the ability to handle missing, late, and out-of-order packets, of a T.38 implementation 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.
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, first 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 needed 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 the enterprise-fax industry is today, how we got here, and where it’s headed.
Phase I of enterprise IP-fax adoption was its use in intra-enterprise applications. T.38 was determined by the ITU in mid-1998, and some quick-to-market vendors 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. Gateways were required to move the fax beyond the enterprise.
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.
In 2005, the international 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 in late 2008, 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 (http://www.sipforum.org) 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, 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 their interop requirements and how they handle T.38 on their Websites.
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.
We have established that “issues” sometimes arise when a business tries to use IP to transport fax by directly connecting with an access provider, typically via SIP trunking. Once the access provider is interconnected with other carriers to access the global E.164 telephone numbering scheme, the FCC becomes involved in the U.S., as are similar agencies in other countries. There are various shared costs, such as administering Local Number Portability and Universal Access, that the provider must support. So, in the US, the provider must submit Form 499-A to the FCC to become a registered provider. (You can find these companies at http://fjallfoss.fcc.gov/cgb/form499/499a.cfm.) Once registered, the provider can obtain “telephone numbers.”
If you are a business user or premises-equipment vendor you will typically be confronted with at least two types of local-access providers, in addition to the incumbent telco. If you are an enterprise-equipment vendor, being familiar with the differences can help you select access-provider partners. Let’s call the two types CLECs and VoIP service providers. From Form 499-A:
A Competitive Access Provider/Competitive Local Exchange Carrier
competes with incumbent local exchange carriers (LECs) to provide local exchange services, or telecommunications services that link customers with inter-exchange facilities, local exchange networks, or other customers, other than Coaxial Cable providers.
Interconnected VoIP service:
An interconnected Voice over Internet protocol (VoIP) service is a service that: (1) Enables real-time, two-way voice communications; (2) Requires a broadband connection from the user's location; (3) Requires Internet protocol-compatible customer premises equipment (CPE); and (4) Permits users generally to receive calls that originate on the public switched telephone network and to terminate calls to the public switched telephone network.
Cbeyond Communications and Bandwidth.com are examples of CLECs, since they will obtain T1 service, for example, from the local incumbent carrier and provide premises equipment to terminate the T1 connection and provide voice and data services. Services such as Cbeyond and Bandwidth.com’s may or may not support fax, although neither of them supports T.38.
Packet8 (from 8x8, Inc.) and Vonage are examples of VoIP service providers. Each of them assumes the subscriber has a broadband service, typically DSL, installed. They then provide terminal adapters or SIP phones for VoIP and, in the case of Packet8, a T.38-capable terminal adapter for a fax machine. (The Vonage adapter for a fax terminal uses G.711 pass-through…be careful.)
Since VoIP service providers typically rely on an ADSL connection, their focus is more strongly on the residential and SOHO markets, as these subscribers usually cannot justify the cost of T1 service.
In 1Q2009, 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’ T.38. 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 rapid move to T.38 by the access provider in 2009 and 2010.
But it took them over 10 years from the time T.38 was determined by the ITU to get here, 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 anytime soon as the carriers have only recently installed gateways with V.17 support, and Commetrex, the primary fax-technology supplier to the equipment industry, just began shipping V.34 in late 2007. Although it won’t take 10 years to put the interop challenges of Phase II behind us, let’s get busy and make it happen.
|
