T.38 Fax
From Wikipedia, the free encyclopedia
Contents |
[edit] T.38 Fax Relay
The T.38 fax relay standard was devised in 1998 as a way to permit faxes to be transported across IP networks between existing G3 fax terminals. After IP, the Internet Protocol, the Group 3 (G3) facsimile(fax) standard is the most-used computer-to-computer protocol. Although fax, the electronic transmission of an image over distance in real time between sender and intended recipient, has been in existence for over 100 years, G3 fax, the standard used hundreds of millions of times every day, was first published as an international standard in 1980. Since the advent of Internet e-mail, many have predicted the demise of fax, and they’ve all been wrong. Today, it’s ingrained as one of the fundamental modes of business communications.
Figure 1
In 1980, when the T.4 and related fax standards were released by the ITU (see sidebar, Fax-Related Standards), the Internet hadn’t been born. That didn’t happen until January 1983, and useful VoIP (voice over IP) didn’t come along until the late ‘90s. Now, in 2006, the rate of adoption of IP as a telephony transport by enterprises and carriers is soaring. But what about using the Internet (IP) to transport fax, FoIP or fax over IP?
There are two primary ways that fax transactions are conveyed across packet networks, such as.IP The T.37 standard specifies how a fax image is encapsulated in e-mail and transported, ultimately, to the recipient using a store-and-forward process through intermediary entities. T.38, however, defines a protocol that supports the use of the T.30 protocol in both the sender and recipient terminals. (See diagram above.) T.38 lets one transmit a fax across an IP network in real time, just as the original G3 fax standards did for the traditional (time-division multiplexed (TDM)) network, also called the public switched telephone network or PSTN.
A special protocol is needed for real-time fax over IP (Internet Protocol) since existing fax terminals only supported PSTN connections, where the information flow was generally smooth and uninterrupted, as opposed to the jittery arrival of IP packets. The trick was to come up with a protocol that makes the IP network “invisible” to the endpoint fax terminals, which would mean the user of a so-called legacy fax terminal need not know that the fax call was traversing an IP network.
The network interconnections supported by T.38 are shown above. The two fax terminals on either side of the figure communicate using T.30, the protocol released by the ITU in 1980. Interconnection of the PSTN with the IP packet network requires a “gateway” between the PSTN and IP networks. PSTN- IP Gateways support TDM voice on the PSTN side and VoIP and FoIP on the packet side.
For voice sessions, the gateway will take in voice packets on the IP side, accumulate a few packets to insure a smooth flow of TDM data upon their release, and then meter them out over TDM where they eventually are heard by a human or stored on a computer for later playback. The gateway employs packet-management techniques to enhance the quality of the speech in the presence of network errors by taking advantage of the natural ability of a listener to not really hear the occasional missing or repeated packet.
But fasimile data are transmitted by modems, which aren’t as forgiving as the human ear is for speech. Missing packets will often cause a fax session to fail at worse or create one or more image lines in error at best. So the job of T.38 is to “fool” the terminal into “thinking” that it’s “talking” directly with another T.30 terminal. It will also correct for network delays with so-called spoofing techniques, and missing or delayed packets with fax-aware buffer-management techniques.
Spoofing refers to the logic implemented in the protocol engine of a T.38 relay that modifies the protocol commands and responses on the TDM side to keep network delays on the IP side from causing the transaction to fail. This is done, for example, by padding image lines or deliberately causing a message to be re-transmitted to render network delays transparent to the sending/receiving fax terminals.
But what about networks that do not have packet loss and excessive delay? Can they do without T.38? Such networks can exhibit acceptable performance, provided the PCM clocks in all gateways are of very high accuracy (explained below). T.38 not only removes the effect of PCM clocks not being synchronized, but also reduces the required network bandwidth by a factor of 10, while it corrects for packet loss and delay.
[edit] Bandwidth Reduction
As shown in the diagram below, a T.38 gateway is comprised of two primary elements: the fax modems and the T.38 subsystem. The fax modems modulate and demodulate the PCM samples of the analog data, turning the sampled-data representation of the fax terminal’s analog signal to its binary translation, and vice versa. The PSTNnetwork samples the analog signal of a voice or modem signal (it doesn’t know the difference) 8,000 times per second (SPS), and encodes them as 8-bit data bytes. This means 8000 samples-per-second times 8-bits per sample, or 64,000 bits per second (bps) to represent the modem (or voice) data in one direction. For both directions the modem transaction consumes 128,000 bits of network bandwidth.
However, the typical modem in a fax terminal transmits the image data at 14,400 bps, so if the analog data are first converted to the digital content they represent, only 14,400 bits (plus network overhead of a few bytes) are needed. And since T.30 fax is a half-duplex protocol, the network is only needed for one direction at a time.
[edit] PCM Clock Synchronization
In the diagram above, there is a sample-rate clock in the fax terminal and one in the gateway’s modems that is used to trigger the sampling of the analog line 8,000 times per second. These clocks are usually quite accurate, but in some low-cost terminal adapters (a one or two-line gateway) the PCM clock can be surprisingly inaccurate. If the terminal is sending data to the gateway, and the gateway’s clock is too slow, the buffers (jitter buffers) in the gateway will eventually overflow, causing the transaction to fail. Since the difference is often quite small, this problem occurs on long, detailed fax images giving the clocks more time to cause the jitter buffer in the gateway to either underflow or overflow, which is just the same as missing or duplicated packets.
Figure 2
[edit] Packet Loss
T.38 provides facilities to eliminate the effects of packet loss through data redundancy. When a packet is sent, either zero, one, two, three, or even more of the previously sent packets are repeated. (The specification does not impose a limit.) This increases the network bandwidth required (it’s still much less than net using T.38) but it allows the receiving gateway to reconstruct the complete packet sequence, even with a fairly high level of packet loss.
[edit] T.38 Version 0, 1, 2, 3
T.38, the ITU recommendation for real-time fax over IP, was first determined in June 1998. Since then, there have been corrections, amendments, and new versions. One of the most interesting had to do with the ASN.1 (Abstract Syntax Notation) used in T.38. ASN.1 is a notational language that formalizes the specification of communications protocols, and reduces the amount of signaling data that must be transmitted relative to text-based protocols. It’s similar to a programming language in that the binary output is precisely described by the input. Since ASN.1 is not text-based, mistakes in ASN.1 are not readily discerned. So if a mistake makes its way through the review process there is a problem. That’s just what happened in the first—what later become known as Version 0—T.38. A comma followed by a return and an ellipsis on the following line was omitted.
Of course the typo was eventually discovered, and, in 2002, Version 2 of T.38 finally corrected the error. But wait! By that time several companies had implemented the ASN.1 specified in the first version. So gateways that implemented the first and “corrected” version of T.38 (V2) were not interoperable, clearly a bad outcome for the correction. So, in July 2003, a correction to the correction (Corrigendum in ITU speak) was issued. It recommends that version numbers be a mandatory attribute in T.38 to indicate which ASN.1 syntax is used, enabling corresponding gateways to use the same encoding. (If no version number is provided by a gateway, Version 0 is assumed.) So the corrected-corrected version became Version 2 along with its Corrigendum.
Earlier, Version 1 had added TCP; later, version 3 added V.34 support. Below are details the versions and the major changes of each:
Version Form Date Changes
Version 0, T.38 June ‘98, Original T.38 w/ ASN.1 error,
Corrigendum April ‘99, Noted ASN.1 incompatibilities
Version 1, T.38 Nov 2000, TCP support, IAF support
Version 2, T.38 2002 Updated Recommendation, changing ASN.1 syntax
Corrigendum July 2003 Made version numbers a mandatory attribute. Tied version number negotiated to ASN.1 syntax used
Version 3, T.38 July 2004 Added V.34 support
[edit] Interoperability
T.38 was first “determined” (to use ITU speak) in 1998, and, as with many telecom standards, adoption by equipment vendors and carriers and enterprises takes considerable time. One necessary aspect of this is the process of working out interoperability problems between equipment vendors, which had not occurred by 2001. In January 2002, Commetrex Corporation opened its T.38 Interoperability Test Lab(http://www.commetrex.com/TT38Forum/T38_portal.html), which was open to any equipment vendor with a fielded T.38 gateway. The effect was a rapid acceleration of T.38 adoption by network-equipment vendors and service providers. Even so, the migration of the world’s networks to IP and the migration of T.38 into deployed gateways takes years, not months.
Fax modems and T.38 fax relay are highly specialized technologies that are developed by companies such as Commetrex, Encore Software, Gao Research, HelloSoft, Netbricks, and SoftRISC. They license the software to network-equipment vendors, such as InfiNet Wireless and Sonus Networks, who, in turn, sell their equipment to IP carriers and service providers. As of 3Q2006, this process is only beginning to reach end users through IP carriers such as iBasis, which uses Cisco gateways, and Global Crossing.
[edit] The ITU Fax-Related Standards
All referenced standards are published by the International Telecommunications Union, an agency of the United Nations.
T.4 – T.4 is the umbrella specification for fax. It specifies the standard image sizes, two forms of image-data compression (encoding), the image-data format, and references, T.30 and the various modem standards.
T.6 - T.6 specifies a compression scheme that reduces the time required to transmit an image by roughly 50-percent.
T.30 – T.30 specifies the procedures that a sending and receiving terminal use to set up a fax call, determine the image size, encoding, and transfer speed, the demarcation between pages, and the termination of the call. T.30 also references the various modem standards.
V.21, V.27ter, V.29, V.17, V.34 – ITU modem standards used in facsimile. The first three were ratified prior to 1980, and were specified in the original T.4 and T.30 standards. V.34 was only recently published for fax.
T.38 – The ITU standard for real-time fax relay across an IPnetwork.
T.37 – The ITU standard for sending a fax-image file via e-mail to the intended recipient of a fax.
