As we have seen in the previous blog article , there are major problems in carrying faxes over IP. Let’s see why Faxing over IP is a reliable standard for transmission of faxes.
A standard which makes the communication much more reliable, whenever conditions are not optional, is T.38.
The T.38 fax relay standard was devised in 1998 as a way to permit the transmission of faxes across IP networks between existing Group 3 (G3) fax terminals. T.38 carries T.30, the protocol used by faxes, over a packet-oriented connection.
Picture By Scuba1aja at the English language Wikipedia, CC BY-SA 3.0
T.38 converts the fax data’s audio signal to a digital image, using an ATA, and transmits it over the Internet. It is then converted back to an audio signal.
The standard can work both over UDP and TCP, but, in my experience, I have only seen UDP implementations.
A T.38 session is started after one of the two sides involved in the fax communication detects a FAX tone. Usually the part on the receiving side first detects a CED tone over the PSTN interface. This CED tone represents a confirmation to receive a fax sent by the receiving side. Fax detection prompts the Gateway ATA to send a re-INVITE with an updated SDP similar to the example below:
v=0
o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com
s=Session SDP
c=IN IP4 iftmg.there.com
t=0 0
m=image 49172 udptl t38
a=T38FaxVersion:0
a=T38maxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:260
a=T38FaxUdpEC:t38UDPRedundancy
If the remote side supports T.38, it replies with a similar SDP. Reusing the port (used earlier for the RTP transmission) is a common practice. Doing so avoids problems when one of the devices performing network and port address translation is behind a router.
After the SDP exchange, the real T.38 communication will take place. Tools like Wireshark allow you to see all T.30 messages and the data exchanged (as shown below).
One of the good aspects of T.38, compared to T.30, is that it allows you to clearly debug fax transmissions.
Most T.38 implementations support fax transmission using V.27 – V-29 and V.17 up to 14.400 baud/s, since V.34 is protected by numerous patents. In addition, fax machines supporting V.34 are not widespread and are affected by compatibility issues. Using V.17 is a good compromise to ensure speed and compatibility.
T.38 makes communications more reliable by implementing two different redundancy protocols: t38UDPRedundancy or t38UDPFEC. By sending the same frame over following packets, T.38 can reduce packet loss. Depending on how redundancy is set, 1, 2, or 3 (or more) of the previously transmitted frames can be included together, with the last one in a UDPTL packet transmitted over the network.
As fax machines are silent while receiving fax data (the fax image), fax transmissions are usually mono-directional. Therefore, the standard uses less bandwidth, by carrying T.30 instead of audio, than an RTP fax transmission using G.711. Using less bandwidth make congestion and packet loss less likely, thereby further increasing the chances of transferring the fax successfully.
Only operators, ATAs, and media gateways which support T.38 should be used.
Conclusions
Although fax transmissions are in decline, they are likely to stay with us for at the least the next ten years. Limited or zero fax support is still a major problem for many Unified Communication solution deployments and should not be ignored.
In this blog article, we saw that, when implemented properly, T.38 overcomes fax transmission problems also in the presence of packet loss. For this reason, it should be included in any Unified Communication Platform that requires fax capabilities.
Suggestion: Many ATA and media gateway devices currently on the market (from FXS/BRI/PRI/FXO to SIP) provide lackluster support for T.38, as a Google search for “ata t.38 problems” quickly shows. This issue is usually due to poor PCM clock synchronization in the gateway.
Instead of meaning that the standard doesn’t work, this issue requires careful selection of hardware. Some VoIP operators / manufacturers prefer not to support to T.38 to reduce implementation costs.
At Wildix, we are proposing T.38 as the default fax transmission mode, for both the built-in fax servers and the ATA / media gateways that we produce. I can assure you that the efforts in implementing a reliable T.38 implementation are fully justified, since it leads to a virtually problem-free fax transferring solution.
