The sad state of FAX standardisation
December 31st, 2008People think of the ITU as a standards body, and many of their documents say something like “ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU” on the front. However, when it comes to the actual document title they say something like “ITU-T Recommendation T.30″. They are nothing more than recommendations, widely treated with contempt by industry when it comes to compliance. Some ITU-T recommendations, like the G.168 recommendation, are rightly ridiculed in the industry. G.168 is a test spec for telephone line echo cancellers. It contains a lot of good tests, which a well designed canceller should pass. Used as a guide for the product developer it is very useful. As a formal test spec it suffers the minor drawback that you can simply mute the receive channel and pass the letter of most of the tests, while completely ignoring the spirit. Most ITU-T recommendations have areas where they are vague, and open to interpretation. Many have areas which hardly any real world equipment complies with. In this rant I want to look at the recommendations related to FAX.
Let’s start with the modem documents related to FAX - V.21, V.27ter, V.29, V.17 and V.34. V.21 is pretty simple, and there isn’t too much to get wrong implementing that. V.27ter, V.29 and V.17 have several areas where very few real world products match what the ITU-T documents say they should send. For example, they should send a period of all 1’s at the end of their training data, so the receiver can test if the training was successful. It is so common for modems to send something else, that no receiver can realistically use these test periods. This means a developer of a new implementation has to test against numerous products in the field, find the quirks they have, and make sure their own implementation tolerates all the abuses. This is very time consuming, and is a huge drag on getting solid products into the field. Some real world implementations just can’t be tolerated. For example, most modern Canon FAX machines ship with a V.29 modem so broken its signal is almost impossible to decode accurately. Most of the millions of thermal paper FAX machines still in use only support V.29 and V.27ter, so Canon machines will usually send FAXes to them at 4800bps. Canon seem to get away with this because most business FAX machines will communicate at the faster V.17 speeds, and never even try V.29. Maybe its unfair to single out Canon, as pretty much every FAX machine makers has many skeletons in their closet. I can’t say much about V.34, as I have no personal experience of implementing V.34 FAX. However, it seems to have taken a long time to shake out the V.34 FAX designs, so they interoperate well. It doesn’t sound like a solid document everyone adheres to.
The T.4 recommendation seriously lacks focus. It covers a hotch-potch of things related to FAX, although its most important function is to define the main image compression schemes for FAX. It does this suprisingly well. Altough there are a couple of variations in implementation out there, if you build a compressor and decompressor strictly to this document it should just work.
The T.30 recommendation is the heart of modern FAX. This was put together by a group of FAX industry people who thought compatibility was a four letter word (yes, their arithmetic really does seem to have been that good 
). At the end of the 70s it was really important for these guys to get their act together over compatibility, in order for a FAX machine industry to get off the ground. They approached this with the enthusiasm of a man going to the guillotine. They produced one of the classically woolly documents. You’ll find more about how to build a usable FAX machine from studying the tests in TSB85 (A test spec for T.30 compliant FAX machines from the TIA) than from T.30 itself. T.30 is a mass of half finished statements, which fail to tie down exactly what they mean. It hasn’t got any better over time. Try looking at the latest additions and tell me precisely what their definition of an Internet aware FAX machine really is. FAX today works because of endless interoperability testing a long time ago, and people sticking to what they found worked. Its not spec based. Its folk knowledge based.
The T.38 recommendation is the key one for making traditional FAX machines interoperate with the IP world. It is much newer than the older specs, and you might expect people would have learned their lesson, and made sure it really told the implementor what to send and what to expect. Dream on. This document makes T.30 look like a robust standard. In some places the original was so bad there are a few clarifications in later revisions. These clarifications seem merely intended to poke fun at people having problems implementing T.38. They clarify nothing, and introduce fresh new confusion. Implementing T.38 is mostly a matter of looking at what rubbish other people send, and trying to fit in with it… and its a mess. Its 10 years since the first revision of T.38 saw the light of day, and interoperability is still a farce. When checking if your box might be compatible with another, don’t just check models. You will need to check the exact software revisions they are using too. This is not just the case with $30 ATA’s, where the suppliers really don’t give a damn about quality. Its true of the big infrastructure makers too.
So, what should an earnest engineer, trying to do a good job, do? Cry, would be my first recommendation. Once you’ve got that out of your system, try to follow basic sound engineering - be cautious about what you send, and expect to receive a lot of garbage. Send precisely what the recommendation says, where it says something precise. A lot of things are not defined very precisely, so try to send to the lowest common denominator, and see how it works out in the real world - test, test and test again, with every piece of kit you can find. On the receive side, be prepared to tolerate any weird signals you can, and test, test and test again.