There are several operating issues affecting the successful transmission of a fax via the Internet. One of them is protocol conversion. Since there are about 250 million fax machines out there that only understand T.30, FoIP has to convert T.30 data into T.38 data for transmission and then convert T.38 data back into T.30 data for reception. This translation happens at the fax server/gateway.
A software bundle in the fax server acts as a bridge between the two protocols. The fax/modem component converts analog fax signals into digital data on the sending end and digital data into fax signals on the receiving end. The fax/network component puts digital data into IP data packets on the sending end and takes those packets apart on the receiving end. The fax/protocol component coordinates the T.38 actual timing with the T.30 expected timing -- for instance, the software will send a signal to stop the receiving fax machine from timing out when a packet is delayed.
This brings us to another issue with IP faxing: network timing. Transmission time through the various nodes of an Internet network is not nearly as standardized as timing on phone lines. If the timing is off in a fax session, the machines might not be able to understand each other, and the transmission of information can end up corrupted or just fail entirely. In IP faxing, there are delays caused by:
- Processing - It takes time for the fax gateway to perform T.30/T.38 conversions and gather the fax data into IP packets for transmission.
- Network hold-ups - If any particular leg of a network is experiencing abnormally high traffic, a packet can arrive later than expected.
- Jitter buffers - The fax gateway may delay packets on the receiving end for a period of time to compensate for variable timing in packet arrival. It wants to send everything to the receiving fax machine in the right order and at the right intervals.
In the case of jitter buffers, a method of compensating for timing problems actually causes some additional delay. In most cases of poor timing, the gateway can negotiate with the receiving fax machine to keep the connection open until the transmission is complete. If a packet arrives out of order at the gateway, it can put it back into the right sequence by reading the sequence number included in each packet.
Of course, if a packet is lost, there's no sequence number to read. And when you're dealing with a network like the Internet, packets do sometimes get lost. FoIP compensates for lost packets using various error-correction methods. One is redundant packets, which is used when transmitting faxes via the UDP/IP protocol layer. Each packet includes its own data along with the data from the previous packet, so two consecutive packets would have to disappear in order for the data to be lost. Another error-correction scheme is one that's built into the TCP/IP protocol layer. TCP requires a receipt confirmation for each packet it sends, and it resends the packet if there's no confirmation. (See searchNetworking: TCP/IP and searchNetworking: UDP to learn about these protocols.)
FoIP has a ways to go before it's as reliable as traditional phone-line faxing, but the implementation of a real-time IP faxing scheme has made it a very attractive option for anybody who sends a lot of long-distance faxes. In most cases, the cost savings and network integration of FoIP far outweigh the downside of having to occasionally resend a fax that doesn't go through.
For more information on FoIP and related topics, check out the links on the next page.